本文最后更新于194 天前，其中的信息可能已经过时，如有错误请发送邮件到pby_while@163.com
kubernetes组件架构：
这边插入一张官方的组件架构图。
Master节点
API Server ：
- 它主要用来接收其他组件发来的请求，并做出相应的处理。
Scheduler：
- 它主要负责挑选出一个最佳node节点，来运行pod。
挑选合适的node节点，通常分为两个阶段：
- 第一阶段：通过初步筛选，根据运行pod的最大要求，如：4G内存，6颗CPU等需求，进行初步筛选。
倘若在这个阶段选出多台，如：20台选出3台。则进入第二阶段。
- 第二阶段：综合各种因素（节点亲和性，污点容忍，资源利用率等），最后将选出一台最佳运行阶段告诉API Server，由master阶段负责调度pod在该node节点上运行。
Controller：
- 它负责监控node节点上运行的pod是否正常工作，如果发现自己监控的某个pod故障了，它会向API Server发出通告，并要求master在其他节点上再重新启动一个相同的pod，然后将故障pod 杀掉。
Controller-Manager：
- 它负责监控所有的Controller是否正常工作。在Kubernetes集群中，有很多功能各异的Controller监控pod的健康状态。Controller-Manager就是用于监控它们的工作状态，一旦Controller故障，它将重启一个新的Controller来代替它的工作。
Etcd：
- Etcd是一个分布式的键值存储系统。它在Kubernetes集群里面用来存储集群的配置数据，节点的状态信息等数据。
Node节点
主要组件有：kubelet、kube-proxy。
kubelet：
- 它是每个节点上运行的“代理节点”，对 Node节点进行实际执行操作的 一个守护进程。
- kubelet会持续监听API Servier，一旦发现有新的pod被调度到自己的节点，就负责拉镜像、创建\启动容器；当pod被删除或者被驱逐时，再负责停止并清理容器和卷。
kube-proxy：
- 它会持续监听着API Server。若Service后端的pod标签或者数量发生变更，API Server会立即把事件推送给所有监听者（包括各个节点的kube-proxy）；而kube-proxy收到通知后，它们会自动将这个消息反映在本地的iptables或者ipvs规则中，更新其（iptables/ipvs）转发规则，从而保证Service始终指向正确的Pod。始终指向正确的Pod。
- 它是用来管理Service的，用户手动创建Service后，后续的管理都是由kube-proxy进行。
网页做挺好|´・ω・)ノ
不是我写的说是
那就抽抽胖白，胖白记得在这里添加一个抽抽的gif动态图，方便抽你∠( ᐛ 」∠)＿
再抽一下抖爱慕yx
逮捕萝莉控