【云原生 | kubernetes 】资源对象 - Pod的深度解析

努力做一名技术

已于 2022-10-01 09:51:39 修改

阅读量684

点赞数 5

分类专栏：云原生文章标签： kubernetes 云原生 docker

于 2022-10-01 08:00:00 首次发布

本文链接：https://blog.csdn.net/weixin_45133467/article/details/127130732

版权

云原生专栏收录该内容

22 篇文章 3 订阅

订阅专栏

一、Pod简述

Pod是k8s（下文Kubernetes简称k8s）的一个抽象概念，Pod本身不是容器。但Pod是由一个或多个容器组成。是 k8s 项目中最小原子调度单位。如果把k8s比作操作系统，那么容器就是进程，而Pod的话就是进程组的概念。

图片来源https://kuboard.cn/learning/k8s-basics/explore.html

二、Namespace共享原理

同一个Pod里的所有容器，共享的是同一个Nettwork Namespace，并且可以声明同一个Volume

在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器。在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。这样的组织关系，可以用下面这样一个示意图来表达：

在这里插入图片描述

Infra容器全称infrastucture container（又叫Pause）基础容器，作为init pod存在，所有当我们创建Pod是都会看到一个Pause容器被创建。现在我们终于知道pause类型镜像（k8s.gcr.io/pause:3.2）的作用是什么。

三、Init容器

1.理解

Init 容器是一种特殊容器，在 Pod 内的应用容器启动之前运行。

**每个Pod中可以包含很多容器，但是有的容器可能依赖某一个功能或特性，需要提前启动一个容器为它提供服务。就像我们使用yum安装一些服务时，会有很多依赖项，如果我们没有安装这个依赖，这个服务会始终安装失败。我们的pod也是，如果Pod的Init容器启动失败，kubelet会不断重启Init容器直到成功，并且Pod的Init容器失败，整个Pod状态也会设置为失败，就像安装依赖一样。**

2.示例

例子定义了一个具有 1 个 Init 容器的简单 Pod。 init容器拉去k8s页面存放到nginx默认路径，当Init容器运行过程中，Pod的状态为Init:0/1 ，init容器启动成功后，pod状态变为Running

1>创建nginx-init.yaml文件

---
apiVersion: v1
kind: Pod
metadata:
    name: nginx-init
spec:
   initContainers:
   - name: install
     image: busybox
     command:
     -  wget
     - "-O"
     - "/work-dir/index.html"
     -  http://kubernetes.io
     volumeMounts:
     -  name: workdir
        mountPath: "/work-dir"
   containers:
   -  name: nginx
      image: nginx
      ports:
      -  containerPort: 80
      volumeMounts:
      -  name: workdir
         mountPath: /usr/share/nginx/html
   volumes:
   -  name: workdir
      emptyDir: {}

2>通过运行下面命令启动Pod：

[root@ycloud ~]# kubectl apply -f nginx-init.yaml 
pod/myapp-pod created

3>验证

[root@ycloud ~]# kubectl get po -owide
NAME                              READY   STATUS             RESTARTS   AGE    IP               NODE     NOMINATED NODE   READINESS GATES
nginx-init                        1/1     Running            0          13m    100.111.212.6    ycloud   <none>           <none>
[root@ycloud ~]# curl 100.111.212.6
<!doctype html><html lang=en class=no-js><head class=live-site><meta name=ROBOTS content="INDEX, FOLLOW">
.....

四、生命周期

Pod的生命周期变化主要体现在status变化，最初状态为Pending阶段，至少要有一个应用容器启动成功后，则进入Running，之后取决于 Pod 中是否有容器以失败状态结束而进入 Succeeded 或者 Failed 阶段。

Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。
Running。这个状态下，Pod 已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。
Succeeded。这个状态意味着，Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。
Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着你得想办法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。
Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。

五、容器状态

Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样。你可以使用容器生命周期回调来在容器生命周期中的特定时间点触发事件。

一旦调度器将 Pod 分派给某个节点，kubelet 就通过容器运行时开始为 Pod 创建容器。容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

六、Pod使用过程中的重要字段：

凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。

1.NodeSelector：是一个供用户将 Pod 与 Node 进行绑定的字段.

apiVersion: v1
kind: Pod
...
spec:
 nodeSelector:
   disktype: ssd

指明Pod永远只能运行在携带“disktype: ssd”标签的节点上；否则会调度失败

2.HostAliases：定义了 Pod 的 hosts 文件（比如 /etc/hosts）的内容

apiVersion: v1
kind: Pod
...
spec:
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
...

在Pod的YAML文件中，我们添加了一组映射关系。

如果我们咋pod启动之后进入pod内去手动添加hosts文件，这样有一个弊端就是当pod重启后，文件将重载。

cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote

3.凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

shareProcessNamespace: true

意味着这个Pod里的容器要共享PID Namespace

[root@ycloud kubernetes]# kubectl apply -f shareproccessnamespace.yaml 
pod/nginx created
---
[root@ycloud kubernetes]# kubectl exec -it nginx -c shell -- /bin/sh
/ # ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   39 101       0:00 nginx: worker process
   40 101       0:00 nginx: worker process
   41 101       0:00 nginx: worker process
   42 101       0:00 nginx: worker process
   43 root      0:00 sh
   57 root      0:00 /bin/sh
   64 root      0:00 ps ax
/ #

可以看到，在这个容器里，我们不仅可以看到它本身的 ps ax 指令，还可以看到 nginx 容器的进程，以及 Infra 容器的 /pause 进程。这就意味着，整个 Pod 里的每个容器的进程，对于所有容器来说都是可见的：它们共享了同一个 PID Namespace。

4.Pod中的容器共享主机的Namespace

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostNetwork: true
  hostIPC: true
  hostPID: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

在这个 Pod 中，我定义了共享宿主机的 Network、IPC 和 PID Namespace。这就意味着，这个 Pod 里的所有容器，会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。

5.Lifecycle处理

k8s 支持 postStart 和 preStop 事件。当一个容器启动后，k8s 将立即发送 postStart 事件；在容器被终结之前， k8s 将发送一个 preStop 事件。容器可以为每个事件指定一个处理程序。

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

你可以看到 postStart 命令在容器的 /usr/share 目录下写入文件 message。命令 preStop 负责终止 nginx 服务。当因为失效而导致容器终止

[root@ycloud ~]# kubectl exec -it lifecycle-demo -- cat /usr/share/message
Hello from the postStart handler

k8s 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期限超时，k8s 的容器管理逻辑会一直阻塞等待 preStop 处理函数执行完毕。

总结

这篇文章中，主要讲解了pod对象，一些重要字段，分析了Pod Namespace共享原理以及Pod的生命周期。

Pod对象是k8s中比较核心的一个概念，在后面的控制器学习中都会用到。

参考文献

https://time.geekbang.org/column/article/40366

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/