家政服务网站做推广有效果吗,7一12岁手工暗器,软件开发外包公司,wordpress 用户增强Pod是Kubernetes中可以创建、调度和部署的最小#xff0c;也是最简单的单元。Pod是基于Kubernetes部署和运维应用的基础。本文重点介绍下Pod各字段的含义及Pod的使用#xff0c;关于Pod更多的知识细节可以参考Kubernetes Pod详解一文。 本文参考的主要内容来源于Kubernetes 1…Pod是Kubernetes中可以创建、调度和部署的最小也是最简单的单元。Pod是基于Kubernetes部署和运维应用的基础。本文重点介绍下Pod各字段的含义及Pod的使用关于Pod更多的知识细节可以参考Kubernetes Pod详解一文。 本文参考的主要内容来源于Kubernetes 1.29版本在阅读时要稍微注意下避免出现因版本不兼容导致的功能差异。
API对象公共属性配置
Pod作为API对象具有API对象需要包含的一些公共属性。其中apiVersions属性用来标识API对象对应资源的版本这里是Pod的API版本kind用来标识API对象的资源类型这里是Pod类型metadata用来记录API对象的元数据信息如name(名称)、uid(唯一id)、namespace(命名空间)、labels(标签)、annotations(注释)、finalizers(终结器)、ownerReferences(属主引用)等更多API对象metadata的介绍可以参考Kubernetes官网ObjectMeta一文spec用来描述对象的期望状态以及关于对象的一些基本信息。对于Pod来说spec声明了需要使用的容器信息和多个容器共享的信息(如重启策略、挂载在Pod的存储卷、安全上下文等)是学习和使用Pod的重点status用来描述系统当前达到的状态由Kubernetes自动更新。不同类型的对象可以有不同的status信息这里是PodStatus。不推荐用户去修改该属性。可以通过该属性查看Pod最新状态辅助定位问题。API对象公共属性配置在Pod的声明文件的内容如下
apiVersion: v1 # 对象基础属性标识API对象对应资源的版本这里是Pod版本
kind: Pod # 对象基础属性标识API对象的资源类型这里是Pod类型
metadata: # 对象基础属性记录API对象的元数据信息name: string # 标识当前API对象在同类资源中的唯一性uid: string # 标识当前API对象在整个集群中的唯一性由Kubernetes自动填充namespace: string # 用于将同一集群的资源进行逻辑分组labels: # 给资源打标签用于指定对用户有意义且相关的对象的标识属性name1: stringname2: stringannotations: # 用来记录一些注释信息name1: stringname2: stringfinalizers: # 用于告诉 Kubernetes等到特定的条件被满足后再完全删除被标记为删除的资源- string- stringownerReferences: # 标记其属主信息- apiVersion: string # 属主版本kind: string # 属主资源类型blockOwnerDeletion: boolean # 默认为 false如果为 true且属主具有 foregroundDeletion“ 终结器则在删除此引用之前无法删除属主controller: boolean # 如果为 true则此引用指向管理的控制器name: string # 属主名称uid: string # 属主uid
spec: # 对象基础属性描述该对象的期望状态不同类型的API对象其spec的格式都是不同的在使用时要根据API对象的类型具体分析. containers: # Pod中声明的容器容器相关的字段很多后面再展开描述- name: stringimage: stringimagePullPolicy: [Always | Never | IfNotPresent]restartPolocy: [Always | Never | OnFailure ]volumes: # Pod专属属性描述Pod上挂载的存储卷可被Pod中的容器共享支持挂载多种存储类型如Secret、ConfigMap等- name: string # 定义创建volume的名称容器中需要使用这个名字来引用存储卷
status: # 对象基本属性描述系统当前达到的状态由Kubernetes自动更新。不同类型的对象可以有不同的status信息。这里对应PodStatushostIP: string # Pod所在Node的IPphase: [Pending | Running | Succeeded | Failed] # Pod所处生命周期阶段qosClass: [BestEffort | Guaranteed | Burstable] # Pod的服务质量类Quality of Service classQoS class在Node资源不足时使用QoS类来就驱逐Pod作出决定PodIP: string # Pod的IPreason: string # 如果运行失败记录具体原因startTime: time # 记录状态的时间conditions: # Status的细分描述造成当前Status的具体原因- lastProbeTime: timelastTransitionTime: timestatus: stringtype: stringreason: stringinitContainerStatuses: # Pod中容器初始状态的记录- containerID: stringimge: stringimageID: stringname: stringlastState: [running | terminated | waiting]state: [running | terminated | waiting]containerStatuses: # Pod中容器当前状态的记录- containerID: stringimge: stringimageID: stringname: stringlastState: [running | terminated | waiting]state: [running | terminated | waiting]注意上面只是列举了常用的属性完整的属性信息可以参考官网PodSpec一文。更多API对象公共属性的知识细节可以参考Kubernetes API对象一文。接下来重点介绍Pod独有属性的使用。
在Pod中声明容器
一个Pod里可以封装一个容器或多个容器可将Pod看成是对容器的编排。接下来介绍如何在Pod中声明容器。在Pod的声明文件的spec.containers属性声明容器内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:containers: # Pod中声明容器- name: string # 容器名称image: string # 镜像名称imagePullPolicy: [Always | Never | IfNotPresent] # 镜像拉取策略command: [string] # 容器启动时执行的命令一般其启动容器镜像里的应用args: string # 命令参数workingDir: string # 容器的工作目录。如果未指定将使用容器运行时的默认值该默认值可能在容器镜像中配置stdin: boolean # 是否使用stdin作为容器的标准输出默认是falsestdinOnce: boolean # 在第一个客户端附加到stdin时打开并接受数据直到客户端断开连接并关闭 stdintty: boolean # 当使用stdin作为标准输出时使用tty接收用户的标准输输入返回操作系统的标准输出terminationMessagePath: string # 指定容器中文件路径用于写入容器的终止消息terminationMessagePolicy: [File | FallbackToLogsOnError] # 指定写入策略File类型指无论容器是否成功终止都写入FallbackToLogsOnError指在容器错误终止时写入ports: # 指定容器公开的端口列表- name: string # 端口名称Service会使用端口名来引用端口containerPort: string # 容器的公开端口protocol: string # 端口协议。必须是UDP、TCP 或 SCTP的一种。默认为TCPhostIP: string # Node的IPhostPort: string # Node的端口上面仅介绍spec.containers的部分属性更多属性的介绍可以参考Kubernetes官网Container v1 core一文。
资源申请及限制–CPU和内存的申请及限制
容器可以正常启动后接下来要考虑的一个问题就是容器CPU和内存等资源的分配及限制。这里重点介绍下CPU和内存资源其他资源的申请和限制有相似之处。可以在Pod声明文件的spec.containers.resources属性中指定需要申请的资源及对其使用的上限内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:containers: # Pod中声明容器- name: string # 容器名称image: string # 镜像名称command: [string] # 容器启动时执行的命令一般其启动容器镜像里的应用args: string # 命令参数resources: # 容器使用资源requests: # 需要申请的资源memory: string # 指定内存资源大小cpu: string # 指定CPU资源大小limits: # 需要限制的资源memory: string # 指定内存资源大小cpu: string # 指定CPU资源大小需要注意的是不同资源使用的单位不同如内存资源的基本单位是字节byte其他还有E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki等而CPU资源以CPU单位度量。Kubernetes中的一个 CPU 等同于1个AWS vCPU或1个GCP核心或1个Azure vCore或裸机上具有超线程能力的英特尔处理器上的1个超线程。在CPU资源中小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 同时也可以使用后缀m表示毫。如 100m CPU、100 milliCPU 和 0.1 CPU 都是相同的。CPU资源的精度不能超过1m。需要注意的是CPU资源只能使用绝对数量而不是相对数量。0.1在单核、双核或48核上的CPU数量值是一样的。使用示例如下
...
spec:containers:- name: demo-appimage: demo-image...resources: # 容器资源requests: # 当前容器申请的资源cpu: 1500m # 申请CPU资源1500m也即1.5个CPUmemory: 1.5Gi # 申请内存资源1.5Gilimits: # 当前容器可使用资源上限cpu: 2 # CPU资源上限2000m也即2个CPUmemory: 2Gi # 内存资源上限2Gi上述示例表明名为demo-app的容器的内存请求为1.5GiB内存限制为2GiBCPU请求为1500milliCPUCPU限制为2个CPU。 在分配资源时可能存在以下情况 (1) 容器申请的资源超过了Node能力。如果没有Node可以满足新创建Pod里容器请求的资源那么这个Pod将无法正常运行会一直处于Pending状态。可以通过kubectl describe pod查看详细信息。 (2) 指定了需要申请的资源但未指定资源的限制。如果没有为容器指定资源限制则会发生以下情况之一容器在可以使用的资源上没有上限。因而可以使用所在节点上所有的可用资源容器在具有默认CPU限制的名字空间中运行系统会自动为容器设置默认限制。集群管理员可以使用LimitRange指定CPU限制的默认值。 (3) 指定了资源的限制但未指定需要申请的资源。这时Kubernetes会自动为其设置与资源的限制相同的资源请求值。 (4) 未指定需要申请的资源也未指定资源的限制。这种情况统一归类为未指定资源的限制进行处理。 常用的资源主要指CPU和内存其他还包括分页大小等同时Kubernetes也支持对一些扩展资源进行申请和限制。更多资源申请及限制相关的属性介绍可以参考Kubernetes官网ResourceRequirements v1 core一文。
配置探针
Kubernetes对Pod的健康状态可以通过三类探针来检查LivenessProbe(存活探针)、ReadinessProbe(就绪探针)及StartupProbe(启动探针)。其中LivenessProbe指示容器是否正在运行。如果存活态探测失败则kubelet会杀死容器并且容器将根据其重启策略来进一步处理。ReadinessProbe指示容器是否准备好为请求提供服务(准备接收流量)。如果就绪态探测失败Endpoint Controller将从与Pod匹配的所有服务的Endpoint列表中删除该Pod的IP地址这样流量就不会到达该Pod。StartupProbe指示容器中的应用是否已经启动。如果提供了启动探针则所有其他探针都会被禁用直到此探针成功为止。如果启动探测失败kubelet将杀死容器而容器依其重启策略来进一步处理。在Pod声明文件定义探针的内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:containers: # Pod中声明容器- name: stringimage: stringargs: stringlivenessProbe: # 配置容器的liveness探针exec: # 通过在容器中执行命令来完成探测注意需要执行shell命令还需显式调用shellcommand: [string] # 需要执行的命令列表initialDelaySeconds: int # 表示在容器启动后延时多少秒才开始探测避免因容器启动但内部服务还未启动就启动探测并失败的情况periodSeconds: int # 探测的频率默认10s最小值是1timeoutSeconds: int # 探测超时限制到了超时时间如果探测还没返回结果则说明此处探测失败。默认值是1最小值是1failureThreshold: int # 最小连续失败次数如果达到则表示容器未就绪。默认值是3最小值是1successThreshold: int # 最小连续成功次数如果达到则表示容器启动成功。默认值是1最小值是1readinessProbe: # 配置容器的readiness探针httpGet: # 通过HTTP GET请求来完成探测host: string # 待访问的主机名称默认是Pod IPpath: string # HTTP GET请求访问的资源路径port: int # 待访问的端口scheme: string # 连接host使用的协议默认是HTTPhttpHeaders: # HTTP GET请求中需要填充的HEADER- name: stringvalue: stringinitialDelaySeconds: intperiodSeconds: inttimeoutSeconds: intfailureThreshold: intsuccessThreshold: intstartupProbe: # 配置容器的startup探针tcpSocket: # 通过tcp套接字请求来完成探测host: string # 待访问的主机名称默认是Pod IPport: int # 待访问的端口initialDelaySeconds: intperiodSeconds: inttimeoutSeconds: intfailureThreshold: intsuccessThreshold: intLivenessProbe、ReadinessProbe、StartupProbe均使用相同的数据结构Probe描述探针。更多探针属性介绍可以参考Kubernetes官网Probe v1 core一文。 在使用探针时需要选择探测方式。目前Kubernetes支持四种不同的探测方式exec方式用来在容器内执行指定命令、httpGet方式用来对容器的IP地址上指定端口和路径执行HTTP GET请求、tcpSocket方式用来对容器的IP地址上的指定端口执行TCP请求、grpc方式(v1.27稳定支持)使用gRPC执行一个远程过程调用。 由于LivenessProbe、ReadinessProbe、StartupProbe三种探针使用相同的数据结构所以仅以其中一种探针作为事例这里选择LivenessProbe。示例代码如下
apiVersion: v1
kind: Pod
metadata:name: probe-demo-http
spec:containers:- name: liveness-demoimage: registry.k8s.io/liveness-demolivenessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 30 # 延迟探测时间periodSeconds: 3 # 重试时间间隔timeoutSeconds: 10 # 探测超时限制到了超时时间如果探测还没返回结果说明探测失败failureThreshold: 3 # 检测失败3次就表示未就绪successThreshold: 2 # 检查成功2次就表示就绪在上述配置中periodSeconds字段指定了kubelet每隔3秒执行一次存活探测。initialDelaySeconds字段告诉kubelet在执行第一次探测前应该等待30秒。kubelet会向容器内运行的服务服务在监听8080端口发送一个HTTP GET请求来执行探测。如果服务器上/healthz路径下的处理程序返回成功代码则kubelet认为容器是健康存活的。如果处理程序返回失败代码则kubelet会杀死这个容器并将其重启。对于HttpGet请求来说返回大于或等于200并且小于400的任何代码都表示成功其它返回代码都表示失败。
使用Hook
在容器的生命周期中Kubernetes为其定义了postStart和preStop两个Hook用来执行用户的一些扩展操作。 当一个容器启动后Kubernetes将立即发送postStart事件在容器被终结之前Kubernetes将发送一个preStop事件。容器可以为每个事件指定一个处理程序。可以在Pod声明文件的spec.containers.lifecycle属性中对postStart事件或preStop事件指定的处理程序内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:containers:- name: stringimage: stringargs: stringlifecycle: # 在容器的生命周期配置HookpostStart: # 创建容器后立即调用postStartexec: # 在容器中执行命令command: [string] # 需要执行的命令列表preStop: # 容器终止前调用preStop如果容器崩溃或退出则不会调用该处理程序。sleep: # 配置休眠信息seconds: int # 休眠时间单位是秒postStart和preStop更多属性的介绍可以参考Kubernetes官网Lifecycle v1 core一文。 在Hook上指定操作时Kubernetes支持三种四种的探测方式exec方式用来在容器内执行指定命令、httpGet方式用来对容器的IP地址上指定端口和路径执行HTTP GET请求、tcpSocket方式用来对容器的IP地址上的指定端口执行TCP请求、sleep方式设置休眠时间。示例代码如下
...
spec:containers:- name: demo-appimage: demo-image...lifecycle:postStart: # 创建容器后立即调用postStartexec: # 在容器中执行命令这里是打印指定字符串command: [/bin/sh, -c, echo Hello World /usr/share/message]preStop: # 容器终止前调用preStop如果容器崩溃或退出则不会调用该处理程序。sleep: # 配置休眠信息seconds: 10 # 休眠10秒在上述示例中postStart事件在容器的/usr/share目录下写入文件message。preStop事件则让容器休眠了10秒。
在Pod中配置Init Container
Kubernetes引入Init Container(初始化容器)执行应用容器(app Contianer)启动之前的一些初始化操作。Init Container与应用容器在本质上是一样的只是它们仅运行一次就结束并且必须在成功运行完成后系统才能继续执行下一个容器。Init Container中定义的容器都会比spec.containers定义的应用容器先启动。如果为一个Pod指定了多个 Init Container那些这个容器会按顺序逐一启动直至都启动并退出应用容器才会启动。 如果Pod的Init Container失败则认为该Pod失败Kubernetes会不断地重启该Pod直到Init Container成功为止。然而如果Pod对应的restartPolicy为Never它就不会重新启动。 可以在Pod的声明文件的spec.initContainers属性配置Init Container内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:initContainers: # Pod中声明Init Container- name: string # 容器名称image: string # 镜像名称command: [string] # 容器启动时执行的命令一般其启动容器镜像里的应用args: string # 命令参数ports: # 指定容器公开的端口列表- name: string # 端口名称Service会使用端口名来引用端口containerPort: string # 容器的公开端口protocol: string # 端口协议。必须是UDP、TCP 或 SCTP的一种。默认为TCPhostIP: string # Node的IPhostPort: string # Node的端口Init Container配置可用属性与spec.containers一致更多属性的介绍可以参考Kubernetes官网Container v1 core一文。 只是考虑到Init Container的使用场景一般无需给Init Container配置生命周期操作(如postStart、preStop等)、探针(如Liveness、Readiness、Startup)等属性。 具体使用示例可以参考Kubernetes官网Init Containers一文。
在Pod中挂载存储卷
容器内部存储的生命周期是短暂的会随着容器环境的销毁而销毁具有不稳定性。如果多个容器希望共享同一份存储则仅仅依赖容器是很难实现的。所以在Kubernetes中把所有的存储资源抽象成存储卷(Volume)并将其设计在Pod层级来解决这个问题。存储卷是与Pod绑定的且与Pod具有相同生命周期的资源对象。Pod的存储卷是被定义在Pod上然后被各个容器挂载到自己的文件系统中的。同一个Pod中的多个容器能够共享Pod级别的存储卷。 可以在Pod的声明文件的spec.volumes属性在Pod中挂载存储卷然后在spec.containers.volumeMounts配置Init Container内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:containers:- name: stringimage: stringcommand: [string]args: stringvolumeMounts: # 在容器中挂载存储卷- name: string # 存储卷的名称对应Pod中的存储卷mountPath: string # 存储卷的挂载路径这里指容器中的路径volumes: # Pod专属属性描述Pod上挂载的存储卷可被Pod中的容器共享支持挂载多种存储类型如Secret、ConfigMap等- name: string # 定义创建volume的名称容器中需要使用这个名字来引用存储卷emptyDir: object # 存储卷的类型这里是emptyDir表示临时目录- name: stringconfigMap: object # 存储卷的类型这里是configMap存储键值对等配置信息- name: stringpersistentVolumeClaim: object # 存储卷的类型这里是persistentVolumeClaim用来声明持久化存储- name: stringsecret: object # 存储卷的类型这里是secret存储敏感键值对等信息Kubernetes支持多种不同类型的存储卷的挂载如azureDisk、cephfs、configMap、emptyDir、persistentVolumeClaim、secret等更多存储卷类型以及spec.volumes属性可以参考Kubernetes官网Volume v1 core一文。在Pod上定义存储卷后就可以在各个容器中将其挂载到文件系统中。更多容器中挂载卷的属性参考Kubernetes官网VolumeMount v1 core一文。使用示例如下
...
spec:containers:- name: demo-appimage: demo-image...volumeMounts: # 容器中使用存储卷- name: demo-volume-1 # 指定需要使用的存储卷该存储卷已在sepc.volumes中声明mountPath: /data/app # 存储卷在容器中的挂载路径volumes:- name: demo-volume-1 # 定义创建volume的名称emptyDir: {} # 存储卷的类型这里是emptyDir表示临时目录上述示例中将类型为emptyDir的存储卷demo-volume-1挂载在Pod上并将其应用到demo-app容器中并对应到容器的/data/app路径。可以使用emptyDir存储容器日志等易失性数据。
在Pod中使用亲和性和反亲和性
在生产环境中出于健壮性、性能等方面的考虑需要将Pod部署到特定的Node或者将存在某些相互依赖、频繁调用的Pod部署在同一个Node亦或让某些Pod尽可能地远离某些特定的Pod等调度需求。如两个应用频繁交互就有必要利用亲和性让两个应用尽可能靠近这样可以减少因网络通信而带来的性能损耗如某个应用采用多副本部署时就有必要采用反亲和性让各个应用实例分布在各个Node节点上这样可以提高服务的高可用性。以上诉求可以通过亲和性和反亲和性这一概念来实现。亲和性和反亲和性主要分为三类 节点亲和性Node Affinity以Node为目标解决Pod可以调度到哪些Node的问题 Pod亲和性Pod Affinity以Pod为目标解决Pod可以和哪些已存在pod部署到同一个拓扑域中的问题 Pod反亲和性Pod AntiAffinity以Pod为目标解决Pod不能和哪些已存在的pod部署在同一个拓扑域中的问题 这里的拓扑域由一些Node节点组成这些Node节点通常有相同的地理空间坐标如在同一个机架、机房或地区一般用region表示机架、机房等拓扑域用Zone表示地区跨度更大的拓扑域。在极端情况下也可以认为一个Node就是一个拓扑域。 可以在Pod的声明文件的spec.affinity属性配置亲和性和反亲和性内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:containers:- name: stringimage: stringaffinity: # Pod的亲和性配置支持三种配置nodeAffinity、podAffinity、podAntiAffinitynodeAffinity: # Pod亲和Node配置preferredDuringSchedulingIgnoredDuringExecution: # 调度期间尽量满足- weight: int #筛选条件的权重优先选择权重总和最大的Nodepreference: # 多个筛选条件所有的条件都要满足AND关系matchExpressions: # 基于Node的标签(label)匹配的规则- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchFields: # 基于Node的字段(field)匹配的规则- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]requiredDuringSchedulingIgnoredDuringExecution: # 调度期间必须满足nodeSelectorTerms: # 多个筛选条件满足一个就行OR关系- matchExpressions:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchFields:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]podAffinity: # Pod间亲和配置preferredDuringSchedulingIgnoredDuringExecution:- weight: intpodAffinityTerm: # Pod亲和筛选项topologyKey: string # 指定拓扑域Pod在亲和筛选时仅能匹配拓扑域相同的NodenamespaceSelector: # 基于命名空间的筛选器matchExpressions: # 匹配的表达式所有的条件都要满足AND关系- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabels: object # matchLabels 是 {keyvalue} 对的映射。matchLabels映射中的单个{keyvalue}相当于matchExpressions的一个元素其key字段是“key”运算符是“In”values数组只包含“value”。这些要求是“AND”。namespaces: [string] # 指定命名空间列表限制namespaceSelector作用的命名空间labelSelector: # 基于标签的筛选器匹配规则与基于命名空间的筛选器的匹配规则一致matchLabels: objectmatchExpressions:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabelKeys: [string]mismatchLabelKeys: [string]requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: stringnamespaceSelector:matchExpressions:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabels: objectnamespaces: [string]labelSelector:matchLabels: objectmatchExpressions:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabelKeys: [string]mismatchLabelKeys: [string]podAntiAffinity: # Pod反亲和配置其配置项与podAffinity一致只是作用效果相反preferredDuringSchedulingIgnoredDuringExecution:- weight: intpodAffinityTerm: # Pod亲和筛选项topologyKey: string # 指定拓扑域Pod在亲和筛选时仅能匹配拓扑域相同的NodenamespaceSelector: # 基于命名空间的筛选器matchExpressions: # 匹配的表达式所有的条件都要满足AND关系- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabels: object # matchLabels 是 {keyvalue} 对的映射。matchLabels映射中的单个{keyvalue}相当于matchExpressions的一个元素其key字段是“key”运算符是“In”values数组只包含“value”。这些要求是“AND”。namespaces: [string] # 指定命名空间列表限制namespaceSelector作用的命名空间labelSelector: # 基于标签的筛选器匹配规则与基于命名空间的筛选器的匹配规则一致matchLabels: objectmatchExpressions:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabelKeys: [string]mismatchLabelKeys: [string]requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: stringnamespaceSelector:matchExpressions:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabels: objectnamespaces: [string]labelSelector:matchLabels: objectmatchExpressions:- key: stringoperator: [In | NotIn | Exists | DoesNotExist | Gt | Lt]values: [string]matchLabelKeys: [string]mismatchLabelKeys: [string]对亲和性来说提供了两种亲和等级软亲和(preferredDuringSchedulingIgnoredDuringExecution也称软需求、软限制)和硬亲和(requiredDuringSchedulingIgnoredDuringExecution也称硬需求、硬限制)。对硬亲和来说必须满足指定的规则如果不存在这样的Node则无法调度PodPod会一致处于pending状态。对软亲和来说强调优先满足指定规则如果不存在这样的Node也不强求仍能调度到无法满足条件的Node上。对于多个规则的场景可以通过设置权重(weight)值来定义执行的先后顺序。权重值越高越先匹配。 更多Affinity属性的介绍可以参考Kubernetes官网Affinity v1 core一文。
NodeAffinity
NodeAffinity(节点亲和性)关注Pod与Node之间的亲和性关系。通过NodeAffinity可以要求或禁止将某个Pod调度到具有特定亲和性关系的Node上以满足应用程序的性能和资源需求。使用示例如下
spec:...affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: topology.kubernetes.io/zoneoperator: Invalues:- antarctica-east1- antarctica-west1- matchFields:- key: topology.kubernetes.io/zoneoperator: Invalues: [antarctica-south1,antarctica-north1]preferredDuringSchedulingIgnoredDuringExecution:- weight: 1preference:matchExpressions:- key: another-node-label-keyoperator: Invalues:- another-node-label-value- weight: 2preference:matchFields:- key: another-node-field-keyoperator: Invalues:- another-node-field-value在这一示例中所应用的规则如下 (1) Node必须包含一个键名为topology.kubernetes.io/zone的标签并且该标签的取值必须为 antarctica-east1 或 antarctica-west1并且必须保证字段的取值为antarctica-south1或antarctica-north1。 (2) Node最好具有一个键名为another-node-label-key 且取值为 another-node-label-value 的标签 或具有一个键名为another-node-field-key且取值为another-node-field-value的字段且优先匹配后面的规则。
PodAffinity和PodAntiAffinity
PodAffinity(Pod亲和性)关注Pod间的亲和性关系而PodAntiAffinity关注Pod间的反亲和性关系。通过PodAffinity和PodAntiAffinity可以将不同的Pod调度到同一个拓扑域或者调度到不同的拓扑域以满足应用程序的性能和资源需求。尽管PodAffinity和PodAntiAffinity使用不同的对象描述但是从结构上来说目前两者结构相同具体可以参考Kubernetes官网PodAffinity v1 core和PodAntiAffinity v1 core。使用示例如下
...
spec:...affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: securityoperator: Invalues:- S1topologyKey: topology.kubernetes.io/zone- namespaceSelector:matchExpressions:- key: namespacke-keyoperator: Invalues:- namespacke-valuetopologyKey: topology.kubernetes.io/zonepodAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: securityoperator: Invalues:- S2topologyKey: topology.kubernetes.io/zone- weight: 10podAffinityTerm:namespaces:- namespace-1- namespace-2namespaceSelector:matchExpressions:- key: namespacke-keyoperator: Invalues:- namespace-valuetopologyKey: topology.kubernetes.io/zone上述示例中定义了一条Pod亲和性规则和一条Pod反亲和性规则。其中 亲和性规则规定只有Node属于特定的拓扑域(这里是topology.kubernetes.io/zone)且该区域中的其他Pod已打上securityS1标签且该区域中的其他Pod命名空间namespacke-key的键包含namespacke-value的值时调度器才可以将示例Pod调度到此节点上。 反亲和性规则规定如果Node属于特定的拓扑域(这里是topology.kubernetes.io/zone)且该区域中的其他Pod已打上securityS2标签或该区域中的其他Pod命名空间namespacke-key的键包含namespacke-value的值则调度器应尝试避免将示例Pod调度到此节点上。但是对于这条规则来说因为是软需求所以如果没有符合条件的Node仍有可能调度到这类Node。 需要注意的是Pod间亲和性和反亲和性都需要不小的计算量因此会在大规模集群中显著降低调度速度。不建议在包含数百个节点的集群中使用这类设置。
Taints(污点)和Tolerations(容忍度)
如果说亲和性使Pod被吸引到一类特定的节点那么Taint(污点)则相反它的作用是使节点能够排斥一类特定的Pod。Toleration(容忍度)则允许调度器调度带有对应Taint的Pod。注意Toleration允许调度但并不保证调度作为其功能的一部分调度器也会评估其他参数。Taint和Toleration相互配合可以用来避免Pod被分配到不合适的Node上。每个节点上都可以应用一个或多个Taint这表示对于那些不能容忍Taint的Pod是不会被该Node接受的。 可以使用命令kubectl taint给Node增加一个Taint示例如下
$kubectl taint nodes node1 key1value1:NoSchedule这样就给名为node1的Node增加了一个Taint它的键名是key1键值是value1效果是NoSchedule。 而Pod为了能够将其部署到拥有Taint的Node上需要在其声明文件中声明spec.Tolerations内容如下
apiVersion: v1
kind: Pod
metadata:name: stringnamespace: string
spec:containers:- name: stringimage: stringtolerations: # 声明可容忍Taint的Node- key: string # 待匹配的taint的keyoperator: [Exists | Equal] # 匹配操作类型相等或模糊匹配effect: [NoSchedule | PreferNoSchedule | NoExecute] # 容忍Taint的效果如PreferNoSchedule将尝试避免将不能容忍污点的Pod调度到的节点上但不能保证一定避免tolerationSeconds: int # 容忍的时长单位是秒如一个Node之前没有Taint再新添加Taint后其上的Pod还可以继续执行tolerationSecondsvalue: string # taint的键对应的值不适用operator为Exists的场景更多Toleration属性的介绍可以参考Kubernetes官网Toleration v1 core一文。使用示例如下
...
spec:...tolerations:- key: example-keyoperator: Existseffect: NoScheduletolerationSeconds: 3600 在上述示例中待创建的Pod可以被分配到taint的键中包含“example-key”的Node上或没有taint的Node上。如果该Pod运行在一个没有taint的Node上如果手动给这个Node添加taint那么这个Pod仍能运行3600秒。
在API对象中使用Pod
因为Pod生命周期是短暂的一旦运行完成则立即回收且涉及Pod的创建、自愈、删除等操作比较复杂所以很少在Kubernetes中直接使用Pod。而是使用更高级的API对象来管理Pod。当前将应用的类型划分为以下几种无状态应用(stateless application、批处理型batch、节点后台支撑型node-daemon和有状态应用型stateful application。对应Kubernetes中API对象是Deployment、Job、DaemonSet和StatefulSet。 在Deployment、Job、DaemonSet和StatefulSet等资源对象中声明Pod的方式一致都是在spec.template属性上声明PodTemplate而PodTemplate遵循Pod的Schema规范。示例如下
apiVersion: apps/v1
kind: Deployment
metadata:name: demo-deployment
spec:replicas: 3selector:matchLabels:app: demo-apptemplate: # template字段用来声明Pod遵循Pod的Schema规范metadata:labels:app: demo-appspec:containers:- name: demo-appimage: demo-app-image所以说掌握了Pod的Schema后就可轻松地在Deployment、Job、DaemonSet和StatefulSet等资源对象中声明Pod然后将关注点转移到对各个应用类型资源对象的使用上。
Pod Cheat Sheet
Pod是学习和使用Kubernetes的基础Pod中各个字段的含义及作用是掌握Pod的基础。针对Pod中的字段可参考如下全景图 需要说明的是上述Pod字段全景图是基于Kubernetes 1.6版本在使用的时候要稍微注意下。
参考
《Kubernetes权威指南 从Docker到Kubernetes实践全接触》 龚正 吴治辉 闫健勇 编著 《深入剖析Kubernetes》 张磊 著 https://lib.jimmysong.io/kubernetes-handbook/objects/Pod-overview Pod 概览 https://jimmysong.io/kubernetes-handbook/concepts/pod.html Pod 解析 https://kubernetes.io/blog/2021/05/14/using-finalizers-to-control-deletion/ Using Finalizers to Control Deletion https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/common-definitions/object-meta/ 对象元数据 https://www.runoob.com/w3cnote/yaml-intro.html YAML 入门教程 https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ Pod https://www.cnblogs.com/liugp/p/16366688.html Kubernetesk8spod详解 https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/ 配置 Pod 的服务质量 https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/ 配置 Pods 和容器 https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#podstatus-v1-core PodStatus v1 core https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ Pod Lifecycle https://cloud.tencent.com/developer/article/1683483 理解 Kubernetes 的亲和性调度 https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/ 为容器的生命周期事件设置处理函数 https://developer.aliyun.com/article/932905 Kubernetes–Pod亲和性调度 https://blog.csdn.net/qq_45631844/article/details/122080509 Kubernetes 亲和性与反亲和性 https://zhuanlan.zhihu.com/p/676245970 K8S学习指南(44)-k8s调度之NodeAffinity
