Kubernetes集群运维实战：节点、证书与版本管理

1. Kubernetes集群运维实战概述在生产环境中运行Kubernetes集群就像驾驶一艘远洋货轮——看似平稳航行的背后需要持续的系统维护和精细操作。作为过去三年管理过数十个生产级K8s集群的老水手我总结出节点管理、证书更新和版本升级这三个最让运维团队头疼的暗礁区。本文将分享一套经过实战检验的完整操作方案特别适合已经部署了Kubernetes但尚未建立系统维护流程的团队。为什么这三个环节如此关键节点管理不当会导致计算资源浪费或服务中断证书过期直接造成集群瘫痪我见过太多凌晨三点被证书过期报警叫醒的案例而版本升级失败可能让整个集群回滚到初始状态。更棘手的是这些操作往往相互关联——你可能需要在节点维护期间完成证书轮换或者在升级版本时同步调整节点配置。2. 节点全生命周期管理2.1 节点健康状态监控体系建立节点健康监控不能仅依赖Kubernetes自带的Ready状态。在我的实践中会部署以下检查层级基础资源监控通过Node Exporter采集的指标包括# 关键磁盘空间指标示例 node_filesystem_avail_bytes{mountpoint/,fstype!tmpfs} / node_filesystem_size_bytes{mountpoint/,fstype!tmpfs} * 100 10当根分区使用率超过90%时触发预警这种情况经常导致kubelet异常。Kubernetes组件监控使用自定义Probe检查kubelet、container runtime等核心服务# 检查kubelet健康状态的简单脚本 curl -sk https://${NODE_IP}:10250/healthz | grep ok || echo kubelet unhealthy网络连通性矩阵通过NetworkPolicy和Service Mesh工具监控节点间的网络延迟和丢包率这对分布式存储类应用尤为重要。经验为每个监控指标设置合理的告警阈值和静默期避免由临时波动引发的告警风暴。我曾遇到一个集群因为默认的5分钟检测间隔导致告警延迟最终演变成雪崩式故障。2.2 节点维护的标准操作流程当需要下线节点进行维护时正确的驱逐(drain)操作顺序应该是标记节点不可调度kubectl cordon node-name优雅驱逐Podkubectl drain node-name --ignore-daemonsets --delete-emptydir-data这里的--delete-emptydir-data会清理临时数据避免残留数据占用空间。维护后重新上线kubectl uncordon node-name实际案例在为某金融客户执行内核升级时我们发现直接drain会导致某些有本地存储的StatefulSet无法迁移。解决方案是提前通过annotation标记特殊Podkind: Pod metadata: annotations: cluster-autoscaler.kubernetes.io/safe-to-evict: false2.3 节点自动修复方案对于大规模集群建议实现节点自愈能力。以下是基于Cluster API的自动修复流程通过MachineHealthCheck资源定义故障条件apiVersion: cluster.x-k8s.io/v1beta1 kind: MachineHealthCheck metadata: name: worker-node-healthcheck spec: clusterName: my-cluster unhealthyConditions: - type: Ready status: Unknown timeout: 5m - type: Ready status: False timeout: 15m结合AWS EC2 Auto Scaling或Azure VM Scale Sets实现自动替换。关键点新节点加入集群后需要预装必要的监控和安全组件这可以通过kubeadm的join配置或自定义DaemonSet完成。3. 证书管理深度解析3.1 Kubernetes证书体系全貌一个生产集群通常包含以下证书以1年有效期为例证书类型默认路径关键作用过期影响CA证书/etc/kubernetes/pki/ca.crt根证书全部组件无法验证API Server/etc/kubernetes/pki/apiserver.crt服务端认证API不可用etcd对等/etc/kubernetes/pki/etcd/peer.crtetcd节点间通信etcd集群分裂kubelet客户端/var/lib/kubelet/pki/kubelet-client-current.pem访问API Server节点失联3.2 手动更新证书的七个步骤以更新API Server证书为例备份现有证书cp -r /etc/kubernetes/pki /etc/kubernetes/pki.backup生成新证书注意SAN列表要完整openssl req -new -key apiserver.key -out apiserver.csr -subj /CNkube-apiserver \ -config (cat /etc/ssl/openssl.cnf (printf [SAN]\nsubjectAltNameDNS:kubernetes,DNS:kubernetes.default,...))使用CA签署openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out apiserver.crt \ -days 365 -extensions SAN -extfile (cat /etc/ssl/openssl.cnf (printf [SAN]\nsubjectAltNameDNS:kubernetes,...))更新Secret如果使用外部etcdkubectl -n kube-system create secret tls etcd-certs --certetcd.crt --keyetcd.key --dry-runclient -o yaml | kubectl apply -f -滚动重启控制平面组件docker restart kube-apiserver验证新证书openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A 1 Validity更新kubeconfig文件kubectl config set-cluster my-cluster --certificate-authority/etc/kubernetes/pki/ca.crt --embed-certstrue血泪教训曾经因为漏掉了Service Account的key pair更新导致所有Pod无法访问API Server。现在我会用这个命令检查所有证书find /etc/kubernetes/pki -type f -name *.crt -exec openssl x509 -noout -dates -in {} \; | awk -F {print $2} | sort3.3 自动化证书轮换方案对于Kubernetes 1.19版本可以启用kubelet自动证书轮换修改kubelet配置apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration rotateCertificates: true serverTLSBootstrap: true在Controller Manager启用相关特性apiVersion: kube-controller-manager.config.k8s.io/v1 kind: KubeControllerManagerConfiguration controllers: - * - csr-signing - csr-approving - csr-cleaner创建ClusterRoleBinding允许节点更新证书kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: auto-approve-csrs-for-group subjects: - kind: Group name: system:nodes apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: system:certificates.k8s.io:certificatesigningrequests:nodeclient apiGroup: rbac.authorization.k8s.io4. 版本升级策略与实践4.1 升级路径规划Kubernetes版本支持策略要求N-2版本兼容这意味着当前版本1.24可升级到1.25或1.26必须跳过直接升级到1.27会存在风险推荐升级顺序1.24.x → 1.25.y → 1.26.z4.2 控制平面升级详细步骤使用kubeadm升级控制平面的标准流程升级kubeadm工具yum install -y kubeadm-1.25.0-0 --disableexcludeskubernetes检查升级计划kubeadm upgrade plan输出会显示可升级版本和需要手动迁移的组件配置。应用升级kubeadm upgrade apply v1.25.0逐个节点升级kubeletyum install -y kubelet-1.25.0-0 kubectl-1.25.0-0 --disableexcludeskubernetes systemctl daemon-reload systemctl restart kubelet关键检查点确保etcd版本兼容kubeadm会自动处理检查API Deprecations列表验证自定义资源定义(CRD)的apiVersion4.3 工作节点滚动升级策略对于超过50个节点的集群建议采用分批次升级创建节点分组标签kubectl label nodes node-group-1 upgrade-groupgroup1使用DaemonSet控制并发度apiVersion: apps/v1 kind: DaemonSet metadata: name: node-upgrade-operator spec: updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2通过PodDisruptionBudget保护关键应用apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb spec: maxUnavailable: 1 selector: matchLabels: app: zookeeper4.4 升级后验证清单完成升级后必须检查核心功能测试kubectl get --raw/readyz?verbose网络插件兼容性kubectl -n kube-system logs -l k8s-appcilium存储卷测试kubectl exec -it test-pod -- df -h /data自定义资源验证kubectl get crd -o jsonpath{range .items[*]}{.metadata.name}{\n}{end} | xargs -I {} kubectl get {} -A5. 运维工具箱推荐5.1 必备CLI工具kubectl-neat清理kubectl输出中的集群模板信息kubectl get pod my-pod -o yaml | kubectl neatk9s终端可视化工具特别适合快速故障排查stern多Pod日志聚合工具stern -n production app.* --since 10m5.2 诊断脚本集锦节点资源使用分析脚本kubectl get nodes --no-headers | awk {print $1} | xargs -I {} sh -c \ echo {}; kubectl describe node {} | grep -A 5 Allocated resources; echo证书过期提醒脚本for cert in $(find /etc/kubernetes/pki -name *.crt); do echo $cert expires on $(openssl x509 -enddate -noout -in $cert | cut -d -f2) done | sort -k 35.3 配置管理最佳实践使用GitOps工具如Argo CD管理集群状态所有kubeadm配置版本化存储通过Policy-as-Code工具如OPA实施安全规范在长期维护中我发现将运维手册代码化能显著降低人为错误。比如把证书更新流程转化为Ansible Playbook或使用Tekton构建升级流水线。记住可靠的Kubernetes运维不是靠英雄主义而是靠可重复的自动化流程。