引入 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 控制台中显示指标,必须使用以下协议之一为服务端口命名:httphttp2grpc。使用 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
    ...