【k8s应用管理】kubernetes 群集调度管理网站首页 其他

【k8s应用管理】kubernetes 群集调度管理

Karoku066 2025-02-11 00:01:02

简介【k8s应用管理】kubernetes 群集调度管理

文章目录

Kubernetes 群集调度管理

Kubernetes 群集调度管理

Kubernetes Pod 创建过程及组件协作

组件初始化与监听
- Controller Manager、Scheduler 和 kubelet 在启动时开始监听（Watch）APIServer 发出的事件。
- 这些组件通过 HTTPS 的 6443 端口与 APIServer 通信。
用户提交请求
- 用户通过 kubectl 或其他 API 客户端向 APIServer 提交请求，创建一个 Pod 对象副本。
APIServer 存储与反馈
- APIServer 尝试将 Pod 对象的相关元信息存入 etcd。
- 写入操作完成后，APIServer 返回确认信息至客户端。
etcd 发送 Create 事件
- etcd 接受创建 Pod 信息后，发送一个 Create 事件给 APIServer。
Controller Manager 处理 Create 事件
- Controller Manager 监听到 Create 事件后，调用 Replication Controller（RC）确保 Node 上需要创建的副本数量。
- RC 根据定义的副本数量自动创建或删除副本。
APIServer 更新 Pod 信息
- APIServer 在 etcd 中记录 Pod 的详细信息，如副本数、容器内容等。
- etcd 将更新信息通过事件发送给 APIServer。
Scheduler 调度 Pod
- Scheduler 监听到 Pod 创建事件后，根据调度算法和策略将 Pod 绑定到集群中的某个 Node 上。
- Scheduler 更新 Pod 信息至 APIServer，由 APIServer 更新至 etcd。
APIServer 反映调度结果
- etcd 将调度成功的事件发送给 APIServer。
- APIServer 开始反映此 Pod 对象的调度结果。
kubelet 启动容器
- kubelet 监听到 Pod 更新事件后，在当前 Node 上调用 Docker 启动容器。
- kubelet 将 Pod 及容器的状态回送至 APIServer。
APIServer 存储状态信息
- APIServer 将 Pod 状态信息存入 etcd。
- etcd 确认写入操作成功后，APIServer 将确认信息发送至相关的 kubelet。

Kubernetes 调度过程

Kubernetes 的调度器（Scheduler）负责将定义的 Pod 分配到集群的节点上。调度过程主要关注公平性、资源高效利用、效率和灵活性。调度器运行为一个独立的程序，持续监听 APIServer，并处理 spec.nodeName 为空的 Pod。
调度过程分为以下几个步骤：

Predicate（过滤阶段）：
- 调度器首先会过滤掉不满足条件的节点。
- 常见的 Predicate 算法包括：PodFitsResources（检查节点资源是否足够）、PodFitsHost（检查节点名称是否与 Pod 指定的 NodeName 匹配）、PodFitsHostPorts（检查节点端口是否与 Pod 请求的端口冲突）、PodSelectorMatches（过滤掉与 Pod 指定的 label 不匹配的节点）和 NoDiskConflict（检查已挂载的 volume 是否与 Pod 指定的 volume 冲突）。
Priorities（优选阶段）：
- 如果有多个节点满足条件，调度器会根据优先级对节点进行排序。
- 优先级由一系列键值对组成，表示不同的优先级项目和其权重。
- 常见的优先级选项包括：LeastRequestedPriority（倾向于资源使用比例更低的节点）、BalancedResourceAllocation（倾向于 CPU 和 Memory 使用率更接近的节点）和 ImageLocalityPriority（倾向于已经有要使用镜像的节点）。
Binding（绑定阶段）：
- 调度器选择优先级最高的节点，并创建一个 binding，表明该 Pod 应该被调度到哪个节点上。

Kubernetes Scheduler 工作原理

Scheduler 是 Kubernetes 的核心组件，负责将 Pod 分配到集群的合适节点上。其调度过程主要关注以下方面：

公平性：确保每个节点都能被分配资源。
资源高效利用：最大化集群资源的利用率。
效率：快速调度大批量的 Pod。
灵活性：允许用户根据需求自定义调度逻辑。

Scheduler 启动后会持续监听 APIServer，获取 spec.nodeName 为空的 Pod，并为每个 Pod 创建一个 binding，指明其应部署的节点。

调度流程

调度过程主要分为以下步骤：

Predicate（过滤）：首先排除不满足条件的节点。常见的 Predicate 算法包括检查节点资源是否充足、端口是否冲突、标签是否匹配等。
Priorities（优选）：对通过 Predicate 的节点按照优先级排序。优先级由一系列键值对组成，键是优先级项的名称，值是权重。常见的优先级选项有资源使用率、资源均衡度、镜像本地性等。
选择节点：从排序后的节点中选择优先级最高的节点作为 Pod 的部署节点。

指定调度节点的方式

pod.spec.nodeName：直接将 Pod 调度到指定的 Node 节点上，跳过 Scheduler 的调度策略。这种方式是强制匹配。
pod.spec.nodeSelector：通过 Kubernetes 的 label-selector 机制选择节点。Scheduler 会根据 Pod 的 nodeSelector 和节点的标签进行匹配，然后将 Pod 调度到目标节点。这种方式属于强制约束。

示例操作

使用 nodeName 指定调度节点

创建一个 Deployment，指定 nodeName 为 node01。
应用 YAML 文件后，所有 Pod 都会被调度到 node01 上。
通过 kubectl describe pod 查看 Pod 事件，发现未经过 Scheduler 调度分配。

使用 pod.spec.nodeName：

通过在 Pod 定义中指定 nodeName，可以直接将 Pod 调度到指定的节点上，这会跳过调度器的调度策略。

示例 YAML 配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      nodeName: node01
      containers:
      - name: myapp
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80

应用此配置后，Pod 会被调度到 node01 上。

使用 nodeSelector 指定调度节点

给节点 node01 和 node02 分别设置标签 myname=a 和 myname=b。
创建一个 Deployment，指定 nodeSelector 为 myname=a。
应用 YAML 文件后，所有 Pod 都会被调度到标签为 myname=a 的节点上（即 node01）。
通过 kubectl describe pod 查看 Pod 事件，发现先经过 Scheduler 调度分配。

使用 pod.spec.nodeSelector：

通过为节点和 Pod 设置 label，并使用 nodeSelector 选择具有特定 label 的节点，调度器会将 Pod 调度到匹配的节点上。

为节点设置 label 的命令如下：

kubectl label nodes node01 myname=a
kubectl label nodes node02 myname=b

在 Pod 定义中使用 nodeSelector 的 YAML 配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp1
  template:
    metadata:
      labels:
        app: myapp1
    spec:
      nodeSelector:
        myname: a
      containers:
      - name: myapp1
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80

应用此配置后，Pod 会被调度到具有 label myname=a 的节点上（即 node01）。

修改和删除Label

使用 kubectl label 命令修改和删除节点标签。
修改节点的 label 需要使用 --overwrite 参数：
```
kubectl label nodes node02 myname=a --overwrite
```
删除节点的 label 只需在命令行最后指定 label 的 key 名，并在其后加上减号：
```
kubectl label nodes node02 myname-
```
可以使用 -l 参数根据 label 查询节点：
```
kubectl get node -l myname=a
```

亲和性

亲和性概述

在 Kubernetes 中，亲和性（Affinity）和反亲和性（Anti-Affinity）用于定义 Pod 调度到节点的规则。主要分为两类：

节点亲和性（Node Affinity）：定义 Pod 与节点的关系。
Pod 亲和性（Pod Affinity）和Pod 反亲和性（Pod Anti-Affinity）：定义 Pod 与 Pod 之间的关系。

每种亲和性都可以进一步细分为硬策略和软策略：

硬策略（requiredDuringSchedulingIgnoredDuringExecution）：必须满足的条件，不满足则 Pod 无法调度。
软策略（preferredDuringSchedulingIgnoredDuringExecution）：优先满足的条件，不满足时仍会调度 Pod，但会尽量满足。

键值运算关系

在定义亲和性规则时，可以使用以下键值运算关系：

In：label 的值在某个列表中。
NotIn：label 的值不在某个列表中。
Gt：label 的值大于某个值（数值比较）。
Lt：label 的值小于某个值（数值比较）。
Exists：某个 label 存在。
DoesNotExist：某个 label 不存在。

示例

通过 YAML 文件定义 Pod 亲和性的

节点亲和性硬策略

apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - node02

可见该文件中定义了一个 Pod，要求该Pod调度到 kubernetes.io/hostname 不为 node02 的节点上。
如果所有节点都不满足条件，Pod 将一直处于 Pending 状态。

节点亲和性软策略

apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - node01

这个文件中定义了的Pod，被优先调度到 kubernetes.io/hostname 为 node01 的节点上。
但不满足时也会调度到其他节点。

硬策略和软策略结合

apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - node02
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: myname
            operator: In
            values:
            - a

这个文件定义的 Pod，首先要求调度到 kubernetes.io/hostname 不为 node02 的节点上，然后在满足硬策略的基础上，优先调度到 myname 为 a 的节点上。

Pod亲和性与反亲和性

Pod 亲和性（Pod Affinity）和反亲和性（Pod Anti-Affinity）是用于定义 Pod 调度策略的两种机制。
可以使 Pod 可以根据其他 Pod 的标签和位置来决定自己的调度位置。

调度策略与匹配标签

nodeAffinity：基于节点的标签进行调度。不支持拓扑域。
podAffinity：基于其他 Pod 的标签进行调度，并支持拓扑域。
podAntiAffinity：基于其他 Pod 的标签进行调度，但要求不在同一拓扑域。

操作符与拓扑域支持

操作符：In, NotIn, Exists, DoesNotExist, Gt, Lt（对于 nodeAffinity 的特定场景）。
拓扑域支持：podAffinity 和 podAntiAffinity 支持拓扑域，通过 topologyKey 指定。

示例

给节点打标签：

kubectl label nodes node01 myname=a
kubectl label nodes node02 myname=a

创建第一个 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: myapp01
  labels:
    app: myapp01
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1

kubectl apply -f pod3.yaml

使用 Pod 亲和性调度第二个 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: myapp02
  labels:
    app: myapp02
spec:
  containers:
  - name: myapp02
    image: soscscs/myapp:v1
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - myapp01
        topologyKey: myname

kubectl apply -f pod4.yaml

myapp02 将被调度到与 myapp01 相同的拓扑域（myname=a 的节点）上。

使用 Pod 反亲和性调度第三个 Pod：

示例 1：首选调度（Preferred）

apiVersion: v1
kind: Pod
metadata:
  name: myapp10
  labels:
    app: myapp10
spec:
  containers:
  - name: myapp10
    image: soscscs/myapp:v1
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - myapp01
          topologyKey: kubernetes.io/hostname

kubectl apply -f pod5.yaml

myapp10 将尽量避免与 myapp01 在同一节点上调度（kubernetes.io/hostname 表示节点级别）。

示例 2：强制调度（Required）

apiVersion: v1
kind: Pod
metadata:
  name: myapp20
  labels:
    app: myapp20
spec:
  containers:
  - name: myapp20
    image: soscscs/myapp:v1
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - myapp01
        topologyKey: myname

kubectl apply -f pod6.yaml

myapp20 强制要求不在与 myapp01 相同的拓扑域上调度。如果所有节点都在同一拓扑域，Pod 将保持 Pending 状态。

调整节点标签以允许调度：
```
kubectl label nodes node02 myname=b --overwrite
```
- 修改 node02 的标签后，myapp20 可以被调度到 node02 上，因为它现在处于不同的拓扑域。

总结

三种亲和性类型

类型	定义	策略
Node Affinity	根据节点的标签，将 Pod 调度到满足条件的节点上。	- 硬策略 (`requiredDuringSchedulingIgnoredDuringExecution`)：必须满足条件，否则 Pod 处于 Pending 状态。 - 软策略 (`preferredDuringSchedulingIgnoredDuringExecution`)：优先满足条件，不满足仍可调度。
Pod Affinity	根据同一命名空间下其他 Pod 的标签，将 Pod 调度到与指定 Pod 在同一拓扑域的节点上。	- 硬策略：必须与指定 Pod 在同一拓扑域。 - 软策略：优先与指定 Pod 在同一拓扑域。
Pod Anti-Affinity	根据同一命名空间下其他 Pod 的标签，将 Pod 调度到与指定 Pod 不同拓扑域的节点上。	- 硬策略：必须与指定 Pod 在不同拓扑域。 - 软策略：优先与指定 Pod 在不同拓扑域。

拓扑域判断规则

亲和性类型	规则	`topologyKey` 作用	示例 `topologyKey` 值
Pod Affinity	Pod 必须或优先调度到与目标 Pod 同一拓扑域的节点上。	通过节点标签的键（如 `kubernetes.io/hostname`）判断是否属于同一逻辑域（如同一主机、可用区）。	- `kubernetes.io/hostname`（节点主机名） - `failure-domain.beta.kubernetes.io/zone`（可用区）
Pod Anti-Affinity	Pod 必须或优先调度到与目标 Pod 不同拓扑域的节点上。	通过节点标签的键确定逻辑域，确保 Pod 分布在不同域中以提高容灾能力。	- `kubernetes.io/hostname` - `topology.kubernetes.io/region`（区域）
Node Affinity	不依赖 `topologyKey`，直接通过节点标签匹配调度。	无	无

**关键说明 **

topologyKey 的作用：

用于定义节点的逻辑分组（如主机、机架、可用区）。
若多个节点的 topologyKey 标签值相同，则视为同一拓扑域。

示例场景：

同一主机：topologyKey: kubernetes.io/hostname
同一可用区：topologyKey: failure-domain.beta.kubernetes.io/zone
同一区域：topologyKey: topology.kubernetes.io/region

应用场景：

亲和性：确保服务副本分布在相同拓扑域（如 Web 应用与缓存服务部署在同一可用区）。
反亲和性：避免单点故障（如数据库主从节点分布在不同主机或可用区）。

污点（Taint）与容忍（Toleration）

1. 污点（Taint）

污点是节点的属性，用于排斥一类特定的 Pod。
通过污点，可以避免 Pod 被调度到不合适的节点上。

污点组成：

key=value:effect

key：污点的键。
value：污点的值（可为空）。
effect：污点的作用效果。

污点效果（effect）：

效果	描述
NoSchedule	不会将 Pod 调度到具有该污点的节点上。
PreferNoSchedule	尽量避免将 Pod 调度到具有该污点的节点上。
NoExecute	不会将 Pod 调度到具有该污点的节点上，并驱逐节点上已有的 Pod。

操作命令：

设置污点：

kubectl taint node <节点名称> <污点key>=<value>:<effect>

示例：

kubectl taint node node01 key1=value1:NoSchedule

查看污点：

kubectl describe node <node-name>
kubectl describe nodes <节点名称> | grep -A 5 Taints

删除污点：

kubectl taint node <节点名称> <污点key>:<effect>-

示例：

kubectl taint node node01 key1:NoSchedule-

容忍（Toleration）

容忍是 Pod 的属性，允许 Pod 被调度到具有匹配污点的节点上。

容忍配置：
在 Pod 的 YAML 文件中的 spec.tolerations 字段进行配置：

spec:
  tolerations:
  - operator: Equal|Exists
    key: <污点key>
    value: <污点value>
    effect: NoSchedule|PreferNoSchedule|NoExecute
	tolerationSeconds: 3600

字段说明：

字段	描述
key	污点的键，需与节点污点一致。
operator	匹配操作符，`Equal`（值相等）或 `Exists`（存在即可，忽略值）。
value	污点的值（`operator` 为 `Equal` 时需指定）。
effect	污点的效果，需与节点污点一致。
tolerationSeconds	Pod 被驱逐前可在节点上继续运行的时间（仅对 `NoExecute` 有效）。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: myapp01
  labels:
    app: myapp01
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  tolerations:
  - key: "check"
    operator: "Equal"
    value: "mycheck"
    effect: "NoExecute"
    tolerationSeconds: 3600

应用场景

专用节点：
- 为某些节点设置污点，确保只有特定 Pod 可以调度到这些节点。
- 示例：GPU 节点仅运行需要 GPU 的任务。
节点维护：
- 设置 NoExecute 污点，驱逐节点上的 Pod 以便维护。
高可用部署：
- 使用 NoSchedule 或 PreferNoSchedule，确保 Pod 分散在不同节点上。

示例

设置污点：

kubectl taint node node01 check=mycheck:NoExecute

查看污点：
```
kubectl describe node node01
```

创建容忍 Pod：

kubectl apply -f pod-with-toleration.yaml

验证 Pod 调度：
```
kubectl get pods -o wide
```

其它相关

污点（Taints）注意事项

容忍所有污点 key
- 当不指定 key 值时，使用 Exists 操作符可以容忍节点上的所有污点 key。
```
tolerations:
- operator: "Exists"
```
容忍所有污点作用
- 当不指定 effect 值时，只要污点的 key 匹配，无论其作用（如 NoSchedule, PreferNoSchedule, NoExecute）是什么，都会被容忍。
```
tolerations:
- key: "key"
  operator: "Exists"
```
多 Master 节点设置
- 在有多个 Master 节点的情况下，为了避免资源浪费，可以将 Master 节点设置为 PreferNoSchedule，这样默认情况下不会调度 Pod 到 Master 节点，但在必要时可以调度。
```
kubectl taint node Master-Name node-role.kubernetes.io/master=:PreferNoSchedule
```

污点应用实例

设置 NoExecute 污点
- 当某个 Node 需要更新升级系统组件时，可以先在该 Node 上设置 NoExecute 污点，以驱逐该 Node 上的所有 Pod。
```
kubectl taint node node01 check=mycheck:NoExecute
```
临时设置 PreferNoSchedule 污点
- 如果其他 Node 资源不足，可以临时将 Master 节点设置为 PreferNoSchedule，允许在必要时调度 Pod 到 Master 节点。
```
kubectl taint node master node-role.kubernetes.io/master=:PreferNoSchedule --overwrite
```
移除污点
- 更新操作完成后，移除之前设置的污点。
```
kubectl taint node node01 check=mycheck:NoExecute-  
```

节点维护操作

查看节点
- 使用 kubectl get nodes 查看集群中的所有节点。
标记节点为不可调度
- 使用 kubectl cordon <NODE_NAME> 将节点标记为不可调度状态，防止新创建的 Pod 调度到此节点。
```
kubectl cordon <NODE_NAME>
```
驱逐节点上的 Pod
- 使用 kubectl drain <NODE_NAME> 命令驱逐节点上的所有 Pod，并设置节点为不可调度状态。
```
kubectl drain <NODE_NAME> --ignore-daemonsets --delete-emptydir-data --force
```
- 参数解释：
  - --ignore-daemonsets：忽略 DaemonSet 管理的 Pod。
  - --delete-emptydir-data：强制删除挂载了本地卷的 Pod。
  - --force：强制驱逐非控制器管理的 Pod。
标记节点为可调度
- 使用 kubectl uncordon <NODE_NAME> 将节点标记为可调度状态，允许新 Pod 调度到此节点。
```
kubectl uncordon <NODE_NAME>
```

Kubernetes Pod 启动与生命周期

Pod 启动过程

控制器创建 Pod 副本：由 controller-manager 管理的控制器根据定义创建 Pod 副本。
调度 Pod：scheduler 根据调度算法选择最合适的 node 节点调度 Pod。
挂载存储卷：kubelet 在目标节点上挂载 Pod 所需的存储卷。
拉取镜像：kubelet 从配置的镜像仓库拉取 Pod 所需的容器镜像。
创建并运行容器：kubelet 调用容器运行时（如 Docker 或 containerd）创建并运行容器。
设置 Pod 状态：kubelet 根据容器探针（如 liveness 和 readiness 探针）的探测结果设置 Pod 的状态。

Pod 生命周期状态

Pending：Pod 已创建但尚未完成调度、镜像拉取或存储卷挂载。
Running：Pod 的所有容器都已被创建，且至少有一个容器正在运行。
Succeeded：Pod 的所有容器都已成功退出，且不再重启，状态为 Completed。
Failed：Pod 的所有容器都已退出，但至少有一个容器是异常退出的，状态为 Error。
Unknown：由于 master 节点与 Pod 所在的 node 节点通信失联，controller-manager 无法获取 Pod 的状态信息。

Node 宕机时的 Pod 驱逐流程

标记 Node 为 Unknown：master 节点上的控制器发现无法与 kubelet 通信时，标记宕机的节点为 Unknown 状态。
创建 NoExecute 污点：自动创建 NoExecute 污点，防止新 Pod 调度到该节点上。
驱逐 Pod：经过默认的 300 秒容忍度时间后，该节点上的 Pod 会被污点自动驱逐。

常见排障命令

1. Pod 故障排查

# 查看 Pod 运行状态
kubectl get -n <命名空间> pods -o wide

# 查看 Pod 详细信息
kubectl describe -n <命名空间> pods <pod名称>

# 查看容器日志
kubectl logs -n <命名空间> <pod名称> -c <容器名> -f [-p]

# 进入容器内部
kubectl exec -n <命名空间> -it <pod名称> -c <容器名> -- sh|命令

# Pod 抓包
kubectl describe -n <命名空间> pods <pod名称>
docker inspect -f {{.State.Pid}} <容器ID>
nsenter -n -t <容器PID>
tcpdump -i ens33 host <目标IP> and tcp and port <端口> -w name.pcap

# 使用临时容器调试
kubectl debug -it -n <命名空间> <pod名称> --image=<临时镜像> [--target=<目标容器名>]

2. Service 故障排查

# 查看 Service 信息
kubectl get -n <命名空间> svc -o wide

# 查看 Service 详细信息
kubectl describe -n <命名空间> svc <svc名称>

# 查看 Pod 标签与 Service Selector 是否匹配
kubectl get -n <命名空间> pods --show-labels

# 编辑 Service 配置
kubectl edit -n <命名空间> svc <svc名称>

3. Node故障排查

# 查看节点状态
kubectl get nodes

# 查看 Master 组件健康状态
kubectl get cs

# 查看集群信息
kubectl cluster-info

# 查看节点详细信息
kubectl describe node <节点名称>

# 查看 kubelet 进程状态
systemctl status kubelet

# 查看 kubelet 日志
journalctl -u kubelet [-r] [-f]

风语者！平时喜欢研究各种技术，目前在从事后端开发工作，热爱生活、热爱工作。

上一篇
深入理解k8s中的容器存储接口（CSI）...

下一篇
A8. Jenkins Pipeline自动化部署过程，多...

站长推荐

U8W/U8W-Mini使用与常见问题解决
U8W/U8W-Mini使用与常见问题解决
分享几个国内免费的ChatGPT镜像网址(亲测有效)
分享几个国内免费的ChatGPT镜像网址(亲测有效)
stm32使用HAL库配置串口中断收发数据（保姆级教程）
stm32使用HAL库配置串口中断收发数据（保姆级教程）
SpringSecurity实现前后端分离认证授权
SpringSecurity实现前后端分离认证授权
【社区图书馆】伴我前行的一本书《The C Programming Language》
【社区图书馆】伴我前行的一本书《The C Programming Language》

您现在的位置是：首页 >其他 >【k8s应用管理】kubernetes 群集调度管理网站首页其他