Nesta página, mostramos como criar um serviço do Kubernetes respaldado por um
grupo de endpoints de rede (NEG, na sigla em inglês)
GCE_VM_IP_PORT
zonal em um Cluster nativo de VPC
do Google Kubernetes Engine (GKE).
Consulte Balanceamento de carga nativo de contêiner para informações sobre os benefícios, os requisitos e as limitações desse recurso.
Visão geral
Um NEG representa um grupo
de endpoints. O GKE é compatível com NEGs independentes do
tipo GCE_VM_IP_PORT
. Os NEGs GCE_VM_IP_PORT
são compatíveis com endpoints usando o
endereço IP interno primário da VM ou um endereço IP de um dos intervalos de IP
do alias.
No contexto de um cluster nativo de VPC do GKE usando NEGs independentes, cada endpoint é um endereço IP do pod e uma porta de destino. Os endereços IP do pod são provenientes do intervalo de IP do alias do nó para pods, que vem do intervalo de endereços IP secundário da sub-rede do cluster para pods.
O GKE fornece um controlador NEG para gerenciar a associação de
NEGs GCE_VM_IP_PORT
. É possível adicionar os NEGs que ele cria como back-ends aos
serviços de back-end para balanceadores de carga configurados fora da
API GKE.
O diagrama a seguir descreve como os objetos da API Kubernetes correspondem aos objetos do Compute Engine.
Entrada com NEGs
Quando os NEGs são usados com a Entrada do GKE, o controlador da Entrada facilita a criação de todos os aspectos do balanceador de carga. Isso inclui a criação de endereço IP virtual, regras de encaminhamento, verificações de integridade, regras de firewall e muito mais.
A Entrada é a maneira recomendada de usar o balanceamento de carga nativo de contêiner, porque tem muitos recursos que simplificam o gerenciamento de NEGs. Os NEGs independentes são uma opção quando os NEGs gerenciados pela Entrada não atendem ao caso de uso.
NEGs independentes
Quando os NEGs são implantados com balanceadores de carga provisionados por algo diferente da Entrada, eles são considerados independentes. Os NEGs independentes são implantados e gerenciados por meio do controlador de NEG, mas as regras de encaminhamento, as verificações de integridade e outros objetos de balanceamento de carga são implantados manualmente.
Os NEGs independentes não entram em conflito com o balanceamento de carga nativo do contêiner da Entrada.
A ilustração a seguir mostra as diferenças na maneira como os objetos de balanceamento de carga são implantados em cada cenário:
Como evitar o vazamento de NEGs
Com os NEGs independentes, você é responsável pelo gerenciamento dos ciclos de vida dos NEGs e dos recursos que compõem o balanceador de carga. O vazamento de NEGs pode ocorrer das seguintes maneiras:
- Quando um serviço do GKE for excluído, o NEG associado não será coletado como lixo se ele ainda for referenciado por um serviço de back-end. Desreferencie o NEG do serviço de back-end para permitir a exclusão do NEG.
- Os NEGs independentes não são excluídos quando um cluster é excluído.
Casos de uso de NEGs independentes
Os NEGs independentes têm vários usos essenciais. Eles são muito flexíveis. Isso é diferente em relação à Entrada (usada com ou sem NEGs) que define um conjunto específico de objetos de balanceamento de carga que foram escolhidos a fim de facilitar o uso.
Os casos de uso de NEGs independentes incluem:
Serviços heterogêneos de contêineres e VMs
Os NEGs podem conter endereços IP da VM e do contêiner. Isso significa que um endereço IP virtual pode apontar para um back-end que consiste em cargas de trabalho do Kubernetes e que não são do Kubernetes. Isso também pode ser usado para migrar cargas de trabalho atuais para um cluster do GKE.
Os NEGs independentes podem apontar para IPs de VM, o que possibilita a configuração manual dos balanceadores de carga com o objetivo de apontar para back-ends compostos por VMs e contêineres no mesmo VIP do serviço.
Controladores da Entrada personalizados
É possível usar um controlador personalizado da Entrada (ou nenhum controlador da Entrada) para configurar balanceadores de carga que visam NEGs independentes.
Como usar o Cloud Service Mesh com o GKE
Use o Cloud Service Mesh com o GKE. O Cloud Service Mesh usa NEGs independentes para fornecer balanceamento de carga nativo de contêiner para a malha de serviço gerenciada.
Usar balanceadores de carga de rede de proxy externo com o GKE
É possível usar NEGs independentes para balancear a carga diretamente para contêineres com o balanceador de carga Proxy de rede externo que não é compatível nativamente com Kubernetes/GKE.
Prontidão do pod
Os portões de prontidão são um recurso de extensibilidade do Kubernetes que permite a injeção de feedback ou sinais extras no PodStatus para permitir que o pod migre para o estado de prontidão. O controlador de NEG gerencia um portão de prontidão personalizado para garantir que o caminho de rede completo, desde o balanceador de carga do Compute Engine até o pod, seja funcional. Os portões de prontidão do pod no GKE são explicados no balanceamento de carga nativo de contêiner.
A Entrada com NEGs implanta e gerencia verificações de integridade do Compute Engine em nome do balanceador de carga. No entanto, os NEGs independentes não fazem suposições sobre as verificações de integridade do Compute Engine porque espera-se que eles sejam implantados e gerenciados separadamente. As verificações de integridade do Compute Engine sempre precisam ser configuradas com o balanceador de carga para impedir que o tráfego seja enviado para os back-ends que não estão prontos para recebê-lo. Se não houver status de verificação de integridade associado ao NEG (normalmente porque nenhuma verificação de integridade está configurada), o controlador de NEG marcará o valor do portão de prontidão do pod como "verdadeiro" quando o endpoint correspondente estiver programado no NEG.
Requisitos
O cluster precisa ser nativo de VPC. Para saber mais, consulte Como criar um cluster nativo de VPC.
O cluster precisa ter o complemento HttpLoadBalancing
ativado.
Os clusters do GKE têm o complemento HttpLoadBalancing
ativado
por padrão.
Antes de começar
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ativar a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa,
instale e, em seguida,
inicialize a
CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update
.
Como usar NEGs independentes
As instruções a seguir mostram como usar NEGs independentes com um balanceador de carga HTTP externo no GKE.
Crie os seguintes objetos:
- Uma implantação que cria e gerencia pods.
- Um serviço que cria um NEG.
- Um balanceador de carga criado com a API Compute Engine. Isso é diferente do uso de NEGs com a Entrada. Nesse caso, a Entrada cria e configura um balanceador de carga para você. Nos NEGs independentes, você é responsável por associar o NEG e o serviço de back-end para conectar os pods ao balanceador de carga. O balanceador de carga consiste em vários componentes, mostrados no diagrama a seguir:
Criar um cluster nativo de VPC
Os clusters do Autopilot são nativos de VPC por padrão, portanto, você pode pular para Implantar uma carga de trabalho.
Para clusters padrão, crie um cluster nativo de VPC na
zona us-central1-a
:
gcloud container clusters create neg-demo-cluster \
--create-subnetwork="" \
--network=default \
--zone=us-central1-a
Crie uma implantação
Os manifestos de exemplo a seguir especificam as implantações que executam três instâncias de um servidor HTTP em contêiner. O servidor HTTP responde a solicitações com o nome do host do servidor de aplicativos, o nome do pod em que o servidor está sendo executado.
Recomenda-se o uso de cargas de trabalho que utilizem o feedback de prontidão do pod.
Como usar o feedback de prontidão do pod
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: replicas: 3 selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname
Como usar o atraso fixado no código
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready replicas: 3 selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname
Salve este manifesto como neg-demo-app.yaml
e, em seguida, crie a implantação executando o seguinte comando:
kubectl apply -f neg-demo-app.yaml
Crie um serviço.
O manifesto a seguir especifica um serviço em que:
- Qualquer pod com o rótulo
run: neg-demo-app
é membro desse serviço. - O serviço tem um campo ServicePort com a porta 80.
- A anotação
cloud.google.com/neg
especifica que a porta 80 será associada a um NEG. O campo opcionalname
especifica que o NEG será nomeadoNEG_NAME
. Se o camponame
for omitido, um nome exclusivo será gerado automaticamente. Consulte Como nomear NEGs para mais detalhes. - Cada pod membro precisa ter um contêiner que faça detecções na porta TCP 9376.
apiVersion: v1
kind: Service
metadata:
name: neg-demo-svc
annotations:
cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
spec:
type: ClusterIP
selector:
run: neg-demo-app # Selects Pods labelled run: neg-demo-app
ports:
- port: 80
protocol: TCP
targetPort: 9376
Substitua NEG_NAME
pelo nome do NEG. O nome do NEG precisa ser
exclusivo na região dele.
Salve este manifesto como neg-demo-svc.yaml
e, em seguida, crie o serviço executando o seguinte comando:
kubectl apply -f neg-demo-svc.yaml
Um NEG é criado poucos minutos após a criação do serviço.
Tipos de serviço
Embora este exemplo use um serviço ClusterIP
, todos os cinco tipos de
Serviço
são compatíveis com NEGs independentes. Recomendamos o tipo padrão, ClusterIP
.
Como nomear NEGs
Nas versões 1.18.18-gke.1200 e posteriores do GKE, é possível especificar um nome personalizado para os NEGs, ou o GKE pode gerar um nome automaticamente. As versões anteriores do GKE são compatíveis apenas com nomes de NEG gerados automaticamente.
O GKE cria um NEG em cada zona usada pelo cluster. Todos os NEGs usam o mesmo nome.
Como especificar um nome
Especificar um nome de NEG personalizado simplifica a configuração do balanceador de carga porque você sabe com antecedência o nome e as zonas dos NEGs. Os nomes de NEGs personalizados precisam atender aos seguintes requisitos:
- ser exclusivo para a zona do cluster para clusters zonais ou exclusivo para a região para clusters regionais;
- não pode corresponder ao nome de qualquer NEG que não tenha sido criado pelo controlador de NEG do GKE.
- Não pode conter sublinhados.
Use o campo name
na anotação cloud.google.com/neg
do Serviço para
especificar um nome de NEG:
cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
Substitua NEG_NAME
pelo nome do NEG. O nome do NEG precisa ser
exclusivo na região dele.
Como usar um nome gerado automaticamente
Os nomes de NEG
gerados automaticamente têm exclusividade garantida. Para usar um
nome gerado automaticamente, omita o campo name
:
cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
O nome gerado automaticamente tem o seguinte formato:
k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH
Como correlacionar portas a vários NEGs
Um serviço pode fazer a detecção em mais de uma porta. Por definição, os NEGs têm apenas um único endereço IP e porta. Isso significa que, se você especificar um serviço com várias portas, ele criará um NEG para cada porta.
O formato da anotação cloud.google.com/neg
é:
cloud.google.com/neg: '{
"exposed_ports":{
"SERVICE_PORT_1":{},
"SERVICE_PORT_2":{},
"SERVICE_PORT_3":{},
...
}
}'
Neste exemplo, cada instância de SERVICE_PORT_N
é um número de porta distinto que se refere às portas de serviço atuais do serviço. Para cada porta de serviço listada, o controlador de NEG cria um NEG em cada zona ocupada pelo cluster.
Recuperar status de NEG
Use o seguinte comando para recuperar os status dos serviços do cluster:
kubectl get service neg-demo-svc -o yaml
O resultado será assim:
cloud.google.com/neg-status: '{
"network-endpoint-groups":{
"SERVICE_PORT_1": "NEG_NAME_1",
"SERVICE_PORT_2": "NEG_NAME_2",
...
},
"zones":["ZONE_1", "ZONE_2", ...]
}
Nessa saída, cada elemento no mapeamento network-endpoint-groups
é uma porta de serviço
(como SERVICE_PORT_1
) e o nome dos NEGs
gerenciados correspondentes (como NEG_NAME_1
). A lista zones
contém todas as zonas (como ZONE_1
) que têm um NEG.
O resultado será assim:
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
labels:
run: neg-demo-app
name: neg-demo-app
namespace: default
selfLink: /api/v1/namespaces/default/services/neg-demo-app
...
spec:
clusterIP: 10.0.14.252
ports:
- port: 80
protocol: TCP
targetPort: 9376
selector:
run: neg-demo-app
sessionAffinity: None
status:
loadBalancer: {}
Neste exemplo, a anotação mostra que a porta de serviço 80 está exposta aos NEGs denominados k8s1-cca197ad-default-neg-demo-app-80-4db81e02
.
Validar criação de NEG
Um NEG é criado poucos minutos após a criação do serviço. Se houver pods que correspondam ao rótulo especificado no manifesto do serviço, então, na criação, o NEG conterá os IPs dos pods.
Há duas maneiras de verificar se o NEG foi criado e se está configurado
corretamente. No GKE 1.18.6-gke.6400 e posterior, um recurso personalizado
ServiceNetworkEndpointGroup
armazena informações de status sobre NEGs criados pelo
controlador de Serviço. Nas versões anteriores, é preciso inspecionar os NEGs
diretamente.
O recurso ServiceNetworkEndpointGroup
Liste os NEGs de um cluster recebendo todos os recursos ServiceNetworkEndpointGroup
:
kubectl get svcneg
Observe o status de um NEG verificando o status do recurso ServiceNetworkEndpointGroup
:
kubectl get svcneg NEG_NAME -o yaml
Substitua NEG_NAME
pelo nome do NEG individual que você quer inspecionar.
A saída desse comando inclui uma seção de status que pode conter mensagens de erro. Alguns erros são relatados como um evento de serviço. Para mais detalhes, consulte o objeto de serviço:
kubectl describe service SERVICE_NAME
Substitua SERVICE_NAME
pelo nome do Serviço relevante.
Para verificar se o controlador de NEG está sincronizando com êxito, confira o
campo de status do recurso ServiceNetworkEndpointGroup
para uma condição com
type:Synced
. A hora da sincronização mais recente está no campo
status.lastSyncTime
.
Os recursos ServiceNetworkEndpointGroup
só existem no GKE versão
1.18 e posteriores.
Como inspecionar NEGs diretamente
Verifique se o NEG existe listando os NEGs no seu projeto do Google Cloud e verificando se um NEG corresponde ao serviço que você criou. O nome do NEG tem o seguinte formato:
k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH
Use o seguinte comando para listar NEGs:
gcloud compute network-endpoint-groups list
O resultado será assim:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f ZONE_NAME GCE_VM_IP_PORT 3
Essa saída mostra que SIZE
do NEG é 3, o que significa que ele tem três endpoints que correspondem aos três pods na implantação.
Identifique os endpoints individuais com o seguinte comando:
gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME
Substitua NEG_NAME
pelo nome do NEG em que você
quer exibir os endpoints individuais.
A saída mostra três endpoints. Cada um deles tem um endereço IP e uma porta do pod:
INSTANCE IP_ADDRESS PORT
gke-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.43 9376
gke-cluster-3-default-pool-4cc71a15-qlpf 10.12.1.44 9376
gke-cluster-3-default-pool-4cc71a15-w9nk 10.12.2.26 9376
Como anexar um balanceador de carga de aplicativo externo a NEGs independentes
É possível usar NEGs como back-end para um balanceador de carga de aplicativo externo usando a API Compute Engine.
Crie uma regra de firewall. Os balanceadores de carga precisam acessar os endpoints do cluster para realizar verificações de integridade. Este comando cria uma regra de firewall para permitir o acesso:
gcloud compute firewall-rules create fw-allow-health-check-and-proxy \ --network=NETWORK_NAME \ --action=allow \ --direction=ingress \ --target-tags=GKE_NODE_NETWORK_TAGS \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:9376
Substitua:
NETWORK_NAME
: a rede em que o cluster é executado;GKE_NODE_NETWORK_TAGS
: as tags de rede nos nós do GKE.
Se você não criou tags de rede personalizadas para seus nós, o GKE gerará tags automaticamente. É possível procurar essas tags geradas executando o seguinte comando:
gcloud compute instances describe INSTANCE_NAME
Substitua
INSTANCE_NAME
pelo nome da instância de VM do host do Compute Engine que executa o nó do GKE. Por exemplo, a saída na seção anterior exibe os nomes das instâncias na colunaINSTANCE
dos nós do GKE. Para clusters padrão, também é possível executargcloud compute instances list
para listar todas as instâncias no projeto.Crie um endereço IP virtual global para o balanceador de carga:
gcloud compute addresses create hostname-server-vip \ --ip-version=IPV4 \ --global
Crie uma verificação de integridade. É usado pelo balanceador de carga para detectar a atividade de endpoints individuais no NEG.
gcloud compute health-checks create http http-basic-check \ --use-serving-port
Crie um serviço de back-end que especifique que esse é um balanceador de carga de aplicativo externo global:
gcloud compute backend-services create my-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
Crie um mapa de URL e um proxy de destino para o balanceador de carga. Esse exemplo é muito simples porque o aplicativo
serve_hostname
usado neste guia tem um único endpoint e não apresenta URLs.gcloud compute url-maps create web-map \ --default-service my-bes
gcloud compute target-http-proxies create http-lb-proxy \ --url-map web-map
Crie uma regra de encaminhamento. É isso que cria o balanceador de carga.
gcloud compute forwarding-rules create http-forwarding-rule \ --address=HOSTNAME_SERVER_VIP \ --global \ --target-http-proxy=http-lb-proxy \ --ports=80
Substitua
HOSTNAME_SERVER_VIP
pelo endereço IP a ser usado para o balanceador de carga. Se você omitir--address
, o GKE atribuirá automaticamente um endereço IP temporário. Também é possível reservar um novo endereço IP externo estático.
Check Point
Estes são os recursos que você criou até agora:
- Um endereço IP virtual externo
- As regras de encaminhamento
- As regras de firewall
- O proxy HTTP de destino
- O mapa de URL para a verificação de integridade do Compute Engine
- O serviço de back-end
- A verificação de integridade do Compute Engine
A relação entre esses recursos é mostrada no diagrama a seguir:
Esses recursos juntos são um balanceador de carga. Na próxima etapa, você adicionará back-ends ao balanceador de carga.
Um dos benefícios dos NEGs independentes demonstrados aqui é que os ciclos de vida do balanceador de carga e do back-end podem ser completamente independentes. O balanceador de carga pode continuar em execução após a exclusão do aplicativo, dos seus serviços ou do cluster do GKE. É possível adicionar e remover novos ou vários NEGs do balanceador de carga sem alterar nenhum dos objetos do balanceador de carga de front-end.
Adicionar back-ends ao balanceador de carga
Use gcloud compute backend-services
add-backend
para
conectar o NEG ao balanceador de carga ao adicioná-lo como um back-end do
serviço de back-end my-bes
:
gcloud compute backend-services add-backend my-bes \
--global \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-zone=NEG_ZONE \
--balancing-mode RATE --max-rate-per-endpoint 5
Substitua:
NEG_NAME
: o nome do grupo de endpoints da rede. Pode ser o nome especificado ao criar o NEG ou um nome gerado automaticamente. Se você não especificou um nome para o NEG, consulte as seguintes instruções para encontrar o nome gerado automaticamente.NEG_ZONE
: a zona em que o grupo de endpoints da rede está. Consulte as instruções a seguir para encontrar esse valor.
Use este comando para ver o nome e o local do NEG:
gcloud compute network-endpoint-groups list
O resultado será assim:
NAME LOCATION ENDPOINT_TYPE SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f ZONE_NAME GCE_VM_IP_PORT 3
Neste exemplo de saída, o nome do NEG é
k8s1-70aa83a6-default-my-service-80-c9710a6f
.
Vários NEGs podem ser adicionados ao mesmo serviço de back-end. Serviços de back-end globais,
como my-bes
, podem ter back-ends NEG em regiões diferentes, enquanto
os serviços de back-end regionais precisam ter back-ends em uma única região.
Validar se o balanceador de carga funciona
Há duas maneiras de validar se o balanceador de carga que você configurou está funcionando:
- Confira se a verificação de integridade está configurada corretamente e gerar relatórios de integridade.
- Acesse o aplicativo e verifique a resposta.
Conferir verificações de integridade
Verifique se o serviço de back-end está associado à verificação de integridade e aos grupos de endpoints da rede e se os endpoints individuais estão íntegros.
Use este comando para verificar se o serviço de back-end está associado à verificação de integridade e ao grupo de endpoints da rede:
gcloud compute backend-services describe my-bes --global
O resultado será assim:
backends:
- balancingMode: RATE
capacityScaler: 1.0
group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...
Em seguida, verifique a integridade dos endpoints individuais:
gcloud compute backend-services get-health my-bes --global
A seção status:
da saída é semelhante à seguinte:
status:
healthStatus:
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.43
port: 50000
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
ipAddress: 10.12.1.44
port: 50000
- healthState: HEALTHY
instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
ipAddress: 10.12.2.26
port: 50000
Acessar o aplicativo
Acesse o aplicativo por meio do endereço IP do balanceador de carga para confirmar que tudo está funcionando.
Primeiro, veja o endereço IP virtual do balanceador de carga:
gcloud compute addresses describe hostname-server-vip --global | grep "address:"
A saída incluirá um endereço IP. Em seguida, envie uma solicitação para esse endereço IP (neste exemplo, 34.98.102.37
):
curl 34.98.102.37
A resposta do aplicativo serve_hostname
precisa ser neg-demo-app
.
Como anexar um balanceador de carga interno do aplicativo a NEGs independentes
É possível usar NEGs para configurar um balanceador de carga de aplicativo interno para os serviços em execução nos pods autônomos do GKE.
Como configurar a sub-rede somente prox
A sub-rede somente proxy é para todos os balanceadores de carga de aplicativo internos regionais na região do balanceador de carga.
Console
Se você estiver usando o Console do Google Cloud, poderá esperar e criar a sub-rede somente proxy mais tarde.
gcloud
Crie a sub-rede somente proxy com o comando gcloud compute networks subnets create.
gcloud compute networks subnets create proxy-only-subnet \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=COMPUTE_REGION \
--network=lb-network \
--range=10.129.0.0/23
Substitua COMPUTE_REGION
pelo Compute Engine da sub-rede.
API
Crie a sub-rede somente proxy com o método subnetworks.insert
.
POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks
{
"name": "proxy-only-subnet",
"ipCidrRange": "10.129.0.0/23",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
"purpose": "REGIONAL_MANAGED_PROXY",
"role": "ACTIVE"
}
Substitua:
PROJECT_ID
: o ID do projeto.COMPUTE_REGION
: o Compute Engine da sub-rede.
Como configurar regras de firewall
Neste exemplo, usamos as seguintes regras de firewall:
fw-allow-ssh
: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite a conectividade SSH de entrada na porta TCP 22 proveniente de qualquer endereço. Você pode escolher um intervalo de IP de origem mais restritivo para esta regra. Por exemplo, é possível especificar apenas os intervalos de IP do sistema do qual você inicia sessões SSH. Neste exemplo, usamos a tag de destinoallow-ssh
para identificar as VMs às quais a regra de firewall se aplica.fw-allow-health-check
: uma regra de entrada aplicável às instâncias com balanceamento de carga, que autoriza o tráfego TCP proveniente de sistemas de verificação de integridade do Google Cloud (130.211.0.0/22
e35.191.0.0/16
). No exemplo, é usada a tag de destinoload-balanced-backend
para identificar as instâncias submetidas à regra.fw-allow-proxies
: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite o tráfego TCP nas portas9376
, nos proxies gerenciados do balanceador de carga HTTP(S) interno. Neste exemplo, usamos a tag de destinoload-balanced-backend
para identificar as instâncias às quais ele deve se aplicar.
Sem essas regras de firewall, a regra padrão de negação de entrada bloqueará o tráfego que chega para as instâncias de back-end.
Console
Acesse a página de políticas de firewall no console do Google Cloud.
Clique em Criar regra de firewall
para criar uma regra que autorize conexões SSH de entrada:- Name:
fw-allow-ssh
- Rede:
lb-network
- Direção do tráfego: entrada
- Ação se houver correspondência: permitir
- Destinos: tags de destino especificadas
- Tags de destino:
allow-ssh
- Filtro de origem:
IPv4 ranges
- Intervalos IPv4 de origem:
0.0.0.0/0
- Protocolos e portas:
- Selecione Portas e protocolos especificados.
- Marque a caixa de seleção
tcp
e especifique a porta22
.
- Name:
Clique em Criar.
Clique em Criar regra de firewall
para criar a regra que permita as verificações de integridade do Google Cloud:- Name:
fw-allow-health-check
- Rede:
lb-network
- Direção do tráfego: entrada
- Ação se houver correspondência: permitir
- Destinos: tags de destino especificadas
- Tags de destino:
load-balanced-backend
- Filtro de origem:
IPv4 ranges
- Intervalos IPv4 de origem:
130.211.0.0/22
e35.191.0.0/16
- Protocolos e portas:
- Selecione Portas e protocolos especificados.
- Marque a caixa de seleção
tcp
e especifique a porta80
. Como prática recomendada, limite esta regra somente aos protocolos e portas que correspondem aos usados por sua verificação de integridade. Se você usartcp:80
para o protocolo e a porta, o Google Cloud pode contatar suas VMs usando HTTP na porta 80, mas não pode entrar em contato com elas usando HTTPS na porta 443.
- Name:
Clique em Criar.
Clique novamente em Criar regra de firewall
novamente para criar a regra que permite que os servidores proxy do balanceador de carga se conectem aos back-ends:- Name:
fw-allow-proxies
- Rede:
lb-network
- Direção do tráfego: entrada
- Ação se houver correspondência: permitir
- Destinos: tags de destino especificadas
- Tags de destino:
load-balanced-backend
- Filtro de origem:
IPv4 ranges
- Intervalos IPv4 de origem:
10.129.0.0/23
- Protocolos e portas:
- Selecione Portas e protocolos especificados.
- Marque a caixa de seleção
tcp
e especifique a porta9376
.
- Name:
Clique em Criar.
gcloud
Crie a regra de firewall
fw-allow-ssh
que permita a conectividade SSH para VMs com a tag de redeallow-ssh
. Se você omitirsource-ranges
, o Google Cloud interpretará que a regra autoriza a conexão proveniente de qualquer origem.gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Crie a regra
fw-allow-health-check
para permitir verificações de integridade do Google Cloud. Neste exemplo, é permitido todo o tráfego TCP de sondagens de verificação de integridade. No entanto, é possível configurar um conjunto mais restrito de portas para atender às suas necessidades.gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcp
Crie a regra
fw-allow-proxies
para permitir que os proxies do balanceador de carga HTTP(S) interno se conectem aos back-ends.gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.129.0.0/23 \ --target-tags=load-balanced-backend \ --rules=tcp:9376
API
Crie a regra de firewall fw-allow-ssh
fazendo uma solicitação POST
ao método firewalls.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-ssh",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"allow-ssh"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"22"
]
}
],
"direction": "INGRESS"
}
Substitua PROJECT_ID
pela ID do seu projeto.
Crie a regra de firewall fw-allow-health-check
fazendo uma solicitação POST
ao método firewalls.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-health-check",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"sourceRanges": [
"130.211.0.0/22",
"35.191.0.0/16"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp"
}
],
"direction": "INGRESS"
}
Crie a regra de firewall fw-allow-proxies
para permitir ao tráfego TCP dentro da sub-rede proxy o método firewalls.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-proxies",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"sourceRanges": [
"10.129.0.0/23"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"9376"
]
}
],
"direction": "INGRESS"
}
Substitua PROJECT_ID
pela ID do seu projeto.
Como configurar o balanceador de carga
Para o endereço IP da regra de encaminhamento, use uma sub-rede de back-end. Se você tentar usar a sub-rede apenas de proxy, a criação da regra de encaminhamento falhará.
Console
Selecionar um tipo de balanceador de carga
- Acesse a página Criar balanceador de carga no Console do Google Cloud. Acesse Criar um balanceador de carga
- Em Balanceamento de carga HTTP(S), clique em Iniciar configuração.
- Selecione Apenas entre minhas VMs. Essa configuração implica que o balanceador de carga é interno.
- Clique em Continuar.
Preparar o balanceador de carga
- Em Nome do balanceador de carga, digite
l7-ilb-gke-map
. - Em Região, selecione a região em que você criou a sub-rede.
- Em Rede, selecione
lb-network
.
Reservar uma sub-rede somente proxy
Reserve uma sub-rede somente proxy:
- Clique em Reservar uma sub-rede.
- Em Nome, insira
proxy-only-subnet
. - Em Intervalo de endereços IP, digite
10.129.0.0/23
. - Clique em Adicionar.
Configurar o serviço de back-end
- Clique em Configuração do back-end.
- No menu Criar ou selecionar serviços de back-end, selecione Criar um serviço de back-end.
- Defina o Nome do serviço de back-end como
l7-ilb-gke-backend-service
. - Em Tipo de back-end, selecione Grupos de endpoints de rede.
- No cartão Novo back-end da seção Back-ends, siga estas etapas:
- Defina Grupo de endpoints de rede como o NEG criado pelo GKE. Para receber o nome do NEG, consulte Validar a criação de NEG.
- Em RPS máximo, especifique uma taxa máxima de
5
RPS por endpoint. O Google Cloud excederá esse limite máximo se necessário. - Clique em Concluído.
- Na lista suspensa Verificação de integridade, selecione
Criar verificação de integridade e especifique os seguintes parâmetros:
- Name:
l7-ilb-gke-basic-check
- Protocolo: HTTP
- Especificação de portas: porta de exibição
- Clique em Salvar e continuar.
- Name:
- Clique em Criar.
Configurar o mapa de URL
- Clique em Regras de roteamento. Certifique-se de que o l7-ilb-gke-backend-service seja o único serviço de back-end para qualquer host e caminho sem correspondência.
Configure o front-end
Clique em Configuração de front-end e siga estas instruções:
Para HTTP:
- Clique em Configuração de front-end.
- Clique em Adicionar IP e porta de front-end.
- Defina o Nome como l7-ilb-gke-forwarding-rule.
- Defina o Protocolo como HTTP.
- Defina a Sub-rede como backend-subnet.
- Em IP interno, selecione Reservar um endereço IP interno estático.
- No painel exibido, forneça os seguintes detalhes:
- Name:
l7-ilb-gke-ip
- Na seção Endereço IP estático, selecione Quero escolher.
- Na seção Endereço IP personalizado, insira
10.1.2.199
. - Clique em Reservar.
- Name:
- Defina Porta como
80
. - Clique em Concluído.
Para HTTPS:
Se você usa o HTTPS entre o cliente e o balanceador de carga, um ou mais recursos de certificado SSL serão necessários para configurar o proxy. Consulte as informações sobre como criar recursos de certificado SSL em Certificados SSL. Os certificados gerenciados pelo Google não são compatíveis com balanceadores de carga HTTP(S) internos.
- Clique em Configuração de front-end.
- Clique em Adicionar IP e porta de front-end.
- No campo Nome, use
l7-ilb-gke-forwarding-rule
. - No campo Protocolo, selecione
HTTPS (includes HTTP/2)
. - Defina a Sub-rede como backend-subnet.
- Em IP interno, selecione Reservar um endereço IP interno estático.
- No painel exibido, forneça os seguintes detalhes:
- Name:
l7-ilb-gke-ip
- Na seção Endereço IP estático, selecione Quero escolher.
- Na seção Endereço IP personalizado, insira
10.1.2.199
. - Clique em Reservar.
- Name:
- Certifique-se de que a Porta esteja definida como
443
, para permitir tráfego HTTPS. - Clique na lista suspensa Certificado.
- Se você já tiver um recurso de certificado SSL autogerenciado que você quer usar como o certificado SSL principal, selecione-o no menu suspenso.
- Caso contrário, selecione Criar um novo certificado.
- Preencha um Nome para
l7-ilb-cert
. - Nos campos apropriados, faça o upload dos arquivos formatados em PEM:
- Certificado de chave pública
- Cadeia de certificados
- Chave privada
- Clique em Criar.
- Preencha um Nome para
- Para adicionar recursos de certificado além do certificado SSL principal, siga estas etapas:
- Clique em Adicionar certificado.
- Selecione um certificado na lista Certificados ou clique em Criar um novo certificado e siga as instruções.
- Clique em Concluído.
Concluir a configuração
Clique em Criar.
gcloud
Defina a verificação de integridade HTTP com o comando gcloud compute health-checks create http.
gcloud compute health-checks create http l7-ilb-gke-basic-check \ --region=COMPUTE_REGION \ --use-serving-port
Defina o serviço de back-end com o comando gcloud compute backend-services create.
gcloud compute backend-services create l7-ilb-gke-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=l7-ilb-gke-basic-check \ --health-checks-region=COMPUTE_REGION \ --region=COMPUTE_REGION
Defina a variável
DEPLOYMENT_NAME
:export DEPLOYMENT_NAME=NEG_NAME
Substitua
NEG_NAME
pelo nome do NEG.Adicione back-ends de NEG ao serviço de back-end com o comando gcloud compute backend-services add-backend.
gcloud compute backend-services add-backend l7-ilb-gke-backend-service \ --network-endpoint-group=$DEPLOYMENT_NAME \ --network-endpoint-group-zone=COMPUTE_ZONE-b \ --region=COMPUTE_REGION \ --balancing-mode=RATE \ --max-rate-per-endpoint=5
Crie o mapa de URL com o comando gcloud compute url-maps create.
gcloud compute url-maps create l7-ilb-gke-map \ --default-service=l7-ilb-gke-backend-service \ --region=COMPUTE_REGION
Crie o proxy de destino.
Para HTTP:
Use o comando gcloud compute target-http-proxies create.
gcloud compute target-http-proxies create l7-ilb-gke-proxy \ --url-map=l7-ilb-gke-map \ --url-map-region=COMPUTE_REGION \ --region=COMPUTE_REGION
Para HTTPS:
Consulte as informações sobre como criar recursos de certificado SSL em Certificados SSL. Os certificados gerenciados pelo Google não são compatíveis com balanceadores de carga HTTP(S) internos.
Atribua os caminhos de arquivo aos nomes de variáveis.
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
export LB_PRIVATE_KEY=PATH_TO_PEM_FORMATTED_FILE
Use o comando gcloud compute ssl-certificates create para criar um certificado SSL regional.
gcloud compute ssl-certificates create
gcloud compute ssl-certificates create l7-ilb-cert \ --certificate=$LB_CERT \ --private-key=$LB_PRIVATE_KEY \ --region=COMPUTE_REGION
Use o certificado SSL regional para criar um proxy de destino com o comando gcloud compute target-https-proxies create.
gcloud compute target-https-proxies create l7-ilb-gke-proxy \ --url-map=l7-ilb-gke-map \ --region=COMPUTE_REGION \ --ssl-certificates=l7-ilb-cert
Crie a regra de encaminhamento.
Para redes personalizadas, referencie a sub-rede na regra de encaminhamento. Observe que esta é a sub-rede da VM, não a do proxy.
Para HTTP:
Use o comando gcloud compute forwarding-rules create com as sinalizações corretas.
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=80 \ --region=COMPUTE_REGION \ --target-http-proxy=l7-ilb-gke-proxy \ --target-http-proxy-region=COMPUTE_REGION
Para HTTPS:
Use o comando gcloud compute forwarding-rules create com as sinalizações corretas.
gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.199 \ --ports=443 \ --region=COMPUTE_REGION \ --target-https-proxy=l7-ilb-gke-proxy \ --target-https-proxy-region=COMPUTE_REGION
API
Crie a verificação de integridade fazendo uma solicitação POST
ao método regionHealthChecks.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks
{
"name": "l7-ilb-gke-basic-check",
"type": "HTTP",
"httpHealthCheck": {
"portSpecification": "USE_SERVING_PORT"
}
}
Substitua PROJECT_ID
pelo ID do projeto.
Crie um serviço de back-end regional fazendo uma solicitação POST
ao método regionBackendServices.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices
{
"name": "l7-ilb-gke-backend-service",
"backends": [
{
"group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
"balancingMode": "RATE",
"maxRatePerEndpoint": 5
}
],
"healthChecks": [
"projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}
Substitua:
PROJECT_ID
: o ID do projeto;NEG_NAME
: o nome do NEG.
Crie o mapa de URLs fazendo uma solicitação POST
ao método regionUrlMaps.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps
{
"name": "l7-ilb-gke-map",
"defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}
Substitua PROJECT_ID
pelo ID do projeto.
Crie o proxy HTTP de destino fazendo uma solicitação POST
ao
método
regionTargetHttpProxies.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy
{
"name": "l7-ilb-gke-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
"region": "COMPUTE_REGION"
}
Substitua PROJECT_ID
pelo ID do projeto.
Crie a regra de firewall fazendo uma solicitação POST
ao método forwardingRules.insert
.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules
{
"name": "l7-ilb-gke-forwarding-rule",
"IPAddress": "10.1.2.199",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
"network": "projects/PROJECT_ID/global/networks/lb-network",
"networkTier": "PREMIUM",
}
Substitua PROJECT_ID
pelo ID do projeto.
Teste
Criar uma instância de VM na zona para testar a conectividade:
gcloud compute instances create l7-ilb-client \
--image-family=debian-9 \
--image-project=debian-cloud \
--zone=COMPUTE_ZONE \
--network=lb-network \
--subnet=backend-subnet \
--tags=l7-ilb-client,allow-ssh
Faça login na instância do cliente para que os serviços HTTP(S) nos back-ends sejam acessados pelo endereço IP da regra de encaminhamento do balanceador de carga de aplicativo interno e o balanceamento de carga do tráfego seja feito entre os endpoints no NEG.
Conecte-se a cada instância do cliente usando SSH:
gcloud compute ssh l7-ilb-client \
--zone=COMPUTE_ZONE-b
Verifique se o IP está exibindo o nome do host:
curl 10.1.2.199
Para fazer testes em HTTPS, execute o seguinte comando:
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
A sinalização -k
faz com que curl
ignore a validação do certificado.
Executar 100 solicitações e confirmar o balanceamento de carga delas
Para HTTP:
{
RESULTS=
for i in {1..100}
do
RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}
Para HTTPS:
{
RESULTS=
for i in {1..100}
do
RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}
Como implementar serviços heterogêneos (VMs e contêineres)
Os balanceadores de carga podem ser front-ends para cargas de trabalho mistas do Kubernetes e que não são do Kubernetes. Isso pode ser parte de uma migração de VMs para contêineres ou uma arquitetura permanente que se beneficia de um balanceador de carga compartilhado. Para isso, crie balanceadores de carga que visam diferentes tipos de back-ends, inclusive NEGs independentes.
VMs e contêineres no mesmo serviço de back-end
Neste exemplo, mostramos como criar um NEG que aponta para uma VM atual que executa uma carga de trabalho e como adicionar esse NEG como outro back-end de um backendService
atual.
Dessa forma, um único balanceador de carga faz o balanceamento entre VMs e contêineres do GKE.
Este exemplo estende o exemplo anterior que usa um balanceador de carga HTTP externo.
Como todos os endpoints são agrupados pelo mesmo backendService
, os endpoints da VM e do contêiner são considerados o mesmo serviço. Isso significa que a correspondência de host ou caminho tratará todos os back-ends de maneira idêntica com base nas regras de mapa de URL.
Quando você usa um NEG como back-end para um serviço de back-end, todos os outros back-ends nesse serviço também precisam ser NEGs. Não é possível usar grupos de instância e NEGs como back-end no mesmo serviço de back-end. Além disso, os contêineres e as VMs não podem existir como endpoints no mesmo NEG. Portanto, eles precisam sempre ser configurados com NEGs separados.
Implante uma VM no Compute Engine com o comando:
gcloud compute instances create vm1 \ --zone=COMPUTE_ZONE \ --network=NETWORK \ --subnet=SUBNET \ --image-project=cos-cloud \ --image-family=cos-stable --tags=vm-neg-tag
Substitua:
COMPUTE_ZONE
: o nome da zona.NETWORK
: o nome da rede.SUBNET
: o nome da sub-rede associada à rede.
Implante um aplicativo na VM:
gcloud compute ssh vm1 \ --zone=COMPUTE_ZONE \ --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
Esse comando implanta na VM o mesmo aplicativo de exemplo usado no exemplo anterior. Para simplificar, o aplicativo é executado como um contêiner do Docker, mas isso não é essencial. O comando
iptables
é necessário para permitir o acesso de firewall ao contêiner em execução.Valide se o aplicativo está sendo exibido na porta 9376 e informando que está sendo executado na vm1:
gcloud compute ssh vm1 \ --zone=COMPUTE_ZONE \ --command="curl -s localhost:9376"
O servidor responderá com
vm1
.Crie um NEG para usar com o endpoint da VM. Os contêineres e as VMs podem ser endpoints de NEG, mas um único NEG não pode ter endpoints de VM e de contêineres.
gcloud compute network-endpoint-groups create vm-neg \ --subnet=SUBNET \ --zone=COMPUTE_ZONE
Anexe o endpoint da VM ao NEG:
gcloud compute network-endpoint-groups update vm-neg \ --zone=COMPUTE_ZONE \ --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"
Substitua
VM_PRIMARY_IP
pelo endereço IP principal da VM.Confirme se o NEG tem o endpoint da VM:
gcloud compute network-endpoint-groups list-network-endpoints vm-neg \ --zone COMPUTE_ZONE
Anexe o NEG ao serviço de back-end usando o mesmo comando usado para adicionar um back-end de contêiner:
gcloud compute backend-services add-backend my-bes --global \ --network-endpoint-group vm-neg \ --network-endpoint-group-zone COMPUTE_ZONE \ --balancing-mode RATE --max-rate-per-endpoint 10
Abra o firewall para permitir a verificação de integridade da VM:
gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=vm-neg-tag \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --rules=tcp:9376
Confirme se o balanceador de carga está encaminhando o tráfego para o novo back-end vm1 e para o back-end atual enviando tráfego de teste:
for i in `seq 1 100`; do curl ${VIP};echo; done
Você verá as respostas dos endpoints do contêiner (
neg-demo-app
) e da VM (vm1
).
VMs e contêineres para diferentes serviços de back-end
Neste exemplo, mostramos como criar um NEG que aponta para uma VM atual que executa uma carga de trabalho e como adicionar esse NEG como back-end a um novo backendService
. Isso é útil para os casos em que os contêineres e as VMs são serviços diferentes, mas precisam compartilhar o mesmo balanceador de carga L7, como no caso dos serviços compartilharem o mesmo endereço IP ou nome de domínio.
Este exemplo estende o exemplo anterior que tem um back-end de VM no mesmo serviço de back-end que o back-end do contêiner. Este exemplo reutiliza essa VM.
Como os endpoints do contêiner e da VM são agrupados em serviço de back-end separados, eles são considerados serviços diferentes. Isso significa que o mapa de URL corresponderá a back-ends e direcionará o tráfego para a VM ou o contêiner com base no nome do host.
O diagrama a seguir mostra como um único endereço IP virtual corresponde a dois nomes de host, que, por sua vez, correspondem a um serviço de back-end baseado em contêiner e a um serviço de back-end baseado em VM.
O diagrama a seguir mostra a arquitetura descrita na seção anterior:
Crie um novo serviço de back-end para a VM:
gcloud compute backend-services create my-vm-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
Anexe o NEG da VM,
vm-neg
, ao serviço de back-end:gcloud compute backend-services add-backend my-vm-bes \ --global \ --network-endpoint-group vm-neg \ --network-endpoint-group-zone COMPUTE_ZONE \ --balancing-mode RATE --max-rate-per-endpoint 10
Adicione uma regra de host ao mapa de URL para direcionar solicitações para o host
container.example.com
ao serviço de back-end do contêiner:gcloud compute url-maps add-path-matcher web-map \ --path-matcher-name=container-path --default-service=my-bes \ --new-hosts=container.example.com --global
Adicione outra regra de host ao mapa de URL para direcionar solicitações para o host
vm.example.com
ao serviço de back-end da VM:gcloud compute url-maps add-path-matcher web-map \ --path-matcher-name=vm-path --default-service=my-vm-bes \ --new-hosts=vm.example.com --global
Valide se o balanceador de carga envia tráfego para o back-end da VM com base no caminho solicitado:
curl -H "HOST:vm.example.com" VIRTUAL_IP
Substitua
VIRTUAL_IP
pelo endereço IP virtual.
Limitações de NEGs independentes
- Erros de validação de anotação são expostos ao usuário por meio de eventos do Kubernetes.
- As limitações de NEGs também se aplicam aos NEGs independentes.
- Os NEGs independentes não funcionam com redes legadas.
- NEGs autônomos só podem ser usados com serviços de rede compatíveis, incluindo o Cloud Service Mesh e os tipos de balanceadores de carga compatíveis.
Preços
Consulte a seção de balanceamento de carga da página de preços para ver detalhes sobre os preços do balanceador de carga. Não há cobrança extra para NEGs.
Solução de problemas
Nesta seção, apresentamos as etapas de solução de problemas comuns que podem ser encontrados com os NEGs independentes.
Nenhum NEG independente configurado
Sintoma: nenhum NEG criado.
Possível resolução:
- Verifique os eventos associados ao serviço e procure mensagens de erro.
- Verifique se a anotação do NEG independente é um JSON bem formado e se as portas expostas correspondem às portas existentes na especificação do serviço.
- Verifique a anotação de status de NEG e veja se as portas de serviço esperadas têm NEGs correspondentes.
- Verifique se os NEGs foram criados nas zonas esperadas, com o comando
gcloud compute network-endpoint-groups list
. - Se estiver usando a versão 1.18 ou posterior do GKE, verifique se o
recurso
svcneg
do Serviço existe. Caso contrário, consulte a condiçãoInitialized
para ver informações sobre o erro. - Se você estiver usando nomes personalizados de NEG, verifique se cada nome de NEG é exclusivo em sua região.
O tráfego não alcança os endpoints
Sintoma: erros 502 ou conexões rejeitadas.
Possível resolução:
- Após a configuração do serviço, novos endpoints geralmente se tornarão acessíveis depois de serem anexados ao NEG, desde que respondam às verificações de integridade.
- Se, após esse período, o tráfego ainda não conseguir alcançar os endpoints, resultando no código de erro 502 para HTTP(S) ou em conexões rejeitadas para balanceadores de carga TCP/SSL, verifique o seguinte:
- Verifique se as regras de firewall autorizam o tráfego TCP de entrada nos seus endpoints proveniente dos seguintes intervalos:
130.211.0.0/22
e35.191.0.0/16
. - Verifique se os endpoints estão íntegros usando a Google Cloud CLI ou chamando
a API
getHealth
nobackendService
ou a API listEndpoints no NEG com o parâmetro showHealth definido comoSHOW
.
- Verifique se as regras de firewall autorizam o tráfego TCP de entrada nos seus endpoints proveniente dos seguintes intervalos:
Lançamento interrompido
Sintoma: uma implantação atualizada é interrompida e o número de réplicas atualizadas não corresponde ao número escolhido.
Possível resolução:
As verificações de integridade da implantação estão falhando. A imagem do contêiner pode estar corrompida ou a verificação de integridade pode estar mal configurada. A substituição gradual dos pods aguarda até que o pod recém-iniciado passe pelo portão de prontidão do pod. Isso só ocorrerá se o pod estiver respondendo às verificações de integridade do balanceador de carga. Se o pod não estiver respondendo ou se a verificação de integridade estiver configurada incorretamente, as condições do portão de prontidão não poderão ser cumpridas e o lançamento não poderá continuar.
Se o kubectl 1.13 ou mais recente estiver sendo usado, será possível verificar o status dos portões de prontidão de um pod com o seguinte comando:
kubectl get my-Pod -o wide
Verifique a coluna READINESS GATES.
Esta coluna não existe no kubectl 1.12 e versões anteriores. Um pod marcado com o estado READY pode ter um portão de prontidão com falha. Para verificar isso, use o seguinte comando:
kubectl get my-pod -o yaml
Os portões de prontidão e os status deles são listados na saída.
Verifique se a imagem do contêiner na especificação do pod de implantação está funcionando corretamente e se é capaz de responder a verificações de integridade.
Confira se as verificações de integridade estão configuradas corretamente.
O NEG não é coletado como lixo
Sintoma: um NEG que deveria ter sido excluído ainda existe.
Possível resolução:
- O NEG não é coletado como lixo se o NEG é referenciado por um Serviço de back-end. Consulte Como evitar NEGs vazados para ver detalhes.
- Se estiver usando a versão 1.18 ou posterior, verifique se há eventos no
recurso
ServiceNetworkEndpointGroup
usando o procedimento negativo de serviço. - Verifique se o NEG ainda é necessário para ser usado por um serviço. Verifique o recurso
svcneg
do serviço que corresponde ao NEG e se há uma anotação de Serviço.
O NEG não é sincronizado com o Serviço
Sintoma: os endpoints esperados (IP do pod) não existem no NEG, o NEG
não está sincronizado ou o erro Failed to sync NEG_NAME (will not retry):
neg name NEG_NAME is already in use, found a custom named neg with an empty
description
Possível resolução:
Se você estiver usando o GKE 1.18 ou posterior, verifique o recurso svcneg
para mais informações:
- Verifique o valor
status.lastSyncTime
para verificar se o NEG foi sincronizado recentemente. - Verifique a condição
Synced
em busca de erros que ocorreram na sincronização mais recente.
Se você estiver usando o GKE 1.19.9 ou posterior, verifique se há um NEG com o nome e a zona correspondentes ao nome e à zona do NEG que o controlador do NEG do GKE precisa criar. Por exemplo, um NEG com o nome que o controlador de NEG precisa usar pode ter sido criado usando a gcloud CLI ou o Console do Google Cloud na zona do cluster (ou uma das zonas do cluster). Nesse caso, é necessário excluir o NEG antes que o controlador de NEG possa sincronizar os endpoints. A criação e assinatura independentes de NEG foram projetadas para serem gerenciadas pelo controlador de NEG.
A seguir
- Visão geral dos grupos de endpoints de rede zonais
- Serviços de back-end
- Como criar verificações de integridade
- Como usar proxies de destino
- Como usar regras de encaminhamento