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
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.
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.
- apiGroups: - "" resources: - services/status verbs: - patch
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 .