forked from UCloudDoc-Team/uk8s
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
109 changed files
with
11,916 additions
and
11,916 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,22 +1,22 @@ | ||
|
||
## 名词解释 | ||
|
||
为了帮助你更好地使用UK8S,你需要对Kubernetes的相关组件有一个大致的了解,本文会对基础组件及概念做一个简要的介绍,如果你希望了解更多内容,请移步[Kubernetes官方文档](https://kubernetes.io/docs/concepts/) | ||
|
||
### Kubernetes基础架构 | ||
|
||
![](/images/introduction/kubernetes-whole-arch.png) | ||
备注:图片源自Kubernetes社区 | ||
|
||
上图是一个概要性的Kubernetes架构,包含了ApiServer,Master、Node、Hub(镜像仓库)等概念,下面我们依次做个简要介绍。 | ||
|
||
**ApiServer:** ApiServer是操作集群的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制,ApiServer作为一个组件运行在Master上。 | ||
|
||
**Node:**Node是Kubernetes的工作节点,其上包含运行Pod所需要的服务。Node可以是虚拟机也可以是物理机,在UK8S,目前只支持虚拟机即UHost。 | ||
|
||
**Master:** Master也是Kubernetes的工作节点,与Node不同的是,Master通常不运行业务Pod,而是安装了用于控制和管理集群的如ApiServer、Scheduler、Controller Manager、Cloud Controller Manager、ETCD等组件。 | ||
|
||
**Hub镜像仓库** Hub提供Docker镜像的管理、存储、分发能力。 | ||
|
||
|
||
|
||
|
||
## 名词解释 | ||
|
||
为了帮助你更好地使用UK8S,你需要对Kubernetes的相关组件有一个大致的了解,本文会对基础组件及概念做一个简要的介绍,如果你希望了解更多内容,请移步[Kubernetes官方文档](https://kubernetes.io/docs/concepts/) | ||
|
||
### Kubernetes基础架构 | ||
|
||
![](/images/introduction/kubernetes-whole-arch.png) | ||
备注:图片源自Kubernetes社区 | ||
|
||
上图是一个概要性的Kubernetes架构,包含了ApiServer,Master、Node、Hub(镜像仓库)等概念,下面我们依次做个简要介绍。 | ||
|
||
**ApiServer:** ApiServer是操作集群的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制,ApiServer作为一个组件运行在Master上。 | ||
|
||
**Node:**Node是Kubernetes的工作节点,其上包含运行Pod所需要的服务。Node可以是虚拟机也可以是物理机,在UK8S,目前只支持虚拟机即UHost。 | ||
|
||
**Master:** Master也是Kubernetes的工作节点,与Node不同的是,Master通常不运行业务Pod,而是安装了用于控制和管理集群的如ApiServer、Scheduler、Controller Manager、Cloud Controller Manager、ETCD等组件。 | ||
|
||
**Hub镜像仓库** Hub提供Docker镜像的管理、存储、分发能力。 | ||
|
||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,49 +1,49 @@ | ||
# 集群节点配置推荐 | ||
|
||
## 1. Master 配置推荐 | ||
|
||
Master 规格跟集群规模有关,集群规模越大,所需要的 Master 规格也越高,不同集群规模的,Master 节点配置推荐如下: | ||
|
||
|节点规模| Master规格| | ||
|:-:|:-:| | ||
|1-10 个节点| >=2 核 4G| | ||
|10-100 个节点| >=4 核 8G| | ||
|100-250 个节点| >=8 核 16G| | ||
|250-500 个节点| >=16 核 32G| | ||
|500-1000 个节点| >=32 核 64G| | ||
|1000 个以上节点|联系我们| | ||
|
||
UK8S Master 节点系统盘默认 40G(不可调整),用于储存 ETCD 信息及相关配置文件等。 | ||
|
||
如随着集群规模提升,有升级 Master 节点规格配置需求,请在云主机节点管理页面,**逐台进行更改配置**。 | ||
|
||
在升级下一台 Master 节点前,**请确保其它两台 Master 节点已处于 Ready 状态**,且 Master 节点上 Kubernetes 相关核心组件状态均处于 **active** 状态。Master 节点核心组件排障方法请参考:[Node 常见故障处理](/uk8s/troubleshooting/node_debug_summary) | ||
|
||
|
||
## 2. 如何选择 Node 配置大小 | ||
|
||
UK8S 集群要求 Node 配置不小于 2C4G,系统盘默认 40G(不可调整),用于储存相关配置文件等等。 | ||
|
||
**关于 Node 节点的资源预留策略** | ||
|
||
在确定 UK8S 的 Node 节点配置之前,您需要知道,UK8S Node 默认预留 **1G 内存,0.2 核 CPU** 以保障系统稳定运行。这些预留的资源是给系统及 Kubernetes 相关服务进程使用的。 | ||
|
||
且当可用内存小于 5% 时会根据 pod 资源优先级开始驱逐,pod 实际可使用的内存约为 {Memeroy of Node}-1G-5% (例如:4G内存,可用约为2.8G),同时,单个节点可创建 Pod 和 Node CPU 核数有关。Pods 数量 = CPU 核数 x 8 (例如:2 核支持最多 16 pods, 4 核支持最多 32 pods)。 | ||
|
||
因此,我们建议 Node 的配置 >= 2C4G,这是保证集群正常运行的基础配置。 | ||
|
||
对于存储资源,UK8S 的 Node 节点默认 40G 系统盘。节点创建时可选择数据盘挂载(亦可在节点创建完成后在主机侧挂载),如节点挂载有数据盘,将用于 Docker 存放本地镜像的,否则本地镜像等将保存在系统盘。请保证该盘磁盘空间充足,避免触发空间不足导致的镜像或 Pod 自动清理。 | ||
|
||
**生产环境 Node 配置选项建议** | ||
|
||
生产环境的 Node 配置选项,可根据整个集群的日常使用的总核数以及故障容忍度、业务类型综合考量,具体如下: | ||
|
||
假设集群总核数设定为 240 核(基于过往运营数据而定),可以容忍 10% 的错误。那么可以选择 10 台 24 核 UHost,并且高峰运行的负荷不要超过 240 * 90% = 216 核。如果容忍度小于 5%,那么可以选择 15 台 16 核的 UHost,这样就算有一台节点出现故障,剩余节点仍可以支持现有业务正常运行(工作负载自动迁移)。 | ||
|
||
从提供错误容忍度的角度看,节点配置越低,节点会更多,那可用性也会相应地提高。但也存在另外两个弊端,一是需要预留给 K8S 的资源过多,造成浪费;二是不便于容器调度,甚至会导致部分容器无法被注册。一个极端的例子,3 台 8 核的节点,可创建 6 个需要预留4核的Pod,但 12 台 2 核的节点,却无法响应一个需要预留 4 核资源的Pod请求。 | ||
|
||
综合资源有效利用率、错误容忍度两个因素,在不考虑业务混合部署、业务总体规模大小的情况下,我们建议生产环境的 Node 节点 CPU 应该介于 4 核至 32 核之间。 | ||
|
||
至于 CPU:Memory 比例,建议根据自身的应用类型申请合适的机型,例如 CPU 密集型的业务可以申请 1:2 的机型,Java 类的应用可以申请 1:4 或 1:8 的机型,如果是不同业务混合部署,最好给 Node 打好标签,配合nodeAffinity 节点亲和性合理调度Pod。 | ||
|
||
|
||
# 集群节点配置推荐 | ||
|
||
## 1. Master 配置推荐 | ||
|
||
Master 规格跟集群规模有关,集群规模越大,所需要的 Master 规格也越高,不同集群规模的,Master 节点配置推荐如下: | ||
|
||
|节点规模| Master规格| | ||
|:-:|:-:| | ||
|1-10 个节点| >=2 核 4G| | ||
|10-100 个节点| >=4 核 8G| | ||
|100-250 个节点| >=8 核 16G| | ||
|250-500 个节点| >=16 核 32G| | ||
|500-1000 个节点| >=32 核 64G| | ||
|1000 个以上节点|联系我们| | ||
|
||
UK8S Master 节点系统盘默认 40G(不可调整),用于储存 ETCD 信息及相关配置文件等。 | ||
|
||
如随着集群规模提升,有升级 Master 节点规格配置需求,请在云主机节点管理页面,**逐台进行更改配置**。 | ||
|
||
在升级下一台 Master 节点前,**请确保其它两台 Master 节点已处于 Ready 状态**,且 Master 节点上 Kubernetes 相关核心组件状态均处于 **active** 状态。Master 节点核心组件排障方法请参考:[Node 常见故障处理](/uk8s/troubleshooting/node_debug_summary) | ||
|
||
|
||
## 2. 如何选择 Node 配置大小 | ||
|
||
UK8S 集群要求 Node 配置不小于 2C4G,系统盘默认 40G(不可调整),用于储存相关配置文件等等。 | ||
|
||
**关于 Node 节点的资源预留策略** | ||
|
||
在确定 UK8S 的 Node 节点配置之前,您需要知道,UK8S Node 默认预留 **1G 内存,0.2 核 CPU** 以保障系统稳定运行。这些预留的资源是给系统及 Kubernetes 相关服务进程使用的。 | ||
|
||
且当可用内存小于 5% 时会根据 pod 资源优先级开始驱逐,pod 实际可使用的内存约为 {Memeroy of Node}-1G-5% (例如:4G内存,可用约为2.8G),同时,单个节点可创建 Pod 和 Node CPU 核数有关。Pods 数量 = CPU 核数 x 8 (例如:2 核支持最多 16 pods, 4 核支持最多 32 pods)。 | ||
|
||
因此,我们建议 Node 的配置 >= 2C4G,这是保证集群正常运行的基础配置。 | ||
|
||
对于存储资源,UK8S 的 Node 节点默认 40G 系统盘。节点创建时可选择数据盘挂载(亦可在节点创建完成后在主机侧挂载),如节点挂载有数据盘,将用于 Docker 存放本地镜像的,否则本地镜像等将保存在系统盘。请保证该盘磁盘空间充足,避免触发空间不足导致的镜像或 Pod 自动清理。 | ||
|
||
**生产环境 Node 配置选项建议** | ||
|
||
生产环境的 Node 配置选项,可根据整个集群的日常使用的总核数以及故障容忍度、业务类型综合考量,具体如下: | ||
|
||
假设集群总核数设定为 240 核(基于过往运营数据而定),可以容忍 10% 的错误。那么可以选择 10 台 24 核 UHost,并且高峰运行的负荷不要超过 240 * 90% = 216 核。如果容忍度小于 5%,那么可以选择 15 台 16 核的 UHost,这样就算有一台节点出现故障,剩余节点仍可以支持现有业务正常运行(工作负载自动迁移)。 | ||
|
||
从提供错误容忍度的角度看,节点配置越低,节点会更多,那可用性也会相应地提高。但也存在另外两个弊端,一是需要预留给 K8S 的资源过多,造成浪费;二是不便于容器调度,甚至会导致部分容器无法被注册。一个极端的例子,3 台 8 核的节点,可创建 6 个需要预留4核的Pod,但 12 台 2 核的节点,却无法响应一个需要预留 4 核资源的Pod请求。 | ||
|
||
综合资源有效利用率、错误容忍度两个因素,在不考虑业务混合部署、业务总体规模大小的情况下,我们建议生产环境的 Node 节点 CPU 应该介于 4 核至 32 核之间。 | ||
|
||
至于 CPU:Memory 比例,建议根据自身的应用类型申请合适的机型,例如 CPU 密集型的业务可以申请 1:2 的机型,Java 类的应用可以申请 1:4 或 1:8 的机型,如果是不同业务混合部署,最好给 Node 打好标签,配合nodeAffinity 节点亲和性合理调度Pod。 | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,2 @@ | ||
## 漏洞修复记录 | ||
|
||
## 漏洞修复记录 | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
# 漏洞修复记录 | ||
|
||
|
||
* [HTTP/2漏洞升级说明](/uk8s/introduction/vulnerability/cve2019-9512-9514) | ||
* [Runc容器逃逸漏洞修复说明](/uk8s/introduction/vulnerability/cve-2019-5736) | ||
* [CloudProvider插件更新说明](/uk8s/introduction/vulnerability/cloudprovider) | ||
|
||
# 漏洞修复记录 | ||
|
||
|
||
* [HTTP/2漏洞升级说明](/uk8s/introduction/vulnerability/cve2019-9512-9514) | ||
* [Runc容器逃逸漏洞修复说明](/uk8s/introduction/vulnerability/cve-2019-5736) | ||
* [CloudProvider插件更新说明](/uk8s/introduction/vulnerability/cloudprovider) | ||
|
Oops, something went wrong.