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 阅读(165) 评论(0) 编辑收藏举报

刷新页面返回顶部

登录后才能查看或发表评论，立即登录或者逛逛博客园首页

相关博文：

· K8S 调度机制

· K8S资源清单实例

· k8s原理之-Pod状态和生命周期管理

· 定义一个pod的

· Kubernetes pod

阅读排行：
· 无需6万激活码！GitHub神秘组织3小时极速复刻Manus，手把手教你使用OpenManus搭建本
· Manus爆火，是硬核还是营销？
· 终于写完轮子一部分：tcp代理了，记录一下
· 别再用vector＜bool＞了！Google高级工程师：这可能是STL最大的设计失误
· 单元测试从入门到精通

阅读目录(Content)

此页目录为空

YIDADA-SRE

念两句诗

Pod

3. Pod

3.1 什么是Pod?

3.2 为什么要引入Pod?

3.3 Pod探针

3.4 Pod探针的检测方式

3.5 探针检查参数配置

3.6 Pod常见状态

3.7 Pod调度流程

3.8 Pause

3.9 init容器-简介

3.10 Pod容器重启策略

3.11 Pod镜像拉取策略

3.12 探针通用配置参数

3.13 TCP探针参数

3.14 HTTP探针参数

公告

个人信息

日历

搜索

常用链接

随笔分类

随笔档案

相册

阅读排行榜

评论排行榜

最新评论

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

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

	ReadinessProbe：一般用于探测容器内的程序是否健康，它的返回值如果为success,那么久代表这个容器已经完成启动，并且程序已经是可以接收流量的状态

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

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

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

	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: #网络插件没有启动

	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中

	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未共享

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

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

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

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

	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

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

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

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

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

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

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

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

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

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

	port:80
	访问容器的端口号或者端口名，如果数字必须在 1 ~ 65535 之前