第一部分：工作负载控制器（Workload Controllers）
这部分解决的核心问题是：“Pod 跑起来之后，谁来保证它持续可用、如何更新、如何处理一次性任务？”
1. ReplicaSet（RS）
- 定位：保证指定数量的 Pod 副本始终运行。
- 工作机制：通过
selector关联 Pod，如果 Pod 数量多于期望则终止多余的，少于则新建。 - 实际使用：通常不直接操作 RS，而是由 Deployment 自动管理。RS 的命名通常带有 Pod 模板的 Hash 值（如
web-5646dd6f6c-5hs6f）。 - 孤儿 Pod 处理：如果手动创建一个带有匹配标签的 Pod，它会被 RS 立即“收养”；如果删除 RS 时加
--cascade=orphan，则保留 Pod 成为孤儿。
2. Deployment（最常用）
- 核心价值：为 Pod 和 RS 提供声明式更新能力。直接操作 RS 而无需手动管理。
- 更新策略：默认为
RollingUpdate（滚动更新）。配套两个关键参数：maxSurge（默认 25%）：更新过程中，Pod 总数最多可以超出期望值的比例。maxUnavailable（默认 25%）：更新过程中，不可用 Pod 的最大比例。
- 更新触发：修改镜像（
kubectl set image）或修改 Pod 模板字段。 - 版本控制与回滚：
- 使用
kubectl rollout history查看版本。 - 使用
--record记录变更命令。 - 回滚命令：
kubectl rollout undo deployment/web --to-revision=2。
- 使用
- 节点故障自愈时间线（需熟记）：
- kubelet 每 10s 上报心跳。
- controller-manager 每 5s 检查，连续 40s 无心跳标记节点
NotReady。 NotReady持续5 分钟（pod-eviction-timeout=300s）后，开始将 Pod 驱逐到其他节点。
修改参数位于 master 静态 Pod：
/etc/kubernetes/manifests/kube-controller-manager.yaml。
3. DaemonSet（DS）
- 适用场景：每个节点运行且只需运行一个 Pod 的守护进程（日志收集 Fluentd、监控 NodeExporter、网络插件 Calico）。
- 调度特性：默认不调度到 Master（因 Master 有
NoSchedule污点）。可通过kubectl taint临时允许 Master 调度。 - 更新策略：支持
RollingUpdate（默认）和OnDelete。 - 生产案例：
- Calico-node：使用
hostNetwork: true和特权模式操作网络。 - Node Exporter：挂载宿主机
/proc和/sys采集指标。
- Calico-node：使用
4. Job（一次性任务）
- 三种重启策略（
restartPolicy）：Never：任务失败后新建 Pod重试（会产生多个失败的 Pod 历史）。OnFailure：任务失败后重启容器（Pod 数量始终为 1，但RESTARTS增加）。
- 并行控制：
completions：总共需要成功完成多少次（如 6）。parallelism：允许同时运行多少个 Pod（如 2）。两者结合可做并行批处理。
- 失败重试：
backoffLimit（默认 6），达到上限后 Job 标记为 Failed。 - 超时终止：
activeDeadlineSeconds优先级高于backoffLimit，超时即强制终止。 - 自动清理：
.spec.ttlSecondsAfterFinished（如 100 秒后自动删除 Job 及 Pod）。
5. CronJob（定时任务）
- 调度语法：标准的 5 位 Cron 表达式（分 时 日 月 周）。
- 并发策略（
concurrencyPolicy）：Allow（默认）：允许并发执行。Forbid：上一次未完成则跳过本次。Replace：取消当前运行的，启动新的。
- 历史限制：
successfulJobsHistoryLimit（默认 3）和failedJobsHistoryLimit（默认 1）。 - 使用注意：CronJob 名称不能超过 52 个字符，因控制器会自动追加 11 个字符（Job 名称最长 63 字符）。
第二部分：Service（服务发现与暴露）
1. 为什么需要 Service？
Pod 是“朝生暮死”的，IP 会变化。Service 提供固定 IP（ClusterIP）和负载均衡，解决动态服务发现问题。
2. 服务发现的三种方式
| 方式 | 原理 | 使用场景 |
|---|---|---|
| ClusterIP 直接访问 | 通过kubectl get svc获取集群内部 IP，curl 测试 | 调试阶段 |
| 环境变量注入 | Pod 启动时注入SERVICE_HOST和SERVICE_PORT | 早期 Pod 访问 Service（注：必须在 Pod 创建前先创建 Service） |
| CoreDNS | 通过<service>.<namespace>.svc.cluster.local访问 | 生产推荐。同 Namespace 下可省略后缀，直接使用 Service 名 |
3. Service 类型详解
| 类型 | 访问链路 | 适用场景 |
|---|---|---|
| ClusterIP（默认） | 客户端 → ClusterIP:Port → Pod | 内部微服务调用 |
| NodePort | 客户端 → 任意节点 IP:30000-32767 → ClusterIP → Pod | 测试环境对外暴露，或没有 LB 时的替代方案 |
| LoadBalancer | 客户端 → LB VIP → 节点 NodePort → ClusterIP → Pod | 生产环境对外暴露（需 Metallb 或云厂商 LB） |
| ExternalName | 集群内访问 Service → DNS CNAME 跳转外部域名 | 将集群外服务映射为 K8s 内部服务名 |
| Headless（ClusterIP: None） | 客户端直接解析到所有 Pod IP（A 记录列表） | StatefulSet 有状态服务（如 etcd、ZK），需要直连 Pod |
4. 会话保持（Session Affinity）
- 设置
spec.sessionAffinity: ClientIP可让同一客户端 IP 始终访问同一个 Pod。 - 默认超时
timeoutSeconds: 10800（3 小时）。适用于需要保存 Session 的有状态应用。 - 原理：在 iptables/IPVS 规则中增加源地址哈希逻辑。
5. 金丝雀发布（多 Deployment 共享 Service）
- 实现思路：
- 稳定版 Deployment（
track: stable）副本数 10。 - 金丝雀版 Deployment（
track: canary）副本数 1。 - Service 的
selector只匹配通用标签（如app: web, tier: frontend），不区分track。 - 流量自动按 Pod 数量比例分发（10:1）。
- 逐步调整两边的副本数（如 8:2、6:4、0:10）完成全量发布。
- 稳定版 Deployment（
- 优点：无需修改 Service，纯副本数控制，简单可靠。
第三部分：kube-proxy 工作原理（iptables vs IPVS）
kube-proxy 是 Service 流量转发的核心组件，理解其原理对排查网络问题至关重要。
1. iptables 模式（默认）
- 数据链路（以访问 ClusterIP
10.103.143.120:80为例）：- PREROUTING→KUBE-SERVICES（总入口）。
- 匹配目标 IP 为 ClusterIP，跳转至KUBE-SVC-XXXXX（Service 专属链）。
- 在该链中：先执行SNAT（非 Pod 网段来源需标记 Masquerade）。
- 通过
statistic --mode random --probability实现负载均衡（如 1/3、1/2、默认）。 - 跳转至KUBE-SEP-XXXXX（Endpoint 链），执行DNAT将目标 IP 改为具体 Pod IP。
- 性能瓶颈：每增加一个 Service/Endpoint，就增加若干条 iptables 规则。当 Service 超过 1000 个时，规则检索延迟显著上升，CPU 飙升。
- 查看命令：
iptables-save | grep <ClusterIP>可追踪整条规则链。
2. IPVS 模式（生产推荐）
- 数据链路：客户端 → 宿主机网卡 → 内核 IPVS 虚拟服务器（哈希表查找）→ 直接转发至 Pod（Real Server）。
- 性能优势：哈希表 O(1) 复杂度，支持 10 万级 Service，吞吐量远高于 iptables。
- 调度算法：支持
rr（轮询）、wrr（加权轮询，最推荐）、lc（最少连接）、sh（源地址哈希，配合 sessionAffinity）。 - 切换与验证：
# 修改 ConfigMapkubectl edit cm-nkube-system kube-proxy# 设置 mode: "ipvs" 和 scheduler: "wrr"kubectl rollout restart ds-nkube-system kube-proxy# 验证ipvsadm-Ln-t10.103.143.120:80
3. 权重（Weight）来源
IPVS 的 wrr 算法权重默认与 Pod 的resources.requests.cpu/memory成正比（由 kube-proxy 计算）。如需临时测试，可手动ipvsadm -e修改，但不持久。
第四部分：Ingress（七层路由与流量治理）
Ingress 解决了四层 Service（如 NodePort/LB）无法基于域名、路径、Header 进行路由的问题。
1. 架构与工作流程
- 部署Ingress Controller（如 ingress-nginx），本质是一个 Nginx Pod，通过 LoadBalancer Service 对外暴露。
- 创建Ingress 资源（定义 host、path、backend）。
- Controller 监听 API Server，将 Ingress 规则转换为 Nginx 配置文件（
/etc/nginx/nginx.conf）并 reload。
关键：Ingress Controller 是“实施者”，Ingress 资源是“声明”。没有 Controller，Ingress 资源毫无作用。
2. 部署注意事项（ingress-nginx）
- 镜像替换：官方
registry.k8s.io可能无法访问，需替换为可用的镜像仓库（如hub.laoma.cloud）。 - Service 类型：部署文件默认为
LoadBalancer，需提前装好 Metallb 分配外部 IP。 - Admission Webhook：部署时会创建
ValidatingWebhookConfiguration，用于校验 Ingress 语法。
3. 路径匹配类型（PathType）
| 类型 | 行为 | 示例 |
|---|---|---|
| Exact | 严格区分大小写的完全匹配 | /foo只匹配/foo，不匹配/foo/ |
| Prefix | 基于/分隔的前缀匹配 | /foo匹配/foo、/foo/、/foo/bar，不匹配/foobar |
| ImplementationSpecific | 由 IngressClass 决定（通常同 Prefix） | 涉及正则时常用此类型 |
4. 生产级核心注解（Annotation）实战
① 路径重写（Rewrite Target）—— 最常用
annotations:nginx.ingress.kubernetes.io/use-regex:"true"nginx.ingress.kubernetes.io/rewrite-target:/$1# path: /webapp01/(.*) → 后端只收到 /(.*) 的内容，剥离前缀场景：前端 API 带版本号
/v1/users，后端实际路径为/users。
② HTTPS 与强制跳转
spec:tls:-hosts:[www.laoma.cloud]secretName:www-tls# 提前创建：kubectl create secret tlsannotations:nginx.ingress.kubernetes.io/force-ssl-redirect:"true"③ 限流与防刷（防 CC）
annotations:nginx.ingress.kubernetes.io/limit-connections:"50"# 单 IP 最大并发连接nginx.ingress.kubernetes.io/limit-rps:"20"# 单 IP 每秒请求数④ IP 白名单（内网系统必备）
annotations:nginx.ingress.kubernetes.io/whitelist-source-range:"10.1.8.0/24,172.16.0.0/12"⑤ 跨域 CORS（前后端分离）
annotations:nginx.ingress.kubernetes.io/enable-cors:"true"nginx.ingress.kubernetes.io/cors-allow-origin:"https://frontend.com"⑥ 超时与缓存
annotations:nginx.ingress.kubernetes.io/proxy-read-timeout:"60"# 防止长连接断连nginx.ingress.kubernetes.io/proxy-cache:"true"nginx.ingress.kubernetes.io/proxy-cache-valid:"200 302 10m"⑦ 灰度发布（基于权重）
annotations:nginx.ingress.kubernetes.io/canary:"true"nginx.ingress.kubernetes.io/canary-weight:"10"# 10% 流量进金丝雀后端⑧ 透传真实客户端 IP
annotations:nginx.ingress.kubernetes.io/x-forwarded-for:"true"nginx.ingress.kubernetes.io/proxy-real-ip-cidr:"10.0.0.0/8"5. 多域名与多路径配置示例
apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:production-ingressspec:ingressClassName:nginxrules:-host:api.laoma.cloudhttp:paths:-path:/v1/pathType:Prefixbackend:service:name:api-v1-svcport:number:80-host:web.laoma.cloudhttp:paths:-path:/pathType:Prefixbackend:service:name:web-svcport:number:80第五部分：环境清理与常用故障排查
资源删除注意事项
- 删除 Deployment 默认级联删除 RS 和 Pod。如需保留 Pod，加
--cascade=orphan。 - 删除 Namespace 会强制删除该命名空间下所有资源（包括正在运行的 Pod），生产环境谨慎操作。
常用排查命令
# 查看控制器事件kubectl describe deployment/web kubectl describe replicaset/web-xxx# 查看 Pod 被谁控制kubectl describe pod web-xxx|grepControlled# 追踪 Service 后端端点kubectl get endpoints<svc-name># 查看 Ingress Controller 日志kubectl logs-ningress-nginx deployment/ingress-nginx-controller# 进入容器测试 DNS 解析kubectl runtest--rm-it--image=busybox --nslookupwebapp01.services.svc.cluster.local总结：掌握Deployment 的滚动更新与回滚机制、Service 的三种发现方式、kube-proxy 的 IPVS 性能优势以及Ingress 的路径重写与限流配置，是应对 K8s 生产环境日常运维和面试深挖的四大基石。