在代管式 Cloud Service Mesh 上设置多集群网格
本指南介绍如何使用 Mesh CA 或 Certificate Authority Service 并启用跨集群负载均衡您可以轻松扩展此流程,将任意数量的集群整合到网格中。
多集群 Cloud Service Mesh 配置可以满足一些重要企业场景,例如扩缩、位置和隔离。如需了解详情,请参阅多集群用例。
前提条件
本指南假定您有两个或多个满足以下要求的 Google Cloud GKE 集群:
- 在集群上安装了 Cloud Service Mesh。您需要
asmcli
、istioctl
工具以及asmcli
下载到 在--output_dir
中指定的目录。 - 在配置 Cloud Service Mesh 之前,网格中的集群必须在所有 pod 之间建立连接。此外,如果您要加入的集群不在同一个项目中,则它们必须向同一舰队宿主项目注册,并且这些集群必须位于同一网络的共享 VPC配置中。我们还建议您使用一个项目来托管共享 VPC,并使用两个服务项目来创建集群。如需了解详情,请参阅通过共享 VPC 设置集群。
- 如果您使用 Certificate Authority Service,则所有集群都必须将各自的从属 CA 池链接到同一根 CA 池。否则,所有这些实例都需要使用同一 CA 池。
设置项目和集群变量
为项目 ID、集群可用区或区域、集群名称和上下文创建以下环境变量。
export PROJECT_1=PROJECT_ID_1 export LOCATION_1=CLUSTER_LOCATION_1 export CLUSTER_1=CLUSTER_NAME_1 export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}" export PROJECT_2=PROJECT_ID_2 export LOCATION_2=CLUSTER_LOCATION_2 export CLUSTER_2=CLUSTER_NAME_2 export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
如果这些集群是新创建的集群,请确保使用以下
gcloud
命令为每个集群提取凭据,否则其关联的context
将在本指南的后续步骤中不可用。这些命令取决于您的集群类型(区域级或可用区级):
区域级
gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1} gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
可用区级
gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1} gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
创建防火墙规则
在某些情况下,您需要创建防火墙规则以允许跨集群流量。例如,在以下情况下,您需要创建防火墙规则:
- 网格中的集群使用不同的子网。
- pod 会打开除 443 和 15002 以外的端口。
GKE 会自动向每个节点添加防火墙规则,以允许同一子网内的流量。如果网格包含多个子网,您必须明确设置防火墙规则以允许跨子网流量。您必须为每个子网添加新的防火墙规则,以允许所有传入流量的来源 IP CIDR 地址块和目标端口。
以下说明允许项目中所有集群之间或仅 $CLUSTER_1
和 $CLUSTER_2
之间进行通信。
收集关于集群的网络的信息。
所有项目集群
如果集群位于同一项目中,则可以使用以下命令,允许在项目中的所有集群之间进行通信。如果项目中有您不想公开的集群,请使用特定集群标签页中的命令。
function join_by { local IFS="$1"; shift; echo "$*"; } ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq) ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}")) ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq) ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
特定集群
以下命令允许
$CLUSTER_1
和$CLUSTER_2
之间进行通信,并且不会公开项目中的其他集群。function join_by { local IFS="$1"; shift; echo "$*"; } ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq) ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}")) ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq) ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
创建防火墙规则。
GKE
gcloud compute firewall-rules create istio-multicluster-pods \ --allow=tcp,udp,icmp,esp,ah,sctp \ --direction=INGRESS \ --priority=900 \ --source-ranges="${ALL_CLUSTER_CIDRS}" \ --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \ --network=YOUR_NETWORK
Autopilot
TAGS="" for CLUSTER in ${CLUSTER_1} ${CLUSTER_2} do TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+="," done TAGS=${TAGS::-1} echo "Network tags for pod ranges are $TAGS" gcloud compute firewall-rules create asm-multicluster-pods \ --allow=tcp,udp,icmp,esp,ah,sctp \ --network=gke-cluster-vpc \ --direction=INGRESS \ --priority=900 --network=VPC_NAME \ --source-ranges="${ALL_CLUSTER_CIDRS}" \ --target-tags=$TAGS
配置端点发现
使用声明式 API 启用公共集群或专用集群之间的端点发现
如果使用 Fleet API 启用托管式 Cloud Service Mesh,系统会为此集群启用端点发现。如果您使用其他工具预配了托管式 Cloud Service Mesh,则可以通过在 asm-options
configmap 中应用配置 "multicluster_mode":"connected"
来手动在舰队中的各公共集群或专用集群之间启用端点发现。在同一舰队中启用了此配置的集群相互之间会自动启用跨集群服务发现。
如果您满足以下条件,则这是配置多集群端点发现的唯一方式 代管式 (TD) 控制平面实现, 如果您拥有代管式 (Istiod) 实现,则建议采用这种方式进行配置。
在继续操作之前,您必须先创建防火墙规则。
启用
如果集群中已存在 asm-options
configmap,请为集群启用端点发现:
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
如果您的集群中尚不存在 asm-options
ConfigMap,则
使用关联数据创建网络,并为
集群:
kubectl --context ${CTX_1} create configmap asm-options -n istio-system --from-file <(echo '{"data":{"multicluster_mode":"connected"}}')
停用
停用集群的端点发现:
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'
如果您从集群中取消注册集群,但不停用端点发现,则 Secret 可能会保留在集群中。您必须手动清理所有剩余的 Secret。
运行以下命令以查找需要清理的 Secret:
kubectl get secrets -n istio-system -l istio.io/owned-by=mesh.googleapis.com,istio/multiCluster=true
删除每个 Secret:
kubectl delete secret SECRET_NAME
对每个剩余的 Secret 重复此步骤。
验证多集群连接
本部分介绍如何将示例 HelloWorld
和 Sleep
服务部署到多集群环境,以验证跨集群负载均衡可正常工作。
设置示例目录的变量
前往
asmcli
的下载位置,然后运行以下命令以设置ASM_VERSION
export ASM_VERSION="$(./asmcli --version)"
将工作文件夹设置为用于验证跨集群负载均衡是否正常工作的示例。这些示例位于您在
asmcli install
命令中指定的--output_dir
目录的子目录中。在以下命令中,将OUTPUT_DIR
更改为您在--output_dir
中指定的目录。export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
启用边车注入
在每个集群中创建示例命名空间。
for CTX in ${CTX_1} ${CTX_2} do kubectl create --context=${CTX} namespace sample done
启用用于注入的命名空间。具体步骤取决于您的控制平面实现。
受管理 (TD)
- 将默认注入标签应用于命名空间:
for CTX in ${CTX_1} ${CTX_2} do kubectl label --context=${CTX} namespace sample istio.io/rev- istio-injection=enabled --overwrite done
受管理(Istiod)
推荐:运行以下命令可将默认注入标签应用于命名空间:
for CTX in ${CTX_1} ${CTX_2} do kubectl label --context=${CTX} namespace sample \ 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 CTX in ${CTX_1} ${CTX_2} do kubectl label --context=${CTX} namespace sample \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite done
安装 HelloWorld 服务
在这两个集群中创建 HelloWorld 服务:
kubectl create --context=${CTX_1} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l service=helloworld -n sample
kubectl create --context=${CTX_2} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l service=helloworld -n sample
将 HelloWorld v1 和 v2 部署到每个集群
将
HelloWorld v1
部署到CLUSTER_1
,并将v2
部署到CLUSTER_2
,这可帮助以后验证跨集群负载均衡:kubectl create --context=${CTX_1} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l version=v1 -n sample
kubectl create --context=${CTX_2} \ -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \ -l version=v2 -n sample
使用以下命令确认
HelloWorld v1
和v2
正在运行。验证输出是否如下所示:kubectl get pod --context=${CTX_1} -n sample
NAME READY STATUS RESTARTS AGE helloworld-v1-86f77cd7bd-cpxhv 2/2 Running 0 40s
kubectl get pod --context=${CTX_2} -n sample
NAME READY STATUS RESTARTS AGE helloworld-v2-758dd55874-6x4t8 2/2 Running 0 40s
部署 Sleep 服务
将
Sleep
服务部署到这两个集群。此 pod 将出于演示目的生成虚假网络流量:for CTX in ${CTX_1} ${CTX_2} do kubectl apply --context=${CTX} \ -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample done
等待在每个集群中启动
Sleep
服务。验证输出是否如下所示:kubectl get pod --context=${CTX_1} -n sample -l app=sleep
NAME READY STATUS RESTARTS AGE sleep-754684654f-n6bzf 2/2 Running 0 5s
kubectl get pod --context=${CTX_2} -n sample -l app=sleep
NAME READY STATUS RESTARTS AGE sleep-754684654f-dzl9j 2/2 Running 0 5s
验证跨集群负载均衡
多次调用 HelloWorld
服务,并检查输出以验证来自 v1 和 v2 的交替回复:
调用
HelloWorld
服务:kubectl exec --context="${CTX_1}" -n sample -c sleep \ "$(kubectl get pod --context="${CTX_1}" -n sample -l \ app=sleep -o jsonpath='{.items[0].metadata.name}')" \ -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
输出类似于如下所示内容:
Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8 Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv ...
再次调用
HelloWorld
服务:kubectl exec --context="${CTX_2}" -n sample -c sleep \ "$(kubectl get pod --context="${CTX_2}" -n sample -l \ app=sleep -o jsonpath='{.items[0].metadata.name}')" \ -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
输出类似于如下所示内容:
Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8 Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv ...
恭喜,您已成功验证负载均衡的多集群 Cloud Service Mesh!
清理 HelloWorld 服务
完成负载均衡验证后,请从集群中移除 HelloWorld
和 Sleep
服务。
kubectl delete ns sample --context ${CTX_1} kubectl delete ns sample --context ${CTX_2}