Gerenciamento de balanceadores de carga VPC

Faça alterações em seus balanceadores de carga VPC existentes.

Não renomeie nenhum NLB ou ALB de VPC. Renomear um balanceador de carga VPC cria um erro para o serviço Kubernetes LoadBalancer, o que pode interromper sua carga de trabalho.

Balanceadores de carga VPC persistentes

Por padrão, os balanceadores de carga VPC são excluídos quando o cluster ao qual estão associados é excluído. No entanto, ao criar uma definição de serviço LoadBalancer, você pode tornar o balanceador de carga persistente para que ele permaneça disponível mesmo depois que o cluster for excluído. Um balanceador de carga VPC persistente pode ser aplicado a um cluster diferente depois que o cluster anterior for excluído.

Os nomes do balanceador de carga VPC são formatados como kube-<cluster_ID>-<kubernetes_lb_service_UID> por padrão. Quando um cluster é excluído, esse formato de nome especifica os balanceadores de carga associados que também são excluídos. Para garantir que o balanceador de carga não seja excluído quando você excluir um cluster, inclua a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name na definição de serviço LoadBalancer para dar ao balanceador de carga um nome exclusivo. O nome do balanceador de carga deve ser exclusivo em sua VPC e pode incluir apenas caracteres alfanuméricos minúsculos e hífens (-). A anotação pode ser aplicada a todos os tipos de balanceadores de carga VPC.

Você é responsável por excluir os balanceadores de carga VPC persistentes quando eles não forem mais necessários. Para excluir um balanceador de carga VPC persistente, exclua a definição de serviço Kubernetes LoadBalancer à qual o balanceador de carga VPC está associado.

Mover um balanceador de carga VPC de um cluster para outro

Os balanceadores de carga VPC persistentes podem ser desvinculados de um cluster VPC e, em seguida, anexados a outro. O novo cluster deve estar dentro da mesma VPC que o cluster original.

Desvinculação de um balanceador de carga VPC de um cluster

Os balanceadores de carga VPC são vinculados à definição de serviço Kubernetes LoadBalancer com a qual foram criados. Para desconectar um balanceador de carga VPC persistente de um cluster, você deve quebrar o vínculo com o serviço LoadBalancer. Isso torna o serviço LoadBalancer inutilizável, e ele pode ser excluído com segurança. O balanceador de carga VPC pode então ser anexado a um cluster diferente.

Para romper o vínculo entre o balanceador de carga VPC e o serviço LoadBalancer, você pode renomear o balanceador de carga VPC ou remover a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name da definição original do serviço LoadBalancer. Observe que essa é a única circunstância em que você deve renomear um balanceador de carga VPC, pois isso cria um erro para o recurso Kubernetes. No entanto, se o seu objetivo final for usar o balanceador de carga VPC em um cluster diferente, esse erro não interromperá sua carga de trabalho. Não renomeie o balanceador de carga da VPC se quiser manter o balanceador de carga no mesmo cluster.

Anexar um balanceador de carga VPC a um cluster

Depois que um balanceador de carga VPC persistente for desconectado de um cluster, você poderá anexá-lo a um cluster diferente criando uma nova definição de serviço Kubernetes LoadBalancer que faça referência ao balanceador de carga VPC.

Ao criar um novo serviço LoadBalancer no novo cluster, você pode usar a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name para especificar o nome do balanceador de carga VPC que deseja anexar.

Quando você cria o serviço LoadBalancer, o tipo de balanceador de carga VPC (ALB, NLB) e o tipo de IP (público, privado) devem corresponder às especificações do serviço LoadBalancer. Por exemplo, um serviço LoadBalancer existente no novo cluster que especifica um tipo de NLB não pode ser usado para anexar um VPC ALB ao cluster. As anotações que especificam o tipo de balanceador de carga e o tipo de IP são service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features e service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type.

As portas de porta e de nó especificadas no serviço LoadBalancer não precisam corresponder àquelas com as quais o balanceador de carga VPC foi criado. O balanceador de carga VPC é reconfigurado com as definições de porta do serviço LoadBalancer ao qual está associado no novo cluster.

Verificações de funcionamento para balanceadores de carga

Os balanceadores de carga VPC são configurados automaticamente com verificações de integridade, que você configura com a anotação externalTrafficPolicy. Você pode usar anotações adicionais para personalizar verificações de integridade em seus balanceadores de carga.

Se externalTrafficPolicy for configurado como Cluster, as verificações de funcionamento do TCP serão aplicadas. Se você estiver configurando um balanceador de carga UDP, deverá fazer especificações adicionais de porta.
Se externalTrafficPolicy for configurado como Local, as verificações de funcionamento HTTP são aplicadas. O tráfego de entrada é entregue somente ao pod de aplicativos que reside nesse nó específico. Se não houver nenhum pod de aplicativo nesse nó específico, o tráfego de entrada será descartado.

A configuração externalTrafficPolicy: Local pode causar falhas nas verificações de integridade dos nós de trabalho do balanceador de carga. Normalmente, esse resultado é o comportamento esperado e não indica necessariamente um problema, pois o tráfego é intencionalmente descartado se o balanceador de carga tentar se conectar a qualquer nó que não tenha um pod de aplicativo. Para obter mais informações, consulte Por que as verificações de integridade do balanceador de carga VPC estão falhando em meus nós de trabalho?.

Personalização de verificações de integridade para balanceadores de carga VPC

Para ter mais controle sobre as verificações de integridade do balanceador de carga VPC, é possível usar anotações opcionais para personalizar as verificações de integridade com configurações avançadas para intervalos de teste, tempos limite e novas tentativas. Você pode alterar ou remover essas personalizações a qualquer momento.

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

Opcional: essa anotação define o protocolo de verificação de integridade no recurso de balanceador de carga VPC associado ao serviço de balanceador de carga Kubernetes. Normalmente, o protocolo de verificação de integridade do VPC LB é determinado pelo valor da configuração externalTrafficPolicy na especificação de serviço do balanceador de carga Kubernetes. 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

Opcional. A porta TCP que é usada 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 a porta TCP especificada estiver fora do intervalo de portas do nó Kubernetes (30.000-32.767), o grupo de segurança VPC aplicado aos nós de trabalho do cluster deverá ser modificado para permitir o tráfego de entrada na porta.
Se essa anotação for aplicada a um serviço de balanceador de carga 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

Opcional. 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

Opcional. 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

Opcional. 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 valor 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.

Ativando verificações de funcionamento do TCP para balanceadores de carga UDP

Como não há verificações de funcionamento do UDP, os balanceadores de carga UDP que usam verificações de funcionamento do TCP devem ter uma porta TCP adicional especificada com a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp.

É possível especificar a porta do nó TCP para outro balanceador de carga ou NodePort em execução em seu cluster. Para o cluster 4.14 e anteriores, se a porta do nó residir fora do intervalo 30000-32767, você deverá modificar o grupo de segurança do cluster VPC kube-<cluster-ID> para permitir o tráfego de entrada para a porta especificada.

Observe que, se o valor de porta especificado for para um serviço que caiu inesperadamente ou teve seu valor de porta reconfigurado, as verificações de integridade do TCP deixarão de funcionar até que o serviço volte a funcionar ou você reconfigure a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp com um novo valor de porta TCP. Para evitar isso, é possível especificar a porta kubelet 10250, que é um valor de porta estática que não passa por interrupções de serviço. No entanto, para as versões de cluster 4.14 e anteriores, você deve modificar o grupo de segurança do cluster VPC kube-<cluster-ID> para aceitar o tráfego de entrada da porta kubelet.

Deseja evitar a complexidade de especificar portas TCP adicionais para verificações de integridade em um balanceador de carga UDP? Configure externalTrafficPolicy como Local para usar verificações de funcionamento HTTP, que não requerem especificações de porta adicionais.

Alterar a sub-rede ou a zona de um balanceador de carga

Depois de criar uma VPC NLB, você não poderá reconfigurar a sub-rede de escuta com a qual ela foi criada. Se quiser alterar a sub-rede de escuta de um VPC NLB existente, você deverá excluir, atualizar e reaplicar o serviço Kubernetes LoadBalancer correspondente.

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Liste os serviços de Kubernetes e encontre o nome do serviço LoadBalancer que deseja mudar.

oc get services

Exemplo de saída.

NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                        AGE
my-load-balancer         LoadBalancer   172.21.77.198   52.118.150.107   8080:32767/TCP,443:30943/TCP   5d

Localize o balanceador de carga da VPC que corresponde ao serviço LoadBalancer de Kubernetes.

Os nomes de balanceador de carga da VPC estão no formato kube-<cluster_ID>-<kubernetes_lb_service_UID>. Para ver seu ID de cluster, execute ibmcloud ks cluster get --cluster <cluster_name>. Para ver o UID do serviço LoadBalancer do Kubernetes, execute oc get svc <load-balancer-name> -o yaml e procure o campo metadata.uid na saída. Os hífens (-) são removidos do UID do serviço Kubernetes LoadBalancer no nome do balanceador de carga VPC.

ibmcloud is load-balancers

Exemplo de saída.

ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group      
r000-5aaaa11f6-c111-111f-b2e0-1c11aaaaf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf11111111fe4ca3f11111cb   Network       subnet-1                                  true        active             online             default                                                    Application

Obtenha a definição de serviço LoadBalancer de Kubernetes e salve a saída como um arquivo yaml chamado my-lb.yaml.
```
oc describe service my-load-balancer -o yaml
```
Excluir o serviço de Kubernetes LoadBalancer. Isso também exclui o balanceador de carga da VPC correspondente.
```
oc delete service my-load-balancer
```
Atualize o arquivo de definição de serviço LoadBalancer do Kubernetes com as mudanças de sub-rede ou zona que deseja implementar. Não mude o nome do serviço LoadBalancer. Para obter detalhes sobre a especificação de sub-redes ou zonas para balanceadores de carga de rede, consulte Configurando um Network Load Balancer para VPC.
Aplique o novo arquivo de definição LoadBalancer.
```
oc apply -f my-lb.yaml
```

Verifique se o serviço LoadBalancer de Kubernetes é recriado com sucesso no cluster. Quando o serviço é criado, o campo LoadBalancer Ingress é preenchido com um endereço IP externo para o NLB.

oc describe service my-load-balancer

Exemplo de saída.

NAME:                     my-load-balancer
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.X.XXX.XX
LoadBalancer Ingress:     169.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.XX.XX.XXX:8080,172.XX.XX.XX:8080,172.XX.XX.XX:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/my-load-balancer with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.

Verifique se o balanceador de carga da VPC é recriado e se a sub-rede ou zona é atualizada. Observe que leva alguns minutos para provisionar o balanceador de carga VPC e você poderá ver o status create_pending até que ele seja totalmente provisionado.

ibmcloud is load-balancers

Exemplo de saída.

ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group     
r006-5ecc68f6-c751-409f-b2e0-1c69babf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf03445796fe4ca3f73885cb   Network       subnet-2                                  true        active             online             default