Kubernetes 学习总结(1) Synopsis

同类产品
docker compose、docker swarm、docker machine、mesos、marathon

Kubernetes 项目地址
https://github.com/kubernetes/kubernetes/releases

Schema


核心组件:
1) API server ：接收、分析用户请求，并处理用户请求
2) Scheduler ：调度资源（通过初选、优选、选定三个阶段调度创建container的请求）
3) Controller manager 控制器管理器：确保各控制器健康运行
Controller 控制器：持续监控容器资源的运行状态，确保已创建的container资源健康运行（控制器包含多种)。控制器不停的在本地loop，如果发现问题，立即向API server请求，API server 调用Scheduler 再次优选出符合条件的node并运行相关container。
4）etcd 是一个高可用的键值存储系统，Kubernetes使用它来存储各个资源的状态，从而实现了Restful的API。
5）Kubelet是 Master在每个Node节点上面的agent，是Node节点上面最重要的模块，它负责维护和管理该Node上面的所有container，但是如果容器不是通过Kubernetes创建的，它并不会管理。本质上，它负责使Pod的运行状态与期望的状态一致。kebelet 接收各种Task ,然后由本机上的Container Engine负责启动容器 ，常用的Container Engine 有 docker 、rocker等。但如果node down掉所有容器就会关闭。
6）kube-proxy 实现了Kubernetes中的服务发现和反向代理功能。反向代理方面：kube-proxy支持TCP和UDP连接转发，默认基于Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面，kube-proxy使用etcd的watch机制，监控集群中service和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射关系，从而保证了后端pod的IP变化不会对访问者造成影响。另外kube-proxy还支持session affinity。
7）runtime 指的是容器运行环境，目前Kubernetes支持docker和rkt两种容器

Pod
K8s 上运行的最小单位是 Pod , k8s 直接调度的是Pod , pod是容器的外壳，它为容器做了一层抽象的封装。可以将多个容器联合起来，定义统一的网络名称空间，就构成了Pod。 同一个Pod中的容器共享同一个net ipc名称空间，也可以共享同一个存储卷。
一般一个pod内只放一个container ，如果放了多个，一般都会有一个主容器，其它容器是为了辅助该主容器运行。（一个容器内运行一个程序，所以有时就需要在另一个容器内运行一个辅助程序，来辅助该主程序的运行）

Pod又分为:
自主式pod(自我管理)
由Pod controller管理的pod

Pod Controller又有以下多种:
Replication Controller (保证pod数量与期望数量相符、滚动更新)
ReplicaSet (新版本中替换Replication Controller，但它一般不直接使用，一般使用它的直接声明式更新的控制器deployment)
Deployment (只能管理无状态pod、支持二级控制器HPA)
StatefulSet (管理有状态pod)
DaemonSet(每个node上运行一个副本，而不是随意运行)
Job 、Cronjob (管理临时短暂task运行程序的pod)

HPA(HorizontalPodAutoScaling) 自动水平扩展

Label
为了方便pod的识别，方便分类管理，可以在pod上进行Tag Label(添加meta info)。由selector 对各资源进行 label筛选。
Kubernetes 提供一个restfull 格式的API。用户的请求-->发给master-->master上的scheduler 分析各node上资源的运行状态--> 选定最合适的node ,将请求发给该node的 kubelet --> kubelet 控制本地的Container Engine 进行创建container 。

Service
就是 client 与pod之间的中间层，service_name 、service address 不会变。service是一个pod服务池的代理抽象，目前的实现方法是通过一个固定的虚拟IP及端口来定义，并且通过分布在所有节点上的proxy来实现内部服务对pod的访问。service是将虚拟IP通过iptables重定向到最终的pod上。Service 实质上就是一些iptables的DNAT规则 。
Client request先到service，然后再由service将request代理到后端相关的pod上。Service 关联后端pod时，使用Labe属性进行识别。
Service name到IP地址之间的解析由DNS负责。DNS是运行在一个专门的pod上。该运行了DNS的Pod属于kubernetes的附件(AddOn)，它支持动态更新。
后期版本的iptables rule 会更新为 lvs rule，因为iptables 的后端调度功能较弱。
例：Client —> SLB/ELB/ELA/NLB—> Nodes —> service name —> nginx —> service name —> tomcat —> service name —> mysql
Service 常用类型有两种：供外部访问，供内部访问

网络
三种网络类型
Pods network: 默认 10.244.0.0/16
Service network:默认 10.96.0.0/12
Node network: 默认172.16.0.0/16

访问流程：client Request —> Node network —> service network —> pod network

Pod内多containers通讯可以利用lo。
各Pods间containers通讯：1) 物理桥桥接; 2) overylay network
Pods与service通讯：先通过core_DNS解析，再由iptables转发即可

kubernetes不提供网络功能，由plugin提供。kubernetes由CNI来负责第三方plugin的网络管理，提供Pod network/service network的管理。
常见的有：flannel(二层叠加网络)、calico(三层BGP，支持各种策略)、canel(结合前两种的功能)
说明：网络策略即定义不同pod之间的container是否可以互联

Kebe-proxy
Kebe-proxy与API server联系，并负责service的管理，以及负责kubernetes cluster外部的访问。service发生变化时由kube-proxy产生事件通知API server，从而同步数据。各Master上的数据存储在共享存储etcd中，防止数据丢失。