Configurazione dei load balancer e dei load balancer di rete

Puoi creare load balancer e load balancer di rete Oracle Cloud Infrastructure per controllare l'accesso ai servizi in esecuzione su un cluster:

• Quando si crea un cluster nel workflow 'Creazione personalizzata', si seleziona una VCN esistente che contiene le risorse di rete che devono essere utilizzate dal nuovo cluster. Se si desidera utilizzare un load balancer o un load balancer di rete per controllare il traffico nella VCN, selezionare una subnet pubblica o privata esistente nella VCN per ospitarla.
• Quando crei un cluster nel workflow 'Creazione rapida', la VCN creata automaticamente contiene una subnet regionale pubblica in cui ospitare un load balancer o un load balancer di rete. Se desideri ospitare un load balancer o un load balancer di rete in una subnet privata, puoi aggiungere una subnet privata alla VCN in un secondo momento.

In alternativa, puoi definire un servizio Kubernetes interno di tipo LoadBalancer (spesso definito semplicemente "load balancer interno") in un cluster per consentire ad altri programmi in esecuzione nella stessa VCN del cluster di accedere ai servizi nel cluster. È possibile eseguire il provisioning di un load balancer interno:

• come load balancer o come load balancer di rete
• con un indirizzo IP pubblico o con un indirizzo IP privato (assegnato dal servizio Load balancer o dal servizio Load balancer di rete)
• in una subnet pubblica o in una subnet privata

Un load balancer o un load balancer di rete con un indirizzo IP pubblico viene definito pubblico. Un load balancer pubblico o di rete può essere gestito in hosting in una subnet pubblica o in una subnet privata.

Un load balancer o un load balancer di rete con un indirizzo IP privato viene definito privato. Un load balancer o un load balancer di rete privato può essere ospitato in una subnet pubblica o in una subnet privata.

Per impostazione predefinita, il provisioning dei load balancer interni viene eseguito con indirizzi IP pubblici e gestito in hosting in subnet pubbliche.

Ulteriori informazioni

• informazioni sui load balancer pubblici e privati di Oracle Cloud Infrastructure, vedere Tipi di load balancer.
• informazioni sui load balancer di rete pubblici e privati di Oracle Cloud Infrastructure, vedere Tipi di load balancer di rete

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 8100
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/internal: "true"
    oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Quando un servizio Kubernetes di tipo LoadBalancer viene distribuito su un cluster, Kubernetes Engine crea un load balancer pubblico o un load balancer di rete Oracle Cloud Infrastructure per accettare il traffico nel cluster. Per impostazione predefinita, al load balancer pubblico o al load balancer di rete di Oracle Cloud Infrastructure viene assegnato un indirizzo IP pubblico effimero. Tuttavia, un indirizzo IP pubblico effimero è temporaneo e dura solo per tutta la durata del load balancer pubblico o del load balancer di rete.

Se desideri che il load balancer pubblico o il load balancer di rete Oracle Cloud Infrastructure creato da Kubernetes Engine abbia lo stesso indirizzo IP pubblico dopo la distribuzione, puoi assegnargli un indirizzo IP pubblico riservato dal pool di indirizzi IP pubblici riservati. Per ulteriori informazioni sulla creazione e la visualizzazione di indirizzi IP pubblici riservati, vedere Indirizzo IP pubblico.

Per assegnare un indirizzo IP pubblico riservato al load balancer pubblico di Oracle Cloud Infrastructure o al load balancer di rete creato da Kubernetes Engine, aggiungere la proprietà LoadBalancerIP nella sezione delle specifiche del file manifest che definisce il servizio di tipo LoadBalancer e specificare l'indirizzo IP pubblico riservato.

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Tenere presente quanto riportato di seguito.

• Se imposti la proprietà loadBalancerIP del servizio LoadBalancer, in seguito non potrai modificare direttamente l'indirizzo IP del load balancer pubblico o del load balancer di rete di Oracle Cloud Infrastructure creato da Kubernetes Engine. Se si desidera modificare l'indirizzo IP, eliminare il servizio LoadBalancer, specificare un indirizzo IP pubblico riservato diverso nel file manifesto e distribuire di nuovo il servizio LoadBalancer.
• Se non si imposta la proprietà loadBalancerIP del servizio LoadBalancer, in seguito non sarà possibile passare direttamente all'indirizzo IP del load balancer pubblico o del load balancer di rete Oracle Cloud Infrastructure creato da Kubernetes Engine da un indirizzo IP effimero a un indirizzo IP pubblico riservato. Se si desidera cambiare l'indirizzo IP effimero in un indirizzo IP pubblico riservato, eliminare il servizio di tipo LoadBalancer, impostare la proprietà loadBalancerIP su un indirizzo IP pubblico riservato nel file manifesto e distribuire di nuovo il servizio di tipo LoadBalancer.
• È possibile eliminare il servizio di tipo LoadBalancer e rilasciare l'indirizzo IP pubblico riservato per altri usi (ad esempio, per assegnarlo a un altro servizio di tipo LoadBalancer).
• Non è possibile specificare un indirizzo IP pubblico riservato per un servizio di tipo LoadBalancer se lo stesso indirizzo IP è già assegnato a un'altra risorsa (ad esempio un'istanza di computazione o un altro servizio di tipo LoadBalancer).
• Non è possibile aggiungere la proprietà loadBalancerIP al file manifest per un servizio di load balancer interno, ovvero un file manifest che include l'annotazione service.beta.kubernetes.io/oci-load-balancer-internal: "true" o oci-network-load-balancer.oraclecloud.com/internal: "true".

• Per impostazione predefinita, l'indirizzo IP pubblico riservato specificato come proprietà loadBalancerIP di un servizio di tipo LoadBalancer nel file manifesto dovrebbe essere una risorsa nello stesso compartimento del cluster. Se si desidera specificare un indirizzo IP pubblico riservato in un compartimento diverso:

  • per i load balancer pubblici, aggiungere il criterio seguente alla tenancy:

    ALLOW any-user to read public-ips in tenancy where request.principal.type = 'cluster'
    ALLOW any-user to manage floating-ips in tenancy where request.principal.type = 'cluster'

  • per i load balancer di rete, aggiungere il criterio seguente alla tenancy:

    ALLOW any-user to use private-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id = 'target.compartment.id'}
    ALLOW any-user to manage public-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id = 'target.compartment.id'}

I gruppi di sicurezza di rete (NSG) di Oracle Cloud Infrastructure ti consentono di controllare il traffico in entrata e in uscita dalle risorse e tra le risorse. Le regole di sicurezza definite per un gruppo NSG garantiscono che tutte le risorse presenti in tale gruppo NSG abbiano lo stesso livello di sicurezza. Per ulteriori informazioni, vedere Gruppi di sicurezza di rete.

Puoi utilizzare i gruppi NSG per controllare l'accesso al load balancer o al load balancer di rete Oracle Cloud Infrastructure di cui Kubernetes Engine esegue il provisioning per un servizio Kubernetes di tipo LoadBalancer.

Quando si utilizzano i gruppi NSG per controllare l'accesso, devono esistere regole di sicurezza appropriate per consentire il traffico in entrata e in uscita verso e dalla subnet del load balancer o del load balancer di rete. Vedere Regole di sicurezza per i load balancer e i load balancer di rete.

Se decidi di utilizzare i gruppi NSG per controllare l'accesso ai load balancer o ai load balancer di rete:

• I gruppi NSG e le regole di sicurezza possono essere gestiti interamente per l'utente da oci-cloud-controller-manager (vedere Specifica delle opzioni di gestione delle regole di sicurezza per i load balancer e i load balancer di rete).
• Puoi gestire i gruppi NSG e le regole di sicurezza personalmente e aggiungere il load balancer o il load balancer di rete ai gruppi NSG esistenti (come descritto in questa sezione).
• È possibile fare in modo che oci-cloud-controller-manager gestisca alcune regole di sicurezza in un gruppo NSG, mentre si gestiscono altre regole di sicurezza in un gruppo NSG diverso.

Per controllare l'accesso utilizzando un gruppo NSG gestito, includere annotazioni nel file manifest per specificare il gruppo NSG a cui si desidera aggiungere il load balancer o il load balancer di rete.

oci.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Tenere presente quanto riportato di seguito.

• Il gruppo NSG specificato deve trovarsi nella stessa VCN del load balancer o del load balancer di rete Oracle Cloud Infrastructure.
• Se il gruppo NSG specificato appartiene a un altro compartimento del cluster, in un criterio IAM è necessario includere un'istruzione criterio simile alla seguente:

  ALLOW any-user to use network-security-groups in TENANCY where ALL { request.principal.type = 'cluster' }

  Se si considera questa istruzione dei criteri troppo permissiva, è possibile limitare l'autorizzazione a specificare in modo esplicito il compartimento a cui appartiene il gruppo NSG e/o a specificare in modo esplicito il cluster. Ad esempio:

  Allow any-user to use network-security-groups in compartment <compartment-ocid> where all { request.principal.id = '<cluster-ocid>' }

• È possibile specificare fino a cinque gruppi NSG, in un elenco separato da virgole, nel formato seguente:

  oci.oraclecloud.com/oci-network-security-groups: "<nsg1-ocid>,<nsg2-ocid>,<nsg3-ocid>,<nsg4-ocid>,<nsg5-ocid>"

• Per rimuovere un load balancer o un load balancer di rete da un gruppo NSG o modificare il gruppo NSG in cui si trova il load balancer o il load balancer di rete, aggiornare l'annotazione e riapplicare il file manifesto.

• Se decidi di controllare l'accesso a un load balancer o a un load balancer di rete Oracle Cloud Infrastructure utilizzando un gruppo NSG gestito dall'utente, Oracle consiglia di disabilitare la gestione delle liste di sicurezza Kubernetes aggiungendo una delle annotazioni seguenti nella sezione dei metadati del file manifest rispettivamente per il load balancer o il load balancer di rete:

  service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: "None"

  oci-network-load-balancer.oraclecloud.com/security-list-management-mode:  "None"

  In alternativa, è possibile aggiungere la seguente annotazione equivalente:

  oci.oraclecloud.com/security-rule-management-mode: "None" 

  Se si segue il suggerimento e si aggiunge l'annotazione, la gestione della lista di sicurezza Kubernetes non è abilitata. È necessario impostare i gruppi NSG con regole di sicurezza in entrata e in uscita per i pool di nodi e per l'endpoint API Kubernetes. Per ulteriori informazioni, vedere Configurazione delle regole di sicurezza nei gruppi di sicurezza di rete e/o nelle liste di sicurezza e Configurazioni delle risorse di rete di esempio. È inoltre necessario impostare i gruppi NSG con regole di sicurezza in entrata e in uscita per la porta di integrità kube-proxy, per l'intervallo di porte di controllo dello stato e per i load balancer.

Le regole di sicurezza controllano l'accesso ai load balancer e ai load balancer di rete Oracle Cloud Infrastructure di cui viene eseguito il provisioning per i servizi Kubernetes di tipo LoadBalancer. Le regole di sicurezza possono essere gestite (ovvero create, aggiornate ed eliminate) nei modi riportati di seguito.

• In un gruppo di sicurezza di rete o in un gruppo NSG (consigliato) Le regole di sicurezza in un gruppo NSG si applicano a qualsiasi risorsa Kubernetes aggiunta al gruppo NSG. Pertanto, i gruppi NSG possono fornire un controllo dell'accesso dettagliato alle singole risorse.
• In una lista di sicurezza. Le regole di sicurezza in una lista di sicurezza si applicano a tutte le risorse Kubernetes in una subnet. Gli elenchi di sicurezza non forniscono un controllo dell'accesso con filtro alle singole risorse nella subnet.

Per informazioni importanti sul funzionamento delle regole di sicurezza e un confronto generale tra liste di sicurezza e gruppi di sicurezza di rete, vedere Regole di sicurezza.

È possibile gestire le regole di sicurezza personalmente, creando, aggiornando ed eliminando le regole in base alle esigenze. In alternativa, è possibile specificare che oci-cloud-controller-manager (che viene eseguito sul piano di controllo del cluster) deve gestire automaticamente alcune o tutte le regole di sicurezza. Kubernetes Engine utilizza oci-cloud-controller-manager per eseguire il provisioning dei load balancer e dei load balancer di rete per i servizi Kubernetes di tipo LoadBalancer.

È possibile utilizzare annotazioni diverse per specificare se oci-cloud-controller-manager gestisce le regole di sicurezza per un load balancer o un load balancer di rete in un gruppo NSG o in una lista di sicurezza, come riportato di seguito.

• Per gestire le regole di sicurezza in un gruppo NSG, utilizzare l'annotazione oci.oraclecloud.com/security-rule-management-mode: "NSG" (consigliata).

  Se si desidera che oci-cloud-controller-manager gestisca le regole di sicurezza in un gruppo NSG (come consigliato da Oracle), è necessario utilizzare l'annotazione oci.oraclecloud.com/security-rule-management-mode: "NSG". Per ulteriori informazioni sull'uso di questa annotazione, vedere Utilizzo dell'annotazione oci.oraclecloud.com/security-rule-management-mode per gestire le regole di sicurezza nei gruppi NSG e nelle liste di sicurezza.

• Per gestire le regole di sicurezza in una lista di sicurezza, utilizzare l'annotazione oci.oraclecloud.com/security-rule-management-mode oppure le annotazioni service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode e oci-network-load-balancer.oraclecloud.com/security-list-management-mode.

  Se si desidera che oci-cloud-controller-manager gestisca le regole di sicurezza nella lista di sicurezza di un load balancer o della subnet del load balancer di rete, effettuare una delle operazioni riportate di seguito.

  • Utilizzare l'annotazione oci.oraclecloud.com/security-rule-management-mode, impostata su "SL-All" o "SL-Frontend". Per ulteriori informazioni sull'uso di questa annotazione, vedere Utilizzo dell'annotazione oci.oraclecloud.com/security-rule-management-mode per gestire le regole di sicurezza nei gruppi NSG e nelle liste di sicurezza.
  • Utilizzare le annotazioni service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode e oci-network-load-balancer.oraclecloud.com/security-list-management-mode rispettivamente, impostate su "All" o "Frontend". Per ulteriori informazioni sull'uso di queste due annotazioni, vedere rispettivamente Specifica delle opzioni di gestione delle liste di sicurezza durante il provisioning di un load balancer OCI e Specifica delle opzioni di gestione delle liste di sicurezza durante il provisioning di un load balancer di rete OCI.

Indipendentemente dalle annotazioni utilizzate e indipendentemente dal fatto che l'utente o oci-cloud-controller-manager gestisca le regole di sicurezza in una lista di sicurezza o in un gruppo NSG, è inoltre possibile specificare l'OCID di uno o più gruppi NSG aggiuntivi a cui si desidera che oci-cloud-controller-manager aggiunga il load balancer o il load balancer di rete. In questo caso, utilizzare l'annotazione oci.oraclecloud.com/oci-network-security-groups o oci-network-load-balancer.oraclecloud.com/oci-network-security-groups. Si noti che oci-cloud-controller-manager non gestisce le regole di sicurezza nei gruppi NSG aggiuntivi specificati da queste annotazioni, pertanto è responsabilità dell'utente gestire le regole di sicurezza. Per ulteriori informazioni sull'uso delle annotazioni oci.oraclecloud.com/oci-network-security-groups o oci-network-load-balancer.oraclecloud.com/oci-network-security-groups, vedere Specifica dei gruppi di sicurezza di rete (consigliato).

I load balancer e i load balancer di rete Oracle Cloud Infrastructure applicano un criterio di controllo dello stato per monitorare continuamente i server backend. Un controllo dello stato è un test per confermare la disponibilità del server backend e può essere una richiesta o un tentativo di connessione. Se un server non supera il controllo dello stato, il load balancer o il load balancer di rete eliminano temporaneamente la rotazione del server. Se il server supera successivamente il controllo dello stato, il load balancer o il load balancer di rete lo restituisce alla rotazione.

I criteri di controllo dello stato includono un numero di parametri, ciascuno dei quali ha un valore predefinito. Quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete OCI per un servizio Kubernetes di tipo LoadBalancer, è possibile eseguire l'override dei valori predefiniti dei parametri di controllo dello stato includendo le annotazioni nella sezione dei metadati del file manifest. In seguito sarà possibile aggiungere, modificare ed eliminare tali annotazioni. Se si elimina un'annotazione che ha specificato un valore per un parametro di controllo dello stato, il load balancer o il load balancer di rete utilizza invece il valore predefinito del parametro.

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-health-check-retries: "5"
    service.beta.kubernetes.io/oci-load-balancer-health-check-interval: "15000"
    service.beta.kubernetes.io/oci-load-balancer-health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/health-check-retries: "5"
    oci-network-load-balancer.oraclecloud.com/health-check-interval: "15000"
    oci-network-load-balancer.oraclecloud.com/health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Tenere presente che se non si specificano in modo esplicito i valori dei parametri di controllo dello stato includendo annotazioni nella sezione metadati del file manifesto, vengono utilizzati i valori predefiniti riportati di seguito.

Per ulteriori informazioni sui criteri di controllo dello stato del load balancer e del load balancer di rete di Oracle Cloud Infrastructure, vedere:

• Controlli dello stato per i load balancer
• Criteri di controllo dello stato per i load balancer di rete

Il traffico in entrata verso un load balancer o un load balancer di rete Oracle Cloud Infrastructure viene distribuito tra i server backend in un set backend. Per impostazione predefinita, quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, tutti i nodi di lavoro nel cluster vengono inclusi nel set backend.

Tuttavia, hai la possibilità di selezionare solo un subset di nodi di lavoro in un cluster da includere nel set backend di un determinato load balancer o load balancer di rete. L'inclusione di subset dei nodi di lavoro di un cluster nei set backend di diversi load balancer e load balancer di rete consente di presentare un singolo cluster Kubernetes come più cluster logici (servizi).

oci.oraclecloud.com/node-label-selector: <label>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/node-label-selector: <label>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Utilizzare la notazione standard del selettore di etichette Kubernetes per specificare le chiavi e i valori di etichetta nelle annotazioni nella sezione dei metadati del file manifesto. Per ulteriori informazioni sulla notazione standard del selettore di etichette Kubernetes, vedere Selettori di etichette nella documentazione di Kubernetes.

La tabella fornisce alcuni esempi di notazione standard del selettore di etichette Kubernetes.

Quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete per un servizio Kubernetes di tipo LoadBalancer, è possibile definire un criterio per il set backend in modo da specificare la modalità di distribuzione del traffico in entrata ai server backend.

Ulteriori informazioni

• Informazioni sui load balancer e sui criteri dei set backend. Vedere Criteri del load balancer.
• Informazioni sui load balancer di rete e sui criteri dei set backend. Vedere Criteri del load balancer di rete.

oci.oraclecloud.com/loadbalancer-policy: <value>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/loadbalancer-policy: "LEAST_CONNECTIONS"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/backend-policy: <value>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/backend-policy: "THREE_TUPLE"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, è possibile utilizzare un gate di idoneità pod per garantire che il traffico venga instradato solo ai pod che sono stati aggiunti correttamente al set backend e che sono pronti a ricevere il traffico. Tenere presente che è possibile specificare i punti di idoneità dei pod per i pod in esecuzione sui nodi virtuali, ma non per i pod in esecuzione sui nodi gestiti. Non definire i gate di idoneità pod per i pod in esecuzione sui nodi gestiti.

I gate di prontezza pod sono condizioni aggiuntive per indicare che un pod è pronto a ricevere traffico. I punti di prontezza dei pod consentono di implementare complessi controlli di prontezza personalizzati e possono aiutare a ottenere zero tempi di inattività durante le distribuzioni in sequenza. Per ulteriori informazioni, consulta i dettagli sulla disponibilità dei pod nella documentazione di Kubernetes.

Quando si esegue il provisioning di un load balancer o di un load balancer di rete, il set backend comprende gli indirizzi IP delle repliche pod di una distribuzione con condizione Ready. L'aggiornamento della distribuzione (ad esempio, per utilizzare una nuova immagine) attiva la sostituzione delle repliche pod esistenti con nuove repliche pod. Tuttavia, la sostituzione di tutte le repliche pod può richiedere del tempo e causare l'indisponibilità backend perché:

• Le repliche pod esistenti potrebbero essere interrotte prima che il set backend sia stato aggiornato con gli indirizzi IP delle nuove repliche pod.
• Il set backend potrebbe essere aggiornato con gli indirizzi IP delle nuove repliche pod prima che le nuove repliche pod siano pronte per ricevere il traffico.

La specifica dell'uso di un controllo di idoneità pod garantisce che i backend siano sempre disponibili per il load balancer o il load balancer di rete. I pod esistenti non vengono interrotti fino a quando non vengono aggiunti nuovi pod al set backend e i nuovi pod sono pronti a ricevere traffico.

Per specificare che Kubernetes Engine deve inserire un controllo di prontezza pod nella specifica pod di ogni pod creato in un determinato spazio di nomi, aggiungere l'etichetta loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled allo spazio di nomi immettendo:

kubectl label ns <namespace> loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

L'esempio riportato di seguito mostra come creare un load balancer con un controllo di idoneità pod.

In primo luogo, assegnare un'etichetta allo spazio di nomi pdr per specificare il gate di idoneità pod per lo spazio di nomi immettendo:

kubectl label ns pdr loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

L'output del comando conferma che lo spazio di nomi è stato etichettato:

namespace/pdr labeled

Quindi, distribuire Nginx nello spazio di nomi pdr immettendo:

kubectl apply -f https://raw.githubusercontent.com/oracle-devrel/oci-oke-virtual-nodes/main/nginx-svc/nginx.yaml -n pdr

Elencare i pod nello spazio di nomi pdr immettendo:

kubectl get pods -n pdr

Ora puoi dimostrare l'uso del pod readiness gate aggiornando la versione dell'immagine nel manifesto Nginx e riapplicando il manifesto, in modo che i pod esistenti vengano sostituiti con nuovi pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.1
...

Per riapplicare il manifesto, inserendo:

kubectl apply -f ./nginx.yaml -n pdr

Osservare i nuovi pod in fase di implementazione immettendo:

kubectl get pods -o wide -n pdr

Ad esempio:

NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES
nginx-678976847c-8bqs7   1/1     Running   0          44m   10.0.10.153   10.0.10.253   <none>           1/1
nginx-678976847c-ttqms   1/1     Running   0          47m   10.0.10.201   10.0.10.253   <none>           1/1

Osservare lo stato di uno dei nuovi pod immettendo:

kubectl describe pod <pod-name> -n pdr

Ad esempio:

kubectl describe pod nginx-678976847c-ttqms  -n pdr

L'output del comando conferma lo stato del controllo di idoneità podreadiness.loadbalancer.oraclecloud.com. Ad esempio:

...
Readiness Gates:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
Conditions:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
  PodScheduled                                                     True 
  Initialized                                                      True 
  Ready                                                            True 
  ContainersReady                                                  True 

Quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, puoi specificare come instradare il traffico proveniente da un cluster all'indirizzo IP del load balancer o del load balancer di rete.

Nei cluster che eseguono Kubernetes versione 1.30 o successiva, il gate di controllo delle funzioni Kubernetes LoadBalancerIPMode è abilitato e il campo ipMode di un servizio di tipo LoadBalancer ha il valore predefinito "VIP". Quando ipMode ha il valore "VIP", il traffico inviato all'indirizzo IP di un servizio di tipo LoadBalancer da un pod all'interno del cluster viene instradato direttamente ai pod dell'applicazione per ottimizzare le prestazioni, ignorando il servizio LoadBalancer. Per ulteriori informazioni, vedere Specifica IPMode dello stato del load balancer nella documentazione di Kubernetes.

Tuttavia, in alcune situazioni, potresti decidere che l'instradamento del traffico direttamente ai pod dell'applicazione non è appropriato. Ad esempio, se il traffico che ha origine all'interno di un cluster viene instradato direttamente ai pod dell'applicazione, non è possibile implementare l'arresto SSL a livello di load balancer.

Per specificare come instradare il traffico inviato all'indirizzo IP del load balancer o del load balancer di rete dall'interno del cluster, aggiungere la seguente annotazione nella sezione dei metadati del file manifest:

oci.oraclecloud.com/ingress-ip-mode: <value>

dove <value> è uno dei seguenti:

• "VIP": tutto il traffico proveniente dal cluster e inviato all'indirizzo IP di un servizio di tipo LoadBalancer viene instradato direttamente ai pod dell'applicazione per ottimizzare le prestazioni, ignorando il servizio LoadBalancer.
• "proxy": tutto il traffico proveniente dal cluster e inviato all'indirizzo IP di un servizio di tipo LoadBalancer viene instradato al load balancer o al load balancer di rete Oracle Cloud Infrastructure di cui è stato eseguito il provisioning per il servizio LoadBalancer. Il load balancer o il load balancer di rete inoltra quindi il traffico ai pod dell'applicazione.

Ad esempio:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/ingress-ip-mode: "proxy"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Se non si specifica l'annotazione oci.oraclecloud.com/ingress-ip-mode o successivamente si rimuove l'annotazione, la proprietà ipMode di un servizio di tipo LoadBalancer avrà il valore predefinito "VIP".

Tenere inoltre presente che quando si utilizza un load balancer di rete privato con l'annotazione oci-network-load-balancer.oraclecloud.com/is-preserve-source impostata su true, il load balancer di rete prevede una limitazione nota che non consente il traffico in cui il nodo di origine e il nodo backend di destinazione sono lo stesso nodo. Questa limitazione impedisce la comunicazione tra pod sullo stesso nodo tramite il load balancer di rete quando vengono soddisfatte tutte le condizioni riportate di seguito.

• L'annotazione oci.oraclecloud.com/ingress-ip-mode viene impostata su proxy .
• L'annotazione oci-network-load-balancer.oraclecloud.com/is-preserve-source viene impostata su true .
• Il load balancer di rete è privato.

Quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, la subnet del load balancer determina il controllo di cui si dispone sulla famiglia di indirizzi IP dell'indirizzo IP su cui il load balancer o il load balancer di rete riceve il traffico.

• Se la subnet è una subnet a stack singolo IPv4, la subnet viene configurata solo per l'indirizzamento IPv4. Al load balancer o al load balancer di rete viene assegnato solo un indirizzo IPv4 su cui ricevere il traffico esterno. Non è possibile modificare la famiglia di indirizzi IP dell'indirizzo IP su cui il load balancer o il load balancer di rete riceve traffico esterno.
• Se la subnet è una subnet a doppio stack IPv4/IPv6, viene configurata sia per l'indirizzamento IPv4 che per l'indirizzamento IPv6. Il load balancer o il load balancer di rete possono essere allocati sia a un indirizzo IPv4 che a un indirizzo IPv6 su cui ricevere traffico esterno. In questa situazione, è possibile utilizzare i campi spec.ipFamilyPolicy e spec.ipFamilies di Kubernetes nel file manifesto del servizio per specificare se il load balancer o il load balancer di rete ricevono traffico esterno solo all'indirizzo IPv4 o solo all'indirizzo IPv6 oppure sia all'indirizzo IPv4 che all'indirizzo IPv6.

Tenere presente che la famiglia di indirizzi IP utilizzata per il traffico tra il listener e il set backend viene determinata in modo diverso per i load balancer e i load balancer di rete.

• Load balancer: il traffico tra un listener del load balancer e il set backend utilizza sempre gli indirizzi IPv4.
• load balancer di rete: il traffico tra un listener del load balancer di rete e il set backend utilizza la stessa famiglia di indirizzi IP dell'indirizzo IP su cui il listener del load balancer di rete riceve il traffico esterno.

La tabella mostra l'interazione tra la famiglia di indirizzi IP della subnet del load balancer, le impostazioni di spec.ipFamilyPolicy e spec.ipFamilies, la famiglia di indirizzi IP da cui vengono allocati gli indirizzi IP al load balancer o al load balancer di rete e il protocollo IP tra il listener e il set backend. Si noti che vengono visualizzate solo combinazioni valide.

Tenere presente che se si utilizza l'annotazione service.beta.kubernetes.io/oci-load-balancer-subnet1 per specificare una subnet alternativa alla subnet specificata per i load balancer al momento della creazione del cluster, assicurarsi che la famiglia di indirizzi della subnet alternativa sia compatibile con i campi spec.ipFamilyPolicy e spec.ipFamilies nel manifesto del servizio.

Per ulteriori informazioni sul supporto IPv4 e IPv6 in Kubernetes, vedere IPv4/IPv6 dual-stack nella documentazione di Kubernetes.

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb" 
spec:
  type: LoadBalancer
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv6
  - IPv4
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"  
spec:
  type: LoadBalancer
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv4
  - IPv6
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    app: nginx

Quando Kubernetes Engine esegue il provisioning di un load balancer di rete Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, il servizio Load Balancer di rete assegna uno o più indirizzi IP al load balancer di rete.

Il servizio Load Balancer di rete assegna un indirizzo IPv4 privato e, nel caso di un load balancer di rete esterno, assegna anche un indirizzo IPv4 pubblico aggiuntivo. Se la subnet del load balancer di rete è compatibile, il servizio Load Balancer di rete può anche assegnare un indirizzo IPv6 (vedere Specifica delle famiglie di indirizzi IP per i load balancer e i load balancer di rete).

Nei cluster che eseguono Kubernetes versione 1.29 o successiva, è possibile specificare l'indirizzo IP da assegnare al load balancer di rete, anziché selezionare l'indirizzo IP da assegnare al servizio Load Balancer di rete. L'indirizzo IP che puoi assegnare dipende dalla famiglia di indirizzi IP della subnet del load balancer di rete, come indicato di seguito.

• IPv4: se la subnet del load balancer di rete è una subnet a stack singolo IPv4 o una subnet a doppio stack IPv4/IPv6, è possibile assegnare un indirizzo IPv4 privato al load balancer di rete.
• IPv4 e IPv6: se la subnet del load balancer di rete è una subnet a doppio stack IPv4/IPv6, è possibile assegnare un indirizzo IPv4 privato o entrambi e un indirizzo IPv6 al load balancer di rete.

Per specificare un indirizzo IPv4 privato da assegnare a un load balancer di rete, aggiungere l'annotazione seguente nella sezione dei metadati del file manifesto:

oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "<ipv4-address>"

dove <ipv4-address> è un indirizzo IPv4 valido, dal blocco CIDRIPv4 CIDR IPv4 specificato per la subnet del load balancer di rete. Ad esempio:

oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "10.0.0.1"

Per specificare un indirizzo IPv6 da assegnare a un load balancer di rete, aggiungere l'annotazione seguente nella sezione dei metadati del file manifesto:

oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "<ipv6-address>"

dove <ipv6-address> è un indirizzo ULA o GUA IPv6 valido, dal blocco CIDR IPv6 specificato per la subnet del load balancer di rete. Ad esempio:

• oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "fd8a:4b3c:7d91:abcd::1"
• oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "2607:9b80:9a0a:9a7e:abcd:ef01:2345:6789"

Ad esempio:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "10.0.0.1"
    oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "fd8a:4b3c:7d91:abcd::1"
spec:
  type: LoadBalancer
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv6
  - IPv4
  ports:
  - port: 80
  selector:
    app: nginx

È tua responsabilità specificare un indirizzo IP valido. Affinché un indirizzo IP sia valido, devono essere soddisfatte le seguenti condizioni:

• L'indirizzo IP deve essere nel formato corretto per l'annotazione utilizzata (IPv4 o IPv6).
• L'indirizzo IP deve provenire dal blocco CIDR appropriato specificato per la subnet del load balancer di rete.
• L'indirizzo IP non deve essere già utilizzato da un'altra risorsa.

Tenere presente quanto riportato di seguito.

• Se l'indirizzo IP non è nel formato corretto o non proviene dal blocco CIDR appropriato, la richiesta di creazione del load balancer di rete non viene accettata.
• Se l'indirizzo IP è nel formato corretto e dal blocco CIDR appropriato, ma l'indirizzo IP è già in uso da un'altra risorsa, la richiesta di creazione del load balancer di rete viene accettata. Tuttavia, la richiesta di lavoro associata non riuscirà e il compartimento conterrà un load balancer di rete in stato Non riuscito.
• Se l'indirizzo IP è valido, il load balancer di rete viene creato con l'indirizzo IP specificato assegnatogli.

Quando Kubernetes Engine esegue il provisioning di un load balancer di rete Oracle Cloud Infrastructure pubblico per un servizio Kubernetes di tipo LoadBalancer, il servizio Load balancer di rete assegna sia un indirizzo IP pubblico che un indirizzo IP privato al load balancer di rete. L'indirizzo IP privato viene utilizzato per i controlli dello stato e la conversione dell'indirizzo della porta (PAT, port address translation), ma non può ricevere traffico esterno dalla rete VCN (inclusa la rete Internet pubblica).

Per visualizzare gli indirizzi IP pubblici e privati assegnati dal servizio Load balancer di rete al load balancer di rete, immettere il comando kubectl get service (o simile). Ad esempio:

kubectl get service my-nginx-svc -o json | jq .status

{
  "loadBalancer": {
    "ingress": [
      {
        "ip": "203.0.113.2"
      },
      {
        "ip": "10.30.3.24"
      }
    ]
  }
}

In alcuni casi, potresti solo voler esporre l'indirizzo IP pubblico del load balancer di rete e nascondere l'indirizzo IP privato. Ad esempio:

• Quando si utilizza il componente aggiuntivo ExternalDNS, è possibile specificare un nome DNS descrittivo per il load balancer di rete includendo l'annotazione external-dns.alpha.kubernetes.io/hostname nel file manifesto del servizio Kubernetes di tipo LoadBalancer. ExternalDNS crea un record DNS per il load balancer di rete nel provider DNS esterno configurato per il cluster. Il record DNS mappa il nome DNS sia all'indirizzo IP pubblico che all'indirizzo IP privato. Di conseguenza, se il traffico esterno utilizza il nome DNS, è possibile che il traffico venga instradato all'indirizzo IP privato del load balancer di rete, anche se l'indirizzo IP privato non può ricevere traffico esterno.
• È possibile impostare l'automazione che utilizza il comando kubectl get service (o simile) per ottenere l'indirizzo IP del load balancer di rete. Se il tuo caso d'uso include l'instradamento del traffico esterno, desideri solo l'indirizzo IP pubblico del load balancer di rete. Tuttavia, per impostazione predefinita, il comando kubectl get service restituisce sia l'indirizzo IP pubblico del load balancer di rete che il relativo indirizzo IP privato.

Per specificare che il comando kubectl get service (o simile) restituisce solo l'indirizzo IP pubblico del load balancer di rete, aggiungere la seguente annotazione nella sezione dei metadati del file manifesto:

oci-network-load-balancer.oraclecloud.com/external-ip-only: "true"

Si noti che "false" è il valore predefinito dell'annotazione oci-network-load-balancer.oraclecloud.com/external-ip-only. Se non si include l'annotazione in modo esplicito nella definizione del servizio, il comando kubectl get service (o simile) restituisce sia l'indirizzo IP pubblico del load balancer di rete che l'indirizzo IP privato

Ad esempio:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/external-ip-only: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Se si include l'annotazione oci-network-load-balancer.oraclecloud.com/external-ip-only: "true" nel file manifesto, quando si immette il comando kubectl get service (o simile), viene restituito solo l'indirizzo IP pubblico. Ad esempio:

kubectl get service my-nginx-svc -o json | jq .status

{
  "loadBalancer": {
    "ingress": [
      {
        "ip": "203.0.113.2"
      }
    ]
  }
}

Puoi escludere determinati nodi di lavoro dalla lista di server backend nel set backend di un load balancer o di un load balancer di rete Oracle Cloud Infrastructure. Per ulteriori informazioni, vedere node.kubernetes.io/exclude-from-external-load-balancers.

Puoi aggiungere tag a un load balancer o a un load balancer di rete di cui Kubernetes Engine esegue il provisioning per un servizio Kubernetes di tipo LoadBalancer. L'applicazione di tag consente di raggruppare risorse eterogenee in vari compartimenti e di aggiungere annotazioni alle risorse con i propri metadati. Vedere Applicazione di tag ai load balancer.

Quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, è possibile specificare se abilitare la funzione di protocollo proxy con listener basati su TCP. L'abilitazione del protocollo proxy consente di trasportare in modo sicuro le informazioni di connessione di trasporto, ad esempio l'indirizzo IP di un client, attraverso più livelli di proxy, al server backend. Sono disponibili le seguenti versioni del protocollo proxy:

• La versione 1, che utilizza un'intestazione basata su testo per passare informazioni tra i proxy ed è la migliore per piccole implementazioni.
• La versione 2, che utilizza un'intestazione basata su testo e binaria per una maggiore efficienza nella produzione e nell'analisi, è la migliore per le implementazioni più grandi.

I load balancer di cui è stato eseguito il provisioning dal protocollo proxy di supporto del motore Kubernetes versione 1 e 2. Load balancer di rete di cui è stato eseguito il provisioning dal protocollo proxy di supporto del motore Kubernetes versione 2.

Ulteriori informazioni

• Informazioni sui load balancer e sulla funzione del protocollo proxy, vedere Protocollo proxy per i load balancer.
• Informazioni sui load balancer di rete e sulla funzione del protocollo proxy, vedere Protocollo proxy per i load balancer di rete.

service.beta.kubernetes.io/oci-load-balancer-connection-proxy-protocol-version: "<value>"

oci-network-load-balancer.oraclecloud.com/is-ppv2-enabled: "<value>"