Você pode configurar um serviço do Kubernetes do tipo LoadBalancer para usar um endereço IP estático. Esteja ciente dos requisitos mínimos de componentes, de uma importante consideração de segurança e das orientações de proteção do cluster antes de implementar esse recurso.
Usando um IP estático para um serviço do tipo LoadBalancer
Normalmente, quando você define um serviço Kubernetes do tipo LoadBalancer, obtém um endereço IP efêmero atribuído pelo balanceador de carga.
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.
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 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 faz 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 do 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 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 sim obtido de um pool de IPs flutuante. Nesse caso, você administra manualmente a alocação e o ciclo de vida do endereço IP usando o NSX Manager.
Consideração importante de segurança e requisito de proteção
Há um possível problema de segurança do qual você deve estar ciente ao usar esse recurso. Se um desenvolvedor puder corrigir o valor Service.status.loadBalancerIP, o desenvolvedor poderá sequestrar o tráfego no cluster destinado ao endereço IP corrigido. Especificamente, se uma Função ou ClusterRole com a permissão patch estiver associada a um serviço ou conta de usuário em um cluster em que esse recurso é implementado, o proprietário dessa conta poderá usar suas próprias credenciais para emitir comandos kubectl e alterar a propriedade estática 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 snippet de função de exemplo demonstra o que não fazer ao implementar esse recurso.
- apiGroups: - "" resources: - services/status verbs: - patch
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status
Se o comando retornar yes, o usuário terá permissões de patch. Consulte Verificando o acesso à API na documentação do Kubernetes para obter mais informações.
Para conceder acesso de desenvolvedor a um cluster, consulte .Conceder aos desenvolvedores vCenter acesso SSO a clusters TKG 2 em Supervisor. Para obter um modelo de função de amostra que você pode personalizar, consulte Exemplo de RBAC para política de segurança de pod. Para obter um exemplo de como restringir o acesso ao cluster, consulte https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.
