Pod

3. Pod

3.1 什么是Pod?

Pod是Kubernetes集群中最小部署单元，一个Pod由一个容器或多个容器组成，每个Pod还包含一个Pause容器，Pause容器是Pod的父容器或者叫根容器，主要负责僵尸进程的回收管理，通过Pause容器可以使同一个Pod里面的多个容器共享存储、网络、PID、IPC等
Pod有以下特点:
	(1)一个Pod可以理解成一个应用实例，提供服务;
	(2)Pod中容器始终部署在同一个Node上;
	(3)Pod中容器共享网络，存储资源;
	(4)Kubernetes集群是直接管理Pod，而不是容器;

3.2 为什么要引入Pod?

1.解决集群之间网络的强依赖性（数据依赖性、网络依赖性、）
2.唯一性Pod的IP地址保证不会冲突
3.解决集群之间暴露多个端口与Pod中共享一个数据目录

3.3 Pod探针

探针是由kubelet对容器执行的定期诊断，以保证pod的状态始终处于运行状态，要执行诊断，kubelet调用由容器实现的Handler(处理程序)，也成为Hook(钩子)，有三种类型的处理程序：

  • ExecAction
ExecAction在容器内执行指定命令，如果命令退出时返回码为0则认为诊断成功
  • StartupProbe启动探针（容器开始运行时执行）
StartupProbe：在k8s1.16版本后新加的探测方式，用于判断容器内应用程序是否已经启动。如果配置了StartupProbe就会先禁止其它的探测，直到它成功为止，成功后将不在进行探测。
  • LivenessProbe存活探针（探针检查失败是否重启容器）
LivenessProbe：用于探测容器是否运行如果探测失败，kubelet会根据配置的重启策略进行相应的处理。若没有配置该探针，默认就是success。
  • ReadinessProbe就绪探针（容器是否正常运行）
ReadinessProbe：一般用于探测容器内的程序是否健康，它的返回值如果为success,那么久代表这个容器已经完成启动，并且程序已经是可以接收流量的状态

如果就绪探针失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址，初始延迟之前的就绪状态默认为Failure（失败），如果容器不提供就绪探针，则默认状态为Success，readinessProbe用于控制Pod是否添加至service

3.4 Pod探针的检测方式

ExecAction：在容器内执行一个命令，如果返回值为0，则认为容器健康
TCPSocketAction：通过TCP连接检查容器内的程序是否健康，它的返回值如果为success，那么久代表这个容器已经完成启动，并且程序已经是可以接受流量的状态
HTTPGetAction：通过应用程序暴露的API地址来检查程序是否是正常的，如果状态码为200~400之间，则认为容器健康

3.5 探针检查参数配置

initialDelaySeconds: 60       # 初始化时间
timeoutSeconds: 2     # 超时时间
periodSeconds: 5      # 检测间隔
successThreshold: 1 # 检查成功为1次表示就绪
failureThreshold: 2 # 检测失败2次表示未就绪

3.6 Pod常见状态

Unschedulable:	#Pod不能被调度，kube-scheduler没有匹配到合适的node节点
PodScheduled:	#Pod正处于调度中，在kube-scheduler刚开始调度的时候，还没有将Pod分配到指定的node，在筛选出合适的节点后就会更新etcd数据，将Pod分配到指定的node
Pending:		#正则创建Pod但是Pod中的容器还没有全部被创建完成=[处于此状态的Pod应该检查Pod依赖的存储是否有权限挂载等]
Failed:			#Pod中有容器启动失败而导致Pod工作异常
Unknown:		#由于某种原因无法获得Pod的当前状态，通常是由于与Pod所在的node节点通信错误
Initialized:	#所有Pod中的初始化容器已经完成了
ImagePullBackOff:	#Pod所在的node节点下载镜像失败
Runing：			#Pod内部的容器已经被创建并且启动
Ready：			#表示Pod中的容器已经可以提供访问服务
Error：			#Pod启动过程中发生错误
NodeLost:		#Pod所在节点失联
Waiting:		#Pod等待启动
Terminating:	#Pod正在被销毁
CrashLoopBackOff:	#Pod但是kubelet正在将他重启
InvalidImageName:	#node节点无法解析镜像名称导致的镜像无法下载
ImageInspectError:	#无法效验镜像，镜像不完整导致
ErrImageNeverPull:	#策略禁止拉取镜像，镜像中心权限是私有等
RegistryUnavailable:	#镜像拉取出错，超时或下载被强制终止
CreateContainerConfigError:	#不能创建kubelet使用的容器配置
CreateContainerError:	#创建容器失败
RunContainerError:	#Pod运行失败，容器中没有初始化PID为1的守护进程等
ContainersNotReady:	#Pod没有准备完毕
ContainersNotInitialized:	#pod没有初始化完毕
ContainerCreating:	#pod正在创建中
PodInitializing:	#Pod正在初始化中
DockerDaemonNotReady:	#node节点docker服务没有启动
NetworkPluginNotReady:	#网络插件没有启动

3.7 Pod调度流程

1.客户端创建Pod由api-server接收请求并鉴权（/root/kube/config）
2.然后写入到etcd、并返回给api-server
3.Scheduler会收到api-server任务信息，Scheduler将不能调度node过滤掉，在可用的节点中进行打分或者选举然后进行调度，调度成功了。把结果返回给api-server这个返回的过程叫 bind pod，然后在写入到etcd，在返回给api-server（写入完成）,然后在同步给Scheduler，调度完成
4.kubelet进行对api-server进行一个监听，进行获取事件调用运行时来运行pod
5.运行时会访问harbor进行一个拉取镜像
6.kubelet创建完pod在把任务返回给api-server、api-server在写入到etcd中

3.8 Pause

  • 简介
  • 目的：初始化pod底层网络
Pause容器，又叫Infra容器，是pod的基础容器，镜像体积只有几百KB左右，配置在kubelet中，注意的功能是一个Pod中多个容器的网络通信。

Infra容器被创建后会初始化Network Namespace,之后其它容器就可以加入到Infra容器中共享Infra容器的网络了，因此如果一个Pod中的两个容器A和B，那么关系如下：
1.A容器和B容器能过直接使用localhost通信
2.A容器和B容器可以看到网卡、IP与端口监听信息。
3.Pod只有一个IP地址，也就是该Pod的Network Namepace对应的IP地址（由Infra容器初始化并创建）
4.k8s环境中的每个Pod有一个独立的IP地址（前提是地址足够用），并且此IP被当前Pod中所有容器在内部共享使用
5.Pod删除后Infra容器随机被删除，其IP被回收

Pause容器共享的Namespace:
1.NET Namespace: Pod中的多个容器共享同一个网络命名空间，即使用相同的IP和端口信息
2.IPC Namespace: Pod中的多个容器可以使用System VIPC或POSIX消息队列进行通信
3.UTS Namespace: Pod中的多个容器共享一个主机名
# MNT Namespace、PID Namespace、User Namespace未共享

3.9 init容器-简介

init容器的作用：
1.可以为业务容器提前准备好业务容器的运行环境，比如将业务容器需要的配置文件提前生成并放在指定位置、检查数据权限或完整性、软件版本等基础运行环境
2.可以在运行业务容器之前准备好需要的业务数据，比如从OSS对象存储下载，或者从其它位置copy
3.检查依赖的服务是否能够访问

init容器的特点：
1.一个pod可以有多个业务容器还能在有多个init容器、但是每个init容器和业务容器的运行环境都是隔离的
2.init容器会比业务容器先启动
3.init容器运行成功之后才会继续运行业务容器
4.如果一个pod有多个init容器，则需要从上到下逐个运行并且全部成功，最后才会运行业务容器
5.init容器不支持探针检测（因为初始化完成后就退出再也不运行了）

3.10 Pod容器重启策略

Pod一旦配置探针，在检测失败的时候，会基于restartPolicy对Pod进行下一步操作

  • restartPolicy（重启重启策略）
Always：当容器异常时，k8s自动重启该容器，ReplicationController/Replicaset/Deployment,默认为Always
OnFailure：当容器失败时（容器停止运行且退出码不为0）k8s自动重启该容器
Never：不论容器运行状态如何都不会重启该容器Job或CronJob

3.11 Pod镜像拉取策略

  • imagePullPolicy
IfNotPresent：node节点没有此镜像就去指定的镜像仓库拉取，node有就使用node本地镜像
Always:	每次重建pod都会重新拉取镜像
Never:  从不拉取镜像，只使用本地镜像

3.12 探针通用配置参数

initialDelaySeconds: 120
初始化延迟时间，告诉kubelet在执行第一次探测前应该等待多少秒，默认是0秒，最小值是0

periodSeconds: 60
探测周期间隔时间，指定了kubelet应该每多少秒执行一次存活探测，默认是10秒，最小值是1

timeoutSeconds: 5
单次探测超时时间，探测的超时后等待多少秒，默认值是1秒，最小值是1

successThreshold: 1
从失败转为成功的重试册数，探测器在失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是1

failureThreshold: 3
从成功转为失败的重试次数，当Pod启动了并且探测到失败，kubernetes的重试次数，存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃Pod会被打上未就绪的标签，默认值是3，最小值是1

3.13 TCP探针参数

探针是由kubelet对容器执行的定期诊断，以保证Pod的状态始终处于运行状态，要执行诊断，kubelet调用由容器实现的Handler（处理程序），也成为Hook（钩子）有三种类型的处理程序：

ExecAction:
在容器内执行指定命令，如果命令退出时返回码为0则认为诊断成功

TCPSocketAction：
对指定端口上的容器的IP地址进行TCP检查

HTTPGetAction:
对指定的端口和路径上的容器的IP地址执行HTTPGet请求，如果响应的状态码大于等于200且小于400，则认为诊断是成功的

每次探测都将获得以下三种结果之一：
成功：容器通过了诊断
失败：容器未通过诊断
未知：诊断失败，因此不会采取任何行动

3.14 HTTP探针参数

HTTP探测器可以在httpGet上配置额外的字段：
host:
连接使用的主机名，默认是Pod的IP，也可以在HTTP头中设置“Host”来代替

scheme: http
用于设置连接主机的方式（HTTP还是HTTPS），默认是HTTP

path: /monitor/index.html
访问HTTP服务的路径

httpHeaders:
请求中自定义的HTTP头，HTTP头字段允许重复

port:80
访问容器的端口号或者端口名，如果数字必须在 1 ~ 65535 之前
posted @ 2023-01-01 22:05  YIDADA-SRE  阅读(146)  评论(0)  编辑  收藏  举报