Kubernetes

Istio 流量管理教程 适用范围 本文基于 Istio 1.30.3 官方文档，说明 Sidecar 模式下的流量管理模型和核心 API。重点是理解 Istio 如何在不修改业务代码的前提下控制服务间流量。 本文覆盖： Gateway：网格边缘的入站或出站代理入口。 VirtualService：流量匹配、路由、超时、重试、故障注入、镜像。 DestinationRule：服务子集、负载均衡、连接池、熔断、异常实例剔除、TLS 策略。 ServiceEntry：把网格外服务加入 Istio 服务注册表。 Sidecar：限制 Envoy Sidecar 的入站端口和出站可见服务范围。 数据面排障思路：从路由、cluster、endpoint、listener 四类 Envoy 配置定位问题。 本文不覆盖 Istio 安装、Bookinfo 部署、Ambient 模式、授权策略、Telemetry API、多集群和生产发布流程。 流量管理模型 Sidecar 模式下，每个业务 Pod 注入一个 Envoy 容器。业务进程仍然访问 Kubernetes Service 或外部域名，真实转发行为由 Envoy 根据 Istio 配置决定。istiod 负责监听 Kubernetes 和 Istio 配置资源，把它们转换为 Envoy xDS 配置，并下发给数据面代理。 flowchart LR C[Client] --> IG[Istio Ingress Gateway / Envoy] IG --> A1[Service A Sidecar] A1 --> A2[Service A App] A2 --> A3[Service A Sidecar] A3 --> B1[Service B Sidecar] B1 --> B2[Service B App] ISTIOD[istiod] -. xDS .-> IG ISTIOD -. xDS .-> A1 ISTIOD -. xDS .-> A3 ISTIOD -. xDS .-> B1典型 HTTP 调用路径： ...

前言 最近在本地虚拟机环境（CentOS 7）搭建 Kubernetes 集群运行微服务 Demo 时，遇到一个非常诡异的“灵异事件”。 起因：由于宿主机休眠，我挂起（Suspend）了一段时间虚拟机。 现象：恢复运行后，集群状态看起来一切正常（Node Ready，Pod Running），但访问 NodePort 暴露的服务时，直接报 502 Bad Gateway。 排查过程极其曲折，从 HTTP 协议一路查到 Linux 内核参数，最终发现是操作系统在网络重置时的“安全机制”坑了 Kubernetes。本文记录了完整的排查思路，希望能帮大家避坑。 🕵️‍♂️ 第一阶段：表象排查（Application Layer） 首先，我尝试访问前端服务： BASHcurl -I http://192.168.6.141:30007/ # HTTP/1.1 502 Bad Gateway 初步分析： 502 通常意味着网关（Service/Kube-proxy）找不到后端 Pod，或者连接被拒绝。 检查 Pod 状态：kubectl get pods -A 显示所有 Pod 均为 Running 且 Ready (1/1)。应用没挂。 检查 Service 关联：kubectl get ep frontend 显示 Endpoints 存在且 IP 正确（如 10.244.104.23:8080）。 看日志：查看 Frontend Pod 日志，没有报错，甚至显示 Server started。 奇怪点：应用活着，配置没动过，重启前好好的，恢复后就断了。 ...