Você pode configurar um serviço Kubernetes do tipo LoadBalancer para usar um endereço IP estático. Esteja ciente dos requisitos mínimos de componentes, uma consideração importante de segurança e orientações de reforço de cluster antes de implementar esse recurso.

Requisitos mínimos

O endereçamento de IP estático para serviços do Kubernetes do tipo LoadBalancer é compatível com clusters do Tanzu Kubernetes que atendem aos seguintes requisitos:
Componente Requisito mínimo Mais informações
vCenter Server e ESXi vSphere 7.0 Atualização 2 Consulte as notas da versão .
Cluster de Supervisor v1.19.1+vmware.2-vsc0.0.8-17610687 Consulte o Atualize o Supervisor Cluster realizando uma atualização de namespaces do vSphere.
Balanceador de Carga

NSX-T Data Center v3.1

ou

NSX Avançado 20.1.x

Consulte as notas da versão .
Versão do Tanzu Kubernetes Uma das versões mais recentes do Tanzu Kubernetes. Consulte o Lista de Tanzu Kubernetes releases.

Usando um IP estático para um serviço do tipo LoadBalancer

Normalmente, quando você define um serviço do Kubernetes do Type LoadBalancer , você obtém um endereço IP efêmero atribuído pelo balanceador de carga. Consulte o Exemplo de balanceador de carga de serviço do Tanzu Kubernetes.

Como alternativa, você pode especificar um endereço IP estático para o balanceador de carga. Na criação do serviço, a instância do balanceador de carga é provisionada com o endereço IP estático que você atribuiu.

O serviço de exemplo a seguir demonstra como configurar um balanceador de carga com suporte com um endereço IP estático. Na especificação do serviço, você inclui o parâmetro loadBalancerIP e um valor de endereço IP, que é 10.11.12.49 neste exemplo.
kind: Service
apiVersion: v1
metadata:
  name: load-balancer-service-with-static-ip
spec:
  selector:
    app: hello-world
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
  loadBalancerIP: 10.11.12.49

Para o balanceador de carga avançado NSX, use um endereço IP do pool de IPAM configurado para o balanceador de carga quando ele foi instalado. Quando o serviço é criado e o endereço IP estático é atribuído, o balanceador de carga o marca como alocado e gerencia o ciclo de vida do endereço IP da mesma forma que um endereço IP efêmero. Ou seja, se o serviço for removido, o endereço IP não será atribuído e será disponibilizado para realocação.

Para o balanceador de carga NSX-T, você tem duas opções. O mecanismo padrão é o mesmo que o NSX Balanceador de carga avançado: use um endereço IP obtido do pool de IPs configurado para o balanceador de carga quando ele foi instalado. Quando o endereço IP estático é atribuído, o balanceador de carga o marca automaticamente como alocado e gerencia seu ciclo de vida.

A segunda opção de NSX-T é pré-alocar manualmente o endereço IP estático. Nesse caso, você usa um endereço IP que não faz parte do pool de IPs do balanceador de carga externo atribuído ao balanceador de carga, mas é obtido de um pool de IPs flutuantes. Nesse caso, você administra manualmente a alocação e o ciclo de vida do endereço IP usando o NSX Manager.

Consideração de segurança importante e requisito de reforço

Há um possível problema de segurança a ser considerado ao usar esse recurso. Se um desenvolvedor puder corrigir o valor de Service.status.loadBalancerIP, o desenvolvedor poderá sequestrar o tráfego no cluster destinado ao endereço IP corrigido. Especificamente, se uma Role ou ClusterRole com a permissão patch estiver vinculada a uma conta de serviço ou de usuário em um cluster no qual esse recurso é implementado, o proprietário da conta poderá usar suas próprias credenciais para emitir comandos kubectl e alterar os comandos estáticos Endereço IP atribuído ao balanceador de carga.

Para evitar as possíveis implicações de segurança do uso da alocação de IP estático para um serviço de balanceador de carga, você deve proteger cada cluster no qual está implementando esse recurso. Para fazer isso, a função ou ClusterRole que você define para qualquer desenvolvedor não deve permitir o verbo patch para apiGroups:"" e resources: services/status. O trecho de função de exemplo demonstra o que não fazer ao implementar esse recurso.

NÃO PERMITIR PATCH
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - patch
Para verificar se um desenvolvedor tem permissões de patch, execute o seguinte comando como esse usuário:
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status

Se o comando retornar yes, o usuário tem permissões de patch. Consulte Como verificar o acesso à API na documentação do Kubernetes para obter mais informações.

Para conceder acesso de desenvolvedor a um cluster, consulte Conceder acesso de desenvolvedor a Tanzu Kubernetes clusters. Para obter um modelo de função de amostra que você pode personalizar, consulte Exemplo de função para a política de segurança do pod. Para obter um exemplo sobre como restringir o acesso ao cluster, consulte https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example .