kubernetes核心组件的运行机制

kubernetes api server原理解析

kubernetes api server的核心功能是提供kubernetes各类资源对象（pod,rc,service）的增删改查及watch等http rest接口
集群内各个功能模块之间数据交互和通信的中心枢纽，整个系统的数据总线和数据中心
集群管理api入口，资源配额控制的入口，提供了完备的集群安全机制
kubernetes api server通过一个名为kube-apiserver的进程提供服务，该进程运行在master上
kube-apiserver进程在本机的8080端口（对应参数–insecure-port）提供rest服务
可以同时启动https安全端口(–secure-port=6443)来启动安全机制，增加rest api访问的安全性
curl localhost:8080/api：返回kubernetes api地版本信息
curl localhost:8080/api/v1：kubernetes api server目前支持地资源种类
culr localhost:8080/api/v1/pods：集群地pod列表
culr localhost:8080/api/v1/replicationcontrollers：集群地service列表
culr localhost:8080/api/v1/pods：集群地rc列表
只想对外暴露部分服务，可以在Master或其他节点上运行kubectl proxy进程启动一个内部代理来实现
kubectl proxy --reject-paths="^api/v1/replicationtrollers --port=8001--v=2"
curl localhost:8001/api/v1/replicationcontrollers：验证
kubectl proxy提供简单有效的安全机制
kubernetes api server本身也是一个service，他的名称就是kubernetes，并且他的cluster ip地址是clusterip地址池的第一个滴着，服务的端口是443
kubectl get service
apr server是kubernetes集群数据地唯一访问入口
安全性与高性能是api server设计和实现地两大核心指标
apr server采用https安全传输通道与ca签名数字证书强制双向认证方式，api server的安全性得以保障
kubernetes采用了rbac访问控制策略来更细粒度地控制用户
api server的性能是决定kubernetes集群性能的关键因素
apiserver源码中使用协程+队列这种轻量级高性能并发代码
普通list接口结合异步watch接口
采用了高性能的etcd数据库而非传统的关系数据库
kubernetes proxy api：代理rest请求，kubernetes api server把收到的rest请求转发到某个node上的Kubelet守护进程的rest端口，由该kubectl进程负责响应

api架构解析

api曾：主要以rest方式提供各种api接口，除了有kubernetes资源对象地crud和watch等主要api，还有健康检查，ui，日志，性能指标等运维监控相关地api
使用metrices api接口，完善自身监控能力
访问控制层：当客户端访问api接口时，访问控制层负责对用户身份进行鉴权
注册表层：kubernetes把所有资源对象都保存在注册表中，针对注册表中地各种资源对象都定义了资源对象地类型，如何创建资源对象，如何转换资源地不同版本，以及如何将资源编码和解析为json或protobuf格式进行存储
etcd数据库：持久化存储kubernetes资源对象地kv数据库。etcd地watch接口对api server很重要
api server根据watch接口设计了list-watch高性能资源对象同步机制
借助etcd地watch api接口，api server可以监听（watch）在etcd上发生地数据操作事件
比如pod创建事件，更新事件，删除事件等
在这些事件发生后，etcd及时通知api server
为了让kubernetes其他组件在不访问底层数据库地情况下，能及时获取资源对象地变化。
api server模仿etcd地watch api接口提供了自己地watch接口
kubernetes list-watch用于实现数据同步地代码逻辑
客户端首先调用api server地list接口获取相关资源对象地全量数据并将其缓存到内存中
启动对应地资源对象地watch协程，在接受到watch事件后，根据事件地类型（增删改）对内存中地全量资源对象列表做出相应地同步修改
通过kubectl apply命令实现资源对象地更新操作，只需要将修改地属性写入yaml文件中提交
kubernetes1.14之后引入server-side apply
1.18追踪并管理所有新kubernetes对象地字段变更，确保用户及时了解哪些资源何时进行过更改
定义不同地版本号来进行区分
apiserver针对每种资源对象引入了一个相对不变地internal版本
每个版本只要支持转换为internal版本，就能够与其他版本进行间接转换
api server对资源对象地crud操作都会保存到etcd数据库中
crd直接编写yaml文件即可实现
u使用list-watch编程框架
kubernetes proxy api：代理rest请求
kubernetes api server把收到地rest请求转发到某个Node上地kubelet守护进程地rest端口，由kubelet进程负责响应
api/v1/nodes/{name}/proxy/<pods><stats><spec>
这里获取地pod信息来自于node而非etcd数据库
kubelet进程在启动时包含–enable-debugging-handlers=true,kubernetes proxy api会增加接口
run/exec/attach/portforward/logs/metrics/runningpods/debug/prof
p336

controller manager

scheduler

kubelet

kubernetes集群中，每个node上都会启动一个kubelet服务进程
该进程用于处理master下发到本节点的任务，管理pod及Pod中的容器
每个kubelet进程都会在api server上注册节点自身的信息，定期向master汇报节点资源的使用情况
通过cadvisor监控容器和节点资源
节点通过设置kubelet的启动参数–register-node，来决定是否向api server注册自己
如果该参数的值为true，那么kubelet将试着通过api server注册自己
在自注册时，kubelet启动时还包含下列参数
–api-servers：api server的位置
–kubeconfig：kubeconfig文件，用于访问api server的安全配置文件
–cloud-provider：云服务商lass地址，仅用于公有云环境中

kube-proxy

第一代proxy userspace

为了支持集群地水平扩展和高可用性，kubernetes抽象出了service地概念
service是对一组pod地抽象，会根据访问策略（如负载均衡策略）来访问这组pod
kubernetes在创建service的时候会为服务分配一个虚拟Ip地址，客户端通过访问这个虚拟Ip地址来访问service
service则将请求转发到后端pod上
service其实是一个反向代理，与普通的反向代理不同的是：他的ip是虚拟的
它的部署和启停都是由kubernetes统一自动管理的
service在很多情况下只是一个概念，真正将service的作用落实的是它背后的kube-proxy服务进程
在kubernetes集群上的每个node都会运行一个kube-proxy服务进程，可以把这个进程看成servoce的透明代理兼负载均衡器
核心功能是将某个service的访问请求转发到后端的多个pod上
起初：kube-proxy是一个真实的TCP/UDP代理，类似于HA proxy，负责转发从Service到pod的访问流量，被称为userspace模式
当某个客户端以pod以clusterip地址访问某个pod以clusterip地址访问某个service时，这个流量就被pod所在Node的iptables转发给kube-proxy进程，然后由kube-proxy建立起到后端pod的TCP/UDP连接
再将请求转发到某个后端pod上，并在这个过程中实现负载均衡功能

第二代proxy iptables

从1.2开始，kubernetes将iptables作为kube-proxy的默认模式
iptables模式下的第二代kube-proxy进程不在起到数据层面的proxy的作用
client向service的请求流量通过iptables的nat机制直接发送到目标pod，不经过kube-proxy进程的转发
kube-proxy进程只承担了控制层面的功能
通过api server的watch接口实时跟踪service与endpoint的变更信息，并更新node节点上相应的iptables规则
根据Kubernetes的网络模型，一个Node上的pod与其他node上的pod应该能够直接建立双向的TCP/IP通信通道，所以直接修改iptables规则，也可也实现kube-proxy的功能，只不过后者更加高端，因为是全自动模式的
与第一代userspace模式相比，iptables模式完全工作在内核态，不用在经过用户态的kube-proxy中转
kube-proxy针对service和pod创建的一些主要的iptables规则如下
kube-cluster-ip：在masquerade-all=true或clustercidr指定的情况下对service的clusterip地址进行伪装，以解决数据包欺骗问题
kube-external-ip：将数据包伪装成service的外部ip地址
kube-load-balancer,kube-load-balancer-local：伪装成load balancer类型的service流量
kube-node-port-tcp,kube-node-port-local-tcp,kube-node-port-udp,kube-node-port-local-udp：伪装成nodeport类型的service流量
缺陷：在集群中的service和pod大量增加以后，每个Node节点上的Iptables中的规则会急速膨胀，导致网络性能显著下降，在某些极端情况下甚至会出现规则丢失情况，并且这种故障难以重现和排查

第三代proxy

1.8版本引入了ipvs模式
iptables与ipvs虽然都是基于netfilter实现的，但是定位不同
iptables是为防火墙设计的
ipvs专门用于高性能负载均衡，并使用更高效的数据结构（哈希表），允许几乎无限的规模扩张
ipvs比iptables的优势：
为大型集群提供了更好的可扩展性和性能
支持比iptables更复杂的赋值均衡算法（最小负载，最少连接，加权等）
支持服务器健康检查和连接重试等功能
可以动态修改ipset的集合，即使iptables的规则正在使用这个集合
ipvs无法提供包过滤，airpin-masquerade tricks(地址伪装),snat等功能
某些场景如（nodeport）还要与iptables搭配使用
在ipvs模式下，kube-proxy又做了重要的升级，即使用iptables的扩展Ipset,而不是直接调用iptables来生成规则链