kubernetes_pod调度

最新推荐文章于 2025-07-02 19:35:51 发布
最新推荐文章于 2025-07-02 19:35:51 发布
阅读量424 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： kubernetes 文章标签： kubernetes 后端 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/hhhhhhhzp/article/details/118462743
本文深入探讨了Kubernetes中的Pod调度策略，包括定向调度（NodeName和NodeSelector）、亲和性调度（NodeAffinity、PodAffinity和PodAntiAffinity）以及污点和容忍机制。通过示例详细解析了各种配置项的使用，帮助读者理解如何根据需求控制Pod在集群中的部署位置，确保服务的稳定性和性能优化。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

目录

简介

在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式：

  • 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
  • 定向调度：NodeName、NodeSelector
  • 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
  • 污点（容忍）调度：Taints、Toleration

定向调度

概述：

定向调度，指的是利用在pod上声明nodeName或者nodeSelector，以此将Pod调度到期望的node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过pod运行失败而已。

NodeName

NodeName用于强制约束将Pod调度到指定的Name的Node节点上。这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。

spec:
  containers:
  - name: ... ...
    image: ... ...
  nodeName: node1 # 指定调度到node1节点上

NodeSelector

NodeSelector 用于将pod调度到添加了指定标签的node节点上。它是通过kubernetes 的 label-selector 机制实现的，也就是说，在pod创建之前，会由scheduler 使用 MatchNodeSelector 调度策略进行label匹配，找出目标node，然后将pod调度到目标节点，该匹配规则是强制约束。

spec:
  containers:
  - name: ... ...
    image: ... ...
  nodeSelector: 
    nodeenv: pro # 指定调度到具有nodeenv=pro标签的节点上

亲和性调度

概述：

上面两种定向调度的方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用Node列表也不行，这就限制了它的使用场景。

​ 基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活。

Affinity主要分为三类：

- nodeAffinity(node亲和性）: 以node为目标，解决pod可以调度到哪些node的问题

- podAffinity(pod亲和性) :  以pod为目标，解决pod可以和哪些已存在的pod部署在同一个拓扑域中的问题

- podAntiAffinity(pod反亲和性) :  以pod为目标，解决pod不能和哪些已存在pod部署在同一个拓扑域中的问题

关于亲和性与反亲和性使用场景的说明：

亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用的尽可能的靠近，这样可以减少因网络通信而带来的性能损耗。

反亲和性：当应用的采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个node上，这样可以提高服务的高可用性。

NodeAffinity

配置项：

pod.spec.affinity.nodeAffinity

  requiredDuringSchedulingIgnoredDuringExecution  Node节点必须满足指定的所有规则才可以，相当于硬限制
    nodeSelectorTerms  节点选择列表
      matchFields   按节点字段列出的节点选择器要求列表
      matchExpressions   按节点标签列出的节点选择器要求列表(推荐)
        key    键
        values 值
        operator 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
  preferredDuringSchedulingIgnoredDuringExecution 优先调度到满足指定的规则的Node，相当于软限制 (倾向)
    preference   一个节点选择器项，与相应的权重相关联
      matchFields   按节点字段列出的节点选择器要求列表
      matchExpressions   按节点标签列出的节点选择器要求列表(推荐)
        key    键
        values 值
        operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
	weight 倾向权重，在范围1-100。

关系符的使用说明:

- matchExpressions:
  - key: nodeenv              # 匹配存在标签的key为nodeenv的节点
    operator: Exists
  - key: nodeenv              # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点
    operator: In
    values: ["xxx","yyy"]
  - key: nodeenv              # 匹配标签的key为nodeenv,且value大于"xxx"的节点
    operator: Gt
    values: "xxx"

requiredDuringSchedulingIgnoredDuringExecution配置示例

... ...
spec:
  containers:
  - name: ... ...
    image: ... ...
  affinity:  #亲和性设置
    nodeAffinity: #设置node亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
        nodeSelectorTerms:
        - matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签
          - key: nodeenv
            operator: In
            values: ["xxx","yyy"]

preferredDuringSchedulingIgnoredDuringExecution配置示例

... ...
spec:
  containers:
  - name: ... ...
    image: ... ...
  affinity:  #亲和性设置
    nodeAffinity: #设置node亲和性
      preferredDuringSchedulingIgnoredDuringExecution: # 软限制
      - weight: 1
        preference:
          matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签(当前环境没有)
          - key: nodeenv
            operator: In
            values: ["xxx","yyy"]

NodeAffinity规则设置的注意事项：

1 如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能运行在指定的Node上
2 如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可
3 如果一个nodeSelectorTerms中有多个matchExpressions ，则一个节点必须满足所有的才能匹配成功
4 如果一个pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的节点亲和性需求，则系统将忽略此变化

PodAffinity

PodAffinity主要实现以运行的Pod为参照，实现让新创建的Pod跟参照pod在一个区域的功能。

配置项：

pod.spec.affinity.podAffinity

  requiredDuringSchedulingIgnoredDuringExecution  硬限制
    namespaces       指定参照pod的namespace
    topologyKey      指定调度作用域
    labelSelector    标签选择器
      matchExpressions  按节点标签列出的节点选择器要求列表(推荐)
        key    键
        values 值
        operator 关系符 支持In, NotIn, Exists, DoesNotExist.
      matchLabels    指多个matchExpressions映射的内容
  preferredDuringSchedulingIgnoredDuringExecution 软限制
    podAffinityTerm  选项
      namespaces      
      topologyKey
      labelSelector
        matchExpressions  
          key    键
          values 值
          operator
        matchLabels 
    weight 倾向权重，在范围1-100


topologyKey用于指定调度时作用域,例如:
    如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围
	如果指定为beta.kubernetes.io/os,则以Node节点的操作系统类型来区分

requiredDuringSchedulingIgnoredDuringExecution配置示例

... ...
spec:
  containers:
  - name: ... ...
    image: ... ...
  affinity:  #亲和性设置
    podAffinity: #设置pod亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
      - labelSelector:
          matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签
          - key: podenv
            operator: In
            values: ["xxx","yyy"]
        topologyKey: kubernetes.io/hostname

上面配置表达的意思是：新Pod必须要与拥有标签nodeenv=xxx或者nodeenv=yyy的pod在同一Node上

preferredDuringSchedulingIgnoredDuringExecution配置示例

... ...
spec:
  containers:
  - name: ... ...
    image: ... ...
  affinity:  #亲和性设置
    podAffinity: #设置pod亲和性
      preferredDuringSchedulingIgnoredDuringExecution: # 软限制
      	- weight: 1
      	  podAffinityTerm:
	      - labelSelector:
	          matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签
	          - key: podenv
	            operator: In
	            values: ["xxx","yyy"]
	        topologyKey: kubernetes.io/hostname

PodAntiAffinity

PodAntiAffinity主要实现以运行的Pod为参照，让新创建的Pod跟参照pod不在一个区域中的功能。

它的配置方式和选项跟PodAffinty是一样的

... ...
spec:
  containers:
  - name: ... ...
    image: ... ...
  affinity:  #亲和性设置
    podAntiAffinity: #设置pod亲和性
      requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
      - labelSelector:
          matchExpressions: # 匹配podenv的值在["xxx"]中的标签
          - key: podenv
            operator: In
            values: ["xxx"]
        topologyKey: kubernetes.io/hostname

污点和容忍

污点：

前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否允许Pod调度过来。

​ Node被设置上污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。

污点的格式为：key=value:effect, key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

- PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
- NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
- NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离

在这里插入图片描述

使用kubectl设置和去除污点的命令示例如下：

# 设置污点
kubectl taint nodes node1 key=value:effect

# 去除污点
kubectl taint nodes node1 key:effect-

# 去除所有污点
kubectl taint nodes node1 key-

容忍（Toleration）：

上面介绍了污点的作用，我们可以在node上添加污点用于拒绝pod调度上来，但是如果就是想将一个pod调度到一个有污点的node上去，这时候应该怎么做呢？这就要使用到容忍。

在这里插入图片描述

污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝

配置示例：

spec:
  containers:
  - name: ... ...
    image: ... ...
  tolerations:      # 添加容忍
  - key: "tag"        # 要容忍的污点的key
    operator: "Equal" # 操作符
    value: "heima"    # 容忍的污点的value
    effect: "NoExecute"   # 添加容忍的规则，这里必须和标记的污点规则相同

容忍的详细配置

[root@master ~]# kubectl explain pod.spec.tolerations
......
FIELDS:
   key       # 对应着要容忍的污点的键，空意味着匹配所有的键
   value     # 对应着要容忍的污点的值
   operator  # key-value的运算符，支持Equal和Exists（默认）
   effect    # 对应污点的effect，空意味着匹配所有影响
   tolerationSeconds   # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间
Kubernetes之pod的调度
qq_63627848的博客
08-12 778
pod的几种调度方式
运维锅总详解Kubernetes之Pod
专注于输出大概有用的软硬件技术！
07-18 1052
如何更好的使用好Pod？本文尝试从Pod组成、Namespace共享、控制器实现原理及Pod设计原则4个方面对Pod的使用进行详细阐述，希望对您理解Pod有所帮助！一、 Kubernetes Pod介绍在 Kubernetes 中，Pod 是最小的可部署单元，包含一个或多个容器。Pod 提供容器共享的存储、网络以及如何运行的描述。以下是对 Kubernetes Pod 的详细介绍，包括其组成部分、...
研发工程师玩转Kubernetes——使用污点（taint）驱逐Pod
方亮的专栏
06-09 1259
在中，有一次Pod被分配到Master Node——UbuntuA上。进一步的实验需要我们关闭其所在的Node，而Master Node又不能关闭，否则我们将无法对Kubernetes进行操作。这个时候我只能使用Pod调度技法来将其从Master Node上驱逐。
读书笔记-k8s之亲和性调度
sailor_q的博客
06-05 2786
亲和性调度功能包括节点亲和性（NodeAffinity)和Pod亲和性（PodAffinity）两个维度的设置。 NodeAffinity：Node亲和性调度 NodeAffinity意为Node亲和性的调度策略，是用于替换NodeSelector的全新调度策略，目前有两种节点亲和性表达。 RequireDuringSchedulingIgnoredDuringExecution：必须满足指定的规则才可以调度Pod到Node上（功能与NodeSelector很像，但是使用的是不同的语法），相当于硬限制
preferredDuringSchedulingIgnoredDuringExecution
最新发布
喝醉酒的小白
07-02 733
项目说明触发节点所有通过 Filter 的节点打分范围每插件对每节点 0~100插件权重每个插件可配置 weight分数合并加权求和结果选出得分最高节点，打平时随机选择用户可控性通过 kube-scheduler config 定义如果你希望我列出每个默认插件的实现原理和打分逻辑，我可以继续展开，或者帮你写个调度器插件打分日志追踪脚本。是否需要？项目内容类型是软约束生效阶段只在调度阶段生效，调度后就不再影响调度器行为是否强制❌ 否；节点可以不满足条件，但得分会降低。
研发工程师玩转Kubernetes——Node亲和性requiredDuringSchedulingIgnoredDuringExecution几种边界实验
方亮的专栏
06-09 2428
requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions之间是取或的关系，即只要满足其中一个条件就可以被调度到。没有匹配的条件，Pod会被创建，但是处于Pending状态，不会被部署到任何一个Node上。如果Pod已经在Node上运行，此时删除Node匹配上的Label，Deployment不会终止该Pod。
Kubernetes Pod亲和性调度(NodeAffinity)
tom的博客
02-23 817
NodeAffinity意为Node 亲和性的调度策略，是用于替换NodeSelector 的全新调度策略。目前有两种节点亲和性表达。 （1）RequiredDuringSchedulingIgnoredDuringExecution: 必须满足指定的规则才可以调度Pod 到Node 上（功能与nodeSelector很像，但是使用的是不同的语法），相当于硬限制。 （2）PreferredDuringSchedulingIgnoredDuringExecution: 强调优先满足指定规则，调度器会尝试调度P
K8S-亲和性
weixin_61269220的博客
10-13 4440
亲和度详说
Kubernetes工作坊_kubernetes实践_Kubernetes_
10-01
Master节点负责整个集群的管理和控制，包括API服务器、etcd（持久化数据存储）、调度器和控制器。Worker节点则执行实际的工作负载，它们运行Pods并与其通信。这种分离式的架构使得系统可扩展且高可用。 **三、核心...
Kubernetes中Pod调度失败的报错与解决
shejizuopin的博客
06-13 920
摘要：Kubernetes中Pod调度失败是常见运维问题，主要类型包括资源不足、节点标签不匹配、节点污点和网络问题。本文结合CSDN技术社区的实战案例，详细分析了各类故障的表现特征（如Pod处于Pending状态）、产生原因及解决方案（资源调整、标签修改、污点处理等），并提供了实用的排查步骤和常见问题对照表，最后总结了日志优先、资源检查等系统化解决方法，有助于提升集群稳定性与资源利用率。（149字）
CIS_Kubernetes_V1.20_Benchmark_v1.0.0_PDF.pdf
08-04
同样的，控制器管理器（controller manager）、调度器（scheduler）、etcd的pod规范文件和配置文件，以及容器网络接口文件的权限和所有权配置也被包含在基准配置中。其中特别强调了etcd数据目录的权限设置要限制到...
k8s-高级调度-污点容忍、亲和性调度
咕噜咕噜wy的博客
01-19 1355
如果 Pod 设置了与节点上的污点匹配的容忍规则，那么该 Pod 就可以被调度到具有该污点的节点上。亲和性调度在NodeSelector的基础之上的进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活。上面配置表达的意思是：新Pod必须要与拥有标签nodeenv=xxx或者nodeenv=yyy的pod在同一Node上，显然现在没有这样pod，接下来，运行测试一下。
kubernetes视频教程笔记 （26）-集群调度-节点亲和性
软件工程小施同学 的专栏
12-07 606
一、节点亲和性 1. pod.spec.nodeAffinity preferredDuringSchedulingIgnoredDuringExecution：软策略 requiredDuringSchedulingIgnoredDuringExecution：硬策略 2. requiredDuringSchedulingIgnoredDuringExecution apiVersion: v1 kind: Pod metadata: name: affinity labels:...
完事后再聊应用场景，K8S调度实战：Node Affinity
ttropsstack的博客
06-21 337
Node Affinity有两种策略：requiredDuringSchedulingIgnoredDuringExecution：调度器只有在规则被满足的时候才能执行调度（硬策略）preferredDuringSchedulingIgnoredDuringExecution：调度器会尝试寻找满足对应规则的节点。
k8s-集群调度
mdzz971209的博客
04-14 363
节点亲和度 键值运算关系 In： label的值在某个列表中 NotIn： label的值不在某个列表中 Gt： label的值大于某个值 Lt： label的值小于某个值 Exists：某个label存在 DoesNotExist： 某个label不存在 pod.spec.nodeAffinity preferredDuringSchedulingIgnoredDuringExecution: 软策略 requiredDuringSchedulingIgnoredDuringExecution: 硬
k8s入门系列---- Node Affinity--use
justlpf的专栏
08-17 584
K8S 跟POD调度相关的三个概念：Node Affinity（节点亲和性），Taints（污点），Tolerations（容忍度），这节先讲下Node Affinity（节点亲和性）。Affinity中文意思 ”亲和性” ，跟nodeSelect 类似，根据节点上的标签来调度 POD 在哪些节点上创建。硬策略表示POD 必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。
POD的调度
qq_45335806的博客
07-24 396
POD亲和性的引入 在真实的生产环境中还存在如下所述的特殊需求 不同Pod之间的亲和性（Affinity）：比如MySQL数据库与 Redis中间件不能被调度到同一个目标节点上，或者两种不同的Pod必须 被调度到同一个Node上，以实现本地文件共享或本地网络通信等特殊需 求，这就是PodAffinity要解决的问题 在每个Node上调度并且仅仅创建一个Pod副本。这种调度通 常用于系统监控相关的Pod，比如主机上的日志采集、主机性能采集等 进程需要被部署到集群中的每个节点，并且只能部署一个副本，这就是
k8s创建pod-affinity亲和性时报错解决办法
qq_17576885的博客
10-23 1257
问题报错说明spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.labelSelector.matchExpressions.values这里格式错误，查看该字段用法。可以将values字段值改为下面两个形式都可以，测试都能创建pod成功running。values是字符串值的数组。
k8s的亲和性设置，指定节点，分散部署pod，捆绑部署pod
u013595395的博客
03-14 8317
前言： 亲和性是affinity，分为两种 -- 强制：requiredDuringSchedulingIgnoredDuringExecution -- 参考：preferredDuringSchedulingIgnoredDuringExecution //也就第一个词不同了，IgnoredDuringExecution的意思是：部署完了就不再管这些规则。比如部署后我把node的标签改了导致不满足规则了，会重新调度吗？不会，根本不去检测变化。 一、指定节点 1.强制指定 （1...
command failed" err="unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined
03-21
<think>好的，我现在需要帮用户解决关于Kubernetes中出现的错误信息：“command failed" err="unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined”。用户之前询问过cgroupDriver的问题，现在遇到了另一个Kubernetes相关错误。首先，我得确定这个错误的具体原因和解决方法。 首先，这个错误通常发生在应用程序或服务尝试在Kubernetes集群内部运行时，无法正确加载集群内的配置。根据错误信息，关键点在于环境变量KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT没有被定义。这两个变量是Kubernetes自动为Pod设置的，用于指向API服务器。所以，如果它们不存在，说明Pod可能没有运行在Kubernetes集群中，或者配置有问题。 接下来，我需要考虑用户可能遇到的情况。用户可能在本地运行了一个本应运行在集群中的程序，或者他们的Pod配置有问题，比如没有正确设置Service Account或RBAC权限。另外，用户可能在测试环境中没有正确模拟集群环境，导致这些变量缺失。 然后，我需要分步骤分析可能的原因和解决方案： 1. **确认运行环境**：用户是否在Kubernetes Pod中运行该程序？如果不是，比如本地调试时，可能需要使用kubeconfig文件而不是集群内配置。 2. **检查Service Account**：如果确实在集群中运行，检查Pod的Service Account是否正确配置，是否有权限访问API服务器。可能需要查看Pod的YAML文件，确保自动挂载Service Account Token被启用。 3. **检查环境变量**：在Pod内部执行命令查看环境变量是否存在。可以通过kubectl exec进入Pod，然后运行env | grep KUBERNETES来确认。 4. **验证API服务器可达性**：即使环境变量存在，API服务器可能无法访问，可能是网络策略或服务端点的问题。 5. **RBAC权限问题**：如果Service Account没有足够的权限，即使环境变量正确，也会出现连接问题。需要检查相关的Role和RoleBinding。 接下来，我需要将这些思路整理成结构化的回答，帮助用户逐步排查问题。同时，需要提供具体的命令和配置示例，让用户能够实际操作。例如，如何检查环境变量，如何配置Service Account，以及如何在本地使用kubeconfig等。 另外，用户之前询问过cgroupDriver的问题，可能是在部署Kubernetes集群时遇到了问题，现在又在运行应用时遇到配置错误，可能需要提醒用户检查集群的整体配置，尤其是Pod的配置是否正确，确保各个组件（如kubelet、容器运行时）的配置一致。 最后，确保回答清晰易懂，分步骤说明可能的原因和解决方法，并给出示例命令，帮助用户快速定位和解决问题。</think>--- ### 错误解析：`unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined` 该错误表示应用程序尝试在 Kubernetes 集群内部运行（In-Cluster模式）时，无法加载集群配置。核心原因是缺失关键环境变量 `KUBERNETES_SERVICE_HOST` 和 `KUBERNETES_SERVICE_PORT`，这两个变量由 Kubernetes 自动注入到 Pod 中，用于定位 API 服务器。以下是详细分析和解决方案： --- ### 一、根本原因 1. **非集群环境运行** 应用程序未在 Kubernetes Pod 中运行（例如本地调试时），导致 Kubernetes 未注入必要的环境变量。 2. **ServiceAccount 配置问题** Pod 的 ServiceAccount 未正确配置，或未启用自动挂载 Token（`automountServiceAccountToken: false`）。 3. **API 服务器访问异常** 即使环境变量存在，API 服务器不可达（网络策略、DNS 解析或服务端点错误）。 --- ### 二、解决方案分步指南 #### 场景 1：本地调试（非集群环境） 当在集群外运行需要访问 Kubernetes API 的代码时： ```bash # 需显式指定 kubeconfig 文件路径 export KUBECONFIG=/path/to/your/kubeconfig ``` 代码中需显式加载外置配置（以 Go 客户端为例）： ```go import "k8s.io/client-go/tools/clientcmd" config, _ := clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig") ``` --- #### 场景 2：修复集群内运行配置（Pod 内部问题） ##### 步骤 1：验证环境变量存在性 进入 Pod 执行检查： ```bash kubectl exec -it <pod-name> -- env | grep KUBERNETES_SERVICE ``` 正常输出应包含： ``` KUBERNETES_SERVICE_HOST=10.96.0.1 KUBERNETES_SERVICE_PORT=443 ``` ##### 步骤 2：检查 ServiceAccount 配置 确认 Pod 配置启用了 ServiceAccount： ```yaml # pod.yaml 示例 apiVersion: v1 kind: Pod metadata: name: myapp spec: serviceAccountName: default # 必须指定有效账户 automountServiceAccountToken: true # 必须为true（默认值） ``` ##### 步骤 3：验证 API 服务器连通性 在 Pod 内执行 API 访问测试： ```bash kubectl exec -it <pod-name> -- sh curl -k https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api/v1/namespaces/default/pods # 若返回 401 Unauthorized，说明网络可达但权限不足 # 若连接超时，检查网络策略或 Calico/Flannel 插件状态 ``` ##### 步骤 4：修复 RBAC 权限 为 ServiceAccount 添加必要权限（示例）： ```yaml # role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] --- # rolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: ServiceAccount name: default namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ``` --- ### 三、特殊案例处理 #### 案例 1：使用自定义调度器 若使用非标准调度器，需确保其具有 `system:kube-scheduler` 权限： ```bash kubectl create clusterrolebinding custom-scheduler \ --clusterrole=system:kube-scheduler \ --user=system:serviceaccount:kube-system:custom-scheduler ``` #### 案例 2：Istio 服务网格冲突 当启用 Istio 自动 Sidecar 注入时，可能拦截 API 请求： ```yaml # 在 Pod 注解中禁用特定端口的劫持 annotations: traffic.sidecar.istio.io/excludeOutboundPorts: "443" ``` --- ### 四、预防措施 1. **准入控制检查** 使用 `ValidatingWebhook` 确保所有 Pod 都配置了有效 ServiceAccount： ```yaml # webhook-config.yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration webhooks: - name: check-serviceaccount rules: [{"apiGroups": [""], "apiVersions": ["v1"], "resources": ["pods"]}] ``` 2. **集群健康监控** 部署 Prometheus 监控关键指标： ```promql # 监控 API 服务器不可用情况 sum(apiserver_request_total{code=~"5.."}) by (verb, resource) ``` --- ### 五、深度原理说明 Kubernetes 通过以下机制注入环境变量： 1. Pod 创建时，kubelet 会向 API 服务器查询 `kubernetes` 服务的 ClusterIP 和端口 2. 将结果写入 Pod 的环境变量： ```bash KUBERNETES_SERVICE_HOST=10.96.0.1 # ClusterIP KUBERNETES_SERVICE_PORT=443 # HTTPS 端口 ``` 3. 应用程序使用 `client-go` 库时，默认优先使用 In-Cluster 配置： ```go rest.InClusterConfig() // 依赖上述环境变量 ``` --- **最终验证流程**： ```bash # 1. 确认环境变量存在 kubectl exec <pod> -- printenv | grep KUBERNETES # 2. 检查 API 服务器可达性 kubectl exec <pod> -- curl -k https://$KUBERNETES_SERVICE_HOST/healthz # 3. 验证 RBAC 权限 kubectl auth can-i list pods --as system:serviceaccount:<namespace>:<serviceaccount> ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

屎到淋头还嚼便

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值