头条权重查询站长工具,网站建设公司发展方向及趋势,建立网站所需的硬件和软件,微网站做的比较好的K8s 集群节点 CPU 使用率高#xff01;内存溢出#xff08;OOM#xff09;#xff01;宕机#xff01;导致大量微服务瘫痪怎么办#xff1f;可能是调度策略没做好#xff0c;看完这篇文章掌握提高集群稳定性的管理诀窍。 Kubernetes#xff08;K8s#xff09;是一个开… K8s 集群节点 CPU 使用率高内存溢出OOM宕机导致大量微服务瘫痪怎么办可能是调度策略没做好看完这篇文章掌握提高集群稳定性的管理诀窍。 KubernetesK8s是一个开源的容器编排工具而容器调度是其非常重要的特性所谓的调度是指将容器Pod分配到集群中的节点上运行的过程。为了更好地控制容器的调度K8s 提供了多种调度策略其中包括定向调度和亲和性策略。在实际的 K8s 集群维护场景中合理使用这些调度策略对集群的稳定性至关重要。本文将通过分享实践案例帮助你更好地理解和使用这些功能。 定向调度 定向调度通过 nodeName 和 nodeSelector 来声明 Pod 期望调度的目标节点这种方式的调度是强制性的不管节点是否存在是否宕机都会往声明的节点上去调度当目标不存在或不可调度时将会导致 Pod 无法运行。 nodeName 强制将 Pod 调度到指定主机名的节点上这种方式简单粗暴没有经过 Scheduler 的调度逻辑。 示例我有一个机器学习的应用需要调度到集群中唯一的 GPU 节点上可以这样做。 apiVersion: apps/v1 kind: Deployment metadata:name: athena spec:replicas: 1selector:matchLabels:app: athenatemplate:metadata:labels:app: athenaspec:containers:- name: athenaimage: athena:2.0.0nodeName: k8s-node-gpu-1 NodeSelector 强制将 Pod 调度到指定标签的节点上这种方式通过 Label-selector 机制实现在 Pod 创建之前会由 Schedule 的 MatchNodeSelector 调度策略根据 Label 匹配节点再将 Pod 调度到目标节点上。 示例我有一个机器学习的应用需要调度到集群中带有 hardware-type:gpu 标签的节点上带有该标签的节点有多台可以这样做。 apiVersion: apps/v1 kind: Deployment metadata:name: athena spec:replicas: 1selector:matchLabels:app: athenatemplate:metadata:labels:app: athenaspec:containers:- name: athenaimage: athena:2.0.0nodeSelector:hardware-type: gpu# gpu-type: T4 (允许有多label匹配) 定向调度比较简单粗暴那有没有相对温和、灵活点的调度策略呢当然是有的接下来让我们来看看亲和性调度策略。 亲和性调度 亲和性调度Affinity在定向调度的基础上通过灵活的节点亲和性nodeAffinity、Pod 亲和性podAffinity、Pod 反亲和性podAntiAffinity规则满足更多样化的调度场景。 nodeAffinity 比 nodeSelector 更加强大和灵活可以让 Pod 满足更多样化的条件调度到指定的节点上支持“软性调度”PreferredDuringSchedulingIgnoreDuringExecution和“硬性调度”RequiredDuringSchedulingIgnoredDuringExecution”硬性调度比较强硬不满足条件则调度不成功而软性调度相对温和属于倾向性优先选择满足条件的节点并不强求。 让我们来看两个示例加深理解 示例 1我有一个机器学习的应用必须调度到集群中带有 hardware-type: gpu且区域 kubernetes.io/zone 的值为 cn-shenzhen-1 或 cn-shenzhen-2 标签的节点上。我们可以通过亲和性的硬性调度实现具体如下 apiVersion: apps/v1 kind: Deployment metadata:name: athena spec:replicas: 2selector:matchLabels:app: athenatemplate:metadata:labels:app: athenaspec:containers:- name: athenaimage: athena:2.0.0affinity:nodeAffinity:# 硬性调度节点必须满足所有条件才可以调度requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: hardware-type# 运算operator: Invalues:- gpu- key: kubernetes.io/zoneoperator: Invalues:- cn-shenzhen-1- cn-shenzhen-2 Operator 支持的运算符还有 Exists(key必须存在value可以是任意的) DoesNotExistkey不能存在 Inkey的value必须在提供的值列表中 NotInkey的value不能在提供的值列表中 Gtkey的value必须大于提供的值仅支持整数 Ltkey的value必须小于提供的值 示例 2我有一个机器学习的应用倾向于调度到集群中带有 hardware-type: gpu且区域 kubernetes.io/zone 的值为 cn-shenzhen-1 或 cn-shenzhen-2 标签的节点上。我们可以通过亲和性的软性调度实现如果不能满足条件他也会尝试去调度其他节点具体如下 apiVersion: apps/v1 kind: Deployment metadata:name: athena spec:replicas: 2selector:matchLabels:app: athenatemplate:metadata:labels:app: athenaspec:containers:- name: athenaimage: athena:2.0.0affinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:# 满足条件的节点会加分值支持1-100分数越高优先级越高# 不加的话满足条件的节点权重也为0不能保证其优先级。- weight: 1preference:matchExpressions:- key: hardware-type# 运算支持的运算符跟硬性调度一致operator: Invalues:- gpu- key: kubernetes.io/zoneoperator: Invalues:- cn-shenzhen-1- cn-shenzhen-2 Pod 亲和性podAffinity和反亲和性podAntiAffinity 顾名思义Pod 亲和性用来指定哪些 Pod 应该跟哪些 Pod 更加靠近而 Pod 反亲和性通常用来打散 Pod让某些 Pod 不在同一节点或区域同样也有“软性调度”PreferredDuringSchedulingIgnoreDuringExecution”和“硬性调度” RequiredDuringSchedulingIgnoredDuringExecution接下来我将用一个示例加深对 Pod 亲和性和反亲和性的理解 示例有两个微服务 zeus 和 athena 相互调用比较频繁他们都有两个副本出于提升效率和可用性考虑我想将 zeus 和 athena 的副本打散到两个不同的可用区zone并让他们的副本必须部署到同一个节点上假设 zeus 已经部署好了那 athena 的部署可以这样实现。 apiVersion: apps/v1 kind: Deployment metadata:name: athena spec:replicas: 2selector:matchLabels:app: athenatemplate:metadata:labels:app: athenaspec:containers:- name: athenaimage: athena:2.0.0affinity:# Pod亲和性podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchLabels:app: zeus# 拓扑键表示在相同主机上调度topologyKey: kubernetes.io/hostname# Pod反亲和性podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchLabels:app: athena# 拓扑键表示在不同区域上调度topologyKey: topology.kubernetes.io/zone 结 语 在文章开头我们提到如何借助调度策略来提升 K8s 集群的可用性相信看完全文的小伙伴都可以悟出其中奥妙我们可以将高计算、高内存的 Pod 调度到指定的节点避免影响关键服务运行另外为了保障微服务的高可用性我们通常会打散副本到不同的节点或者可用区。 本文首发SRE运维手记作者亦零一。 本文由博客一文多发平台 OpenWrite 发布