告别踩坑：Kubernetes 集群节点的四大核心配置指南

部署 Kubernetes 集群，不仅仅是执行 kubeadm init 命令那么简单。每个节点主机的底层配置，直接决定了集群的稳定性、性能和安全性。本篇文章将深入解析 Kubernetes 节点配置中的四大核心要素：Swap、DNS、防火墙和时间同步，并提供详细的实战配置指南。

1. Swap：为什么必须禁用？

核心要求： K8s 节点上严禁使用 Swap。这是 Kubernetes 官方的强制性要求。

深层原因：
Swap 机制将内存数据交换到硬盘，目的是防止内存耗尽。但在 Kubernetes 的高性能、高可用场景下，这会引发严重问题：

• 性能灾难：硬盘的 I/O 速度远低于 RAM。一旦 Pod 发生内存交换，其性能将急剧下降，可能导致应用延迟飙升，甚至引发连锁反应影响其他 Pod。
• 调度器误判：K8s 的调度器根据节点的真实资源情况（如 CPU、内存）来做出决策。Swap 的存在会使内存信息失真，导致调度器将 Pod 调度到看似有足够内存但实际上已经被 Swap 占用的节点上，造成资源分配不均。

实战配置：

1. 临时禁用：使用 swapoff -a 命令来禁用所有活动的 Swap 分区或文件。

   sudo swapoff -a
   

2. 永久禁用：这是最关键的一步。编辑 /etc/fstab 文件，该文件定义了系统启动时挂载的所有文件系统。

   sudo nano /etc/fstab
   

   找到其中包含 swap 关键词的行，通常类似于 /swapfile none swap sw 0 0。在其前面加上 # 将其注释掉，以防止系统重启后自动启用。

   # /swapfile none swap sw 0 0
   

   保存并退出文件即可。
3. 验证：重启后，使用 free -h 再次确认 Swap 行的 total 和 used 都为 0B。

2. DNS：确保内外网通信畅通

核心要求： 每个节点必须能够可靠地解析内外部域名。

深层原因：
DNS 在 Kubernetes 中扮演着至关重要的角色：

• 外部域名解析：节点上的 kubelet 需要解析镜像仓库的域名（如 registry.k8s.io）来拉取镜像。如果 DNS 配置错误，Pod 将无法启动。
• 主机名解析：在集群初始化和管理过程中，kubelet 和其他组件需要解析 kube-apiserver 的主机名。
• 集群内部服务发现：尽管 Pod 内部的 DNS 解析由 CoreDNS 管理，但 CoreDNS 本身也依赖于节点主机的 DNS 来解析外部域名。

实战配置（以 Ubuntu 20.04+ 为例）：
Ubuntu 默认使用 systemd-resolved 作为 DNS 解析器。

1. 检查服务状态：确保 systemd-resolved 正在运行。

   sudo systemctl status systemd-resolved
   

   其状态应为 active (running)。
2. 验证本地解析器：检查 /etc/resolv.conf 文件。正确配置下，它会指向本地的 127.0.0.53 地址，这是 systemd-resolved 监听 DNS 请求的地址。

   cat /etc/resolv.conf
   

3. 配置上游 DNS：如果你的网络环境没有自动分配 DNS，或者你想使用特定的 DNS 服务器，可以通过 netplan 进行配置。

   # /etc/netplan/01-netcfg.yaml
   network:
     ethernets:
       eth0:
         dhcp4: true
         nameservers:
           addresses: [8.8.8.8, 114.114.114.114]
     version: 2
   

   修改后，执行 sudo netplan apply。

3. 防火墙：安全与功能兼备

核心要求： 仅开放 Kubernetes 正常运行所需的特定端口，而不是关闭防火墙。

深层原因：
完全关闭防火墙会使主机的所有端口暴露在公网，存在巨大的安全风险。正确的做法是像一个守卫森严的大门，只允许 Kubernetes 组件之间以及外部管理工具的必要通信通过。

实战配置（以 UFW 为例）：
以下是 Kubernetes 默认使用的关键端口。

ufw 命令行配置示例：

1. 如果防火墙未启用，先启用它：

   sudo ufw enable
   

2. 添加规则：

   # 所有节点都需要开放的端口
   sudo ufw allow 10250/tcp comment 'Kubelet API'
   sudo ufw allow 22/tcp comment 'SSH'
   # 主节点专用端口
   sudo ufw allow 6443/tcp comment 'Kubernetes API Server'
   sudo ufw allow 2379:2380/tcp comment 'etcd server'
   sudo ufw allow 10251/tcp comment 'kube-scheduler'
   sudo ufw allow 10252/tcp comment 'kube-controller-manager'
   # 工作节点专用端口 (NodePort)
   sudo ufw allow 30000:32767/tcp comment 'NodePort Services'
   

4. 时间同步：分布式系统的心跳

核心要求： 所有节点必须通过 NTP 服务保持精确的时间同步。

深层原因：
时间同步在任何分布式系统中都至关重要，Kubernetes 也不例外：

• 认证和授权：Kubernetes 的证书和令牌（Token）都有严格的有效期。如果节点时间不同步，一个节点的证书在另一个节点上可能被认为已过期，导致认证失败。
• 日志和审计：不一致的时间戳会使日志分析变得异常困难。在排查问题时，你无法确定事件发生的真实顺序。

实战配置：
大多数现代 Linux 发行版都默认使用 systemd-timesyncd 或 chrony。chrony 通常被认为是更精确、更专业的选择。

1. 检查同步状态：

   sudo timedatectl status
   

   确认 System clock synchronized 状态为 yes。
2. 配置 NTP 源：
   • systemd-timesyncd：编辑 /etc/systemd/timesyncd.conf，在 [Time] 部分指定 NTP 服务器。

     [Time]
     NTP=ntp.aliyun.com time.windows.com
     

     重启服务：sudo systemctl restart systemd-timesyncd
   • chrony：编辑 /etc/chrony/chrony.conf，注释掉默认的 NTP 源，添加你自己的。

     # pool ntp.ubuntu.com iburst
     pool ntp.aliyun.com iburst
     pool time.windows.com iburst
     

     使用 chronyc sources 检查同步情况。

总结

这四项核心配置，是确保 Kubernetes 集群稳定、安全运行的基石。它们不仅是技术要求，更是对主机运维的严谨态度。在部署集群前，请务必将这份清单作为你的自查手册，确保每一项都已妥善配置。这将为你未来的 Kubernetes 之旅节省大量宝贵的故障排查时间。