Enable mutual access between workloads on remote and managed control planes - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

Este tópico descreve como estabelecer o acesso mútuo entre clusters após a utilização do recurso de plano de controle remoto do ASM.

Pré-requisitos

Conclua todas as etapas descritas em Reduzir a latência de push usando o plano de controle remoto do ASM. Neste tópico, cluster-1 representa um cluster Alibaba Cloud Container Service for Kubernetes (ACK) gerenciado pelo plano de controle gerenciado do ASM, enquanto cluster-2 representa um cluster não ACK gerenciado pelo plano de controle remoto do ASM.
Os procedimentos deste tópico exigem alternância entre arquivos kubeconfig. Adicione os arquivos kubeconfig do cluster-1 e do cluster-2 ao mesmo arquivo de configuração e use o comando kubectl config use-context para alternar entre os clusters. Alternativamente, use o kubecm ou o kubectx para gerencie os arquivos kubeconfig de múltiplos clusters.
Configure a rede do cluster e o gateway leste-oeste e implante as aplicações httpbin e sleep tanto no cluster-1 quanto no cluster-2. Para mais detalhes, consulte Estabelecer interconexão cross-network multi-cluster usando o gateway leste-oeste do ASM.

Etapa 1: Testar o acesso do cluster-1 ao cluster-2

Use o arquivo kubeconfig do cluster-1 para execute o comando abaixo. Esse comando dimensiona a aplicação httpbin no cluster-1 para 0 réplicas para fins de teste.
```
kubectl scale deployment httpbin --replicas 0
```
Com o arquivo kubeconfig do cluster-1, execute o seguinte comando para acessar a aplicação httpbin a partir da aplicação sleep no cluster-1.
```
kubectl exec deployment/sleep -it -- curl httpbin:8000/status/418
```
Saída esperada:
```
    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`
```
Essa saída confirma que o acesso foi bem-sucedido. A requisição é processada pela aplicação httpbin no cluster-2 e a comunicação usa criptografia via Mutual Transport Layer Security (mTLS).

Etapa 2: Testar o acesso do cluster-2 ao cluster-1

Crie os recursos ClusterRole e ClusterRoleBinding no cluster-1 com o arquivo YAML a seguir. O plano de controle remoto do cluster-2 usa esse ClusterRole para obter informações de serviço do cluster-1.

Expand to visualize the yaml file

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app: istio-reader
  name: istio-reader-clusterrole-istio-system
rules:
- apiGroups:
  - config.istio.io
  - security.istio.io
  - networking.istio.io
  - authentication.istio.io
  - rbac.istio.io
  - telemetry.istio.io
  - extensions.istio.io
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  - pods
  - services
  - nodes
  - replicationcontrollers
  - namespaces
  - secrets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.istio.io
  resources:
  - workloadentries
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - networking.x-k8s.io
  - gateway.networking.k8s.io
  resources:
  - gateways
  - gatewayclasses
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - multicluster.x-k8s.io
  resources:
  - serviceexports
  verbs:
  - get
  - list
  - watch
  - create
  - delete
- apiGroups:
  - multicluster.x-k8s.io
  resources:
  - serviceimports
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - replicasets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - authentication.k8s.io
  resources:
  - tokenreviews
  verbs:
  - create
- apiGroups:
  - authorization.k8s.io
  resources:
  - subjectaccessreviews
  verbs:
  - create
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create", "get", "list", "watch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app: istio-reader
  name: istio-reader-clusterrole-istio-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istio-reader-clusterrole-istio-system
subjects:
- kind: ServiceAccount
  name: istio-reader-service-account
  namespace: istio-system

Verifique se os contextos do kubectl estão configurados corretamente. O contexto do cluster-1 deve ter o nome cluster-1 e o contexto do cluster-2 deve ter o nome cluster-2.
Instale a ferramenta istioctl e garanta que sua versão seja compatível com a versão do ASM em uso. Mude para o diretório extraído do istio e execute o comando abaixo.
```
# Replace <YOUR_CLUSTER1_ID> with the ID of cluster-1.
bin/istioctl create-remote-secret \
--context=cluster-1 \
--name=<YOUR_CLUSTER1_ID> | \
kubectl apply -f - --context=cluster-2
```
Após concluir esta etapa, um secret será gerado no namespace istio-system do cluster-2. Esse secret contém a credencial de acesso necessária para conectar-se ao cluster-1. Gerencie as permissões desse secret com cuidado para evitar vazamentos.
Use o arquivo kubeconfig do cluster-1 para execute o comando a seguir e definir o número de réplicas da aplicação httpbin como 1.
```
kubectl scale deployment httpbin --replicas 1
```
Use o arquivo kubeconfig do cluster-2 para execute o comando abaixo e dimensionar o número de réplicas da aplicação httpbin para 0.
```
kubectl scale deployment httpbin --replicas 0
```

Use o arquivo kubeconfig do cluster-2 para execute o seguinte comando e testar o acesso do cluster-2 à aplicação httpbin no cluster-1.

kubectl exec deployment/sleep -it -- curl httpbin:8000/status/418

Saída esperada:

    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`