一、Pod变化需要稳定入口Kubernetes 中 Pod 会因为扩缩容、滚动发布、节点故障而不断变化直接访问 Pod IP 不可靠。Service 提供稳定的虚拟入口并通过标签选择后端 Pod。Ingress 则在集群入口层按域名和路径管理 HTTP/HTTPS 流量。两者配合才能把内部服务发现和外部访问解耦。对象作用典型范围ClusterIP集群内访问内部服务NodePort节点端口暴露测试或特殊场景LoadBalancer云负载均衡公网入口Ingress七层路由域名、路径、TLS二、Service如何选择后端Service 通过 selector 匹配 Pod 标签。只要标签一致EndpointSlice 会自动维护后端地址。下面的 Service 把流量转给带有app: order-api的 Pod。apiVersion:v1kind:Servicemetadata:name:order-apispec:type:ClusterIPselector:app:order-apiports:-name:httpport:80targetPort:8080这里port是 Service 暴露端口targetPort是容器端口。排障时要检查三件事Service selector 是否匹配 Pod 标签Pod readiness 是否通过EndpointSlice 是否生成。如果 Service 没有 endpointsIngress 再正确也无法访问后端。三、Ingress负责七层路由Ingress 只是规则对象真正执行流量转发的是 Ingress Controller例如 Nginx Ingress、Traefik 或云厂商控制器。下面示例把api.example.com/orders转发到order-api。apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:api-ingressspec:ingressClassName:nginxrules:-host:api.example.comhttp:paths:-path:/orderspathType:Prefixbackend:service:name:order-apiport:number:80生产环境还要配置 TLS、请求体大小、超时、限流和访问日志。不同 Controller 的注解不同团队应收敛成模板避免每个服务随意复制配置。四、流量治理与发布Service 和 Ingress 也参与发布策略。滚动发布依赖 readinessProbe 控制新 Pod 何时接流量灰度发布可通过多个 Service、Ingress 权重或服务网格实现。基础检查命令如下kubectl get svc,endpointslice,ingress-nprod kubectl describe ingress api-ingress-nprod kubectl get pod-lapporder-api-nprod当出现 502 或 504 时要沿着链路看DNS 是否到入口负载均衡Ingress Controller 是否收到请求Service 是否有 endpointPod 是否 ready应用是否超时。Kubernetes 流量管理不是只写 YAML而是让入口、服务发现、健康检查和发布节奏形成闭环。命名空间和网络策略也会影响流量。多团队集群中Service 名称应清晰表达领域和用途避免跨命名空间随意访问。若启用了 NetworkPolicy要确认 Ingress Controller 到业务 Pod、业务 Pod 到依赖服务的方向都被允许。TLS 证书可以交给 cert-manager 自动签发和续期但续期失败需要告警。对外入口还应限制请求体大小、连接时间和来源 IP防止单个入口规则拖垮整个控制面。在生产落地时建议为每个服务准备固定的排障清单域名解析、Ingress 规则、Controller 日志、Service endpoints、Pod readiness、应用日志和后端依赖。这样一线同学遇到故障时能按链路定位而不是在大量 YAML 中盲目搜索。Service 与 Ingress 的价值正是把动态 Pod 背后的访问关系变成稳定、可审计的声明。容量规划也不能忽略。Ingress Controller 本身需要副本、资源限制和水平扩缩容入口负载均衡也要能承接峰值连接。对于核心业务建议把入口层指标接入告警包括请求量、错误率、延迟、连接数和重载失败次数。只有入口组件自身稳定后端服务的弹性才有意义。 本文是《云原生工程实战》系列持续更新关注不迷路。 下一篇《云原生CI/CD流水线设计与GitOps实践》讲流量入口配置如何纳入可审计、可回滚的发布流程。 你在实际项目里遇到过 Service 可用但 Ingress 路由不通的问题吗评论区聊聊。觉得有用点个赞收藏方便回头查阅 相关可运行源码/资料已整理成资源包可在我主页的资源里自取。☁️ 本文示例需要一台云服务器新用户可通过此链接领取优惠自用https://cloud.tencent.com/act/cps/redirect?redirect2446cps_key49a769c067bd9c9f53fcb1bdf9feaf23fromconsolecps_promotion_id102832
一、Pod变化需要稳定入口Kubernetes 中 Pod 会因为扩缩容、滚动发布、节点故障而不断变化直接访问 Pod IP 不可靠。Service 提供稳定的虚拟入口并通过标签选择后端 Pod。Ingress 则在集群入口层按域名和路径管理 HTTP/HTTPS 流量。两者配合才能把内部服务发现和外部访问解耦。对象作用典型范围ClusterIP集群内访问内部服务NodePort节点端口暴露测试或特殊场景LoadBalancer云负载均衡公网入口Ingress七层路由域名、路径、TLS二、Service如何选择后端Service 通过 selector 匹配 Pod 标签。只要标签一致EndpointSlice 会自动维护后端地址。下面的 Service 把流量转给带有app: order-api的 Pod。apiVersion:v1kind:Servicemetadata:name:order-apispec:type:ClusterIPselector:app:order-apiports:-name:httpport:80targetPort:8080这里port是 Service 暴露端口targetPort是容器端口。排障时要检查三件事Service selector 是否匹配 Pod 标签Pod readiness 是否通过EndpointSlice 是否生成。如果 Service 没有 endpointsIngress 再正确也无法访问后端。三、Ingress负责七层路由Ingress 只是规则对象真正执行流量转发的是 Ingress Controller例如 Nginx Ingress、Traefik 或云厂商控制器。下面示例把api.example.com/orders转发到order-api。apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:api-ingressspec:ingressClassName:nginxrules:-host:api.example.comhttp:paths:-path:/orderspathType:Prefixbackend:service:name:order-apiport:number:80生产环境还要配置 TLS、请求体大小、超时、限流和访问日志。不同 Controller 的注解不同团队应收敛成模板避免每个服务随意复制配置。四、流量治理与发布Service 和 Ingress 也参与发布策略。滚动发布依赖 readinessProbe 控制新 Pod 何时接流量灰度发布可通过多个 Service、Ingress 权重或服务网格实现。基础检查命令如下kubectl get svc,endpointslice,ingress-nprod kubectl describe ingress api-ingress-nprod kubectl get pod-lapporder-api-nprod当出现 502 或 504 时要沿着链路看DNS 是否到入口负载均衡Ingress Controller 是否收到请求Service 是否有 endpointPod 是否 ready应用是否超时。Kubernetes 流量管理不是只写 YAML而是让入口、服务发现、健康检查和发布节奏形成闭环。命名空间和网络策略也会影响流量。多团队集群中Service 名称应清晰表达领域和用途避免跨命名空间随意访问。若启用了 NetworkPolicy要确认 Ingress Controller 到业务 Pod、业务 Pod 到依赖服务的方向都被允许。TLS 证书可以交给 cert-manager 自动签发和续期但续期失败需要告警。对外入口还应限制请求体大小、连接时间和来源 IP防止单个入口规则拖垮整个控制面。在生产落地时建议为每个服务准备固定的排障清单域名解析、Ingress 规则、Controller 日志、Service endpoints、Pod readiness、应用日志和后端依赖。这样一线同学遇到故障时能按链路定位而不是在大量 YAML 中盲目搜索。Service 与 Ingress 的价值正是把动态 Pod 背后的访问关系变成稳定、可审计的声明。容量规划也不能忽略。Ingress Controller 本身需要副本、资源限制和水平扩缩容入口负载均衡也要能承接峰值连接。对于核心业务建议把入口层指标接入告警包括请求量、错误率、延迟、连接数和重载失败次数。只有入口组件自身稳定后端服务的弹性才有意义。 本文是《云原生工程实战》系列持续更新关注不迷路。 下一篇《云原生CI/CD流水线设计与GitOps实践》讲流量入口配置如何纳入可审计、可回滚的发布流程。 你在实际项目里遇到过 Service 可用但 Ingress 路由不通的问题吗评论区聊聊。觉得有用点个赞收藏方便回头查阅 相关可运行源码/资料已整理成资源包可在我主页的资源里自取。☁️ 本文示例需要一台云服务器新用户可通过此链接领取优惠自用https://cloud.tencent.com/act/cps/redirect?redirect2446cps_key49a769c067bd9c9f53fcb1bdf9feaf23fromconsolecps_promotion_id102832
