Neste tutorial, você verá como combinar o Anthos Service Mesh com o Cloud Load Balancing para expor aplicativos em uma malha de serviço aos clientes da Internet.
O Anthos Service Mesh é uma malha de serviço gerenciado e baseado no Istio. Ele oferece uma camada de comunicação padronizada, observável e de segurança aumentada para aplicativos. Não importa se você usa o Anthos Service Mesh, o Traffic Director ou o Istio, uma malha de serviço oferece uma plataforma de comunicação holística para os clientes que se comunicam na malha. No entanto, o desafio permanece em como conectar clientes que estão fora da malha aos aplicativos hospedados na malha.
É possível expor um aplicativo aos clientes de várias maneiras, dependendo de onde o cliente está. Neste tutorial, mostramos como expor um aplicativo aos clientes unindo o Cloud Load Balancing ao Anthos Service Mesh para integrar balanceadores de carga a uma malha de serviço. Este tutorial se destina a profissionais avançados que executam o Anthos Service Mesh. No entanto, ele também funciona para Istio no Google Kubernetes Engine.
Gateway de entrada da malha
O Istio 0.8 apresentou o gateway de entrada (em inglês) da malha que fornece um conjunto dedicado de proxies com portas que ficam expostas ao tráfego que vem de fora da malha de serviço. Esses proxies de entrada da malha permitem controlar o comportamento de exposição L4 separadamente do comportamento de roteamento de aplicativos. Os proxies também permitem aplicar o roteamento e a política ao tráfego externo da malha antes de chegar ao sidecar de um aplicativo. A entrada da malha define o tratamento de tráfego quando ele chega a um nó da malha. Antes, no entanto, os componentes externos precisam definir como o tráfego chega à malha.
Para gerenciar esse tráfego externo, você precisa de um balanceador de carga externo para a malha. Neste tutorial, o Google Cloud Load Balancing é provisionado por meio de recursos de entrada do GKE para automatizar a implantação. O exemplo canônico dessa configuração é um serviço de balanceamento de carga externo que, no caso do Google Cloud, implanta um balanceador de carga TCP/UDP público. Esse balanceador de carga aponta para os NodePorts de um cluster do GKE. Esses NodePorts expõem os pods de gateway de entrada do Istio, que roteiam o tráfego para proxies sidecar de malha downstream. O diagrama a seguir ilustra essa topologia. O balanceamento de carga do tráfego particular interno é semelhante a esta arquitetura, exceto pelo fato de que você implanta um balanceador de carga TCP/UDP interno.
O uso do balanceamento de carga transparente L4 com um gateway de entrada da malha oferece as seguintes vantagens:
- Esta configuração simplifica a implantação do balanceador de carga.
- O balanceador de carga fornece um IP virtual (VIP, na sigla em inglês) estável, uma verificação de integridade e uma distribuição de tráfego confiável quando ocorrem alterações no cluster, interrupções de nó ou de processo.
- Todas as regras de roteamento, terminação TLS e política de tráfego são processadas em um único local no gateway de entrada da malha.
Entrada e serviços do GKE
Há várias maneiras de fornecer acesso a aplicativos àqueles clientes que estão fora do cluster. Veja na tabela a seguir os componentes primitivos do Kubernetes disponíveis para implantar balanceadores de carga no Google Cloud. O tipo de balanceador de carga que você usa para expor aplicativos aos clientes dependerá muito se eles forem externos ou internos, que tipo de suporte de protocolo é necessário e se a malha de serviço abrange vários clusters do GKE ou se estão em um único cluster.
Qualquer um dos tipos de balanceador de carga na tabela a seguir pode expor aplicativos hospedados em malha, dependendo do caso de uso.
Recurso do GKE | Balanceador de carga baseado na nuvem | Características |
---|---|---|
Entrada para balanceadores de carga HTTP(S) externos | Balanceador de carga HTTP(S) externo |
Proxies L7 em pontos de presença (PoPs, na sigla em inglês) de extremidade do Google VIP público Escopo global Cluster único |
Entrada para balanceadores de carga HTTP(S) internos | Balanceador de carga HTTP(S) interno |
Proxies L7 dentro da rede de nuvem privada virtual (VPC) VIP particular Escopo regional Cluster único |
Serviço LoadBalancer externo |
Balanceador de carga de rede |
Passagem de L4 em PoPs de extremidade do Google VIP público Escopo regional Cluster único |
Serviço LoadBalancer interno |
Balanceador de carga TCP/UDP interno |
Passagem de L4 na rede de roteamento da VPC VIP particular Escopo regional Cluster único |
Entrada de vários clusters (vários clusters, entrada externa) | Balanceador de carga HTTP(S) externo |
Proxies L7 em PoPs de extremidade do Google VIP público Escopo global Vários clusters |
Embora o balanceador de carga padrão do Anthos Service Mesh seja o TCP/UDP externo, o foco deste tutorial é o balanceador de carga HTTP(S) externo. O balanceador de carga HTTP(S) externo oferece integração com serviços de extremidade, como o Identity-Aware Proxy (IAP), o Google Cloud Armor e o Cloud CDN, bem como uma rede distribuída globalmente de proxies de extremidade. Na próxima seção, descrevemos a arquitetura e as vantagens do uso de duas camadas de balanceamento de carga HTTP.
Entrada na nuvem e entrada da malha
A implantação do balanceamento de carga L7 externo fora da malha com uma camada de entrada da malha oferece vantagens significativas, especialmente para o tráfego da Internet. Mesmo que os gateways de entrada do Anthos Service Mesh e do Istio forneçam roteamento avançado e gerenciamento de tráfego na malha, algumas funções são melhor veiculadas na extremidade da rede. Aproveitar a rede na extremidade da Internet por meio do balanceador de carga HTTP(S) externo do Google Cloud pode oferecer benefícios significativos de desempenho, confiabilidade ou segurança em relação à entrada da malha. Esses benefícios incluem:
- Anúncio VIP global do Anycast e terminação TLS e HTTP distribuídos globalmente
- Defesa contra DDoS e filtragem de tráfego na extremidade com o Google Cloud Armor
- Funcionalidades do gateway da API com o IAP
- Criação e rotação automática de certificação pública com certificados gerenciados pelo Google
- Balanceamento de carga multirregional e de vários clusters na extremidade com o Ingress para vários clusters
Essa camada externa de balanceamento de carga L7 é chamada de entrada na nuvem porque ela é criada em balanceadores de carga gerenciados na nuvem, em vez de proxies auto-hospedados usados pela entrada da malha. A combinação de entrada na nuvem e entrada da malha utiliza recursos complementares da infraestrutura do Google Cloud e da malha. Veja no diagrama a seguir como combinar a entrada na nuvem e a entrada da malha para exibir na forma de duas camadas de balanceamento de carga no tráfego da Internet.
Nessa topologia, a camada de entrada na nuvem recebe tráfego de fora da malha de serviço e direciona esse tráfego à camada de entrada da malha. Em seguida, a camada de entrada da malha direciona o tráfego para os back-ends de aplicativos hospedados na malha.
Topologia de entrada na nuvem e da malha
Nesta seção, descrevemos os papéis complementares que cada camada de entrada ocupa quando são usados em conjunto. Esses papéis não são regras concretas, mas sim diretrizes que usam as vantagens de cada camada. É provável que as variações desse padrão sejam baseadas no seu caso de uso.
- Entrada do Cloud: quando emparelhada com a entrada da malha, a camada de entrada na nuvem é melhor usada para segurança de extremidade e balanceamento de carga global. A camada de entrada na nuvem é integrada à proteção contra DDoS, firewalls de nuvem, autenticação e produtos de criptografia na extremidade. Por isso, essa camada se destaca em executar esses serviços fora da malha. A lógica de roteamento costuma ser objetiva nessa camada, mas ela pode ser mais complexa para ambientes multirregionais e com vários clusters. Devido à função crucial dos balanceadores de carga voltados para a Internet, a camada de entrada na nuvem é provavelmente gerenciada por uma equipe de infraestrutura que tem controle exclusivo sobre como os aplicativos são expostos e protegidos na Internet. Esse controle também torna essa camada menos flexível e dinâmica do que uma infraestrutura orientada por desenvolvedores, uma consideração que pode afetar a quem e como você fornece acesso administrativo a essa camada.
- Entrada da malha: quando pareada com a entrada na nuvem, a camada de entrada da malha fornece um roteamento flexível parecido com o do aplicativo. Devido a essa flexibilidade, a entrada da malha é melhor que a entrada na nuvem, seguindo a lógica de roteamento complexa e a visibilidade no nível do aplicativo. A separação entre camadas de entrada também facilita aos proprietários de aplicativos na hora de controlar diretamente essa camada sem afetar outras equipes. Ao expor aplicativos da malha de serviço por meio de um balanceador de carga L4 em vez de L7, recomendamos que você encerre o TLS do cliente na camada de entrada dentro da malha para ajudar a proteger aplicativos.
Verificação de integridade
Uma das complexidades do uso de duas camadas do balanceamento de carga L7 é a verificação de integridade. Você precisa configurar cada balanceador de carga para verificar a integridade da próxima camada a fim de garantir que ela possa receber tráfego. A topologia do diagrama a seguir mostra como a entrada na nuvem verifica a integridade dos proxies de entrada da malha. Em contrapartida, a malha verifica a integridade dos back-ends do aplicativo.
Essa topologia tem as seguintes considerações:
- Entrada do Cloud: neste tutorial, você configura o balanceador de carga do Google Cloud por meio da entrada para verificar a integridade dos proxies de entrada da malha nas portas expostas da verificação de integridade. Se um proxy de malha estiver inativo ou se o cluster, a malha ou a região não estiverem disponíveis, o balanceador de carga do Google Cloud detectará essa condição e não enviará tráfego ao proxy da malha.
- Entrada da malha: no aplicativo de malha, você realiza verificações de integridade diretamente nos back-ends a fim de executar o balanceamento de carga e o gerenciamento de tráfego localmente.
Segurança
A topologia anterior envolve diversos elementos de segurança. Um dos elementos mais importantes é a forma de configurar a criptografia e implantar certificados. A Entrada para balanceador de carga HTTP(S) externo tem ampla integração com certificados gerenciados pelo Google. Essa integração provisiona automaticamente certificados públicos, anexa-os a um balanceador de carga e renova e alterna certificados por meio da interface declarativa do Entrada do GKE. Os clientes da Internet se autenticam nos certificados públicos e se conectam ao balanceador de carga externo como o primeiro salto na nuvem privada virtual (VPC).
O próximo salto, que fica entre o Google Front End (GFE) e o proxy de entrada da malha, é criptografado por padrão. A criptografia no nível da rede entre os GFEs e respectivos back-ends é aplicada automaticamente. No entanto, se os seus requisitos de segurança ditam que o proprietário da plataforma retém a propriedade das chaves de criptografia, será possível ativar o HTTP/2 com criptografia TLS entre a entrada do cluster (o GFE) e a entrada da malha (o proxy envoy). instância). Quando você ativa o HTTP/2 com criptografia TLS para esse caminho, é possível usar um certificado autoassinado ou público para criptografar o tráfego. Isso acontece porque o GFE não faz a autenticação nele. Essa camada adicional de criptografia é demonstrada neste guia. Para evitar o mau uso de certificados, não use o certificado público do balanceador de carga público em outro lugar. Em vez disso, recomendamos usar certificados diferentes na malha de serviço.
Se a malha de serviço exigir TLS, todo o tráfego será criptografado entre proxies sidecar e a entrada da malha. O diagrama a seguir ilustra a criptografia HTTPS do cliente para o balanceador de carga do Google Cloud, do balanceador de carga para o proxy de entrada da malha e do proxy de entrada para o proxy sidecar.
Objetivos
- Implantar um cluster do Google Kubernetes Engine (GKE) no Google Cloud.
- Implantar o Anthos Service Mesh baseado no Istio no cluster do GKE.
- Configurar a entrada do GKE para encerrar o tráfego HTTPS público e direcionar esse tráfego para aplicativos hospedados por malha de serviço.
- Implantar o aplicativo Online Boutique no cluster do GKE que você expõe aos clientes na Internet.
Custos
Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:
- Google Kubernetes Engine
- Compute Engine
- Cloud Load Balancing;
- Anthos Service Mesh
- Google Cloud Armor
- Cloud Endpoints
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.
Antes de começar
-
No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
No Console do Google Cloud, ative o Cloud Shell.
Todos os comandos de terminal deste tutorial são executados a partir do Cloud Shell.
Faça upgrade para a versão mais recente do Google Cloud CLI:
gcloud components update
Defina seu projeto padrão do Google Cloud:
export PROJECT=PROJECT export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)") gcloud config set project ${PROJECT}
Substitua
PROJECT
pelo ID do projeto que quer usar neste tutorial.Crie um diretório de trabalho:
mkdir -p ${HOME}/edge-to-mesh cd ${HOME}/edge-to-mesh export WORKDIR=`pwd`
Depois de concluir o tutorial, é possível excluir o diretório de trabalho.
Como criar clusters do GKE
Os recursos descritos neste tutorial exigem uma versão de cluster do GKE 1.16 ou mais recente.
No Cloud Shell, crie um novo arquivo
kubeconfig
. Esta etapa garante que você não crie conflitos com seu arquivokubeconfig
(padrão) atual.touch edge2mesh_kubeconfig export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
Defina as variáveis de ambiente no cluster do GKE:
export CLUSTER_NAME=edge-to-mesh export CLUSTER_LOCATION=us-west1-a
Ative a API do Google Kubernetes Engine.
gcloud
gcloud services enable container.googleapis.com
Config Connector
Este tutorial inclui recursos do Config Connector. É possível usar esses recursos para realizar as mesmas tarefas que você concluiu na guia
gcloud
. Para utilizar esses recursos, instale o Config Connector e aplique os recursos da maneira que funcionar melhor para seu ambiente.Use o manifesto
Services
a seguir:apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1 kind: Service metadata: annotations: cnrm.cloud.google.com/deletion-policy: "abandon" cnrm.cloud.google.com/disable-dependent-services: "false" name: container.googleapis.com spec: resourceID: container.googleapis.com projectRef: external: PROJECT
Criar um cluster do GKE.
gcloud
gcloud container clusters create ${CLUSTER_NAME} \ --machine-type=e2-standard-4 \ --num-nodes=4 \ --zone ${CLUSTER_LOCATION} \ --enable-ip-alias \ --workload-pool=${PROJECT}.svc.id.goog \ --release-channel rapid \ --addons HttpLoadBalancing \ --labels mesh_id=proj-${PROJECT_NUMBER}
Config Connector
Use os manifestos
ContainerCluster
eContainerNodePool
abaixo:apiVersion: container.cnrm.cloud.google.com/v1beta1 kind: ContainerNodePool metadata: annotations: cnrm.cloud.google.com/project-id: PROJECT name: edge-to-mesh spec: clusterRef: name: edge-to-mesh location: us-west1-a nodeConfig: machineType: e2-standard-4 nodeCount: 4 --- apiVersion: container.cnrm.cloud.google.com/v1beta1 kind: ContainerCluster metadata: annotations: cnrm.cloud.google.com/project-id: PROJECT cnrm.cloud.google.com/remove-default-node-pool: "true" labels: mesh_id: proj-PROJECT_NUMBER name: edge-to-mesh spec: addonsConfig: httpLoadBalancing: disabled: false location: us-west1-a initialNodeCount: 1 releaseChannel: channel: RAPID workloadIdentityConfig: workloadPool: PROJECT.svc.id.goog
Substitua
PROJECT_NUMBER
pelo valor da variável de ambientePROJECT_NUMBER
recuperada anteriormente.Para usar uma entrada na nuvem, é preciso ativar o complemento de balanceamento de carga HTTP. Os clusters do GKE têm o balanceamento de carga HTTP ativado por padrão. Não o desative.
Para usar o Anthos Service Mesh gerenciado, é preciso aplicar o rótulo
mesh_id
no cluster.Certifique-se de que o cluster está em execução:
gcloud container clusters list
A resposta será semelhante a:
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS edge-to-mesh us-west1-a v1.22.6-gke.300 35.233.195.59 e2-standard-4 v1.22.6-gke.300 4 RUNNING
Conecte-se ao cluster:
gcloud container clusters get-credentials ${CLUSTER_NAME} \ --zone ${CLUSTER_LOCATION} \ --project ${PROJECT}
Como instalar uma malha de serviço
Nesta seção, você configurará o Anthos Service Mesh gerenciado com a API de frota.
Ative as APIs necessárias:
gcloud
gcloud services enable mesh.googleapis.com
Config Connector
Use o manifesto
Services
a seguir:apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1 kind: Service metadata: annotations: cnrm.cloud.google.com/deletion-policy: "abandon" cnrm.cloud.google.com/disable-dependent-services: "false" name: mesh.googleapis.com spec: resourceID: mesh.googleapis.com projectRef: external: PROJECT
Ative o Anthos Service Mesh na frota:
gcloud
gcloud container fleet mesh enable
Config Connector
Use o manifesto
GKEHubFeature
a seguir:apiVersion: gkehub.cnrm.cloud.google.com/v1beta1 kind: GKEHubFeature metadata: name: servicemesh spec: projectRef: external: PROJECT location: global resourceID: servicemesh
Registre o cluster na frota:
gcloud
gcloud container fleet memberships register ${CLUSTER_NAME} \ --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME} \ --enable-workload-identity
Config Connector
Use o manifesto
GKEHubMembership
a seguir:apiVersion: gkehub.cnrm.cloud.google.com/v1beta1 kind: GKEHubMembership metadata: annotations: cnrm.cloud.google.com/project-id: PROJECT name: edge-to-mesh spec: location: global authority: issuer: https://container.googleapis.com/v1/projects/PROJECT/locations/us-west1-a/clusters/edge-to-mesh endpoint: gkeCluster: resourceRef: name: edge-to-mesh
Ative o gerenciamento automático do plano de controle e o plano de dados gerenciado:
gcloud
gcloud container fleet mesh update \ --management automatic \ --memberships ${CLUSTER_NAME}
Config Connector
Use o manifesto
GKEHubFeatureMembership
a seguir:apiVersion: gkehub.cnrm.cloud.google.com/v1beta1 kind: GKEHubFeatureMembership metadata: name: servicemesh-membership spec: projectRef: external: PROJECT_ID location: global membershipRef: name: edge-to-mesh featureRef: name: servicemesh mesh: management: MANAGEMENT_AUTOMATIC
Após alguns minutos, verifique se o status no plano de controle é
ACTIVE
:gcloud container fleet mesh describe
A saída será assim:
... membershipSpecs: projects/841956571429/locations/global/memberships/edge-to-mesh: mesh: management: MANAGEMENT_AUTOMATIC membershipStates: projects/841956571429/locations/global/memberships/edge-to-mesh: servicemesh: controlPlaneManagement: details: - code: REVISION_READY details: 'Ready: asm-managed-rapid' state: ACTIVE dataPlaneManagement: details: - code: OK details: Service is running. state: ACTIVE state: code: OK description: 'Revision(s) ready for use: asm-managed-rapid.' updateTime: '2022-09-29T05:30:28.320896186Z' name: projects/your-project/locations/global/features/servicemesh resourceState: state: ACTIVE ...
Como implantar a Entrada do GKE
Nas etapas a seguir, você implantará o balanceador de carga HTTP(S) externo por meio do controlador Entrada do GKE. O recurso Entrada automatiza o provisionamento do balanceador de carga, os certificados TLS e a verificação de integridade do back-end. Além disso, use o Cloud Endpoints para provisionar automaticamente um nome DNS público ao aplicativo.
Instalar um gateway de entrada
Como prática recomendada de segurança, recomendamos que você implante o gateway de entrada em um namespace diferente do plano de controle.
No Cloud Shell, crie um namespace
asm-ingress
dedicado:kubectl create namespace asm-ingress
Adicione um rótulo ao namespace
asm-ingress
:kubectl label namespace asm-ingress istio-injection=enabled
A saída será assim:
namespace/asm-ingress labeled
Rotular o namespace
asm-ingress
comistio-injection=enabled
instrui o Anthos Service Mesh a injetar automaticamente os proxies sidecar do Envoy quando um aplicativo é implantado.Execute o seguinte comando para criar o manifesto
Deployment
comoingress-deployment.yaml
:cat <<EOF > ingress-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: asm-ingressgateway namespace: asm-ingress spec: selector: matchLabels: asm: ingressgateway template: metadata: annotations: # This is required to tell Anthos Service Mesh to inject the gateway with the # required configuration. inject.istio.io/templates: gateway labels: asm: ingressgateway spec: securityContext: fsGroup: 1337 runAsGroup: 1337 runAsNonRoot: true runAsUser: 1337 containers: - name: istio-proxy securityContext: allowPrivilegeEscalation: false capabilities: drop: - all privileged: false readOnlyRootFilesystem: true image: auto # The image will automatically update each time the pod starts. resources: limits: cpu: 2000m memory: 1024Mi requests: cpu: 100m memory: 128Mi serviceAccountName: asm-ingressgateway --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: asm-ingressgateway namespace: asm-ingress spec: maxReplicas: 5 minReplicas: 3 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: asm-ingressgateway --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: asm-ingressgateway namespace: asm-ingress rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: asm-ingressgateway namespace: asm-ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: asm-ingressgateway subjects: - kind: ServiceAccount name: asm-ingressgateway --- apiVersion: v1 kind: ServiceAccount metadata: name: asm-ingressgateway namespace: asm-ingress EOF
Esse
Deployment
tem o próprioServiceAccount
comRole
eRoleBinding
associados, permitindo que o gateway acesse certificados.Implante
ingress-deployment.yaml
no cluster para criar o recursoDeployment
:kubectl apply -f ingress-deployment.yaml
A saída será assim:
deployment.apps/asm-ingressgateway configured role.rbac.authorization.k8s.io/asm-ingressgateway configured rolebinding.rbac.authorization.k8s.io/asm-ingressgateway configured serviceaccount/asm-ingressgateway created
Verifique se todas as implantações estão funcionando:
kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress
A saída será assim:
deployment.apps/asm-ingressgateway condition met
Execute o seguinte comando para criar o manifesto
Service
comoingress-service.yaml
:cat <<EOF > ingress-service.yaml apiVersion: v1 kind: Service metadata: name: asm-ingressgateway namespace: asm-ingress annotations: cloud.google.com/neg: '{"ingress": true}' cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}' cloud.google.com/app-protocols: '{"https":"HTTP2"}' # HTTP/2 with TLS encryption labels: asm: ingressgateway spec: ports: # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks - name: status-port port: 15021 protocol: TCP targetPort: 15021 # Any ports exposed in Gateway resources should be exposed here. - name: http2 port: 80 targetPort: 8080 - name: https port: 443 targetPort: 8443 selector: asm: ingressgateway type: ClusterIP EOF
Esse
Service
tem as seguintes anotações que definem parâmetros do balanceador de carga de Entrada quando ele é implantado:cloud.google.com/backend-config
refere-se ao nome de um recurso personalizado chamadoBackendConfig
. O controlador Entrada usaBackendConfig
para definir parâmetros no recursoBackendService
do Google Cloud. Use esse recurso na próxima etapa para definir parâmetros personalizados da verificação de integridade do Google Cloud.cloud.google.com/neg: '{"ingress": true}'
ativa os back-ends de Entrada (os proxies de entrada da malha, neste caso) para balanceamento de carga nativo de contêiner. Para um balanceamento de carga mais eficiente e estável, esses back-ends usam grupos de endpoints da rede (NEGs, na sigla em inglês) em vez de grupos de instâncias.cloud.google.com/app-protocols: '{"https":"HTTP2"}'
direciona o GFE para se conectar ao gateway de entrada da malha de serviço usando HTTP2 com TLS, conforme descrito em Entrada para balanceamento de carga HTTP(S) externo e HTTP(S) externo Visão geral do balanceamento de carga para uma camada extra de criptografia.
Implante
ingress-service.yaml
no cluster para criar o recursoService
:kubectl apply -f ingress-service.yaml
A saída será assim:
service/asm-ingressgateway created
Aplicar configurações do serviço de back-end
No Cloud Shell, execute o seguinte comando para criar o manifesto
BackendConfig
comoingress-backendconfig.yaml
:cat <<EOF > ingress-backendconfig.yaml apiVersion: cloud.google.com/v1 kind: BackendConfig metadata: name: ingress-backendconfig namespace: asm-ingress spec: healthCheck: requestPath: /healthz/ready port: 15021 type: HTTP securityPolicy: name: edge-fw-policy EOF
BackendConfig
é uma definição de recurso personalizada (CRD, na sigla em inglês) que define os parâmetros de back-end do balanceamento de carga do Entrada. Para uma lista completa dos parâmetros de back-end e front-end que podem ser configurados por meio do Entrada do GKE, consulte Recursos do Entrada.Neste tutorial, o manifesto
BackendConfig
especifica verificações de integridade personalizadas para os proxies de entrada da malha. O Anthos Service Mesh e o Istio expõem as verificações de integridade do proxy sidecar na porta15021
no caminho/healthz/ready
. Os parâmetros de verificação de integridade personalizados são necessários porque a porta de exibição (443
) dos proxies de entrada da malha é diferente da porta de verificação de integridade (15021
). O Entrada do GKE usa os parâmetros de verificação de integridade a seguir emBackendConfig
para configurar as verificações de integridade do balanceador de carga do Google Cloud. A política de segurança que ajuda a proteger o tráfego de balanceamento de carga contra diferentes tipos de ataques de rede também é referenciada.healthCheck.port
define a porta que recebe uma verificação de integridade pelo balanceador de carga do Google Cloud no endereço IP de cada pod.healthCheck.requestPath
define o caminho HTTP que recebe uma verificação de integridade na porta especificada.type
define o protocolo da verificação de integridade (neste caso, HTTP).securityPolicy.name
refere-se ao nome de uma política de segurança do Cloud Armor.
Implante
ingress-backendconfig.yaml
no cluster para criar o recursoBackendConfig
:kubectl apply -f ingress-backendconfig.yaml
A resposta será semelhante a:
backendconfig.cloud.google.com/ingress-backendconfig created
Os parâmetros
BackendConfig
e as anotações do Serviçoasm-ingressgateway
não são aplicados a um balanceador de carga do Google Cloud até que o recurso Entrada seja implantado. A implantação do Entrada vincula todos esses recursos.
Definir políticas de segurança
O Google Cloud Armor fornece proteção contra DDoS e políticas de segurança personalizáveis que podem ser anexadas a um balanceador de carga por meio de recursos de Entrada. Nas etapas a seguir, você criará uma política de segurança que usa regras pré-configuradas para bloquear ataques de scripting em vários locais (XSS). Essa regra ajuda a bloquear o tráfego que corresponde a assinaturas de ataque conhecidas, mas permite qualquer outro tráfego. Seu ambiente pode usar regras diferentes dependendo da carga de trabalho.
gcloud
No Cloud Shell, crie uma política de segurança chamada
edge-fw-policy
:gcloud compute security-policies create edge-fw-policy \ --description "Block XSS attacks"
Crie uma regra de política de segurança que use os filtros XSS pré-configurados:
gcloud compute security-policies rules create 1000 \ --security-policy edge-fw-policy \ --expression "evaluatePreconfiguredExpr('xss-stable')" \ --action "deny-403" \ --description "XSS attack filtering"
Config Connector
Use o manifesto ComputeSecurityPolicy
a seguir:
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeSecurityPolicy
metadata:
annotations:
cnrm.cloud.google.com/project-id: PROJECT_ID
name: edge-fw-policy
spec:
rule:
- action: allow
description: "Default rule"
match:
versionedExpr: SRC_IPS_V1
config:
srcIpRanges:
- "*"
priority: 2147483647
- action: deny-403
description: "XSS attack filtering"
match:
expr:
expression: "evaluatePreconfiguredExpr('xss-stable')"
priority: 1000
O edge-fw-policy
foi referenciado por ingress-backendconfig
na seção
anterior. Quando o recurso Entrada é implantado, ele vincula essa política de segurança
ao balanceador de carga para ajudar a proteger os back-ends do
Serviço asm-ingressgateway
.
Configurar o endereçamento IP e o DNS
No Cloud Shell, crie um IP estático global para o balanceador de carga do Google Cloud:
gcloud
gcloud compute addresses create ingress-ip --global
Config Connector
Use o manifesto
ComputeAddress
a seguir:apiVersion: compute.cnrm.cloud.google.com/v1beta1 kind: ComputeAddress metadata: annotations: cnrm.cloud.google.com/project-id: PROJECT_ID name: ingress-ip spec: location: global
Esse IP estático é usado pelo recurso Entrada e permite que o IP permaneça igual, mesmo se o balanceador de carga externo for alterado.
Consiga o endereço IP estático:
export GCLB_IP=$(gcloud compute addresses describe ingress-ip --global --format "value(address)") echo ${GCLB_IP}
Para criar um mapeamento estável e legível para o IP de Entrada, é preciso ter um registro DNS público. Use o provedor de DNS e a automação que quiser. Neste tutorial, o Endpoints é usado em vez da criação de uma zona de DNS gerenciada. O Endpoints fornece gratuitamente um registro DNS gerenciado pelo Google para um IP público.
Execute o seguinte comando para criar o arquivo de especificação YAML chamado
dns-spec.yaml
:cat <<EOF > dns-spec.yaml swagger: "2.0" info: description: "Cloud Endpoints DNS" title: "Cloud Endpoints DNS" version: "1.0.0" paths: {} host: "frontend.endpoints.${PROJECT}.cloud.goog" x-google-endpoints: - name: "frontend.endpoints.${PROJECT}.cloud.goog" target: "${GCLB_IP}" EOF
A especificação YAML define o registro DNS público no formato
frontend.endpoints.${PROJECT}.cloud.goog
, em que${PROJECT}
é o número exclusivo do projeto.Implante o arquivo
dns-spec.yaml
no projeto do Google Cloud:gcloud endpoints services deploy dns-spec.yaml
O resultado será assim:
Operation finished successfully. The following command can describe the Operation details: gcloud endpoints operations describe operations/rollouts.frontend.endpoints.edge2mesh.cloud.goog:442b2b38-4aee-4c60-b9fc-28731657ee08 Service Configuration [2021-11-14r0] uploaded for service [frontend.endpoints.edge2mesh.cloud.goog]
Agora que o IP e o DNS estão configurados, é possível gerar um certificado público para proteger o front-end do Entrada. O Entrada do GKE é compatível com certificados gerenciados pelo Google como recursos do Kubernetes, o que permite que você os provisione por meios declarativos.
Provisionar um certificado TLS
No Cloud Shell, execute o seguinte comando para criar o manifesto
ManagedCertificate
comomanaged-cert.yaml
:cat <<EOF > managed-cert.yaml apiVersion: networking.gke.io/v1 kind: ManagedCertificate metadata: name: gke-ingress-cert namespace: asm-ingress spec: domains: - "frontend.endpoints.${PROJECT}.cloud.goog" EOF
Esse arquivo YAML especifica que o nome DNS criado por meio do Endpoints é usado para provisionar um certificado público. Como o Google gerencia totalmente o ciclo de vida desses certificados públicos, eles são gerados e alternados regularmente, sem intervenção direta do usuário.
Implante o arquivo
managed-cert.yaml
no cluster do GKE:kubectl apply -f managed-cert.yaml
A resposta será semelhante a:
managedcertificate.networking.gke.io/gke-ingress-cert created
Inspecione o recurso
ManagedCertificate
para verificar o progresso da geração do certificado:kubectl describe managedcertificate gke-ingress-cert -n asm-ingress
A resposta será semelhante a:
Name: gke-ingress-cert Namespace: asm-ingress Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"networking.gke.io/v1","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"gke-ingress-cert","namespace":"... API Version: networking.gke.io/v1 Kind: ManagedCertificate Metadata: Creation Timestamp: 2020-08-05T20:44:49Z Generation: 2 Resource Version: 1389781 Self Link: /apis/networking.gke.io/v1/namespaces/asm-ingress/managedcertificates/gke-ingress-cert UID: d74ec346-ced9-47a8-988a-6e6e9ddc4019 Spec: Domains: frontend.endpoints.edge2mesh.cloud.goog Status: Certificate Name: mcrt-306c779e-8439-408a-9634-163664ca6ced Certificate Status: Provisioning Domain Status: Domain: frontend.endpoints.edge2mesh.cloud.goog Status: Provisioning Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Create 44s managed-certificate-controller Create SslCertificate mcrt-306c779e-8439-408a-9634-163664ca6ced
Quando o certificado estiver pronto, o
Certificate Status
seráActive
.
Implantar o recurso Entrada
No Cloud Shell, execute o seguinte comando para criar o manifesto
Ingress
comoingress.yaml
:cat <<EOF > ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: gke-ingress namespace: asm-ingress annotations: kubernetes.io/ingress.allow-http: "false" kubernetes.io/ingress.global-static-ip-name: "ingress-ip" networking.gke.io/managed-certificates: "gke-ingress-cert" kubernetes.io/ingress.class: "gce" spec: defaultBackend: service: name: asm-ingressgateway port: number: 443 rules: - http: paths: - path: /* pathType: ImplementationSpecific backend: service: name: asm-ingressgateway port: number: 443 EOF
Esse manifesto define um recurso Entrada que une todos os recursos anteriores. O manifesto especifica os seguintes campos:
kubernetes.io/ingress.allow-http: "false"
desativa o tráfego HTTP na porta80
do balanceador de carga do Google Cloud. Isso impede efetivamente que os clientes se conectem com o tráfego não criptografado porque a porta443
detecta somente HTTPS, e a porta80
está desativada.kubernetes.io/ingress.global-static-ip-name: "ingress-ip"
vincula o endereço IP criado anteriormente ao balanceador de carga. Esse link permite que o endereço IP seja criado separadamente do balanceador de carga. Assim, o endereço IP poderá ser reutilizado separadamente do ciclo de vida do balanceador de carga.networking.gke.io/managed-certificates: "gke-ingress-cert"
vincula esse balanceador de carga ao recurso de certificado SSL gerenciado pelo Google criado anteriormente.
Implante
ingress.yaml
no cluster:kubectl apply -f ingress.yaml
Inspecione o recurso Entrada para verificar o progresso da implantação do balanceador de carga:
kubectl describe ingress gke-ingress -n asm-ingress
A resposta será semelhante a:
... Annotations: ingress.kubernetes.io/https-forwarding-rule: k8s2-fs-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor ingress.kubernetes.io/ssl-cert: mcrt-306c779e-8439-408a-9634-163664ca6ced networking.gke.io/managed-certificates: gke-ingress-cert kubernetes.io/ingress.global-static-ip-name: ingress-ip ingress.gcp.kubernetes.io/pre-shared-cert: mcrt-306c779e-8439-408a-9634-163664ca6ced ingress.kubernetes.io/backends: {"k8s-be-31610--07bdde06b914144a":"HEALTHY","k8s1-07bdde06-asm-ingress-asm-ingressgateway-443-228c1881":"HEALTHY"} ingress.kubernetes.io/forwarding-rule: k8s2-fr-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor ingress.kubernetes.io/https-target-proxy: k8s2-ts-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor ingress.kubernetes.io/target-proxy: k8s2-tp-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor ingress.kubernetes.io/url-map: k8s2-um-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor ...
O recurso Entrada está pronto quando as anotações
ingress.kubernetes.io/backends
indicam que os back-ends sãoHEALTHY
. As anotações também mostram os nomes de diferentes recursos do Google Cloud provisionados, incluindo serviços de back-end, certificados SSL e proxies de destino HTTPS.
Instalar o certificado de gateway de entrada autoassinado
Nas etapas a seguir, você gera e instala um certificado (como um recurso secret
do Kubernetes) que permite ao GFE estabelecer uma conexão TLS com o gateway de entrada da malha de serviço. Para mais detalhes sobre os requisitos do certificado do gateway de entrada, consulte o guia seguro de considerações do protocolo de back-end.
No Cloud Shell, crie a chave privada e o certificado usando
openssl
:openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \ -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \ -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \ -out frontend.endpoints.${PROJECT}.cloud.goog.crt
Crie o
Secret
no namespaceasm-ingress
:kubectl -n asm-ingress create secret tls edge2mesh-credential \ --key=frontend.endpoints.${PROJECT}.cloud.goog.key \ --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
Configurar o gateway de entrada para balanceamento de carga externo
Nas etapas a seguir, você criará um recurso compartilhado Gateway
no namespace asm-ingress
. Os gateways geralmente são de propriedade dos administradores da plataforma ou da equipe de administradores de rede. Assim, o recurso Gateway
é criado no namespace asm-ingress
de propriedade do administrador da plataforma e pode ser usado em outros namespaces com suas próprias entradas VirtualService
.
No Cloud Shell, execute o seguinte comando para criar o manifesto
Gateway
comoingress-gateway.yaml
:cat <<EOF > ingress-gateway.yaml apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: asm-ingressgateway namespace: asm-ingress spec: selector: asm: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below tls: mode: SIMPLE credentialName: edge2mesh-credential EOF
É necessário usar a entrada de caractere curinga
*
no campohosts
doGateway
. O GCLB não usa a extensão SNI nos back-ends. O uso da entrada de caractere curinga envia o pacote criptografado (do GCLB) para o gateway de entrada do ASM. O gateway de Entrada do ASM descriptografa o pacote e usa o cabeçalho de host HTTP no pacote descriptografado para tomar decisões de roteamento, com base nas entradasVirtualService
.Implante
ingress-gateway.yaml
no cluster:kubectl apply -f ingress-gateway.yaml
A saída será assim:
gateway.networking.istio.io/asm-ingressgateway created
Como instalar o aplicativo de exemplo Online Boutique
No Cloud Shell, crie um namespace
onlineboutique
dedicado:kubectl create namespace onlineboutique
Adicione um rótulo ao namespace
onlineboutique
:kubectl label namespace onlineboutique istio-injection=enabled
A saída será assim:
namespace/onlineboutique labeled
Rotular o namespace
onlineboutique
comistio-injection=enabled
instrui o Anthos Service Mesh a injetar automaticamente os proxies sidecar do Envoy quando um aplicativo é implantado.Faça o download dos arquivos YAML do Kubernetes para o aplicativo de exemplo Online Boutique:
curl -LO \ https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml
Implante o aplicativo do Online Boutique:
kubectl apply -f kubernetes-manifests.yaml -n onlineboutique
A resposta será semelhante a:
deployment.apps/frontend created service/frontend created service/frontend-external created ...
Verifique se todas as implantações estão funcionando:
kubectl get pods -n onlineboutique
A saída será assim:
NAME READY STATUS RESTARTS AGE adservice-d854d8786-fjb7q 2/2 Running 0 3m cartservice-85b5d5b4ff-8qn7g 2/2 Running 0 2m59s checkoutservice-5f9bf659b8-sxhsq 2/2 Running 0 3m1s ...
Execute o seguinte comando para criar o manifesto
VirtualService
comofrontend-virtualservice.yaml
:cat <<EOF > frontend-virtualservice.yaml apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: frontend-ingress namespace: onlineboutique spec: hosts: - "frontend.endpoints.${PROJECT}.cloud.goog" gateways: - asm-ingress/asm-ingressgateway http: - route: - destination: host: frontend port: number: 80 EOF
Observe que o
VirtualService
é criado no namespace do aplicativo (onlineboutique
). Em geral, o proprietário do aplicativo decide e configura como e qual tráfego será roteado para o aplicativofrontend
para que oVirtualService
seja implantado pelo proprietário do aplicativo.Implante
frontend-virtualservice.yaml
no cluster:kubectl apply -f frontend-virtualservice.yaml
A saída será assim:
virtualservice.networking.istio.io/frontend-virtualservice created
Acesse o seguinte link:
echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
Seu front-end do Online Boutique é exibido.
Para exibir os detalhes do certificado, clique em
Ver informações do site na barra de endereço do seu navegador e, depois, clique em Certificado (válido).O visualizador de certificados exibe detalhes do certificado gerenciado, incluindo a data de validade e quem emitiu o certificado.
Agora você tem um balanceador de carga HTTPS global que serve como front-end para seu aplicativo hospedado pela malha de serviço.
Limpeza
Após concluir este tutorial, é possível limpar os recursos que você criou no Google Cloud para que não sejam faturados no futuro. É possível excluir todo o projeto ou remover recursos do cluster e, depois, excluir o cluster.
Excluir o projeto
- No Console do Google Cloud, acesse a página Gerenciar recursos.
- Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
- Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.
Excluir recursos individuais
Se você quiser manter o projeto do Google Cloud usado neste tutorial, exclua os recursos individuais:
Exclua o recurso Entrada:
kubectl delete -f ingress.yaml
Exclua o certificado gerenciado:
kubectl delete -f managed-cert.yaml
Exclua a entrada DNS do Endpoints:
gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"
A resposta será semelhante a:
Are you sure? This will set the service configuration to be deleted, along with all of the associated consumer information. Note: This does not immediately delete the service configuration or data and can be undone using the undelete command for 30 days. Only after 30 days will the service be purged from the system.
Quando for solicitado continuar, digite Y.
A resposta será semelhante a:
Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete... Operation finished successfully. The following command can describe the Operation details: gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5
Exclua o endereço IP estático:
gcloud compute addresses delete ingress-ip --global
A resposta será semelhante a:
The following global addresses will be deleted: - [ingress-ip]
Quando for solicitado continuar, digite Y.
A resposta será semelhante a:
Deleted [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
Exclua o cluster do GKE:
gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
A seguir
- Saiba mais sobre mais recursos oferecidos pelo Entrada do GKE que podem ser usados com sua malha de serviço.
- Saiba mais sobre os diferentes tipos de balanceamento de carga na nuvem disponíveis para o GKE.
- Saiba mais sobre os recursos e as funcionalidades oferecidas pelo Anthos Service Mesh.
- Veja como implantar o Entrada em vários clusters do GKE para balanceamento de carga multirregional.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.