K8S之POD

目录

Pod

一、基本概念：

二、pod存在意义

三、Pod实现机制

四、pod镜像拉取策略

五、pod资源限制

六、pod重启机制 

七、pod的健康检查

八、Pod的调度策路

(一) 创建Pod的流程

(二) 影响Pod调度的因素

例子

---

Pod

一、基本概念：

  1. k8s中最小的部署单元

  2. 包含多个容器，它是一个或多个的集合

  3. 一个pod中的容器共享网络命名空间

  4. pod是短暂的，重启pod以后IP会改变，Pod 属于生命周期比较短暂的组件，比如，当 Pod 所在节点发生故障，那么该节点上的 Pod 会被调度到其他节点，但需要注意的是，被重新调度的 Pod 是一个全新的 Pod,跟之前的 Pod

  5. 每一个 Pod 都有一个特殊的被称为”根容器“的 Pause 容器。Pause 容器对应的镜 像属于 Kubernetes 平台的一部分，除了 Pause 容器，每个 Pod 还包含一个或多个紧密相关的用户业务容器

二、pod存在意义

  1. 创建容器使用docker，一个docker对应一个容器，一个容器中运行一个应用程序，当然一个docker中可以创建多个容器，但是这种方式不好管理，因为docker是单进程的，如下图：

   2. pod是多进程设计，可以运行多个应用程序（容器），一个pod中可以有多个容器，一个容器中运行一个应用程序

   3. pod存在为了亲密性应用

        * 两个应用之间进行交互更加方便

        * 网络之间调用可以直接通过127.0.0.1，不需要通过ip调用

        * 两个应用之间需要频繁调用时

三、Pod实现机制

  1. 共享网络

     实现原理：创建pod时，首先会在pod中创建一个pause根容器，也称为info容器，然后创建其它的业务容器，每创建一个业务容器，都会被加入到根容器中，让所有的业务容器在同一个namespace下，只要在同一个namespace下那么所有容器共享ip、port

  2. 共享存储

     实现原理：引入数据卷Volumn，使用数据卷进行持久化存储

四、pod镜像拉取策略

五、pod资源限制

上述代码表明 MySQL 容器申请最少 0.25 个 CPU 以及 64MiB 内存，在运行过程中容器所能使 用的资源配额为 0.5 个 CPU 

六、pod重启机制 

七、pod的健康检查

  1. 容器检查，但是这种检查方式有缺陷

   2. 应用层面检查

       实现原理：K8S会根据容器的检查策略（存活或就绪检查）以及配置的检查方法对容器进行检查，如果检查失败就会根据检查策略来处理该容器

模拟上述配置的操作流程：

八、Pod的调度策路

(一) 创建Pod的流程

master节点做的：

  1. 创建pod时，首先会到apiserver进行创建，并将pod的有关信息存储到etcd中

  2. scheduler会去监控apiserver中是否有新的pod创建，如果有，就会去etcd中读取新创建的pod信息，并根据调度算法将pod调度某个Node节点上，然后将调度结果返回给apiserver并通过apiserver将信息存储到etcd中

Node节点做的：

  3. 调度到某个Node节点上以后，就在该Node节点上进行操作，通过kubelet访问apiserver去读取etcd拿到分配给当前节点的pod，最后kubelet通过docker创建容器并将创建之后的状态返回给apiserver并通过apiserver将容器创建成功的信息存储到etcd中

(二) 影响Pod调度的因素

  1. 资源限制

 根据requests找到满足条件的Node节点进行调度

2. 节点选择器标签影响Pod调度

  示例：     

    第一步：首先对节点创建标签

     第二步：在Pod配置文件中进行配置

 3. 节点亲和性影响Pod调度

 4. 污点和污点容忍

  场景：

    1. 对某些特定的节点做分配：通过ip、节点的硬盘等

    2. 基于Taint做驱逐，例如在Node1中加驱逐，那么Node1就不会被分配pod，pod会被分配到其它Node节点中

  具体演示：

    （1）查看节点的污点情况

 污点值有三个：

  NoSchedule：该节点一定不被调度

  PreferNoschedule：尽量不被调度，节点现存 Pod 不受影响，如果实在是没有符合的节点，也
可以调度上来

  NoExecute：不会调度，当设为此值时，该节点上的Pod 对象会被驱逐到其它节点中

    （2）为节点添加污点：kubectl taint node 节点名 key=value:污点三个值

     （3）删除污点： kubectl taint node 节点名称 key:污点值-

     （4）污点容忍

          当pod的配置文件中设置了污点容忍，那么就算node节点的污点值为NoSchedule，该pod也有可能会被调度到该node节点上，类似于软亲和性

# 等值判断

# 存在性判断

1、当不指定 key 值时，表示容忍所有的污点 key：

tolerations:
- operator: “Exists”

2、当不指定 effect 值时，表示容忍key所有的污点：

tolerations:
- key: “key”
operator: “Exists”

例子

假设您给一个节点添加了如下污点：

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:NoSchedule

假定有一个 Pod，它有两个容忍度：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

在这种情况下，上述 Pod 不会被分配到上述节点，因为其没有容忍度和第三个污点相匹配。 但是如果在给节点添加上述污点之前，该 Pod 已经在上述节点运行， 那么它还可以继续运行在该节点上，因为第三个污点是三个污点中唯一不能被这个 Pod 容忍的。

通常情况下，如果给一个节点添加了一个 effect 值为 NoExecute 的污点， 则任何不能忍受这个污点的 Pod 都会马上被驱逐， 任何可以忍受这个污点的 Pod 都不会被驱逐。 但是，如果 Pod 存在一个 effect 值为 NoExecute 的容忍度指定了可选属性 tolerationSeconds 的值，则表示在给节点添加了上述污点之后， Pod 还能继续在节点上运行的时间。例如
 

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

这表示如果这个 Pod 正在运行，同时一个匹配的污点被添加到其所在的节点， 那么 Pod 还将继续在节点上运行 3600 秒，然后被驱逐。 如果在此之前上述污点被删除了，则 Pod 不会被驱逐。