k8s相关服务pod定义

k8s相关服务pod定义

1、Pod概述

在Kubernetes集群中，Pod是所有业务类型的基础，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。

只要有pod就会启动pause容器，一个pod会有单个或多个容器

pause起到了同一个pod共用网络栈，共享存储卷

2、Pod的工作方式

​例如，如果一个Node失败，控制器可以自动的在另外一个节点上部署一个完全一样的副本。控制器是Pod模板来创建Pod，Pod的控制器包括：

DeploymentStatefulSetDaemonSet

Replicaset 概述

假如我们现在想要让 nginx pod 使用 nginx:1.9.1 的镜像来代替原来的 nginx:1.7.9 的镜像，运行以下命令：

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

或者我们可以使用 edit 命令来编辑 Deployment，将image从nginx:1.7.9 改写成 nginx:1.9.1。

kubectl edit deployment/nginx-deployment

查看更新进度：

$ kubectl rollout status deployment/nginx-deployment

Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

deployment "nginx-deployment" successfully rolled out

扩容：

kubectl scale deployment nginx-deployment --replicas 10

如果集群支持 horizontal pod autoscaling（HPA） 的话，还可以为 Deployment 设置自动扩展：

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

Deployment更新时会创建一个新的ReplicaSet，然后将新的ReplicaSet中的Pod慢慢扩容到指定的副本数，将旧的ReplicaSet慢慢缩容到0。因此，更新时总能够确保旧的服务不会停止，这就是滚动更新。

Deployment的回滚

当我们像上文一样更新了Deployment之后，我们发现nginx:1.9.1的镜像不是很稳定，因此想要修改回nginx:1.7.9的版本，此时我们不需要手动更改Deployment文件，而是利用Deployment的回滚功能。

使用rollout history命令查看Deployment的版本（revision）：

$ kubectl rollout history deployment/nginx-deployment

deployments "nginx-deployment":

REVISION    CHANGE-CAUSE

1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record

2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

因为我们创建 Deployment 的时候使用了 —recored 参数可以记录命令，我们可以很方便的查看每次 revison 的变化。

查看单个 revision 的详细信息：

kubectl rollout history deployment/nginx-deployment --revision=2

现在，可以使用rollout undo命令回滚到前一个revision：

$ kubectl rollout undo deployment/nginx-deployment

deployment "nginx-deployment" rolled back

也可以使用--to-revision参数指定某个历史版本：

$ kubectl rollout undo deployment/nginx-deployment --to-revision=2

deployment "nginx-deployment" rolled back

你可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revison 历史记录。默认的会保留所有的 revision；如果将该项设置为 0，Deployment 就不允许回退了。

只有 Deployment 的 rollout 被触发才会创建一个 revision！注意！当且仅当 Deployment 的 Pod template被更改，例如更新 template 中的 label 和容器镜像时，才会触发一个rollout，从而为Deployment创建出一个新的 revision。

1、通过kubectl create 创建一个deployment，那么此时就会调用deployment-controller（deployment控制器）创建一个replica set

2、replica set调用replicaset-controller创建pod

3、Pod创建完之后就会由启用资源调度程序default-scheduler，将pod分配对应的node节点，由kubelet管理pod

rollout命令的更多用法：

history（查看历史版本）

pause（暂停Deployment）

resume（恢复暂停的Deployment）

status（查看资源状态）

undo（回滚版本）

maxSurge:滚动更新时最多可以多启动多少个pod

maxUnavailable:滚动更新时最大可以删除多少个pod

maxSurge和maxUnavailable可以用来决定更新的最大pod数和最小pod数

spec.strategy.type.rollingUpdate.maxSurge： 指定在升级时，最大可以创建多少个pod。这个值可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，也就是说，新旧pod的总量不能超过130%。简单来讲，就是在滚动升级时，会先启动30%的新的pod。然后开始杀掉旧的pod，每当一个旧的pod被杀掉，一个新的pod的会被启动，始终保持总量不超过130%，直至更新完成。需要说明的是，当maxUnavailable为0时，maxSurge的值不能为0。spec.strategy.type.rollingUpdate.maxUnavailable： 指定在升级时，最大不可用的pods的值。可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，最少可用的Pod为70%,也就是说，在滚动升级的时候，会先杀掉30%旧的pod，然后开始启动新pod。当一个新的Pod被创建，一个旧的Pod就会被销毁。始终保持可用的pod在总量的70%，直至升级完成。需要说明的是，当maxSurge为0时，maxUnavailable的值不能为0。

StatefulSet

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

StatefulSet是Deployment/RS的一个特殊变种，有如下特性：

StatefulSet里每个Pod都有稳定、唯一的网络标识，可以用来发现集群内其他成员。假设StatefulSet名字叫kafka，那么第1个Pod会命名为kafka-0，第2个Pod叫kafka-1，以此类推。

StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态。

StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC实现，删除Pod时默认不会删除与StatefulSet相关的存储卷。

Headless Service没有Cluster IP，当解析Headless Service的DNS域名时，得到的是该Service对应的全部Pod的Endpoint列表。StatefulSet在Headless Service的基础上，又为受Headless Service控制的每个Pod实例创建了一个DNS域名，格式为：$(podname).$(headless service name)。

样例：一个3节点的kafka的StatefulSet集群

该应用集群的headless service名称定义为kafka

该应用集群的StatefulSet名字为kafka，则StatefulSet里的3个Pod的名称分别为：kafka-0,kafka-1,kafka-2

该应用集群的StatefulSet中3个Pod的DNS名称应该是：kafka-0.kafka,kafka-1.kafka,kafka-2.kafka

可以在该应用集群的配置文件中直接使用上述DNS名称来代表相应的Pod。

DaemonSet 的一些典型用法：

在每个节点上运行集群守护进程在每个节点上运行日志收集守护进程在每个节点上运行监控守护进程

一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求

3、网络通讯模式

网络通讯模式一：

网络通讯模式二：

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

flannel0是flanneld开启的网桥，flanneld是进程

两个不同主机间的pod之间通讯，源10.1.15.2，目标10.1.20.3

首先找到自己的网关docker0，docker0上面的钩子函数会将数据包抓到flannel0，flannel0会有大量的路由表记录从etcd获取，，，，判断到底路由到哪台机器，然后数据包到flanneld网桥，flanneld将数据报文封装mac源66.11，目标66.12，flanneld采用udp，封装新的源15.2，目标20.3外面封装数据包实体payload，转发到66.12，flanneld拆封转发到flannel0，第二次解封docker0看到的是10.1.20.3

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。