一、证书优化1、检查当前证书有效期先看看现状# 在master节点执行kubeadm certs check-expiration[rootmaster ~]# kubeadm certs check-expiration[check-expiration]Reading configuration from thekubeadm-configConfigMapinnamespacekube-system...[check-expiration]Usekubeadm init phase upload-config kubeadm --config your-config-fileto re-upload it. CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Mar 07,202703:24 UTC 364d ca no apiserver Mar 07,202703:24 UTC 364d ca no apiserver-etcd-client Mar 07,202703:24 UTC 364d etcd-ca no apiserver-kubelet-client Mar 07,202703:24 UTC 364d ca no controller-manager.conf Mar 07,202703:24 UTC 364d ca no etcd-healthcheck-client Mar 07,202703:24 UTC 364d etcd-ca no etcd-peer Mar 07,202703:24 UTC 364d etcd-ca no etcd-server Mar 07,202703:24 UTC 364d etcd-ca no front-proxy-client Mar 07,202703:24 UTC 364d front-proxy-ca no scheduler.conf Mar 07,202703:24 UTC 364d ca no super-admin.conf Mar 07,202703:24 UTC 364d ca no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Mar 04,203603:24 UTC 9y no etcd-ca Mar 04,203603:24 UTC 9y no front-proxy-ca Mar 04,203603:24 UTC 9y no2 、20年证书优化方案步骤1创建有效期配置文件# 创建证书有效期配置文件catcert-20y-config.yamlEOF apiVersion: kubeadm.k8s.io/v1beta4 kind: ClusterConfiguration kubernetesVersion: v1.35.0 certificateValidityPeriod: 175200h # 20年 20 × 365 × 24 caCertificateValidityPeriod: 175200h # 20年 clusterName: kubernetes controlPlaneEndpoint: 192.168.1.20:6443 networking: dnsDomain: cluster.local podSubnet: 192.168.0.0/16 serviceSubnet: 10.96.0.0/12 EOF步骤2完整备份必须# 创建完整备份BACKUP_DIR/root/k8s-backup-$(date%Y%m%d-%H%M%S)mkdir-p$BACKUP_DIR# 备份所有关键目录cp-r/etc/kubernetes$BACKUP_DIR/cp-r/var/lib/kubelet$BACKUP_DIR/cp-r$HOME/.kube$BACKUP_DIR/# 备份etcd数据如果重要etcdctl snapshot save$BACKUP_DIR/etcd-snapshot.db# 验证备份ls-la$BACKUP_DIRecho备份完成$BACKUP_DIR步骤3停止控制平面组件# 移动manifests目录停止所有控制平面Podmv/etc/kubernetes/manifests /etc/kubernetes/manifests.baksleep30# 等待Pod完全停止# 确认组件已停止crictl --runtime-endpoint unix:///var/run/cri-dockerd.sockps|grep-Ekube|etcd如果没有停掉就需要 1. 强制停止控制平面容器# 手动删除仍在运行的kube-apiserver容器crictl --runtime-endpoint unix:///var/run/cri-dockerd.sock stop 20b8239b6cbc4 crictl --runtime-endpoint unix:///var/run/cri-dockerd.sockrm20b8239b6cbc4# 检查是否还有其他控制平面容器在运行crictl --runtime-endpoint unix:///var/run/cri-dockerd.sockps-a|grep-Ekube-apiserver|kube-controller|kube-scheduler|etcd# 确认没有控制平面组件在运行crictl --runtime-endpoint unix:///var/run/cri-dockerd.sockps|grep-Ekube-apiserver|kube-controller|kube-scheduler|etcd# 也应该没有输出除kube-proxy外步骤4重新生成所有证书关键步骤20年有效期1、 先查看有什么证书# 确认控制平面已停止后执行证书操作cd/etc/kubernetesls-lapki/# 查看现有证书# 进入证书目录cd/etc/kubernetes# 备份当前证书虽然已经备份过但再确认一次***这个重要的证书****cp-rpki pki.bak.$(date%Y%m%d-%H%M%S)kubeadm 检测到 /etc/kubernetes/pki/ 目录下所有证书都已经存在为了安全起见它不会覆盖现有证书而是直接使用现有的。 需要强制重新生成证书要让 kubeadm 强制重新生成所有证书需要先删除现有的证书文件2、 删除现有证书但保留CAcd/etc/kubernetes/pki# 删除所有组件证书保留CA和sa密钥rm-fapiserver.* apiserver-kubelet-client.* front-proxy-client.*rm-fetcd/server.* etcd/peer.* etcd/healthcheck-client.* apiserver-etcd-client.*# 确认删除结果ls-la|grep-Eapiserver|etcd|front-proxy-client# 应该没有输出在实际操作中还会有etcd 证书删除# 进入 etcd 目录cd/etc/kubernetes/pki/etcd/# 删除所有 etcd 证书文件保留目录rm-fserver.* peer.* healthcheck-client.*# 确认删除结果ls-la/etc/kubernetes/pki/etcd/# 应该只显示 . 和 ..没有证书文件 etcd CA 核心文件说明文件名称作用重要性ca.crtetcd 根证书用于验证所有 etcd 相关证书的真伪⭐⭐⭐必须保留ca.keyetcd 根证书私钥用于签发新的 etcd 证书server/peer/client⭐⭐⭐必须保留 为什么必须保留根据 Kubernetes 官方文档etcd 的 CA 证书是整个 etcd 安全体系的根基ca.crt是公钥证书所有组件用它来验证 etcd 证书的合法性ca.key是私钥用来签发所有其他的 etcd 证书 证书签发关系etcd CA (ca.crt/ca.key) ── 签发 ──→ server.crt (etcd 服务端证书) ├── 签发 ──→ peer.crt (etcd 集群间通信证书) ├── 签发 ──→ healthcheck-client.crt (健康检查证书) └── 签发 ──→ apiserver-etcd-client.crt (APIServer 连接 etcd 用) 为什么 etcd 需要独立的 CA根据 StarlingX 的官方文档etcd 有自己独立的 CA 是 Kubernetes 的最佳实践 -2-3独立 CA 意味着 etcd 的安全体系与集群其他部分隔离即使集群 CA 出问题etcd 仍然可以独立运行这是 etcd 作为关键数据存储的额外安全保护后续升级集群 etcd 的 CA 证书在升级 Kubernetes 集群时不会自动升级需要你手动管理。3、执行证书生成现在一切就绪。请在 master 节点上执行以下命令# 进入 kubernetes 配置目录cd/etc/kubernetes# 执行证书生成命令kubeadm init phase certs all--config/root/cert-20y-config.yaml执行结果# 执行证书生成命令kubeadm init phase certs all--config/root/cert-20y-config.yaml W030713:16:28.73256561311validation.go:79]WARNING: certificateValidityPeriod: the value 175200h0m0s ismorethan the recommended defaultforcertificate expiration: 8760h0m0s W030713:16:28.73264861311validation.go:79]WARNING: caCertificateValidityPeriod: the value 175200h0m0s ismorethan the recommended defaultforCA certificate expiration: 87600h0m0s[certs]Using certificateDir folder/etc/kubernetes/pki[certs]Using existing ca certificate authority[certs]Generatingapiservercertificate and key[certs]apiserver serving cert is signedforDNS names[kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master]and IPs[10.96.0.1192.168.1.20][certs]Generatingapiserver-kubelet-clientcertificate and key[certs]Using existing front-proxy-ca certificate authority[certs]Generatingfront-proxy-clientcertificate and key[certs]Using existing etcd/ca certificate authority[certs]Generatingetcd/servercertificate and key[certs]etcd/server serving cert is signedforDNS names[localhost master]and IPs[192.168.1.20127.0.0.1 ::1][certs]Generatingetcd/peercertificate and key[certs]etcd/peer serving cert is signedforDNS names[localhost master]and IPs[192.168.1.20127.0.0.1 ::1][certs]Generatingetcd/healthcheck-clientcertificate and key[certs]Generatingapiserver-etcd-clientcertificate and key[certs]Using the existingsakey✅ 执行结果分析输出信息含义状态WARNING: certificateValidityPeriod...提醒20年超过默认值⚠️ 可忽略Using existing ca certificate authority保留集群根CA9年有效期✅ 符合预期Generating apiserver certificate...生成API Server证书20年✅ 成功Generating apiserver-kubelet-client...生成API Server访问kubelet证书✅ 成功Using existing front-proxy-ca...保留front-proxy CA✅ 符合预期Generating front-proxy-client...生成front-proxy客户端证书✅ 成功Using existing etcd/ca...保留etcd CA你特意保留的✅ 完全正确Generating etcd/server, etcd/peer...生成etcd服务端、对等、健康检查证书✅ 成功Generating apiserver-etcd-client...生成API Server连接etcd证书✅ 成功Using the existing sa key保留Service Account密钥✅ 必须保留✅ 生成的证书[rootmaster kubernetes]# ls /etc/kubernetes/pki -la总用量60drwxr-xr-x.3root root40963月713:16.drwxr-xr-x.5root root1843月712:55..-rw-r--r--.1root root12813月713:16 apiserver.crt -rw-r--r--.1root root11233月713:16 apiserver-etcd-client.crt -rw-------.1root root16793月713:16 apiserver-etcd-client.key -rw-------.1root root16753月713:16 apiserver.key -rw-r--r--.1root root11763月713:16 apiserver-kubelet-client.crt -rw-------.1root root16753月713:16 apiserver-kubelet-client.key -rw-r--r--.1root root11073月711:24 ca.crt -rw-------.1root root16753月711:24 ca.key drwxr-xr-x.2root root1623月713:16 etcd -rw-r--r--.1root root11233月711:24 front-proxy-ca.crt -rw-------.1root root16753月711:24 front-proxy-ca.key -rw-r--r--.1root root11193月713:16 front-proxy-client.crt -rw-------.1root root16753月713:16 front-proxy-client.key -rw-------.1root root16793月711:24 sa.key -rw-------.1root root4513月711:24 sa.pub[rootmaster kubernetes]# ls /etc/kubernetes/pki/etcd/ -la总用量36drwxr-xr-x.2root root1623月713:16.drwxr-xr-x.3root root40963月713:16..-rw-r--r--.1root root10943月711:24 ca.crt -rw-------.1root root16753月711:24 ca.key -rw-r--r--.1root root11233月713:16 healthcheck-client.crt -rw-------.1root root16793月713:16 healthcheck-client.key -rw-r--r--.1root root11923月713:16 peer.crt -rw-------.1root root16793月713:16 peer.key -rw-r--r--.1root root11923月713:16 server.crt -rw-------.1root root16753月713:16 server.key4、证书生成完成后还需要重新生成kubeconfig文件并恢复控制平面最后一步正确操作强制重新生成 kubeconfig如果不删除是不会被覆盖掉✅备份现有的 kubeconfig 文件可选但推荐# 创建备份目录mkdir-p/root/kubeconfig-backup-$(date%Y%m%d-%H%M%S)# 备份所有 .conf 文件cp/etc/kubernetes/*.conf /root/kubeconfig-backup-$(date%Y%m%d-%H%M%S)/✅删除现有的 kubeconfig 文件# 删除所有 kubeconfig 文件rm-f/etc/kubernetes/*.conf# 确认删除ls-la/etc/kubernetes/*.conf# 应该输出ls: 无法访问 /etc/kubernetes/*.conf: 没有那个文件或目录✅重新生成 kubeconfig 文件# 重新生成所有 kubeconfigkubeadm init phase kubeconfig all--config/root/cert-20y-config.yaml# 查看新生成的文件ls-la/etc/kubernetes/*.conf# 现在应该看到新文件日期是当前时间✅验证新 kubeconfig 文件# 查看 admin.conf 中的证书有效期应与新证书一致kubeadm certs check-expiration|grep-A5admin.conf✅更新你的 kubectl 配置## 用新生成的 admin.conf 覆盖# 将新的 admin.conf 复制为默认 kubectl 配置cp/etc/kubernetes/admin.conf$HOME/.kube/config# 验证文件时间戳已更新ls-la$HOME/.kube/config✅验证 kubectl 能否正常连接需等控制平面恢复mv/etc/kubernetes/manifests.bak /etc/kubernetes/manifests systemctl restart kubelet再次检查证书有效期是否达到预期kubeadm certs check-expiration✅ 最终验证确认证书类型当前过期时间剩余时间状态组件证书admin.conf、apiserver、etcd-peer 等2046 年 3 月 2 日19 年 11 个月✅ 20 年目标达成CA 根证书ca、etcd-ca、front-proxy-ca2036 年 3 月 4 日9 年✅ 正确保留 关键点验证所有组件证书均已更新admin.conf: 2046 年 ✅apiserver: 2046 年 ✅apiserver-etcd-client: 2046 年 ✅etcd-peer、etcd-server: 2046 年 ✅front-proxy-client: 2046 年 ✅所有列出的 11 个组件证书都显示为 2046 年CA 证书正确保留ca: 2036 年9 年etcd-ca: 2036 年9 年front-proxy-ca: 2036 年9 年 恭喜你的集群证书优化工作圆满成功现在你的 Kubernetes 集群已经具备了20 年证书有效期的坚实基础可以放心承载长期业务。后续只需按计划进行版本升级和日常监控即可。 证书管理方案对比对比维度方案A手动续期方案B分阶段生成 (你用的方法)方案C初始化配置核心原理使用kubeadm certs renew all命令基于现有证书模板进行续期。使用kubeadm init phase子命令模拟kubeadm init的过程重新生成指定的证书或配置文件。在集群初始化前通过修改kubeadm-init.yaml配置文件设定证书的有效期然后一次性创建所有证书。操作时机集群已存在证书即将过期时。集群已存在需要对证书进行更精细的控制或重新生成时。集群初始化之前。是否依赖CA依赖使用现有的CA证书和密钥进行签发。依赖使用现有的CA证书和密钥签发新证书。依赖同样需要CA。如果未提供kubeadm会生成默认的。优点简单快捷一条命令即可完成所有证书续期。灵活性高可以精确控制生成哪些证书适合需要对证书进行重构或调整的场景。一劳永逸在集群创建时就设定好超长有效期后续无需再为证书到期烦恼。缺点无法修改证书的有效期只能续期默认的1年。操作步骤相对复杂需要理解证书体系。集群创建后无法直接修改此配置。有效期结果所有证书有效期延长1年。通过配置文件中的certificateValidityPeriod字段可生成任意自定义有效期如20年的证书。在初始化时通过certificateValidityPeriod字段可生成任意自定义有效期的证书。二、集群pod数量优化成支撑10000个pod的优化方案1、查看当前节点能够支撑的pod数据目前最多支撑110个三个节点330个目前都可以支撑1000多个实在生产中应该也满足需求[rootmaster ~]# # 检查 allocatable 资源kubectl describe nodes|grep-A6AllocatableAllocatable: cpu:16ephemeral-storage:16364077029hugepages-1Gi:0hugepages-2Mi:0memory: 3328836Ki pods:110-- Allocatable: cpu:16ephemeral-storage:16364077029hugepages-1Gi:0hugepages-2Mi:0memory: 3328856Ki pods:110-- Allocatable: cpu:16ephemeral-storage:16364077029hugepages-1Gi:0hugepages-2Mi:0memory: 3328788Ki pods:1102、 硬件升级必须节点类型CPU 核心内存磁盘配置网络带宽Master64 核128 GBNVMe SSD100 GbpsWorker (x2)128 核512 GBNVMe SSD 独立数据盘100 Gbps3、 操作系统极限调优所有节点cat/etc/sysctl.d/99-k8s-10k.confEOF # 端口范围每个Pod可能占用多个端口 net.ipv4.ip_local_port_range 1024 65500 # 连接跟踪每个Pod可能有多条连接 net.netfilter.nf_conntrack_max 10000000 net.netfilter.nf_conntrack_tcp_timeout_established 86400 net.netfilter.nf_conntrack_tcp_timeout_time_wait 60 # 文件句柄每个容器可能有多个文件描述符 fs.file-max 50000000 fs.nr_open 50000000 # PID 限制每个容器一个PID kernel.pid_max 4194304 kernel.threads-max 10000000 # 网络缓冲区 net.core.rmem_max 134217728 net.core.wmem_max 134217728 net.ipv4.tcp_rmem 4096 87380 134217728 net.ipv4.tcp_wmem 4096 65536 134217728 net.core.netdev_max_backlog 50000 # 允许更多mmap区域 vm.max_map_count 262144 EOFsysctl-p/etc/sysctl.d/99-k8s-10k.conf4、kubelet 配置每个Worker节点编辑 /var/lib/kubelet/config.yaml 或通过启动参数maxPods:5000# 允许每节点运行5000个PodpodsPerCore:0# 不限制eventBurst:100# 增加事件突发容量eventRecordQPS:50# 提高事件QPSkubeAPIQPS:100# 与API Server通信的QPSkubeAPIBurst:200serializeImagePulls:false# 并行拉取镜像但可能耗尽磁盘I/O重启kubeletsystemctl daemon-reload systemctl restart kubelet5、 容器运行时优化若使用cri-dockerd需调整其并发能力可能需修改源码或换用containerd。建议改用 containerd原生CRI性能更好# 停止cri-dockerd启用containerdsystemctl stop cri-docker systemctl disable cri-docker systemctlenable--nowcontainerd修改kubelet启动参数为 --container-runtimeremote --container-runtime-endpointunix:///run/containerd/containerd.sock6、网络Calico极限配置Pod CIDR使用超大局域网段例如 10.0.0.0/8约1600万个IP# 安装Calico时指定kubectl apply-fhttps://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico.yaml# 修改ippoolkubectl patch ippool default-ipv4-ippool-p{spec:{cidr:10.0.0.0/8}}Calico 资源限制提高Felix的处理能力kubectlsetenvdaemonset/calico-node-nkube-systemFELIX_IPINIPMTU1480FELIX_VXLANMTU1450\FELIX_MAXCONNECTIONSPERHOST1000000FELIX_MAXCONNECTIONSPERHOST10000007、kube-proxyIPVS模式调优编辑ConfigMap kube-proxyapiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: ipvs ipvs: scheduler: rr strictARP:truesyncPeriod: 1m# 增大同步周期减少API压力minSyncPeriod: 30s conntrack: maxPerCore:0# 让系统自动管理tcpCloseWaitTimeout: 1h tcpEstablishedTimeout: 24h重启kube-proxy8. 控制平面极限调优API Server编辑 /etc/kubernetes/manifests/kube-apiserver.yaml添加---max-requests-inflight10000---max-mutating-requests-inflight5000---request-timeout5m---watch-cache-size1000# 增加watch缓存---watch-cache-sizesevents#1000---default-watch-cache-size1000---delete-collection-workers10---enable-aggregator-routingtrue---enable-priority-and-fairnesstrue# 启用APFetcd编辑 /etc/kubernetes/manifests/etcd.yaml- --quota-backend-bytes34359738368# 32GB- --auto-compaction-modeperiodic - --auto-compaction-retention6h - --snapshot-count100000# 降低快照频率- --heartbeat-interval500# 降低心跳频率- --election-timeout5000Controller Manager Scheduler- --kube-api-qps200- --kube-api-burst400- --concurrent-deployment-syncs50- --concurrent-replicaset-syncs509. 资源配额与准入控制为每个命名空间设置严格的 ResourceQuota 和 LimitRange强制每个Pod声明资源请求防止系统过载。例如每个Pod最小内存128Mi、CPU 100m则5000个Pod至少需要640Gi内存和500核CPU必须与硬件匹配。10. 监控与压力测试部署Prometheus Grafana重点关注API Server QPS/延迟etcd磁盘同步延迟10ms节点CPU/内存/网络/磁盘I/OPod启动时间IPVS连接数逐步加压测试观察资源使用和稳定性实际限制与结论即使完成上述所有配置在3节点上运行10000个Pod仍面临以下无法逾越的限制kubelet性能kubelet处理5000个Pod的周期性同步如状态上报、探针检查将耗尽CPU。容器运行时cri-dockerd或containerd创建/销毁数千个容器的能力有限。网络每个Pod可能占用多个端口、连接跟踪条目netfilter和IPVS表项将极其庞大5000个Pod × 服务数。控制平面API Server需处理来自3万个Pod的频繁心跳每个Pod有多个容器etcd可能成为瓶颈。硬件成本即使硬件达标成本也远超增加节点。最佳实践将10000个Pod分散到至少20-30个Worker节点每节点运行300-500个Pod配合上述优化才能实现稳定生产。三、kubeadm集群全方位优化指南1. 架构与高可用性这是集群稳定性的基石直接关系到能否应对节点故障。优化项关键操作与说明kubeadm关联控制平面高可用部署至少3个控制平面节点并使用负载均衡器如 HAProxy Keepalived暴露 API Server 端点。--control-plane-endpoint参数指向负载均衡器地址。etcd 高可用选择堆叠式etcd与控制平面同节点适合中小规模或外部etcd集群性能更好更稳定适合大规模。通过kubeadm配置文件中的etcd字段定义。2. 安全加固安全是红线以下是kubeadm环境下最常见的加固手段。优化项关键操作与说明kubeadm关联API Server 安全禁用匿名请求 (--anonymous-authfalse)启用NodeRestriction准入控制器 (--enable-admission-pluginsNodeRestriction)限制kubelet权限。在kubeadm-config.yaml的apiServer.extraArgs字段中配置。etcd 数据加密配置EncryptionConfiguration对存储在etcd中的敏感资源如 Secrets进行静态数据加密。在kubeadm-config.yaml的apiServer.extraArgs中指定--encryption-provider-config。RBAC 最小权限实施最小权限原则严格管理ServiceAccount、用户和组的权限避免随意授予cluster-admin。kubeadm初始化的集群默认启用RBAC策略需自行定义。审计日志启用并配置审计日志 (Audit Logging)记录API请求的详细元数据便于安全分析和问题排查。在kubeadm-config.yaml的apiServer.extraArgs中指定审计策略文件路径。Pod 安全启用Pod Security Admission (PSA) 或部署OPA Gatekeeper等策略引擎强制执行Pod的安全标准如禁止特权容器。在kubeadm-config.yaml的apiServer.extraArgs中启用PodSecurity准入控制器。3. 性能与资源调优除了我们讨论过的maxPods还有更多精细化的控制。优化项关键操作与说明kubeadm关联kubelet 性能调整eventRecordQPS(事件记录速率) 和eventBurst避免日志淹没kubelet。在 kubelet 配置文件或kubeletExtraArgs中设置。kubelet 资源预留通过--system-reserved和--kube-reserved为操作系统和kubelet本身预留CPU和内存防止Pod争抢系统资源导致节点不稳定。在 kubelet 配置文件或kubeletExtraArgs中设置。kube-proxy 模式对于大规模集群使用 IPVS模式 替代默认的iptables模式以获得更好的负载均衡性能和更快的服务更新速度你已配置。通过kubeproxy.config.k8s.io配置中的mode: ipvs设置。容器运行时对于大规模场景推荐使用 containerd 而非 cri-dockerd其资源占用更小性能更好。在kubeadm-init.yaml的nodeRegistration.criSocket中指定。内核与系统参数持续监控并调优网络、内存、文件系统相关内核参数如我们之前已调整的net.ipv4.ip_local_port_range等。独立于kubeadm直接在操作系统层面配置。日志轮转配置kubelet的containerLogMaxSize和containerLogMaxFiles控制容器日志的轮转策略避免日志占用过多磁盘。在 kubelet 配置文件或kubeletExtraArgs中设置。4. 可观测性与自动化运维这是保证集群长期健康运行的眼睛和手。优化项关键操作与说明kubeadm关联监控告警部署 Prometheus Grafana Alertmanager 堆栈全面监控集群节点、控制平面组件、Pod和应用的指标并设置关键告警。无直接关联属于集群建成后的运维工作。日志收集部署 EFK (Elasticsearch, Fluentd, Kibana) 或 Loki Promtail 堆栈实现日志的集中收集、索引和查询。无直接关联属于集群建成后的运维工作。备份与恢复使用 Velero 等工具定期备份etcd数据和Kubernetes资源对象并演练恢复流程。无直接关联属于集群建成后的运维工作。证书自动化建立自动化证书续期机制通过CronJob定期执行kubeadm certs renew all避免证书过期导致集群不可用我们已手动延长但自动化思维通用。使用kubeadm certs renew命令。GitOps采用 Argo CD 或 Flux 等GitOps工具将集群配置和应用声明式地存储在Git仓库中实现自动同步和版本控制。无直接关联属于集群建成后的运维工作。