Ubuntu 上部署 Kubernetes 的最佳实践
一 规划与版本选择
- 选择 Ubuntu 22.04/24.04 LTS，内核与驱动生态稳定；容器运行时优先 containerd 1.6+，与 kubelet 的 systemd cgroup 驱动一致，减少资源争用与兼容性问题。
- 版本策略建议固定小版本，例如 Kubernetes v1.28.x LTS，便于安全补丁与兼容性管理；避免跨小版本混用组件。
- 节点规划：控制平面至少 3 台以实现 etcd 多数派与调度器/控制器高可用；工作节点按业务峰值与容灾预留冗余。
- 场景匹配：本地开发/CI 可用 Minikube/Kind；边缘与资源受限环境可用 K3s；生产自托管优先 kubeadm；云上优先托管 EKS/AKS/GKE/ACK 以降低运维复杂度。
二 系统与安全基线
- 基础配置（所有节点）：
- 关闭 Swap：swapoff -a 并注释 /etc/fstab 中的 swap 行；内核参数启用桥接与转发：
- net.bridge.bridge-nf-call-ip6tables = 1
- net.bridge.bridge-nf-call-iptables = 1
- net.ipv4.ip_forward = 1
- 加载模块：modprobe br_netfilter；确保主机名唯一并配置 /etc/hosts 或 DNS 可解析。
- 容器运行时与 kubelet：
- 安装并生成默认配置：containerd config default | tee /etc/containerd/config.toml；将 SystemdCgroup = true；重启 containerd。
- 安装 kubeadm/kubelet/kubectl 指定同一版本，启用 kubelet 开机自启。
- 安全加固：
- 启用 Pod Security Standards（PSS），至少使用 baseline；按需开启 审计日志 以满足合规（如 SOC2）。
- 启用 AppArmor/SELinux（Ubuntu 常用 AppArmor）；最小权限创建运维账号与 RBAC 绑定，避免在生产使用 root。
三 网络与高可用架构
- Pod 网络与网段：初始化时通过 –pod-network-cidr 指定与 CNI 插件一致的网段；例如 Calico 默认 192.168.0.0/16，或 Flannel 常用 10.244.0.0/16。
- 控制平面高可用：
- 使用 –control-plane-endpoint 指向外部 负载均衡器（VIP 或云 SLB）；常见做法为 HAProxy + Keepalived 提供 VIP，健康检查转发至各 Master 的 6443 端口。
- 多 Master 堆叠或外置 etcd 均可，生产推荐外置 etcd 与负载均衡前置，减少控制面单点风险。
- 端口与连通性：确保节点间与负载均衡器到节点的 6443（API Server）/ 2379-2380（etcd）/ 10250（kubelet） 等端口放通；云上优先使用 内网 SLB 与安全组白名单。
四 存储 可观测性与弹性
- 持久化存储：为数据库等有状态应用规划 动态供给（StorageClass） 与 备份/恢复 策略；在 Ubuntu 上优先使用成熟 CSI 驱动与本地卷/云盘组合，验证 拓扑与性能 后再上线。
- 可观测性：
- 部署 Metrics Server 以启用 kubectl top 与 HPA；
- 日志建议集中化（如 EFK/ Loki + Grafana），指标与日志统一到同一可观测平台，设置告警阈值与保留策略。
- 弹性伸缩：
- 工作负载使用 HPA（基于 CPU/内存或自定义指标）；
- 节点层面结合 Cluster Autoscaler 与云 Spot 实例 降低成本，设置节点组与污点/容忍度，保障关键负载稳定。
五 运维 备份与常见排错
- 备份与灾难恢复：
- 对 etcd 实施定期快照/备份（如 每日 CronJob），并进行 异地/离线 留存；定期演练恢复流程与一致性校验。
- 常用排错清单：
- Pod Pending：检查节点资源、污点/容忍度、CNI 是否就绪、PV/PVC 绑定状态；
- Service 无法访问：核对 Service/Endpoints、Pod 标签选择器、网络策略与云安全组/防火墙；
- 节点 NotReady：检查 kubelet、容器运行时、CNI 插件日志与内核日志（如 br_netfilter/转发）。
- 上线前自检：
- 固定组件版本、校验内核与驱动、验证 Pod CIDR 与 Service CIDR 不冲突、演练 控制面/etcd 故障切换与 etcd 恢复。