Anthos Service Mesh 和 Traffic Director 现已更名为 Cloud Service Mesh。如需了解详情，请参阅 Cloud Service Mesh 概览。

此页面由 Cloud Translation API 翻译。

引入 Kubernetes 工作负载

本页面介绍了如何通过 Google Cloud 控制台 Cloud Service Mesh。

部署 Kubernetes 服务

如需将 Kubernetes 服务部署到具有 Cloud Service Mesh 的集群，您必须执行以下操作：

为所有容器创建 Kubernetes Service。全部部署应该有一个 Kubernetes 服务
为您的 Service 端口命名。虽然 GKE 允许您定义未命名的服务端口，但 Cloud Service Mesh 要求您提供端口名称（与端口的协议匹配）。
为部署添加标签。这样，您就可以使用 Cloud Service Mesh 流量，一些管理功能，例如在同一网站的多个不同版本之间拆分流量，服务。

以下示例部署和服务说明了这些要求：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer

在具有 Cloud Service Mesh 的集群上部署服务后，请务必注入 Sidecar 代理。

示例：部署 Online Boutique 示例

anthos-service-mesh-packages 代码库中的 Online Boutique 示例应用在 microservices-demo 代码库中原始清单集的基础上进行了修改。按照最佳实践，每项服务都部署在单独的具有唯一服务账号的命名空间

为应用创建命名空间：

kubectl apply -f \
  DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces

预期输出：

namespace/ad created
namespace/cart created
namespace/checkout created
namespace/currency created
namespace/email created
namespace/frontend created
namespace/loadgenerator created
namespace/payment created
namespace/product-catalog created
namespace/recommendation created
namespace/shipping created

启用命名空间以进行注入。具体步骤取决于您的控制平面实现。

受管理 (TD)

将默认注入标签应用于命名空间：

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio.io/rev- istio-injection=enabled --overwrite
done;

代管式 (Istiod)

推荐：运行以下命令可将默认注入标签应用于命名空间：

  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;

如果您是使用 Managed Istiod 控制平面的现有用户：我们建议您使用默认注入，但基于修订版本的注入支持。请按照以下说明操作：

运行以下命令查找可用的发布渠道：
```
kubectl -n istio-system get controlplanerevision
```
输出类似于以下内容：
```
NAME                AGE
asm-managed-rapid   6d7h
```
注意：如果上方列表中显示了两个控制平面修订版本，请移除其中一个。不支持在集群中使用多个控制平面渠道。

在输出中，NAME 列的值是与 Cloud Service Mesh 版本可用的发布版本对应的修订版本标签。

将修订版本标签应用于命名空间：

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio-injection- istio.io/rev=REVISION_LABEL --overwrite
done;

集群内

推荐：运行以下命令可将默认注入标签应用于命名空间：

  for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
    kubectl label namespace $ns \
        istio.io/rev- istio-injection=enabled --overwrite
  done;

我们建议您使用默认注入，但支持基于修订版本的注入：请按照以下说明操作：

使用以下命令查找 istiod 的修订版本标签：

kubectl get deploy -n istio-system -l app=istiod -o \
   jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

将修订版本标签应用于命名空间。在以下命令中，REVISION_LABEL 是您在上一步中记下的 istiod 修订版本标签的值。

for ns in ad cart checkout currency email frontend loadgenerator payment product-catalog recommendation shipping; do
  kubectl label namespace $ns \
      istio-injection- istio.io/rev=REVISION_LABEL --overwrite
done;

将示例应用部署到集群。

创建服务账号和部署：

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments

预期输出：

serviceaccount/ad created
deployment.apps/adservice created
serviceaccount/cart created
deployment.apps/cartservice created
serviceaccount/checkout created
deployment.apps/checkoutservice created
serviceaccount/currency created
deployment.apps/currencyservice created
serviceaccount/email created
deployment.apps/emailservice created
serviceaccount/frontend created
deployment.apps/frontend created
serviceaccount/loadgenerator created
deployment.apps/loadgenerator created
serviceaccount/payment created
deployment.apps/paymentservice created
serviceaccount/product-catalog created
deployment.apps/productcatalogservice created
serviceaccount/recommendation created
deployment.apps/recommendationservice created
serviceaccount/shipping created
deployment.apps/shippingservice created

创建服务：

kubectl apply -f \
 DIR_PATH/samples/online-boutique/kubernetes-manifests/services

预期输出：

service/adservice created
service/cartservice created
service/checkoutservice created
service/currencyservice created
service/emailservice created
service/frontend created
service/frontend-external created
service/paymentservice created
service/productcatalogservice created
service/recommendationservice created
service/shippingservice created

创建服务条目：

kubectl apply -f \
 DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml

预期输出：

serviceentry.networking.istio.io/allow-egress-googleapis created
serviceentry.networking.istio.io/allow-egress-google-metadata created

为服务端口命名

如要纳入 Cloud Service Mesh，必须为服务端口命名，并且名称必须加入端口的协议，例如：

apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080
    name: http

服务端口名称可以包含以下语法的后缀：name: protocol[-suffix]，其中方括号表示必须以短划线开头的可选后缀，例如：

kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80
    name: http-web

如需在 Google Cloud 控制台中显示指标，必须使用以下协议之一为服务端口命名：http、http2 或 grpc。使用 https 协议命名的服务端口被视为 tcp，因此对于这些服务，系统不会显示指标。

注入 Sidecar 代理

本部分介绍如何使用 Cloud Service Mesh 配置 Sidecar 代理注入，以增强网络安全性、可靠性和可观测性。这些函数是从应用的主要容器，并在常见的进程外代理（辅助信息文件）中实现；作为同一 Pod 中的单独容器提供您可以使用 Cloud Service Mesh 的功能，无需重新设计让您的生产应用参与服务网格。

以下情况会导致自动边车代理注入（自动注入） Cloud Service Mesh 会检测您为工作负载的 Pod。代理会拦截工作负载的所有入站和出站流量，与 Cloud Service Mesh 进行通信。

执行这些任务所需的权限

为执行本页面中的任务，您必须拥有 roles/container.clusterAdmin 或更高的角色。如需详细了解此角色包含的权限，请参阅 Google Kubernetes Engine 角色。

启用自动 Sidecar 注入

启用用于注入的命名空间。具体步骤取决于您的控制平面实现。
受管 (TD)
1. 将默认注入标签应用于命名空间：
```
kubectl label namespace NAMESPACE
    istio.io/rev- istio-injection=enabled --overwrite
```
代管式 (Istiod)
推荐：运行以下命令可将默认注入标签应用于命名空间：
```
  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite
```
如果您是使用 Managed Istiod 控制平面的现有用户：我们建议您使用默认注入，但基于修订版本的注入支持。请按照以下说明操作：
1. 运行以下命令查找可用的发布渠道：
  kubectl -n istio-system get controlplanerevision
  输出类似于以下内容：
  NAME AGE asm-managed-rapid 6d7h
  注意：如果上述列表中显示了两个控制平面修订版本，请移除一个。不支持在集群中使用多个控制平面渠道。
  
  在输出中，NAME 列的值是与 Cloud Service Mesh 版本可用的发布版本对应的修订版本标签。
2. 将修订版本标签应用于命名空间：
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
集群内
推荐：运行以下命令可将默认注入标签应用于命名空间：
```
  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite
```
我们建议您使用默认注入，但支持基于修订版本的注入：请按照以下说明操作：
1. 使用以下命令查找 istiod 的修订版本标签：
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. 将修订版本标签应用于命名空间。在以下命令中，REVISION_LABEL 是您在上一步中记下的 istiod 修订版本标签的值。
  kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
按照下一部分中的步骤重启受影响的 pod。

为 demo 命名空间添加注解，如下所示：

kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

重启 pod 以更新 Sidecar 代理

借助自动 Sidecar 注入，您可以通过 pod 重启来更新现有 pod 的 Sidecar：

如何重启 pod 取决于 pod 是否在 Deployment 中创建。

如果您使用了 Deployment，请重启 Deployment，这会重启所有安装了 Sidecar 的 pod：
```
kubectl rollout restart deployment -n NAMESPACE
```
如果您未使用 Deployment，请删除 Pod，系统会自动重新创建 Pod 及其 Sidecar：
```
kubectl delete pod -n NAMESPACE --all
```
检查命名空间中的所有 Pod 是否都已注入 Sidecar：
```
kubectl get pod -n NAMESPACE
```
在上一个命令的以下示例输出中，注意 READY 列表示每个工作负载均有两个容器：主容器和 Sidecar 代理的容器。
```
NAME                    READY   STATUS    RESTARTS   AGE
WORKLOAD           2/2     Running   0          20s
...
```

引入 Kubernetes 工作负载

部署 Kubernetes 服务

示例：部署 Online Boutique 示例

受管理 (TD)

代管式 (Istiod)

集群内

为服务端口命名

注入 Sidecar 代理

执行这些任务所需的权限

启用自动 Sidecar 注入

受管 (TD)

代管式 (Istiod)

集群内

重启 pod 以更新 Sidecar 代理