1 Pod概念

1.1 Pod分类

• 自主式Pod
• 控制器管理的Pod

1.2 Pod的基本概念

一个Pod可以拉取多个镜像，跑多个容器，但是注意同一个Pod的端口不要相同，不然可能会出现无限重启的情况。

一个Pod中的多个容器，他们共用Pause，既共用网络，也共用存储卷

1.3 控制器管理的Pod

1.3.1 ReplicationController，RC（复制控制器）

适用于长期伺服型的业务类型

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

1.3.2 ReplicaSet，RS（副本集）

适用于长期伺服型的业务类型

RS是新一代的RC，提供同样的高可用能力，只是能支持更多种类的匹配模式，支持集合式的selector。副本集对象一般不单独使用，而是作为Deployment的理想状态参数使用。

1.3.3 Deployment（部署）

适用于长期伺服型的业务类型

Deployment表示对K8S集群的一次更新操作。可以创建、更新、滚动升级一个新的服务。滚动升级，实际上就是创建新的RS，将RS副本数增加到设定的值，然后将旧的RS减小到0，滚动更新同时包括回滚。

虽然RS可以独立使用，但一般还是使用Deployment来管理，这样就无需担心跟其他机制不兼容的问题（比如 RS不支持rolling-update，但Deployment支持）

1.3.4 Horizontal Pod Autoscaling （平滑扩展）

支持Replication controller、Deployment和Replica Set，在v1版本中仅支持根据Pod的CPU利用率扩缩容，在v1alpha版本中，支持根据内存和用户自定义的metrics扩缩容

1.3.5 StatefulSet（有状态服务）

StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计）

• 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC实现。

• 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）实现

• 有序部署，有序扩展，即Pod是有序的，在部署或扩展时要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running或者Ready状态），基于init containers 来实现

  举个栗子，部署的应用，应该先启mysql，在启apach，在启nginx。如果顺序不对，例如mysql还没启动，就启动了apach，就会报错，报找不到数据；没有启动nginx，就启动了apach，会报找不到代理的路径。

• 有序收缩，有序删除（即从N-1到0）

• 有序的自动滚动更新

其与PetSet有什么关联嘛？

1.3.6 DaemonSet（后台支撑服务）

DaemonSet确保全部（或者一些，可以给某个Node打污点）Node上运行一个（有且只有一个）Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DeamonSet将会删除它创建的所有它所创建的Pod。

使用DaemonSet的一些典型案例：

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

思考，如果每个Node都要运行好几个类似的程序怎么办？

解法1：将其整合成一个Pod的不同服务

解法2：多个DaemonSet

1.3.6 Job

负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

1.3.7 Cron Job

管理基于时间的Job， 即：

• 在给定时间点只运行一次
• 周期性地在给定时间点运行

1.3.8 Service（服务发现）

Service用来访问具有同一组标签的Pod，访问Service的的Ip+端口即可轮询访问到其所绑定的Pod

每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。

后续要访问Service可以通过Node-port或者Service LoadBalancer或者Ingress，Ingress Controller

2 网络通讯方式

2.1 网络插件解决网络连通问题

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

所以构建集群需要先解决扁平化的网络空间。

如何解决？Flannel、Calico、Weave……

2.2 如何访问

• 同一个Pod内的多个容器：IO，直接localhost+端口即可访问

• 各个Pod之间的通讯：Overlay Network

  • Pod在相同网段（同一台机器）

    由Docker0网桥直接进行转发

  • Pod在不用网段（不同机器）

    Pod的地址是与Docker0在同一个网段的，但Docker0网段与宿主机网段是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以相互访问

• Pod与Service之间的通讯

  各个节点的Iptables规则，新一些的版本加入了LVS转换，效率更高

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

• 外网访问Pod：Service，Ingress

2.3 Flannel

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

2.4 ETCD与Flannel关联

etcd存储管理Flanner可分配的IP地址段资源

监控etcd中每个Pod的实际地址，并在内存中建立维护Pod节点路由表

etcd在Kubernetes集群中多处被调用，非常非常重要。