1.构成

Master节点

Master节点是集群的控制节点，由API Server、Scheduler、Controller Manager和

ETCD四个组件构成。

● API Server：各组件互相通讯的中转站，接受外部请求，并将信息写到ETCD中。

● Controller Manager：执行集群级功能，例如复制组件，跟踪Node节点，处理节

点故障等等。

● Scheduler：负责应用调度的组件，根据各种条件（如可用的资源、节点的亲和性

等）将容器调度到Node上运行。

● ETCD：一个分布式数据存储组件，负责存储集群的配置信息。

在生产环境中，为了保障集群的高可用，通常会部署多个Master，如CCE的集群高可

用模式就是3个Master节点。

Node节点

Node节点是集群的计算节点，即运行容器化应用的节点。

● kubelet：kubelet主要负责同Container Runtime打交道，并与API Server交互，

管理节点上的容器。

● kube-proxy：应用组件间的访问代理，解决节点上应用的访问问题。

● Container Runtime：容器运行时，如Docker，最主要的功能是下载镜像和运行容

器。

1.1基本对象

● Pod Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。

● Deployment Deployment是对Pod的服务化封装。一个Deployment可以包含一个或多个Pod，每个Pod的角色相同，所以系统会自动为Deployment的多个Pod分发请求。

● StatefulSet StatefulSet是用来管理有状态应用的对象。和Deployment相同的是，StatefulSet 管理了基于相同容器定义的一组Pod。但和Deployment不同的是，StatefulSet为它们的每个Pod维护了一个固定的ID。这些Pod是基于相同的声明来创建的，但是不能相互替换，无论怎么调度，每个Pod都有一个永久不变的ID。

● Job Job是用来控制批处理型任务的对象。批处理业务与长期伺服业务（Deployment）的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出（Pod自动删除）。

● DaemonSet DaemonSet是这样一种对象（守护进程），它在集群的每个节点上运行一个 Pod，且保证只有一个Pod，这非常适合一些系统层面的应用，例如日志收集、资源监控等，这类应用需要每个节点都运行，且不需要太多实例，一个比较好的例子就是Kubernetes的kube-proxy。

● Service Service是用来解决Pod访问问题的。Service有一个固定IP地址，Service将访问流量转发给Pod，而且Service可以给这些Pod做负载均衡。

● Ingress Service是基于四层TCP和UDP协议转发的，Ingress可以基于七层的HTTP和HTTPS 协议转发，可以通过域名和路径做到更细粒度的划分。

● ConfigMap ConfigMap是一种用于存储应用所需配置信息的资源类型，用于保存配置数据的键值对。通过ConfigMap可以方便的做到配置解耦，使得不同环境有不同的配置。

● Secret Secret是一种加密存储的资源对象，您可以将认证信息、证书、私钥等保存在 Secret中，而不需要把这些敏感数据暴露到镜像或者Pod定义中，从而更加安全和灵活。

● PersistentVolume（PV） PV指持久化数据存储卷，主要定义的是一个持久化存储在宿主机上的目录，比如一个NFS的挂载目录。

● PersistentVolumeClaim（PVC） Kubernetes提供PVC专门用于持久化存储的申请，PVC可以让您无需关心底层存储资源如何创建、释放等动作，而只需要申明您需要何种类型的存储资源、多大的存储空间。

1.2yaml

2.流程

POD创建流程

1. 用户通过kubectl或其它API客户端提交了Pod Spec给API Server。

2. API Server尝试着将Pod对象的相关信息存入etcd中，待写入操作执行完成，API Server即会返回确认信息至客户端。

3. API Server开始反馈etcd中的状态变化。

4. 所有的kubernetes组件均使用watch机制来跟踪检查API Server上的相关的变化。

5. kube-scheduler（调度器）通过其watcher觉察到API Server创建了新的Pod对象但尚未绑定至任何工作节点。

6. kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新至API Server。

7. 调度结果信息由API Server更新至etcd存储系统，而且API Server也开始反映此Pod对象的调度结果。

8. Pod被调度到的目标工作节点上的kubelet尝试在当前节点上调用Docker启动容器，并将容器的结果状态返回送至API Server。

9. API Server将Pod状态信息存入etcd系统中。

10. 在etcd确认写入操作成功完成后，API Server将确认信息发送至相关的kubelet告之其Pod状态。

deployment创建流程

包含图中第1步，由用户通过kubectl调用kube-apiserver接口创建一个ReplicaSet资源（也可以是其他资源，这里假设为ReplicaSet）。

包含图中第2步，kube-apiserver将要新创建的ReplicaSet资源信息(yaml文件表示的信息)写入etcd。

包含图中第0、3、4步，controller-manager通过List-Watch模式从kube-apiserver处获取所有其控制资源的数据，当然会包含新创建的ReplicaSet资源的数据。controller-manager收到新建ReplicaSet资源的数据后，对比当前ReplicaSet资源已有的Pod副本数，以及期望的Pod副本数。

包含图中第5、6步，由于ReplicaSet资源已有的Pod副本数，以及期望的Pod副本数之间肯定存在差异，controller-manager会将创建Pod的资源信息(yaml文件表示的信息)递给kube-apiserver，kube-apiserver而后将新建Pod资源信息(yaml文件表示的信息)写入etcd。

包含图中0、7、8步，scheduler通过List-Watch模式从kube-apiserver处获取所有其需要的资源的数据，当然会包含需要新建一个Pod的数据。大致的方式是查看是否所有Pod都已经分了节点资源，此时就会发现有Pod并未分配到节点。

包含图中第9、10步，scheduler通过调度算法选择一个节点分配给新创建的Pod，scheduler会通过kube-apiserver将数据最终写入到etcd中。

包含图中0、11、12步，kubelet通过List-Watch模式从kube-apiserver处获取所有其需要的资源的数据，当然会包含需要在当前节点新启动一个Pod的信息。大致的方式是得到当前节点所有需要运行的Pod信息，发现有一个Pod还未处于运行状态。

上面图中并未画出以下步骤，kubelet会通过CRI(Container Runtime Interface)通知到当前节点上的容器运行工具（如：Docker）需要创建一个新的Pod。完成创建后容器运行工具也会通过CRI(Container Runtime Interface)告知kubelet当前Pod状态。进一步kubelet也会将新创建的容器状态告知kube-apiserver而后更新etcd中有关当前Pod的资源信息。

3.pod编排调度

Deployment

StatefulSet

亲和与反亲和调度

弹性伸缩调度

4.网络

同一个节点中的Pod通信

不同节点上的Pod通信

service

在Kubernetes集群架构中介绍过Node节点上的kube-proxy，实际上Service相关的事情都由节点上的kube-proxy处理。在Service创建时Kubernetes会分配IP给Service，同时通过API Server通知所有kube-proxy有新Service创建了，kube-proxy收到通知后通过iptables记录Service对应的IP和端口，从而让Service在节点上可以被查询到。

下图是一个实际访问Service的图示，Pod X访问Service（10.247.124.252:8080），在往外发数据包时，在节点上根据iptables规则目的IP:Port被随机替换为Pod1的IP:Port，从而通过Service访问到实际的Pod。除了记录Service对应的IP和端口，kube-proxy还会监控Service和Endpoint的变化，从而保证Pod重建后仍然能通过Service访问到Pod。

Service 的类型与使用场景

Service的类型除了ClusterIP还有NodePort、LoadBalancer和Headless Service，这几

种类型的Service有着不同的用途。

● ClusterIP：用于在集群内部互相访问的场景，通过ClusterIP访问Service。

● NodePort：用于从集群外部访问的场景，通过节点上的端口访问Service，详细介

绍请参见NodePort类型的Service。

● LoadBalancer：用于从集群外部访问的场景，其实是NodePort的扩展，通过一个

特定的LoadBalancer访问Service，这个LoadBalancer将请求转发到节点的

NodePort，而外部只需要访问LoadBalancer，详细介绍请参见LoadBalancer类

型的Service。

● Headless Service：用于Pod间的互相发现，该类型的Service并不会分配单独的

ClusterIP，而且集群也不会为它们进行负载均衡和路由。您可通过指定

spec.clusterIP字段的值为“None”来创建Headless Service，详细介绍请参见

Headless Service。

Ingress

就绪探针，存活探针

NetworkPolicy

5.持久化数据

Volume 的类型

Kubernetes的Volume有非常多的类型，在实际使用中使用最多的类型如下。

● emptyDir：一种简单的空目录，主要用于临时存储。

● hostPath：将主机某个目录挂载到容器中。

●

ConfigMap、Secret：特殊类型，将Kubernetes特定的对象类型挂载到Pod，在6.1 ConfigMap和6.2 Secret章节介绍过如何将ConfigMap和Secret挂载到

Volume中。

● persistentVolumeClaim：Kubernetes的持久化存储类型，详细介绍请参考8.2

PV、PVC和StorageClass中会详细介绍。

、、

kb

kb