进行 Kubernetes 工作负载初始配置

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

部署 Kubernetes 服务

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

  • 为所有容器创建 Kubernetes Service。所有 Deployment 应关联一个 Kubernetes Service。

  • 为您的 Service 端口命名。虽然 GKE 允许您定义未命名的服务端口，但 Cloud Service Mesh 要求您为端口提供名称，并确保名称与端口协议匹配。

  • 为 Deployment 添加标签。这样一来，您就可以使用 Cloud Service Mesh 流量管理功能，例如在同一服务的不同版本之间拆分流量。

以下示例 Deployment 和 Service 演示了这些要求：

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 的集群上部署 Service 后，请务必注入边车代理。

示例：部署 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. 启用用于注入的命名空间。具体步骤取决于控制平面实现。

    托管式 (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;

    如果您是使用托管式 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 配置的命名空间标签时，将自动进行边车代理注入（即自动注入）。该代理会拦截工作负载的所有入站和出站流量，并与 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

    如果您是使用托管式 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 列表示每个工作负载均有两个容器：主容器和边车代理的容器。

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