二 核心组件/附件 #

2.1 Controller #

这些控制器分别用于确保不同类型的 POD 资源运行于符合用户所期望的状态。

• RelicationController

控制同一类 POD 对象的副本数量，实现程序的滚动更新，或者回滚的操作。

在滚动更新时候，允许临时超出规定的副本数量，

• RelicaSet

副本集控制器，它不直接使用，它有一个声明式中心控制器 Deployment

• Deployment

它只能管理无状态的应用，这个控制器，支持二级控制器，例如：HPA（Horizontal Pod Autoscaler，水平 POD 自动伸缩控制器），当负载高的时候，自动启动更多的 POD。

• StatefulSet

管理有状态的应用

• DaemonSet

如果需要在每一个 node 上运行一个副本，而不是随意运行

• Job

运行一次性作业，时间不固定的操作，例如：备份、清理，临时启动一个 POD 来进行备份的任务，运行完成就结束了。

如果运行时候 JOB 挂了，那么需要重新启动起来，如果运行完成了则不需要再启动了。

• Cronjob

运行周期性作业

2.2 Service #

为客户端提供一个稳定的访问入口，Service 靠标签选择器来关联 POD 的，只要 POD 上有相关的标签，那么就会被 Service 选中，作为 Service 的后端，Service 关联 POD 后会动态探测这个 POD 的 IP 地址和端口，并作为自己调度的后端。

总的来说客户端请求 Service 由 Service 代理至后端的 POD，所以客户端看到的始终是 Service 的地址。

K8S 上的 Service 不是一个应用程序，也不是一个组件，它是一个 iptables dnat 规则，或者 ipvs 规则，Service 只是规则，所以是 ping 不通的，由于是dnat规则或是ipvs规则，可以使用利用端口进行测试

Service 作为 k8s 的对象来说，是有名称的，可以通过 Service 的名称解析为 Service 的 IP 地址

一般格式: svcname.namespace.svc.cluster.local, 如果在同一个 namespace 中可以直接使用 svcname , 如果不在同一个 namespace 中, 需要写完整的FQDN域名。

• AddOns

解析域名是由 DNS 来解析的，为 k8s 中提供域名解析这种基础服务，称之为基础架构 POD 也称为 k8s 附件，所以域名解析的 POD 就是 k8s 中的一种 AddOns。

而 k8s 中的 dns 附件，是动态的，例如：service 名称发生更改，就会自动触发 dns 中的解析记录的改变，如果手动修改 service 的地址，也会自动触发 DNS 解析记录的改变，所以客户端访问服务时，可以直接访问服务的名称。

2.3 网络模型 #

k8s 有三种网络：POD网络、集群网络、节点网络

POD网络：所有 POD 处于同一个网络中，叠加网络
集群网络：Service 是一个另外一个网络
节点网络：node 节点也是另外一个网络，宿主机的内网网络

POD网络：所有 POD 处于同一个网络中，叠加网络
集群网络：Service 是一个另外一个网络
节点网络：node 节点也是另外一个网络，宿主机的内网网络

所以，接入外部访问时候，请求首先到达 node 网络，然后 node 网络代理至 service 网络，service 根据 iptables/ipvs 规则来转发到 pod 网络中的 pod 上。

NODE 网络 -> SVC 网络 -> POD 网络

NODE 网络 -> SVC 网络 -> POD 网络

k8s 有三种通信：

• 同一个 POD 内的多个容器间的通信，可以通过 lo 通信直接通讯。

• POD 与 POD 通信，如果使用 flannel 所有 POD 都处于一个网络，可以跨 node 与另外的 POD 直接通信，因为使用了叠加网络。

• POD 与 Service 通信。

2.4 kube-proxy #

在 node 节点上运行的一个守护进程，它负责随时与 apiserver 进行通信，因为每个 pod 发生变化后需要保存在 apiserver 中，而 apiserver 发生改变后会生成一个通知事件，这个事件可以被任何关联的组件接收到，例如被 kube-proxy 一旦发现某个 service 后端的 pod 地址发生改变，那么就由 kube-proxy 负责在本地将地址写入 iptables 或者 ipvs 规则中。

所以 service 的管理是靠 kube-proxy 来实现的，当你创建一个 service ，那么就靠 kube-proxy 在每个节点上创建为 iptables 或者 ipvs 规则，每个 service 的变动也需要 kube-proxy 反应到规则上。

apiserver 需要保存各个 node 信息，它需要保存在 etcd 中。

2.5 etcd #

是一个键值存储的系统，与 redis 很像，但是 etcd 还有一些协调功能是 redis 所不具备的，它还有节点选举等功能，从这个角度来讲 etcd 更像 zookeeper。

由于整个集群的所有信息都保存在 etcd，所以 etcd 如果宕机，那么整个集群就挂了，因而 etcd 需要做高可用。

2.6 flanel #

托管为 k8s 的附件运行, 在 k8s 中有很多其他的开源网络插件，例如高性能的 calico 三层网络插件,性能很好，支持访问控制

node 网络：物理各节点之间进行通信

POD 网络：所有 node上的 POD 彼此之间通过叠加，或者直接路由方式通信

service 网络：由 kube-proxy 负责管控和生成

知识小结 #

• Master

kube-scheduler             # 调度 pod
kuber-controller-manager   # 管理 pod
kube-apiserver             # 接收请求
etcd                       # 集群状态存储，集群所有的组件的状态都保存在这里

kube-scheduler             # 调度 pod
kuber-controller-manager   # 管理 pod
kube-apiserver             # 接收请求
etcd                       # 集群状态存储，集群所有的组件的状态都保存在这里

• node

kubelet                    # 节点/pod管理
kube-proxy                 # watch apiserver管理service
docker                     # 容器运行时

kubelet                    # 节点/pod管理
kube-proxy                 # watch apiserver管理service
docker                     # 容器运行时