Nesta página, mostraremos como implantar um Ingress que exibe um aplicativo em vários clusters do GKE. Para saber mais sobre a entrada de vários clusters, consulte entrada de vários clusters.
Para uma comparação detalhada entre Ingress de vários clusters (MCI), Gateway de vários clusters (MCG) e balanceador de carga com grupos de endpoints de rede independentes (LB e NEGs independentes), consulte Escolher sua API de balanceamento de carga de vários clusters para o GKE.
Tutorial de implantação
Nas tarefas a seguir, você implantará um aplicativo fictício chamado whereami
e um MultiClusterIngress
em dois clusters. O Ingress fornece um endereço IP virtual (VIP, na sigla em inglês)
compartilhado para as implantações do aplicativo.
Esta página baseia-se no trabalho feito em Como configurar a entrada de vários clusters, onde você criou e registrou dois clusters. Confirme se você tem dois clusters que também estão registrados em uma frota:
gcloud container clusters list
A saída será assim:
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS
gke-eu europe-west1-b 1.16.8-gke.9 *** e2-medium 1.16.8-gke.9 2 RUNNING
gke-us us-central1-b 1.16.8-gke.9 *** e2-medium 1.16.6-gke.13 * 2 RUNNING
Como criar o namespace
Como as frotas têm a propriedade de
semelhança de namespace,
recomendamos coordenar a criação e o gerenciamento de namespaces em clusters
para que os namespaces idênticos sejam de propriedade e gerenciados pelo mesmo grupo. É possível criar
namespaces por equipe, por ambiente, por aplicativo ou por componente do
aplicativo. Os namespaces podem ser tão granulares quanto necessário, desde que um namespace ns1
em um
cluster tenha o mesmo significado e uso de ns1
em outro cluster.
Neste exemplo, você cria um namespace whereami
para cada aplicativo em
cada cluster.
Crie um arquivo chamado
namespace.yaml
que tenha o seguinte conteúdo:apiVersion: v1 kind: Namespace metadata: name: whereami
Alterne para o contexto do gke-us:
kubectl config use-context gke-us
Crie o namespace:
kubectl apply -f namespace.yaml
Alterne para o contexto do gke-eu:
kubectl config use-context gke-eu
Crie o namespace:
kubectl apply -f namespace.yaml
A saída será assim:
namespace/whereami created
Como implantar o app
Crie um arquivo chamado
deploy.yaml
que tenha o seguinte conteúdo:apiVersion: apps/v1 kind: Deployment metadata: name: whereami-deployment namespace: whereami labels: app: whereami spec: selector: matchLabels: app: whereami template: metadata: labels: app: whereami spec: containers: - name: frontend image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20 ports: - containerPort: 8080
Alterne para o contexto do gke-us:
kubectl config use-context gke-us
Implante o aplicativo
whereami
:kubectl apply -f deploy.yaml
Alterne para o contexto do gke-eu:
kubectl config use-context gke-eu
Implante o aplicativo
whereami
:kubectl apply -f deploy.yaml
Verifique se o aplicativo
whereami
foi implantado com sucesso em cada cluster:kubectl get deployment --namespace whereami
A saída será semelhante a esta nos dois clusters:
NAME READY UP-TO-DATE AVAILABLE AGE whereami-deployment 1/1 1 1 12m
Como implantar com o cluster de configuração
Agora que o aplicativo foi implantado em gke-us
e gke-eu
, você
implantará um balanceador de carga implantando os recursos MultiClusterIngress
e
MultiClusterService
no cluster de configuração. Eles são os
equivalentes de vários clusters dos recursos de entrada e serviço.
No guia de configuração,
você configurou gke-us
como o cluster de configuração. O cluster de configuração é
usado para implantar e configurar o Ingress em todos os clusters.
Defina o contexto como o cluster de configuração.
kubectl config use-context gke-us
MultiClusterService
Crie um arquivo chamado
mcs.yaml
que tenha o seguinte conteúdo:apiVersion: networking.gke.io/v1 kind: MultiClusterService metadata: name: whereami-mcs namespace: whereami spec: template: spec: selector: app: whereami ports: - name: web protocol: TCP port: 8080 targetPort: 8080
Implante o recurso
MultiClusterService
que corresponde ao aplicativowhereami
:kubectl apply -f mcs.yaml
Verifique se o recurso
whereami-mcs
foi implantado no cluster de configuração:kubectl get mcs -n whereami
A saída será assim:
NAME AGE whereami-mcs 9m26s
Esse
MultiClusterService
cria um serviço sem comando derivado em cada cluster que corresponde a pods comapp: whereami
. É possível ver que existe um no clustergke-us
kubectl get service -n whereami
.A saída será assim:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mci-whereami-mcs-svc-lgq966x5mxwwvvum ClusterIP None <none> 8080/TCP 4m59s
Um serviço sem comando semelhante também existirá em gke-eu
. Esses serviços locais são
usados para selecionar dinamicamente os endpoints do pod para programar o balanceador
de carga global do Ingress com back-ends.
MultiClusterIngress
Crie um arquivo chamado
mci.yaml
que tenha o seguinte conteúdo:apiVersion: networking.gke.io/v1 kind: MultiClusterIngress metadata: name: whereami-ingress namespace: whereami spec: template: spec: backend: serviceName: whereami-mcs servicePort: 8080
Essa configuração encaminha todo o tráfego para o
MultiClusterService
chamadowhereami-mcs
que existe no namespacewhereami
.Implante o recurso
MultiClusterIngress
que se refere aowhereami-mcs
como um back-end:kubectl apply -f mci.yaml
A saída será assim:
multiclusteringress.networking.gke.io/whereami-ingress created
Observe que
MultiClusterIngress
tem o mesmo esquema que do Kubernetes Ingress. A semântica de recursos do Ingress também é a mesma, com exceção do campobackend.serviceName
.
O campo backend.serviceName
em um MultiClusterIngress
que se refere a um
MultiClusterService
na API Fleet em vez de um serviço em um cluster do
Kubernetes. Isso significa que qualquer uma das configurações do Ingress, como o encerramento do
TLS, pode ser definida da mesma maneira.
Como validar um status de implantação bem-sucedido
A implantação de novos balanceadores de carga do Google Cloud pode levar
vários minutos. A atualização dos balanceadores de carga que já existem é concluída mais rapidamente porque novos recursos não precisam ser implantados. O recurso MultiClusterIngress
detalha os recursos básicos
do Compute Engine que foram criados em nome do MultiClusterIngress
.
Verifique se a implantação foi bem-sucedida:
kubectl describe mci whereami-ingress -n whereami
A saída será assim:
Name: whereami-ingress Namespace: whereami Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"networking.gke.io/v1","kind":"MultiClusterIngress","metadata":{"annotations":{},"name":"whereami-ingress","namespace":"whe... API Version: networking.gke.io/v1 Kind: MultiClusterIngress Metadata: Creation Timestamp: 2020-04-10T23:35:10Z Finalizers: mci.finalizer.networking.gke.io Generation: 2 Resource Version: 26458887 Self Link: /apis/networking.gke.io/v1/namespaces/whereami/multiclusteringresses/whereami-ingress UID: 62bec0a4-8a08-4cd8-86b2-d60bc2bda63d Spec: Template: Spec: Backend: Service Name: whereami-mcs Service Port: 8080 Status: Cloud Resources: Backend Services: mci-8se3df-8080-whereami-whereami-mcs Firewalls: mci-8se3df-default-l7 Forwarding Rules: mci-8se3df-fw-whereami-whereami-ingress Health Checks: mci-8se3df-8080-whereami-whereami-mcs Network Endpoint Groups: zones/europe-west1-b/networkEndpointGroups/k8s1-e4adffe6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-88670678 zones/us-central1-b/networkEndpointGroups/k8s1-a6b112b6-whereami-mci-whereami-mcs-svc-lgq966x5m-808-609ab6c6 Target Proxies: mci-8se3df-whereami-whereami-ingress URL Map: mci-8se3df-whereami-whereami-ingress VIP: 34.98.102.37 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 3m35s multi-cluster-ingress-controller whereami/whereami-ingress Normal UPDATE 3m10s (x2 over 3m34s) multi-cluster-ingress-controller whereami/whereami-ingress
Há vários campos que indicam o status dessa implantação do Ingress:
Events
é o primeiro lugar para procurar. Se ocorrer um erro, ele será listado aqui.Cloud Resource
lista os recursos do Compute Engine, como regras de encaminhamento, serviços de back-end e regras de firewall que foram criados pelo Multi Cluster Ingress Console. Se eles não estiverem listados, significa que ainda não foram criados. Inspecione recursos individuais do Compute Engine com o console ou o comandogcloud
para receber o status.VIP
lista um endereço IP quando ele é alocado. Observe que o balanceador de carga ainda não está processando o tráfego, embora o VIP exista. Se você não vir um VIP após alguns minutos ou se o balanceador de carga não disponibilizar uma resposta 200 em 10 minutos, consulte Solução de problemas e operações.
Se os eventos de saída forem
Normal
, a implantação doMultiClusterIngress
provavelmente será bem-sucedida, mas a única maneira de determinar se o caminho de tráfego completo é funcional é testá-lo.Valide se o aplicativo está sendo exibido no VIP com o endpoint
/ping
:curl INGRESS_VIP/ping
Substitua
INGRESS_VIP
pelo endereço IP virtual (VIP, na sigla em inglês).A saída será assim:
{ "cluster_name": "gke-us", "host_header": "34.120.175.141", "pod_name": "whereami-deployment-954cbf78-mtlpf", "pod_name_emoji": "😎", "project_id": "my-project", "timestamp": "2021-11-29T17:01:59", "zone": "us-central1-b" }
A saída deve indicar a região e o back-end do aplicativo.
Também é possível acessar o URL
http://INGRESS_VIP
no seu navegador para ver uma versão gráfica do aplicativo que mostra a região de origem.O cluster que recebe o tráfego encaminhado depende do seu local. O GCLB foi projetado para encaminhar o tráfego do cliente para o back-end mais próximo disponível com capacidade.
Especificações de recursos
Especificação MultiClusterService
A definição MultiClusterService
consiste em duas partes:
Uma seção
template
que define o serviço a ser criado nos clusters do Kubernetes. Embora a seçãotemplate
contenha campos aceitos em um serviço típico, há apenas dois campos compatíveis emMultiClusterService
:selector
eports
. Os outros campos serão ignorados.Uma seção
clusters
opcional que define quais clusters recebem tráfego e as propriedades de balanceamento de carga de cada cluster. Se nenhuma seçãoclusters
for especificada ou se nenhum cluster estiver listado, todos os clusters serão usados por padrão.
O manifesto a seguir descreve um MultiClusterService
padrão:
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: NAME
namespace: NAMESPACE
spec:
template:
spec:
selector:
app: POD_LABEL
ports:
- name: web
protocol: TCP
port: PORT
targetPort: TARGET_PORT
Substitua:
NAME
: o nome doMultiClusterService
. Esse nome é indicado pelo camposerviceName
nos recursosMultiClusterIngress
;NAMESPACE
: o namespace do Kubernetes em que oMultiClusterService
está implantado. Ele precisa corresponder ao mesmo namespace que oMultiClusterIngress
e os pods em todos os clusters na frota;POD_LABEL
: o rótulo que determina quais pods são selecionados como back-ends para esseMultiClusterService
em todos os clusters da frota;PORT
: precisa corresponder à porta referenciada peloMultiClusterIngress
que referencia esseMultiClusterService
.TARGET_PORT
: a porta usada para enviar tráfego do GCLB para o pod. Um NEG é criado em cada cluster com essa porta como porta de veiculação.
Especificação MultiClusterIngress
O mci.yaml
a seguir descreve o front-end do balanceador de carga:
apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
name: NAME
namespace: NAMESPACE
spec:
template:
spec:
backend:
serviceName: DEFAULT_SERVICE
servicePort: PORT
rules:
- host: HOST_HEADER
http:
paths:
- path: PATH
backend:
serviceName: SERVICE
servicePort: PORT
Substitua:
NAME
: o nome do recurso ;MultiClusterIngress
NAMESPACE
: o namespace do Kubernetes em que oMultiClusterIngress
está implantado. Ele precisa estar no mesmo namespace que oMultiClusterService
e os pods em todos os clusters na frota;DEFAULT_SERVICE
: atua como o back-end padrão de todo o tráfego que não corresponde a nenhuma regra de host ou caminho. Esse é um campo obrigatório, e um back-end padrão precisa ser especificado noMultiClusterIngress
, mesmo que haja outras correspondências de host ou caminho configuradas;PORT
: qualquer número de porta válido. Ele precisa corresponder ao campoport
dos recursos doMultiClusterService
;HOST_HEADER
: corresponde ao tráfego pelo campo de cabeçalho do host HTTP. O campohost
é opcional;PATH
: corresponde ao tráfego pelo caminho do URL HTTP. O campopath
é opcional;SERVICE
: o nome de umMultiClusterService
implantado no mesmo namespace e cluster de configuração que oMultiClusterIngress
.
Recursos de entrada de vários clusters
Nesta seção, mostramos como configurar recursos adicionais de entrada de vários clusters.
Seleção de cluster
Por padrão, os serviços derivados da entrada de vários clusters são programados em cada cluster membro. No entanto, convém aplicar regras de entrada a clusters específicos. Alguns casos de uso incluem:
- aplicar a entrada de vários clusters a todos os clusters, menos ao cluster de configuração, para isolá-lo.
- migrar cargas de trabalho entre clusters de uma forma "azul/verde";
- rotear para back-ends de aplicativos que existem apenas em um subconjunto de clusters;
- usar um único VIP L7 para roteamento de host ou caminho para back-ends que residem em clusters diferentes.
A seleção de cluster permite selecionar clusters por região ou nome no objeto MultiClusterService
. Isso controla quais clusters o
MultiClusterIngress
aponta e onde os Serviços derivados são programados.
Os clusters na mesma frota e região não podem ter o mesmo nome para que eles possam ter referências exclusivas.
Abrir
mcs.yaml
apiVersion: networking.gke.io/v1 kind: MultiClusterService metadata: name: whereami-mcs namespace: whereami spec: template: spec: selector: app: whereami ports: - name: web protocol: TCP port: 8080 targetPort: 8080
Essa especificação cria Serviços derivados em todos os clusters, o comportamento padrão.
Anexe as seguintes linhas na seção de clusters:
apiVersion: networking.gke.io/v1 kind: MultiClusterService metadata: name: whereami-mcs namespace: whereami spec: template: spec: selector: app: whereami ports: - name: web protocol: TCP port: 8080 targetPort: 8080 clusters: - link: "us-central1-b/gke-us" - link: "europe-west1-b/gke-eu"
Este exemplo cria recursos de Serviços derivados apenas nos clusters gke-us e gke-eu. Você precisa selecionar clusters para aplicar seletivamente as regras de entrada. Se a seção "clusters" do
MultiClusterService
não for especificada ou se nenhum cluster estiver listado, ele será interpretado como o padrão "todos".
Suporte a HTTPS
O secret do Kubernetes é compatível com HTTPS. Antes de ativar o suporte a HTTPS, crie um endereço IP estático. Esse IP estático permite que HTTP e HTTPS compartilhem o mesmo endereço IP. Para mais informações, consulte Como criar um IP estático.
Depois de criar um endereço IP estático, crie um secret.
Crie um secret:
kubectl -n whereami create secret tls SECRET_NAME --key PATH_TO_KEYFILE --cert PATH_TO_CERTFILE
Substitua:
SECRET_NAME
: pelo nome do secret;PATH_TO_KEYFILE
: pelo caminho do arquivo de chave TLS;PATH_TO_CERTFILE
: pelo caminho para o arquivo de certificado TLS.
Atualize o arquivo
mci.yaml
com o nome do secret:apiVersion: networking.gke.io/v1 kind: MultiClusterIngress metadata: name: whereami-ingress namespace: whereami annotations: networking.gke.io/static-ip: STATIC_IP_ADDRESS spec: template: spec: backend: serviceName: whereami-mcs servicePort: 8080 tls: - secretName: SECRET_NAME
Substitua
SECRET_NAME
pelo nome do seu secret. OSTATIC_IP_ADDRESS
é o endereço IP ou o URL completo do endereço alocado na seção Como criar um IP estático.Reimplante o recurso
MultiClusterIngress
:kubectl apply -f mci.yaml
A saída será assim:
multiclusteringress.networking.gke.io/whereami-ingress configured
Suporte a BackendConfig
A CRD BackendConfig a seguir permite personalizar configurações no recurso BackendService do Compute Engine:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: whereami-health-check-cfg
namespace: whereami
spec:
healthCheck:
checkIntervalSec: [int]
timeoutSec: [int]
healthyThreshold: [int]
unhealthyThreshold: [int]
type: [HTTP | HTTPS | HTTP2 | TCP]
port: [int]
requestPath: [string]
timeoutSec: [int]
connectionDraining:
drainingTimeoutSec: [int]
sessionAffinity:
affinityType: [CLIENT_IP | CLIENT_IP_PORT_PROTO | CLIENT_IP_PROTO | GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | NONE]
affinityCookieTtlSec: [int]
cdn:
enabled: [bool]
cachePolicy:
includeHost: [bool]
includeQueryString: [bool]
includeProtocol: [bool]
queryStringBlacklist: [string list]
queryStringWhitelist: [string list]
securityPolicy:
name: ca-how-to-security-policy
logging:
enable: [bool]
sampleRate: [float]
iap:
enabled: [bool]
oauthclientCredentials:
secretName: [string]
Para usar o BackendConfig, anexe-o ao recurso MultiClusterService
usando uma anotação:
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: whereami-mcs
namespace: whereami
annotations:
cloud.google.com/backend-config: '{"ports": {"8080":"whereami-health-check-cfg"}}'
spec:
template:
spec:
selector:
app: whereami
ports:
- name: web
protocol: TCP
port: 8080
targetPort: 8080
Para mais informações sobre a semântica do BackendConfig, consulte Como associar uma porta de serviço a um BackendConfig.
Suporte ao gRPC
A configuração de aplicativos gRPC na Entrada de vários clusters requer uma configuração muito específica. Veja algumas dicas para garantir que seu balanceador de carga esteja configurado corretamente:
- Verifique se o tráfego do balanceador de carga para o aplicativo é HTTP/2. Use protocolos de aplicativo para configurar isso.
- Verifique se o aplicativo está configurado corretamente no SSL, já que esse é um requisito de HTTP/2. É permitido o uso de certificados autoassinados.
- Desative o mTLS no aplicativo, já que o mTLS não é compatível com os balanceadores de carga externos L7.
Ciclo de vida dos recursos
Alterações de configuração
Os recursos MultiClusterIngress
e MultiClusterService
se comportam como objetos padrão
do Kubernetes. Por isso, as alterações feitas nos objetos são refletidas de maneira assíncrona
no sistema. Qualquer alteração que resulte em uma configuração inválida faz com que os objetos associados
do Google Cloud permaneçam inalterados e gerem um erro no stream de eventos do
objeto. Os erros associados à configuração serão informados como eventos.
Como gerenciar recursos do Kubernetes
A exclusão do objeto do Ingress desativa o balanceador de carga HTTP(S) para que
o tráfego não seja mais encaminhado para qualquer MultiClusterService
definido.
A exclusão de MultiClusterService
remove os serviços derivados associados em
cada um dos clusters.
Como gerenciar clusters
O conjunto de clusters segmentados pelo balanceador de carga pode ser alterado adicionando ou removendo clusters da frota.
Por exemplo, para remover o cluster gke-eu
como back-end de uma entrada,
execute:
gcloud container fleet memberships unregister CLUSTER_NAME \
--gke-uri=URI
Substitua:
CLUSTER_NAME
: o nome do cluster.URI
: o URI do cluster do GKE.
Para adicionar um cluster na Europa, execute:
gcloud container fleet memberships register europe-cluster \
--context=europe-cluster --enable-workload-identity
Saiba mais sobre as opções de registro de cluster em Registrar um cluster do GKE.
Registrar ou cancelar o registro de um cluster altera o status dele como um back-end
para todas as entradas. Cancelar o registro do cluster gke-eu
o remove como um back-end disponível para todos os Ingresses criados. O
inverso é verdadeiro para registrar um novo cluster.
Como desativar a entrada de vários clusters
Antes de desativar a Entrada de vários clusters, primeiro exclua os
recursos MultiClusterIngress
e MultiClusterService
e verifique se os
recursos de rede associados foram excluídos.
Em seguida, para desativar a Entrada de vários clusters, use o seguinte comando:
gcloud container fleet ingress disable
Se você não excluir os recursos MultiClusterIngress
e MultiClusterService
antes de desativar o Ingress de vários clusters, talvez encontre um erro semelhante a este:
Feature has associated resources that should be cleaned up before deletion.
Se você quiser forçar a desativação da Entrada de vários clusters, use o seguinte comando:
gcloud container fleet ingress disable --force
Anotações
As anotações a seguir são compatíveis com os recursos MultiClusterIngress
e MultiClusterService
.
Anotações MultiClusterIngress
Anotação | Descrição |
---|---|
networking.gke.io/frontend-config | Referencia um recurso BackendConfig no mesmo namespace que o recurso MultiClusterIngress. |
networking.gke.io/static-ip | Refere-se ao endereço IP literal de um IP estático global. |
networking.gke.io/pre-shared-certs | Refere-se a um recurso SSLCertificate global. |
Anotações MultiClusterService
Anotação | Descrição |
---|---|
networking.gke.io/app-protocols | Use essa anotação para definir o protocolo de comunicação entre o balanceador de carga e o aplicativo. Os protocolos possíveis são HTTP, HTTPS e HTTP/2. Consulte HTTPS entre o balanceador de carga e o aplicativo e HTTP/2 para balanceamento de carga com Entrada. |
cloud.google.com/backend-config | Use essa anotação para configurar o serviço de back-end associado a um servicePort. Para mais informações, consulte Configuração de entrada. |
Políticas de SSL e redirecionamentos HTTPS
É possível usar o recurso FrontendConfig para configurar políticas de SSL e redirecionamentos HTTPS. As políticas de SSL permitem especificar quais conjuntos de criptografia e versões de TLS são aceitos pelo balanceador de carga. Os redirecionamentos HTTPS permitem aplicar o redirecionamento de HTTP ou da porta 80 para HTTPS ou para a porta 443. As etapas a seguir configuram uma política de SSL e o redirecionamento HTTPS juntos. Observe que eles também podem ser configurados de forma independente.
Crie uma política de SSL que recuse solicitações usando uma versão anterior à TLS v1.2.
gcloud compute ssl-policies create tls-12-policy \ --profile MODERN \ --min-tls-version 1.2 \ --project=PROJECT_ID
Substitua
PROJECT_ID
pelo ID do projeto em que os clusters do GKE estiverem em execução.Visualize sua política para garantir que ela foi criada.
gcloud compute ssl-policies list --project=PROJECT_ID
O resultado será assim:
NAME PROFILE MIN_TLS_VERSION tls-12-policy MODERN TLS_1_2
Crie um certificado para
foo.example.com
como no exemplo. Quando você tiver okey.pem
e ocert.pem
, armazene essas credenciais como um secret que será referenciado pelo recurso MultiClusterIngress.kubectl -n whereami create secret tls SECRET_NAME --key key.pem --cert cert.pem
Salve o seguinte recurso FrontendConfig como
frontendconfig.yaml
. Consulte Como configurar recursos do front-end para mais informações sobre os campos compatíveis em um FrontendConfig.apiVersion: networking.gke.io/v1beta1 kind: FrontendConfig metadata: name: frontend-redirect-tls-policy namespace: whereami spec: sslPolicy: tls-12-policy redirectToHttps: enabled: true
Esse FrontendConfig ativará redirecionamentos HTTPS e uma política de SSL que impõe uma versão mínima do TLS de 1.2.
Implantar o
frontendconfig.yaml
no cluster de configuração.kubectl apply -f frontendconfig.yaml --context MCI_CONFIG_CLUSTER
Substitua
MCI_CONFIG_CLUSTER
pelo nome do cluster de configuração.Salve o seguinte MultiClusterIngress como
mci-frontendconfig.yaml
.apiVersion: networking.gke.io/v1 kind: MultiClusterIngress metadata: name: foo-ingress namespace: whereami annotations: networking.gke.io/frontend-config: frontend-redirect-tls-policy networking.gke.io/static-ip: STATIC_IP_ADDRESS spec: template: spec: backend: serviceName: default-backend servicePort: 8080 rules: - host: foo.example.com http: paths: - backend: serviceName: whereami-mcs servicePort: 8080 tls: - secretName: SECRET_NAME
- Substitua
STATIC_IP_ADDRESS
por um endereço IP global estático que você já tenha provisionado. - Substitua
SECRET_NAME
pelo secret em que o certificadofoo.example.com
está armazenado.
Há dois requisitos ao ativar redirecionamentos HTTPS:
- O TLS precisa estar ativado, seja por meio do campo
spec.tls
ou da anotação de certificado pré-compartilhadanetworking.gke.io/pre-shared-certs
. O MultiClusterIngress não será implantado se os redirecionamentos HTTPS estiverem ativados, mas o HTTPS não estiver. - Um IP estático precisa ser referenciado por meio da anotação
networking.gke.io/static-ip
. Os IPs estáticos são necessários ao ativar HTTPS em um MultiClusterIngress.
- Substitua
Implante o MultiClusterIngress no cluster de configuração.
kubectl apply -f mci-frontendconfig.yaml --context MCI_CONFIG_CLUSTER
Aguarde um ou dois minutos e inspecione
foo-ingress
.kubectl describe mci foo-ingress --context MCI_CONFIG_CLUSTER
Uma saída bem-sucedida será parecida com esta:
- O status
Cloud Resources
é preenchido com nomes de recursos. - O campo
VIP
é preenchido com o endereço IP do balanceador de carga
Name: foobar-ingress Namespace: whereami ... Status: Cloud Resources: Backend Services: mci-otn9zt-8080-whereami-bar mci-otn9zt-8080-whereami-default-backend mci-otn9zt-8080-whereami-foo Firewalls: mci-otn9zt-default-l7 Forwarding Rules: mci-otn9zt-fw-whereami-foobar-ingress mci-otn9zt-fws-whereami-foobar-ingress Health Checks: mci-otn9zt-8080-whereami-bar mci-otn9zt-8080-whereami-default-backend mci-otn9zt-8080-whereami-foo Network Endpoint Groups: zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluste-mci-default-backend-svc--80-9e362e3d zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-bar-svc-067a3lzs8-808-89846515 zones/europe-west1-b/networkEndpointGroups/k8s1-1869d397-multi-cluster--mci-foo-svc-820zw3izx-808-8bbcb1de zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluste-mci-default-backend-svc--80-a528cc75 zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-bar-svc-067a3lzs8-808-36281739 zones/us-central1-b/networkEndpointGroups/k8s1-a63e24a6-multi-cluster--mci-foo-svc-820zw3izx-808-ac733579 Target Proxies: mci-otn9zt-whereami-foobar-ingress mci-otn9zt-whereami-foobar-ingress URL Map: mci-otn9zt-rm-whereami-foobar-ingress VIP: 34.149.29.76 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal UPDATE 38m (x5 over 62m) multi-cluster-ingress-controller whereami/foobar-ingress
- O status
Verifique se os redirecionamentos HTTPS funcionam corretamente enviando uma solicitação HTTP por meio de
curl
.curl VIP
Substitua
VIP
pelo endereço IP do MultiClusterIngress.A saída deve mostrar que a solicitação foi redirecionada para a porta HTTPS, o que indica que os redirecionamentos estão funcionando corretamente.
Verifique se a política de TLS funciona corretamente enviando uma solicitação HTTPS usando a versão 1.1 do TLS. Como o DNS não está configurado para esse domínio, use a opção
--resolve
para instruir ocurl
a resolver o endereço IP diretamente.curl https://foo.example.com --resolve foo.example.com:443:VIP --cacert CERT_FILE -v
Nesta etapa, é necessário o arquivo PEM de certificado usado para proteger o MultiClusterIngress. Uma saída bem-sucedida será semelhante a esta:
... * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: O=example; CN=foo.example.com * start date: Sep 1 10:32:03 2021 GMT * expire date: Aug 27 10:32:03 2022 GMT * common name: foo.example.com (matched) * issuer: O=example; CN=foo.example.com * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7fa10f00e400) > GET / HTTP/2 > Host: foo.example.com > User-Agent: curl/7.64.1 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS == 100)! < HTTP/2 200 < content-type: application/json < content-length: 308 < access-control-allow-origin: * < server: Werkzeug/1.0.1 Python/3.8.6 < date: Wed, 01 Sep 2021 11:39:06 GMT < via: 1.1 google < alt-svc: clear < {"cluster_name":"gke-us","host_header":"foo.example.com","metadata":"foo","node_name":"gke-gke-us-default-pool-22cb07b1-r5r0.c.mark-church-project.internal","pod_name":"foo-75ccd9c96d-dkg8t","pod_name_emoji":"👞","project_id":"mark-church-project","timestamp":"2021-09-01T11:39:06","zone":"us-central1-b"} * Connection #0 to host foo.example.com left intact * Closing connection 0
O código de resposta é 200 e o TLSv1.2 está sendo usado, o que indica que tudo está funcionando corretamente.
Em seguida, tente verificar se a política de SSL aplica a versão correta do TLS tentando se conectar com o TLS 1.1. Sua política de SSL precisa ser configurada para uma versão mínima de 1.2 para que esta etapa funcione.
Envie a mesma solicitação da etapa anterior, mas aplique uma versão TLS de 1.1.
curl https://foo.example.com --resolve foo.example.com:443:VIP -v \ --cacert CERT_FILE \ --tls-max 1.1
Uma saída bem-sucedida será semelhante a esta:
* Added foo.example.com:443:34.149.29.76 to DNS cache * Hostname foo.example.com was found in DNS cache * Trying 34.149.29.76... * TCP_NODELAY set * Connected to foo.example.com (34.149.29.76) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: cert.pem CApath: none * TLSv1.1 (OUT), TLS handshake, Client hello (1): * TLSv1.1 (IN), TLS alert, protocol version (582): * error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version * Closing connection 0 curl: (35) error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
A falha na conclusão do handshake TLS indica que a política de SSL bloqueou o TLS 1.1.
Como criar um IP estático
Aloque um IP estático:
gcloud compute addresses create ADDRESS_NAME --global
Substitua
ADDRESS_NAME
pelo nome do IP estático a ser alocado.A saída contém o URL completo do endereço que você criou, semelhante ao seguinte:
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME].
Veja o endereço IP que você acabou de criar:
gcloud compute addresses list
A saída será assim:
NAME ADDRESS/RANGE TYPE STATUS ADDRESS_NAME STATIC_IP_ADDRESS EXTERNAL RESERVED
Esta saída inclui:
- O
ADDRESS_NAME
que você definiu. - O
STATIC_IP_ADDRESS
alocado.
- O
Atualize o arquivo
mci.yaml
com o IP estático:apiVersion: networking.gke.io/v1 kind: MultiClusterIngress metadata: name: whereami-ingress namespace: whereami annotations: networking.gke.io/static-ip: STATIC_IP_ADDRESS spec: template: spec: backend: serviceName: whereami-mcs servicePort: 8080
Substitua
STATIC_IP_ADDRESS
por:- O endereço IP alocado, semelhante a:
34.102.201.47
- O URL completo do endereço que você criou, semelhante a:
"https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/addresses/ADDRESS_NAME"
STATIC_IP_ADDRESS
não é o nome do recurso (ADDRESS_NAME
).- O endereço IP alocado, semelhante a:
Reimplante o recurso
MultiClusterIngress
:kubectl apply -f mci.yaml
A saída será assim:
multiclusteringress.networking.gke.io/whereami-ingress configured
Siga as etapas em Como validar um status de implantação bem-sucedido para verificar se a implantação está sendo veiculada no
STATIC_IP_ADDRESS
.
Certificados pré-compartilhados
Os certificados pré-compartilhados
são enviados ao Google Cloud e podem ser usados pelo
balanceador de carga para o encerramento de TLS em vez de certificados armazenados em secrets do
Kubernetes. Esses certificados são enviados do GKE
para o Google Cloud fora de banda e referenciados por um recurso MultiClusterIngress
.
Vários certificados, seja por certificados pré-compartilhados ou secrets do Kubernetes, também são compatíveis.
Usar os certificados na entrada de vários clusters requer a anotação
networking.gke.io/pre-shared-certs
e os nomes dos certificados. Quando
vários certificados são especificados para um determinado MultiClusterIngress
, um
pedido predeterminado define qual certificado é apresentado ao cliente.
Liste os certificados SSL disponíveis executando:
gcloud compute ssl-certificates list
O exemplo a seguir descreve o tráfego de clientes para um dos hosts especificados que corresponde ao nome comum dos certificados pré-compartilhados. Assim, o certificado que corresponde ao nome de domínio será apresentado.
kind: MultiClusterIngress
metadata:
name: shopping-service
namespace: whereami
annotations:
networking.gke.io/pre-shared-certs: "domain1-cert, domain2-cert"
spec:
template:
spec:
rules:
- host: my-domain1.gcp.com
http:
paths:
- backend:
serviceName: domain1-svc
servicePort: 443
- host: my-domain2.gcp.com
http:
paths:
- backend:
serviceName: domain2-svc
servicePort: 443
Certificados gerenciados pelo Google
Os certificados gerenciados pelo Google
são compatíveis com os recursos MultiClusterIngress
pela anotação
networking.gke.io/pre-shared-certs
. A entrada de vários clusters suporta o anexo de certificados
gerenciados pelo Google a um recurso MultiClusterIngress
. No entanto, ao contrário da entrada
de cluster único, a geração declarativa de um recurso ManagedCertificate
do Kubernetes
não é suportada nos recursos MultiClusterIngress
. A criação original do
certificado gerenciado pelo Google precisa ser feita diretamente na API
compute ssl-certificates create
antes de anexá-lo a uma
MultiClusterIngress
. Isso pode ser feito seguindo estas etapas:
Crie um certificado gerenciado pelo Google como na etapa 1 aqui. Não passe para a etapa 2, porque o Ingress de vários clusters anexará esse certificado para você.
gcloud compute ssl-certificates create my-google-managed-cert \ --domains=my-domain.gcp.com \ --global
Faça referência ao nome do certificado no
MultiClusterIngress
usando a anotaçãonetworking.gke.io/pre-shared-certs
.kind: MultiClusterIngress metadata: name: shopping-service namespace: whereami annotations: networking.gke.io/pre-shared-certs: "my-google-managed-cert" spec: template: spec: rules: - host: my-domain.gcp.com http: paths: - backend: serviceName: my-domain-svc servicePort: 8080
O manifesto anterior anexa o certificado ao MultiClusterIngress
para que ele possa encerrar o tráfego dos clusters de back-end do GKE.
O Google Cloud renovará automaticamente seu certificado
antes da expiração. As renovações ocorrem de forma transparente e não exigem
atualizações para a Entrada de vários clusters.
Protocolos de aplicativo
A conexão entre o proxy do balanceador de carga e seu aplicativo usa HTTP
por padrão. Ao usar a anotação networking.gke.io/app-protocols
, é possível configurar
o balanceador de carga para usar HTTPS ou HTTP/2 ao encaminhar solicitações para o
aplicativo. No campo annotation
do exemplo a seguir, http2
refere-se ao nome da porta MultiClusterService
e HTTP2
refere-se ao
protocolo que o balanceador de carga usa.
kind: MultiClusterService
metadata:
name: shopping-service
namespace: whereami
annotations:
networking.gke.io/app-protocols: '{"http2":"HTTP2"}'
spec:
template:
spec:
ports:
- port: 443
name: http2
BackendConfig
Consulte a seção acima sobre como configurar a anotação.
A seguir
- Leia a visão geral da rede GKE.
- Saiba mais sobre como configurar o balanceamento de carga HTTP com a Entrada.
- Implemente a entrada em vários clusters com HTTPS de ponta a ponta.