【云原生|实战研发】2：Pod的深入实践与理解

待我称王封你为后i 2023-09-30 13:59 19阅读 0赞

本期文章是介绍Pod的简单实践和容器设计模式深入学习，上次的文章中我们已经学习过了Docker、K8s的核心概念理解与简单的代码实战相关知识，也学习了DevOps与微服务的概念，感兴趣的同学可以去我的云原生专栏中学习，任意门：[云原生学习专栏][Link 1]

#### Pod的深入实践理解 ####

*  Pod深入实践学习
 *   *  1、创建一个简单的Pod
     *  2、通过label组成一个Pod
     *   *  pause的label信息
         *  nginx的label信息
     *  3、到底为什么需要Pod？
     *   *  真实的操作系统案例：进程组
         *  Pod的真正作用
     *  4、Pod的具体业务案例
     *  5、Pod的深入理解：超亲密关系
     *  总结
 *  Pod的实现机制
 *   *  1、刨根究底：Pod到底怎么实现的？
     *   *  解法1：通过共享网络
         *  解法2：通过共享存储
 *  附录：Pod的详细定义
 *  附录：Pod的常用命令

## Pod深入实践学习 ##

我们已经了解到，K8s的所有功能都是通过Pod进行展开实现的，大致如下图所示：

![在这里插入图片描述][c1368c926c1141c4bda0929ac7b8ac84.png]

Pod是一组container的集合，container之间可以通过localhost:port的方式直接访问。

### 1、创建一个简单的Pod ###

apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        app: hello-world
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
          - containerPort: 80

创建一个Pod

kubectl create -f pod1.yaml

查看Pod信息：

$ kubectl get pod -o wide
    NAME    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
    nginx   1/1     Running   0          69s   10.244.1.3   node01   <none>           <none>

对该node01节点进行docker ps命令操作得到：

![在这里插入图片描述][f3f3311a2a224e83bd940f9103b8593f.png]  
通过上图我们可以看到，该pod的组成是：一个pause的容器和n个自定义的容器。

大致如下图所示：  
![在这里插入图片描述][50494a3bf27c4477ba448e6ec3336bfc.png]

### 2、通过label组成一个Pod ###

Pod使用label把上述的container组成一个的，接下来查看看container的label信息：

#### pause的label信息 ####

![在这里插入图片描述][0a3fb49d32d34af9900ce41639ade03c.png]

#### nginx的label信息 ####

![在这里插入图片描述][5a9a030f83d44c4fadb650972cb7431c.png]

通过上面的对比分析，会发现： pod.name:“nginx”, namespace: “default”，"pod.uid"都是一样的。

而K8s就是通过这些label来组织Pod的。

### 3、到底为什么需要Pod？ ###

首先需要回顾一下容器的概念，容器的本质是一个视图被隔离、资源受限的进程。

而容器里PID=1的进程就是应用本身（如下图与下文所示），所以，管理虚拟机 = 管理基础设施；管理容器=直接管理应用本身。

而这一点也正是不可变基础设施的最佳表现，这个时候应用就是基础设施，一定是不可变的。

Docker中，进程管理的基础就是Linux的PID名空间技术。在不同PID名空间中，进程ID是独立的：即在两个不同名空间下的进程可以有相同的PID。

当创建一个Docker容器的时候，就会新建一个PID名空间。容器启动进程在该名空间内PID为1。当PID1进程结束之后，Docker会销毁对应的PID名空间，并向容器内所有其它的子进程发送SIGKILL。

需要注意的是：PID=1的进程对于操作系统而言具有特殊意义。操作系统的PID1进程是init进程，以守护进程方式运行，是所有其他进程的祖先，具有完整的进程生命周期管理能力。在Docker容器中，PID1进程是启动进程，它也会负责容器内部进程管理的工作。而这也将导致进程管理在Docker容器内部和完整操作系统上的不同。

![在这里插入图片描述][e9f45039e9694a65b541cb7f6507a3ee.png]

而介于上面的场景之下，K8s的作用又是什么呢？这里需要引用一个特殊的经典话语，那就是容器本身没有价值，有价值的是“容器编排”。而K8s就是用来容器编排的，也有很多人说K8s是云原生时代的操作系统。那么如果按照这个比较关系下去，那么容器镜像就是操作系统里的软件安装包，容器、容器镜像、K8s就是这样一个相互之间的关系。

可以大致的认为：K8s=操作系统linux、容器=进程（linux线程），Pod=进程组（线程组）

#### 真实的操作系统案例：进程组 ####

引入一个Helloworld程序，而该程序由4个进程组构成，这些进程之间共享某些系统的资源文件。

如下图所示，程序中有4个进程。（这里的进程就是linux系统中的线程），分别是api、main、log、compute，这四个线程共同协作helloworld程序的系统资源，进行运行程序的工作。这就是进程组的概念。  
![在这里插入图片描述][1ee78bd1050a446fabb20e8869f5abfc.png]

假设现在需要用容器跑起来上面的程序，那么该怎么进行处理？

最直接的方法，就是通过启动一个docker容器，里面运行四个进程，那么就会存在一个问题，即该容器中PID=1的进程是应用本身的话，如mian进程，那么谁来负责管理剩余的3个进程成了需要解决的难题。

那么对于这个方法，最需要注意的问题是，容器本身是“单进程”模型。（这并不是意味着容器只能跑一个进程。）  
而是说因为容器=应用=进程，所以只能管理PID=1的进程，而其他再跑起来的进程，只能认为是托管状态。所以说除非应用进程具备“进程管理”能力，即helloworld程序需要具备systemd的能力。或者将容器的Pid=1的进程改成systemd，而这样会导致管理容器=管理systemd！=直接管理应用本身。

而如果不具备systemd的能力，那么一旦PID=1的进程kill或者死掉了，那么剩下3个进程的资源没有进行回收，那么这是一个很严重的问题。

总结的来说，一旦容器启动了多个进程，那么只能有一个PID=1的进程，而如果PID=1的进程挂了，那么就会没人回收剩下3个应用的回收，而如果run一个systemd进程来管理其他进程，那么这个时候没有办法直接管理其他的应用，这个时候应用状态的生命周期就不等于容器的生命周期，这样的情况就十分复杂了。

引申：Linux 容器的“单进程”模型，指的是容器的生命周期等同于 PID=1 的进程（容器应用进程）的生命周期，而不是说容器里不能创建多进程。当然，一般情况下，容器应用进程并不具备进程管理能力，所以你通过 exec 或者 ssh 在容器里创建的其他进程，一旦异常退出（比如 ssh 终止）是很容易变成孤儿进程的。

#### Pod的真正作用 ####

而Pod就是用来K8s抽象出来的类比为进程组的概念，而上面提到的情况，就可以认为是一个拥有4个容器的pod，即现在不会塞进一个容器中，而是用4个分别独立的容器启动起来，包含在一个pod里面，而4个容器共享了一部分资源，所以说，Pod在K8s里面是一个逻辑单位（没有真实的去对应某些东西）。

总的来说，Pod 是 Kubernetes 分配资源的一个单位，因为里面的容器要共享某些资源，所以 Pod 也是 Kubernetes 的原子调度单位。

而Pod的设计问题早在 Google 研发 Borg 的时候，就已经发现了这样一个情况：这些应用之前往往有着密切的协作关系，使得它们必须部署在同一台机器上并共享某些资源。  
![在这里插入图片描述][00eb3815bffe418ea8d3ade4f21b6844.png]

### 4、Pod的具体业务案例 ###

现在通过一个例子来帮助我们更好的理解为什么Pod是原子调度单位。

假设现在两个容器，是需要协作完成业务的，所以应该在一个Pod里面。第一个容器为业务容器A，完成写日志文件的功能，第二个容器为转发容器B，顾名思义，即将日志文件转发到后端进行对应处理。

A和B的资源需求如下：A 需要 1G 内存，B需要 0.5G 内存。  
而当前集群环境的可用内存情况如下：Node01：1.25G 内存，Node02：2G 内存。

如果没有Pod，那么A和B需要运行在一台机子上，调度器先把A调到了Node01上，那么这就会使得B不能调度到01上了，因为资源不够，也就是内存不够B用了，这个时候调度失败，需要重新调度。

这类问题在以前没有K8s的Pod的帮助下，很多企业解决这类问题都比较复杂，并且需要额外的开销。

而现在只需要一个Pod就解决了。这样的一个 A 容器和 B 容器一定是属于一个 Pod 的，在调度时是以一个 Pod 为单位进行调度，问题是不存在的。

### 5、Pod的深入理解：超亲密关系 ###

通过上述讲解，已经有了一定的了解。那么继续深入研究一下Pod的“超亲密关系”。

对于普通的亲密关系，就是通过调度来解决的。例如两个应用需要在同一台主机上运行。

而对于Pod的超亲密关系则会存在这样几类关系：

1、两个进程之间会发生文件交换，一个写日志，一个读日志  
2、两个进程之间需要通过 localhost 或者说是本地的 Socket 去进行通信，这种本地通信也属于超亲密关系  
3、两个容器是微服务，需要发生非常频繁的 RPC 调用，考虑性能方面将之认为是超亲密关系  
4、两个容器是应用，需要共享某些 Linux Namespace。举个简单例子：有一个容器需要加入另一个容器的 Network Namespace。这样就能看到另一个容器的网络设备，和它的网络信息。

### 总结 ###

所以通过上述的讲解，理解了Pod的概念设计来由，以及为什么需要Pod。

通过Pod，可以知道怎么去描述超亲密关系，怎么去进行统一的业务调度。

这就是Pod最主要的来由与作用。

## Pod的实现机制 ##

### 1、刨根究底：Pod到底怎么实现的？ ###

在机器上，Pod是怎么实现的，对于这个问题，核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源和数据。

容器之间原本是被 Linux Namespace 和 cgroups 隔开的，现在要解决的是怎么去打破这个隔离，然后共享某些资源等。这就是 Pod 的设计要解决的核心问题所在。

#### 解法1：通过共享网络 ####

假设现在有一个 Pod，其中包含了两个容器A 和 B，它们要共享 Network Namespace。  
在 Kubernetes 里的解法是这样的：它会在每个 Pod 里，额外起一个 Infra container 小容器来共享整个 Pod 的 Network Namespace。

Infra container 是一个十分小的镜像，大概 100-200KB ，是一个汇编语言写的、永远处于“暂停”状态的容器。

这就可以使得其他所有容器都会通过 Join Namespace 的方式加入到 Infra container 的 Network Namespace 中。

所以 Pod 里面的所有容器，它们看到的网络视图是一致的，如它们看到的网络设备、IP地址、Mac地址等等，跟网络相关的信息等。上述这些信息都来自于Pod 第一次创建的这个 Infra container。这就是 Pod 解决网络共享的一个方法。

在 Pod 里面，有一个 IP 地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个 Infra container 的 IP 地址。所以Pod里面的容器看到的都是这个。而对于宿主机上的其他网络资源，都是一个 Pod为 一组来分的，并且被该 Pod 中的所有容器共享网络视图。

该Infra容器相当于总dialing，所以整个 Pod 中是 Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。这也是为什么 K8s中，允许去单独更新 Pod 里的某一个镜像的，即做这个操作，整个 Pod 并不会进行重建或者重启。  
![在这里插入图片描述][be73e211348140f18088965f1ff493b3.png]

#### 解法2：通过共享存储 ####

有两个容器，一个是 A，一个是B，在A放一些文件，使之能通过 Nginx 访问到。所以A需要去 share 这个目录。 share 文件或者是 share 目录在 Pod 里面是容易实现的，就是把 volume 变成了 Pod level。对于同一个Pod下的容器来说共享所有的 volume即可。

在下图的案例中，这个 volume 叫做 shared-data，是属于 Pod level 的，在每一个容器里可以直接声明：挂载 shared-data 这个 volume。只要声明挂载这个 volume，在容器里去看这个目录，实际上每个容器看到的就是同一份。

在之前的例子中，A写了日志，只要这个日志是写在一个 volume 中，只要声明挂载了同样的 volume，这个 volume 就可以立刻被另外一个 B容器给看到。以上就是 Pod 实现存储的方式。  
![在这里插入图片描述][03491187a11a44758527f266509fc077.png]

## 附录：Pod的详细定义 ##

apiVersion: v1 # 必选，API的版本号
    kind: Pod       # 必选，类型Pod
    metadata:       # 必选，元数据
      name: nginx   # 必选，符合RFC 1035规范的Pod名称
      # namespace: default # 可选，Pod所在的命名空间，不指定默认为default，可以使用-n 指定namespace 
      labels:       # 可选，标签选择器，一般用于过滤和区分Pod
        app: nginx
        role: frontend # 可以写多个
      annotations:  # 可选，注释列表，可以写多个
        app: nginx
    spec:   # 必选，用于定义容器的详细信息
    #  initContainers: # 初始化容器，在容器启动之前执行的一些初始化操作
    #  - command:
    #    - sh
    #    - -c
    #    - echo "I am InitContainer for init some configuration"
    #    image: busybox
    #    imagePullPolicy: IfNotPresent
    #    name: init-container
      containers:   # 必选，容器列表
      - name: nginx # 必选，符合RFC 1035规范的容器名称
        image: nginx:1.15.2    # 必选，容器所用的镜像的地址
        imagePullPolicy: IfNotPresent     # 可选，镜像拉取策略, IfNotPresent: 如果宿主机有这个镜像，那就不需要拉取了. Always: 总是拉取, Never: 不管是否存储都不拉去
        command: # 可选，容器启动执行的命令 ENTRYPOINT, arg --> cmd
        - nginx 
        - -g
        - "daemon off;"
        workingDir: /usr/share/nginx/html       # 可选，容器的工作目录
    #    volumeMounts:   # 可选，存储卷配置，可以配置多个
    #    - name: webroot # 存储卷名称
    #      mountPath: /usr/share/nginx/html # 挂载目录
    #      readOnly: true        # 只读
        ports:  # 可选，容器需要暴露的端口号列表
        - name: http    # 端口名称
          containerPort: 80     # 端口号
          protocol: TCP # 端口协议，默认TCP
        env:    # 可选，环境变量配置列表
        - name: TZ      # 变量名
          value: Asia/Shanghai # 变量的值
        - name: LANG
          value: en_US.utf8
    #    resources:      # 可选，资源限制和资源请求限制
    #      limits:       # 最大限制设置
    #        cpu: 1000m
    #        memory: 1024Mi
    #      requests:     # 启动所需的资源
    #        cpu: 100m
    #        memory: 512Mi
    #    startupProbe: # 可选，检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。
    #      httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。
    #            path: /api/successStart # 检查路径
    #            port: 80
    #    readinessProbe: # 可选，健康检查。注意三种检查方式同时只能使用一种。
    #      httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。
    #            path: / # 检查路径
    #            port: 80        # 监控端口
    #    livenessProbe:  # 可选，健康检查
          #exec:        # 执行容器命令检测方式
                #command: 
                #- cat
                #- /health
        #httpGet:       # httpGet检测方式
        #   path: /_health # 检查路径
        #   port: 8080
        #   httpHeaders: # 检查的请求头
        #   - name: end-user
        #     value: Jason 
    #      tcpSocket:    # 端口检测方式
    #            port: 80
    #      initialDelaySeconds: 60       # 初始化时间
    #      timeoutSeconds: 2     # 超时时间
    #      periodSeconds: 5      # 检测间隔
    #      successThreshold: 1 # 检查成功为2次表示就绪
    #      failureThreshold: 2 # 检测失败1次表示未就绪
    #    lifecycle:
    #      postStart: # 容器创建完成后执行的指令, 可以是exec httpGet TCPSocket
    #        exec:
    #          command:
    #          - sh
    #          - -c
    #          - 'mkdir /data/ '
    #      preStop:
    #        httpGet:      
    #              path: /
    #              port: 80
          #  exec:
          #    command:
          #    - sh
          #    - -c
          #    - sleep 9
      restartPolicy: Always   # 可选，默认为Always，容器故障或者没有启动成功，那就自动该容器，Onfailure: 容器以不为0的状态终止，自动重启该容器, Never:无论何种状态，都不会重启
      #nodeSelector: # 可选，指定Node节点
      #      region: subnet7
    #  imagePullSecrets:     # 可选，拉取镜像使用的secret，可以配置多个
    #  - name: default-dockercfg-86258
    #  hostNetwork: false    # 可选，是否为主机模式，如是，会占用主机端口
    #  volumes:      # 共享存储卷列表
    #  - name: webroot # 名称，与上述对应
    #    emptyDir: {
        }    # 挂载目录
    #        #hostPath:              # 挂载本机目录
    #        #  path: /etc/hosts
    #

## 附录：Pod的常用命令 ##

#创建一个pod
    kubectl create -f po.yml
    #查看创建的pod
    kubectl get po
    #创建一个指定命名空间的pod
    kubectl create -f po.yml -n kube-public
    #创建一个命名空间
    kubectl create ns ns_name
    #删除一个pod
    kubectl delete po nginx
    #删除指定命名空间的pod
    kubectl delete po nginx -n kube-public
    #查看删除键pod 所用的时间
    time kubectl delete po nginx

[Link 1]: https://blog.csdn.net/weixin_51484460/category_11839151.html?spm=1001.2014.3001.5482
[c1368c926c1141c4bda0929ac7b8ac84.png]: https://img-blog.csdnimg.cn/c1368c926c1141c4bda0929ac7b8ac84.png
[f3f3311a2a224e83bd940f9103b8593f.png]: https://img-blog.csdnimg.cn/f3f3311a2a224e83bd940f9103b8593f.png
[50494a3bf27c4477ba448e6ec3336bfc.png]: https://img-blog.csdnimg.cn/50494a3bf27c4477ba448e6ec3336bfc.png
[0a3fb49d32d34af9900ce41639ade03c.png]: https://img-blog.csdnimg.cn/0a3fb49d32d34af9900ce41639ade03c.png
[5a9a030f83d44c4fadb650972cb7431c.png]: https://img-blog.csdnimg.cn/5a9a030f83d44c4fadb650972cb7431c.png
[e9f45039e9694a65b541cb7f6507a3ee.png]: https://img-blog.csdnimg.cn/e9f45039e9694a65b541cb7f6507a3ee.png
[1ee78bd1050a446fabb20e8869f5abfc.png]: https://img-blog.csdnimg.cn/1ee78bd1050a446fabb20e8869f5abfc.png
[00eb3815bffe418ea8d3ade4f21b6844.png]: https://img-blog.csdnimg.cn/00eb3815bffe418ea8d3ade4f21b6844.png
[be73e211348140f18088965f1ff493b3.png]: https://img-blog.csdnimg.cn/be73e211348140f18088965f1ff493b3.png
[03491187a11a44758527f266509fc077.png]: https://img-blog.csdnimg.cn/03491187a11a44758527f266509fc077.png