Configurando um Application Load Balancer for VPC

Exponha seu app para uma rede pública ou privada configurando um serviço LoadBalancer do Kubernetes em seu cluster. Quando você expõe o seu aplicativo, um Application Load Balancer for VPC (VPC ALB) que roteia as solicitações para o seu aplicativo é criado automaticamente para você em sua VPC fora do seu cluster. Em seguida, você pode, se desejar, registrar o VPC ALB com um registro DNS e um certificad TLS. Os ALBs do VPC suportam apenas o protocolo TCP.

Não confunda o Application Load Balancer for VPC com os balanceadores de carga do aplicativo Ingress do Red Hat OpenShift on IBM Cloud. Os Application Load Balancers for VPC (VPC ALBs) são executados fora do seu cluster em sua VPC e são configurados pelos serviços Kubernetes LoadBalancer que você cria. Balanceadores de carga do aplicativo (ALBs) do Ingress são controladores do Ingress que são executados em nós do trabalhador em seu cluster.

Configurando um VPC ALB público ou privado

Antes de Iniciar

Certifique-se de que você possui a função de acesso ao serviço IAM “Writer” ou “Manager” IBM Cloud para o namespace no qual você implanta o serviço Kubernetes LoadBalancer para o VPC ALB.
Acesse o seu Red Hat OpenShift cluster.
Para visualizar os VPC ALBs, instale o plug-in infrastructure-service. O prefixo para a execução de comandos é ibmcloud is.
```
ibmcloud plugin install infrastructure-service
```

Para permitir que seu aplicativo receba solicitações públicas ou privadas:

Implemente o seu app no cluster. Certifique-se de incluir um rótulo na seção de metadados de seu arquivo de configuração de implementação. Esse rótulo customizado identifica todos os pods nos quais seu app é executado para incluí-los no balanceamento de carga.

Crie um arquivo YAML de configuração para o seu serviço LoadBalancer do Kubernetes. No arquivo YAML, especifique a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type como "public" ou "private". A seção annotations no arquivo de exemplo inclui apenas algumas anotações disponíveis. Para obter uma lista completa das anotações obrigatórias e opcionais do VPC ALB, consulte Anotações e especificações.

Para tornar seu VPC ALB facilmente identificável, considere nomear o serviço no formato <app_name>-vpc-alb-<VPC_zone>.

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "`<app_name>-vpc-alb-<VPC_zone>`"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
spec:
 type: LoadBalancer
 selector:     
    <selector_key>: <selector_value>
 ports:
   - name: http
     protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   - name: https
     protocol: TCP
     port: 443
     targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  externalTrafficPolicy: Local # Specify Local or Cluster.

Crie o serviço LoadBalancer do Kubernetes em seu cluster.
```
oc apply -f myloadbalancer.yaml -n <namespace>
```
Verifique se o serviço LoadBalancer do Kubernetes foi criado com êxito em seu cluster. Quando o serviço é criado, o campo LoadBalancer Ingress é preenchido com um nome do host que é designado pelo VPC ALB.

O VPC ALB leva alguns minutos para provisionar em sua VPC. Não é possível acessar o app usando o nome do host do serviço LoadBalancer de Kubernetes até que o ALB da VPC seja totalmente fornecido.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Exemplo de saída da CLI para um serviço `LoadBalancer` público:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

Verifique se o VPC ALB é criado com sucesso em sua VPC. Na saída, verifique se o VPC ALB está com um Status operacional como online e um Status de provisão como active.

ibmcloud is load-balancers

Na saída da CLI de exemplo a seguir, o VPC ALB que é nomeado kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 é criado para o serviço Kubernetes LoadBalancer:

ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default

Se você criou um serviço LoadBalancer público, enrole o nome do host do serviço Kubernetes LoadBalancer que é designado pelo VPC ALB localizado na etapa 4. Exemplo:
```
curl 06496f64-us-south.lb.appdomain.cloud:8080
```
Exemplo de saída
```
Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!
```
Se você criou um serviço privado do LoadBalancer, deverá estar conectado à sua rede privada VPC para efetuar curl do nome do host.

Não exclua as sub-redes que você anexou ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Os ALBs e NLBs da VPC que não estejam vinculados a clusters do tipo “ Kubernetes ” ou “ OpenShift ” podem ser atualizados diretamente por meio dos comandos “ibmcloud is” ou na seção “Infraestrutura da VPC” do console. Por exemplo, alterar a porta de um ouvinte de front-end ou o valor de tempo limite do controle de integridade. No entanto, no caso dos balanceadores de carga do VPC vinculados a clusters do tipo Kubernetes ou OpenShift, quaisquer atualizações neles devem ser realizadas por meio de anotações na configuração do Ingress. O provedor do IBM Cloud realiza periodicamente uma ressincronização com quaisquer ALBs e NLBs da VPC associados, a fim de garantir que o balanceador de carga em execução esteja em conformidade com a configuração esperada do Ingress. Portanto, se você fizer alguma alteração nesse balanceador de carga diretamente pela VPC, em vez de usar anotações do Ingress, essas alterações serão revertidas.

Registrando um registro DNS e certificado TLS

O Application Load Balancer para VPC (ALB da VPC) fornece um nome de host HTTP padrão no formato 1234abcd-<region>.lb.appdomain.cloud por meio do qual é possível acessar o app. No entanto, se desejar que um certificado TLS para o domínio do seu aplicativo suporte HTTPS, será possível criar um subdomínio fornecido pela IBM ou trazer seu próprio domínio customizado para os VPC ALBs públicos e privados.

Depois de criar um subdomínio DNS para um ALB da VPC, não será possível usar comandos nlb-dns health-monitor para criar uma verificação de funcionamento customizada. Em vez disso, a verificação de funcionamento do balanceador de carga VPC padrão fornecida para o nome do host do ALB VPC padrão é usada. Para obter mais informações, consulte a documentação do VPC.

Antes de Iniciar

Configure um VPC ALB. Assegure-se de definir uma porta HTTPS no seu serviço Kubernetes LoadBalancer que configura o VPC ALB.
Para usar o certificado TLS para acessar seu app via HTTPS, seu app deve ser capaz de finalizar conexões TLS.

Para registrar um nome do host do VPC ALB com um subdomínio DNS:

Recupere o nome do host para seu ALB do VPC executando o comando get svc. Na saída, procure o nome do host na coluna IP EXTERNO. Por exemplo, 1234abcd-us-south.lb.appdomain.cloud.

oc get svc -o wide

Exemplo de saída

NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
...
webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver

Crie um subdomínio DNS customizado ou fornecido pela IBM para o nome do host do balanceador de carga.
- Domínio customizado: forneça o próprio domínio customizado e dê a ele um alias especificando o IP externo do balanceador de carga, no formato 1234abcd-us-south.lb.appdomain.cloud, como um registro de nome canônico (CNAME).
  1. Registre um domínio customizado trabalhando com o seu provedor do Domain Name Service (DNS) ou com o IBM Cloud DNS.
  2. Defina um alias para o domínio customizado especificando o IP externo do balanceador de carga como um registro de nome canônico (CNAME). No exemplo a seguir, o balanceador de carga com o IP externo de 1234abcd-us-south.lb.appdomain.cloud é alcançável em www.your-custom-domain.com.
  Host/Serviço
  
  O prefixo no qual você deseja alcançar o app, como www.
  
  Tipo de Recurso
  
  Selecione CNAME.
  
  TTL
  
  Selecione um tempo de vida.
  
  Valor/Destino
  
  O IP externo do LoadBalancer que você recuperou anteriormente. Por exemplo, 1234abcd-us-south.lb.appdomain.cloud.. Observe que ao usar o IBM Cloud DNS, certifique-se de inserir um ponto à direita.
- Subdomínio fornecido pela IBM: use comandos nlb-dns para gerar um subdomínio com um certificado TLS para o nome de host do ALB da VPC. A IBM Cloud cuida de gerar e manter o certificado TLS curinga para o subdomínio.
  1. Crie um subdomínio DNS e um certificado TLS.
```
ibmcloud oc nlb-dns create vpc-gen2 --cluster CLUSTER_NAME_OR_ID --lb-host VPC_LB_HOSTNAME --type (public|private)
```
  2. Verifique se o subdomínio foi criado. Para obter mais informações, consulte Entendendo o formato de subdomínio.
```
ibmcloud oc nlb-dns ls --cluster CLUSTER_NAME_OR_ID
```
    Exemplo de saída
```
Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
```
Se você tiver criado um subdomínio para um VPC ALB público, abra um navegador da web e insira a URL para acessar o app por meio do subdomínio, como o www.your-custom-domain.com de exemplo. Se você criou um subdomínio para um VPC ALB privado, deve-se estar conectado à sua rede privada VPC para testar o acesso ao seu subdomínio.

Para usar o certificado TLS para acessar seu app via HTTPS, assegure-se de que você tenha definido uma porta HTTPS em seu serviço de Kubernetes LoadBalancer. É possível verificar se as solicitações estão sendo roteadas corretamente por meio da porta HTTPS executando curl -v --insecure https://<domain>. Um erro de conexão indica que nenhuma porta HTTPS está aberta no serviço. Além disso, assegure-se de que as conexões TLS possam ser finalizadas por seu app. É possível verificar se o app finaliza correamente o TLS executando curl -v https://<domain>. Um erro de certificado indica que seu app não está finalizando de forma adequada as conexões TLS.

Registro de um registro DNS privado para um VPC ALB privado

Na versão 4.15 ou posterior, você pode usar as seguintes anotações opcionais para associar um DNS próprio instance que atende a um DNS personalizado zone com um VPC ALB privado. Para isso, ambas as anotações opcionais devem ser definidas. Se não forem especificados, os registros DNS do tipo “ A ” para a propriedade hostname desse balanceador de carga são adicionados à zona DNS pública lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn": O DNS instance a ser associado a este balanceador de carga. A instância especificada pode estar em uma região ou conta diferente, sujeita às políticas de IAM. Valores possíveis: 9 ≤ comprimento ≤ 512
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id": O DNS zone a ser associado a este balanceador de carga. A zona especificada pode estar em uma região ou conta diferente, sujeita às políticas de IAM. Valores possíveis: 1 ≤ comprimento ≤ 128, O valor deve corresponder à expressão regular ^[1]*[a-z0-9]$

Você precisa fazer o seguinte como pré-requisito para poder usar esse recurso:

Criar a zona DNS que pode ser vinculada a um balanceador de carga
Habilitar a autorização de serviço para serviço entre LBs de VPC e DNS Services
Adicionar a VPC do cluster às redes permitidas da zona

Para obter informações detalhadas, consulte os documentos Integrando um balanceador de carga de aplicativos com o IBM Cloud DNS Services e Adicionar uma VPC como uma rede permitida à zona DNS.

Exemplo:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

Anotações e especificações

Analise as anotações e especificações necessárias e opcionais do VPC ALB.

Anotações e especificações necessárias

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "alb": Anotação para criar um VPC ALB. Se você não incluir service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features, um VPC ALB será provisionado por padrão.
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private": (Necessário para ALBs de VPC privados) Anotação para especificar um serviço que aceita solicitações públicas ou privadas. Se essa anotação não for incluída, será criado um VPC ALB público.
externalTrafficPolicy: Especifique Cluster para encaminhar uma solicitação a um nó de trabalho que contenha o pod do aplicativo. Esse nó de trabalho pode estar em uma zona diferente. Por padrão, essa anotação está definida como “ Cluster ”.; Especifique Local para impedir que o tráfego de entrada seja encaminhado para um nó diferente. Esta opção também configura verificações de funcionamento de HTTP.; Observe que, para usar o IP de origem do cliente original para VPC ALBs, você deve ativar o protocolo PROXY com a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol".

Anotações e especificações opcionais

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name

Inclua um nome exclusivo para tornar seu balanceador de carga VPC persistente. Os balanceadores de carga VPC persistentes não são excluídos quando o cluster ao qual pertencem é excluído. Para obter mais informações, consulte Balanceadores de carga VPC persistentes. Essa anotação pode ser definida somente na criação do balanceador de carga. Ele não pode ser usado em uma operação de atualização.

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"

Ative o protocolo PROXY. O balanceador de carga transmite informações de conexão do cliente, incluindo o endereço IP do cliente, o endereço IP do servidor proxy e ambos os números de porta, em cabeçalhos da solicitação para seu app back-end. Observe que o seu app back-end deve ser configurado para aceitar o protocolo PROXY. Por exemplo, é possível configurar um app NGINX para aceitar o protocolo PROXY seguindo estas etapas.

service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

Anotação para especificar uma zona da VPC à qual seu cluster está anexado. Quando você especifica uma zona nessa anotação, ocorrem dois processos: (1) O VPC ALB é implantado na mesma sub-rede dessa zona à qual seus nós de trabalho estão conectados e (2) somente os nós de trabalho em seu cluster nessa zona são configurados para receber tráfego do VPC ALB. Para colocar o balanceador de carga em uma zona específica, deve-se especificar essa anotação ao criar o balanceador de carga. Se você alterar posteriormente essa anotação para uma zona diferente, os nós de escuta e de trabalho de backend serão atualizados automaticamente para corresponder à nova zona. Se o rótulo “ dedicated: edge ” estiver definido nos nós de trabalho e você especificar essa anotação, apenas os nós de borda na zona especificada serão configurados para receber tráfego. Nós de borda em outras zonas e nós não de borda na zona especificada não recebem tráfego do balanceador de carga. Para ver as zonas, execute ibmcloud ks zone ls --provider vpc-gen2.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

Anotação para especificar uma ou mais sub-redes nas quais o serviço VPC ALB é implantado. Se especificada, essa anotação terá precedência sobre a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Sem essa anotação, as sub-redes que o VPC ALB implementa serão atualizadas automaticamente para corresponder às zonas de um cluster se o cluster for atualizado de uma região de zona única para várias zonas ou vice-versa. Observe que é possível especificar uma sub-rede diferente na mesma VPC das sub-redes às quais seu cluster está anexado. Nesse caso, mesmo que o VPC ALB seja implementado em uma sub-rede diferente na mesma VPC, o VPC ALB ainda poderá rotear o tráfego para seus nós do trabalhador nas sub-redes do cluster. Para ver sub-redes em todos os grupos de recursos, execute ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE. Essa anotação pode ser adicionada ou modificada para VPC ALBs existentes.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

Anotação para especificar um seletor de rótulo de nó de trabalho. Você pode configurar nós de trabalho específicos em seu cluster para receber tráfego especificando chaves seletoras de rótulo. É possível incluir apenas um seletor de rótulo na anotação, e esse seletor deve ser especificado no formato "key=value". Se esta anotação não for especificada, todos os nós do trabalhador em seu cluster estarão configurados para receber tráfego do VPC ALB. Essa anotação tem precedência sobre a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-zone , e quaisquer rótulos dedicated: edge nos nós de trabalho são ignorados. Para limitar o tráfego a uma zona específica, você pode usar essa anotação para especificar os nós de trabalho nessa zona. Observe que a definição de um novo rótulo em um nó de trabalho do cluster não configura automaticamente o nó de trabalho para receber tráfego; é necessário recriar ou atualizar o VPC ALB para que o nó de trabalho recém-rotulado receba tráfego.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

O protocolo de verificação de integridade no recurso de balanceador de carga VPC associado ao serviço de balanceador de carga Kubernetes. As opções disponíveis são http, https ou tcp. Normalmente, o protocolo de verificação de integridade do VPC LB é determinado pelo valor da configuração externalTrafficPolicy na especificação do serviço do balanceador de carga Kubernetes, mas essa anotação substitui essa lógica. Essa anotação não altera o comportamento do Kubernetes, e do kube-proxy em particular, com relação às várias configurações do externalTrafficPolicy.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

A porta do serviço “ TCP ” utilizada para as verificações de integridade. Essa anotação se aplica somente se ibm-load-balancer-cloud-provider-vpc-health-check-protocol também for especificado.

Se o seu cluster não executar o Secure by Default, talvez seja necessário fazer as seguintes modificações nos grupos de segurança VPC aplicados. Se o seu cluster executar o Secure by Default, essas alterações serão aplicadas automaticamente.

Se a porta TCP especificada estiver fora do intervalo de portas dos nós Kubernetes (30.000–32.767), o grupo de segurança da VPC aplicado aos nós de trabalho do cluster deverá ser modificado para permitir o tráfego de entrada nessa porta.

Se essa anotação for aplicada a um serviço de balanceador de carga do Kubernetes associado a um VPC ALB, as regras de saída do grupo de segurança atribuído ao VPC ALB deverão ser modificadas para permitir o tráfego de saída para a porta TCP especificada.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

A verificação de integridade URL caminho para verificações de integridade de HTTP e HTTPs. Essa anotação se aplica somente se ibm-load-balancer-cloud-provider-vpc-health-check-protocol for definido como http ou https. O caminho URL deve estar no formato de um destino de solicitação de formato de origem. Se essa anotação não for especificada e a anotação ibm-load-balancer-cloud-provider-vpc-health-check-protocol for definida como http ou https, o valor padrão / será aplicado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

O número de segundos de espera entre as tentativas de verificação de integridade. Por padrão, esse valor é definido como 5 e tem um mínimo de 2 e um máximo de 60. Esse valor deve ser maior que o valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que é definido como 2 por padrão.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

O número de segundos para aguardar uma resposta a uma verificação de integridade. Por padrão, esse valor é definido como 2 e tem um mínimo de 1 e um máximo de 59. Esse valor deve ser menor que o ibm-load-balancer-cloud-provider-vpc-health-check-delay, que é definido como 5 por padrão.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

O número máximo de novas tentativas de verificação de integridade para o balanceador de carga VPC. Por padrão, esse valor é definido como 2 e tem um mínimo de 1 e um máximo de 10.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

O tempo limite de conexão inativa do listener, em segundos. O tempo limite de inatividade padrão depende das configurações de sua conta. Normalmente, esse valor é 50. No entanto, algumas contas listadas para permissão têm configurações de tempo limite maiores. Se você não definir a anotação, seus balanceadores de carga usarão a configuração de tempo limite em sua conta. Você pode especificar explicitamente o tempo limite definindo essa anotação. O mínimo é 50. O valor máximo é 7200.

service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"

Versão 4.17 ou posterior.

Registre o endereço IP do balanceador de carga com o domínio de ingresso especificado. Se o domínio especificado não existir, será criado um domínio que usa o provedor gerenciado interno da IBM (IBM NS1). Para criar um novo domínio, o nome deve ser exclusivo em todos os domínios existentes (não apenas naqueles em seu cluster). A exclusão do serviço de balanceador de carga remove o endereço IP do domínio. No entanto, a remoção da anotação não remove o endereço IP do domínio.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

Versão 4.15 ou posterior.

O DNS instance a ser associado a este balanceador de carga. Para obter mais informações, consulte Registrar um registro DNS privado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

Versão 4.15 ou posterior.

O DNS zone a ser associado a este balanceador de carga. Para obter mais informações, consulte Registrar um registro DNS privado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

O número de nós de trabalho por zona para os quais o balanceador de carga roteia. O valor padrão é 8. Para um cluster com nós de trabalho em três zonas, isso faz com que o balanceador de carga encaminhe o tráfego para um total de 24 nós de trabalho. O número total de nós de trabalho em todas as zonas para as quais o balanceador de carga roteia não pode exceder 50. Se o cluster tiver menos de 50 nós de trabalho em todas as zonas, especifique 0 para rotear para todos os nós de trabalho em uma zona.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

Versão 1.30 ou posterior.

Um grupo de segurança gerenciado pelo cliente a ser adicionado ao balanceador de carga VPC. Se não quiser usar o grupo de segurançaIBM, especifique um grupo de segurança que você possui e gerencia. Essa opção remove o grupo de segurança IBM e o substitui pelo grupo de segurança que você especificar. A remoção da anotação de um balanceador de carga existente substitui o grupo de segurança que você adicionou pelo grupo de segurança IBM. Você pode adicionar ou remover essa anotação a qualquer momento. Você é responsável por gerenciar seu grupo de segurança e mantê-lo atualizado.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic

Disponível para clusters que executam Secure by Default. Anotação para criar grupos de segurança para cada endereço IP de um ALB associado a uma porta externa que você especificar. Essas regras são criadas no grupo de segurança do cluster e são atualizadas automaticamente se o endereço IP do VPC ALB for alterado. Especifique as portas externas válidas em uma lista separada por vírgulas, como 80,443. Neste exemplo, se cada ALB público associado a cada valor de porta externa tiver dois endereços IP, será criada uma regra de saída por endereço IP, em um total de 4 novas regras. Você pode adicionar ou remover essa anotação a qualquer momento.

selector

A chave de rótulo (<selector_key>) e o valor (<selector_value>) usados na seção spec.template.metadata.labels do YAML de implementação do app. Esse rótulo customizado identifica todos os pods nos quais seu app é executado para incluí-los no balanceamento de carga.

port

A porta na qual o serviço atende.

targetPort

A porta para a qual o serviço direciona o tráfego. O aplicativo em execução no pod deve estar à escuta para tráfego de entrada TCP nessa porta de destino. A porta de destino geralmente é definida estaticamente na imagem que está sendo executada no pod do aplicativo. A porta de destino configurada no pod é diferente da porta do nó para o serviço e também pode ser diferente da porta externa que está configurada no VPC LB.

a-z0-9- ↩︎