zifuy 的个人笔记

架构和原理

Kubernetes主要由以下几个核心组件组成：

• etcd保存了整个集群的状态；
• apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kubelet负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的插件，其中有的已经成为CNCF中的托管项目：

• CoreDNS负责为整个集群提供DNS服务
• Ingress Controller为服务提供外网入口
• Prometheus提供资源监控
• Dashboard提供GUI
• Federation提供跨可用区的集群

Kubernetes实现需求的具体流程

这里已创建一个ReplicaSet对象为例

1、用户执行kubectl create 命令提交给Api-Server;Api-Server将信息存储到ETCD；Api-Server开始反馈ETCD中的变化

2、controller-manager watch到有新的生命周期事件改变（创建POD），并将改变存储到 Api-Server--->ETCD

3、scheduler watch到有新的对象创建但未绑定节点，计算后更新调度结果绑定node,更新pod信息到 Api-Server--->ETCD

4、kubectl watch到本节点有pod调度过来后调用Docker执行生命周期动作，并将改变存储到 Api-Server。

kube-proxy原理

kube-proxy是Kubernetes的核心组件，部署在每个Node节点上，它是实现Kubernetes Service的通信与负载均衡机制的重要组件;kube-proxy的主要作用就是负责service的实现。

kube-proxy负责为Pod创建代理服务service,实现service到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。

service另外一个重要作用是，一个服务后端的Pods可能会随着生存灭亡而发生IP的改变，service的出现，给服务提供了一个固定的IP，而无视后端Endpoint的变化。

Service原理

kube-proxy当前实现了三种代理模式：

1、userspace mode是v1.0及之前版本的默认模式

2、从v1.1版本中开始增加了iptables mode，在v1.2版本中正式替代userspace模式成为默认模式。

Iptables模式

该模式相比 userspace 模式，克服了请求在用户态-内核态反复传递的问题，性能上有所提升，但使用 iptables NAT 来完成转发，存在不可忽视的性能损耗，而且在大规模场景下，iptables 规则的条目会十分巨大，性能上还要再打折扣。

iptables的方式则是利用了linux的iptables的nat转发进行实现

3、在kubernetes 1.8以上的版本中，对于kube-proxy组件增加了除iptables模式和用户模式之外还支持ipvs模式

Ipvs模式

kube-proxy ipvs 是基于 NAT 实现的，通过ipvs的NAT模式，对访问k8s service的请求进行虚IP到POD IP的转发

不创建大量的 iptables 规则, 而是通过netlink 创建ipvs规则，并使用k8s Service与Endpoints信息，对所在节点的ipvs规则进行定期同步;

netlink 与 iptables 底层都是基于 netfilter 钩子，但是 netlink 由于采用了 hash table 而且直接工作在内核态，在性能上比 iptables 更优

请求到达pod上的过程

内部：

kube-proxy为集群提供service功能，相同功能的pods对外抽象为service，service可以实现反向代理和服务发现。

外部：

从 kubernetes 1.2 版本开始，kubernetes提供了 Ingress 对象来实现对外暴露服务；到目前为止 kubernetes 总共有三种暴露服务的方式:

• LoadBlancer Service
• NodePort Service
• Ingress

LoadBlancer Service 需要结合云平台来实现

NodePort  是通过在集群的每个 node 上暴露一个端口，然后将这个端口映射到某个具体的 service 来实现的，存在弊端

Ingress 这个是 1.2 后才出现的，通过 Ingress和service建立联系通过域名访问。

rc/rs功能的实现、API接受到一个创建rc/rs的请求，到最终在节点创建pod的全过程

ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector

具体实现需要分析源码，参考这篇文章

deployment/rs区别

deployment是rs的超集，提供更多的部署功能，如：回滚、暂停和重启、 版本记录、事件和状态查看、滚动升级和替换升级。

如果能使用deployment，则不应再使用rc和rs。

功能上的区别如下：

replication controller

• 确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod，Replication Controller会创建新的，反之则会删除掉多余的以保证Pod数量不变。

• 确保pod健康：当pod不健康，运行出错或者无法提供服务时，Replication Controller也会杀死不健康的pod，重新创建新的。

• 弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况，做到自动伸缩。

• 滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

Deployment

主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：

• Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。

• 事件和状态查看：可以查看Deployment的升级详细进度和状态。

• 回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。

• 版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。

• 暂停和启动：对于每一次升级，都能够随时暂停和启动。

• 多种升级方案：Recreate：删除所有已存在的pod,重新创建新的; RollingUpdate：滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。

当一个pod失效时 k8s是如何发现并重启另一个