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 恢复。