Puede configurar un servicio de Kubernetes de tipo LoadBalancer para que utilice una dirección IP estática. Tenga en cuenta los requisitos de componente mínimos, un importante aspecto sobre seguridad y las instrucciones de fortalecimiento del clúster cuando implemente esta función.

Usar una IP estática en un servicio de tipo LoadBalancer

Por lo general, cuando se define un servicio de Kubernetes de Tipo LoadBalancer, el equilibrador de carga asigna una dirección IP efímera.

También puede especificar una dirección IP estática para el equilibrador de carga. Al crear el servicio, la instancia del equilibrador de carga se aprovisiona con la dirección IP estática que asignó.

El siguiente servicio de ejemplo demuestra cómo configurar un equilibrador de carga compatible con una dirección IP estática. En la especificación de servicio, se incluyen el parámetro loadBalancerIP y un valor de dirección IP, el cual es 10.11.12.49 en este ejemplo. 
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 NSX Advanced Load Balancer, utilice una dirección IP del grupo de IPAM que se configuró para el equilibrador de carga cuando se instaló. Cuando se crea el servicio y se asigna la dirección IP estática, el equilibrador de carga la marca como asignada y administra el ciclo de vida de la dirección IP de la misma forma que una dirección IP efímera. Es decir, si se elimina el servicio, la dirección IP no está asignada y se vuelve disponible para reasignarla.

En el caso del equilibrador de carga de NSX-T, tiene dos opciones. El mecanismo predeterminado es el mismo que en NSX Advanced Load Balancer: utilice una dirección IP tomada del grupo de direcciones IP que se configuró para el equilibrador de carga cuando se instaló. Cuando se asigna la dirección IP estática, el equilibrador de carga la marca automáticamente como asignada y administra su ciclo de vida.

La segunda opción de NSX-T consiste en preasignar manualmente la dirección IP estática. En este caso, se utiliza una dirección IP que no forma parte del grupo de direcciones IP del equilibrador de carga externo asignado al equilibrador de carga, sino que se toma de un grupo de direcciones IP flotantes. En este caso, administra manualmente la asignación y el ciclo de vida de la dirección IP mediante NSX Manager.

Requisitos importantes de fortalecimiento y consideración de seguridad

Puede producirse un problema de seguridad que se debe tener en cuenta al utilizar esta función. Si un desarrollador puede revisar el valor de Service.status.loadBalancerIP, es posible que el desarrollador pueda secuestrar el tráfico en el clúster destinado para la dirección IP con revisiones. En concreto, si una función o ClusterRole con el permiso patch está enlazada a una cuenta de usuario o servicio en un clúster donde esté implementada esta función, ese propietario de cuenta puede usar sus propias credenciales para emitir comandos kubectl y cambiar la dirección IP estática asignada al equilibrador de carga.

Para evitar las posibles implicaciones de seguridad que tiene usar la asignación de direcciones IP estáticas para un servicio de equilibrador de carga, debe fortalecer cada clúster en el que vaya a implementar esta función. Para ello, la función o ClusterRole que defina para cualquier desarrollador no debe permitir el verbo patch para apiGroups:"" y resources: services/status. El fragmento de función de ejemplo demuestra lo que no se debe hacer al implementar esta función.

NO PERMITIR LA REVISIÓN 
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - patch
Para comprobar si un desarrollador tiene permisos de revisión, ejecute el siguiente comando como ese usuario: 
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status

Si el comando devuelve yes, el usuario tiene permisos de revisión. Consulte Comprobación de acceso a la API (Checking API Access) en la documentación de Kubernetes para obtener más información.

Para conceder al desarrollador acceso a un clúster, consulte .Conceder a los desarrolladores acceso de vCenter SSO a los clústeres de Servicio TKG. Para obtener una plantilla de función de ejemplo que pueda personalizar, consulte Aplicar la directiva de seguridad de pods predeterminada a clústeres de servicio TKG. Para obtener un ejemplo sobre cómo restringir el acceso al clúster, consulte https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.