Cilium Service Mesh 实战部署 Echo App 演示 Gateway 流量操纵与 Pod 级路由观测【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/ciliumCilium Service Mesh 文档中的 Echo App 是一个轻量级的应答回显工作负载专门为 Gateway API 相关的演示与验证而设计它由两组 echo server 组成收到请求后会在响应体中原样带回实际接收该请求的 Pod 的名称与命名空间。读完本文你将掌握该演示应用的完整部署方法、清单manifest中每个字段的工程含义以及如何在后续 Gateway / Header / 流量切分splitting等实验场景中通过响应体直接观测 Gateway 对流量的操纵结果。Echo App 的定位一个可观测路由行为的探针工作负载在 Cilium 的 Service Mesh 文档体系见 Service Mesh 文档索引中多个 Gateway API 章节例如 header.rst 与 splitting.rst都通过.. include:: ../echo-app.rst指令直接复用了本节的部署内容。也就是说Echo App 是整个 Gateway 演示体系的基础公共工作负载它模拟真实业务中的多副本服务echo-1 与 echo-2 两组各一个副本它不携带任何业务逻辑响应内容完全由请求上下文与 Pod 自身元数据决定因此响应体本身就是一份路由证据Cilium Service Mesh 基于 eBPF 内核数据面 Envoy 代理解析 HTTP/gRPC 等应用层协议且不向应用 Pod 注入 sidecar对比 demo-app.rst 中对 sidecar 方案的说明因此用这种无侵入的工作负载验证 L7 流量行为尤为直接。文档原文的核心思想是The application will reply to the client and, in the body of the reply, will include information about the Pod receiving the original request. We will use this information to illustrate how the traffic is manipulated by the Gateway.即客户端收到响应后通过响应体中携带的 Pod 信息即可判断这条流量最终被 Gateway 调度到了哪里——这正是验证 HTTPRoute 的 backendRefs、header 匹配、流量按比例切分等行为的观测手段。部署步骤官方文档给出的部署命令|SCM_WEB|是文档构建时替换为仓库地址的占位符仓库内对应文件为 examples/kubernetes/gateway/echo-basic.yaml$ kubectl apply -f 仓库地址/examples/kubernetes/gateway/echo-basic.yaml部署完成后按原文档要求验证 Pod 已按预期运行$ kubectl get pods NAME READY STATUS RESTARTS AGE echo-1-7d88f779b-m6r46 1/1 Running 0 21s echo-2-5bfb6668b4-n7llh 1/1 Running 0 21s可以看到两个 Pod 均处于1/1 Running状态。这里1/1也侧面印证了 Cilium Service Mesh 不注入 Envoy sidecar 的特性——若使用传统 sidecar 方案READY 列会显示2/2。清单解析echo-basic.yaml 的完整结构echo-basic.yaml 由 4 个资源对象组成两个 Service 两个 Deployment两组分别服务于 echo-1 与 echo-2。下面按原文档绝不删减的原则完整展开每个字段。Service 对象对外暴露端口--- apiVersion: v1 kind: Service metadata: labels: app: echo-1 name: echo-1 spec: ports: - port: 8080 # Service 对外端口ClusterIP 8080 name: high protocol: TCP targetPort: 3000 # 转发到 Pod 容器的 3000 端口 selector: app: echo-1要点echo-1 的 Service 端口为 8080echo-2 的 Service 端口为 8090两者端口刻意错开避免在同一命名空间内产生 Service 端口冲突targetPort: 3000对应容器内 echo server 实际监听端口selector: app: echo-1与 Deployment 模板 Pod 上的标签一致保证流量被正确选中。Deployment 对象echo server 容器--- apiVersion: apps/v1 kind: Deployment metadata: labels: app: echo-1 name: echo-1 spec: replicas: 1 # 每组仅 1 个副本 selector: matchLabels: app: echo-1 template: metadata: labels: app: echo-1 spec: containers: - image: registry.k8s.io/gateway-api/echo-basic:v1.5.1 # 当前仓库使用的版本 name: echo-1 ports: - containerPort: 3000 env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name # 注入 Pod 名称 - name: NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace # 注入命名空间echo-2 的 Deployment 结构完全相同仅标签、名称与镜像参数替换为 echo-2。从清单中可以看出响应体自报身份的实现原理镜像registry.k8s.io/gateway-api/echo-basic:v1.5.1是 Kubernetes Gateway API 官方提供的 echo 基础镜像。它收到任意 HTTP 请求后返回的响应体中包含请求方法、路径、请求头等上下文信息以及运行该容器的 Pod 身份Downward API 注入身份清单通过fieldRef把metadata.namePod 名与metadata.namespace分别注入为环境变量POD_NAME和NAMESPACE。echo server 进程读取这两个变量并写入响应体——这就是响应体里能看到echo-1-7d88f779b-m6r46这样的 Pod 名的直接来源副本数为 1每组只部署 1 个副本目的是让请求到达哪个组的判断结果没有副本内随机性干扰便于在 Gateway 演示中把路由结果与 backendRef 严格对应。注意仓库中另有一些旧路径示例如 echo-server.yaml、ingress-path-types.yaml、external-authz/manifests.yaml引用的是较旧的 staging 镜像gcr.io/k8s-staging-gateway-api/echo-basic:v20231214...等。Gateway 系列文档当前使用的统一入口是本文介绍的 examples/kubernetes/gateway/echo-basic.yamlv1.5.1。如何用它验证 Gateway 对流量操纵部署完成后echo-1 / echo-2 各自通过 Service8080 / 8090可被直接访问。直接请求任一 Pod 或 Service$ curl http://$(kubectl get pod -l appecho-1 -o jsonpath{.items[0].status.podIP}):3000/响应体将包含请求上下文与POD_NAME、NAMESPACE注入的 Pod 身份信息与kubectl get pods输出的 Pod 名如echo-1-7d88f779b-m6r46一一对应。在后续实验中验证逻辑始终是同一套在集群中创建 Gateway 与 HTTPRoute把入站流量转发到 echo-1 / echo-2可参考 basic-http.yaml通过 Gateway 地址发起请求检查响应体中的 Pod 名称是否落在 HTTPRoute 声明的 backendRef 上若 HTTPRoute 配置了 header 匹配或按比例切分对应 header.rst 与 splitting.rst 两节则分别带/不带特定 header 发送多次请求统计响应体中 echo-1 与 echo-2 出现的比例是否符合预期若涉及 ListenerSet 等场景可先kubectl -n listenerset-demo apply -f examples/kubernetes/gateway/echo-basic.yaml部署到演示命名空间见 listenerset.rst。由于 Cilium 的 Gateway 实现由 Envoy 在用户态完成 L7 匹配与转发、再由 eBPF 数据面完成高效转发echo 响应体中来自哪个 Pod的证据链恰好完整覆盖了 GatewayClass 参数、Gateway listener、HTTPRoute 规则三层配置的实际效果。小结Echo App 是 Cilium Gateway 演示体系的公共基础负载两组单副本 echo serverecho-1/echo-2镜像为registry.k8s.io/gateway-api/echo-basic:v1.5.1部署仅需一条命令kubectl apply -f 仓库地址/examples/kubernetes/gateway/echo-basic.yaml随后用kubectl get pods确认两个 Pod 均为1/1 Running可观测性来自 Downward APIPOD_NAME/NAMESPACE两个环境变量把 Pod 身份写入每个响应体使客户端无需登录节点即可判定流量落点适用前提集群已通过 Cilium 安装 Service MeshGateway API 相关能力并启用 Gateway 支持本文所有路径均相对于当前仓库根目录可直接在仓库中检索对应清单与文档继续深入。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cilium Service Mesh 实战：部署 Echo App 演示 Gateway 流量操纵与 Pod 级路由观测
Cilium Service Mesh 实战部署 Echo App 演示 Gateway 流量操纵与 Pod 级路由观测【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/ciliumCilium Service Mesh 文档中的 Echo App 是一个轻量级的应答回显工作负载专门为 Gateway API 相关的演示与验证而设计它由两组 echo server 组成收到请求后会在响应体中原样带回实际接收该请求的 Pod 的名称与命名空间。读完本文你将掌握该演示应用的完整部署方法、清单manifest中每个字段的工程含义以及如何在后续 Gateway / Header / 流量切分splitting等实验场景中通过响应体直接观测 Gateway 对流量的操纵结果。Echo App 的定位一个可观测路由行为的探针工作负载在 Cilium 的 Service Mesh 文档体系见 Service Mesh 文档索引中多个 Gateway API 章节例如 header.rst 与 splitting.rst都通过.. include:: ../echo-app.rst指令直接复用了本节的部署内容。也就是说Echo App 是整个 Gateway 演示体系的基础公共工作负载它模拟真实业务中的多副本服务echo-1 与 echo-2 两组各一个副本它不携带任何业务逻辑响应内容完全由请求上下文与 Pod 自身元数据决定因此响应体本身就是一份路由证据Cilium Service Mesh 基于 eBPF 内核数据面 Envoy 代理解析 HTTP/gRPC 等应用层协议且不向应用 Pod 注入 sidecar对比 demo-app.rst 中对 sidecar 方案的说明因此用这种无侵入的工作负载验证 L7 流量行为尤为直接。文档原文的核心思想是The application will reply to the client and, in the body of the reply, will include information about the Pod receiving the original request. We will use this information to illustrate how the traffic is manipulated by the Gateway.即客户端收到响应后通过响应体中携带的 Pod 信息即可判断这条流量最终被 Gateway 调度到了哪里——这正是验证 HTTPRoute 的 backendRefs、header 匹配、流量按比例切分等行为的观测手段。部署步骤官方文档给出的部署命令|SCM_WEB|是文档构建时替换为仓库地址的占位符仓库内对应文件为 examples/kubernetes/gateway/echo-basic.yaml$ kubectl apply -f 仓库地址/examples/kubernetes/gateway/echo-basic.yaml部署完成后按原文档要求验证 Pod 已按预期运行$ kubectl get pods NAME READY STATUS RESTARTS AGE echo-1-7d88f779b-m6r46 1/1 Running 0 21s echo-2-5bfb6668b4-n7llh 1/1 Running 0 21s可以看到两个 Pod 均处于1/1 Running状态。这里1/1也侧面印证了 Cilium Service Mesh 不注入 Envoy sidecar 的特性——若使用传统 sidecar 方案READY 列会显示2/2。清单解析echo-basic.yaml 的完整结构echo-basic.yaml 由 4 个资源对象组成两个 Service 两个 Deployment两组分别服务于 echo-1 与 echo-2。下面按原文档绝不删减的原则完整展开每个字段。Service 对象对外暴露端口--- apiVersion: v1 kind: Service metadata: labels: app: echo-1 name: echo-1 spec: ports: - port: 8080 # Service 对外端口ClusterIP 8080 name: high protocol: TCP targetPort: 3000 # 转发到 Pod 容器的 3000 端口 selector: app: echo-1要点echo-1 的 Service 端口为 8080echo-2 的 Service 端口为 8090两者端口刻意错开避免在同一命名空间内产生 Service 端口冲突targetPort: 3000对应容器内 echo server 实际监听端口selector: app: echo-1与 Deployment 模板 Pod 上的标签一致保证流量被正确选中。Deployment 对象echo server 容器--- apiVersion: apps/v1 kind: Deployment metadata: labels: app: echo-1 name: echo-1 spec: replicas: 1 # 每组仅 1 个副本 selector: matchLabels: app: echo-1 template: metadata: labels: app: echo-1 spec: containers: - image: registry.k8s.io/gateway-api/echo-basic:v1.5.1 # 当前仓库使用的版本 name: echo-1 ports: - containerPort: 3000 env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name # 注入 Pod 名称 - name: NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace # 注入命名空间echo-2 的 Deployment 结构完全相同仅标签、名称与镜像参数替换为 echo-2。从清单中可以看出响应体自报身份的实现原理镜像registry.k8s.io/gateway-api/echo-basic:v1.5.1是 Kubernetes Gateway API 官方提供的 echo 基础镜像。它收到任意 HTTP 请求后返回的响应体中包含请求方法、路径、请求头等上下文信息以及运行该容器的 Pod 身份Downward API 注入身份清单通过fieldRef把metadata.namePod 名与metadata.namespace分别注入为环境变量POD_NAME和NAMESPACE。echo server 进程读取这两个变量并写入响应体——这就是响应体里能看到echo-1-7d88f779b-m6r46这样的 Pod 名的直接来源副本数为 1每组只部署 1 个副本目的是让请求到达哪个组的判断结果没有副本内随机性干扰便于在 Gateway 演示中把路由结果与 backendRef 严格对应。注意仓库中另有一些旧路径示例如 echo-server.yaml、ingress-path-types.yaml、external-authz/manifests.yaml引用的是较旧的 staging 镜像gcr.io/k8s-staging-gateway-api/echo-basic:v20231214...等。Gateway 系列文档当前使用的统一入口是本文介绍的 examples/kubernetes/gateway/echo-basic.yamlv1.5.1。如何用它验证 Gateway 对流量操纵部署完成后echo-1 / echo-2 各自通过 Service8080 / 8090可被直接访问。直接请求任一 Pod 或 Service$ curl http://$(kubectl get pod -l appecho-1 -o jsonpath{.items[0].status.podIP}):3000/响应体将包含请求上下文与POD_NAME、NAMESPACE注入的 Pod 身份信息与kubectl get pods输出的 Pod 名如echo-1-7d88f779b-m6r46一一对应。在后续实验中验证逻辑始终是同一套在集群中创建 Gateway 与 HTTPRoute把入站流量转发到 echo-1 / echo-2可参考 basic-http.yaml通过 Gateway 地址发起请求检查响应体中的 Pod 名称是否落在 HTTPRoute 声明的 backendRef 上若 HTTPRoute 配置了 header 匹配或按比例切分对应 header.rst 与 splitting.rst 两节则分别带/不带特定 header 发送多次请求统计响应体中 echo-1 与 echo-2 出现的比例是否符合预期若涉及 ListenerSet 等场景可先kubectl -n listenerset-demo apply -f examples/kubernetes/gateway/echo-basic.yaml部署到演示命名空间见 listenerset.rst。由于 Cilium 的 Gateway 实现由 Envoy 在用户态完成 L7 匹配与转发、再由 eBPF 数据面完成高效转发echo 响应体中来自哪个 Pod的证据链恰好完整覆盖了 GatewayClass 参数、Gateway listener、HTTPRoute 规则三层配置的实际效果。小结Echo App 是 Cilium Gateway 演示体系的公共基础负载两组单副本 echo serverecho-1/echo-2镜像为registry.k8s.io/gateway-api/echo-basic:v1.5.1部署仅需一条命令kubectl apply -f 仓库地址/examples/kubernetes/gateway/echo-basic.yaml随后用kubectl get pods确认两个 Pod 均为1/1 Running可观测性来自 Downward APIPOD_NAME/NAMESPACE两个环境变量把 Pod 身份写入每个响应体使客户端无需登录节点即可判定流量落点适用前提集群已通过 Cilium 安装 Service MeshGateway API 相关能力并启用 Gateway 支持本文所有路径均相对于当前仓库根目录可直接在仓库中检索对应清单与文档继续深入。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考