您正在查看 v1.21 Service Mesh 文档。

可用版本

Cloud Service Mesh
1.22 归档
 1.21 归档
 1.20 归档
 1.19 归档
 1.18 归档

此页面由 Cloud Translation API 翻译。

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

本页介绍了如何使用 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 代码库中原始清单集的基础上进行了修改。按照最佳实践，每项服务都会部署在具有唯一服务账号的单独命名空间中。

为应用创建命名空间：

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 有助于增强网络安全性、可靠性和可观测性。这些功能从应用的主容器中抽象出来，并在作为同一 pod 中单独的容器提供的常见进程外代理 (Sidecar) 中实现。您可以使用 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，这会重启所有安装了 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 代理