3.1 K8s API Server 原理分析
K8s API server核心提供对各种资源对象的增、删、改、查以及Watch等HTTPRest接口，是集群内各个模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。
（1）是集群管理的API入口。
（2）资源配额控制的入口。
（3）提供了完备的集群安全机制。
3.1.1 K8s API server 通过一个名为Kube-apiserver的进程提供服务，该进程运行在Master节点上。在默认情况下，Kube-apiserver进程在本地的8080端口提供rest服务。可以同时开启HTTPS安全端口来启动安全机制，加强REST API访问安全性。
我们可以通过命令行工具Kubectl来与K8s API server交互，它们之间的接口是REST调用。为了测试和学习K8s API server所提供的接口，我们也可以使用curl命令行工具进行快速验证。
也可以用变成的方式调用API server的接口
3.2 Controller Manager 原理分析
集群内的管理控制中心
3.2.1 Replication Controller
副本控制器，确保Pod副本数量保持预设值。
3.2.2 Node Controller
kubelet进程在启动时通过API server注册自身的节点信息，并定时向API server汇报状态信息，
API server将这些信息更新到etcd中，etcd中存储节点信息：健康状况，节点资源，节点名称，节点地址，OS version， Docker版本，kubelet版本。
Node controller 通过API server实时获取Node的相关信息。
3.2.3 ResourceQuota Controller
资源配额管理保证指定的资源对象在任何时候都不会超量占用系统物理资源。
3.2.4 Namespace Controller
3.2.5 Service Controller 与 Endpotint controller
Service、Endpoints与pod的关系： Endpoints表示一个service对应的所有POD副本的访问地址。
Endpoints controller就是负责生成和维护所有Endpoints对象的控制器。
Endpoints对象在哪里被使用？ 答案： 每个Node上的kube-proxy进程，kube-proxy进程获取每个
service的Endpoints，实现了Service的负载均衡。
3.3 Scheduler原理分析
负责Pod调度的重要功能模块。接收Controller Manager创建新Pod，为其安排一个Node，然后完成后，目标NOde上的kubelet服务进程接管后续工作。
3.4 kubelet运行机制分析
k8s集群中，在每个node节点上都会启动一个kubelet服务进程，该进程用于处理Master节点上下发到本节点的任务，管理Pod以及Pod中的容器。每个kubelet进程会在API server上注册节点自身信息，定期向Master节点汇报节点资源使用情况。
3.4.1 节点管理
3.4.2 Pod管理
3.4.3 容器健康检查
3.4.4 cAdvisor资源监控
3.5 kube-proxy 运行机制分析
service是对一组Pod的抽象，它会根据访问策略来访问这些POD。
service只是一个概念，真正将service的作用落实的是Kube-proxy服务进程。
每个Node上都运行一个kube-proxy服务进程，可以看做是Service的透明代理兼负载均衡器。
其核心功能是将某个service的访问请求转发的到后端的多个pod实例上。
service的Cluster IP与NodePort等概念是kube-proxy服务通过Iptable的NAT转换实现的，kube-proxy在运行
过程中动态创建与Service相关的iptables规则，这些规则实现了Cluster Ip以及NodePort请求流量重定向
到Kube-proxy进程上对应服务的代理端口的功能。
由于kube-proxy的作用，在service的调用过程中客户端无须关心后端有几个Pod ，中间过程的通信、负载均衡算法以及
故障恢复都是透明的。
3.6 集群安全机制
略
3.7 网络原理