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。

posted @ 2022-06-11 20:10  大数据老司机  阅读(2457)  评论(0)  编辑  收藏  举报