Pod详解

Pod结构，Pause是根容器，不会出现在kubeclt get pod中。
每个pod都可以包含一个或者多个容器。但只要有一个根容器，有Pod控制器创建pod的时候创建的，作用：
1 可以以他为依据，判断pod的健康状态。
2 可以在跟容器设置ip地址，其他容器都以此ip，实现pod内部的通信
比如设置pause的ip为192.168.1.1，而nginx容器可以共享这个ip，外部的容器想访问ngxin容器，就可以通过pause的ip加上端口号进行访问（pod内部的通讯）。

pod配置

具体配置可以看https://www.cnblogs.com/weicunqi/p/14931793.html

Pod的生命周期

pod的生命周期有五个过程：
1 pod创建过程
2 运行初始化容器过程
3 运行著容器过程(容器启动后钩子， 容器终止前钩子，容器的存货性检测。就绪性检测。)
4 pod终止过程

在整个生命周期，pod会出现五种状态。

创建和终止过程

初始化容器（相当于一些依赖环境）

运行初始化容器。

• 初始化容器主要是做一些环境的准别，比如一个node容器依赖mysql redis等等，那么就需要mysql和reids串行运行完成，node容器才能运行。所以就可以运用初始化容器了，只有当mysql和reids完成才会继续往下运行主容器。

apiVersion: v1
kind: Pod
metadata:
  name: pod-initcontainer
  namespace: dev
spec:
  containers:
  - name: main-container
    image: nginx:1.17.1
    ports: 
    - name: nginx-port
      containerPort: 80
  initContainers: ## 依赖的初始化容器
  - name: test-mysql
    image: busybox:1.30
    command: ['sh', '-c', 'until ping 192.168.5.14 -c 1 ; do echo waiting for mysql...; sleep 2; done;']
  - name: test-redis
    image: busybox:1.30
    command: ['sh', '-c', 'until ping 192.168.5.15 -c 1 ; do echo waiting for reids...; sleep 2; done;']

只有初始化容器运行完毕之后才会运行主容器。

钩子函数

k8s在主容器启动之后和停止之前提供了两个钩子函数。

• post start：容器创建之后执行，如果失败了会重启容器，比如容器启动成功后发消息给企业微信通知容器启动。
• pre stop ：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作

钩子处理器支持使用三种定义动作方向。

• Exec命令：在容器内执行一次命令 如容器启动之后cat xxx执行一次命令
• TCPSocket：在当前容器尝试访问指定的socket 如容器启动之后访问指定的socket
• HTTPGet：在当前容器中向某url发起http请求 如在容器启动时发起网络请求。

容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。
如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例" 摘除 "，不承担业务流量。
k8s提供了两种容器

• liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器
• readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量

一个是会重启容器，一个是不会转发流量。livenessProbe 决定是否重启容器，readinessProbe 决定是否将请求转发给容器。

上述的探针均支持三种方式：

• 1 Exec，容器运行的时候，在容器内反复执行一次命令，如果没报错则正常。
• 2 TCPSocket：容器运行的时候，将会反复尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常
• 3 HTTPGet：反复调用容器内Web应用的URL，如果返回的状态码在200和399之间，则认为程序正常，否则不正常

一共三种，执行命令判断，尝试建立连接判断，请求容器web应用url返回状态码判断。
探测的其他配置：

频率，超时时间，最大失败次数等等。

重启策略

旦容器探测出现了问题，kubernetes就会对容器所在的Pod进行重启，其实这是由pod的重启策略决定的，pod的重启策略有 3 种，分别如下：

• 1 Always ：容器失效时，自动重启该容器，这也是默认值。
• 2 OnFailure ： 容器终止运行且退出码不为0时重启
• 3 Never ： 不论状态为何，都不重启该容器
  重启策略适用于pod所有容器，重启的容器时长会随着重启的次数的增多增多，10s 20s 40s 80s 160s等等。

Pod调度

默认情况下，一个Pod在哪个node节点运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是k8s提供了四种调度方式，供我们使用。

• 1 自动调度，也就是默认，pod运行在哪个节点完全由Scheduler组件计算得出。
• 2 定向调度，就是yaml文件的NodeName和NodeSelector等等
• 3 亲和性调度 NodeAffinity(Node亲和性) PodAffinity(pod亲和性)、PodAntiAffinity(pod反亲和性)
• 4 污点（容忍）调度 Taints、Toleration

定向调度

定向调度，指的是利用在pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过pod运行失败而已。

亲和性调度

它在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活。
关于亲和性(反亲和性)使用场景的说明：

• 亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用的尽可能的靠近，这样可以减少因网络通信而带来的性能损耗。
• 反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性。

三种方式：

• nodeAffinity(node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题
• PodAffinity主要实现以运行的Pod为参照，实现让新创建的Pod跟参照pod在一个区域的功能。
• PodAntiAffinity主要实现以运行的Pod为参照，让新创建的Pod跟参照pod不在一个区域中的功能。

污点和容忍调度

上面的调度都是站在了pod的角度上，来确定pod是否要调度到某个指定的Node上。污点和容忍调度是站在node的角度上，决定是否允许pod调度过来。

污点调度,三种：

• 1 PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
• 2 NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
• 3 NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离
  
  master节点就是加了污点，才不会让pod分配到他身上。
  
  如果只有一个节点Node1,
  第一种：PreferNoSchedule，pod1可以运行在node1上
  第二种：修改为NoSchedule，pod1可以运行，但是pod2不能
  第三种：修改为NoExecute, pod3不能运行，并且之前运行中的Pod1也在退出状态。

容忍

有污点但是我能容忍，可以通过给pod加上容忍，表示我可以容忍你的污点，比如nod1节点为NoExecute，但是给pod加上了容忍，那么此时Pod可以正常运行在node1上。
污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝
容忍是加在pod上的。

apiVersion: v1
kind: Pod
metadata:
  name: pod-toleration
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
  tolerations:      # 添加容忍
  - key: "tag"        # 要容忍的污点的key
    operator: "Equal" # 操作符
    value: "heima"    # 容忍的污点的value
    effect: "NoExecute"   # 添加容忍的规则，这里必须和标记的污点规则相同

Pod控制器详情

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。
pod是k8s的最小单位，但是k8s不会自己去控制pod。一般pod有两种：

• 自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建,比如使用yaml文件创建出来的pod。
• 控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建,比如之前创建的deployment创建的pod。

在k8s中，有许许多多的pod控制器。

ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代

ReplicaSet：保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级

Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本

Horizontal Pod Autoscaler：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷

DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务

Job：它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务

Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行

StatefulSet：管理有状态应用

我们之前创建的deployment，他其实也不直接控制pod，而是通过ReplicaSet级联对象来控制pod。ReplicaSet可以保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级

ReplicaSet(RS)

ReplicaSet的主要作用是保证一定数量的pod正常运行，它会持续监听这些Pod的运行状态，一旦Pod发生故障，就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级。

Deployment(Deploy）

为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。值得一提的是，这种控制器并不直接管理pod，而是通过管理ReplicaSet来简介管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。

Deployment主要功能有下面几个：

• 支持ReplicaSet的所有功能
• 支持发布的停止、继续
• 支持滚动升级和回滚版本

金丝雀发布（灰度发布）

Deployment控制器支持控制更新过程中的控制，如“暂停(pause)”或“继续(resume)”更新操作。
比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

在旧版本的基础之上，创建新版应用，然后根据三种方式切分访问流量：

• 1 根据cookie切分流量
• 2 基础header切分流量
• 3 基于权重切分流量
  有特殊标记的就会访问到新应用上去。当中间切换或者新应用出问题了，也可以迅速的将流量切换到老应用上。

滚动发布

他跟金丝雀发布不一样的是，金丝雀发布，老版本和新版本应用是共存的，比如老版本3个pod，而新版一个pod。共存。1
而滚动发布就是：当新的v2创建完毕之后，老的一个v1就不再接受流量了，所以此时正常工作的有只有三个，v1 v1 v2，依次类推，用这种方式一个一个替换掉老的服务。

Horizontal Pod Autoscaler(HPA)控制器

Horizontal Pod Autoscaler：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷.
之前我们可以通过kubectl scales实现pod扩容和缩容，但这不符合k8s的定位目标，自动化，智能化。k8s期望可以实现通过检测pod的使用情况，实现pod数量的自动跳转，所以产生了HPA控制器。
HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。

DaemonSet(DS)控制器

DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务
DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建

DaemonSet控制器的特点：

每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上

当节点从集群中移除时，Pod 也就被垃圾回收了

Job控制器

Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务。Job特点如下：

• 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量
• 当成功结束的pod达到指定的数量时，Job将完成执行
  

CronJob(CJ)控制器

Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行
CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行。
但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。也就是说，CronJob可以在特定的时间点(反复的)去运行job任务。

一些内容转自 https://www.cnblogs.com/weicunqi/p/14943106.html
仅作学习笔记使用。