Kubernetes Handbook：Node（工作节点）核心概念与集群管理实战指南

教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载Node 是 Kubernetes 集群中的工作节点是 Pod 实际运行的物理机或虚拟机也是集群调度、资源上报与故障检测的基本单元。本文以 concepts/node.md 为主线系统讲解 Node 的地址Address、状态条件Condition、容量Capacity与版本信息Info四类状态信息的含义与判读方法并围绕kubectl cordon、kubectl drain、kubectl uncordon三大运维命令给出可复制的节点维护流程同时结合本仓库的 kubelet 配置文件、systemd 单元与 kubectl-cheatsheet.md 等实操资料深入到--hostname-override、unschedulable字段与 Pod Disruption Budget 等底层机制帮助读者既能看懂kubectl get nodes的输出也能安全、规范地完成一次节点的下线与维护。Node 在集群中的定位Node 是 Kubernetes 集群的工作节点可以是物理机也可以是虚拟机。在 Kubernetes 的经典架构中集群由 Master 与 Node 两类角色构成Master 承载 API Server、Controller Manager、Scheduler 等控制面组件而 Node 则运行 kubelet、kube-proxy 与容器运行时真正承载用户的工作负载。仓库的 concepts/index.md 中给出了整体架构视图其中 kubelet 负责维护容器的生命周期同时也负责 VolumeCSI和网络CNI的管理。从仓库的 practice/node-installation.md 可以看出一个标准的 Node 节点包含如下组件kubelet、kube-proxy、Docker容器运行时与 flannel网络插件并且每台 Node 节点上都需要安装 flannel。kubelet 启动后通过 TLS bootstrapping 向 kube-apiserver 发送 register node 请求从而把该节点注册进集群成为集群可调度资源的一部分。Node 的状态信息Kubernetes 通过NodeStatus持续收集并暴露节点的运行状态。使用kubectl describe nodes node即可查看某个节点的完整状态信息guide/kubectl-cheatsheet.md。Node 的状态信息分为四类Address、Condition、Capacity 和 Info。Address地址Node 的地址信息包括三类分别服务于不同的通信场景HostName节点的主机名可以被 kubelet 中的--hostname-override参数替代。在仓库的 etc/kubernetes/kubelet 中可以看到真实配置示例KUBELET_HOSTNAME--hostname-override172.20.0.113当节点的主机名不可靠例如 DHCP 分配的动态主机名或需要在集群内统一命名时就可以通过该参数强制指定节点在集群内注册的 HostName覆盖操作系统的主机名。ExternalIP可以被集群外部路由到的 IP 地址通常用于从集群外部访问该节点上的服务。InternalIP集群内部使用的 IP集群外部无法访问主要用于节点间通信与 Pod 调度。Condition状态条件Condition 用于描述节点当前的健康与资源压力状况是调度器与控制器做出决策的重要依据主要包括OutOfDisk磁盘空间不足时为True。ReadyNode controller 40 秒内没有收到节点的状态报告时为Unknown节点健康时为True否则为False。Ready 条件是最核心的健康信号kubectl get nodes输出中的STATUS列即由此而来。MemoryPressure当节点有内存压力时为True否则为False。DiskPressure当节点有磁盘压力时为True否则为False。查看所有节点是否就绪可以直接复用 guide/kubectl-cheatsheet.md 中提供的 JSONPath 技巧$ JSONPATH{range .items[*]}{.metadata.name}:{range .status.conditions[*]}{.type}{.status};{end}{end} \ kubectl get nodes -o jsonpath$JSONPATH | grep ReadyTrue当节点因为内存或磁盘压力进入MemoryPressure/DiskPressure状态时kubelet 会根据资源驱逐策略逐出部分 Pod 以恢复节点可用性这也是 concepts/pod-disruption-budget.md 中提到的由于节点资源不足而将容器逐出的非自愿中断场景之一。Capacity容量Capacity 描述节点可提供的资源上限主要包括CPU节点可用的 CPU 核数以千分之一核为单位即1000m 1 核。内存节点可用的内存容量。可运行的最大 Pod 个数受 kubelet 的--max-pods参数限制默认通常是 110。调度器Scheduler在做 Pod 调度时会以 Capacity 为基准扣除已分配Allocatable 之外的资源后判断节点是否有足够的剩余资源承接新的 Pod。Info版本信息Info 记录节点的软件与系统版本信息例如操作系统、Kubernetes 版本、Docker / 容器运行时版本等。通过kubectl describe nodes node的System Info部分即可查看常用于排查版本不匹配或升级前后的一致性核对。Node 管理cordon / drain / uncordon节点维护如下线物理机、升级内核、调整硬件是集群运维的日常操作。仓库的 concepts/node.md 给出了一套标准的三个命令工作流核心目的只有一个在节点不可用的整个过程中保证集群中运行的 Pod 不中断服务。禁止 Pod 调度到该节点kubectl cordonkubectl cordon nodecordon封锁命令将节点标记为不可调度unschedulable其底层实现是修改节点对象的spec.unschedulable字段为true。这一点在 guide/kubectl-cheatsheet.md 中有直接对应$ kubectl patch node k8s-node-1 -p {spec:{unschedulable:true}} # 部分更新节点也就是说kubectl cordon与上述kubectl patch的效果等价后者是前者更底层的等价操作。封锁之后已经运行在该节点上的 Pod不会被驱逐继续正常运行新创建的 Pod不会被调度到该节点上调度器会自动将其分配到其他可用节点通过kubectl get nodes查看时该节点的 STATUS 会显示Ready,SchedulingDisabled。驱逐该节点上的所有 Podkubectl drainkubectl drain nodedrain排空命令会删除该节点上的所有 PodDaemonSet 除外并在其他 node 上重新启动它们通常该节点需要维护时使用该命令。直接使用该命令会自动调用kubectl cordon node命令因此一个典型的排空流程是先封锁节点自动完成不再接收新的 Pod 调度再驱逐存量 Pod将普通 Pod 在其他节点重新创建维护期间节点处于排空状态直到维护完成。该命令会删除该节点上的所有 PodDaemonSet 除外在其他 node 上重新启动它们通常该节点需要维护时使用该命令。直接使用该命令会自动调用kubectl cordon node命令。当该节点维护完成启动了 kubelet 后再使用kubectl uncordon node即可将该节点添加到 kubernetes 集群中。需要注意的是drain驱逐 Pod 的过程实际上走的是 Eviction API这与 concepts/pod-disruption-budget.md 中关于自愿中断的论述完全对应集群管理员应使用遵循 Pod Disruption BudgetPDB的工具例如kubectl drain通过 Eviction API 驱逐 Pod而不是直接删除 Pod。当驱逐请求可能暂时被拒绝时drain 工具会定期重试所有失败的请求直到所有 Pod 都被终止或者达到配置的超时时间。对于设置了 PDB 的 Deploymentdrain会严格遵守可用副本数不低于 PDB 指定阈值的约束宁可阻塞等待也不会突破 PDB 底线这正是节点维护期间应用不中断服务的关键保障。恢复节点调度kubectl uncordonkubectl uncordon node当该节点维护完成启动了 kubelet 后再使用kubectl uncordon node即可将该节点添加到 kubernetes 集群中。uncordon会把节点的spec.unschedulable字段重新置为false节点恢复为可调度状态此后新创建的 Pod 又可以正常调度到该节点上。节点维护完整流程综合以上三个命令一次标准的节点维护流程如下# 1. 排空节点自动完成封锁 驱逐所有非 DaemonSet Pod kubectl drain node # 2. 查看节点状态确认 SchedulingDisabled kubectl get nodes # 3. 执行维护操作如升级内核、更换硬件等 # 维护完成后重新启动 kubelet # 4. 恢复节点调度 kubectl uncordon node与节点管理相关的其他操作节点管理不只是封锁与排空仓库中还有两类与其密切相关的操作值得掌握。查看与标记节点查看节点详细信息kubectl describe nodes my-node获取所有节点的 ExternalIP$ kubectl get nodes -o jsonpath{.items[*].status.addresses[?(.typeExternalIP)].address}查看节点的资源使用指标需要 Metrics Server / Heapster 支撑kubectl top node my-node见 guide/kubectl-cheatsheet.md。用 Taint 控制节点调度除了封锁cordon这种一刀切的临时手段Kubernetes 还提供 Taint污点与 Toleration容忍机制做更精细的调度控制concepts/taint-and-toleration.md。二者的作用方式与节点亲和性相反具有 taint 的 node 和 pod 是互斥关系而具有节点亲和性关系的 node 和 pod 是相吸的。每个节点上都可以应用一个或多个 taint不能容忍这些 taint 的 Pod 不会被该节点接受而为 Pod 设置 toleration 后这些 Pod 可以但不要求被调度到具有相应 taint 的节点上。为 node1 设置 taintkubectl taint nodes node1 key1value1:NoSchedule kubectl taint nodes node1 key1value1:NoExecute kubectl taint nodes node1 key2value2:NoSchedule删除 taint 与查看 taintkubectl taint nodes node1 key1:NoSchedule- kubectl taint nodes node1 key1:NoExecute- kubectl taint nodes node1 key2:NoSchedule- kubectl describe nodes node1在 Pod 的 spec 中设置 tolerations 字段可以有多个 keytolerations: - key: key1 operator: Equal value: value1 effect: NoSchedule - key: key1 operator: Equal value: value1 effect: NoExecute - key: node.alpha.kubernetes.io/unreachable operator: Exists effect: NoExecute tolerationSeconds: 6000其中value的值可以为NoSchedule、PreferNoSchedule或NoExecutetolerationSeconds是当 Pod 需要被驱逐时可以继续在 node 上运行的时间。Kubernetes 内置的node.alpha.kubernetes.io/unreachable污点会在节点不可达时自动添加配合tolerationSeconds可以控制 Pod 在节点失联后继续存活的时长这与drain驱逐是互补的两套保障机制。从配置到命令kubelet 与节点的真实落地为了把上述概念落到真实环境可以对照仓库中 kubelet 的完整配置链路理解节点注册与状态上报的实现环境配置文件 etc/kubernetes/kubelet 中KUBELET_ADDRESS、KUBELET_HOSTNAME即--hostname-override、KUBELET_API_SERVER、KUBELET_POD_INFRA_CONTAINER等参数逐一决定了节点监听的地址、在集群中注册的名称、接入的 API Server 地址与 Pod 基础设施镜像systemd 单元 systemd/kubelet.service 通过EnvironmentFile-/etc/kubernetes/config与EnvironmentFile-/etc/kubernetes/kubelet加载上述配置并最终以ExecStart/usr/bin/kubelet ...启动 kubelet在 practice/node-installation.md 中可以看到kubelet 启动时向 kube-apiserver 发送 TLS bootstrapping 请求需要先把kubelet-bootstrap用户赋予system:node-bootstrappercluster 角色kubelet 通过认证后发送 register node 请求还需要把kubelet-nodes用户赋予system:nodecluster 角色并加入system:nodes组之后节点才真正出现在集群中。也就是说Node 之所以能出现在kubectl get nodes列表中、能上报 Address / Condition / Capacity / Info 状态、能被 cordon / drain 管理其背后是 kubelet 从注册、认证到周期心跳上报的一整套机制在支撑。理解了这一链路再看kubectl drain与kubectl uncordon的运维语义就会清晰很多封锁与排空只是控制面侧的标记与驱逐动作而节点重新加入集群的前提始终是 kubelet 进程恢复正常并向 API Server 持续上报状态。参考文档concepts/node.mdNode 状态与 cordon / drain / uncordon 管理命令guide/kubectl-cheatsheet.md节点相关 kubectl 速查命令concepts/taint-and-toleration.mdTaint 与 Toleration 调度控制concepts/pod-disruption-budget.mdPDB 与kubectl drain的 Eviction API 配合practice/node-installation.mdNode 节点安装与 kubelet 注册流程etc/kubernetes/kubelet、systemd/kubelet.servicekubelet 配置与启动单元concepts/index.mdKubernetes 整体架构与组件职责赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Laravel FastLogin部署指南生产环境配置与性能调优Laravel FastLogin部署指南生产环境配置与性能调优 Laravel FastLogin是一款强大的扩展包允许你的用户通过FaceID或ToucApollo核心概念详解命名空间与集群管理Apollo核心概念详解命名空间与集群管理 本文详细解析了Apollo配置中心的核心概念重点介绍了命名空间的设计理念、类型体系及其在实际应用中的使用场景。命配置中心后端微服务Playwright CLI与npx playwright终极API差异与兼容性处理指南Playwright CLI与npx playwright终极API差异与兼容性处理指南 Playwright CLI是一个专为浏览器自动化设计的命令行工具AI 技能浏览器控制GUI 自动化测试上一篇Chromeless HTML获取方法提取页面源代码的两种方式下一篇Cosmos-Reason2-32B API参考手册从基础调用到高级集成的完整文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考