使用自动 Envoy 注入设置 Google Kubernetes Engine Pod

概览

在服务网格中，您的应用代码不需要了解网络配置。相反，您的应用通过数据平面进行通信，该数据平面由处理服务网络的控制平面进行配置。在本指南中，Traffic Director 是您的控制平面，而 Envoy Sidecar 代理是您的数据平面。

Envoy Sidecar 注入器可轻松将 Envoy Sidecar 代理添加到您的 Google Kubernetes Engine Pod 中。在 Envoy Sidecar 注入器添加代理时，它还会设置该代理以处理应用流量并连接到 Traffic Director 以进行配置。

本指南将逐步介绍 Google Kubernetes Engine 的 Traffic Director 设置。这些步骤为扩展到高级使用场景奠定了基础，例如扩展到多个 Google Kubernetes Engine 集群以及 Compute Engine 虚拟机的服务网格。如果您使用共享 VPC 配置 Traffic Director，也可以使用这些说明。

设置过程包括：

为您的工作负载创建 GKE 集群。
安装 Envoy Sidecar 注入器并启用注入。
部署样本客户端并验证注入。
部署 Kubernetes 服务以进行测试。
使用 Cloud Load Balancing 组件配置 Traffic Director，以将流量路由到测试服务。
从示例客户端向测试服务发送请求以验证配置。

前提条件

在按照本指南中的说明进行操作之前，请先查看设置 Traffic Director 前的准备工作，并确保您已完成该文档中所述的前提任务。

如需了解受支持的 Envoy 版本，请参阅 Traffic Director 版本说明。

使用共享 VPC 的其他前提条件

如果要在共享 VPC 环境中设置 Traffic Director，请确保以下事项。

您对共享 VPC 拥有正确的权限和角色。
您已设置正确的项目和账单。
您已在项目中启用结算功能。
您已在每个项目（包括宿主项目）中启用了 Traffic Director 和 GKE API。
您已为每个项目设置了正确的服务账号。
您已创建 VPC 网络和子网。
您已启用共享 VPC。

如需了解详情，请参阅共享 VPC。

配置 IAM 角色

此 IAM 角色配置示例假定共享 VPC 的宿主项目有两个子网，并且共享 VPC 中有两个服务项目。

在 Cloud Shell 中，创建一个工作文件夹 (WORKDIR))，您可以在其中创建与本部分关联的文件：
```
mkdir -p ~/td-shared-vpc
cd ~/td-shared-vpc
export WORKDIR=$(pwd)
```

在宿主项目中配置 IAM 权限，以便服务项目可以使用共享 VPC 中的资源。

在此步骤中，您将配置 IAM 权限，使服务项目 1 可以访问 subnet-1，服务项目 2 可以访问 subnet-2。您将 Compute Network User IAM 角色 (roles/compute.networkUser) 分配给每个子网的各服务项目中的 Compute Engine 计算默认服务账号和 Google Cloud API 服务账号。

对于服务项目 1，为 subnet-1 配置 IAM 权限：

export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')

cat > subnet-1-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_1_API_SA}
  - serviceAccount:${SVC_PROJECT_1_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_1_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-1 \
subnet-1-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_1}

对于服务项目 2，为 subnet-2 配置 IAM 权限：

export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')

cat > subnet-2-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_2_API_SA}
  - serviceAccount:${SVC_PROJECT_2_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_2_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-2 \
subnet-2-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_2}

对于每个服务项目，您必须将 Kubernetes Engine Host Service Agent User IAM 角色 (roles/container.hostServiceAgentUser) 授予宿主项目中的 GKE 服务账号：

gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
    --role roles/container.hostServiceAgentUser

gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
    --role roles/container.hostServiceAgentUser

此角色允许服务项目的 GKE 服务账号使用宿主项目的 GKE 服务账号来配置共享网络资源。

对于每个服务项目，向 Compute Engine 默认服务账号授予宿主项目中的 Compute Network Viewer IAM 角色 (roles/compute.networkViewer)。
```
gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
    --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
    --role roles/compute.networkViewer

gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
    --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
    --role roles/compute.networkViewer
```
Envoy 边车代理连接到 xDS 服务 (Traffic Director API) 后，该代理将使用 Compute Engine 虚拟机主机或 GKE 节点实例的服务账号。该服务账号必须具有 compute.globalForwardingRules.get 项目级层 IAM 权限。使用 Compute Network Viewer 角色足以完成此步骤。

为您的工作负载创建 GKE 集群

GKE 集群必须满足以下要求才能支持 Traffic Director：

必须启用网络端点组支持。如需了解详情和示例，请参阅独立网络端点组。
您的 GKE 节点/pod的服务账号必须具有访问 Traffic Director API 的权限。如需详细了解所需权限，请参阅启用服务账号以访问 Traffic Director API。

创建 GKE 集群

在您的首选可用区（例如 us-central1-a）中创建一个名为 traffic-director-cluster 的 GKE 集群。

gcloud container clusters create traffic-director-cluster \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

将 kubectl 指向新创建的集群

发出以下命令，将 kubectl 的当前上下文更改为新创建的集群：

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

安装 Envoy Sidecar 注入器

以下部分提供了安装 Envoy Sidecar 注入器的说明。启用 Sidecar 注入器后，它将自动为新的和现有的 Google Kubernetes Engine 工作负载部署 Sidecar 代理。因为 Envoy Sidecar 注入器在 GKE 集群内运行，所以如果要使用 Traffic Director 支持多集群服务网格，则需要将其安装到每个集群一次。

下载 Sidecar 注入器

下载并解压缩 Envoy Sidecar 注入器。

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

配置 Sidecar 注入器

如果您是使用旧版 API，又想配置 Sidecar 注入器，请执行以下操作来修改 specs/01-configmap.yaml 文件：

将 YOUR_PROJECT_NUMBER_HERE 替换为项目编号以填充TRAFFICDIRECTOR_GCP_PROJECT_NUMBER。项目编号是您的项目的数字标识符。如需了解如何获取所有项目列表，请参阅识别项目。
将 TRAFFICDIRECTOR_NETWORK_NAME 替换为要用于 Traffic Director 的 Google Cloud Virtual Private Cloud 网络名称以填充 YOUR_NETWORK_NAME_HERE。记下此 VPC 网络名称，因为稍后配置 Traffic Director 时将会用到。

如果您是使用当前处于预览状态的新服务路由 API，请执行以下操作：

通过将 "" 替换为服务网格的名称来填充 TRAFFICDIRECTOR_MESH_NAME，以获取服务网格的配置。
- 请注意，如果您正在配置 Gateway，则不会用到边车注入器。将 Envoy 代理部署为 Pod。

例如，该文件可能如下所示：

$ cat specs/01-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
name: injector-mesh
namespace: istio-control
data:
mesh: |-
defaultConfig:
discoveryAddress: trafficdirector.googleapis.com:443

# Envoy proxy port to listen on for the admin interface.
proxyAdminPort: 15000

proxyMetadata:
# Google Cloud Project number where Traffic Director resources are configured.
# This is a numeric identifier of your project (e.g. "111222333444").
# You can get a list of all your projects with their corresponding numbers by
# using "gcloud projects list" command or looking it up under "Project info"
# section of your Google Cloud console.
# If left empty, configuration will be attempted to be fetched for the Google Cloud
# project associated with service credentials.
# Leaving empty is not recommended as it is not guaranteed to work in future
# releases.
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER: "YOUR_PROJECT_NUMBER_HERE"

# Google Cloud VPC network name for which the configuration is requested (This is the VPC
# network name referenced in the forwarding rule in Google Cloud API). If left empty,
# configuration will be attempted to be fetched for the VPC network over which
# the request to Traffic Director (trafficdirector.googleapis.com) is sent out.
# Leaving empty is not recommended as it is not guaranteed to work in future
# releases.
TRAFFICDIRECTOR_NETWORK_NAME: "default"

您还可以选择为每个自动注入的代理启用日志记录和跟踪。如需详细了解这些配置，请参阅为 Sidecar 代理配置其他属性。使用 Sidecar 注入器时，TRAFFICDIRECTOR_ACCESS_LOG_PATH 的值只能设置为 /etc/envoy/ 目录中的文件。例如，目录 /etc/envoy/access.log 是有效位置。

请注意，TRAFFICDIRECTOR_INTERCEPTION_PORT 不应在此 ConfigMap 中配置，因为 Sidecar 注入器已对其进行配置。

为 Sidecar 注入器配置传输层安全协议 (TLS)

本部分介绍如何为 Sidecar 注入器配置传输层安全协议 (TLS)。

Sidecar 注入器使用 Kubernetes 更改准入网络钩子在创建新 pod时注入代理。此网络钩子是一个 HTTPS 端点，因此您需要提供密钥和传输层安全协议 (TLS) 证书。

您可以使用 openssl 创建私钥和自签名证书以保护 Sidecar 注入器。

如果您有私钥和由可信证书授权机构 (CA) 签名的证书，则可以跳过这一步。

CN=istio-sidecar-injector.istio-control.svc

openssl req \
  -x509 \
  -newkey rsa:4096 \
  -keyout key.pem \
  -out cert.pem \
  -days 365 \
  -nodes \
  -subj "/CN=${CN}" \
  -addext "subjectAltName=DNS:${CN}"

cp cert.pem ca-cert.pem

此示例 openssl 命令会向 key.pem 输出一个 4096 位 RSA 私钥，并向 cert.pem 输出一个 X.509 格式的自签名证书。因为证书是自签名的，所以证书被复制到 ca-cert.pem，并且被视为由 CA 签名的证书。证书在 365 天内有效，无需密码。如需详细了解如何创建证书和签名，请参阅有关证书签名请求的 Kubernetes 文档。

必须每年重复执行本部分中的步骤，以在密钥和证书过期之前重新生成并应用。

获取密钥和证书后，您必须创建一个 Kubernetes Secret 并更新 Sidecar 注入器的网络钩子。

创建要在其下创建 Kubernetes Secret 的命名空间：
```
kubectl apply -f specs/00-namespaces.yaml
```

为 Sidecar 注入器创建 Secret。

kubectl create secret generic istio-sidecar-injector -n istio-control \
  --from-file=key.pem \
  --from-file=cert.pem \
  --from-file=ca-cert.pem

修改 specs/02-injector.yaml 中名为 istio-sidecar-injector-istio-control 的 Sidecar 注入网络钩子的caBundle：

CA_BUNDLE=$(cat cert.pem | base64 | tr -d '\n')
sed -i "s/caBundle:.*/caBundle:\ ${CA_BUNDLE}/g" specs/02-injector.yaml

将 Sidecar 注入器安装到 GKE 集群

部署Sidecar 注入器。
```
kubectl apply -f specs/
```

验证Sidecar 注入器正在运行。

kubectl get pods -A | grep sidecar-injector

这将返回如下所示的输出：

istio-control   istio-sidecar-injector-6b475bfdf9-79965  1/1 Running   0   11s
istio-control   istio-sidecar-injector-6b475bfdf9-vntjd  1/1 Running   0   11s

打开专用集群上的必要端口

如果您遵循使用 Envoy 设置 Traffic Director 服务安全中的说明，则可以跳过此部分并转到下一部分，启用 Sidecar 注入。

如果您在专用集群上安装 Envoy Sidecar 注入器，则需要将防火墙规则中的 TCP 端口 9443 添加到主节点，以便 webhook 正常工作。

以下步骤介绍了如何更新必要的防火墙规则。请注意，update 命令会替换现有防火墙规则，因此您需要确保默认端口 443 (HTTPS) 和 10250 (kubelet) 以及要打开的新端口。

找到集群的来源范围 (master-ipv4-cidr)。在以下命令中，将 CLUSTER_NAME 替换为您的集群名称，即 traffic-director-cluster：
```
FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
 --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
 --format="value(name)")
```

更新防火墙规则以打开 TCP 端口 9443，以启用自动注入功能：

gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
 --allow tcp:10250,tcp:443,tcp:9443

启用 Sidecar 注入

以下命令为 default 命名空间启用注入。Sidecar 注入器会将 Sidecar容器注入在此命名空间下创建的 pod：

kubectl label namespace default istio-injection=enabled

您可以运行以下命令来验证 default 命名空间已正确启用：

kubectl get namespace -L istio-injection

此时应返回：

NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   7d16h   enabled
istio-control     Active   7d15h
istio-system      Active   7d15h

如果要使用 Envoy 为 Traffic Director 配置服务安全性，请返回该设置指南中的设置测试服务部分。

部署示例客户端并验证注入

本部分介绍如何部署运行 Busybox 的示例 pod，它提供了一个简单的接口，可连接测试服务。在实际部署中，您应改为部署自己的客户端应用。

kubectl create -f demo/client_sample.yaml

Busybox pod 由两个容器组成。第一个容器是基于 Busybox 映像的客户端，第二个容器是由 Sidecar 注入器注入的 Envoy 代理。您可以运行以下命令来获取有关该 pod 的更多信息：

kubectl describe pods -l run=client

此时应返回：

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

部署 Kubernetes 服务以进行测试

下文将介绍如何设置测试服务，您将在本指南的后面部分使用该测试服务提供设置的端到端验证。

使用 NEG 配置 GKE 服务

GKE 服务必须通过网络端点组 (NEG) 公开，以便您可以将它们配置为 Traffic Director 后端服务的后端。将 NEG 注解添加到 Kubernetes 服务规范并选择一个名称（替换以下示例中的 NEG-NAME），以便于日后查找。当您将 NEG 附加到 Traffic Director 后端服务时，将需要该名称。如需详细了解如何为 NEG 添加注释，请参阅为 NEG 命名。

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

此注解创建一个独立的 NEG，其中包含与服务 pod 的 IP 地址和端口相对应的端点。如需了解详情和示例，请参阅独立网络端点组。

以下示例服务包括 NEG 注解。该服务在端口 80 上通过 HTTP 提供主机名。使用以下命令获取该服务并将其部署到 GKE 集群。

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

验证新服务是否已创建，以及应用 pod 是否正在运行：

kubectl get svc

输出应类似如下所示：

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

验证与此服务关联的应用 pod 是否正在运行：

kubectl get pods

此操作会返回：

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

保存 NEG 的名称

找到在上述示例中创建的 NEG 并记下其名称，以用于下一部分的 Traffic Director 配置。

gcloud compute network-endpoint-groups list

此示例会返回以下内容：

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

将 NEG 的名称保存在 NEG_NAME 变量中：

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

使用 Cloud Load Balancing 组件配置 Traffic Director

本部分使用 Compute Engine 负载平衡资源配置 Traffic Director。这样一来，示例客户端的边车代理即可接收来自 Traffic Director 的配置。来自示例客户端的出站请求由边车代理处理并路由到测试服务。

您必须配置以下组件：

健康检查。如需详细了解健康检查，请参阅健康检查概念和创建健康检查。
后端服务。如需详细了解后端服务，请参阅后端服务。
路由规则映射。这包括创建转发规则、目标 HTTP 代理和网址映射。如需了解详情，请参阅使用 Traffic Director 的转发规则、使用 Traffic Director 的目标代理和使用网址映射。

创建健康检查和防火墙规则

请按照以下说明创建健康检查以及健康检查探测所需的防火墙规则。如需了解详情，请参阅健康检查的防火墙规则。

控制台

转到 Google Cloud 控制台中的“健康检查”页面。
转到“健康检查”页面
点击创建健康检查。
对于名称，请输入 td-gke-health-check。
对于协议，请选择 HTTP。
点击创建。
进入 Google Cloud 控制台中的防火墙政策页面。
进入“防火墙政策”页面
点击创建防火墙规则。
在“创建防火墙规则”页面上，提供如下信息：
- 名称：提供规则的名称。本示例使用的是 fw-allow-health-checks。
- 网络：选择一个 VPC 网络。
- 优先级：输入一个表示优先级的数字。这个数字越小，优先级就越高。请确保防火墙规则的优先级高于可能会拒绝入站流量的其他规则的优先级。
- 流量方向：选择入站。
- 对匹配项执行的操作：选择允许。
- 目标：选择网络中的所有实例。
- 来源过滤条件：选择正确的 IP 范围类型。
- 来源 IP 地址范围：35.191.0.0/16,130.211.0.0/22
- 目标过滤条件：选择 IP 类型。
- 协议和端口：点击指定的端口和协议，然后选中 tcp。TCP 是所有健康检查协议的底层协议。
- 点击创建。

gcloud

创建健康检查。

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

创建防火墙规则以允许健康检查器 IP 地址范围。

gcloud compute firewall-rules create fw-allow-health-checks \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --rules tcp

创建后端服务

使用负载均衡方案 INTERNAL_SELF_MANAGED 创建全局后端服务。在 Google Cloud 控制台中，负载均衡方案是隐式设置的。请将健康检查添加到后端服务。

控制台

转到 Google Cloud 控制台中的 Traffic Director 页面。
转到 Traffic Director 页面
在服务标签页上，点击创建服务。
点击继续。
对于服务名称，请输入 td-gke-service。
选择您在 Traffic Director ConfigMap 中配置的网络。
在后端类型下，选择网络端点组。
选择您创建的网络端点组。
将 RPS 上限设置为 5。
将均衡模式设置为速率。
点击完成。
在健康检查下，选择 td-gke-health-check，这是您创建的健康检查。
点击继续。

gcloud

创建后端服务并将健康检查与后端服务相关联。

gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

将之前创建的 NEG 作为后端添加到后端服务。如果您使用目标 TCP 代理配置 Traffic Director，则必须使用 UTILIZATION 均衡模式。如果您使用的是 HTTP 或 HTTPS 目标代理，则可以使用 RATE 模式。
```
gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone ZONE \
 --balancing-mode [RATE | UTILIZATION] \
 --max-rate-per-endpoint 5
```

创建路由规则映射

路由规则映射定义了 Traffic Director 如何路由您的流量。作为路由规则映射的一部分，您可以配置虚拟 IP (VIP) 地址和一组关联的流量管理规则，例如基于主机的路由。当应用向 VIP 发送请求时，附加的 Envoy Sidecar 代理将执行以下操作：

拦截请求。
根据网址映射中的流量管理规则对其进行评估。
根据请求中的主机名选择后端服务。
选择与所选后端服务关联的后端或端点。
将流量发送到该后端或端点。

控制台

在 Console 中，目标代理已与转发规则相结合。创建转发规则时，Google Cloud 会自动创建目标 HTTP 代理并将其附加到网址映射。

路由规则由转发规则以及主机和路径规则（也称为网址映射）组成。

转到 Google Cloud 控制台中的 Traffic Director 页面。
转到 Traffic Director 页面
点击路由规则映射
点击创建路由规则。
输入 td-gke-url-map 作为网址映射的名称。
点击添加转发规则。
对于转发规则名称，请输入 td-gke-forwarding-rule。
选择您的网络。
选择您的内部 IP。
点击保存。
（可选）添加自定义主机和路径规则，或将路径规则保留为默认值。
将主机设置为 service-test。
点击保存。

gcloud

创建将 td-gke-service 用作默认后端服务的网址映射。

gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service

创建网址映射路径匹配器和主机规则，以根据主机名和路径为您的服务路由流量。此示例使用 service-test 作为服务名称，并使用默认路径匹配器来匹配此主机的所有路径请求 (/*)。

gcloud compute url-maps add-path-matcher td-gke-url-map \
   --default-service td-gke-service \
   --path-matcher-name td-gke-path-matcher

gcloud compute url-maps add-host-rule td-gke-url-map \
   --hosts service-test \
   --path-matcher-name td-gke-path-matcher

创建目标 HTTP 代理。

gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

创建转发规则。

gcloud compute forwarding-rules create td-gke-forwarding-rule \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --address=0.0.0.0 \
  --target-http-proxy=td-gke-proxy \
  --ports 80 --network default

此时，Traffic Director 将您的 Sidecar 代理配置为将指定 service-test 主机名的请求路由到 td-gke-service 的后端。在此示例中，这些后端是与您之前部署的 Kubernetes 测试服务关联的网络端点组中的端点。

验证配置

本部分介绍如何验证从示例 Busybox 客户端发送的流量是否路由到您的 service-test Kubernetes 服务。如需发送测试请求，您可以在其中一个容器上访问 shell并执行以下验证命令。service-test pod 应返回服务 pod 的主机名。

# Get the name of the pod running Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

验证配置的方法如下：

示例客户端发送一个指定service-test主机名的请求。
示例客户端具有由 Envoy Sidecar 注入器注入的 Envoy 边车代理。
边车代理拦截该请求。
Envoy 使用网址映射匹配 service-test 主机名与 td-gke-service Traffic Director 服务。
Envoy 从与 td-gke-service 关联的网络端点组中选择一个端点。
Envoy 将请求发送到与 service-test Kubernetes 服务关联的 pod。

后续步骤

了解高级流量管理
了解 Traffic Director 服务安全。
了解如何使用 Envoy 设置可观测性。
了解如何排查 Traffic Director 部署的问题。
了解为 Google Kubernetes Engine Pod 进行自动 Envoy 注入的设置选项。