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.
Requisitos mínimos
| Componente | Requisito mínimo | Más información |
|---|---|---|
| vCenter Server y ESXi | vSphere 7.0 Update 2 | Consulte las notas de la versión. |
| Clúster supervisor | v1.19.1+vmware.2-vsc0.0.8-17610687 |
Consulte Actualizar clúster supervisor mediante una actualización de los espacios de nombres de vSphere. |
| Equilibrador de carga | NSX-T Data Center v3.1 O NSX Advanced 20.1.x |
Consulte las notas de la versión. |
| Versión de Tanzu Kubernetes | Una de las versiones más recientes de Tanzu Kubernetes. | Consulte Comprobar la compatibilidad del clúster de Tanzu Kubernetes para actualizar. |
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. Consulte Ejemplo del servicio del equilibrador de carga de Tanzu Kubernetes.
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ó.
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.
- apiGroups: - "" resources: - services/status verbs: - patch
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 acceso de desarrollador a clústeres de Tanzu Kubernetes. Para obtener una plantilla de función de ejemplo que pueda personalizar, consulte Función de ejemplo para la directiva de seguridad de pods. 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.
