对 Kubernetes 工作负载进行初始配置

注意 ：本指南仅支持通过 Istio API 部署 Cloud Service Mesh，不支持 Google Cloud API。如需了解详情，请参阅 Cloud Service Mesh 概览。

本页面介绍了如何使用 Cloud Service Mesh 配置 Kubernetes 工作负载。

部署 Kubernetes 服务

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

• 为所有容器创建 Kubernetes Service。所有 Deployment 都应连接 Kubernetes 服务。

• 为服务端口命名。虽然 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 代码库中的原始清单集进行了修改。按照最佳实践，每项服务都部署在具有唯一服务帐号的单独命名空间中。

1. 为应用创建命名空间：

   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
   

2. 启用自动 Sidecar 注入（自动注入）。此命令会有所不同，具体取决于您使用的是托管式 Cloud Service Mesh 还是集群内 Cloud Service Mesh。如果您使用的是代管式 Cloud Service Mesh，请使用默认注入标签（例如 istio-injection=enabled）。如果您使用的是集群内 Cloud Service Mesh，请使用您用于注释入站流量网关命名空间的同一修订版本标签。请注意，已迁移的代管式控制平面客户除了可以使用默认注入标签外，还可以使用现有的修订版本标签。

   默认注入标签

   将默认注入标签应用于命名空间。在以下命令中，GATEWAY_NAMESPACE 与您用于为入站流量网关命名空间添加注释的值相同。

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

   注意 ：您可以忽略任何标签“istio.io/rev”未找到错误。

   预期输出：

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

   修订版本标签

   将修订版本标签应用于应用命名空间。 在以下命令中，REVISION 与您用于为入站流量网关命名空间添加注释的值相同。

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

   预期输出：

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

3. 将示例应用部署到集群。

   1. 创建服务账号和部署：

      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
      

   2. 创建服务：

      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
      

   3. 创建服务条目：

      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，因此对于这些服务，系统不会显示指标。

注入边车代理

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

当 Cloud Service Mesh 检测到您为工作负载的 Pod 配置的命名空间标签时，便会发生自动边车代理注入（自动注入）。该代理会拦截工作负载的所有入站和出站流量，并与 Cloud Service Mesh 通信。

执行这些任务所需的权限

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

启用自动 Sidecar 注入

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

   受管 (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
   

   如果您是使用代管式 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
      

   集群内

   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
      

2. 按照下一部分中的步骤重启受影响的 pod。

3. 按如下方式为 demo 命名空间添加注解：

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

重启 pod 以更新 Sidecar 代理

警告：除非您为蓝绿部署设置负载均衡器或路由器，否则请确保在预演环境中测试重启 pod，以验证您的服务可以处理任何潜在的流量中断。

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

重启 Pod 的方式取决于 Pod 是否在 Deployment 过程中创建。

1. 如果您使用了 Deployment，请重启 Deployment，这会重启所有安装了 Sidecar 的 pod：

   kubectl rollout restart deployment -n NAMESPACE

   如果您未使用 Deployment，请删除 Pod，系统会自动重新创建 Pod 及其 Sidecar：

   kubectl delete pod -n NAMESPACE --all

2. 检查命名空间中的所有 Pod 是否都已注入 Sidecar：

   kubectl get pod -n NAMESPACE

   在上一个命令的以下示例输出中，注意 READY 列表示每个工作负载均有两个容器：主容器和边车代理的容器。

   NAME                    READY   STATUS    RESTARTS   AGE
   WORKLOAD           2/2     Running   0          20s
   ...