Kubernetes第三讲：Pod资源详解

Kubernetes第三讲：Pod资源详解

1. Pod

Pod是Kubernetes的最小工作单元（提供应用的单元），每个Pod包含一个或多个容器，Pod中的容器会作为一个整体被Master调度到一个Node上运行。

kubelet的运行方式有两种：①、通过与kubernetes的master节点交互，接受任务并执行；②、可以作为一个独立组件运行，通过监听某个目录中的yml文件，当发现变化，就执行yml文件，我们可以在这个目录中定义启动Pod的yml文件，不需要master端，kubelet也会自行启动或更新pod，但通过这方式启动的pod没法被master端调度，只能在当前的kubelet主机节点上运行，所以被称作静态pod。

1.1 Pod架构

Pod组成

①、一个Pod中封装了一个或者多个紧耦合的应用容器；

②、Pod中的所有容器使用同一个network namespace，即相同的IP地址空间和Port空间（但是各自的IP地址是独立的），它们可以直接用localhost通信；

③、当Kubernetes挂载volume到Pod上时，本质上是将volume挂载到Pod中的每一个容器。

Pod有两种模式：

Kubernetes 系统的 Pod 资源对象用于运行单个容器，此应用称为 Pod 对象的主容器（main container）；同时 Pod 也能容纳多个容器，不过额外的容器一般工作为 Sidecar型，用于辅助主容器完成工作职能。

①、运行单一容器：也就是将单个容器简单封装成Pod（一个Pod中提供一种应用），Kubernetes不能直接管理容器，只能通过管理Pod来管理容器；在实践中应该将多个应用分别构建到多个而非单个 Pod 中，这样多个Pod能够被调度到多个不同的主机运行，且可以独立按需进行规模变动，使得系统资源利用率更高、系统架构更加灵活；

②、运行多个容器：多个容器应用关系紧密且需要使用共享数据存储时，一般将它们封装在一个Pod中，一般应用于分布式应用系统中，目前分布式系统多采用的模式包括Sidecar pattern、Ambassador pattern、Adapter pattern 3种模型。

❶、Sidecar pattern（边车模型）：为 Pod 的主应用容器提供协同的辅助应用容器，每个应用独立运行，最为典型的代表是将主应用容器中的日志使用 agent 代理收集至日志服务器中时，可以将 agen 运行为辅助应用容器，即 sidecar；另一种典型的应用场景是当主应用容器为database数据库，且启用本地缓存（缓存使用Redis）时使用这种模式。

Sidecar模式

❷、Ambassador pattern（大使模型）：为远程服务创建一个本地代理，代理应用运行于容器中，主容器中的应用通过代理容器访问远程服务；典型的场景是主应用容器中的进程访问“一主多从”模型的远程Rdis应用时，可在当前 Pod容器中为 Redis 建一个Ambassador container ，主应用容器中的进程直接通过 localhost 接口访问 Ambassador container 即可。

Ambassador模式

❸、Adapter pattern（适配器模型）：一般应用于将主应用容器中的内容进行标准化输出，类似于协议转换器的作用，提供一个有利于调用者统一接收数据的接口，例如标准化日志数据的输出等。

Adapter模式

Pod内部结构

Pod内部结构

一个pod 中会分配一个pause容器，这也被称为根容器，根容器的状态代表整个pod 的状态；Pod 中多个容器共享pause容器的网络，容器间可以通过local host互访。

1.2 Pod生命周期

Pod状态转换

Pod状态

1、挂起（Pending）-- Pod 已被Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建；等待时间包括调度Pod 的时间和通过网络下载镜像的时间。

2、运行中（Running）-- 该Pod 已经调度到了一个节点上，Pod 中所有的容器都已被创建，至少有一个容器正在运行，或者正处于启动或重启状态。

3、成功（Succeeded）-- Pod 中的所有容器都被成功终止，并且不会再重启。

4、失败（Failed）-- Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止，也就是说，容器以非0状态退出或者被系统终止。

5、未知（Unknown）-- 因为某些原因无法取得Pod 的状态，通常是因为与Pod 所在主机通信失败。

创建Pod

创建Pod

1、用户通过 kubectl 或者其他 API 客户端提交 Pod Spec 给API Server；

2、API Server 尝试将 Pod 对象的相关信息存入 etcd 中，待写入操作执行完成后，API Server 返回确认信息给客户端（此时Pod的状态为Pending）；

3、API Server 会时刻反映 etcd 中的状态变化；

4、因为所有的 Kubernetes 组件均使用监听机制来跟踪检查 API Server 的相关信息的变动，kube-scheduler（调度器）通过其看门狗 " watcher "发现 API Server 创建了新的 Pod，但尚未绑定至任何工作节点；kube-scheduler将根据Pod 对象的spec信息（如计算资源、nodeSelector等），以及工作节点当前状态来挑选工作节点，并将调度结果信息返回给 API Server；（此时Pod的状态为Running）

5、API Server将调度结果信息更新至 etcd 数据库中，而且 API Server 也开始反映此Pod 对象的调度结果（保证kube-scheduler不会重复调取该任务）；

6、Pod 被调度到的目标工作节点上的 kubelet 尝试在当前节点上调用容器引擎（如Docker engine）来启动容器，并将容器的结果状态返回给 API Server；

7、API Server Pod 状态信息存入 etcd 数据库中；在etcd 确认写入操作成功完成后，API Server 将确认信息发送给相关节点的 kubelet，完成整个Pod创建。

终止Pod

终止Pod

1、用户发送删除 Pod 对象的命令；

2、 API Server中的 Pod 对象的状态会随着时间的推移而更新，在宽限期内（默认为 30 秒），Pod 被视为"dead"；此时将 Pod 标记为" Terminating "状态；

3、同时，kubelet 在监控到 Pod对象转为" Terminating "状态的同时启动Pod关闭过程；

4、同时，端点控制器监控到 Pod 对象的关闭行为时，将其从所有匹配到此端点的 Service 资源的端点列表中移除；

5、如果当前 Pod 对象定义了 preStop 钩子处理器，则在其标记为" Terminating "后即会以同步的方式启动执行；如若宽限期结束后， preStop 钩子仍未执行结束，则第2步会被重新执行并额外获取 一个时长为2秒的小宽限期；

6、Pod 对象中的容器进程收到 TERM 信号；

7、宽限期结束后，若存在任何一个仍在运行的进程，那么 Pod 收到 SIGKILL信号（直接被强制终止）；

8、Kubelet 请求 API Server 将此 Pod 资源的宽限期设置为0从而完成删除操作，它变得对用户不再可见。

注：所有删除操作的宽限期都是 30s ，不过  kubectl delete 命令可以使用 "--grace-period=

1.3 Pod健康检查

默认的健康检查机制：每个容器启动时都会执行一个进程，此进程由Dockerfile的CMD或ENTRYPOINT指定。如果进程退出时返回码非零，则认为容器发生故障，Kubernetes就会根据restartPolicy重启容器。

探针机制

从Pod状态转换我们可以看出来，只要有至少有一个容器正在运行，或者正处于启动或重启状态时Pod都会显示Running状态，所以Running状态并不代表应用无异常。Kubernetes借助探针(Probes) 机制来周期性的监测容器运行的状态，更准确的判断Pod状态并返回结果。

1、Liveness探针：存活探针，用于捕获容器的状态是否处于存活状态，如果探测失败， kubelet会根据重启策略尝试重启容器，需要指定restartPolicy为Always或OnFailure；但是即使是重启容器，也不能解决由于后端服务（如数据库或缓存服务）导致的故障。

2、Readiness探针：就绪探针，如果readiness探针探测失败，则kubelet认为该容器没有准备好对外提供服务，但是并不会杀死或者重启容器，而只是通知服务尚未就绪并触发依赖就绪状态的操作（如endpointController 会从与pod 匹配的所有服务的端点中删除该Pod 的地址等）以确保不会有客户端请求接入此Pod对象。

适用于Pod在不接收任何流量的情况下启动、并且仅在探测成功后才开始接收流量的场景，在启动期间处理大型数据、配置文件或迁移的场景等，应该避免于 Pod 对象启动后立即让其处理客户端请求，而是待容器初始化操作执行完成并转为“就绪”状态。

注：Liveness探针指示Pod 是否存活， Readiness探针则可指示容器是否可以对外提供服务；Pod处于存活状态并不意味着可以提供服务。

#可以通过命令实时查看pod状态kubectl get pods -w

探针实现

探针的实现方式分为3种类型的Handler，也就是说使用不同的方式来周期性诊断是否成功：

①、exec: 在容器内执行用户指定的命令（需要设置为周期性执行），如果命令退出时返回码为0 （表示命令成功执行了） ，则认为诊断成功；在默认情况下三次探测失败，则认为容器不存活，一次探测成功，则认为容器存活。

注：由于执行命令会占用容器资源，所以一般要求探测操作的命令应该尽可能简单和轻量。

②、tcpSocket: 对指定端口上的容器的IP地址进行TCP检查，如果能够正常建立连接，则认为诊断成功，当探针探测到端口无法访问时返回诊断失败；相比于httpGet精准度更低，但是更加高效、更节约资源。

③、httpGet : 对指定端口和路径上的容器IP地址发起HTTP Get请求，如果响应的状态码≥ 200且<400, 则认为诊断成功。

kind: Pod...spec: containers:...#以环境变量的方式向mysql传送root密码 env: - name: MYSQL_ROOT_PASSWORD value: password#mysql服务端口 ports: - containerPort: 3306 name: mysql-master#添加存活探针，周期性检测3306/TCP端口 readinessProbe: tcpSocket: port: 3306#在Pod启动5秒后开始检测，每10秒检测一次 initialDelaySeconds: 5 periodSeconds: 10

容器生命周期钩子Container Lifecycle Hooks

监听容器生命周期的特定事件，并在事件发生时执行已注册的回调函数；钩子的回调函数支持exec（钩子函数触发时执行用户自定义的命令）和httpGet（钩子函数触发时在当前容器中向某 URL 发起 HTTP请求）两种方式。

①、postStart：容器创建后立即执行，注意由于是异步执行，它无法保证一定在ENTRYPOINT之前运行。如果失败，容器会被杀死，并根据RestartPolicy决定是否重启。

②、preStop：容器终止前执行，以同步的方式调用，在完成前会阻塞删除容器的调用，常用于资源清理；如果失败，容器同样也会被杀死。

1.4 QoS

服务质量 (QoS) 是一种服务质量保障机制，用于确定哪些Pod可以使用多少资源；Kubernetes主要管理Pod，而Pod中最重要的是计算资源，所以大多资源管理都是基于CPU和内存的。

节点资源

通过使用以下命令来查看某个node节点资源使用情况，主要指CPU和内存的使用情况：

# -o yaml：参数表示输出结果以yaml文件的格式显示kubectl get nodes -o yaml

显示结果：

①、capacity：该Node的资源真实量，资源信息（包括CPU使用情况、内存使用情况、网络吞吐量及文件系统的使用情况等）由各个node上的kubelet服务获取并上传给APIServer；

其中包含2种基本的资源：

❶、CPU：资源的基本单位是millicores，确切的说指的是使用 CPU的时间；1个核相当于1000 millicores；CPU是可压缩资源，如果CPU资源不足，会通过减少分配给现有业务的时间分片来腾出一部分资源

❷、Memory：内存的限制和请求以Bytes 为单位；内存和硬盘之类的资源是不可压缩资源，一旦一块内存或硬盘空间分配给了现有业务，就不能再被释放给其他Pod使用，除非终止Pod，资源才会被回收 。

②、allocatable：指的是当前这台机器可以被容器使用的资源量，即排除了该节点上已经被占用的资源后剩余的资源。

资源申请

①、request：指容器希望能够保证获取到的最少的资源量。只有节点上的剩余资源大于request值时，容器才会被调度到该节点上，Kubernetes调度器会根据容器的 requests 属性中定义的资源量来判定仅哪些节点可接收运行相关的Pod资源；

对于压缩型的资源 CPU 来说，如果未定义其requests值以确保其最小的可用资源时，它可能会被其他的 Pod 资源压缩至极低的水平， 甚至会达 Pod 不能运行的境地；而对于非压缩型资源来说，内存资源在任何原因导致的紧缺情形下都有可能导致相关的进程被杀死。

②、limit：指的是容器使用资源的上限值，属于硬限制；但是对于CPU资源来说，当没有出现资源抢占时，limit参数并不会起作用；对内存资源来说，容器使用内存超过limit值时就会被OOMkill 掉从而重启，此时容器状态会被标记为" CrashLoopBackOff "，

注：OOM（out of memory），内存溢出；1核CPU相当于1000微核，所以250m表示四分之一核CPU。

spec: containers:... resources:#指定CPU和内存的requests值 requests: memory: "64Mi" cpu: "250m"#指定CPU和内存的limits值 limits: memory: "128Mi" cpu: "500m"

QoS级别

①、Guaranteed级别：是优先级最高的QoS级别，系统管理员—般对这种Pod 的资源占用量比较明确，也就是在创建Pod时，在 pod.spec.containers.resources中指定memory的limits和request、cpu的limits和request的值分别相等。

②、Burstable级别：是优先级其次的QoS级别；pod.spec.containers.resources中至少指定一种资源的request，来实现当有资源的时候，pod运行于最佳性能；当资源不足时，pod运行在最低限度，一般要求limit >request；

注：以上例子中即是Burstable级别的QoS。

③、BestEffort级别：优先级最低的级别；不指定pod.spec.containers.resources参数；当node资源充足时它可以充分使用，但是当node资源被Guaranteed、Burstable Pod 所抢占的时候，它的资源也会被剥夺，而且会被无限压缩。

每个运行状态容器都有其 OOM 得分，得分越高越会被优先杀死；其中Guaranteed级别的Pod得分最低，BestEffort级别的Pod得分最高，所以优先级Guaranteed> Burstable> Best-Effort，优先级低的Pod会在资源不足时优先被杀死；同等级别优先级的 Pod 资源在 OOM 时，与自身的 requests 属性相比，其内存占用比例最大的 Pod 对象将被首先杀死。

2. 资源调度

2.1 资源保护机制--Eviction

在Kubernetes集群中的每一个node上，除了用户容器还会运行很多其他的重要组件，他们以服务进程的方式运行，主要分为两个大类：kubernetes daemon（如kubelet等）和system daemon（如sshd等）。为保证这两类组件有足够的资源运行，同时保证物理节点的稳定性，kubernetes 引入了Eviction policy特性。

当kubernetes 所管理的不可压缩资源短缺时，就有可能触发Eviction ，不可压缩资源包括：可用内存 (memory.available) ，可用的宿主机磁盘 (nodefs.available) ，容器运行镜像存储空间 (imagefs.available) 等，Eviction 提供两种保护模式：

①、Soft模式：允许为某一项参数设置一个缓冲时间，这段时间是为了给Pod 预留出退出时间，当达到阈值一段时间之后， kubelet才会启动Eviction 过程。

②、Hard模式：当某—项参数达到阈值之后立刻触发，直接杀掉Pod，但是会根据Besteffort级别的Pod、Burstable类别并且发生资源使用量已经超出了requests的Pod；Guaranteed 类别并且资源使用量超过了其limits 限制的Pod，这样的QoS级别的顺序来删除Pod；对于同类别Qos 的Pod，kubernetes会根据 Pod优先级（pod priority）来选择移除的顺序。

注：Kubelet计算Eviction阈值的数据来源，主要依赖于Cgroups读取到的值以及监控到的数据。

2.2 Kubernetes调度器

API Server 在接受客户端提交Pod 对象创建请求后 ，然后是通过调度器 kube-scheduler) 从集群中选择—个可用的最佳节点来创建并运行Pod ；在调度的过程当中有三个阶段，即节点预选、节点优选、节点选定（类似于nova-scheduler的过滤-权重过程） ，从而筛选出最佳的节点。

节点预选--过滤

①、调度机制：默认调度器会首先调用一组Predicate 算法，执行预选操作（也就是过滤出适合的节点），调度器会逐一根据规则进行筛选，将那些不符合条件的节点过滤，最终会获得一个可用节点的列表；如果预选没能选定一个合适的节点，此时Pod 会—直处于Pending 状态，直到有一个可用节点完成调度。

②、常用的预选策略(Predicates)：

❶、GeneralPredicates 基础调度策略

• PodFitsResources: 检查节点上的CPU和内存资源是否满足Pod requests字段的资源要求。

• PodFitsHostPorts：检查Pod 申请的宿主机端口是否已经被占用。

• PodMatchNodeSelector：检查Pod nodeSelector或nodeAffinity指定的节点是否与待选节点匹配。

❷、Host相关的过滤规则

• PodToleratesNodeTaints ：如果Pod 对象中定义了spec.tolerations属性，则需要检查Pod是否容忍Node Taints（污点）。

• CheckNodeMemoryPressure：检查Pod 是否可以调度到MemoryPressure（内存压力）的节点上。

❸、Pod相关的过滤规则

• PodAffinityPredicate：检查待调度Pod与Node上已有Pod之间的亲和（affinity）和反亲和（anti-affinity）关系。

节点优选--权重

①、调度机制：调用一组Priority的调度算法，来给可用节点列表中的每个Node打分（计算优先级分值），分值介于0-10之间，其中0表示不适用，10表示最适合托管该Pod 对象，以便选出最合适运行Pod 对象的节点；Kube-scheduler policy支持管理员为各Priorities函数设置权重值（分值乘以权重得出最终的分值），来人为控制调度器的调度行为（比如某个node硬件设备性能更高，将其设置更高的权重值，使得Pod有更大的几率调度到该node上）。

②、常用的优选策略（Priorities）

• LeastRequestedPriority：选择空闲资源 (CPU和Memory) 最多的主机。

注：权重值={ CPU[ capacity-sum(requested) ]*10/capacity +memory[ capacity-sum(requested) ]*10/capacity }/2

如，CPU的可用资源为100，运行容器申请的资源为15；内存可用资源为100，运行容器申请资源为20，那么通过该规则获得的权重值=[（100-15）*10/100+（100-20）*10/100]/2=8.25分。

• BalancedResourceAllocation：选择各种资源分配最均衡的节点，避免一个节点上CPU被大量分配，而Memory大量剩余的情况。

• NodeAffinityPriority：考查Pod的nodeSelector或者nodeAffinity指定的节点，是否与待考察节点匹配。一个Node满足上述的字段数目越多（匹配到的标签越多），它的得分就会越高。

• TaintTolerationPriority：Pod对象的spec.tolerations与节点的taints 的进行匹配度检查。

• lnterPodAffinityPriority：检查待调度Pod与Node上的已有Pod之间的亲和 (affinity) 和反亲(anti-affinity) 关系。

• ImageLocalityPriority：如果待调度Pod 要使用的镜像很大，并且已经存在于某些Node上，那么这些Node 的得分就会比较高。

节点选定

最终得分最高的那个Node就是调度结果。当这类节点多于1个时，则进行随机选择；当调度器对—个Pod调度成功之后，就会在它的spec.nodeName字段填写上调度结果的名字（所在node的主机名）。

2.3 标签与亲和性调度

Label

Label是一个 key=value的键值对，由用户指定，用于给某个资源Pod定义一个标签，实际上标签能够附加于Kubernetes任何资源对象之上；随后可以通过Label Selector来选择一组相同 label 的对象；Key值必须是唯一的，且起始必须是字母；可以在创建时在yml文件中指定labels字段，也可以使用label命令给对象添加标签。

在实际应用中，一般会给同一个资源对象附加多个不同维度的标签以实现更加灵活的资源分组。

Label可以给对象创建多组标签；单label方式如 "A=B"，多label的方式如 "A=B,C=D,..." 或者 "A in (B,C,...)"。

#查看default命名空间中所有Pod，并显示标签kubectl get pods --show-labels #查看default命名空间中所有Pod，并显示指定key的标签kubectl get pods -L kye1，kye2 #为指定Pod|Node打标签kubectl label | key=value --overwrite #为已存在的key强制更新其value

Labels Selectors

通过标签选择器，用户或客户端可以指定批量的对象进行操作，标签选择器也是Kubernetes的核心分组方式，使用标签选择器一般遵循以下几个原则：

①、同时指定的多个选择器之间的逻辑关系为“与”操作；

②、使用空的标签选择器时，每个资源对象都将被选中；

③、使用"key="的标签选择器时，将不会选中任何资源对象。

目前支持两种标签选择器，基于等值的(equality-based) 和基于集合的(setbased)。

①、Equality- based 标签选择器允许用标签的key和values过滤，格式为 key=values 或者 key != values 分别表示筛选出指定的 key-value对的标签（严格匹配）。

②、Set-based 的标签条件允许用—组value来过滤key，支持三种操作符：in, notin 和 exists （仅针对于key符号），格式为 key in/notin （value1，value2...）（范围匹配）。

当使用Exists|DoseNotExist进行选择时，value的值必须为空；表示是否存在指定的key，并不关心key有没有指定value。

#基于等值的选择kubectl get pods -l "key1=value1,key2=value2" # ","表示"与"操作 #基于集合的选择kubectl get pods -l "key1 in (value1,value2)" # ","表示"或"操作 #使用标签选择器来关联Pod资源对象selector: matchLabels: #进行精准匹配 key1: value1 matchExpressions: #进行范围匹配 - {key: key1,operator: In|NotIn,values:[value1]} - {key: key2,operator: Exists|DoseNotExist,value:}

注：注解annotation也是一种key-value类型的标签，但是不能用于Kubernetes的资源筛选，只是用于显示资源的元数据信息而已；可以通过命令 "kubectl annotate" 为资源添加注解。

亲和性调度

亲和性调度分为Node亲和性与Pod亲和性，与标签选择不同的是亲和性调度可以匹配更多的逻辑组合，而不是单纯的字符串匹配。

①、NodeAffinity：在pod.spec.affinity中指定nodeAffinity，通过标签来选择node亲和性，使得Pod调度到能够满足指定的key-value标签的node上；PodAffinity：在pod.spec.affinity中指定podAffinity，通过标签来选择Pod亲和性，使得Pod与匹配到标签的Pod部署在同一个node上。

②、支持的调度算法

• requiredDuringSchedulingIgnoredDuringExecution：表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。

• requiredDuringSchedulingRequiredDuringExecution：表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试；其中RequiredDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，则重新选择符合要求的节点。

• preferredDuringSchedulingIgnoredDuringExecution：表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。

• preferredDuringSchedulingRequiredDuringExecution：表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署；其中RequiredDuringExecution表示如果后面节点标签发生了变化，满足了条件，则重新调度到满足条件的节点。

③、匹配操作符

• In：label的值在某个列表中

• NotIn：label的值不在某个列表中

• Exists：某个label存在

• DoesNotExist：某个label不存在

• Gt：label的值大于某个值（字符串比较）

• Lt：label的值小于某个值（字符串比较）

spec: containers: - name: httpd image: httpd affinity:#为Pod添加node亲和性 nodeAffinity:#设置调度算法 requiredDuringSchedulingIgnoredDuringExecution:#添加node选择器调度条件 nodeSelectorTerms: - matchExpressions:#包含标签 env=test的node节点 - key: env operator: In values: - test

污点--Taint

kubectl taint node key=value[effect]

其中[effect] 可取值：[ NoSchedule | PreferNoSchedule | NoExecute ]

• NoSchedule ：一定不能被调度。

• PreferNoSchedule：尽量不要调度，但是也可以被调度。

• NoExecute：不仅不会调度，还会驱逐Node上已有的Pod。

spec: containers:...#添加Pod对污点的容忍，也就是说Pod一定不能调度到含有 key=value污点的node上 tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule"

2.4 优先级与抢占机制

优先级和抢占机制并非在Pod最开始调度的阶段就被触发，而是在Pod调度失败时才会触发。

①、调度器里维护着一个调度队列，当 Pod拥有了优先级之后，高优先级的Pod就可能会比低优先级的Pod提前出队，从而尽早完成调度过程；

注：PriorityClass是一种资源类型，优先级是一个32bit 的整数，最大值不超过 1000000000（10亿），并且值越大优先级越高。

②、当一个高优先级的Pod 调度失败的时候，调度器的抢占能力就会被触发；这时，调度器就会试图从当前集群里寻找一个节点，使得当这个节点上的一个或多个低优先级的Pod被删除后，待调度的高优先级Pod 就可以被调度到这个节点上。

3. Pod配置详解

apiVersion: v1kind: Podmetadata: name: pod-all labels: key: value tier: frontend #注解也是一种key-value类型的数据，但是不能用于Kubernetes的资源筛选，只是资源的元数据信息而已 annotation: author: KnockCloud #注明这个Pod资源的作者spec: containers: - name: nginx image: nginx:latest imagePullPolicy: Always|ifNotPresent|Nerver # Alway：总是从指定的仓库中获取镜像； # ifNotPresent：当本地不存在该镜像时，才从目标仓库中获取； # Nerver：禁止从仓库中下载，只能使用本地镜像。 #设置资源需求 resources: #指定CPU和内存的requests值 requests: memory: "64Mi" cpu: "250m" #指定CPU和内存的limits值 limits: memory: "128Mi" cpu: "500m" #设置Pod端口 ports: - name: https #应该指定为Pod容器内应用监听的端口，如nginx监听端口为8080。但是在Kubernetes系统的网络模型中，各节点上Pod的IP地址处于同一网络平面，无论是否为容器指定要暴露的端口，都不会响集群其他节点之上的Pod客户端对其进行访问；所以此处的端口只是一个标识，并不具有实际意义。 containerPort: 8080 protocol: tcp #如果要使集群外部访问到容器服务，则可以指定hostPort和hostIP。 hostPort: 8080 #指定主机端口，主机将接收到请求通过NAT机制转发到containerPort上。 hostIP: 192.168.10.11 #此处默认为0.0.0.0，表示Pod所在主机上所有可用的IP地址的8080端口均可用于请求转发。 #通过command附加命令的方式传递到容器中执行，但是配置信息传递有两种方式，一是通过args字段传递，另一种是通过环境变量传递。 command: ["/bin/bash"] #通过args字段传递 args: ["-c","while true;do sleep 30;done"] #通过环境变量传递 env: - name: REDIS_HOST value: database.server:6379 - name: LOG_LEVEL value: info #对于需要运行在Pod所在主机的命名空间内的容器（如Kubernetes的核心组件），也就是说Pod和主机共享主机命名空间，则可以启用使用主机的Network、PID、IPC命名空间，默认均未启用（false） hostNetwork: true hostPID: true hostIPC: true #添加生命周期钩子函数，分别在Pod启动后和终止前执行钩子函数 lifecycle: postStart: #在Pod启动之后会首先修改test.html内容 exec: command: ['/bin/sh','-c',"echo 'lifecycle hooks handler'> /usr/share/nginx/html/test.html] preStop: #在Pod终止之前会到path路径下获取test.html文件 httpGet: path: /test.html port: 8080 scheme: HTTPS #指定用于连接到主机（Pod）的方式，默认为HTTP（根据端口选择不同的方式） #添加存活探针来判断容器的健康状态 livenessProbe: exec: command: ['test','-e','/usr/share/nginx/html/test.html'] #test -e命令用来查看指定文件是否存在 httpGet: host: #默认为Pod的IP地址 path: /test.html port: 8080 scheme: HTTPS tcpSocket: host: #默认为Pod的IP地址 port: https #可以指定协议以代替端口号 failureThreshold: 3 #探测失败阈值：当处于成功状态时，探测操作至少连续多少次的失败才被视为是检测不通过；默认值为3秒，最小值为1秒。 initialDelaySeconds: 0 #开始探测延迟时长：即容器启动多久之后再开始第一次探测操作；默认为0秒，即容器启动后立刻开始进行探测。 periodSeconds: 10 #探测频率：多长时间探测一次；默认为10秒，最小为1秒。频率过高也会消耗更多的资源，频率过低则无法及时探测到错误。 successThreshold: 1 #探测成功阈值：当处于失败状态时，探测操作至少连续多少次的成功探测才被视为是检测通过；默认值为1秒，最小值也为1秒。 timeoutSeconds: 1 #探测超时时间，默认值为1秒。 #添加就绪探针来判断服务的可用性 readinessProbe: exec: command: ['test','-e','/usr/share/nginx/html/test.html'] #test -e命令用来查看指定文件是否存在 httpGet: host: #默认为Pod的IP地址 path: /test.html port: 8080 scheme: HTTPS tcpSocket: host: #默认为Pod的IP地址 port: https #可以指定协议以代替端口号 failureThreshold: 3 #探测失败阈值：当处于成功状态时，探测操作至少连续多少次的失败才被视为是检测不通过；默认值为3秒，最小值为1秒。 initialDelaySeconds: 0 #开始探测延迟时长：即容器启动多久之后再开始第一次探测操作；默认为0秒，即容器启动后立刻开始进行探测。 periodSeconds: 10 #探测频率：多长时间探测一次；默认为10秒，最小为1秒。频率过高也会消耗更多的资源，频率过低则无法及时探测到错误。 successThreshold: 1 #探测成功阈值：当处于失败状态时，探测操作至少连续多少次的成功探测才被视为是检测通过；默认值为1秒，最小值也为1秒。 timeoutSeconds: 1 #探测超时时间，默认值为1秒。 #为Pod定义节点选择器，当部署Pod时会部署在具有指定key=value标签的节点上，前提是管理员需要提前为节点打好标签（如disktype=nvme），从而完成节点亲和性调度。 nodeSelector: disktype: nvme #初始化容器，Pod的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作（例如启动后延时20s，等待主容器内的服务正常可用）；可用字段同spec.containers initContainers: - name: wait_for_server image: busybox command: ['sh','-c','sleep 20']

干货满满，建议收藏！！