在 Kubernetes（K8s）集群里，节点（Node）是运行容器化应用的 "硬件载体"，主要分控制平面节点和工作节点两类。
一、节点的两类角色
1. 控制平面节点（比如cka-master）
相当于集群的 "大脑"，负责管理整个集群，主要运行以下核心组件：
-
kube-apiserver：所有操作的入口，处理 API 请求；
-
etcd：存储集群所有配置和状态数据，像 "数据库"；
-
kube-scheduler：决定哪个 Pod 该放到哪个节点上；
-
kube-controller-manager：确保集群状态符合预期（比如 Pod 挂了自动重启）。
默认不让普通 Pod 运行在这里（有 "污点" 保护），避免业务影响管理功能。
2. 工作节点（比如cka-worker1、cka-worker2）
相当于集群的 "手脚"，专门运行业务 Pod，需要装这些基础组件：
-
kubelet：管理节点上的容器，确保 Pod 正常运行；
-
kube-proxy：处理网络规则，实现 Service 负载均衡；
-
容器运行时：比如 Docker，负责创建和启动容器；
-
网络插件：比如 Calico，让不同节点的 Pod 能互相通信。
没有默认 "污点"，是业务 Pod 的主要运行地。
二、节点调度：让 Pod 到指定节点运行
K8s 用 "标签 + 亲和性 + 污点容忍度" 控制 Pod 调度，简化后核心方法如下：
1. 标签 + nodeSelector（简单定向）
-
给节点打标签：比如给
cka-worker2标上 "用 SSD 硬盘" 的标签：kubectl label nodes cka-worker2 disktype=ssd -
让 Pod 只跑在有这标签的节点：在 Pod 的 yaml 里加
nodeSelector：yaml
spec: containers: - name: nginx image: nginx nodeSelector: disktype: ssd # 只调度到带ssd标签的节点
2. 亲和性（更灵活）
-
硬性要求：Pod 必须跑在符合条件的节点，没符合的就等着；
-
软性偏好：优先跑在符合条件的节点，没有就跑其他节点。
3. 污点与容忍度（节点 "拒绝" 与 Pod "允许"）
-
控制节点默认有 "污点"，不让普通 Pod 跑；
-
若要在控制节点跑 Pod，需给 Pod 加 "容忍度"（yaml 里加
tolerations字段），再配合nodeSelector指定节点。
三、节点维护：监控、升级与恢复
1. 监控节点资源
装metrics-server后，用kubectl top nodes看节点 CPU、内存使用情况，比如：
kubectl top nodes
# 能看到每个节点的资源占用率，及时发现瓶颈2. 节点升级（以控制节点为例）
-
先 "隔离" 节点：
kubectl cordon cka-master，不让新 Pod 进来； -
再 "驱逐" 旧 Pod：
kubectl drain cka-master --delete-emptydir-data --ignore-daemonsets，把现有 Pod 移到其他节点； -
升级组件：先更
kubeadm，再升控制平面组件，最后更kubelet和kubectl； -
恢复节点：
kubectl uncordon cka-master，让节点重新接收 Pod。
3. 数据备份（etcd）
控制节点的etcd存着集群核心数据，定期备份：
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save etcdbackupfile.db万一数据丢了，用备份恢复即可。
节点是 K8s 集群的基础，核心要点可简单记为：
角色分两类：控制节点管集群，工作节点跑业务；
初始化要规范：静态 IP、改源、设解析，一步不能少；
调度有方法：标签、亲和性、污点容忍度，按需选着用；
维护要有序：监控看资源、升级先隔离、数据常备份。
掌握这些，就能管好 K8s 节点，为后续跑业务 Pod 打牢基础。