Kubernetes(k8s)pod详解
一、简介
在Kubernetes集群中,Pod是所有业务类型的基础,也是K8S管理的最小单位级,它是一个或多个容器的组合。这些容器共享存储、网络和命名空间,以及如何运行的规范。在Pod中,所有容器都被统一安排和调度,并运行在共享的上下文中。对于具体应用而言,Pod是它们的逻辑主机,Pod包含业务相关的多个应用容器。
二、Pod实现机制与设计模式
每个Pod都有一个特殊的被称为"根容器"的Pause 容器(Pause容器,又叫Infrastructure容器)。 Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod还包含一个或者多个紧密相关的用户业务容器。
众所周知,容器之间是通过Namespace隔离的,Pod要想解决上述应用场景,那么就要让Pod里的容器之间高效共享。
具体分为两个部分:网络和存储
- 共享网络
kubernetes的解法是这样的:会在每个Pod里先启动一个infra container小容器,然后让其他的容器连接进来这个网络命名空间,然后其他容器看到的网络试图就完全一样了,即网络设备、IP地址、Mac地址等,这就是解决网络共享问题。在Pod的IP地址就是infra container的IP地址。
- 共享存储
比如有两个容器,一个是nginx,另一个是普通的容器,普通容器要想访问nginx里的文件,就需要nginx容器将共享目录通过volume挂载出来,然后让普通容器挂载的这个volume,最后大家看到这个共享目录的内容一样。
例如:
# pod-write-read.yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: write
image: centos
command: ["bash","-c","for i in {1..100};do echo $i >> /data/hello;sleep 1;done"]
volumeMounts:
- name: data
mountPath: /data
- name: read
image: centos
command: ["bash","-c","tail -f /data/hello"]
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: data
emptyDir: {}
上述示例中有两个容器,write容器负责提供数据,read消费数据,通过数据卷将写入数据的目录和读取数据的目录都放到了该卷中,这样每个容器都能看到该目录。
验证:
$ kubectl apply -f pod-write-read.yaml
$ kubectl logs my-pod -c read -f
在Pod中容器分为以下几个类型:
- Infrastructure Container:基础容器,维护整个Pod网络空间,对用户不可见
- InitContainers:初始化容器,先于业务容器开始执行,一般用于业务容器的初始化工作
- Containers:业务容器,具体跑应用程序的镜像
三、镜像拉取策略
apiVersion: v1
kind: Pod
metadata:
name: pod001
spec:
containers:
- name: busybox001
image: busybox
imagePullPolicy: IfNotPresent
imagePullPolicy 字段有三个可选值:
-
IfNotPresent:镜像在宿主机上不存在时才拉取
-
Always:默认值,每次创建 Pod 都会重新拉取一次镜像
-
Never: Pod 永远不会主动拉取这个镜像
注意,这里的重启是指在Pod所在Node上面本地重启,并不会调度到其他Node上去。
四、资源限制
Pod资源配额有两种:
申请配额:调度时使用,参考是否有节点满足该配置
-
spec.containers[].resources.limits.cpu
-
spec.containers[].resources.limits.memory
限制配额:容器能使用的最大配置
-
spec.containers[].resources.requests.cpu
-
spec.containers[].resources.requests.memory
apiVersion: v1
kind: Pod
metadata:
name: pod002
spec:
containers:
- name: busybox002
image: busybox
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
其中cpu值比较抽象,可以这么理解:
1核=1000m
1.5核=1500m
那上面限制配置就是1核的二分之一(500m),即该容器最大使用半核CPU。
该值也可以写成浮点数,更容易理解:
半核=0.5
1核=1
1.5核=1.5
五、重启策略
apiVersion: v1
kind: Pod
metadata:
name: pod003
spec:
containers:
- name: busybox003
image: busybox
restartPolicy: Always
restartPolicy字段有三个可选值:
-
Always:当容器终止退出后,总是重启容器,默认策略。
-
OnFailure:当容器异常退出(退出状态码非0)时,才重启容器。适于job
-
Never:当容器终止退出,从不重启容器。适于job
六、 健康检查
默认情况下,kubelet 根据容器状态作为健康依据,但不能容器中应用程序状态,例如程序假死。这就会导致无法提供服务,丢失流量。因此引入健康检查机制确保容器健康存活。
健康检查有两种类型:
- livenessProbe
如果检查失败,将杀死容器,根据Pod的restartPolicy来操作。
- readinessProbe
如果检查失败,Kubernetes会把Pod从service endpoints中剔除。
这两种类型支持三种检查方法:
- httpGet
发送HTTP请求,返回200-400范围状态码为成功。
- exec
执行Shell命令返回状态码是0为成功。
- tcpSocket
发起TCP Socket建立成功。
# health-check.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
上述示例:启动容器第一件事在容器内创建文件,停止30s,删除该文件,再停止60s,确保容器还在运行中。
验证现象:容器启动正常,30s后异常,会restartPolicy策略自动重建,容器继续正常,反复现象。
$ kubectl apply -f health-check.yaml
$ kubectl describe pod liveness-exec
$
七、调度策略
先看下创建一个Pod的工作流程: create pod -> apiserver -> write etcd -> scheduler -> bind pod to node -> write etcd -> kubelet( apiserver get pod) -> dcoekr api,create container -> apiserver -> update pod status to etcd -> kubectl get pods
Pod根据调度器默认算法将Pod分配到合适的节点上,一般是比较空闲的节点。但有些情况我们希望将Pod分配到指定节点,该怎么做呢?
这里给你介绍调度策略:nodeName、nodeSelector和污点
1)nodeName
nodeName用于将Pod调度到指定的Node名称上。
例如:下面示例会绕过调度系统,直接分配到k8s-node1节点。
# SchedulePolicy-nodeName.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
run: busybox
name: busyboxnn
namespace: default
spec:
nodeName: k8s-node1
containers:
- image: busybox
name: bs
command:
- "ping"
- "baidu.com"
执行&查看
$ kubectl apply -f SchedulePolicy-nodeName.yaml
$ kubectl get pod busyboxnn -o wide
2)nodeSelector
nodeSelector用于将Pod调度到匹配Label的Node上。先给规划node用途,然后打标签,例如将两台node划分给不同团队使用:
$ kubectl label nodes k8s-node1 team=a
$ kubectl label nodes k8s-node2 team=b
后在创建Pod只会被调度到含有team=a标签的节点上。
# SchedulePolicy-nodeSelector.yaml
apiVersion: v1
kind: Pod
metadata:
name: busyboxsn
namespace: default
spec:
nodeSelector:
team: b
containers:
- image: busybox
name: bs
command:
- "ping"
- "baidu.com"
执行&查看
$ kubectl apply -f SchedulePolicy-nodeSelector.yaml
$ kubectl get pod busyboxsn -o wide
3)taint(污点)与tolerations(容忍)
- 污点应用场景:节点独占,例如具有特殊硬件设备的节点,如GPU
设置污点命令:
kubectl taint node [node] key=value[effect]
其中[effect] 可取值:
- NoSchedule :一定不能被调度。
- PreferNoSchedule:尽量不要调度。
- NoExecute:不仅不会调度,还会驱逐Node上已有的Pod。
示例:
先给节点设置污点,说明这个节点不是谁都可以调度过来的:
$ kubectl taint node k8s-node1 abc=123:NoSchedule
查看污点:
$ kubectl describe node k8s-node1 |grep Taints
然后在创建Pod只有声明了容忍污点(tolerations),才允许被调度到abc=123污点节点上。
# SchedulePolicy-tolerations.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
run: busybox
name: busybox3
namespace: default
spec:
tolerations:
- key: "abc"
operator: "Equal"
value: "123"
effect: "NoSchedule"
containers:
- image: busybox
name: bs
command:
- "ping"
- "baidu.com"
如果不配置容忍污点,则永远不会调度到k8s-node1。(也可以叫做反亲和性)
去掉污点:
kubectl taint node k8s-node1 abc=123:NoSchedule
$ kubectl taint node k8s-node1 abc:NoSchedule-
master节点默认是打了污点标记,不调度的,去掉污点标记
#添加 尽量不调度 PreferNoSchedule
kubectl taint nodes k8s-master node-role.kubernetes.io/master:PreferNoSchedule
#去除污点NoSchedule,最后一个"-"代表删除
kubectl taint nodes k8s-master node-role.kubernetes.io/master:NoSchedule-
八、Pod状态
1)Pod常见状态
1、Pending:等待中
Pod已经被创建,但还没有完成调度,或者说有一个或多个镜像正处于从远程仓库下载的过程。处在这个阶段的Pod可能正在写数据到etcd中、调度、pull镜像或启动容器。
2、Running:运行中
该 Pod 已经绑定到了一个节点上,Pod 中所有的容器都已被创建。至少有一个容器正在运行,或者正处于启动或重启状态。
3、Succeeded:正常终止
Pod中的所有的容器已经正常的执行后退出,并且不会自动重启,一般会是在部署job的时候会出现。
4、Failed:异常停止
Pod 中的所有容器都已终止了,并且至少有一个容器是因为失败终止。也就是说,容器以非0状态退出或者被系统终止。
5、Terminating 或 Unknown 状态
从 v1.5 开始,Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod,而是将其标记为 Terminating 或 Unknown 状态。
6、Error 状态
通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括:
- 依赖的 ConfigMap、Secret 或者 PV 等不存在
- 请求的资源超过了管理员设置的限制,比如超过了 LimitRange 等
- 违反集群的安全策略,比如违反了 PodSecurityPolicy 等
- 容器无权操作集群内的资源,比如开启 RBAC 后,需要为 ServiceAccount 配置角色绑定。
7、Completed状态
状态由ContainerCreating变为Completed再变为CrashLoopBackOff,原因是command: 或args 参数错误无法正常执行。
用一张图来表示Pod的各个状态
2)Pod 其它状态详细说明
状态 | 描述 |
---|---|
ContainerCreating | 容器创建中 |
PodInitializing pod | 初始化中 |
CrashLoopBackOff | 容器曾经启动了,但可能又异常退出了,kubelet正在将它重启 |
InvalidImageName | 无法解析镜像名称 |
ImageInspectError | 无法校验镜像 |
ErrImageNeverPull | 策略禁止拉取镜像 |
ImagePullBackOff | 正在重试拉取 |
RegistryUnavailable | 连接不到镜像中心 |
ErrImagePull | 通用的拉取镜像出错 |
CreateContainerConfigError | 不能创建kubelet使用的容器配置 |
CreateContainerError | 创建容器失败 |
m.internalLifecycle.PreStartContainer | 执行hook报错 |
RunContainerError | 启动容器失败 |
PostStartHookError | 执行hook报错 |
ContainersNotInitialized | 容器没有初始化完毕 |
ContainersNotRead | 容器没有准备完毕 |
DockerDaemonNotReady | docker还没有完全启动 |
NetworkPluginNotReady | 网络插件还没有完全启动 |
pod启动后停止问题总结(ContainerCreating-》Completed-》CrashLoopBackOff):
pod 是否能持续运行,是由执行命令决定的,执行命令如果一执行就停止,控制台也停止持续输出,pod生命周期就结束,pod状态就会变成CrashLoopBackOff。