Ubuntu 上落地 Kubernetes 自动化运维的路线图
一 基础架构自动化
- 使用 Ansible 编排 Ubuntu 节点初始化与组件安装，保证一致性与可重复部署。
- 典型步骤：禁用 Swap、加载内核模块 overlay/br_netfilter、安装 containerd 并生成默认配置、安装指定版本的 kubeadm/kubelet/kubectl、启用 kubelet。
- 示例（Playbook 片段）：
- name: 关闭 Swap
command: swapoff -a
- name: 加载内核模块
shell: |
modprobe overlay
modprobe br_netfilter
- name: 安装 containerd
apt: name=containerd state=present
- name: 生成 containerd 配置
shell: containerd config default | tee /etc/containerd/config.toml
- name: 重启并启用 containerd
service: name=containerd state=restarted enabled=yes
- name: 安装 kubeadm/kubelet/kubectl
apt: name={{ item }} state=present
loop: [kubeadm,kubelet,kubectl]
- name: 启用 kubelet
service: name=kubelet enabled=yes
- 使用 kubeadm 初始化集群并安装网络插件（如 Calico），随后加入工作节点。
- 初始化示例：
- kubeadm init --pod-network-cidr=192.168.0.0/16 --apiserver-advertise-address=<MASTER_IP> --control-plane-endpoint=<VIP_or_MASTER_IP>
- 安装 Calico（与上面 Pod CIDR 保持一致）：
- kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml
- 工作节点加入：
- kubeadm join <MASTER_IP>:6443 --token --discovery-token-ca-cert-hash
- 端口与安全基线（防火墙仅放通必要端口，生产建议配合 RBAC/认证 与 镜像签名 等加固）。
二 应用交付自动化
- 以 Git 仓库 为唯一可信源，采用 GitOps 流水线（如 Argo CD/Flux）或 Jenkins/GitLab CI 驱动交付。
- 流程要点：代码提交 → 构建镜像（含 语义化版本 或 Commit SHA）→ 推送到镜像仓库 → 更新 Helm/Kustomize 清单或 GitOps 应用定义 → 自动同步到集群 → 健康检查与回滚。
- 用 Helm 管理复杂应用与版本化发布，结合 Helmfile 做多环境编排与批量操作。
- 常用命令：
- helm repo add stable https://charts.helm.sh/stable
- helm upgrade --install myapp stable/mychart -f values-prod.yaml --atomic --create-namespace
- 用 Kustomize 做环境差异化（dev/staging/prod）与 SealedSecrets 管理密钥，避免明文落地。
- 示例 Bash 自动化脚本（适合小规模或过渡阶段）：
- 部署并等待就绪：
- kubectl apply -f deployment.yaml
- kubectl rollout status deployment/myapp-deployment
- kubectl get pods
- 参数化与错误处理（示例）：
- if [ -z “$1” ]; then echo “用法: $0 ”; exit 1; fi
- kubectl apply -f “$1” || { echo “部署失败”; exit 1; }
- kubectl rollout status deployment/myapp-deployment || { echo “发布失败”; exit 1; }
三 可观测性与自愈
- 监控与告警：部署 Prometheus + Grafana（如 kube-prometheus-stack），覆盖 节点/Pod/控制面 关键指标，配置 CPU/内存/存储/网络 与 Pod CrashLoopBackOff 等告警规则。
- Helm 安装示例：
- helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
- helm install kube-prometheus prometheus-community/kube-prometheus-stack
- 日志管理：使用 EFK（Elasticsearch/Fluent Bit/Kibana） 或 Loki+Promtail 收集容器日志，建立 索引/保留策略 与 错误关键字 告警。
- 可视化巡检：使用 k9s 快速查看资源、日志与事件，配合 Popeye 做配置与健康扫描。
- 自动扩缩容：
- HPA（基于 CPU/内存/自定义指标）：kubectl autoscale deployment myapp --cpu-percent=50 --min=2 --max=10
- VPA（垂直伸缩，建议测试环境先行）
- KEDA（事件驱动伸缩，适配 Kafka/Prometheus/HTTP 等触发器）
四 备份恢复与高可用
- 证书与关键配置备份：
- 定期备份 /etc/kubernetes/pki 目录（证书轮换窗口内完成）。
- etcd 快照与恢复（控制面节点执行）：
- 快照保存：
- ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379
–cacert=/etc/kubernetes/pki/etcd/ca.crt
–cert=/etc/kubernetes/pki/apiserver-etcd-client.crt
–key=/etc/kubernetes/pki/apiserver-etcd-client.key
snapshot save /backup/etcd-$(date +%F).db
- 快照恢复（按官方步骤先停控制面组件，恢复后重启）。
- 高可用建议：
- 控制平面：至少 3 台 Master，前置 Keepalived/VIP 或 云负载均衡；对外暴露 API Server 6443。
- 工作节点：跨机架/可用区分布；为 NodePort 服务规划非冲突端口段（默认 30000–32767）。
五 平台化与日常运维
- 平台化工具选型（可视化管理与多集群能力）：
- Rancher：多集群/项目/用户与认证集成、监控与日志套件、应用商店。
- KubeSphere：多租户、DevOps 流水线、可观测、日志审计、服务网格等一体化能力。
- KubeOperator：轻量级发行版，规划/部署/运营生产级集群，支持离线环境与扩容。
- 日常巡检与合规：
- 巡检清单：节点 Ready、Pod Crash/重启、PVC/PV 绑定、镜像拉取失败、节点资源压力、控制面组件 CrashLoop。
- 合规与加固：启用 RBAC、Pod Security、NetworkPolicy、镜像仓库可信源、最小权限 ServiceAccount、Secrets 加密 与 审计日志。
- 建议的落地顺序：
- 第1阶段：用 Ansible 自动化部署与扩容，统一基线；
- 第2阶段：引入 GitOps 与 Helm/Kustomize，打通 CI/CD；
- 第3阶段：上线 监控/日志/告警 与 HPA/KEDA，完善可观测与弹性；
- 第4阶段：建设 备份/恢复 演练与 平台化（Rancher/KubeSphere/KubeOperator）。
