第一部分工作负载控制器Workload Controllers这部分解决的核心问题是“Pod 跑起来之后谁来保证它持续可用、如何更新、如何处理一次性任务”1. ReplicaSetRS定位保证指定数量的 Pod 副本始终运行。工作机制通过selector关联 Pod如果 Pod 数量多于期望则终止多余的少于则新建。实际使用通常不直接操作 RS而是由 Deployment 自动管理。RS 的命名通常带有 Pod 模板的 Hash 值如web-5646dd6f6c-5hs6f。孤儿 Pod 处理如果手动创建一个带有匹配标签的 Pod它会被 RS 立即“收养”如果删除 RS 时加--cascadeorphan则保留 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-revision2。节点故障自愈时间线需熟记kubelet 每 10s 上报心跳。controller-manager 每 5s 检查连续 40s 无心跳标记节点NotReady。NotReady持续5 分钟pod-eviction-timeout300s后开始将 Pod 驱逐到其他节点。修改参数位于 master 静态 Pod/etc/kubernetes/manifests/kube-controller-manager.yaml。3. DaemonSetDS适用场景每个节点运行且只需运行一个 Pod 的守护进程日志收集 Fluentd、监控 NodeExporter、网络插件 Calico。调度特性默认不调度到 Master因 Master 有NoSchedule污点。可通过kubectl taint临时允许 Master 调度。更新策略支持RollingUpdate默认和OnDelete。生产案例Calico-node使用hostNetwork: true和特权模式操作网络。Node Exporter挂载宿主机/proc和/sys采集指标。4. Job一次性任务三种重启策略restartPolicyNever任务失败后新建 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 表达式分 时 日 月 周。并发策略concurrencyPolicyAllow默认允许并发执行。Forbid上一次未完成则跳过本次。Replace取消当前运行的启动新的。历史限制successfulJobsHistoryLimit默认 3和failedJobsHistoryLimit默认 1。使用注意CronJob 名称不能超过 52 个字符因控制器会自动追加 11 个字符Job 名称最长 63 字符。第二部分Service服务发现与暴露1. 为什么需要 ServicePod 是“朝生暮死”的IP 会变化。Service 提供固定 IPClusterIP和负载均衡解决动态服务发现问题。2. 服务发现的三种方式方式原理使用场景ClusterIP 直接访问通过kubectl get svc获取集群内部 IPcurl 测试调试阶段环境变量注入Pod 启动时注入SERVICE_HOST和SERVICE_PORT早期 Pod 访问 Service注必须在 Pod 创建前先创建 ServiceCoreDNS通过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 或云厂商 LBExternalName集群内访问 Service → DNS CNAME 跳转外部域名将集群外服务映射为 K8s 内部服务名HeadlessClusterIP: None客户端直接解析到所有 Pod IPA 记录列表StatefulSet 有状态服务如 etcd、ZK需要直连 Pod4. 会话保持Session Affinity设置spec.sessionAffinity: ClientIP可让同一客户端 IP 始终访问同一个 Pod。默认超时timeoutSeconds: 108003 小时。适用于需要保存 Session 的有状态应用。原理在 iptables/IPVS 规则中增加源地址哈希逻辑。5. 金丝雀发布多 Deployment 共享 Service实现思路稳定版 Deploymenttrack: stable副本数 10。金丝雀版 Deploymenttrack: canary副本数 1。Service 的selector只匹配通用标签如app: web, tier: frontend不区分track。流量自动按 Pod 数量比例分发10:1。逐步调整两边的副本数如 8:2、6:4、0:10完成全量发布。优点无需修改 Service纯副本数控制简单可靠。第三部分kube-proxy 工作原理iptables vs IPVSkube-proxy 是 Service 流量转发的核心组件理解其原理对排查网络问题至关重要。1. iptables 模式默认数据链路以访问 ClusterIP10.103.143.120:80为例PREROUTING→KUBE-SERVICES总入口。匹配目标 IP 为 ClusterIP跳转至KUBE-SVC-XXXXXService 专属链。在该链中先执行SNAT非 Pod 网段来源需标记 Masquerade。通过statistic --mode random --probability实现负载均衡如 1/3、1/2、默认。跳转至KUBE-SEP-XXXXXEndpoint 链执行DNAT将目标 IP 改为具体 Pod IP。性能瓶颈每增加一个 Service/Endpoint就增加若干条 iptables 规则。当 Service 超过 1000 个时规则检索延迟显著上升CPU 飙升。查看命令iptables-save | grep ClusterIP可追踪整条规则链。2. IPVS 模式生产推荐数据链路客户端 → 宿主机网卡 → 内核 IPVS 虚拟服务器哈希表查找→ 直接转发至 PodReal Server。性能优势哈希表 O(1) 复杂度支持 10 万级 Service吞吐量远高于 iptables。调度算法支持rr轮询、wrr加权轮询最推荐、lc最少连接、sh源地址哈希配合 sessionAffinity。切换与验证# 修改 ConfigMapkubectl edit cm-nkube-system kube-proxy# 设置 mode: ipvs 和 scheduler: wrrkubectl rollout restart ds-nkube-system kube-proxy# 验证ipvsadm-Ln-t10.103.143.120:803. 权重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 资源是“声明”。没有 ControllerIngress 资源毫无作用。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不匹配/foobarImplementationSpecific由 IngressClass 决定通常同 Prefix涉及正则时常用此类型4. 生产级核心注解Annotation实战① 路径重写Rewrite Target—— 最常用annotations:nginx.ingress.kubernetes.io/use-regex:truenginx.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③ 限流与防刷防 CCannotations: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:truenginx.ingress.kubernetes.io/cors-allow-origin:https://frontend.com⑥ 超时与缓存annotations:nginx.ingress.kubernetes.io/proxy-read-timeout:60# 防止长连接断连nginx.ingress.kubernetes.io/proxy-cache:truenginx.ingress.kubernetes.io/proxy-cache-valid:200 302 10m⑦ 灰度发布基于权重annotations:nginx.ingress.kubernetes.io/canary:truenginx.ingress.kubernetes.io/canary-weight:10# 10% 流量进金丝雀后端⑧ 透传真实客户端 IPannotations:nginx.ingress.kubernetes.io/x-forwarded-for:truenginx.ingress.kubernetes.io/proxy-real-ip-cidr:10.0.0.0/85. 多域名与多路径配置示例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加--cascadeorphan。删除 Namespace 会强制删除该命名空间下所有资源包括正在运行的 Pod生产环境谨慎操作。常用排查命令# 查看控制器事件kubectl describe deployment/web kubectl describe replicaset/web-xxx# 查看 Pod 被谁控制kubectl describe pod web-xxx|grepControlled# 追踪 Service 后端端点kubectl get endpointssvc-name# 查看 Ingress Controller 日志kubectl logs-ningress-nginx deployment/ingress-nginx-controller# 进入容器测试 DNS 解析kubectl runtest--rm-it--imagebusybox --nslookupwebapp01.services.svc.cluster.local总结掌握Deployment 的滚动更新与回滚机制、Service 的三种发现方式、kube-proxy 的 IPVS 性能优势以及Ingress 的路径重写与限流配置是应对 K8s 生产环境日常运维和面试深挖的四大基石。
Kubernetes 工作负载与网络核心：从 Controller 到 Ingress 生产级实践
第一部分工作负载控制器Workload Controllers这部分解决的核心问题是“Pod 跑起来之后谁来保证它持续可用、如何更新、如何处理一次性任务”1. ReplicaSetRS定位保证指定数量的 Pod 副本始终运行。工作机制通过selector关联 Pod如果 Pod 数量多于期望则终止多余的少于则新建。实际使用通常不直接操作 RS而是由 Deployment 自动管理。RS 的命名通常带有 Pod 模板的 Hash 值如web-5646dd6f6c-5hs6f。孤儿 Pod 处理如果手动创建一个带有匹配标签的 Pod它会被 RS 立即“收养”如果删除 RS 时加--cascadeorphan则保留 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-revision2。节点故障自愈时间线需熟记kubelet 每 10s 上报心跳。controller-manager 每 5s 检查连续 40s 无心跳标记节点NotReady。NotReady持续5 分钟pod-eviction-timeout300s后开始将 Pod 驱逐到其他节点。修改参数位于 master 静态 Pod/etc/kubernetes/manifests/kube-controller-manager.yaml。3. DaemonSetDS适用场景每个节点运行且只需运行一个 Pod 的守护进程日志收集 Fluentd、监控 NodeExporter、网络插件 Calico。调度特性默认不调度到 Master因 Master 有NoSchedule污点。可通过kubectl taint临时允许 Master 调度。更新策略支持RollingUpdate默认和OnDelete。生产案例Calico-node使用hostNetwork: true和特权模式操作网络。Node Exporter挂载宿主机/proc和/sys采集指标。4. Job一次性任务三种重启策略restartPolicyNever任务失败后新建 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 表达式分 时 日 月 周。并发策略concurrencyPolicyAllow默认允许并发执行。Forbid上一次未完成则跳过本次。Replace取消当前运行的启动新的。历史限制successfulJobsHistoryLimit默认 3和failedJobsHistoryLimit默认 1。使用注意CronJob 名称不能超过 52 个字符因控制器会自动追加 11 个字符Job 名称最长 63 字符。第二部分Service服务发现与暴露1. 为什么需要 ServicePod 是“朝生暮死”的IP 会变化。Service 提供固定 IPClusterIP和负载均衡解决动态服务发现问题。2. 服务发现的三种方式方式原理使用场景ClusterIP 直接访问通过kubectl get svc获取集群内部 IPcurl 测试调试阶段环境变量注入Pod 启动时注入SERVICE_HOST和SERVICE_PORT早期 Pod 访问 Service注必须在 Pod 创建前先创建 ServiceCoreDNS通过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 或云厂商 LBExternalName集群内访问 Service → DNS CNAME 跳转外部域名将集群外服务映射为 K8s 内部服务名HeadlessClusterIP: None客户端直接解析到所有 Pod IPA 记录列表StatefulSet 有状态服务如 etcd、ZK需要直连 Pod4. 会话保持Session Affinity设置spec.sessionAffinity: ClientIP可让同一客户端 IP 始终访问同一个 Pod。默认超时timeoutSeconds: 108003 小时。适用于需要保存 Session 的有状态应用。原理在 iptables/IPVS 规则中增加源地址哈希逻辑。5. 金丝雀发布多 Deployment 共享 Service实现思路稳定版 Deploymenttrack: stable副本数 10。金丝雀版 Deploymenttrack: canary副本数 1。Service 的selector只匹配通用标签如app: web, tier: frontend不区分track。流量自动按 Pod 数量比例分发10:1。逐步调整两边的副本数如 8:2、6:4、0:10完成全量发布。优点无需修改 Service纯副本数控制简单可靠。第三部分kube-proxy 工作原理iptables vs IPVSkube-proxy 是 Service 流量转发的核心组件理解其原理对排查网络问题至关重要。1. iptables 模式默认数据链路以访问 ClusterIP10.103.143.120:80为例PREROUTING→KUBE-SERVICES总入口。匹配目标 IP 为 ClusterIP跳转至KUBE-SVC-XXXXXService 专属链。在该链中先执行SNAT非 Pod 网段来源需标记 Masquerade。通过statistic --mode random --probability实现负载均衡如 1/3、1/2、默认。跳转至KUBE-SEP-XXXXXEndpoint 链执行DNAT将目标 IP 改为具体 Pod IP。性能瓶颈每增加一个 Service/Endpoint就增加若干条 iptables 规则。当 Service 超过 1000 个时规则检索延迟显著上升CPU 飙升。查看命令iptables-save | grep ClusterIP可追踪整条规则链。2. IPVS 模式生产推荐数据链路客户端 → 宿主机网卡 → 内核 IPVS 虚拟服务器哈希表查找→ 直接转发至 PodReal Server。性能优势哈希表 O(1) 复杂度支持 10 万级 Service吞吐量远高于 iptables。调度算法支持rr轮询、wrr加权轮询最推荐、lc最少连接、sh源地址哈希配合 sessionAffinity。切换与验证# 修改 ConfigMapkubectl edit cm-nkube-system kube-proxy# 设置 mode: ipvs 和 scheduler: wrrkubectl rollout restart ds-nkube-system kube-proxy# 验证ipvsadm-Ln-t10.103.143.120:803. 权重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 资源是“声明”。没有 ControllerIngress 资源毫无作用。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不匹配/foobarImplementationSpecific由 IngressClass 决定通常同 Prefix涉及正则时常用此类型4. 生产级核心注解Annotation实战① 路径重写Rewrite Target—— 最常用annotations:nginx.ingress.kubernetes.io/use-regex:truenginx.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③ 限流与防刷防 CCannotations: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:truenginx.ingress.kubernetes.io/cors-allow-origin:https://frontend.com⑥ 超时与缓存annotations:nginx.ingress.kubernetes.io/proxy-read-timeout:60# 防止长连接断连nginx.ingress.kubernetes.io/proxy-cache:truenginx.ingress.kubernetes.io/proxy-cache-valid:200 302 10m⑦ 灰度发布基于权重annotations:nginx.ingress.kubernetes.io/canary:truenginx.ingress.kubernetes.io/canary-weight:10# 10% 流量进金丝雀后端⑧ 透传真实客户端 IPannotations:nginx.ingress.kubernetes.io/x-forwarded-for:truenginx.ingress.kubernetes.io/proxy-real-ip-cidr:10.0.0.0/85. 多域名与多路径配置示例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加--cascadeorphan。删除 Namespace 会强制删除该命名空间下所有资源包括正在运行的 Pod生产环境谨慎操作。常用排查命令# 查看控制器事件kubectl describe deployment/web kubectl describe replicaset/web-xxx# 查看 Pod 被谁控制kubectl describe pod web-xxx|grepControlled# 追踪 Service 后端端点kubectl get endpointssvc-name# 查看 Ingress Controller 日志kubectl logs-ningress-nginx deployment/ingress-nginx-controller# 进入容器测试 DNS 解析kubectl runtest--rm-it--imagebusybox --nslookupwebapp01.services.svc.cluster.local总结掌握Deployment 的滚动更新与回滚机制、Service 的三种发现方式、kube-proxy 的 IPVS 性能优势以及Ingress 的路径重写与限流配置是应对 K8s 生产环境日常运维和面试深挖的四大基石。
