O Anthos Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Configurar uma malha híbrida ou de várias nuvens

Nesta página, explicamos como configurar uma malha híbrida ou de várias nuvens para as seguintes plataformas:

Híbrido: GKE no Google Cloud e GKE no VMware (pré-lançamento)
Híbrido: GKE no Google Cloud e GKE em Bare Metal (pré-lançamento)
Várias nuvens: GKE no Google Cloud e Amazon EKS (visualização)

Observação sobre a plataforma: o comando asmcli create-mesh usado para ativar a descoberta de endpoints exige que todos os clusters na malha sejam uma das combinações de plataformas de várias nuvens/híbridas na lista anterior. Outras combinações de malhas de várias nuvens ou híbridas em outras plataformas não são compatíveis. O Anthos Service Mesh gerenciado não é compatível com malhas de várias nuvens ou híbridas.

Ao seguir estas instruções, você configurará dois clusters, mas poderá estender esse processo para incorporar qualquer quantidade de clusters em sua malha.

Pré-requisitos

Todos os clusters precisam ser registrados no mesmo projeto host da frota.
Todos os clusters do GKE precisam estar em uma configuração de VPC compartilhada na mesma rede.
O endereço do plano de controle do Kubernetes e o endereço do gateway do cluster precisam estar acessíveis em todos os clusters da malha. O projeto do Google Cloud em que os clusters do GKE estão localizados precisa ter permissão para criar tipos de balanceamento de carga externos. Recomendamos que você use redes autorizadas e regras de firewall da VPC para restringir o acesso.
Clusters particulares, incluindo clusters privados do GKE, não são compatíveis. Se você usa clusters no local, incluindo o GKE no VMware e o GKE em Bare Metal, o endereço do plano de controle do Kubernetes e o endereço do gateway precisam ser acessíveis por pods em clusters do GKE. Recomendamos que você use o CloudVPN para conectar a sub-rede do cluster do GKE à rede do cluster no local.
Se você usar a CA do Istio, utilize o mesmo certificado raiz personalizado para todos os clusters.

Antes de começar

Neste guia, presume-se que você tenha instalado o Anthos Service Mesh com a ferramenta asmcli. Você precisa do asmcli e do pacote de configuração que o asmcli faz o download para o diretório especificado em --output_dir quando você executou asmcli install. Para mais informações, consulte Instalar ferramentas dependentes e validar o cluster para:

Você precisa ter acesso aos arquivos kubeconfig de todos os clusters que está configurando na malha. Para criar um novo arquivo kubeconfig no cluster do GKE, é possível exportar o ambiente KUBECONFIG com o caminho completo do arquivo como valor no terminal e gerar a entrada kubeconfig.

Configurar variáveis de ambiente e marcadores

Você precisa das seguintes variáveis de ambiente ao instalar o gateway leste-oeste.

Crie variáveis de ambiente para os nomes de rede:

O padrão dos clusters do GKE é o nome da rede do cluster:
```
export NETWORK_1="PROJECT_ID-CLUSTER_NETWORK"
``````
```
Outros clusters usam default:
```
export NETWORK_2="default"
``````
```

Se você instalou o Anthos Service Mesh em outros clusters com valores diferentes para --network_id, transmita os mesmos valores para o valor para NETWORK_2.

Instalar o gateway leste-oeste

Instale um gateway dedicado a CLUSTER_1 (seu cluster do GKE) dedicado ao tráfego leste-oeste para CLUSTER_2 (seu cluster de várias nuvens ou local):
```
asm/istio/expansion/gen-eastwest-gateway.sh \
    --network ${NETWORK_1}  \
    --revision asm-1232-2 | \
    ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_1 install -y -f -
```
Observe que esse gateway é público na Internet por padrão. Os sistemas de produção podem exigir outras restrições de acesso, como regras de firewall, para evitar ataques externos.

Instale um gateway em CLUSTER_2 que seja dedicado ao tráfego leste-oeste para CLUSTER_1.

asm/istio/expansion/gen-eastwest-gateway.sh \
    --network ${NETWORK_2} \
    --revision asm-1232-2 | \
    ./istioctl --kubeconfig=PATH_TO_KUBECONFIG_2 install -y -f -

Expor serviços

Como os clusters estão em redes separadas, é necessário expor todos os serviços (\*.local) no gateway leste-oeste em ambos os clusters. Embora este gateway seja público na Internet, os serviços por trás dele só poderão ser acessados por serviços com um certificado mTLS confiável e um ID de carga de trabalho, como se estivessem na mesma rede.

Expor serviços pelo gateway leste-oeste para cada cluster

    kubectl --kubeconfig=PATH_TO_KUBECONFIG_1 apply -n istio-system -f \
        asm/istio/expansion/expose-services.yaml
    kubectl --kubeconfig=PATH_TO_KUBECONFIG_2 apply -n istio-system -f \
        asm/istio/expansion/expose-services.yaml

Ativar descoberta de endpoints

Execute o comando asmcli create-mesh para ativar a descoberta de endpoints. Este exemplo mostra apenas dois clusters, mas é possível executar o comando para ativar a descoberta de endpoints em clusters adicionais, sujeitos ao limite de serviço do GKE Hub.

  ./asmcli create-mesh \
      FLEET_PROJECT_ID \
      PATH_TO_KUBECONFIG_1 \
      PATH_TO_KUBECONFIG_2

Verificar a conectividade de vários clusters

Nesta seção, você verá como implantar os serviços de amostra HelloWorld e Sleep no ambiente de vários clusters para verificar se o balanceamento de carga entre eles funciona.

Ative a injeção de sidecar

Localize o valor do rótulo de revisão, que você vai usar em etapas futuras.

Use o comando a seguir para localizar o identificador de revisão, que vai ser usado em etapas futuras.

kubectl -n istio-system get pods -l app=istiod --show-labels

A resposta será semelhante a:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-173-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
istiod-asm-173-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586

Na saída, na coluna LABELS, observe o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-173-3. Use o valor da revisão nas etapas da próxima seção.

Instalar o serviço HelloWorld

Crie o namespace de amostra e a definição de serviço em cada cluster. No comando a seguir, substitua REVISION pelo rótulo de revisão istiod que você anotou na etapa anterior.
```
for CTX in ${CTX_1} ${CTX_2}
do
    kubectl create --context=${CTX} namespace sample
    kubectl label --context=${CTX} namespace sample \
        istio-injection- istio.io/rev=REVISION --overwrite
done
```
em que REVISION é o rótulo de revisão istiod que você anotou anteriormente.

A resposta é:
```
label "istio-injection" not found.
namespace/sample labeled
```
Você pode ignorar label "istio-injection" not found. com segurança

Crie o serviço HelloWorld em ambos os clusters:

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

Implantar o HelloWorld v1 e v2 em cada cluster

Implante HelloWorld v1 em CLUSTER_1 e v2 em CLUSTER_2. Isso ajudará a verificar o balanceamento de carga entre clusters posteriormente:

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

Confirme se HelloWorld v1 e v2 estão em execução usando os seguintes comandos. Verifique se a saída é semelhante a esta:

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

Implantar o serviço Sleep

Implante o serviço Sleep nos dois clusters. Esse pod gera tráfego de rede artificial para fins de demonstração:

for CTX in ${CTX_1} ${CTX_2}
do
    kubectl apply --context=${CTX} \
        -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
done

Aguarde a inicialização do serviço Sleep em cada cluster. Verifique se a saída é semelhante a esta:

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

Verificar o balanceamento de carga entre clusters

Chame o serviço HelloWorld várias vezes e confira o resultado para verificar as respostas alternadas da v1 e da v2:

Chame o serviço 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'

A resposta será semelhante a esta:

Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
...

Chame o serviço HelloWorld novamente:

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'

A resposta será semelhante a esta:

Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
...

Parabéns, você verificou seu balanceamento de carga com vários clusters do Anthos Service Mesh!

Limpar

Quando terminar de verificar o balanceamento de carga, remova os serviços HelloWorld e Sleep do seu cluster.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}