本文还有配套的精品资源，点击获取

简介：Kubernetes节点是集群中运行容器化应用的工作单元，包含kubelet、容器运行时和kube-proxy等核心组件。本文详细解析了节点的角色、状态管理、健康检查、资源调度、网络策略、持久化存储等内容，并介绍了节点升级和维护的最佳实践。通过学习本文，读者将掌握Kubernetes节点的核心原理与实际操作，提升集群管理的稳定性与效率。

1. Kubernetes集群基础概念

Kubernetes（简称K8s）是一个用于自动化部署、扩展和管理容器化应用的开源系统。其核心架构由控制平面（Control Plane）和工作节点（Worker Node）组成，实现对大规模容器集群的统一调度与管理。

1.1 Kubernetes基本架构概述

Kubernetes集群由两类节点组成：

• Master节点 ：负责整个集群的管理和控制，包含以下核心组件：
• API Server ：提供RESTful API，是集群操作的入口。
• etcd ：分布式键值存储，保存集群的所有状态信息。
• Scheduler ：负责将Pod调度到合适的Node上运行。
• Controller Manager ：运行控制器，确保集群的期望状态与实际状态一致。

• Cloud Controller Manager （可选）：与云平台交互，管理节点和负载均衡。

• Node节点 ：是实际运行容器化应用的工作节点，包含以下关键组件：

• kubelet ：负责与Master通信，管理Pod和容器生命周期。
• kube-proxy ：实现Service的网络代理与负载均衡。
• 容器运行时 （如Docker、containerd）：负责运行容器。

1.2 Pod与生命周期管理

Pod是Kubernetes中最小的可部署单元，通常包含一个或多个共享资源的容器。Pod的生命周期包括以下几个阶段：

• Pending ：Pod已创建，但尚未被调度。
• Running ：Pod已被调度到某个Node，并且至少一个容器正在运行。
• Succeeded / Failed ：Pod中所有容器已完成运行，根据退出状态判断成功或失败。
• Unknown ：由于通信问题，Pod状态无法获取。

kubelet负责监控Pod状态，并向API Server上报，确保系统的自愈能力。

1.3 核心组件作用解析

API Server

API Server是Kubernetes控制平面的核心组件，提供REST API，供用户、集群组件和外部系统调用。它处理请求、验证、更新集群状态，并与etcd进行数据交互。

etcd

etcd是一个高可用的分布式键值存储系统，保存集群的所有配置数据和状态信息，如Pod、Service、ConfigMap等资源对象。

Controller Manager

Controller Manager负责运行一系列控制器（Controller），例如Replication Controller、Node Controller等，确保集群的实际状态与期望状态一致。

Scheduler

Scheduler负责将新创建的Pod分配到一个合适的Node上运行，基于资源可用性、亲和性策略等进行调度决策。

1.4 小结

本章从Kubernetes整体架构出发，介绍了Master与Node节点的职责划分、Pod生命周期管理机制以及核心组件的作用。这些基础概念为后续深入理解Node节点及其组件（如kubelet、kube-proxy）打下了坚实的理论基础。下一章将重点剖析Node节点在集群中的角色与功能模块。

2. Node节点的核心角色与职责

Node节点是Kubernetes集群中承载容器化工作负载的基础设施单元，是整个集群执行层的核心组成部分。每个Node节点通过与Master节点的协作，完成Pod的创建、运行、监控以及网络通信等关键任务。理解Node节点的核心角色与职责，是掌握Kubernetes集群工作原理和进行运维优化的基础。

2.1 Node节点在Kubernetes集群中的定位

Kubernetes集群由Master节点和多个Node节点组成。Master节点负责集群的全局调度与状态管理，而Node节点则专注于执行由Master下发的任务。每个Node节点作为Pod运行的载体，负责提供运行容器所需的环境，并通过与Master节点持续通信，保持状态同步。

2.1.1 作为工作负载运行的载体

Node节点的核心功能之一是运行Pod。Pod是Kubernetes中最小的部署单元，通常包含一个或多个共享资源的容器。当用户通过kubectl提交Pod定义后，Kubernetes调度器（Scheduler）会根据资源需求和调度策略将Pod分配到合适的Node节点上执行。

Node节点上运行的 kubelet 组件负责接收来自API Server的Pod配置信息，并协同容器运行时（如Docker或containerd）启动容器。同时， kube-proxy 组件负责维护节点的网络规则，确保Pod间的通信和Service的访问逻辑正常运作。

以下是一个典型的Pod定义文件：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

执行命令：

kubectl apply -f nginx-pod.yaml

执行逻辑说明：

• kubectl apply 将YAML文件提交给API Server。
• API Server将Pod定义持久化到etcd中。
• Scheduler选择一个合适的Node节点并绑定Pod。
• Node节点上的 kubelet 拉取Pod定义并启动容器。

参数说明：

• apiVersion : 指定API组和版本，此处为 v1 。
• kind : 定义资源类型，这里是Pod。
• metadata.name : Pod的名称。
• spec.containers : 容器列表，定义了容器名称、镜像和端口。

2.1.2 与Master节点的通信机制

Node节点通过API Server与Master节点保持通信。 kubelet 定期向API Server发送心跳信息，并上报节点状态（如CPU、内存使用情况、Pod运行状态等）。API Server将这些信息存储在etcd中，供其他组件（如Controller Manager、Scheduler）使用。

此外， kube-proxy 通过API Server监听Service和Endpoints的变化，并据此更新本机的网络规则（如iptables或IPVS规则），确保网络通信正常。

通信流程图：

graph TD
    A[Master Node] --> B(API Server)
    B --> C[kubelet @ Node]
    B --> D[kube-proxy @ Node]
    C --> E[(etcd)]
    D --> E
    C --> F[上报节点状态]
    D --> G[同步Service规则]

逻辑分析：

• Node节点的 kubelet 和 kube-proxy 通过HTTPS协议与API Server通信。
• kubelet 负责节点状态上报和Pod生命周期管理。
• kube-proxy 根据Service资源信息配置本机网络转发规则。

2.2 Node节点的主要功能模块

Node节点上运行着多个关键组件，它们协同工作，实现容器运行、资源监控、网络通信等核心功能。

2.2.1 kubelet、kube-proxy和容器运行时的协作关系

Node节点上的核心组件包括 kubelet 、 kube-proxy 和容器运行时（如Docker、containerd）。它们的协作关系如下：

组件	功能描述
kubelet	负责Pod管理、容器生命周期控制、状态上报等
kube-proxy	负责维护节点网络规则，实现Service通信
容器运行时	负责容器的创建、运行、销毁等操作

代码示例：查看kubelet运行状态

systemctl status kubelet

输出示例：

● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2025-04-05 10:00:00 UTC; 1 day ago
     Docs: https://kubernetes.io/docs/
 Main PID: 1234 (kubelet)
    Tasks: 10
   Memory: 100.0M
   CGroup: /system.slice/kubelet.service
           └─1234 /usr/bin/kubelet --config=/var/lib/kubelet/config.yaml

逻辑分析：

• kubelet 服务由systemd管理，配置文件位于 /var/lib/kubelet/config.yaml 。
• 启动参数中包含节点IP、最大Pod数量、日志路径等配置项。

容器运行时示例：查看containerd状态

systemctl status containerd

输出示例：

● containerd.service - containerd container runtime
   Loaded: loaded (/lib/systemd/system/containerd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2025-04-05 10:00:00 UTC; 1 day ago
     Docs: https://containerd.io
 Main PID: 5678 (containerd)
    Tasks: 15
   Memory: 200.0M
   CGroup: /system.slice/containerd.service
           └─5678 /usr/bin/containerd

逻辑分析：

• containerd 是默认的容器运行时，负责容器镜像管理、容器生命周期控制。
• 配置文件位于 /etc/containerd/config.toml 。

2.2.2 系统资源监控与上报

Node节点通过 kubelet 上报节点资源使用情况，包括CPU、内存、磁盘等指标。这些信息存储在 Node 资源对象的 status 字段中，供调度器在调度Pod时参考。

代码示例：查看节点资源信息

kubectl describe node <node-name>

输出片段：

Capacity:
  cpu:                4
  memory:             16Gi
  pods:               110
Allocatable:
  cpu:                3.5
  memory:             15Gi
  pods:               110
System Info:
  OS Image:           Ubuntu 22.04
  Kernel Version:     5.15.0-105-generic
  Container Runtime:  containerd://1.6.28
  Kubelet Version:    v1.28.0

参数说明：

• Capacity : 节点总资源容量。
• Allocatable : 可分配给Pod的资源量。
• OS Image : 操作系统版本。
• Container Runtime : 容器运行时及版本。
• Kubelet Version : kubelet版本。

逻辑分析：

• kubelet 定期向API Server发送节点资源使用情况。
• 这些信息用于调度决策，确保Pod不会超出节点资源限制。

2.3 Node节点的状态信息管理

Node节点的状态信息由 kubelet 上报，并通过API Server存储在etcd中。这些状态信息用于判断节点是否可用、是否适合调度Pod等。

2.3.1 节点状态字段（Conditions）解析

Node的 status.conditions 字段描述了节点的当前状态，包括Ready、MemoryPressure、DiskPressure等条件。每个条件都有 type 、 status 、 reason 和 message 字段。

代码示例：查看节点状态

kubectl describe node <node-name> | grep -A 5 "Conditions"

输出示例：

Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason              Message
  ----             ------  -----------------                 ------------------                ------              -------
  Ready            True    2025-04-06 12:00:00 UTC           2025-04-05 10:00:00 UTC           KubeletReady        kubelet is posting ready status
  MemoryPressure   False   2025-04-06 12:00:00 UTC           2025-04-05 10:00:00 UTC           MemoryPressure      false
  DiskPressure     False   2025-04-06 12:00:00 UTC           2025-04-05 10:00:00 UTC           DiskPressure        false

参数说明：

• Type : 条件类型，如Ready、MemoryPressure。
• Status : 当前状态（True/False/Unknown）。
• LastHeartbeatTime : 上次心跳时间。
• Reason : 状态变化的原因。
• Message : 附加信息。

逻辑分析：

• 当 Ready 状态为 True 时，节点可调度。
• 如果 MemoryPressure 为 True ，说明节点内存资源紧张，可能影响Pod调度。

2.3.2 Taint和Toleration机制对调度的影响

Taint机制允许Node节点对Pod设置排斥策略，而Toleration允许Pod接受特定Taint，从而控制Pod的调度行为。

代码示例：为节点添加Taint

kubectl taint nodes <node-name> key=value:NoSchedule

逻辑分析：

• 该命令为节点添加了一个Taint，键为 key ，值为 value ，作用为 NoSchedule 。
• 没有对应Toleration的Pod将不会被调度到该节点。

Pod定义中添加Toleration：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

参数说明：

• key : 匹配的Taint键。
• operator : 匹配方式，Equal或Exists。
• value : Taint的值。
• effect : Taint的影响，如NoSchedule、NoExecute。

逻辑分析：

• Toleration允许Pod被调度到具有特定Taint的节点上。
• 该机制常用于节点专用调度、维护模式等场景。

通过本章内容，我们深入了解了Node节点在Kubernetes集群中的核心角色与职责，包括作为工作负载运行的载体、与Master节点的通信机制、主要功能模块的协作关系、资源监控与上报机制，以及节点状态管理和Taint/Toleration机制。这些内容为后续章节中对kubelet、容器运行时、网络代理等组件的深入解析打下了坚实的基础。

3. kubelet组件详解与配置

3.1 kubelet的功能与运行原理

3.1.1 Pod管理与容器生命周期控制

kubelet 是 Kubernetes Node 节点上的核心组件，负责管理 Pod 的生命周期和与容器运行时（如 containerd 或 Docker）的交互。每个 Node 节点上必须运行一个 kubelet 实例，它通过监听 API Server 的指令来创建、销毁 Pod，并确保容器按照期望的状态运行。

Pod生命周期管理流程

kubelet 通过以下步骤管理 Pod 的生命周期：

1. 监听 API Server ：kubelet 持续监听 API Server 上的 Pod 资源变化，一旦发现有新的 Pod 被调度到当前节点，kubelet 会启动 Pod 的创建流程。
2. Pod创建流程 ：kubelet 调用容器运行时接口（CRI）来创建 Pod 沙箱容器（Pause 容器），用于共享网络和命名空间。
3. 容器启动 ：在 Pod 沙箱创建完成后，kubelet 依次启动容器定义中指定的各个容器。
4. 状态同步 ：kubelet 实时监控所有容器的运行状态，并将 Pod 的状态信息上报给 API Server。
5. 终止与清理 ：当 Pod 被删除或发生异常时，kubelet 会通知容器运行时终止并清理容器。

mermaid流程图：Pod生命周期控制流程

graph TD
    A[kubelet监听API Server] --> B{是否有新Pod被调度到本节点?}
    B -->|是| C[创建Pod沙箱容器]
    C --> D[启动容器定义中的容器]
    D --> E[监控容器状态]
    E --> F[上报Pod状态到API Server]
    B -->|否| G[持续监听]
    H[Pod被删除或发生异常] --> I[调用容器运行时终止容器]
    I --> J[清理Pod资源]

代码示例：Pod状态上报机制

kubelet 通过 /var/lib/kubelet/config.yaml 中的配置项 statusUpdateFrequency 控制状态上报频率，默认为 10 秒一次。

# /var/lib/kubelet/config.yaml
statusUpdateFrequency: 10s

当 kubelet 上报 Pod 状态时，会调用如下 API：

func (kl *Kubelet) updatePodStatus(pod *v1.Pod, status *v1.PodStatus) error {
    // 构造Pod状态更新请求
    updateReq := &kubeletapi.PodStatusUpdate{
        PodName:      pod.Name,
        PodNamespace: pod.Namespace,
        Status:       *status,
    }
    // 向API Server发送状态更新
    return kl.kubeClient.CoreV1().Pods(pod.Namespace).UpdateStatus(context.TODO(), pod.Name, &v1.Pod{
        ObjectMeta: pod.ObjectMeta,
        Status:     *status,
    }, metav1.UpdateOptions{})
}

逐行解读分析 ：
- 第 2 行：构造一个 Pod 状态更新请求对象，包含 Pod 名称、命名空间和当前状态。
- 第 5 行：调用 Kubernetes API Client 的 UpdateStatus 方法，将 Pod 的最新状态提交到 API Server。
- 第 7 行：使用 context.TODO() 表示当前操作不带上下文，适用于短期操作。

3.1.2 向API Server上报状态信息

kubelet 定期向 API Server 上报节点和 Pod 的状态信息，以便集群调度器和控制器能够准确判断节点健康状况和容器运行状态。

上报内容包括：

• Node状态 ：CPU、内存、磁盘使用情况、节点是否就绪等。
• Pod状态 ：容器是否运行、重启次数、IP 地址等。
• 事件信息 ：如容器启动失败、镜像拉取失败等。

状态上报频率配置

kubelet 支持以下配置项用于控制状态上报：

# /var/lib/kubelet/config.yaml
nodeStatusUpdateFrequency: 10s
statusUpdateFrequency: 5s

• nodeStatusUpdateFrequency ：控制节点状态上报频率，默认为 10 秒。
• statusUpdateFrequency ：控制 Pod 状态上报频率，默认为 5 秒。

代码示例：kubelet上报节点状态逻辑

func (kl *Kubelet) syncNodeStatus() {
    node, err := kl.getNodeObject()
    if err != nil {
        klog.Errorf("Failed to get node object: %v", err)
        return
    }

    // 获取系统资源使用情况
    resourceUsage, err := kl.getRuntime().GetNodeResources()
    if err != nil {
        klog.Errorf("Failed to get node resources: %v", err)
        return
    }

    // 更新节点状态字段
    node.Status.Capacity = resourceUsage.Capacity
    node.Status.Allocatable = resourceUsage.Allocatable

    // 上报节点状态到API Server
    _, err = kl.kubeClient.CoreV1().Nodes().UpdateStatus(context.TODO(), node, metav1.UpdateOptions{})
    if err != nil {
        klog.Errorf("Failed to update node status: %v", err)
    }
}

逐行解读分析 ：
- 第 2 行：定义 syncNodeStatus 函数，用于同步节点状态。
- 第 4 行：获取当前节点对象。
- 第 8 行：调用容器运行时接口获取系统资源使用情况。
- 第 12 行：更新节点的 Capacity（总资源）和 Allocatable（可分配资源）。
- 第 15 行：将更新后的节点状态提交到 API Server。
- 第 16 行：记录错误日志，便于排查问题。

参数说明

参数	说明
nodeStatusUpdateFrequency	控制节点状态上报频率，默认为 10 秒
statusUpdateFrequency	控制 Pod 状态上报频率，默认为 5 秒

3.2 kubelet的配置参数与调优策略

3.2.1 常用配置项解析（如–node-ip、–max-pods）

kubelet 提供了丰富的配置参数，用于控制其行为和性能。以下是一些常用的配置项及其作用：

常用 kubelet 配置参数说明

配置项	说明	默认值
--node-ip	设置节点的 IP 地址，用于容器网络通信	自动检测
--max-pods	设置节点上允许运行的最大 Pod 数量	110
--pod-max-pids	设置每个 Pod 最大允许的进程数	0（不限制）
--image-gc-low-threshold	设置镜像垃圾回收的最低阈值（百分比）	85
--image-gc-high-threshold	设置镜像垃圾回收的最高阈值（百分比）	95

配置示例：限制最大 Pod 数量

# /var/lib/kubelet/config.yaml
maxPods: 50

该配置限制每个节点最多运行 50 个 Pod，适用于资源有限的节点。

配置示例：设置节点 IP 地址

# /var/lib/kubelet/config.yaml
nodeIP: 192.168.1.10

指定 kubelet 使用的节点 IP 地址，避免自动检测导致的网络错误。

3.2.2 日志管理与故障排查技巧

kubelet 日志是排查节点问题的重要依据。日志通常位于 /var/log/kubelet.log ，也可以通过 journalctl 查看。

日志级别设置

kubelet 支持通过 --v 参数设置日志级别，值越大日志越详细：

# 设置日志级别为4（详细日志）
kubelet --v=4

日志级别说明

级别	说明
0	默认日志级别，输出关键信息
1-3	输出调试信息
4-6	输出详细调试信息
7+	输出 HTTP 请求/响应内容（谨慎使用）

日志查看命令示例

# 查看 kubelet 日志
journalctl -u kubelet.service -f

# 查看特定时间的日志
journalctl -u kubelet.service --since "1 hour ago"

# 查看最近 100 条日志
journalctl -u kubelet.service -n 100

代码示例：kubelet日志记录函数

func logPodCreation(pod *v1.Pod) {
    klog.Infof("Creating Pod: %s/%s", pod.Namespace, pod.Name)
    if klog.V(4).Enabled() {
        klog.Infof("Pod Spec: %+v", pod.Spec)
    }
}

逐行解读分析 ：
- 第 2 行：使用 klog.Infof 输出 Pod 创建信息。
- 第 4 行：检查日志级别是否为 4 或更高，若是则输出 Pod 的详细配置。

3.3 kubelet的安全机制与权限控制

3.3.1 TLS认证与客户端证书配置

kubelet 与 API Server 之间的通信必须通过 TLS 加密，以确保安全性。kubelet 使用客户端证书进行身份认证。

证书配置流程

1. 生成 kubelet 客户端证书
   使用 cfssl 或其他工具生成 kubelet 客户端证书。

bash # 生成 kubelet 证书请求 cfssl genkey kubelet-csr.json | cfssljson -bare kubelet

2. 签署证书
   将证书请求提交给 Kubernetes CA 进行签署。

bash cfssl sign -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubelet.csr | cfssljson -bare kubelet

3. 配置 kubelet 使用证书

yaml # /var/lib/kubelet/config.yaml tlsCertFile: /etc/kubernetes/pki/kubelet.crt tlsPrivateKeyFile: /etc/kubernetes/pki/kubelet.key

证书验证逻辑代码示例

func validateClientCertificate(cert *x509.Certificate) error {
    if cert.NotAfter.Before(time.Now()) {
        return fmt.Errorf("certificate has expired")
    }

    if !cert.IsCA {
        return fmt.Errorf("certificate is not a CA certificate")
    }

    return nil
}

逐行解读分析 ：
- 第 2 行：检查证书是否已过期。
- 第 5 行：检查证书是否为 CA 证书，确保其可用于身份认证。

3.3.2 基于RBAC的角色权限管理

kubelet 需要具有特定权限才能访问 API Server，通常通过 RBAC 角色绑定实现。

RBAC权限配置示例

# kubelet-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: kube-system
  name: kubelet
rules:
- apiGroups: [""]
  resources: ["pods", "nodes", "events"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

绑定角色到 kubelet 用户：

# kubelet-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubelet
  namespace: kube-system
subjects:
- kind: User
  name: system:node:<node-name>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: kubelet
  apiGroup: rbac.authorization.k8s.io

RBAC权限验证逻辑代码示例

func checkRBACPermission(user string, resource string, verb string) bool {
    allowedResources := map[string][]string{
        "system:node:<node-name>": {"pods", "nodes", "events"},
    }

    allowedVerbs := []string{"get", "list", "watch", "create", "update", "patch", "delete"}

    if resources, ok := allowedResources[user]; ok {
        for _, r := range resources {
            if r == resource {
                for _, v := range allowedVerbs {
                    if v == verb {
                        return true
                    }
                }
            }
        }
    }

    return false
}

逐行解读分析 ：
- 第 2 行：定义 checkRBACPermission 函数，用于检查用户是否具有指定资源和操作权限。
- 第 3 行：定义允许的资源映射。
- 第 4 行：定义允许的操作。
- 第 6 行：检查用户是否在允许的列表中。
- 第 7 行：遍历用户允许的资源。
- 第 8 行：匹配资源后，遍历允许的操作。
- 第 11 行：返回权限验证结果。

本章从 kubelet 的核心功能出发，详细解析了其对 Pod 生命周期的管理机制、状态上报流程、配置参数、日志管理、安全机制与权限控制等关键内容。后续章节将继续深入探讨 kube-proxy、容器运行时集成等内容。

4. 容器运行时（如Docker、Containerd）集成

在 Kubernetes 架构中，容器运行时（Container Runtime）是 Node 节点上不可或缺的核心组件之一，它负责容器的创建、运行、销毁等生命周期管理。Kubernetes 通过容器运行接口（CRI, Container Runtime Interface）与底层容器运行时进行交互。目前主流的容器运行时包括 Docker 和 Containerd，它们在 Kubernetes 中的使用方式和集成机制存在显著差异。

本章将深入探讨容器运行时在 Kubernetes 中的角色、选型依据、配置方法及其与 kubelet 的协作机制，帮助读者理解如何在不同场景下选择和部署合适的容器运行时。

4.1 容器运行时的作用与选型分析

4.1.1 Docker与Containerd的对比

Docker 曾是 Kubernetes 早期默认使用的容器运行时，其优势在于用户友好、生态成熟、支持广泛。然而，随着 Kubernetes 对容器运行时抽象接口（CRI）的完善，Docker 逐渐显现出与 Kubernetes 架构耦合度高、组件复杂、维护成本高等问题。

对比项	Docker	Containerd
是否原生支持 CRI	否（需通过 dockershim 间接支持）	是
架构复杂度	高（包含 CLI、API、存储等组件）	低（专注于容器生命周期管理）
性能	相对较低	高
维护成本	高	低
社区活跃度	极高	高
官方推荐	否（自 Kubernetes 1.24 起移除支持）	是

从上表可以看出，虽然 Docker 仍然在容器生态中占据重要地位，但 Containerd 更适合 Kubernetes 的轻量级运行需求，且已被 Kubernetes 官方推荐作为默认容器运行时。

4.1.2 CRI接口与容器运行时兼容性

CRI（Container Runtime Interface）是 Kubernetes 定义的一组 gRPC 接口，用于 kubelet 与容器运行时之间的通信。其目的是解耦 Kubernetes 与具体的容器运行时实现，使得用户可以灵活替换底层容器引擎。

CRI 主要定义了如下几类接口：

• ImageService ：负责镜像的拉取、删除、查询等操作。
• RuntimeService ：负责容器和 Pod 的创建、启动、停止、删除等生命周期管理。

Containerd 原生支持 CRI，通过 containerd-shim 和 cri-containerd 插件即可实现与 kubelet 的无缝集成。而 Docker 虽然功能强大，但需要额外的 dockershim 插件才能接入 CRI，且在 Kubernetes v1.24 之后已被弃用。

graph TD
    A[kubelet] -->|CRI gRPC| B(Container Runtime)
    B --> C{Containerd}
    B --> D[Docker]
    C --> E[cri-containerd]
    C --> F[containerd-shim]
    D --> G[dockershim]
    G --> H[Docker Engine]

该流程图展示了 kubelet 通过 CRI 与容器运行时通信的机制。Containerd 原生支持 CRI，结构更简洁，而 Docker 则需要额外的 dockershim 层进行适配。

4.2 容器运行时的配置与部署

4.2.1 Containerd的配置文件结构

Containerd 的配置文件通常位于 /etc/containerd/config.toml ，采用 TOML 格式，支持高度定制化配置。

一个典型的配置文件如下：

version = 2
[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.9"
  [plugins."io.containerd.grpc.v1.cri".containerd]
    default_runtime_name = "runc"
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
      runtime_type = "io.containerd.runc.v2"
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
        SystemdCgroup = true

参数说明：

• sandbox_image ：指定 Pod 的 pause 镜像地址，用于 Pod 的网络命名空间初始化。
• default_runtime_name ：指定默认容器运行时，通常为 runc 。
• runtime_type ：运行时类型， io.containerd.runc.v2 是基于 runc 的运行时实现。
• SystemdCgroup ：是否启用 systemd 的 cgroup 管理，推荐在使用 systemd 的系统中设置为 true 。

操作步骤：

1. 编辑配置文件 /etc/containerd/config.toml 。
2. 修改或添加所需配置项。
3. 重启 containerd 服务以应用配置：

sudo systemctl restart containerd

4.2.2 镜像拉取策略与容器日志管理

镜像拉取策略

Containerd 支持多种镜像拉取策略，常见的有：

• Always ：每次启动容器时都拉取最新镜像。
• IfNotPresent ：仅当本地不存在该镜像时拉取。
• Never ：不拉取镜像，仅使用本地已有的镜像。

在 Kubernetes 中，可通过容器的 imagePullPolicy 字段进行配置：

spec:
  containers:
  - name: my-app
    image: myregistry.com/myapp:latest
    imagePullPolicy: IfNotPresent

容器日志管理

Containerd 默认将容器日志输出到 /var/log/containers/ 目录下，每个容器日志文件命名格式为：

<namespace>_<pod-name>_<container-name>-<container-id>.log

可以通过修改 Containerd 配置启用 JSON 日志格式或集成外部日志系统（如 Fluentd、Logstash）进行集中管理。

日志查看命令：

journalctl -u containerd.service

或直接查看日志文件：

cat /var/log/containers/<pod-namespace>_<pod-name>_<container-name>-*.log

4.3 容器运行时与kubelet的交互机制

4.3.1 CRI接口调用流程

kubelet 与容器运行时之间通过 CRI 接口进行通信，调用流程如下：

1. kubelet 通过 CRI gRPC 接口向容器运行时发送请求（如创建 Pod）。
2. 容器运行时接收请求，调用底层容器引擎（如 runc）执行操作。
3. 容器运行时将操作结果返回给 kubelet，kubelet 更新 Pod 状态。

以下是一个简化的 CRI 接口调用代码示例（使用 Go）：

// 创建 PodSandbox
func (c *criService) RunPodSandbox(ctx context.Context, req *runtime.RunPodSandboxRequest) (*runtime.RunPodSandboxResponse, error) {
    // 1. 创建 Pod 的网络命名空间
    networkNS, err := createNetworkNamespace()
    if err != nil {
        return nil, err
    }

    // 2. 使用 containerd 创建 sandbox 容器
    containerID, err := containerdClient.CreateSandboxContainer(req, networkNS)
    if err != nil {
        return nil, err
    }

    // 3. 返回 PodSandboxID
    return &runtime.RunPodSandboxResponse{PodSandboxId: containerID}, nil
}

逻辑分析：

• 该函数用于创建 PodSandbox，是 Pod 生命周期的第一步。
• createNetworkNamespace() 创建网络命名空间，为 Pod 提供独立的网络环境。
• containerdClient.CreateSandboxContainer() 实际调用 Containerd 创建 pause 容器。
• 最后返回 PodSandbox ID，供后续操作使用。

4.3.2 容器启动与健康检查的实现方式

容器启动流程

1. kubelet 通过 CRI 调用 RunPodSandbox 创建 Pod 的沙箱容器（pause 容器）。
2. 创建成功后，调用 CreateContainer 创建业务容器。
3. 调用 StartContainer 启动容器。
4. kubelet 监控容器状态，并定期上报给 API Server。

健康检查机制

Kubernetes 提供三种类型的健康检查探针（Probe）：

• LivenessProbe ：判断容器是否存活，若失败则重启容器。
• ReadinessProbe ：判断容器是否准备好接收流量。
• StartupProbe ：判断容器是否启动完成（用于慢启动应用）。

示例配置如下：

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

逻辑说明：

• httpGet 表示使用 HTTP 接口进行健康检查。
• initialDelaySeconds 表示容器启动后等待多久开始检查。
• periodSeconds 表示检查间隔。

这些探针由 kubelet 调用容器运行时提供的接口进行检测，Containerd 通过调用容器的 exec 命令或访问 HTTP 接口来实现探针逻辑。

本章从容器运行时的基本作用出发，对比了 Docker 与 Containerd 的差异，深入分析了 Containerd 的配置结构、镜像与日志管理机制，并详细解析了 kubelet 与容器运行时之间的 CRI 调用流程及容器健康检查的实现方式。这些内容为后续部署、调优和故障排查 Kubernetes Node 节点提供了坚实的技术基础。

5. kube-proxy网络代理作用与实现

Kubernetes中，网络通信是集群运行的核心问题之一。 kube-proxy 作为集群中每个Node节点上的关键网络组件，负责实现Kubernetes的Service资源模型，确保服务间的通信能够高效、可靠地进行。本章将深入探讨kube-proxy在网络通信中的核心作用、其工作模式、配置方法以及如何与整个网络架构协同工作，以支持Kubernetes的服务发现与负载均衡机制。

5.1 kube-proxy在网络通信中的角色

kube-proxy是Kubernetes中实现Service抽象的核心组件之一。它运行在每个Node节点上，负责维护节点上的网络规则，确保请求能够正确地转发到后端Pod。其主要功能包括：

• 监听API Server中Service和Endpoints的变化；
• 根据变化更新本地的网络规则（如iptables或IPVS规则）；
• 实现集群内部服务的负载均衡；
• 支持外部访问（配合Ingress或NodePort类型Service）；
• 保证服务发现和网络策略的连贯性。

5.1.1 Service资源的实现机制

Kubernetes中Service是抽象的逻辑概念，它定义了一组Pod的访问策略。例如，一个Service可以通过标签选择器（Selector）来匹配后端的Pod，并为这些Pod提供一个稳定的IP和DNS名称。

Service的工作原理如下：

1. 用户定义一个Service资源，指定Selector和端口；
2. kube-proxy监听API Server，当Service被创建时，kube-proxy会获取Service的IP和服务端口；
3. kube-proxy根据当前节点上的Endpoints（即匹配Selector的Pod列表）配置本地的网络转发规则；
4. 当有请求访问Service的ClusterIP时，请求会被转发到后端Pod中的一个（依据负载均衡策略）。

示例Service定义：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

逻辑流程图（Mermaid格式）：

graph TD
    A[用户定义Service] --> B[API Server接收Service定义]
    B --> C[kube-proxy监听Service变化]
    C --> D[获取Endpoints列表]
    D --> E[kube-proxy更新本地网络规则]
    E --> F[Service ClusterIP访问生效]

解释说明：

• Endpoints 是Service与Pod之间的桥梁，kube-proxy通过Endpoints获取后端Pod的IP和端口；
• ClusterIP 是Kubernetes为Service分配的虚拟IP，仅在集群内部可见；
• kube-proxy 根据Endpoints的变化动态更新转发规则，确保请求能正确路由到健康的Pod。

5.1.2 负载均衡与流量转发策略

kube-proxy支持多种负载均衡算法，具体行为取决于其工作模式（如iptables或IPVS）。

负载均衡策略包括：

策略	说明
Round Robin	默认策略，轮询方式选择后端Pod
Session Affinity	基于客户端IP进行会话保持，适用于有状态服务
Least Connection	选择当前连接数最少的Pod（仅IPVS模式支持）

配置Session Affinity的示例：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800

代码逻辑分析：

• sessionAffinity: ClientIP 表示启用基于客户端IP的会话保持；
• timeoutSeconds: 10800 表示保持会话的时间（单位：秒），默认为10800秒（3小时）；
• 此配置在kube-proxy中会被转换为iptables的 recent 模块规则或IPVS的连接跟踪机制，实现客户端IP绑定。

5.2 kube-proxy的工作模式（Userspace、Iptables、IPVS）

kube-proxy支持三种主要的工作模式：Userspace、Iptables和IPVS。不同模式在网络性能、可扩展性和配置复杂度上各有优劣。

5.2.1 不同模式的性能与适用场景

模式	性能	可扩展性	稳定性	适用场景
Userspace	低	差	稳定	早期版本，测试用途
Iptables	中	中	稳定	小型集群或默认模式
IPVS	高	高	稳定	大型生产环境，推荐使用

Userspace模式

• 所有流量通过kube-proxy的用户空间程序转发；
• 每个连接都需要kube-proxy代理，性能较差；
• 不推荐用于生产环境。

Iptables模式

• 利用Linux内核的iptables规则实现转发；
• 性能优于Userspace；
• 随着Service数量增加，iptables规则会变得复杂，影响性能；
• 是Kubernetes 1.2之前的默认模式。

IPVS模式

• 使用Linux内核的IP Virtual Server模块；
• 支持更高效的负载均衡算法（如RR、WRR、LC、SH）；
• 支持更复杂的网络拓扑；
• 是Kubernetes 1.11之后推荐的默认模式。

5.2.2 IPVS模式的配置与优化

要启用IPVS模式，需在kube-proxy配置文件中进行设置：

配置文件示例（/var/lib/kube-proxy/config.conf）：

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs
ipvs:
  scheduler: "rr"  # 调度算法：rr（轮询）、wrr、lc等
  excludeCIDRs:
    - "10.0.0.0/8"

参数说明：

• mode: ipvs 表示启用IPVS模式；
• scheduler 设置负载均衡调度算法；
• excludeCIDRs 指定不需要转发的IP段，用于排除特定网络流量。

验证IPVS规则：

ipvsadm -L -n

输出示例：

TCP  10.96.0.1:80 rr
  -> 10.244.1.3:9376              Route   1      0          0
  -> 10.244.2.5:9376              Route   1      0          0

逻辑分析：

• 上述命令展示了当前IPVS的转发规则；
• rr 表示轮询调度；
• -> 后面是后端Pod的IP和端口；
• 每个后端Pod的权重为1，表示流量均分。

5.3 kube-proxy的配置与维护

kube-proxy的配置直接影响Kubernetes网络通信的性能和稳定性。合理配置其参数是集群运维的重要任务之一。

5.3.1 核心配置参数解析

参数	说明
--bind-address	kube-proxy监听的本地地址，默认为0.0.0.0
--cluster-cidr	集群Pod网络CIDR，用于判断是否为集群内部流量
--healthz-bind-address	健康检查监听地址
--proxy-mode	指定工作模式（userspace、iptables、ipvs）
--iptables-sync-period	iptables规则同步周期，默认30s
--ipvs-sync-period	IPVS规则同步周期，默认30s
--conntrack-max	最大连接跟踪数，默认为0（无限制）

配置建议：

• 对于大规模集群，建议设置合理的 conntrack-max 值以防止连接跟踪表溢出；
• 如果使用IPVS，建议启用 --ipvs-min-sync-period 来减少规则同步的频率；
• 在多网卡环境中，建议指定 --bind-address 为集群内网IP。

5.3.2 网络策略与服务发现的联动

kube-proxy不仅处理Service的流量转发，还与Kubernetes的网络策略（NetworkPolicy）和服务发现机制（如CoreDNS）协同工作。

服务发现流程图（Mermaid）：

graph LR
    A[Pod访问Service名称] --> B[CoreDNS解析域名]
    B --> C[返回Service ClusterIP]
    C --> D[Pod访问ClusterIP]
    D --> E[kube-proxy转发流量到后端Pod]

流程说明：

1. Pod通过DNS名称访问服务（如my-service.namespace）；
2. CoreDNS解析该名称，返回Service的ClusterIP；
3. Pod向ClusterIP发起请求；
4. kube-proxy根据本地规则将请求转发到后端Pod；
5. 实现服务发现与负载均衡的闭环。

示例代码：Pod中访问Service

curl http://my-service.default.svc.cluster.local:80

执行逻辑说明：

• my-service.default.svc.cluster.local 是Kubernetes内部DNS格式；
• DNS解析由CoreDNS完成；
• 实际请求通过kube-proxy转发到后端Pod；
• 整个过程对用户透明，体现Kubernetes服务抽象的优势。

总结说明：

kube-proxy作为Kubernetes网络通信的核心组件，不仅负责Service的实现，还在负载均衡、服务发现、网络策略等方面扮演重要角色。理解其工作模式、配置参数和维护方式，是构建高性能、高可用Kubernetes集群的关键环节。下一章我们将深入探讨Node节点的状态管理机制，进一步完善Kubernetes的节点管理知识体系。

6. Node节点状态管理（Ready、NotReady、Unschedulable）

在Kubernetes集群中，Node节点的状态管理是保障集群稳定性与资源调度效率的关键环节。每个节点的状态直接影响其是否能够接收新的Pod调度请求，以及是否处于正常运行状态。本章将从节点状态的定义与判定机制入手，深入解析Node Ready、NotReady、Unschedulable等状态的含义、影响以及控制方式，并结合实际场景，探讨节点状态异常的处理流程与自动化策略。

6.1 节点状态的定义与判定条件

Kubernetes通过Node对象的 status.conditions 字段来记录节点的健康状态。其中最重要的状态是 Ready 和 NotReady ，它们决定了节点是否可以参与调度。此外，还存在一些辅助状态字段，用于反映节点的资源使用情况、网络状况等。

6.1.1 Node Ready Condition详解

Node Ready 是节点状态中最重要的条件之一，表示节点是否准备好接收工作负载。其定义如下：

status:
  conditions:
    - type: Ready
      status: "True"
      reason: KubeletReady
      message: kubelet is posting ready status
      lastHeartbeatTime: "2025-04-05T12:34:56Z"
      lastTransitionTime: "2025-04-05T12:34:56Z"

参数说明：

• type ：表示状态类型，这里是 Ready 。
• status ：当前状态值，可为 True 、 False 或 Unknown 。
• reason ：状态变化的原因。
• message ：更详细的描述信息。
• lastHeartbeatTime ：最后一次心跳时间。
• lastTransitionTime ：状态最后一次变更的时间。

当 status 为 True 时，表示节点处于就绪状态，可以接收Pod调度；当为 False 或 Unknown 时，表示节点可能存在问题。

判定逻辑：

• kubelet每隔一段时间（默认为10秒）向API Server发送心跳。
• 如果超过 node-monitor-grace-period （默认40秒）未收到心跳，则将节点标记为 Unknown 。
• 如果再超过 pod-eviction-timeout （默认5分钟），仍未恢复，则触发Pod驱逐。

6.1.2 Node不可用的常见原因分析

节点状态变为 NotReady 可能由以下原因导致：

原因	描述	影响
kubelet宕机	kubelet进程异常退出	无法上报状态，Pod无法启动
网络不通	节点与API Server之间通信中断	无法调度新Pod
磁盘压力	磁盘空间不足或inode耗尽	阻止新Pod创建
内存压力	内存使用率过高	阻止新Pod创建
PID压力	进程数过多	影响系统稳定性

示例：查看节点状态

kubectl describe node <node-name>

输出中会包含完整的 Conditions 字段信息，便于排查问题。

6.2 节点调度状态的控制方法

Kubernetes允许管理员通过设置节点的调度状态来控制其是否参与调度，这对于节点维护、滚动升级等场景非常有用。

6.2.1 设置Unschedulable状态的意义

将节点标记为 Unschedulable 后，调度器将不再向该节点分配新的Pod，但已有的Pod仍然可以继续运行。这在进行节点维护（如升级kubelet、操作系统补丁）时非常有用。

如何设置Unschedulable状态：

kubectl taint nodes <node-name> node.kubernetes.io/unreachable:NoSchedule

注意： NoSchedule 表示不允许调度新的Pod，但已有的Pod不会被驱逐。还可以使用 NoExecute 来驱逐已有的Pod。

使用 kubectl drain 优雅驱逐Pod：

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

• --ignore-daemonsets ：忽略DaemonSet管理的Pod。
• --delete-emptydir-data ：删除使用emptyDir卷的Pod数据。

6.2.2 使用kubectl taint命令控制节点调度

Taint机制是Kubernetes中控制节点调度的高级手段。通过为节点添加Taint，可以阻止特定Pod调度到该节点上。

示例：为节点添加Taint

kubectl taint nodes node-01 env=production:NoSchedule

示例：为Pod添加Toleration

tolerations:
  - key: "env"
    operator: "Equal"
    value: "production"
    effect: "NoSchedule"

表格：Taint与Toleration匹配规则

Taint设置	Toleration设置	是否匹配
key=env, value=prod, effect=NoSchedule	key=env, value=prod, effect=NoSchedule	✅
key=env, value=prod, effect=NoSchedule	key=env, value=prod	❌（effect必须一致）
key=env, value=prod, effect=NoSchedule	key=env, operator=Exists	✅（不关心value）
key=env, effect=NoSchedule	key=env, effect=NoExecute	❌（effect不一致）

6.3 节点状态异常的处理流程

节点状态异常是Kubernetes运维中常见的问题。处理流程包括自动恢复机制和人工干预策略，以及如何利用监控系统进行实时响应。

6.3.1 自动恢复机制与人工干预策略

Kubernetes内置了自动恢复机制，如节点心跳检测、Pod驱逐等。然而，对于某些复杂问题，仍需人工介入。

自动恢复机制：

• 心跳检测机制 ：定期检查节点状态。
• Pod驱逐机制 ：在节点长时间未恢复时自动驱逐Pod。
• 节点自动修复 ：如kubelet重启、系统自动修复脚本。

人工干预策略：

• 检查节点状态 ：使用 kubectl describe node 。
• 日志排查 ：查看 /var/log/kubelet.log 。
• 网络排查 ：使用 ping , traceroute , telnet 等工具。
• 重启服务 ：必要时重启kubelet或容器运行时。

6.3.2 监控系统对节点状态的实时响应

通过集成Prometheus、Grafana、Alertmanager等监控工具，可以实现对节点状态的实时监控与告警。

示例：Prometheus监控指标

指标名称	描述
node_ready	节点是否处于Ready状态
node_num_cpu	CPU数量
node_memory_MemAvailable_bytes	可用内存大小
node_diskio_io_time_seconds_total	磁盘IO时间

告警规则示例（Prometheus Rule）：

- alert: NodeNotReady
  expr: node_ready != 1
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: Node {{ $labels.instance }} is not ready
    description: Node {{ $labels.instance }} has been unreachable for more than 2 minutes.

流程图：节点状态异常处理流程

graph TD
    A[节点状态变为NotReady] --> B{是否自动恢复?}
    B -->|是| C[系统自动恢复]
    B -->|否| D[触发告警]
    D --> E[人工介入]
    E --> F[排查原因]
    F --> G{是否需要维护?}
    G -->|是| H[设置Unschedulable]
    G -->|否| I[恢复节点]
    H --> J[维护完成后解除Taint]

总结

本章系统地讲解了Kubernetes中Node节点的状态管理机制，包括状态的定义与判定、调度状态的控制方式以及异常处理流程。通过对Node Ready、Unschedulable等状态的深入分析，结合Taint与Toleration机制、kubelet心跳机制、监控告警系统等内容，读者可以全面掌握节点状态管理的原理与实践方法，为构建高可用、可维护的Kubernetes集群打下坚实基础。

7. 节点健康检查机制（Heartbeat、Probe）

Kubernetes作为一个高度自动化和自愈能力强大的容器编排平台，其健康检查机制是保障系统稳定性和服务高可用性的关键环节。本章将深入探讨Kubernetes中与节点和容器相关的健康检查机制，包括心跳机制、容器探针（Probe）类型、探针配置策略以及节点健康状态的综合判断逻辑。

7.1 节点心跳机制与状态更新

7.1.1 kubelet向API Server发送心跳的原理

每个Node节点上的kubelet组件会定期向API Server发送心跳（Heartbeat）信号，以表明该节点当前处于活跃状态。心跳信息中包含了节点的资源使用情况、Pod状态、以及节点的Condition信息（如 Ready 、 MemoryPressure 等）。

心跳默认每10秒发送一次，由kubelet的以下配置控制：

# kubelet配置示例
nodeStatusUpdateFrequency: 10s

API Server接收到心跳后，会更新节点的 lastHeartbeatTime 字段。如果API Server在指定时间内未收到心跳（默认为40秒），则将节点标记为 NotReady 。

7.1.2 心跳超时与节点驱逐策略

Kubernetes通过控制器（如Node Controller）来监控节点心跳状态。当节点超时未上报心跳时，控制器会将其标记为 NotReady 状态，并在一段时间后（默认5分钟）开始逐出该节点上的Pod。

以下是一些关键参数：

参数名	默认值	描述
--node-monitor-grace-period	40s	心跳超时时间
--node-monitor-period	5s	控制器检查节点状态的时间间隔
--pod-eviction-timeout	5m	从节点NotReady到开始逐出Pod的等待时间

可以通过修改控制器管理器的配置来调整这些参数，以适应不同规模和网络环境的集群。

7.2 容器健康检查（Readiness、Liveness、Startup Probe）

7.2.1 探针类型与作用机制

Kubernetes提供了三种类型的容器健康检查探针：

• livenessProbe ：判断容器是否存活。若失败，Kubernetes将重启容器。
• readinessProbe ：判断容器是否准备好接收流量。若失败，Pod将从Service的Endpoints中移除。
• startupProbe ：判断容器是否启动完成。用于慢启动应用，避免在启动过程中触发liveness失败。

探针可以通过HTTP、TCP或执行命令的方式进行检测。以下是一个典型的探针配置示例：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

7.2.2 探针配置的最佳实践

• initialDelaySeconds ：合理设置启动延迟，防止容器启动慢导致误杀。
• periodSeconds ：根据服务特性设置检测频率，过高会增加系统负载。
• failureThreshold ：决定失败几次后触发动作，liveness一般为3次，readiness可根据需求设为更多。
• probe路径选择 ：应选择能真实反映应用状态的轻量级接口，避免影响性能。

示例：使用 exec 探针执行脚本检查容器状态

startupProbe:
  exec:
    command:
      - cat
      - /tmp/app_ready
  periodSeconds: 5
  timeoutSeconds: 3
  failureThreshold: 10

7.3 整体节点健康状态的判断逻辑

7.3.1 Kubelet上报的节点健康指标

节点的健康状态由多个Condition字段共同决定，主要包括：

• Ready ：表示节点是否可以调度Pod。
• MemoryPressure ：是否内存不足。
• DiskPressure ：磁盘空间是否不足。
• PIDPressure ：进程数量是否过高。
• NetworkUnavailable ：网络是否不可用。

这些Condition由kubelet定期采集并上报给API Server。例如：

kubectl describe node <node-name> | grep -A 5 "Conditions"

输出示例：

Conditions:
  Type             Status    LastHeartbeatTime                 LastTransitionTime                Reason              Message
  ----             ------    -----------------                 ------------------                ------              -------
  Ready            True      2025-04-05T10:00:00Z              2025-04-05T09:50:00Z              KubeletReady        kubelet is posting ready status
  MemoryPressure   False     2025-04-05T10:00:00Z              2025-04-05T09:50:00Z              KubeletHasSufficientMemory   ...

7.3.2 多节点健康检查的集中管理方案

对于大型集群，推荐使用以下方案进行节点健康状态的集中监控：

1. Prometheus + Node Exporter ：采集节点CPU、内存、磁盘等指标。
2. Alertmanager ：定义健康状态异常告警规则，及时通知运维。
3. Grafana ：可视化展示各节点的健康状态趋势。
4. 自定义控制器 ：基于Kubernetes Operator开发自定义节点健康控制器，实现自动修复逻辑。

示例：Prometheus监控节点CPU使用率

- targets: ['node-exporter:9100']
  labels:
    job: node

结合Grafana仪表盘，可实时查看所有节点的CPU、内存、磁盘压力等健康指标，便于及时干预。

（接续内容将在下一章节展开）

本文还有配套的精品资源，点击获取

简介：Kubernetes节点是集群中运行容器化应用的工作单元，包含kubelet、容器运行时和kube-proxy等核心组件。本文详细解析了节点的角色、状态管理、健康检查、资源调度、网络策略、持久化存储等内容，并介绍了节点升级和维护的最佳实践。通过学习本文，读者将掌握Kubernetes节点的核心原理与实际操作，提升集群管理的稳定性与效率。

本文还有配套的精品资源，点击获取