È possibile configurare un servizio Kubernetes di tipo LoadBalancer per utilizzare un indirizzo IP statico. Prima di implementare questa funzionalità, esaminare con attenzione i requisiti minimi dei componenti, una considerazione di sicurezza importante e una guida alla protezione avanzata del cluster.
Requisiti minimi
| Componente | Requisito minimo | Ulteriori informazioni |
|---|---|---|
| vCenter Server ed ESXi | vSphere 7.0 Update 2 | Vedere le Note di rilascio. |
| Cluster supervisore | v1.19.1+vmware.2-vsc0.0.8-17610687 |
Vedere Aggiornamento dei Cluster supervisore eseguendo un aggiornamento degli spazi dei nomi vSphere. |
| Bilanciamento del carico | NSX-T Data Center v3.1 Oppure NSX Advanced 20.1.x |
Vedere le Note di rilascio. |
| Versione di Tanzu Kubernetes | Una delle versioni più recenti di Tanzu Kubernetes. | Vedere Elenco di Release di Tanzu Kubernetes. |
Utilizzo di un IP statico per un servizio di tipo LoadBalancer
In genere quando si definisce un servizio Kubernetes di tipo LoadBalancer, si ottiene un indirizzo IP temporaneo assegnato dal bilanciamento del carico. Vedere Esempio di bilanciamento del carico del servizio Tanzu Kubernetes.
In alternativa, è possibile specificare un indirizzo IP statico per il bilanciamento del carico. Alla creazione del servizio, viene eseguito il provisioning dell'istanza del bilanciamento del carico con l'indirizzo IP statico assegnato.
loadBalancerIP e un valore di indirizzo IP, che in questo esempio è
10.11.12.49.
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
Per NSX Advanced Load Balancer, si utilizza un indirizzo IP del pool IPAM configurato per il bilanciamento del carico al momento dell'installazione. Quando il servizio viene creato e viene assegnato l'indirizzo IP statico, il bilanciamento del carico lo contrassegna come allocato e gestisce il ciclo di vita dell'indirizzo IP nello stesso modo di un indirizzo IP temporaneo. Ciò significa che, se il servizio viene rimosso, viene annullata l'assegnazione dell'indirizzo IP che è quindi di nuovo disponibile per la riassegnazione.
Per il bilanciamento del carico NSX-T, sono disponibili due opzioni. Il meccanismo predefinito è uguale a quello di NSX Advanced Load Balancer e consiste nell'utilizzo di un indirizzo IP recuperato dal pool di IP configurato per il bilanciamento del carico al momento dell'installazione. Quando viene assegnato l'indirizzo IP statico, il bilanciamento del carico lo contrassegna automaticamente come allocato e ne gestisce il ciclo di vita.
La seconda opzione di NSX-T consiste nel preallocare manualmente l'indirizzo IP statico. In questo caso si utilizza un indirizzo IP che non fa parte del pool IP del bilanciamento del carico esterno assegnato al bilanciamento del carico, ma viene invece recuperato da un pool di IP mobili. In questo caso, l'allocazione e il ciclo di vita dell'indirizzo IP vengono amministrati manualmente utilizzando NSX Manager.
Considerazione importante sulla sicurezza e requisiti di protezione avanzata
È necessario tenere in considerazione un potenziale problema di sicurezza quando si utilizza questa funzionalità. Se uno sviluppatore è in grado di modificare il valore di Service.status.loadBalancerIP, può assumere il controllo del traffico nel cluster destinato all'indirizzo IP modificato. In particolare, se un ruolo o un ruolo cluster con l'autorizzazione patch è associato a un servizio o un account utente in un cluster in cui questa funzionalità è implementata, il proprietario di tale account può utilizzare le proprie credenziali per creare comandi kubectl e modificare l'indirizzo IP statico assegnato al bilanciamento del carico.
Per evitare le potenziali implicazioni di sicurezza dell'utilizzo dell'allocazione IP statica per un servizio di bilanciamento del carico, è necessario proteggere ciascun cluster in cui si implementa questa funzionalità. A tale scopo, il ruolo o il ruolo cluster definito per uno sviluppatore non deve consentire il verbo patch per apiGroups:"" e resources: services/status. Il frammento di ruolo di esempio mostra cosa non fare quando si implementa questa funzionalità.
- apiGroups: - "" resources: - services/status verbs: - patch
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status
Se il comando restituisce yes, l'utente dispone delle autorizzazioni di patch. Per ulteriori informazioni, vedere Controllo dell'accesso all'API nella documentazione di Kubernetes.
Per concedere l'accesso di sviluppatore a un cluster, vedere Concessione dell'accesso agli sviluppatori ai cluster di Tanzu Kubernetes. Per un modello di ruolo di esempio che è possibile personalizzare, vedere Ruolo di esempio per il criterio di sicurezza pod. Per un esempio su come limitare l'accesso al cluster, vedere https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example.
