Appearance
04 - ACK 容器服务与云原生
本章目标：容器是简历核心竞争力，也是最容易被深挖的章节。要求讲清：ACK 产品族谱与托管 K8s 的差异、自建 K8s vs ACK 的选型论证（我的真实选择是移动云自建，理由要讲得掷地有声）、节点池、Terway 网络插件、ACK Serverless 概念、ACR 镜像仓库、SLS 日志、ARMS 一句话。水位：架构与选型【必背】，组件细节【理解】，Serverless 生态【了解】。
4.1 ACK 是什么——产品族谱【必背】
知识点：ACK（Container Service for Kubernetes，容器服务 Kubernetes 版）是阿里云的 K8s 托管平台，本质是帮你把 K8s 集群的生产化难题（控制面高可用、证书、组件升级、网络集成）平台化。产品族谱：
| 产品 | 形态 | 一句话 |
|---|---|---|
| ACK 托管版（Pro） | 控制面托管，节点是你的 ECS | 生产默认选择 |
| ACK 专有版 | 控制面也在你自己的 ECS 上 | 强自主，运维责任全在用户 |
| ACK Serverless | 无节点，Pod 直接跑在 ECI 上 | 按用付费，免运维节点 |
| ACK Edge | 边缘计算场景 | 云端管控+边缘执行 |
- 关键认知：托管版托的是控制面（apiserver/etcd/controller-manager/scheduler），不是节点——业务节点仍是你租的 ECS，节点上的 kubelet、容器运行时、节点的系统层维护仍是用户侧责任。
- 移动云对标：移动云有自己的容器平台产品线；我的真实实践是移动云 ECS 自建 K8s（三主三从），本章 4.2 详细论证。
标准回答（面试官问"讲讲你对 ACK 的理解"）：
ACK 是阿里云的 K8s 托管服务，我对它的定位是"把 K8s 生产化的脏活平台化"——控制面的 apiserver、etcd、调度器这些组件由阿里云托管，保证高可用和版本升级，用户只需要管业务节点。它有个产品族谱：托管版是主流，控制面托管、节点用 ECS；专有版控制面也放在自己机器上，自主性最强但运维全自己扛；Serverless 版干脆连节点都没有，Pod 直接跑在弹性容器实例上；还有边缘版。这里有个容易误解的点我特别说一下：托管版托的只是控制面，不是全部——节点上的 kubelet、运行时、系统层维护还是用户责任，就像我在移动云自建 K8s 时，节点层的内核参数、容器运行时、镜像基线都是我管的，只是控制面那部分在托管版里由平台兜底。我的真实经验是移动云三主三从自建集群，控制面高可用、CLB 接入、节点管理全是自己做的，所以我对"ACK 到底帮我省了什么"这个问题有非常具体的答案，不是背参数。
追问：K8s 控制面有哪些组件，各自什么职责？
apiserver 是唯一入口，所有增删改查都经过它，认证鉴权也在这层；etcd 是分布式 KV 存储，存集群全部状态，必须奇数节点做仲裁；scheduler 负责调度，把 Pod 按资源和亲和性约束绑到节点；controller-manager 跑各种控制器，副本数、节点状态、端点这些"期望与现实的差值"都是控制器收敛的；节点侧 kubelet 上报状态并按 spec 拉起容器，kube-proxy 维护 Service 的转发规则。我在移动云自建时这些组件的部署、证书、健康检查都亲手做过——三台 master 分摊 apiserver 和 etcd，CLB 四层统一接 6443。这套组件知识是自建训练出来的深度，也是我理解托管版价值的坐标系：托管版省的就是控制面这四件套的运维。
4.2 自建 K8s vs ACK——选型论证【必背——核心实战】
知识点：
| 维度 | ACK 托管版 | 自建 K8s（我的移动云方案） |
|---|---|---|
| 控制面高可用 | 平台托管保证 | 自己三 master + etcd 仲裁 + CLB 接入 |
| 控制面成本 | 按集群收托管费 | 无托管费（master 规格成本） |
| 证书/升级 | 平台自动化 | 自己管证书轮换、版本升级窗口 |
| 自主性 | 受平台约束（版本节奏、组件白名单） | 完全自主（组件、参数、调度策略） |
| 生态集成 | Terway/SLB/SLS/ACR 原生打通 | 自己对接（自建 Ingress、自建监控） |
| 能力建设 | 快速上生产 | 过程即能力建设 |
| 合规/政企偏好 | 数据出平台的问题要评估 | 数据链路完全自主可控 |
我的真实选型论证（STAR）：
S：项目二基于移动云交付 K8s 底座，客户是政企背景，预算受控。T：规划控制面高可用方案，在托管容器平台与自建之间做决策。A：我从四个维度论证——成本上，自建三台 2C4G master 的年成本低于托管控制面费用，且规格本来就小；自主性上，政企客户对平台依赖度敏感，证书、组件版本、调度策略完全自主掌握，出问题排查链路不跨平台；能力上，团队需要沉淀 K8s 全栈运维能力，自建过程本身就是最佳训练；风险上，我评估了自建的三大责任——etcd 仲裁与备份、证书轮换、版本升级，都有明确的应对方案（三副本仲裁、CLB 健康检查摘除、变更窗口+快照兜底）。R：集群平稳运行，三主架构扛住节点级故障演练，apiserver 统一接入零故障；同时团队形成了一套自建 K8s 的部署 SOP 与巡检清单。
标准回答（面试官问"为什么你的项目用自建 K8s 而不是 ACK/托管容器"）：
这是我真实做过的选型，我分四个维度讲。第一是成本：我们项目在移动云，预算受控，自建三台 2 核 4G 的 master 承载控制面，这个规格成本远低于托管平台的控制面费用，而且我们的集群规模小，控制面负载本来就轻。第二是自主性：客户是政企背景，对平台依赖度比较敏感，自建意味着证书、组件版本、调度策略完全在我们手里，排查问题不用跨平台提工单等响应。第三是能力建设：项目本身有培养运维能力的诉求，自建过程把控制面高可用、证书管理、节点纳管这些能力全练了一遍，这套能力到任何一家云都能迁移。第四是我对风险的评估：自建多出来的三大责任——etcd 仲裁、证书轮换、版本升级——我都有对应方案，三副本仲裁加 CLB 健康检查摘除、变更窗口加快照兜底。反过来我也清楚什么时候该选托管：集群规模大、业务快速增长、要深度用云生态的时候，ACK 的节点池、Terway 网络、SLB 自动联动这些集成能省大量自建工作量，这笔账我会算，只是当时的项目条件下自建是更优解。
追问 1：自建最大的三个坑是什么，你怎么防？
第一个是 etcd：它是集群的命脉，我的防法是三节点奇数仲裁、系统盘用 SSD、定期 etcdctl 备份快照落异地、master 打污点禁业务 Pod 防止资源被抢。第二个是证书：kubeadm 默认证书一年期，到期集群瘫痪，我的做法是部署时记录到期时间、纳入年巡检清单、用工具提前轮换并演练一次。第三个是版本升级：跨版本升级有前后依赖，我的纪律是小步走——先在测试集群演练升级路径，生产升级前打快照、按 master 逐台再 worker 逐台的顺序滚动，任何一步验证不过就停。我在移动云实践里这三个坑全部预先写入部署 SOP 和巡检清单，属于"防在事前"而不是"救在事后"。这三个坑也是我认为自建最有价值的部分——托管平台把这些自动化了，但只有亲手防过，才真正理解托管服务的价值在哪。
追问 2：如果让你重新选，还自建吗？
项目条件不变我还是选自建——预算、政企自主性、能力建设三个约束都在。但如果条件变化我会切换立场：业务量翻几倍、节点要频繁扩缩、要接日志和监控生态，托管版省下的运维工时就值回票价了。我的选型框架不是立场而是算账：自建省托管费但花人力，托管花托管费但省人力，规模越大托管的人力优势越明显；另外生态集成是托管的隐形价值，比如云负载均衡自动创建、日志组件一键安装，自建都要自己搭。所以我的答案是"条件决定结论"，而且我对两边的工作量分布有真实体感，这正是双云实践给我的判断力。
4.3 节点池【理解】
知识点：
- 节点池：阿里云 ACK 里"同规格、同标签、同污点、同系统配置"的节点的逻辑分组，是节点管理的单位。
- 价值：统一管理（批量升级系统镜像/K8s 版本）、差异化调度（按池打标签污点，业务亲和到对应池）、混合规格（不同业务用不同实例规格）、按需伸缩（池级别扩缩容）。
- 最佳实践：master 与业务分离（托管版天然分离）；业务池按负载画像分池（计算密集/内存密集分池）；给特殊节点打污点（GPU 池、专用中间件池）。
- 对标：我在移动云自建集群用 Label + Taint/Toleration + 节点分组手工实现了同样的管理意图（监控组件亲和到监控节点、业务 Pod 分散 worker）。
标准回答（面试官问"节点池是什么，解决什么问题"）：
节点池是 ACK 里节点管理的逻辑分组概念，把同规格、同系统配置、同标签污点的节点归成一个池，管理动作以池为单位做——批量升级系统镜像和 K8s 版本、按池扩缩容、按池配置网络模式，不用一台台机器操作。它的价值在异构管理：不同业务对节点的要求不同，计算密集的和内存密集的分池用不同规格，GPU 节点单独一池打上污点防止普通业务误调度上去。我在移动云自建集群里没有这个产品化能力，但我用 Label 加 Taint 手工实现了同样的管理意图——三台 worker 统一打业务标签、监控节点打污点只允许监控组件容忍、Pod 反亲和打散副本，这其实就是手工版的节点池。所以 ACK 的节点池对我来说是"把我手工做的事产品化"的理解，不是新概念，这也是我对标学习的方法：每个托管能力都还原成我自建时的对应操作。
4.4 Terway 网络插件【理解】
知识点：
- ACK 支持两大网络插件：Terway（阿里云原生）与 Flannel（社区经典）。
- Flannel 模式：Pod 网段是 overlay 虚拟网段，节点之间隧道封包转发；地址与 VPC 无关；性能有封包损耗。
- Terway 模式：Pod 直接使用 VPC 弹性网卡 ENI 分配的 VPC 网段地址——Pod IP 就是 VPC 内真实 IP：
- 与 VPC 内其他产品（SLB、RDS、ECS）天然互通、走原生转发性能更好；
- 支持 NetworkPolicy 网络策略；
- 代价：节点可挂 ENI 数量有限 → 单节点 Pod 数有上限，需规划；
- Terway v1.11+ 支持节点池级"独占 ENI / 共享 ENI"两种模式混合部署。
- 选型：要 Pod 与 VPC 直通（访问 RDS 白名单按 Pod IP、SLB 直连 Pod）选 Terway；规模敏感、要最大 Pod 密度选 Flannel。
- 移动云对标：我自建集群的 CNI 选型与网络规划（Pod CIDR 与 VPC 网段不重叠、service 网段规划）是同一套知识域。
标准回答（面试官问"ACK 的 Terway 和 Flannel 怎么选"）：
这两个插件的本质区别是 Pod 地址属于谁。Flannel 是经典 overlay 方案：Pod 网段是集群内部虚拟网段，跨节点流量走隧道封包，优点是节点能承载的 Pod 数量大、部署简单，代价是封包性能损耗，而且 Pod IP 不是 VPC 真实地址，外部系统按 IP 放行时看不到 Pod。Terway 是阿里云原生的方案：Pod 直接用 VPC 弹性网卡分配的 VPC 网段地址，Pod IP 就是 VPC 里的真实 IP，和 SLB、RDS、其他 ECS 天然互通，性能走原生转发没有封包损耗，还支持 NetworkPolicy 做细粒度策略；代价是受节点能挂的 ENI 数量限制，单节点 Pod 密度有上限，要做容量规划。选型口诀：要 Pod 和 VPC 直通——比如 RDS 白名单按 Pod 维度授权、SLB 直挂 Pod——选 Terway；要最大 Pod 密度和简单可靠，Flannel 够用。Terway 较新版本还支持节点池级独占和共享 ENI 两种模式共存。我的经验锚点是移动云自建：CNI 选型、Pod CIDR 与 VPC 网段不重叠的规划、service 网段预留，这套网络规划我是亲手做的，所以 Terway 解决的"Pod 地址与 VPC 融合"问题，对我来说是熟悉知识域的产品化版本。
追问：K8s 网络规划要注意什么？
我总结四条。一是三个网段各归各：节点网段在 VPC 里分，Pod 网段和 Service 网段独立规划且与 VPC 网段不重叠，还要预留扩展倍数——集群扩容后再改网段是伤筋动骨的；二是/apiserver 高可用入口提前定：用云负载均衡 VIP 还是 keepalived 虚 IP，影响证书 SAN 和 kubeconfig；三是出口收敛：节点走 NAT SNAT 统一出网，拉镜像和访问外部服务路径清晰；四是策略预留：NetworkPolicy 或安全组把 pod 到数据库、pod 到 apiserver 的访问路径先收窄再放开。我在移动云部署时网络规划是单独一节文档过评审的，这些点全在里面——网络是 K8s 出问题最难查的一层，规划期多花一小时，排障期少熬一夜。
4.5 ACK Serverless（ACI/ECI）【了解→理解】
知识点：
- ACK Serverless：无节点的 K8s——不买任何 ECS，Pod 直接落在 ECI（弹性容器实例）上，按 Pod 的 CPU 内存用量秒级计费。
- 对比托管版：托管版仍要管节点（节点池、伸缩）；Serverless 连节点运维都免了，但单价高、常驻大集群成本不划算。
- 适用：突发弹性流量（用 ECI 补峰）、批处理任务、初创业务冷启动；常驻重负载仍以节点型更省。
- 组合形态：普通节点池常驻基线 + ECI 弹性峰值（压峰省钱两不误）。
- 移动云对标：移动云有容器实例类 Serverless 产品，概念同构；我项目用固定节点自建，未用 Serverless——诚实标注。
标准回答（面试官问"了解 ACK Serverless 吗"）：
ACK Serverless 是"没有节点的 K8s"：普通集群要买 ECS 当节点，它把节点层完全去掉，你提交 Pod，平台直接把 Pod 落到弹性容器实例 ECI 上运行，按 Pod 实际占用的 CPU 内存按秒计费，用完释放。它的价值是把节点运维彻底归零——不用规划节点池、不用做节点伸缩、空闲不付费；代价是单价高于包年包月节点，常驻大负载用它反而贵。所以典型用法是组合：常驻基线流量跑在节点池的 Pod 上，突发峰值用 ECI 弹性接住，峰值过去自动释放，成本曲线被压平。适用场景还有批处理和业务冷启动。我如实说明水位：我的移动云项目是固定节点自建形态，业务平稳，没用 Serverless 产品，但这个"节点型与 Serverless 型的成本分界"我理解得清楚——本质是"常驻负载买节点便宜、波动负载按用量买弹性便宜"的算术题。这类产品概念我都是体系化了解加对标，生产深度在移动云的 K8s 自建上。
4.6 ACR 容器镜像服务【理解】
知识点：
- ACR（容器镜像服务）：阿里云镜像仓库，个人版免费（少量命名空间/仓库，够学习用）、企业版收费（企业级安全、大并发拉取、P2P 分发加速、镜像漏洞扫描、按需加载）。
- 核心能力：镜像托管、与 ACK 免密拉取集成（免密组件免去 imagePullSecrets 配置）、跨地域同步、镜像安全扫描。
- 与自建对标：自建 Harbor（我项目场景的真实替代物）——Harbor 免费但要自己维护高可用、存储、漏洞扫描；ACR 企业版是托管 Harbor 超集思路。
- 我的真实用例：移动云自建 K8s 的镜像分发走内网私有仓库思路；镜像源访问外网走 NAT SNAT（呼应 02 章）。
标准回答（面试官问"镜像仓库怎么管理"）：
云上标准做法是用托管镜像仓库：阿里云的 ACR 分个人版和企业版，个人版免费够个人和学习用，企业版提供企业级能力——大并发拉取加速、镜像漏洞扫描、跨地域同步、和 ACK 的免密拉取集成，集群配了免密组件就不用每个命名空间维护 imagePullSecrets。我的对标经验是自建 Harbor：移动云项目里镜像的分发走的私有仓库思路，Harbor 这套要自己管存储、备份和高可用，ACR 企业版等于把这套托管化，还加了 P2P 分发这种自建很难做到的能力。日常镜像治理我会抓三件事：一是镜像 tag 规范，应用名、版本、构建号齐备，禁用 latest 上生产；二是镜像瘦身，多阶段构建控制体积，拉取快部署才快；三是安全基线，基础镜像用可信源定期更新，有条件的加漏洞扫描。这三件事我在自建集群都执行过，和用 ACR 是同一套治理逻辑，只是工具不同。
4.7 SLS 日志服务【理解——对标自建监控栈】
知识点：
- SLS（日志服务）：采集、存储、检索、分析、告警一体化的托管日志平台；采集端 logtail agent；支持毫秒级检索、SQL 分析。
- 与 ACK 集成：集群安装 SLS 组件后，容器 stdout 与日志文件自动采集进 SLS，按索引计费存储。
- 对标自建：EFK（Elasticsearch+Filebeat+Kibana）或 Loki——SLS 是托管 EFK 超集思路；自建要管 ES 的存储水位和性能，SLS 按量付费免运维。
- 我的真实用例：移动云 监控节点 4C8G 上自建监控栈（Prometheus + Grafana + 日志采集），规格定 4C8G 的原因就是时序数据内存开销大（呼应 01 章）。
标准回答（面试官问"容器日志怎么采集管理"）：
云上两条路线。托管路线是 SLS 日志服务：ACK 集群装上 SLS 组件后，容器的标准输出和日志文件自动采集，检索分析告警都在平台上，不用管存储和索引维护，按索引和存储量计费。自建路线是 EFK 或 Loki：采集端 Filebeat 或 Fluent Bit，存储检索 ES 或 Loki，展示 Kibana 或 Grafana，灵活省钱但 ES 的内存和存储水位、分片管理全要自己操心。我的真实经验是自建路线——移动云项目里监控栈独立部署在一台 4 核 8G 的监控节点上，Prometheus 抓指标加日志采集组件，当时规格特意给到 8G 内存，就是因为时序数据和日志处理的内存开销大，这个规格决策在 ECS 那章我讲过。两条路线的取舍逻辑：有稳定的云平台绑定意愿、要省运维人力，托管 SLS；成本敏感、要数据自主、已有自建栈，自建。我的自建运维经验让我两边都理解得具体，包括日志保留策略和水位治理这些细节。
追问：日志采集你们怎么设计的保留和分级？
三条原则。分级采集：不是所有日志都值得进检索系统，错误日志和应用关键路径日志全量采，DEBUG 和访问日志采样或短保留，避免采集系统被噪声打爆；保留分层：近期日志保检索性能，历史日志转压缩归档，按合规要求定总保留期，到期清理；水位治理：采集端限速防日志风暴，存储端配容量告警——日志系统最常见的故障是自己把自己撑爆。我在移动云项目里日志和监控共享那台 4C8G 监控节点，水位是重点巡检项，就是因为这两个系统都是"越用越大"的，必须主动治理而不是等报警。
4.8 ARMS【了解——一句话级】
知识点：ARMS（应用实时监控服务）是阿里云的 APM/可观测平台：应用性能监控（Trace 链路追踪、接口指标）、Prometheus 托管、前端监控、Grafana 托管。一句话口径：应用层的深度可观测——代码级的链路和性能分析，运维层指标之上的一层。
标准回答（面试官问"ARMS 是什么，用过吗"）：
一句话定位：ARMS 是阿里云的应用可观测平台，核心能力是 APM 应用性能监控——通过链路追踪看一个请求在微服务间的完整调用路径和耗时分布，也有 Prometheus 托管和 Grafana 托管能力。它在可观测三层——指标、日志、链路——里主要补的是链路这一层，运维监控看到"接口慢了"，ARMS 能看到"慢在哪个服务哪个方法"。我如实说明：这块我是产品定位级了解，没有实操——我项目里微服务的链路观测是开发侧配合解决的，我运维侧的深度在指标和日志层，也就是 Prometheus 加日志采集那一套，是我亲手在移动云监控节点上搭起来的。如果要用 ARMS，我的理解是它是把我熟悉的可观测体系托管化再加链路能力，概念挂得上。
4.9 K8s 核心对象与云上资源联动【必背】
知识点：
- 五大核心对象：Deployment（无状态副本与滚动更新）、StatefulSet（有状态，稳定网络标识）、Service（ClusterIP 集群内 / NodePort 节点端口 / LoadBalancer 云负载均衡）、Ingress（七层域名路径路由）、ConfigMap/Secret（配置与敏感信息外置）。
- LoadBalancer 类型 Service 的联动：ACK 的云控制器（CCM）在 Service 发布时自动创建并绑定 CLB/SLB——托管生态最大便利之一；自建环境这一步要手工配负载均衡。
- 我自建的对应架构：apiserver 走 CLB 四层 VIP；业务七层入口走 Ingress Nginx；个别四层服务用 NodePort + CLB 透传。
- 移动云对标：这些对象我全部在自建集群手工实践过——对托管自动化有"翻译能力"。
标准回答（面试官问"讲讲 K8s 核心对象，云上有什么联动"）：
我把最核心的五个对象讲清：Deployment 管无状态副本的期望数和滚动更新；StatefulSet 管有状态应用的稳定网络标识和启停顺序；Service 给一组 Pod 提供稳定访问地址，类型有集群内的 ClusterIP、节点端口的 NodePort，还有 LoadBalancer——最后一个在 ACK 上有个特别值得讲的联动：云控制器会在 Service 发布时自动创建并绑定云负载均衡，Service 一上线 SLB 就自动生成挂好，这在自建环境里是要手工建负载均衡再指后端节点的一段工作，托管生态把这段自动化了。Ingress 在 Service 之上做七层路由，按域名和路径把流量分到不同 Service，我自建集群的业务入口就是 Ingress Nginx 统一管的。ConfigMap 和 Secret 把配置和敏感信息从镜像里剥离，改配置不用重建镜像。我的对标视角是这些对象我全部在移动云集群手工实践过——Deployment 编排微服务、Ingress 管业务入口、CLB VIP 管 apiserver——所以 ACK 把哪一段自动化了、自动化到什么程度，我一眼能看懂，这就是自建经验给托管产品的"翻译能力"。
追问：Service 三种类型分别什么场景用？
ClusterIP 给集群内部互访，微服务之间调用走它，最常用；NodePort 在每台节点开端口，适合调试和简单对外，但端口管理和安全面都乱，不推荐生产主入口；LoadBalancer 接云负载均衡，是生产对外服务的首选。我的组合拳：业务对外统一走 Ingress——一个入口集中管理证书和路由；个别非 HTTP 的四层服务用 NodePort 加 CLB 组合做透传；集群内部一律 ClusterIP。判断标准就两个：流量从哪来、需不需要七层能力。
4.10 发布流程与镜像治理【理解——对标 CI/CD 实践】
知识点：
- 发布链路：CI 构建 → 推镜像仓库（唯一 tag：应用名+版本+构建号，禁 latest）→ 更新 Deployment 镜像 tag → 滚动更新（readiness 门控）→ 灰度观察 → 完成；回滚
rollout undo秒级。 - 滚动参数：maxSurge（加速）、maxUnavailable（容量下限）；PodDisruptionBudget 保护滚动期容量。
- 镜像治理三件套：多阶段构建瘦身、基础镜像定期更新、漏洞扫描。
- 移动云对标：我把这套发布 SOP 文档化并在自建集群真实执行过（含回滚演练）。
标准回答（面试官问"容器应用的发布流程怎么设计"）：
标准链路五段我完整执行过。第一段 CI 构建产出镜像，打唯一 tag——应用名加版本加构建号，禁用 latest 上生产；第二段更新 Deployment 的镜像 tag 触发滚动更新；第三段 readiness 探针门控——新 Pod 就绪才接流量，探针不过就进不来，坏版本天然隔离；第四段灰度验证，先小比例流量切到新版本，对比错误率和耗时指标，稳定后放全量；第五段发布后观察期，监控大盘给本次发布打标记，异常曲线能立即关联版本。回滚设计两点：K8s 保留历史 ReplicaSet，rollout undo 一条命令回上一版本，秒级完成；镜像 tag 唯一性保证回滚到的是确切的旧版本——同 tag 覆盖会让回滚变成赌博。参数上 maxSurge 控制发布加速、maxUnavailable 控制容量下限，配 PodDisruptionBudget 保护滚动期的服务容量。我在移动云把这套写成发布 SOP，tag 核对、探针配置核对、回滚命令预置都在检查单里，真实发布和回滚都执行过。这套流程在 ACK 上语义完全一致——K8s 原生机制不因托管而改变。
追问：灰度怎么做最简单有效？
最简方案是双 Deployment 按副本比例灰度：新旧版本各一个 Deployment，Service 的 selector 加版本标签，先放一个新副本对满量旧副本，验证后逐步调比例；更精细的用 Ingress 按 Header 或权重分流，可以给测试账号定向导流做内部验证。我的原则是灰度的目的在于用最小爆炸半径发现问题——比例多大不重要，发布前后的指标对比能力和秒级回滚能力才重要。灰度期间发现问题，第一动作是切流量回旧版本，不是在线上调试新版本。
4.11 Ingress 与 SLB 的完整流量链路【理解】
知识点：
- 完整链路：客户端 → 云负载均衡（CLB/ALB）→ Ingress Controller Pod（节点 NodePort 或直挂 Pod）→ Service → Pod。
- 两种入口形态：LoadBalancer 类型 Service（四层直通，一个 Service 一个 LB）；Ingress（七层聚合路由，一个集群一个入口）。
- 健康检查的两层：LB 探测节点端口（节点级）+ K8s readiness 探测 Pod（实例级）。
- 证书位置：七层入口统一终止 TLS，Ingress 挂证书。
- 移动云对标：我的自建集群就是"CLB VIP（apiserver 四层）+ Ingress Nginx（业务七层）"双入口形态。
标准回答（面试官问"K8s 流量从公网进来怎么走"）：
我拿自建集群的真实链路讲。公网流量先进云负载均衡——四层监听把 TCP 流量透传到节点的 NodePort 或直挂 Pod，这一层解决"多节点高可用接入"；然后进 Ingress Controller——通常是 Nginx 类七层网关，按域名和路径把请求路由到不同的 Service；Service 再按标签选择器把流量导到具体 Pod。两个入口形态要分清：LoadBalancer 类型 Service 是四层直通，一个 Service 配一个负载均衡，适合 TCP 类服务；Ingress 是七层聚合，一个集群一个统一入口管所有 HTTP 业务，证书也在这里统一终止。健康检查是两层的：负载均衡探测节点端口，管"节点活不活"；K8s readiness 探针管"Pod 能不能接流量"——两层各管各的，流量先落到健康节点、再进健康 Pod。我的自建集群就是双入口形态：CLB 四层 VIP 专管 apiserver 的 6443，业务七层走 Ingress Nginx——控制面和应用面入口分离，故障域也分离。在 ACK 上这个链路被自动化：LoadBalancer Service 自动创建云 LB，链路逻辑不变，这就是我说的"托管自动化、语义不变"。
追问 1：为什么 apiserver 和业务入口要分开？
三个理由：故障域分离——业务入口被大流量打挂时不影响控制面，集群还能调度自愈；安全策略不同——apiserver 只对运维网段和集群组件开放，业务入口对公网，访问控制粒度完全不同；协议形态不同——apiserver 是 HTTPS over TCP 走四层透传，业务要七层路由和证书统一管理。我在移动云把两个入口做成两套监听两组安全组，边界清晰，排查问题时也不会互相干扰。
追问 2：Ingress 挂了会怎样，怎么保它的高可用？
Ingress 是单点风险，必须多副本部署并打散节点——至少两个副本反亲和，前端用负载均衡四层接入 NodePort；这样任何一个 Ingress Pod 或节点故障，LB 健康检查摘除，流量走其他副本。监控上给 Ingress 单独的指标——连接数、响应时间、错误率，它是所有业务流量的咽喉，水位要单独盯。我的集群 Ingress 就是两副本加 LB 接入的形态，升级 Ingress 组件也按滚动来，保持任一时刻有副本在服务。
4.12 实操模板
模板 A：K8s 部署形态选型决策表
| 问题 | 若是 | 若否 |
|---|---|---|
| 是否要控制面自主（政企/合规/成本）？ | 自建/专有版 | ACK 托管版 |
| 是否有频繁节点扩缩+重生态集成？ | ACK 托管版（节点池+Terway+SLS 集成） | 自建可行 |
| 常驻负载大且平稳？ | 节点型（包年包月省） | 波动大→ACK Serverless/ECI 补峰 |
| 是否需要 Pod 与 VPC 直通？ | Terway | Flannel 够用 |
| 团队 K8s 运维能力是否成熟？ | 自建可承担 | 优先托管，先建能力再谈自建 |
模板 B：RBAC 角色矩阵（自建/ACK 通用）
| 角色 | 范围 | 权限动词 | 用途 |
|---|---|---|---|
| 集群管理员 | 全集群 | *（cluster-admin） | 仅堡垒机受控使用 |
| 变更岗 | 指定命名空间 | get/list/create/update/delete deployment·service | 日常发布 |
| 值班/巡检 | 全集群 | get/list/watch（只读） | 巡检与排障 |
| CI 流水线 | 指定命名空间 | 指定资源 update（镜像 tag） | 自动发布 |
| 开发调试 | 自己的命名空间 | view + portforward | 联调 |
模板 C：自建 K8s 上线检查清单（我的移动云实践精简版）
- 网络规划：VPC/Pod/Service 三网段不重叠且留扩展。
- 控制面：三 master + etcd 仲裁，SSD 系统盘，etcd 定期备份。
- 接入层：CLB 四层 VIP + TCP 健康检查自动摘除。
- 节点治理：Label/Taint 分组、Pod 反亲和打散。
- 出口：NAT SNAT 统一出网，无公网 IP。
- 镜像：私有仓库分发，tag 规范，禁 latest 上生产。
- 监控：独立监控节点 4C8G，Prometheus+Grafana+日志采集。
- 变更纪律：升级前快照、测试集群演练路径、逐台滚动。
- RBAC 收敛：管理员凭证受控、按命名空间最小授权、CI 限定动作。
4.13 章末自测（一句话答案）
- ACK 托管版托的是什么？——只托控制面（apiserver/etcd/scheduler/controller-manager），节点仍是用户 ECS。
- ACK 四个产品形态？——托管版、专有版、Serverless 版、Edge 边缘版。
- 我为什么在移动云选自建 K8s？——成本（小规格 master 便宜）、政企自主性、团队能力建设，且三大风险有预案。
- Terway 和 Flannel 本质区别？——Terway 的 Pod 用 VPC 弹性网卡真实 IP 直通 VPC，Flannel 是 overlay 虚拟网段隧道转发。
- Terway 的代价？——受节点 ENI 数量限制，单节点 Pod 密度有上限。
- 节点池是什么？——同规格同标签污点节点的逻辑分组，管理动作以池为单位。
- ACK Serverless 按什么计费？——按 Pod 实际 CPU/内存用量（ECI），免节点运维。
- ACR 企业版比个人版多了什么方向的能力？——企业级安全（扫描/免密/跨地域同步/大并发拉取加速）。
- SLS 对标自建什么栈？——EFK/Loki 的托管超集思路。
- 我移动云监控节点规格及原因？——4C8G，时序与日志处理内存开销大，且监控与业务隔离防互相放大故障。
- Pending 的一句话排查法？——describe pod 看 Events，"Pending 问调度，事件给答案"。
- kubeconfig 的管理等级？——等同生产数据库密码：RBAC 最小权限、不入仓库聊天工具、离职即吊销。
- 容器四层安全基线？——镜像供应链、运行时（非 root/只读/limits）、编排管控（特权与 NetworkPolicy）、集群边界（RBAC+etcd）。
- PVC Pending 排查口诀？——查 StorageClass、查配额、查驱动与可用区限制、查历史卷；卷供应失败四连查。
4.14 高频追问补充包（排障连环问）
追问 A：Pod 一直 Pending 怎么排查？
kubectl describe pod看事件——Pending 的原因写在 Events 里。高频四类：资源不足——节点 CPU/内存 Allocatable 不够，扩节点或调 requests；调度约束——污点、亲和性、节点选择器把可调度节点筛空了；PVC 未绑定——存储类或配额问题；网络插件分配失败——IP 池耗尽。我的口诀："Pending 问调度，事件给答案"，九成情况 Events 最后一行就是原因。
追问 B：ImagePullBackOff 怎么排查？
本质是拉镜像失败。四查：镜像名和 tag 拼写是否正确——手滑写错最常见；私有仓库认证——imagePullSecret 是否存在且有效，密钥过期就是它；网络路径——节点到仓库的连通性，我环境里节点无公网 IP，拉公网镜像要过 NAT 或走内网仓库；仓库限流——匿名拉取限频，改用认证拉取。我项目里镜像走内网仓库分发，这个坑面就小很多。
追问 C：etcd 备份你怎么做的？
用 etcdctl snapshot save 定期快照——etcd 数据目录整体拷贝，快照文件异地存放不能和 etcd 同机；保留多份按天轮换；关键配套是恢复演练——快照能不能恢复、恢复到新环境集群状态是否一致，只有演练过才知道。恢复场景：etcd 数据损坏、误删大量资源、跨集群迁移。我在移动云把 etcd 备份做成 cron 加异地存放，恢复步骤写在应急手册里。
追问 D：节点 NotReady 怎么处理？
先看节点状态和事件：kubelet 进程挂了就拉起；容器运行时异常重启运行时；磁盘满会拖死 kubelet——清理；网络不通——节点到 apiserver 的心跳断，查安全组和网络；资源耗尽——内存压力驱逐。处理顺序是"先恢复节点或把节点摘除"——给节点打污点让 Pod 漂走，保业务优先，再慢慢修节点。我建议 NotReady 事件直接配告警，节点的死活不能靠用户报障发现。
追问 E：HPA 配置有什么要点？
三个要点：指标选择——CPU 适合大多数场景，流量类指标更贴近业务但要自定义 metrics；稳定窗口与冷却——防止指标抖动引起副本震荡，扩容快缩容慢是原则；requests 必须配——HPA 按 requests 算利用率，没配 requests HPA 不工作。我还会配最小最大副本数兜底，防止异常指标把副本数打到极端。
追问 F：怎么验证集群升级不影响业务？
三步走：测试集群先行——同版本路径完整演练一次升级；生产低峰滚动——按 master 逐台、worker 逐台的顺序，每台之间验证节点 Ready 和关键服务健康；随时可停——任何一步异常就停在中间版本，K8s 支持 N-1 版本混跑，这是滚动升级的安全垫。升级前快照和 etcd 备份是最后保险。我移动云的升级 SOP 就是这套，升级窗口的业务监控是必配的。
追问 G：ConfigMap 更新后 Pod 里的配置会自动变吗？
分两种挂载方式：以环境变量注入的 ConfigMap，更新后不生效——变量是 Pod 启动时注入的，要滚动重启；以文件卷挂载的，kubelet 会异步更新文件内容，但应用还得支持热加载配置，否则同样要重启。我的实践是配置变更统一走"更新 ConfigMap 加滚动重启"的确定性路径，热加载当优化不当依赖——确定性比聪明重要，配置生效状态可预期，排障才不玄学。
追问 H：Service 的域名是怎么解析的？
集群内 CoreDNS 负责解析：同命名空间直接用服务名，跨命名空间用"服务名.命名空间"，Service 的 ClusterIP 由 DNS 解析返回；Headless Service 特殊，直接解析到后端 Pod IP 列表，适合有状态应用自己发现成员。我排障时会 nslookup 服务域名验证 DNS 链路——微服务"时通时不通"的诡异问题，一半出在 DNS 缓存或连接池长连接缓存上，先把解析和连接的"缓存时间窗"搞清楚，再谈网络。
追问 I：加一台节点的完整流程是什么？
四步：一规划核对——规格、所在安全组、镜像基线版本核对；二创建加入——自建是 kubeadm join，ACK 是节点池里添加自动完成；三验证四件——节点 Ready、系统组件 Pod 正常运行、网络连通性（Pod 跨节点通信、到镜像仓库和数据库的路径）、监控 agent 上报数据；四打标签污点纳入调度——按角色归组。我的扩容检查单就是这四步，其中安全组组间授权是高频遗漏项——又是我那个健康检查异常案例的教训，授权先于挂载。
追问 J：kubeconfig 的权限怎么收敛？
生产 kubeconfig 等于集群最高权限，按敏感凭证管理：按人按用途签发独立证书或 ServiceAccount Token，配 RBAC 最小权限——值班只读、变更岗限定命名空间和动作；kubeconfig 绝不进聊天工具、网盘和代码仓库；人员变动立即吊销重发。我自建集群的 RBAC 就是按角色分发的，管理凭证的管控等级等同于生产数据库密码——因为拿它能删整个集群，风险等级只高不低。
4.15 专题：集群的日常巡检与周报【理解】
知识点（日巡检七项）：
- 节点 Ready 状态与事件。
- 控制面组件健康（apiserver/etcd/scheduler 的存活与延迟）。
- 异常 Pod 扫描：CrashLoopBackOff / Pending / OOMKilled。
- 证书到期台账。
- etcd 备份完成度。
- 资源水位：节点级与命名空间配额两级。
- 镜像仓库与发布记录核对。
事件告警单独配：NotReady、Pod 驱逐、OOM 直接触发，不等巡检。周报三榜单：异常 Pod 榜（推开发）、资源消耗 Top 榜（容量与成本输入）、当周变更发布记录。
标准回答（面试官问"K8s 集群的日常运维你怎么做"）：
我有一张日巡检清单七项：节点 Ready 状态与事件、控制面组件健康——apiserver、etcd、调度器的存活和响应延迟、异常 Pod 扫描——CrashLoopBackOff、Pending、OOMKilled 这三类高频问题逐一核对、证书到期台账、etcd 备份完成度、节点与命名空间两级资源水位、镜像仓库与发布记录核对。事件类告警单独配：节点 NotReady、Pod 驱逐、OOM 直接触发通知，不等巡检窗口。周报沉淀三个榜单：异常 Pod 榜——反复重启的应用清单推给开发跟踪；资源消耗 Top 榜——容量和成本优化的直接输入；当周变更发布记录——运维侧的完整留痕。我移动云项目这套巡检真实跑过：证书到期台账就是巡检暴露出来的机制缺口，OOM 榜单推动过两个服务的内存限制调整——巡检的价值始终是闭环加修剪。这套清单到 ACK 上同样成立，事件和指标的数据源换成平台提供的能力，方法不变。
追问：巡检发现某服务反复 OOMKilled，怎么处理？
先恢复业务再谈根因：临时升内存 limits 让服务先稳住，配好告警观察。然后区分"真不够"还是"泄漏"：内存曲线稳定在高位被打爆——配额确实小了，评估正常占用后合理上调；锯齿状增长然后崩溃重启——疑似内存泄漏，交开发抓堆分析。根因处理后回看 OOM 榜单确认退出，并把案例写进周报。我的纪律是 OOM 不允许"重启了事"——重启掩盖的是问题不是解决，反复 OOM 的服务一定有结构性原因。
追问 K：容器环境的安全基线和虚拟机有什么不同？
多了三层。镜像供应链：基础镜像要来自可信源、定期更新补丁、上线前漏洞扫描——镜像一旦带毒， replicas 越多感染面越大；运行时配置：容器以非 root 用户运行、根文件系统只读、资源 limits 必配防抢夺、不必要的能力 drop 掉；编排层：特权容器和宿主机敏感挂载要管控，NetworkPolicy 收紧 Pod 间访问。虚拟机时代的三件套——补丁、口令、基线——依然要做，容器是"三层新增 + 三件老事"。我在自建集群里重点落实了非 root 运行和资源 limits 两项，这两项是"不加约束迟早出事"的典型。
4.16 专题：容器环境安全基线【理解】
知识点（四层基线）：
- 镜像供应链：可信基础镜像、定期更新、漏洞扫描、tag 不可变（禁 latest 上生产）。
- 运行时：非 root 用户、只读根文件系统、资源 requests/limits 必配、最小化能力（drop 特权能力）。
- 编排层：特权容器与宿主机敏感目录挂载管控、NetworkPolicy 收紧 Pod 互访、Secret 不落镜像。
- 集群边界：apiserver 收敛（RBAC+堡垒机）、节点安全组组间授权、etcd 加密与备份。
标准回答（面试官问"容器环境的安全你怎么管"）：
我按四层基线管。第一层镜像供应链：基础镜像只用可信源并定期更新打补丁，业务镜像上线前过漏洞扫描，tag 唯一且不可变——latest 上生产在我这是红线，因为它让"跑的到底是什么版本"不可追溯。第二层运行时：容器非 root 运行、根文件系统只读、写目录单独挂载，CPU 内存 requests 和 limits 必配——既是资源公平也是防抢夺的安全线，特权能力能 drop 就 drop。第三层编排管控：特权容器和挂载宿主机敏感目录的 Pod 要审批管控，NetworkPolicy 把 Pod 间访问从全通收紧到按需，敏感配置走 Secret 不打进镜像——镜像进仓库就是半公开资产。第四层集群边界：apiserver 的 RBAC 最小权限加堡垒机收敛，节点安全组组间授权，etcd 数据备份加访问控制。我移动云自建集群把第二层和第四层完整落地，第一层的扫描用仓库自带能力，诚实说没有上签名体系。这套和云安全中心的容器版能力是配套关系：我管配置基线，平台管检测告警。
追问：容器逃逸怎么理解，最需要防什么？
容器和宿主机共享内核，隔离弱于虚拟机——逃逸就是容器内进程突破隔离拿到宿主机权限。最需要防的三件事：不以特权模式和 root 跑容器——特权模式是逃逸的最大放大器；不挂载宿主机敏感路径如 docker.sock——挂了它等于把宿主机控制权交给容器；内核与运行时保持更新——逃逸漏洞多数在内核和运行时层修复。我的口径：容器安全的前提是"镜像可信加运行时收敛"，这两层守住，逃逸面就收窄到需要同时满足多个罕见条件，风险可控。
追问 L：命名空间和资源配额怎么用？
命名空间是逻辑隔离单元：按团队、按环境、按业务线划分，配 ResourceQuota 限制每空间的 CPU/内存/Pod 总量，配 LimitRange 约束单 Pod 的默认上下限——防止某个团队无限制吃掉集群。我的实践：生产集群按业务线分命名空间加配额，配额值来自容量评审，超了走扩容流程而不是改配额。这套治理在多团队集群是必需品，单团队小集群可以先建命名空间习惯后配配额。
追问 M：集群版本停在旧版本会有什么风险？
三层风险：安全——K8s 与节点内核的漏洞修复集中在较新版本，停在旧版等于已知漏洞敞开；生态——新版本 CNI、存储、监控组件陆续不再支持旧版，越停越难升——跨多版本升级的复杂度是指数增长的；支持——托管版有版本支持窗口，过期版本失去平台支持。我的纪律：跟小版本节奏升级，最多落后一个大版本，升级前测试集群演练——这是我 etcd/证书/升级三大坑纪律之一。
追问 N：怎么限制某团队只能在自己命名空间操作？
用 Role 而不是 ClusterRole：在目标命名空间内绑定 Role（限定动词——get/list/create/update，限定资源——deployment/service/pod），配 RoleBinding 绑到团队的 ServiceAccount 或用户组；只读巡检给 view 类角色。这样即使凭证泄漏，爆炸半径也被锁在命名空间内。我的集群 RBAC 就是按"命名空间为边界、动词最小化"设计的，管理员的 cluster-admin 凭证只保存在堡垒机的受控位置。
追问 O：K8s 的 Service 怎么做会话保持？
Service 的 spec 里配 sessionAffinity: ClientIP——按源 IP 把同一客户端粘到同一 Pod，超时默认三小时可调。但我的架构口径还是无状态优先：会话进 Redis 后 Service 不开粘性，滚动发布和扩缩容都不受粘滞影响；确实有状态且无共享存储的老应用才用 sessionAffinity 过渡，并把改造排上日程。粘性是过渡手段不是终态，这个判断我在面试里会主动讲。
追问 P：Pod 挂了存储卷，PVC 一直 Pending 怎么排查？
PVC Pending 是"卷没有动态供应成功"。四查：StorageClass 是否存在且是默认——PVC 没指定 class 又无默认类就卡住；配额——命名空间的存储资源配额是否打满；供应能力——对应存储插件的驱动是否正常、后端云盘是否有地域/可用区限制——云盘只能挂同节点可用区，跨可用区调度会卡卷；回收策略与历史卷——某些平台限制同时挂载或待释放卷数量。我在自建环境里给 PVC 配了明确的 StorageClass 和容量规划，避免隐式默认值带来的意外。
参考资料（链接采集时间 2026-10）
以下链接均于 2026 年 10 月通过搜索与抓取核实可用：
- 使用 Terway 网络插件（ACK 官方文档，含独占/共享 ENI 模式）：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/work-with-terway
- 创建和管理节点池：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/create-a-node-pool
- ACK 网络概述（容器网络在阿里云资源上的实现）：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/network
- 什么是容器服务 Serverless 版（ACK Serverless）：https://help.aliyun.com/zh/ack/serverless-kubernetes
- ACK Serverless 通过 Pod 环境变量采集应用日志到 SLS：https://help.aliyun.com/zh/ack/serverless-kubernetes/user-guide/use-log-service-to-collect-application-logs
- 日志服务 SLS 文档：https://help.aliyun.com/zh/sls
- ACR 企业版按需加载容器镜像：https://help.aliyun.com/zh/acr/user-guide/load-resources-of-a-container-image-on-demand
- 容器镜像服务 ACR 产品页：https://www.aliyun.com/product/acr
- 容器服务 ACK 产品页：https://www.aliyun.com/product/aliware/containerservice