当前位置： 首页 > news >正文

Kubernetes 工作负载与网络核心：从 Controller 到 Ingress 生产级实践

news 2026/6/30 4:32:02

第一部分：工作负载控制器（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。
  • 节点故障自愈时间线（需熟记）：
    1. kubelet 每 10s 上报心跳。
    2. controller-manager 每 5s 检查，连续 40s 无心跳标记节点NotReady。
    3. 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采集指标。

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）

  • 实现思路：
    1. 稳定版 Deployment（track: stable）副本数 10。
    2. 金丝雀版 Deployment（track: canary）副本数 1。
    3. Service 的selector只匹配通用标签（如app: web, tier: frontend），不区分track。
    4. 流量自动按 Pod 数量比例分发（10:1）。
    5. 逐步调整两边的副本数（如 8:2、6:4、0:10）完成全量发布。
  • 优点：无需修改 Service，纯副本数控制，简单可靠。

第三部分：kube-proxy 工作原理（iptables vs IPVS）

kube-proxy 是 Service 流量转发的核心组件，理解其原理对排查网络问题至关重要。

1. iptables 模式（默认）

  • 数据链路（以访问 ClusterIP10.103.143.120:80为例）：
    1. PREROUTING→KUBE-SERVICES（总入口）。
    2. 匹配目标 IP 为 ClusterIP，跳转至KUBE-SVC-XXXXX（Service 专属链）。
    3. 在该链中：先执行SNAT（非 Pod 网段来源需标记 Masquerade）。
    4. 通过statistic --mode random --probability实现负载均衡（如 1/3、1/2、默认）。
    5. 跳转至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. 架构与工作流程

  1. 部署Ingress Controller（如 ingress-nginx），本质是一个 Nginx Pod，通过 LoadBalancer Service 对外暴露。
  2. 创建Ingress 资源（定义 host、path、backend）。
  3. 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 生产环境日常运维和面试深挖的四大基石。

http://www.jsqmd.com/news/1093750/

相关文章：

  • LoRA训练实战61：Krea2人物角色LoRA保姆级训练教程，几分钟捏出专属IP！
  • 一款H5播放器，搞定所有流媒体协议？EasyPlayer.js流媒体播放器到底有多强
  • 数据脱敏方法有哪些？一文盘点数据脱敏常用方法
  • OTA升级包签名被伪造，13万辆车被迫召回：签名链路安全怎么做才对？
  • 【车载】轮速-AK协议：从电流信号到车辆控制的解码之旅
  • 2026私域下半场：如何利用AI微信机器人打造专属的智能销冠？
  • Skills开源项目：为AI Agent提供标准化技能库，实现代码仓库自动化操作
  • 全球AI可见性基础建设：从“内容传播”到“AI信息标准协议”的重构
  • 海外信号覆盖不好怎么办？跨境IoT设备弱信号问题深度解析
  • AI 赋能接口自动化测试系列（二）：全场景测试数据智能构造Agent Skill
  • Frida模块加载技术：从内存加载到对抗检测的实战指南
  • 后端架构演进：微服务与单体应用如何选择
  • 靠谱的2026年6月六安GEO优化选哪家
  • AI Agent多智能体系统在金融投资分析中的实战应用
  • 2026 年小程序开发公司推荐，靠谱服务商汇总
  • 内卷VS躺平VS转型：2026年程序员的第三条路
  • VMware虚拟机安装Ubuntu实践记录
  • 一键部署不是为了省时间 —— 它是把“买来的 PaaS“变成“自己的平台“的拐点
  • 工业级低功耗采集器：智能采集，赋能物联监测
  • Postman接口自动化测试：从脚本到可视化报告的完整实践
  • TAS5716数字音频功放：从DSP处理到PWM驱动的完整设计指南
  • Windows系统文件api-ms-win-core-shlwapi-legacy-l1-1-0.dll丢失找不到问题解决
  • 打进内网后一脸懵？内网渗透第一步——信息收集决定了你能走多远
  • 告别SPSS繁琐操作！百考通AI，搞定经管社科量化论文实证难题
  • 银企直联技术选型：专线前置机 vs API直连 vs 统一API聚合
  • AI-Berkshire多智能体投资研究框架：从环境部署到实战调优指南
  • 第九章-云端纪元《改变世界的程序员》
  • 字节开源Deer-Flow：AI工作流编排引擎实战，构建可靠应用管道
  • etcd安全升级实战：修复JWT漏洞与滚动更新K8s集群大脑
  • 阿姆智创IBOX-6076R工控设备方案，深耕SMT产线与机器视觉领域