其他分享
首页 > 其他分享> > k8s2 pod详情 Pod控制器详情

k8s2 pod详情 Pod控制器详情

作者：互联网

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在主容器启动之后和停止之前提供了两个钩子函数。

容器探测

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

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

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

一共三种，执行命令判断，尝试建立连接判断，请求容器web应用url返回状态码判断。
探测的其他配置：
在这里插入图片描述
频率，超时时间，最大失败次数等等。

重启策略

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

Pod调度

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

定向调度

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

亲和性调度

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

三种方式：

污点和容忍调度

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

污点调度,三种：
容忍

有污点但是我能容忍，可以通过给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有两种：

在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主要功能有下面几个：

金丝雀发布（灰度发布）

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

滚动发布

在这里插入图片描述在这里插入图片描述
他跟金丝雀发布不一样的是，金丝雀发布，老版本和新版本应用是共存的，比如老版本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特点如下：

CronJob(CJ)控制器

Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行
CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行。
但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。也就是说，CronJob可以在特定的时间点(反复的)去运行job任务。
在这里插入图片描述
一些内容转自 https://www.cnblogs.com/weicunqi/p/14943106.html
仅作学习笔记使用。

标签：容器,控制器,调度,详情,Pod,pod,运行
来源： https://blog.csdn.net/lin_fightin/article/details/122630935