写到Kubernetes生产环境运维这块很多团队都会在TKE腾讯云容器服务和ACK阿里云容器服务之间纠结。这两个都是国内主流的公有云托管Kubernetes平台也是我在日常工作中接触最多的两类生产集群。这篇内容就把它们放在一起从选型、建集群、日常运维、高可用设计、成本控制到问题排查完整梳理一遍生产级集群的运维要点。无论是已经在用TKE/ACK的老手还是正准备从自建K8s迁到公有云的团队都可以直接拿来当操作手册。这篇指南偏实战不会花太多篇幅讲Kubernetes基础概念而是围绕这两个云平台的不同点、控制台操作细节、底层机制展开。很多结论是我在多个生产项目里踩坑总结出来的不一定适用于所有场景但至少能帮你在大方向上少走弯路。1. 架构选型托管集群为什么是生产首选1.1 TKE 与 ACK 的定位差异TKE和ACK都提供托管版集群也就是控制面API Server、etcd、Controller Manager、Scheduler由云厂商负责维护用户只需要管理节点池和工作负载。这个模式下你不需要关心etcd备份、控制面HA、API Server证书轮换这些基础运维工作这对绝大多数团队来说是最省心的选择。腾讯云把这种方式叫托管版阿里云则分为托管版ACK标准版和专有版ACK专有集群。选择建议很直接新集群一律选托管版。专有版虽然给了你控制面的完全访问权限可以SSH到master节点看起来更“自由”但代价是你得自己承担控制面的全部运维责任升级、etcd备份、故障恢复每一样都够你喝一壶。除非有极其特殊的需求比如必须要改API Server的启动参数否则没必要选专有版。自建Kubernetes集群我也维护过一段时间对比下来最大的痛点不是安装而是后续的升级和故障修复。kubeadm init出来的集群虽然初始化时有preflight检查就是网上常看到的[init] using kubernetes version和[preflight] running pre-flight checks这些输出看起来挺正规但到了大版本升级、etcd迁移、证书轮换的时候每一步操作都得小心翼翼稍有不慎就是整个集群不可用。托管集群把这些最麻烦的部分吃掉了代价是每个节点会有一些托管费用但从人力成本折算下来我觉得非常划算。1.2 网络插件选型VPC-CNI、Flannel 与 Terway 怎么选网络插件是所有Kubernetes集群里最影响架构的决策也是TKE和ACK差异最明显的地方。TKE默认支持两种网络模式Global Router基于Flannel的Overlay网络和VPC-CNI基于弹性网卡ENI的Underlay网络。ACK这边对应的是Flannel和Terway其中Terway也是阿里云基于ENI实现的Underlay方案。如果集群规模不大比如几百个Pod以内业务对网络性能没有极致要求Flannel/Global Router成本低、部署简单Pod网段和VPC网段不用强关联适合快速启动。但要注意Overlay网络因为有VXLAN封装转发路径上多了一层延迟和带宽都有损耗对延迟敏感的业务不友好。生产环境我更推荐直接上VPC-CNI/Terway。这个模式下Pod直接使用VPC内的IP地址不经过隧道封装网络性能和传统虚拟机基本一致。TKE的VPC-CNI原生支持固定IPStatefulSet类型的工作负载可以让Pod每次调度都拿到相同IPACK的Terway同样支持类似能力。另外Underlay模式下的Pod可以直接绑定安全组实现更细粒度的网络隔离。选型时有几个硬性条件要提前确认Pod网段和VPC网段不能重叠否则路由表会混乱。VPC-CNI/Terway要求每个节点有足够的可用ENI配额和IP配额集群规模大了以后要注意配额上限。如果业务里有大量短连接、高并发场景更倾向于用Underlay网络。架构上我倾向于将不同业务拆到不同集群或不同命名空间然后用网络策略NetworkPolicy做隔离。TKE和ACK现在都支持NetworkPolicy但Flannel模式下要额外装Calico组件VPC-CNI模式下可以直接利用安全组实现类似效果这也是我推荐Underlay的另一个原因。1.3 生产环境的版本与地域规划版本选择上有一个很现实的建议不要用最新版本也不要用快停止支持的旧版本。比如当下的主流版本在1.26到1.30之间选一个已经发布了半年以上、生态工具兼容性好的版本最稳妥。TKE和ACK的版本支持周期不同但都支持跨版本升级建议在创建集群时选一个比最新版本低一个小版本的版本号给自己的业务留出适配时间。地域规划方面首先要保证集群开启多可用区部署。TKE和ACK都支持在创建时将节点池分布在多个可用区控制面会自动跨可用区高可用。其次要考虑业务的地域属性例如华东用户多就优先选上海或杭州华北用户多就优先选北京。跨地域容灾集群属于进阶话题后面高可用章节会细说。如果公司有多云策略同一个业务同时跑在TKE和ACK上一定要尽早统一两边的Kubernetes版本和对象定义。TKE和ACK虽然都是标准的Kubernetes发行版但在部分CRD、负载均衡器配置、存储类名称上有差异将这些差异封装在应用层比如用Helm Chart统一模板能省下大量心智负担。2. 集群创建与初始化从控制台到底层细节2.1 创建集群的关键参数与网段规划创建生产集群不是点几下鼠标那么简单很多参数一旦声明后期修改成本极高。先说容器运行时。TKE和ACK现在已经默认使用containerd不再推荐Docker。不要因为习惯而坚持用Dockercontainerd在稳定性、镜像拉取性能、资源占用上都更好而且底层CRI标准是一致的。如果你手上有老脚本依赖Docker命令建议写成OCI标准的方式或者通过crictl命令来替代。网段规划是创建集群时最需要认真填的字段。每个云厂商都会要求你填写VPC网段、Pod网段或容器网段、Service网段。这里有几个核心原则VPC网段按实际业务规模规划如果有多个Kubernetes集群复用同一个VPC每个集群的Pod网段和Service网段都要提前分配好不能重叠。Service网段一般不大几百到几千个IP就够用对应/24到/20但一旦集群创建后不能修改。Pod网段规划要考虑未来的扩展例如每个节点最多多少个Pod、集群总Pod规模上限、是否需要固定IP等不要为了省IP而卡死自己。我踩过一个印象很深的坑某个测试集群创建时随手填了Pod网段后来业务扩容后发现网段太小几千个Pod直接把IP池打满最后只能重建集群。所以创建前先花半小时把未来一到两年的规模预估一下比事后迁移集群省太多时间。安全组方面TKE和ACK的节点默认都会加入一个安全组。生产环境建议不要直接修改默认安全组而是创建独立的安全组来管控节点之间的互访规则。你还需要关掉控制台的公网访问或者至少加上访问来源IP白名单。2.2 节点池设计与亲和性规划节点池是TKE和ACK都非常依赖的概念。节点池可以理解为一组具有相同配置机型、镜像、标签、计费方式、伸缩策略的节点的集合不同节点池服务于不同业务形态。生产环境里我是这样划分节点池的系统节点池部署集群核心组件如CoreDNS、日志采集DaemonSet、监控Agent使用较小规格的实例2C4G或4C8G给组件预留充足的CPU和内存。在线业务节点池部署常规无状态服务使用通用型或计算型实例开启集群自动扩缩容。大数据/离线任务节点池使用高规格实例例如内存型或高IO型配合节点亲和性、污点容忍度调度Spark、Flink等任务避免和在线业务互相影响。节点池划分完之后前期就要通过标签、污点、亲和性设置细化调度规则。比如系统节点池打上dedicatedsystem标签并加上CriticalAddonsOnlytrue:NoSchedule污点让非系统Pod不调度上去离线任务节点池加上dedicatedoffline污点只允许显式容忍该污点的Pod部署。TKE和ACK都支持为节点池设置“节点数范围”和弹性伸缩策略这部分我放在后面“扩缩容”详谈。这里要提醒的是不要把所有节点塞进一个池子否则一旦某个可用区出问题整个业务都会受影响。2.3 初始化必做的三件事日志、监控、告警很多集群刚创建出来日志、监控、告警全都没配等到生产出问题才手忙脚乱开控制台查。托管集群的控制面虽然不需要你管但业务侧的日志和监控必须自己提前搭好。TKE这边可以用日志服务CLS采集容器stdout和日志文件ACK对应的是日志服务SLS。两者都支持通过控制台一键给集群安装日志采集组件然后通过配置采集规则把日志投递到日志服务。采集规则强烈建议按命名空间和业务标签来配置不要全局一把梭否则日志量太大会烧钱查询速度也会慢。监控方面两个平台都提供了容器监控能力TKE的云原生监控集成Prometheus体系、ACK的云监控和Prometheus托管服务。生产集群至少要有以下指标看板节点维度CPU、内存、磁盘IO、网络流量、文件系统使用率。工作负载维度Pod重启次数、请求QPS、错误率、P99延迟、容器内存使用量。集群维度API Server请求延迟和错误码分布、etcd健康状态、调度器失败任务数。告警规则不要只配置节点存活这一种。我的经验是至少配上下面几类规则节点状态为NotReady持续5分钟。工作负载Ready副本数小于期望副本数持续10分钟。节点CPU使用率超过85%、内存使用率超过90%持续15分钟。Pod频繁重启5分钟内超过5次。集群API Server错误率超过5%。这里提一句很多团队喜欢在告警时手动ack掉控制台里点确认收到然后就不管了。我见过太多因为“手动ack再也没跟进”导致的事故。告警处理不是点一下按钮而是要去找到根因并解决否则下次还会爆发。3. 日常运维的核心动作升级、扩缩容与存量治理3.1 集群升级控制台流程与实际操作注意点混合云环境里升级Kubernetes是公认的高危操作云厂商托管集群把它变成了控制台里的“几步点击”但仍然需要谨慎对待。TKE和ACK的升级方式略有不同但大体都分为控制面升级和工作节点升级或节点池升级两个阶段。控制面升级通常比较安全因为API Server、etcd的配置是云厂商统一维护的升级过程中可能出现短暂的API不可用但对已有的Pod和Service一般没有影响。工作节点升级则是真正的风险点因为节点需要被排空drain、驱逐Pod如果节点上有本地数据emptyDir、hostPath就会丢失如果工作负载没有正确配置PDBPodDisruptionBudget和优雅停机就会触发大量服务中断。升级前有几件事必须做确认业务侧使用的API资源在新版本中没有被移除或废弃。可以用kubectl convert或者云平台提供的版本兼容性检查工具提前确认所有CRD、自定义资源在目标版本下可用。检查应用清单中的镜像兼容性特别是使用了kubectl apply和旧版API的工作负载升级后API版本过期会导致清单无法解析。开启PDB确保关键应用在节点排空期间核心服务不中断。如果之前没设置升级前至少要给无状态应用补上PDB配置。备份重要的自定义资源。虽然云厂商托管版有控制面自动备份但业务自定义资源如Ingress配置、ConfigMap、Secret、CRD实例不在云厂商备份范围内自己用Velero或kubectl get resource -o yaml导出留底。在升级时间窗口上选择业务低峰期且确保有“回滚预案”。TKE和ACK都支持版本回滚但仅限于一定的时间范围内过了窗口期就只能往前升级所以低峰操作很重要。升级过程中我会先升级一个节点池里的一个节点做验证确认核心业务在这个节点上调度正常、网络通畅再滚动升级剩余节点。这个“先放一个探路者”的习惯帮我避免了好几次大规模故障。3.2 自动扩缩容与节点池弹性生产集群的资源利用率普遍不高普遍在30%到50%左右。原因是避免峰值突发时资源不足但这是对云成本的巨大浪费。利用Kubernetes的HPAHorizontalPodAutoscaler 集群自动扩缩容可以很好地把水位控制在合理范围。HPA配置时要考虑几个参数minReplicas和maxReplicas、targetCPUUtilizationPercentage、cooldown冷却时间。TKE和ACK都支持在控制台直接创建HPA规则也可以直接用YAML管理。这里给一个参考配置apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: sample-web spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: sample-web minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60节点池弹性方面TKE的节点池和ACK的节点池都支持根据集群Pending Pod数量自动扩容节点缩容则基于节点利用率。这里有几个生产实践经验给节点池设置合理的弹性范围不要设置过大的最大值否则遇到流量波动会瞬间创建大量节点账单分分钟失控。扩容冷却时间建议按云厂商默认配置微调一般设置5到10分钟避免反复扩容缩容的“抖动”。缩容时要开启“节点保护”比如TKE的缩容保护、ACK的缩容保护开关防止承载了关键Pod的工作节点被自动回收。可以考虑加一台小规格的稳定实例专门承接突发的扩容间隙流量避免扩容期间Pod一直处于Pending状态而拖垮用户体验。另外提醒一下HPA和VPA不要同时配置同一个Deployment它们对副本数和资源配额的调整逻辑会互相打架导致调度器反复调整Pod数量。新场景先用HPAVPA通常用于很难预估资源需求的有状态应用且要配合完善的监控指标。3.3 证书、密钥与权限轮转治理这个经常被忽略但对生产级的稳定性影响非常大。Kubernetes的组件之间通过TLS证书通信托管集群虽然不让你直接管理控制面证书但你的kubeconfig、集群内部的Secret、各类API凭证都需要按期轮转。TKE和ACK的kubeconfig默认有效期各不相同一般在几年之内。你需要记录每个集群kubeconfig的过期时间并在过期前重新下载更新。可以写一个定时提醒脚本把每个集群的证书过期时间存到租户的日历或内部运维系统。不要等业务发现kubectl报“证书过期或无效”才处理。Secret的管理建议统一使用云厂商的密钥管理服务比如TKE对接密钥管理系统KMS、ACK对接KMS或凭据管家。不要把数据库密码、第三方API Key直接明文写进Secret里至少在Secret中引用KMS加密的密文或者在应用侧通过外部密钥系统拉取。还有一点权限最小化。就算你是集群管理员日常操作也不要用admin账号。TKE和ACK都支持对接云访问管理CAM/RAM应该按角色配置不同权限开发人员只给命名空间级别的edit角色运维人员给集群级别的admin角色财务或审计人员只给只读权限。这样可以降低误操作风险也方便出事之后追责。4. 高可用与故障转移实战4.1 多可用区部署与Pod调度策略高可用不是云厂商托管版自带的属性而是需要你自己设计出来的。控制面多可用区高可用只是平台的基础能力业务侧如果不做多可用区部署集群再稳也会因为单可用区故障而断流。多可用区部署的第一步是节点池覆盖多个可用区。TKE和ACK在创建节点池时都支持选择多个可用区节点会自动打上topology.kubernetes.io/zone标签。第二步是让工作负载的Pod分布到不同可用区这个可以通过Pod拓扑分布约束或节点亲和性实现。下面是一个拓扑分布约束的配置片段spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topolology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: sample-web这个配置的意思是尽量让Pod均匀分布在不同的可用区最多允许1个Pod的偏差如果无法满足则不调度。加上这个约束后一台可用区故障时至少还有一半的Pod继续提供服务。有状态应用数据库、缓存、消息队列的高可用要复杂得多。云厂商提供的云盘TKE的CBS、ACK的云盘ESSD默认是单可用区存储跨可用区挂载一般不支持。因此数据库这类组件要使用云厂商的托管数据库服务TDSQL、RDS或者自建跨可用区的主从同步不建议直接在Kubernetes里用本地存储跑核心数据。如果你的业务确实需要StatefulSet 云盘务必加上Pod反亲和确保每个副本调度到不同节点上避免一台物理机故障导致所有副本同时挂掉。4.2 集群级故障转移与快速恢复可用区故障、节点批量失联这类极端情况虽然罕见但必须演练过。这里我分享一套实战过的恢复流程当看到多个节点同时进入NotReady状态时不要慌张先在云厂商控制台检查是否为可用区级别的故障比如云平台公告。确认是可用区故障后如果业务Pod没有设置跨可用区容忍和反亲和需要快速将故障可用区的Pod调度到健康可用区。最简单的方式是调整Deployment的副本数或者直接删除故障节点上的Pod让调度器重新分配到健康节点。如果业务数据有依赖优先确保核心库可用。数据库如果用的是云数据库服务云厂商通常会有跨可用区高可用能力会自动切换如果是自建数据库就要靠提前配置好的主从切换脚本。恢复后不要马上把节点加回来先观察新节点上的Pod是否正常、网络是否连通、负载是否过高稳定一段时间后再慢慢恢复原有拓扑。集群级容灾要求你准备一个备用集群并且定期演练切换。TKE和ACK都有跨地域集群能力但真正的多集群切换需要配合DNS、负载均衡、配置同步工具。Velero是我用得比较多的备份恢复工具它可以备份整个集群的资源对象和PV快照。实践上我会把核心业务每隔6小时备份一次到对象存储TKE的COS、ACK的OSS同时在备用地域部署一套完全一样的集群用GitOps例如ArgoCD方式同步应用配置故障时直接拉起业务。4.3 多集群联合运维的思路一个公司如果有多个集群可能同时覆盖TKE和ACK还涉及多集群管理。不想给每个集群单独搞控制台账号的话可以从下面几个角度做统一运维在自建运维平台里统一汇总所有集群的kubeconfig用一个跳板机统一执行kubectl命令。通过KubeSphere这类可视化工具接入多个集群能比较方便地在统一界面上管理集群、项目和应用。KubeSphere对TKE和ACK都能通过kubeconfig纳管适合不想依赖云厂商自家控制台的团队。使用ArgoCD实现跨集群的应用同步。把目标集群和部署目录绑定同一套Helm Chart直接部署到多个集群镜像版本也统一管理。多集群运维要警惕配置漂移。同一个应用在两个集群里的配置不完全一致时很容易出现“测试集群正常、生产集群异常”的问题。所以尽量把配置模板化、环境差异化参数单独维护不手工在单个集群里去改动。5. 成本控制与资源治理5.1 节点规格与实例组合策略公有云Kubernetes最大的开销来自计算节点。选机型时不要清一色全上大规格也不要清一色用小规格要按业务类型分开。先讲一个通用经验无状态业务建议使用计算型或通用型实例如TKE的标准型S系列、ACK的通用型g系列如果是Web、API网关这类高并发小内存业务通常2C4G到4C8G就够了而且小规格实例更有利于弹性扩缩容时细粒度调节。内存型或高IO型实例留给缓存、数据库这类中间件。异构算力GPU不建议和CPU业务放在同一个节点池里GPU节点价格高且调度策略特殊单独管理更方便。包年包月和按量计费的混合使用很关键。基础负载使用包年包月或节省计划拉低成本突发负载使用按量计费实例配合弹性伸缩。TKE和ACK都支持在节点池维度设置不同的计费方式也支持按量转包年包月。对离线任务或非关键业务可以直接用云厂商的竞价实例TKE竞价实例、ACK抢占式实例价格往往只有按量的两折左右但要做好被回收的准备需要在代码里处理实例中断的优雅退出逻辑。优化扩容时还要关注镜像体积。每次扩容新节点都要拉取镜像镜像越大扩容时间越长成本越高。建议用云厂商提供的镜像加速能力TKE的镜像缓存、ACK的免密镜像缓存加速在集群创建时把常用镜像预缓存到节点本地这样扩容时Pod启动速度能从分钟级降到秒级。5.2 成本分析与配额治理成本控制最关键的是让每一笔云计算费用都能对应到一个业务、一个项目或者一个团队。TKE和ACK的控制台都有成本分析功能能够按命名空间、标签、集群维度展示成本和使用率但要让它发挥价值前提是你在创建资源时就规范打标签。建议强制要求所有Deployment、StatefulSet、Service、Ingress带上以下标签team: 所属团队business: 所属业务线env: 环境prod、staging、devcost-center: 成本中心TKE和ACK都支持通过控制台策略或OPA策略做标签校验不满足要求的资源创建请求直接拒绝。刚开始推行会很痛苦但养成习惯之后成本分析、业务排查都轻松很多。配额治理上至少要在命名空间级别配置ResourceQuota和LimitRange。ResourceQuota限制整个命名空间的CPU、内存、Pod数等总量LimitRange给单个Pod和容器设置默认资源请求和上限。很多生产事故的根因是某个业务写了一个没有资源上限的Pod把整个节点内存吃满拖垮了同节点的其他Pod。这个坑完全可以靠LimitRange提前规避。容灾演练也可以顺带做成本治理。比如每季度做一次资源水位分析找出CPU长期低于5%的闲置Pod、没有用户访问的测试环境、忘记删除的PVC和负载均衡器逐项清理。这些“僵尸资源”每季度大概能帮客户节省10%到20%的云账单效果非常直接。6. 常见问题与排查技巧实录6.1 节点NotReady与网络插件异常节点NotReady是生产环境出现频率最高、影响面最大的问题之一。排查的时候先分清楚是节点层面还是Pod层面。先看节点状态kubectl get nodes -o wide kubectl describe node node-name常见原因和应对方案如下表现象可能原因排查方向节点显示NotReady系统组件异常kubelet停止响应登录节点查看systemctl status kubelet和日志节点磁盘使用率超过90%镜像残留、日志文件过大、容器可写层膨胀清理无效镜像、限制日志轮转大小网络插件Pod反复重启VPC-CNI/Terway组件与底层VPC配置不一致检查节点ENI绑定情况、安全组规则节点内存耗尽容器内存无限制导致OOM检查LimitRange配置看系统日志里的OOM事件containerd/cgroup异常运行时卡死crictl ps、journalctl -u containerd查看运行时日志如果是网络插件导致的NotReadyTKE的VPC-CNI和ACK的Terway通常都有组件健康状态面板可以在控制台里看到每个节点的ENI/IPAM状态。手动修复前先记录所有网络Pod的日志防止恢复后信息丢失。6.2 DNS解析超时DNS问题是另一个高频故障类型。现象是Pod内域名解析间歇性失败、业务请求出现“connection refused”或“no such host”。排查时先看CoreDNS状态kubectl get pods -n kube-system -l k8s-appkube-dns kubectl logs -n kube-system deployment/coredns --tail50常见的原因包括CoreDNS副本数不足高并发查询时丢请求。建议生产集群至少运行2个副本并配置反亲和。上游DNS响应慢。CoreDNS默认会转发到VPC的DNS服务器如果VPC DNS有抖动会影响所有Pod解析。可以在CoreDNS配置里调大超时时间或配置备用上游。节点本地DNS缓存NodeLocal DNSCache未启用。流量大的集群建议开启节点级DNS缓存减少CoreDNS压力。TKE和ACK都有对应的NodeLocal DNSCache组件手动装上后能明显改善解析延迟。排查DNS问题时先用kubectl exec进入一个临时Pod反复执行nslookup和dig对比Pod内和节点上的解析结果快速定位是集群内DNS问题还是上游DNS问题。6.3 镜像拉取失败与私有仓库配置镜像拉取失败通常会显示ErrImagePull或ImagePullBackOff。单一节点拉取失败多数是节点认证问题整个集群都失败就要看仓库或者网络策略。如果使用云厂商的镜像仓库TCR/ACR或自建的Harbor出现拉取失败时先在节点上手动拉一次镜像确认基本连通性。然后重点检查以下几点Secret中仓库凭证是否过期。一般建议使用独立机器人账号并设置较长的有效期到期前更新关联的Secret。仓库是否配置了公网白名单或私有网络访问限制集群节点是否在这个允许范围内。镜像地址拼写是否正确。注意registry和namespace之间的路径要完整特别是私有镜像仓库经常会因为少写一个namespace导致404。如果使用了镜像加速器或镜像缓存检查缓存是否过期TKE和ACK的镜像缓存都支持配置有效期缓存过期后需要重新预热。镜像过大也会触发拉取超时。遇到这种情况不要在业务层面硬扛直接改成用镜像缓存或重新规划基础镜像降低镜像分层层数。6.4 负载均衡与Ingress问题TKE的Service类型LoadBalancer会创建CLBACK则创建SLB。使用中常见的坑是负载均衡器后端实例绑定异常、会话保持失效、健康检查误报。排查负载均衡问题时先到云厂商控制台看清楚负载均衡的监听器状态、后端服务器状态。如果后端服务器的健康检查失败多数是Pod没有监听预期端口或者节点安全组挡住了负载均衡的健康检查流量。TKE和ACK默认会自动放行负载均衡到节点的访问但如果你改了安全组规则很容易把这个放行规则覆盖掉。Ingress配置上优先使用云厂商提供的Ingress ControllerTKE的CLB Ingress、ACK的ALB Ingress它们对底层负载均衡的联动更自动。自建Nginx Ingress的时候要特别关注ingress-nginx的副本数是否大于1且部署时配置好externalTrafficPolicy: Local保留客户端IP或Cluster更好的负载均衡的取舍——前者延迟更低但会影响负载均衡转发后者更均衡但会丢失源IP。排查Ingress问题时优先看Ingress Controller的访问日志和错误日志kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail100然后看Ingress资源本身的事件kubectl describe ingress ingress-name大多数Ingress问题的根子都在注解配置错误比如跨域、重写规则冲突、上游超时设置不合理或者后端Service选择器没匹配上Pod。6.5 调度失败与资源不足Pod长时间处于Pending状态时kubectl describe pod会给出原因。系统提示Insufficient cpu、Insufficient memory、0/3 nodes are available这类信息时先排查资源是否真的不足还是因为污点/亲和性把调度卡住了。如果是资源不足直接扩容或调整副本数如果是调度策略问题检查节点标签、污点、亲和性表达式尤其是多个亲和性表达式叠加时很容易出现互相约束导致某个Pod永远没有合适的节点。还有一个很容易被忽略的问题Pod设置了resources.requests但节点上的可分配资源被系统组件占用。节点上除了业务Pod还有日志Agent、监控Agent、网络插件这类系统组件它们在计算节点资源时同样占用可分配量。给节点池预留一定的系统资源余量比如5%到10%会大幅度减少这类“明明CPU没满但就是调度不上去”的困惑。个人实操心得带我自己的团队迁到TKE和ACK这些年越到后面越觉得做生产级集群运维真正难的不是控制台操作或某个功能配置而是能不能把“高可用”“可观测”“成本可治理”这些要求落实到每一处细节里。托管平台解决的是底座可靠性业务侧的架构设计、资源规划、监控告警补全还是要靠自己。如果你只记住一句话那就是先定好网段和命名规范再谈弹性伸缩和成本优化先补好日志和监控再上生产流量先做一次故障演练再承诺给业务方“稳定运行”。最后再分享一个实用的小技巧我会在每次集群大版本升级前主动创建一个临时集群把核心业务的工作负载镜像在新集群里跑一遍验证兼容性并记录下所有异常输出。这个“冒烟集群”成本不高却能提前暴露绝大多数升级坑线上升级的稳妥度会提高好几个数量级。生产环境没有捷径但提前演好、准备好是可以做到让故障影响范围最小化的。