Kubernetes(k8s)容器编排Pod介绍和使用

曾经终败给现在 2024-03-16 22:35 57阅读 0赞

#### 目录 ####

*  1 Pod 特点
 *   *  1.1 网络
     *  1.2 存储
 *  2 使用方式
 *   *  2.1 自主式Pod
     *  2.2 控制器管理的Pod
 *  3 自主运行Pod
 *   *  3.1 创建资源清单
     *   *  3.1.1 参数描述
     *  3.2 创建Pod
     *  3.3 Pod操作
     *   *  3.3.1 查看Pod列表
         *  3.3.2 查看描述信息
         *  3.3.3 访问pod
         *  3.3.4 删除Pod
 *  4 控制器运行Pod
 *   *  4.1 创建资源清单
     *  4.2 参数描述
     *   *  4.2.1 Replicas
         *  4.2.2 Selector
         *  4.2.3 Pod Template
     *  4.3 创建Pod
     *  4.4 Pod操作
     *   *  4.4.1 删除Pod
 *  5 镜像拉取策略
 *   *  5.1 always
     *   *  5.1.1 修改资源清单
         *  5.1.2 生效配置
         *  5.1.3 查看创建过程
     *  5.2 IfNotPresent
     *   *  5.2.1 修改资源清单
         *  5.2.2 生效配置
         *  5.2.3 查看创建过程
 *  6 Pod生命周期
 *   *  6.1 各个阶段
     *  6.2 Pod重启策略
     *  6.3 Pod状态转换
     *  6.4 生命周期行为
     *   *  6.4.1 初始化容器
         *  6.4.2 容器探测

--------------------

## 1 Pod 特点 ##

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

> Pod是kubernetes中你可以创建和部署的最小也是最简的单位，一个Pod代表着集群中运行的一个进程。

Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项，Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。

> Pod有两个必须知道的特点

### 1.1 网络 ###

每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口，在同一个Pod中的容器可以同locahost进行互相通信，当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。

### 1.2 存储 ###

Pod能够配置共享存储卷，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据，存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。

## 2 使用方式 ##

### 2.1 自主式Pod ###

这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上，直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上，Pod不会自愈。
    
    	如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除，同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。

### 2.2 控制器管理的Pod ###

Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。
    
    	例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的

## 3 自主运行Pod ##

### 3.1 创建资源清单 ###

> 通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下

vi nginx-pod.yml
    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.12
        ports:
        - containerPort: 80

#### 3.1.1 参数描述 ####

> 下面简要分析一下上面的Pod定义文件：

*  apiVersion： 使用哪个版本的Kubernetes API来创建此对象
 *  kind：要创建的对象类型，例如Pod，Deployment等
 *  metadata：用于唯一区分对象的元数据，包括：name，UID和namespace
 *  labels：是一个个的key/value对，定义这样的label到Pod后，其他控制器对象可以通过这样的label来定位到此Pod，从而对Pod进行管理。（参见Deployment等控制器对象）
 *  spec： 其它描述信息，包含Pod中运行的容器，容器中运行的应用等等。不同类型的对象拥有不同的spec定义。详情参见API文档

### 3.2 创建Pod ###

> 使用`kubectl`创建pod

kubectl apply -f nginx-pod.yml

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

### 3.3 Pod操作 ###

#### 3.3.1 查看Pod列表 ####

kubectl get pods

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

> 可以通过增加 `-o wide`查看详细信息

kubectl get pods -o wide

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

#### 3.3.2 查看描述信息 ####

> 可以通过`describe`查看pod的详细信息

kubectl describe pod nginx

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

#### 3.3.3 访问pod ####

> 可以通过`k8s`创建的虚拟IP进行访问，可以在k8s的任何一个节点访问

curl 10.244.1.10

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

#### 3.3.4 删除Pod ####

> 可以使用`delete`删除Pod，删除后不能进行恢复

kubectl delete pod nginx

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

## 4 控制器运行Pod ##

> Pod本身不具备容错性，这意味着如果Pod运行的Node宕机了，那么该Pod无法恢复，因此推荐使用Deployment等控制器来创建Pod并管理。

### 4.1 创建资源清单 ###

> 通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下

vi nginx-pod.yml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      replicas: 2
      selector:
        matchLabels:
            app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.12
            ports:
            - containerPort: 80

### 4.2 参数描述 ###

> 下面简要分析一下上面的Pod定义文件：

#### 4.2.1 Replicas ####

> 副本数量

spec.replicas 是可以选字段，指定期望的pod数量，默认是1。

#### 4.2.2 Selector ####

> 标签选择器

.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。
    
    	在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。

#### 4.2.3 Pod Template ####

> Pod模板，.spec.template 是 .spec中唯一要求的字段。

.spec.template 是 pod template，它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。
    
    	另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考selector）和适当的重启策略。
    
    	.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。

### 4.3 创建Pod ###

kubectl apply -f nginx-pod.yml
    
    kubectl get pods -o wide

> 创建后发现，有两个nginx的pod在运行，符合我们的预期

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

### 4.4 Pod操作 ###

#### 4.4.1 删除Pod ####

> 这里可以尝试删除Pod

kubectl delete pod nginx-deployment-f77774fc5-cgs82
    # 查看Pod详情
    kubectl get pods -o wide

> 删除Pod后发现重新新建了一个Pod，这是因为有控制器发现少了一个Pod就会进行重新拉起来一个

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

## 5 镜像拉取策略 ##

> pod的镜像拉取策略分为三种：

*  always（总是从官方下载镜像）
 *  never（从不下载镜像）
 *  ifnotpresent（如果本地没有镜像就从官方下载镜像）。

**Kubernetes集群默认使用IfNotPresent策略**

### 5.1 always ###

> 不管是否存在本地镜像，总是从远程仓库下载

#### 5.1.1 修改资源清单 ####

> 我们可以通过修改配置清单来配置不同的策略

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      replicas: 2
      selector:
        matchLabels:
            app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.12
            imagePullPolicy: Always
            ports:
            - containerPort: 80

#### 5.1.2 生效配置 ####

kubectl apply -f nginx-pod.yml

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

#### 5.1.3 查看创建过程 ####

kubectl describe pod nginx-deployment

> 可以清楚的看到重新下载而没有使用本地镜像

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

### 5.2 IfNotPresent ###

> Kubernetes集群的默认策略，如果有本地镜像就使用，没有则从远程仓库下载

#### 5.2.1 修改资源清单 ####

> 我们可以通过修改配置清单来配置不同的策略

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      replicas: 2
      selector:
        matchLabels:
            app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.12
            imagePullPolicy: IfNotPresent
            ports:
            - containerPort: 80

#### 5.2.2 生效配置 ####

kubectl apply -f nginx-pod.yml

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

#### 5.2.3 查看创建过程 ####

kubectl describe pod nginx-deployment

> 可以清楚的看到没有重新下载镜像而是使用本地的镜像。

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

## 6 Pod生命周期 ##

### 6.1 各个阶段 ###

> POD中明确规定了如下几个阶段

<table> 
 <thead> 
  <tr> 
   <th align="left">状态值</th> 
   <th align="left">说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left"><code>挂起（Pending）</code></td> 
   <td align="left">Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建，等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>运行中（Running）</code></td> 
   <td align="left">该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>成功（Succeeded）</code></td> 
   <td align="left">Pod 中的所有容器都被成功终止，并且不会再重启。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>失败（Failed）</code></td> 
   <td align="left">Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>未知（Unknown）</code></td> 
   <td align="left">因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。</td> 
  </tr> 
 </tbody> 
</table>

实际上还有一中状态Terminating，在代码和文档中都没有说明，但却是存在。这种情况出现杂无法获取所在主机的资源情况，一直在尝试建立连接。

### 6.2 Pod重启策略 ###

> 在Pod中的容器可能会由于异常等原因导致其终止退出，Kubernetes提供了重启策略以重启容器。

Pod通过`restartPolicy`字段指定重启策略，重启策略类型为：Always、OnFailure 和 Never，默认为 Always。
    
    	重启策略对同一个Pod的所有容器起作用，容器的重启由Node上的kubelet执行。Pod支持三种重启策略，在配置文件中通过`restartPolicy`字段设置重启策略：

<table> 
 <thead> 
  <tr> 
   <th align="left">重启策略</th> 
   <th align="left">说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">Always</td> 
   <td align="left">当容器失效时，由kubelet自动重启该容器</td> 
  </tr> 
  <tr> 
   <td align="left">OnFailure</td> 
   <td align="left">当容器终止运行且退出码不为0时，由kubelet自动重启该容器</td> 
  </tr> 
  <tr> 
   <td align="left">Never</td> 
   <td align="left">不论容器运行状态如何，kubelet都不会重启该容器</td> 
  </tr> 
 </tbody> 
</table>

注意：这里的重启是指在Pod的宿主Node上进行本地重启，而不是调度到其它Node上。

### 6.3 Pod状态转换 ###

<table> 
 <thead> 
  <tr> 
   <th align="left">Pod的容器数</th> 
   <th align="left">Pod当前状态</th> 
   <th align="left">发生的事件</th> 
   <th align="left">Pod结果状态</th> 
   <th align="left"></th> 
   <th align="left"></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left"></td> 
   <td align="left"></td> 
   <td align="left"></td> 
   <td align="left">RestartPolicy=Always</td> 
   <td align="left">RestartPolicy=OnFailure</td> 
   <td align="left">RestartPolicy=Never</td> 
  </tr> 
  <tr> 
   <td align="left">包含一个容器</td> 
   <td align="left">Running</td> 
   <td align="left">容器成功退出</td> 
   <td align="left">Running</td> 
   <td align="left">Succeeded</td> 
   <td align="left">Succeeded</td> 
  </tr> 
  <tr> 
   <td align="left">包含一个容器</td> 
   <td align="left">Running</td> 
   <td align="left">容器失败退出</td> 
   <td align="left">Running</td> 
   <td align="left">Running</td> 
   <td align="left">Failure</td> 
  </tr> 
  <tr> 
   <td align="left">包含两个容器</td> 
   <td align="left">Running</td> 
   <td align="left">1个容器失败退出</td> 
   <td align="left">Running</td> 
   <td align="left">Running</td> 
   <td align="left">Running</td> 
  </tr> 
  <tr> 
   <td align="left">包含两个容器</td> 
   <td align="left">Running</td> 
   <td align="left">容器被OOM杀掉</td> 
   <td align="left">Running</td> 
   <td align="left">Running</td> 
   <td align="left">Failure</td> 
  </tr> 
 </tbody> 
</table>

### 6.4 生命周期行为 ###

#### 6.4.1 初始化容器 ####

> 初始化容器（`init container`）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。

1.  初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么`kubernetes`需要重启它直到成功完成。（注意：如果`pod`的`spec.restartPolicy`字段值为“`Never`”，那么运行失败的初始化容器不会被重启。）
2.  每个初始化容器都必须按定义的顺序串行运行。

#### 6.4.2 容器探测 ####

> 容器探测（`container probe`）是`Pod`对象生命周期中的一项重要的日常任务，它是`kubelet`对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（`handler`）进行定义，`Kubernetes`支持三种处理器用于`Pod`探测：

*  `ExecAction`：在容器内执行指定命令，并根据其返回的状态码进行诊断的操作称为`Exec`探测，状态码为`0`表示成功，否则即为不健康状态。
 *  `TCPSocketAction`：通过与容器的某`TCP`端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
 *  `HTTPGetAction`：通过向容器`IP`地址的某指定端口的指定`path`发起`HTTP GET`请求进行诊断，响应码为`2xx`或`3xx`时即为成功，否则为失败。

> 任何一种探测方式都可能存在三种结果：`“Success”（成功）`、`“Failure”（失败）`、`“Unknown”（未知）`，只有`success`表示成功通过检测。

[f06e2ef4d8f441658d853789e6480e52.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/e843882447da4ec681de468f142234b2.png
[5ab6653902214b31831517a05f5836d9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/5c4541005cb24bae86c621e2266f4708.png
[8e81c899014c4f0fb4df2d0926f426bc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/02dda57c4a794402875f724e2e1000ab.png
[8cd3e2f6e4e44dfabf39ad158c2925a0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/5b8f69a0049f476090957457ed1348d6.png
[ad9603e94ed44060b4d63c5faeb54023.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/378024de582d4ce89a5b573edde438b1.png
[f3d5b2375ad14fa9999d5cd115a4af4c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/fbb95a20d6e44c4aba07773040c7cfce.png
[dd9db954a4e141b488d4d9c1fe3874d7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/a505035a6f034671babd12fa5759f56d.png
[5efa986ac32b4074bb4a2fdf732cf956.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/00c9cf6563e94afa839f81bd6ba62fc3.png
[f0536bfb1d5e4c569161555ae49054ca.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/d910fa713b5449baa959580153fbed10.png
[3750c9b4821949ef96fb99422bd32178.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/0a4e8a1daaf34f4984c6c74e9fc7f74c.png
[834a520695824d94a2f03cb5a356fa60.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/3aae1ef9b48d490384f51221a49da3e8.png
[5d572924563e4639b1713d8b7c59a0a6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/462144a0fa254d5a8d6a1c8251ffb15f.png
[1900d2c5914d4249b0efa15ad15bbc60.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/15/92dbbcea8e43400dbcef0de3661584e2.png