Kubernetes基础篇-02-Kubernetes的基础概念(Pod概念,网络通讯方式)_网络 pod概念

1. Pod概念

Pod官方没有明显区分，但是我们可以将Pod大致分为两类；

1.1 自主式Pod

不是被控制器管理的Pod,一旦死亡不会被拉起重启，也不会自动创建副本数满足期望值，这些都是自主式Pod的缺陷；

1. 只要由Pod,就会先启动pause容器
2. 一个Pod里面包含多个容器
3. Pod内容器会共用pause的网络栈和存储卷
4. 在同一个Pod里面，容器的端口不能重复

1.2 控制器管理的Pod

1.2.1 ReplicationController 简称：RC

ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationControlle

1.2.2 ReplicaSet 简称： RS

ReplicaSet和RC没啥本质区别，只是名字不一样，但是RS支持集合式的selector；
所谓集合式的selector就是说我们在创建Pod的时候都会给Pod打标签，根据标签来管理相应的Pod;

1.2.3 Deployment

虽然RS可以独立使用，但是一般建议使用Deployment来自动管理Rs,好处就是不需要担心和其他机制的兼容问题(比如RS不支持rolling-update滚动更新， 但Deloyment支持)；
Deployment不负责Pod创建，它是通过RS来创建的；

假设开始是RS管理V1版

现在要滚动更新到V2版本，deployment会创建一个新的RS,假设是RS-1，然后V1删除一个，V2创建一个，依次类推，达到滚动更新的目的

如果此时发现更新的某个V2出现问题，还可以回滚，新建一个老的V1，删除V2，原因是Deployment在滚动更新的时候不会直接删除RS，而是将它停用，当需要回滚的时候再将它启用，达到回滚目的；

1.2.4 HPA(Horizontal Pod AutoScale)

Horizontal Pod AutoScale仅适用于Deployemnt和Rs,在V1版本中仅支持根据Pod的CPU利用率扩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩缩容；

假设现在RS-1创建了2个Pod, HPA会监控它

当RS-1的CPU利用率大于等于80，且当前Pod数量小于10，则会创建新的Pod,直到
CPU利用率低于80，当CPU低于80时，会回收Pod,但是不能小于2个，达到一个水平拓展的目的

1.2.5 StatefulSet

StatefulSet是为了解决有状态服务的问题(对应Deployments和 ReplicaSets是为无状态服务而设计)，其应用场景包括:

• 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据，基于PVC 来实现
• 稳定的网络标志，即Pod重新调度后其PodName 和 HostName不变，基于 Headless Service(即没有Cluster IP的Service)来实现
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N1在下一个Pod运行之前所有之前的Pod必须都是Running和 Ready 状态)基于init containers来实现
• 有序收缩，有序删除(即从N-1到0)

无状态服务指的是没有相应的存储需要保留，打个比方，你是工厂流水线员工，老板把你调走一个月再调回来，你可以照样工作，不影响；但是如果是有状态服务，比如你是项目经理，当你管理着一个项目，老板把你调走再调回来，你就不能像之前一样管理，因为很多东西变了，典型的有状态服务比如Mysql;

1.2.6 DaemonSet

DaemonSet确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有 Pod

使用DaemonSet的一些典型用法:

• 运行集群存储daemon，例如在每个Node 上运行 glusterd ceph。
• 在每个Node上运行日志收集 daemon，例如fluentd、logstash。
• 在每个Node上运行监控 daemon，例如 Prometheus Node Exporter

1.2.7 Job，CornJob

Job负责批处理任务，即仅执行一次的任务，他能保证批处理任务的一个或多个Pod成功结束；
用途： 比如备份数据库
当然我们也可以直接在linux上写脚本备份，没问题，但是如果脚本执行失败了，是没办法重新执行的，但是Job可以，当执行失败之后，它会继续重试直到成功，当然你也可以设置成功次数，比如成功2次之后再退出；

Corn Job是在管理基于时间的Job,即:

1. 在给定时间点只运行一次；
2. 周期性的在给定时间点运行

2. 服务发现

客户端访问Pod是通过service,这里面使用的是Ribbon轮询算法

3. 网络通讯方式

3.1 网络通讯模式-1

Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在 GCE(GoogleComputeEngine)里面是现成的网络模型，Kubernetes假定这个网络已经存在而在私有云里搭建Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问先打通，然后运行Kubernetes；

3.2 网络通讯模式-2

• 同一个Pod内的多个容器之间 io
• 各Pod之间的通讯:Overlay Network
• Pod与Service之间的通讯:各节点的Iptables规则

3.3 网络解决方案 Kubernetes + Flannel -1

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(OverlayNetwork)，通过这个覆盖网络，将数据包原封不动地传递到目标容器内;

3.4 网络解决方案 Kubernetes + Flannel -2

举例：

3.5 网络解决方案 Kubernetes + Flannel -3

ETCD之Flannel提供说明:

• 存储管理Flannel 可分配的IP 地址段资源
• 监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表

3.6 不同情况下网络通信方式

同一个Pod内部通讯:同一个Pod共享同一个网络命名空间，共享同一个Linux 协议栈

Pod1至Pod2

1. Pod1与Pod2不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问
2. Pod1与Pod2在同一台机器，由 Docker 网桥直接转发请求至Pod2，不需要经过Flannel 演示
   

Pod至Service的网络:目前基于性能考虑，全部为iptables维护和转发

Pod到外网: Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade，把源IP 更改为宿主网卡的IP，然后向外网服务器发送请求

外网访问 Pod:Service

3.7 组件通讯示意图

4. 其他

命令式编程：它侧重于如何实现程序，就像我们刚接触编程的时候那样，我们需要把程序的实现过程按照逻辑结果一步步写下来;

举个列子：你让小明去买水，告诉它左转下楼右转走两步买水然后走两步左转上楼交给你

声明式编程:它侧重于定义想要什么，然后告诉计算机/引擎，让他帮你去实现

举个列子：你让小明去买水 ，怎么买小明自己决定；