Istio Proxyless gRPC 实战使用grpc-agent注入模板让 gRPC 应用直连 istiod以 grpc-echo 示例为例【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio本篇指南围绕 Istio 仓库中的官方示例 samples/grpc-echo 展开介绍其核心能力Proxyless无 Sidecar 代理数据面gRPC 支持。它通过一种名为grpc-agent的特殊注入模板向 Pod 注入istio-proxySidecar——但该容器内只运行pilot-agent完全不启动 Envoy改由 gRPC 客户端自身的 xDS 能力直接与 istiod 通信。读完本文你将掌握grpc-agent注入模板的工作原理、echo 示例的完整部署资源结构以及 gRPC 应用接入 Istio 服务网格所需的引导bootstrap、证书与代理容器app container改造方式并能直接对照仓库源码理解其底层实现。一、什么是 Proxyless gRPC示例文档的定位grpc-echo示例的官方说明非常精炼它指出了两个关键事实该示例用于演示Istio 的 Proxyless gRPC 支持其实现依赖一个特殊的注入模板grpc-agent——模板照常注入istio-proxySidecar但该 Sidecar只会运行pilot-agent而不会运行 Envoy。之所以称为 Proxyless是因为传统服务网格中数据面的流量劫持与转发由 Envoy 完成而在 Proxyless 模式下数据面职能下沉到 gRPC 库本身——现代 gRPC 客户端原生支持基于 xDS 协议的服务发现、负载均衡、超时与集群管理不再需要业务进程旁路的 Envoy 参与数据转发。关于 gRPC 对 xDS 各项特性的支持矩阵官方文档指向 gRPC 上游的doc/grpc_xds_features.md特征状态说明读者在评估功能可行性时应参考该能力清单。从代码结构看这也印证了仓库对这类工作负载的专门支持pkg/test/framework/components/echo/kube/testdata/proxyless.yaml 与proxyless-custom-image.yaml等测试数据的存在说明 Proxyless 已成为集成测试框架中 echo 组件的标准部署形态之一。二、grpc-agent注入模板注入 Sidecar 但不运行 Envoy2.1 模板从哪来、如何被使用grpc-agent并不是硬编码在代码里的逻辑而是一段sidecar 注入模板由 istiod 的注入配置通过 ConfigMap 提供。模板文件本体位于manifests/charts/istio-control/istio-discovery/files/grpc-agent.yamlHelm chart 内嵌的模板源istiod-injector-configmap.yaml将模板打包进注入器 ConfigMap 的grpc-agentkey用户侧只需在 Deployment 的 Pod template 上声明式选用该模板annotations: inject.istio.io/templates: grpc-agent仓库中samples/grpc-echo/grpc-echo.yaml的 echo-v1/echo-v2 两个 Deployment 正是这样声明的。同时注入器单元测试数据 pkg/kube/inject/testdata/inject/grpc-agent.yaml 及其grpc-agent.yaml.injected产物也用于校验模板渲染结果的一致性。2.2 模板的核心机制DISABLE_ENVOYtrue对比普通 Sidecar 注入模板grpc-agent的关键差异在于给istio-proxy容器注入了以下环境变量见 grpc-agent.yaml# grpc 使用 xds:/// 解析无需解析 ClusterIP因此关闭 DNS 捕获 - name: ISTIO_META_DNS_CAPTURE value: false - name: DISABLE_ENVOY value: trueDISABLE_ENVOYtruepilot-agent启动后不再拉起 Envoy 子进程仅作为代理进程存在负责后续的 SDS 证书签发与 xDS 网关职责。ISTIO_META_DNS_CAPTUREfalseProxyless 的 gRPC 通过xds:///目标名解析上游无需像 Envoy 那样捕获 DNS 来重写虚拟 IP。istio-proxy容器的启动参数则照常使用pilot-agent proxy sidecarargs 中的proxy sidecar --domain ... --proxyLogLevel ...因此容器镜像仍是proxyv2只是 Envoy 未被拉起。这也是为什么 README 表述为Sidecar 只会运行 pilot-agent 而不是 envoy。2.3 代理与业务容器之间的通道UDS 证书目录模板在 Pod 中建立了三块关键共享存储对应渲染结果 grpc-agent.yaml.injected 中的 volume 定义卷挂载类型挂载点作用workload-certsemptyDir/var/run/secrets/workload-spiffe-credentials存放 pilot-agent 通过 SDS 签发的 SPIFFE 身份证书供 gRPC mTLS 使用workload-socketemptyDir/var/run/secrets/workload-spiffe-udsUDS 证书通道istio-xdsemptyDirMemory/etc/istio/proxypilot-agent 与 gRPC 客户端之间的 UDS 通道用于 XDS/SDS模板源码中的注释直接写明了这一设计意图grpc-agent.yaml# UDS channel between istioagent and gRPC client for XDS/SDS - mountPath: /etc/istio/proxy name: istio-xds也就是说pilot-agent 通过本地 Unix Domain Socket 向同 Pod 的 gRPC 应用提供 xDS 配置下发与 SDS 证书服务gRPC 应用侧则依赖模板自动注入的两个环境变量来对接见模板对业务容器的改写逻辑env: - name: GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORT value: true - name: GRPC_XDS_BOOTSTRAP value: /etc/istio/proxy/grpc-bootstrap.jsonGRPC_XDS_BOOTSTRAP指向/etc/istio/proxy/grpc-bootstrap.json——该文件由 pilot-agent 生成声明 xDS 服务器地址通过istio-xdsUDS与节点身份等GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORTtrue让 gRPC 启用基于 SDS 的证书换取能力从而获得与 Envoy 一致的 mTLS 通信同时模板还会把istio-data/var/lib/istio/dataagent 输出证书的目录挂载进业务容器OUTPUT_CERTS/var/lib/istio/data正是 pilot-agent 落盘证书的位置见渲染结果中的OUTPUT_CERTS环境变量。此外模板将ISTIO_META_GENERATORgrpc注入 istio-proxyistiod 据此可识别该工作负载是 Proxyless gRPC 类型从而按 gRPC 生成器逻辑下发 xDS 资源。模板还保留了标准的 readiness 探针/healthz/ready位于 15020 端口由 pilot-agent 提供健康检查端点确保 Pod 在 agent 就绪前不会被纳入流量。2.4 与grpc-simple模板的区别若希望对比仓库中还存在另一种更轻的 Proxyless 模板 grpc-simple.yaml它完全不注入istio-proxy容器而是通过一个busyboxinitContainer 手写 bootstrap 文件xds_servers直接指向dns:///istiod.ns.svc:15010并要求业务进程自行处理证书。而grpc-agent方案保留了 pilot-agent从而复用 istiod 的证书签发与 xDS 代理通道业务容器无需感知 istiod 地址与 CA 细节是更接近完整网格体验的 Proxyless 形态。三、示例部署资源详解echo Service 与 v1/v2 双 Deploymentgrpc-echo示例的完整清单为 samples/grpc-echo/grpc-echo.yaml包含一个echo服务和 v1/v2 两个版本的 Deployment目标命名空间均为echo-grpc使用前需自行创建该 namespace。3.1 Service一个工作负载暴露多协议端口apiVersion: v1 kind: Service metadata: name: echo namespace: echo-grpc spec: selector: app: echo type: ClusterIP ports: - name: http port: 80 targetPort: 18080 - name: grpc port: 7070 targetPort: 17070 - name: tcp port: 9090 targetPort: 19090该 Service 将后端的 echo 应用同时以 HTTP80→18080、gRPC7070→17070与裸 TCP9090→19090三种协议暴露给集群方便在验证 Proxyless gRPC 的同时用 HTTP/TCP 流量做对照实验。3.2 Deployment两个版本 grpc-agent注入echo-v1 与 echo-v2 结构几乎一致仅在--version v1/v2参数与--xds-grpc-server17070等细项上区分。二者都在 Pod template 上声明annotations: inject.istio.io/templates: grpc-agent proxy.istio.io/config: {holdApplicationUntilProxyStarts: true}第二个注解holdApplicationUntilProxyStarts: true保证业务容器在 pilot-agentistio-proxy完成启动并写好 bootstrap 文件之前不会先启动避免 gRPC 客户端初始化时读不到/etc/istio/proxy/grpc-bootstrap.json或连接不上 UDS——这是 Proxyless 部署中非常关键的启动顺序控制。业务容器app镜像registry.istio.io/testing/app:latest通过命令行参数开启多协议监听与 xDS 端点参数含义从示例参数组合推断--port 18080HTTP 服务端口对应 Service 的 http 80--port 8080/--port 3333附加端口其中 3333 同时作为tcp-health-port供探针使用--grpc 17070gRPC 服务端口对应 Service 的 grpc 7070同时配合--xds-grpc-server17070表示该端口通过 xDS 下发--grpc 17171第二个 gRPC 监听端口示例用于验证 xDS 对多端口/动态端口的配置下发--tcp 19090TCP 端口对应 Service 的 tcp 9090--metrics15014指标暴露端口--crt/cert.crt/--key/cert.keymTLS 证书与密钥路径--version v1/v2实例版本标识容器声明了17070、17171、8080、3333四个 containerPort3333名为tcp-health-port并配置了完善的健康检查startupProbe 与 livenessProbe 均以 TCP 连接tcp-health-port判定readinessProbe 通过 HTTP GET/8080 端口判定同时INSTANCE_IP通过 downwardAPI 注入 Pod IP 供应用上报自身地址。四、结合仓库验证注入效果与集成测试4.1 从注入产物看最终 Pod 形态查看测试数据 pkg/kube/inject/testdata/inject/grpc-agent.yaml.injected可以看到grpc-agent模板渲染后的典型 Pod 结构业务容器如traffic被自动追加GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORTtrue与GRPC_XDS_BOOTSTRAP/etc/istio/proxy/grpc-bootstrap.json环境变量并挂载istio-xds、workload-certs、istio-data卷istio-proxy 容器DISABLE_ENVOYtrue无 Envoy 数据面仅由 pilot-agent 提供 15020 健康端口与istio-proxy wait的 postStart 逻辑注入器在sidecar.istio.io/status注解中登记的容器即为[istio-proxy,traffic]istio.io/rev: default表示使用 default 版本注入。4.2 pilot-agent 侧的支撑实现从源码角度看grpc-bootstrap.json的生成逻辑位于 pilot-agent 的启动选项中pilot/cmd/pilot-agent/options/options.go与grpc-bootstrap关键词匹配其职责是把 xDS 服务器地址收敛为本地 UDS 端点并输出给同 Pod 的 gRPC 库使用而 istiod 侧的pilot/pkg/networking/grpcgen则是为这类工作负载生成 gRPC 专属 xDS 配置的生成器参见其测试 grpcgen_test.go其中包含对grpc-bootstrap相关配置的断言从源码结构可以推断pilot 已为ISTIO_META_GENERATORgrpc的工作负载走独立的 grpcgen 配置生成链路。4.3 端到端验证方式仓库的 Proxyless 场景已在集成测试框架中固化pkg/test/framework/components/echo/kube/testdata/proxyless.yaml与proxyless-custom-image.yaml展示了用 echo 组件一键部署 Proxyless 工作负载的测试模板pkg/test/framework/components/echo/common/deployment/echos.go中的公共部署逻辑会根据配置选择注入grpc-agent。因此想要亲自复现本示例的读者可以直接基于samples/grpc-echo/grpc-echo.yaml在已安装 Istio含 istiod 注入器与grpc-agent模板的集群中创建echo-grpc命名空间并应用清单随后使用任意 gRPC 客户端以xds:///echo/grpc示例中 xDS 服务名为 Service DNSecho端口为 gRPC 端口发起调用即可观察 gRPC 库通过 pilot-agent 从 istiod 拉取端点并完成负载均衡与 mTLS。五、实战注意事项与限制前置条件grpc-agent模板随 istiod 注入器 ConfigMap 一起发布要求网格内的注入器版本与模板匹配Helm 渲染的 istiod-injector-configmap.yaml 默认已内置grpc-agent且业务代码需使用支持 xDS 的 gRPC 版本部分能力仍属实验特性需设置 gRPC 侧实验开关详见 gRPC 上游的 xDS 特性状态文档。探针重写需关闭模板会强制写入sidecar.istio.io/rewriteAppHTTPProbers: false因为无 Envoy 时探针无法被代理改写应用必须自行对外暴露 HTTP/TCP 探针端点。启动顺序务必像示例那样设置holdApplicationUntilProxyStarts: true确保 gRPC 库启动前 bootstrap 与 UDS 已就绪同时istio-proxy的 readiness 探针15020/healthz/ready能反映 agent 就绪状态。能力边界Proxyless 模式只覆盖 gRPC 库已实现的 xDS 特性如集群发现、负载均衡、超时、mTLS对于 HTTP/TCP 等其他协议的治理仍需传统 Envoy Sidecar本示例中的 HTTP 与 TCP 端口更多用于对照与探针场景真正被网格化的是 17070/17171 这两个 gRPC 端口。标签与身份模板注释grpc-agent.yaml提醒若 gRPC 使用 mTLS 初始化代码security.istio.io/tlsMode: istio标签必须由用户在 workload 上自行设置模板不会自动添加。六、小结与延伸阅读grpc-echo虽然只是一个示例但它清晰地演示了 Istio Proxyless gRPC 的完整落地路径一条注入注解grpc-agent 一份由 pilot-agent 生成的 bootstrap gRPC 库原生 xDS 客户端即可在不引入 Envoy 数据面的前提下让 gRPC 服务融入服务网格获得证书签发SDS、服务发现与负载均衡等能力。对于想要深入探究的读者仓库内可按以下顺序继续阅读模板实现manifests/charts/istio-control/istio-discovery/files/grpc-agent.yaml 与对照版本 grpc-simple.yaml注入渲染产物pkg/kube/inject/testdata/inject/grpc-agent.yaml.injected测试部署形态pkg/test/framework/components/echo/kube/testdata/proxyless.yaml配置生成实现pilot/pkg/networking/grpcgen及其 测试本示例清单samples/grpc-echo/grpc-echo.yaml【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Istio Proxyless gRPC 实战：使用 `grpc-agent` 注入模板让 gRPC 应用直连 istiod（以 grpc-echo 示例为例）
Istio Proxyless gRPC 实战使用grpc-agent注入模板让 gRPC 应用直连 istiod以 grpc-echo 示例为例【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio本篇指南围绕 Istio 仓库中的官方示例 samples/grpc-echo 展开介绍其核心能力Proxyless无 Sidecar 代理数据面gRPC 支持。它通过一种名为grpc-agent的特殊注入模板向 Pod 注入istio-proxySidecar——但该容器内只运行pilot-agent完全不启动 Envoy改由 gRPC 客户端自身的 xDS 能力直接与 istiod 通信。读完本文你将掌握grpc-agent注入模板的工作原理、echo 示例的完整部署资源结构以及 gRPC 应用接入 Istio 服务网格所需的引导bootstrap、证书与代理容器app container改造方式并能直接对照仓库源码理解其底层实现。一、什么是 Proxyless gRPC示例文档的定位grpc-echo示例的官方说明非常精炼它指出了两个关键事实该示例用于演示Istio 的 Proxyless gRPC 支持其实现依赖一个特殊的注入模板grpc-agent——模板照常注入istio-proxySidecar但该 Sidecar只会运行pilot-agent而不会运行 Envoy。之所以称为 Proxyless是因为传统服务网格中数据面的流量劫持与转发由 Envoy 完成而在 Proxyless 模式下数据面职能下沉到 gRPC 库本身——现代 gRPC 客户端原生支持基于 xDS 协议的服务发现、负载均衡、超时与集群管理不再需要业务进程旁路的 Envoy 参与数据转发。关于 gRPC 对 xDS 各项特性的支持矩阵官方文档指向 gRPC 上游的doc/grpc_xds_features.md特征状态说明读者在评估功能可行性时应参考该能力清单。从代码结构看这也印证了仓库对这类工作负载的专门支持pkg/test/framework/components/echo/kube/testdata/proxyless.yaml 与proxyless-custom-image.yaml等测试数据的存在说明 Proxyless 已成为集成测试框架中 echo 组件的标准部署形态之一。二、grpc-agent注入模板注入 Sidecar 但不运行 Envoy2.1 模板从哪来、如何被使用grpc-agent并不是硬编码在代码里的逻辑而是一段sidecar 注入模板由 istiod 的注入配置通过 ConfigMap 提供。模板文件本体位于manifests/charts/istio-control/istio-discovery/files/grpc-agent.yamlHelm chart 内嵌的模板源istiod-injector-configmap.yaml将模板打包进注入器 ConfigMap 的grpc-agentkey用户侧只需在 Deployment 的 Pod template 上声明式选用该模板annotations: inject.istio.io/templates: grpc-agent仓库中samples/grpc-echo/grpc-echo.yaml的 echo-v1/echo-v2 两个 Deployment 正是这样声明的。同时注入器单元测试数据 pkg/kube/inject/testdata/inject/grpc-agent.yaml 及其grpc-agent.yaml.injected产物也用于校验模板渲染结果的一致性。2.2 模板的核心机制DISABLE_ENVOYtrue对比普通 Sidecar 注入模板grpc-agent的关键差异在于给istio-proxy容器注入了以下环境变量见 grpc-agent.yaml# grpc 使用 xds:/// 解析无需解析 ClusterIP因此关闭 DNS 捕获 - name: ISTIO_META_DNS_CAPTURE value: false - name: DISABLE_ENVOY value: trueDISABLE_ENVOYtruepilot-agent启动后不再拉起 Envoy 子进程仅作为代理进程存在负责后续的 SDS 证书签发与 xDS 网关职责。ISTIO_META_DNS_CAPTUREfalseProxyless 的 gRPC 通过xds:///目标名解析上游无需像 Envoy 那样捕获 DNS 来重写虚拟 IP。istio-proxy容器的启动参数则照常使用pilot-agent proxy sidecarargs 中的proxy sidecar --domain ... --proxyLogLevel ...因此容器镜像仍是proxyv2只是 Envoy 未被拉起。这也是为什么 README 表述为Sidecar 只会运行 pilot-agent 而不是 envoy。2.3 代理与业务容器之间的通道UDS 证书目录模板在 Pod 中建立了三块关键共享存储对应渲染结果 grpc-agent.yaml.injected 中的 volume 定义卷挂载类型挂载点作用workload-certsemptyDir/var/run/secrets/workload-spiffe-credentials存放 pilot-agent 通过 SDS 签发的 SPIFFE 身份证书供 gRPC mTLS 使用workload-socketemptyDir/var/run/secrets/workload-spiffe-udsUDS 证书通道istio-xdsemptyDirMemory/etc/istio/proxypilot-agent 与 gRPC 客户端之间的 UDS 通道用于 XDS/SDS模板源码中的注释直接写明了这一设计意图grpc-agent.yaml# UDS channel between istioagent and gRPC client for XDS/SDS - mountPath: /etc/istio/proxy name: istio-xds也就是说pilot-agent 通过本地 Unix Domain Socket 向同 Pod 的 gRPC 应用提供 xDS 配置下发与 SDS 证书服务gRPC 应用侧则依赖模板自动注入的两个环境变量来对接见模板对业务容器的改写逻辑env: - name: GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORT value: true - name: GRPC_XDS_BOOTSTRAP value: /etc/istio/proxy/grpc-bootstrap.jsonGRPC_XDS_BOOTSTRAP指向/etc/istio/proxy/grpc-bootstrap.json——该文件由 pilot-agent 生成声明 xDS 服务器地址通过istio-xdsUDS与节点身份等GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORTtrue让 gRPC 启用基于 SDS 的证书换取能力从而获得与 Envoy 一致的 mTLS 通信同时模板还会把istio-data/var/lib/istio/dataagent 输出证书的目录挂载进业务容器OUTPUT_CERTS/var/lib/istio/data正是 pilot-agent 落盘证书的位置见渲染结果中的OUTPUT_CERTS环境变量。此外模板将ISTIO_META_GENERATORgrpc注入 istio-proxyistiod 据此可识别该工作负载是 Proxyless gRPC 类型从而按 gRPC 生成器逻辑下发 xDS 资源。模板还保留了标准的 readiness 探针/healthz/ready位于 15020 端口由 pilot-agent 提供健康检查端点确保 Pod 在 agent 就绪前不会被纳入流量。2.4 与grpc-simple模板的区别若希望对比仓库中还存在另一种更轻的 Proxyless 模板 grpc-simple.yaml它完全不注入istio-proxy容器而是通过一个busyboxinitContainer 手写 bootstrap 文件xds_servers直接指向dns:///istiod.ns.svc:15010并要求业务进程自行处理证书。而grpc-agent方案保留了 pilot-agent从而复用 istiod 的证书签发与 xDS 代理通道业务容器无需感知 istiod 地址与 CA 细节是更接近完整网格体验的 Proxyless 形态。三、示例部署资源详解echo Service 与 v1/v2 双 Deploymentgrpc-echo示例的完整清单为 samples/grpc-echo/grpc-echo.yaml包含一个echo服务和 v1/v2 两个版本的 Deployment目标命名空间均为echo-grpc使用前需自行创建该 namespace。3.1 Service一个工作负载暴露多协议端口apiVersion: v1 kind: Service metadata: name: echo namespace: echo-grpc spec: selector: app: echo type: ClusterIP ports: - name: http port: 80 targetPort: 18080 - name: grpc port: 7070 targetPort: 17070 - name: tcp port: 9090 targetPort: 19090该 Service 将后端的 echo 应用同时以 HTTP80→18080、gRPC7070→17070与裸 TCP9090→19090三种协议暴露给集群方便在验证 Proxyless gRPC 的同时用 HTTP/TCP 流量做对照实验。3.2 Deployment两个版本 grpc-agent注入echo-v1 与 echo-v2 结构几乎一致仅在--version v1/v2参数与--xds-grpc-server17070等细项上区分。二者都在 Pod template 上声明annotations: inject.istio.io/templates: grpc-agent proxy.istio.io/config: {holdApplicationUntilProxyStarts: true}第二个注解holdApplicationUntilProxyStarts: true保证业务容器在 pilot-agentistio-proxy完成启动并写好 bootstrap 文件之前不会先启动避免 gRPC 客户端初始化时读不到/etc/istio/proxy/grpc-bootstrap.json或连接不上 UDS——这是 Proxyless 部署中非常关键的启动顺序控制。业务容器app镜像registry.istio.io/testing/app:latest通过命令行参数开启多协议监听与 xDS 端点参数含义从示例参数组合推断--port 18080HTTP 服务端口对应 Service 的 http 80--port 8080/--port 3333附加端口其中 3333 同时作为tcp-health-port供探针使用--grpc 17070gRPC 服务端口对应 Service 的 grpc 7070同时配合--xds-grpc-server17070表示该端口通过 xDS 下发--grpc 17171第二个 gRPC 监听端口示例用于验证 xDS 对多端口/动态端口的配置下发--tcp 19090TCP 端口对应 Service 的 tcp 9090--metrics15014指标暴露端口--crt/cert.crt/--key/cert.keymTLS 证书与密钥路径--version v1/v2实例版本标识容器声明了17070、17171、8080、3333四个 containerPort3333名为tcp-health-port并配置了完善的健康检查startupProbe 与 livenessProbe 均以 TCP 连接tcp-health-port判定readinessProbe 通过 HTTP GET/8080 端口判定同时INSTANCE_IP通过 downwardAPI 注入 Pod IP 供应用上报自身地址。四、结合仓库验证注入效果与集成测试4.1 从注入产物看最终 Pod 形态查看测试数据 pkg/kube/inject/testdata/inject/grpc-agent.yaml.injected可以看到grpc-agent模板渲染后的典型 Pod 结构业务容器如traffic被自动追加GRPC_XDS_EXPERIMENTAL_SECURITY_SUPPORTtrue与GRPC_XDS_BOOTSTRAP/etc/istio/proxy/grpc-bootstrap.json环境变量并挂载istio-xds、workload-certs、istio-data卷istio-proxy 容器DISABLE_ENVOYtrue无 Envoy 数据面仅由 pilot-agent 提供 15020 健康端口与istio-proxy wait的 postStart 逻辑注入器在sidecar.istio.io/status注解中登记的容器即为[istio-proxy,traffic]istio.io/rev: default表示使用 default 版本注入。4.2 pilot-agent 侧的支撑实现从源码角度看grpc-bootstrap.json的生成逻辑位于 pilot-agent 的启动选项中pilot/cmd/pilot-agent/options/options.go与grpc-bootstrap关键词匹配其职责是把 xDS 服务器地址收敛为本地 UDS 端点并输出给同 Pod 的 gRPC 库使用而 istiod 侧的pilot/pkg/networking/grpcgen则是为这类工作负载生成 gRPC 专属 xDS 配置的生成器参见其测试 grpcgen_test.go其中包含对grpc-bootstrap相关配置的断言从源码结构可以推断pilot 已为ISTIO_META_GENERATORgrpc的工作负载走独立的 grpcgen 配置生成链路。4.3 端到端验证方式仓库的 Proxyless 场景已在集成测试框架中固化pkg/test/framework/components/echo/kube/testdata/proxyless.yaml与proxyless-custom-image.yaml展示了用 echo 组件一键部署 Proxyless 工作负载的测试模板pkg/test/framework/components/echo/common/deployment/echos.go中的公共部署逻辑会根据配置选择注入grpc-agent。因此想要亲自复现本示例的读者可以直接基于samples/grpc-echo/grpc-echo.yaml在已安装 Istio含 istiod 注入器与grpc-agent模板的集群中创建echo-grpc命名空间并应用清单随后使用任意 gRPC 客户端以xds:///echo/grpc示例中 xDS 服务名为 Service DNSecho端口为 gRPC 端口发起调用即可观察 gRPC 库通过 pilot-agent 从 istiod 拉取端点并完成负载均衡与 mTLS。五、实战注意事项与限制前置条件grpc-agent模板随 istiod 注入器 ConfigMap 一起发布要求网格内的注入器版本与模板匹配Helm 渲染的 istiod-injector-configmap.yaml 默认已内置grpc-agent且业务代码需使用支持 xDS 的 gRPC 版本部分能力仍属实验特性需设置 gRPC 侧实验开关详见 gRPC 上游的 xDS 特性状态文档。探针重写需关闭模板会强制写入sidecar.istio.io/rewriteAppHTTPProbers: false因为无 Envoy 时探针无法被代理改写应用必须自行对外暴露 HTTP/TCP 探针端点。启动顺序务必像示例那样设置holdApplicationUntilProxyStarts: true确保 gRPC 库启动前 bootstrap 与 UDS 已就绪同时istio-proxy的 readiness 探针15020/healthz/ready能反映 agent 就绪状态。能力边界Proxyless 模式只覆盖 gRPC 库已实现的 xDS 特性如集群发现、负载均衡、超时、mTLS对于 HTTP/TCP 等其他协议的治理仍需传统 Envoy Sidecar本示例中的 HTTP 与 TCP 端口更多用于对照与探针场景真正被网格化的是 17070/17171 这两个 gRPC 端口。标签与身份模板注释grpc-agent.yaml提醒若 gRPC 使用 mTLS 初始化代码security.istio.io/tlsMode: istio标签必须由用户在 workload 上自行设置模板不会自动添加。六、小结与延伸阅读grpc-echo虽然只是一个示例但它清晰地演示了 Istio Proxyless gRPC 的完整落地路径一条注入注解grpc-agent 一份由 pilot-agent 生成的 bootstrap gRPC 库原生 xDS 客户端即可在不引入 Envoy 数据面的前提下让 gRPC 服务融入服务网格获得证书签发SDS、服务发现与负载均衡等能力。对于想要深入探究的读者仓库内可按以下顺序继续阅读模板实现manifests/charts/istio-control/istio-discovery/files/grpc-agent.yaml 与对照版本 grpc-simple.yaml注入渲染产物pkg/kube/inject/testdata/inject/grpc-agent.yaml.injected测试部署形态pkg/test/framework/components/echo/kube/testdata/proxyless.yaml配置生成实现pilot/pkg/networking/grpcgen及其 测试本示例清单samples/grpc-echo/grpc-echo.yaml【免费下载链接】istioConnect, secure, control, and observe services.项目地址: https://gitcode.com/GitHub_Trending/is/istio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考