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)
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:
- Instale as ferramentas necessárias
- Fazer o download do asmcli
- Conceder permissões de administrador de cluster
- Validar o projeto e o cluster
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çaCrie 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
emCLUSTER_1
ev2
emCLUSTER_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
ev2
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}