引入 Kubernetes 工作负载

本页介绍了如何使用 Cloud Service Mesh 引入 Kubernetes 工作负载。

部署 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 示例

此 API 中的 Online Boutique 示例应用 anthos-service-mesh-packages 原始清单集修改了代码库 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. 启用用于注入的命名空间。具体步骤取决于您的控制平面实现。

    受管 (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 控制平面的现有用户： 我们建议您使用默认注入，但基于修订版本的注入 支持。请按照以下说明操作：

    1. 运行以下命令以查找可用的发布渠道：

      kubectl -n istio-system get controlplanerevision

      输出类似于以下内容：

      NAME                AGE
asm-managed-rapid   6d7h

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

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

      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;

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

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

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

    2. 将修订版本标签应用于命名空间。在以下命令中，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;

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

注入 Sidecar 代理

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

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

启用自动 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

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

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

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

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

重启 pod 以更新 Sidecar 代理

借助自动 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 列表示每个工作负载均有两个容器：主容器和 Sidecar 代理的容器。

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