Provisioning dei load balancer OCI per i servizi Kubernetes di tipo LoadBalancer

oci.oraclecloud.com/load-balancer-type: "lb"

Si noti che lb è il valore predefinito dell'annotazione oci.oraclecloud.com/load-balancer-type. Se l'annotazione non viene inclusa in modo esplicito nella definizione del servizio, viene utilizzato il valore predefinito dell'annotazione.

Considerare, ad esempio il file di configurazione nginx_lb.yaml. Definisce una distribuzione (kind: Deployment) per l'applicazione nginx, seguita da una definizione di un servizio di tipo LoadBalancer (type: LoadBalancer) che bilancia il traffico http sulla porta 80 per l'applicazione nginx.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

La prima parte del file di configurazione definisce una distribuzione Nginx, richiedendo che venga ospitata in 3 pod che eseguono l'immagine nginx:latest e che accetti il traffico verso i container sulla porta 80.

La seconda parte del file di configurazione definisce il servizio Nginx, che utilizza il tipo LoadBalancer per bilanciare il traffico Nginx sulla porta 80 tra i pod disponibili.

Per creare la distribuzione e il servizio definiti in nginx_lb.yaml durante la connessione al cluster Kubernetes, immettere il comando riportato di seguito.

kubectl apply -f nginx_lb.yaml

Al completamento della creazione della distribuzione e del load balancer, questo comando restituisce quanto riportato di seguito.

deployment "my-nginx" created
service "my-nginx-svc" created

Il load balancer potrebbe richiedere alcuni minuti per passare da uno stato in sospeso a completamente operativo. È possibile visualizzare lo stato corrente del cluster immettendo:

kubectl get all

L'output del comando precedente mostra lo stato corrente:

NAME                                  READY     STATUS    RESTARTS   AGE
po/my-nginx-431080787-0m4m8           1/1       Running   0          3m
po/my-nginx-431080787-hqqcr           1/1       Running   0          3m
po/my-nginx-431080787-n8125           1/1       Running   0          3m

NAME               CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
svc/kubernetes     203.0.113.1     <NONE>           443/TCP        3d
svc/my-nginx-svc   203.0.113.7     192.0.2.22       80:30269/TCP   3m

NAME                      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/my-nginx           3         3         3            3           3m

NAME                            DESIRED   CURRENT   READY     AGE
rs/my-nginx-431080787           3         3         3         3m

L'output mostra che la distribuzione my-nginx è in esecuzione su 3 pod (le voci po/my-nginx), che il load balancer è in esecuzione (svc/my-nginx-svc) e che dispone di un IP esterno (192.0.2.22) che i client possono utilizzare per connettersi all'applicazione distribuita nei pod.

Quando esegui il provisioning di un load balancer Oracle Cloud Infrastructure (OCI) per un servizio Kubernetes di tipo LoadBalancer, puoi configurarlo per arrestare il traffico SSL/TLS. Questa configurazione, spesso definita SSL frontend, garantisce che il traffico cifrato proveniente da Internet venga decifrato nel load balancer prima di essere inoltrato ai nodi di lavoro.

L'implementazione dell'interruzione SSL a livello di load balancer comporta l'offload del processo di decifrazione intensivo dai pod delle applicazioni, la semplificazione della gestione dei certificati e il miglioramento delle prestazioni backend.

Tenere presente che è possibile implementare la cifratura SSL point-to-point completa tra client e pod delle applicazioni in esecuzione sui nodi di lavoro. A tale scopo, configurare l'interruzione SSL nel load balancer (come descritto in questa sezione) e implementare anche il protocollo SSL backend tra il load balancer e i nodi di lavoro (vedere Implementazione di SSL/TLS tra il load balancer e i nodi di lavoro (backend SSL)).

oci.oraclecloud.com/oci-load-balancer-ssl-config: '{"CipherSuiteName":"<cipher-suite-name>", "Protocols":["<tls-version>"]}'

oci.oraclecloud.com/oci-load-balancer-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'

Quando Kubernetes Engine esegue il provisioning di un load balancer per un servizio Kubernetes di tipo LoadBalancer, è possibile specificare che si desidera implementare SSL tra il load balancer e i server backend (nodi di lavoro) nel set backend. Questa configurazione è nota come SSL backend. Per implementare il protocollo SSL backend, è necessario associare un certificato SSL al set backend del load balancer.

Tenere presente che è possibile implementare la cifratura SSL point-to-point completa tra client e pod delle applicazioni in esecuzione sui nodi di lavoro. A tale scopo, associare un certificato SSL al set backend del load balancer (come descritto in questa sezione) e creare un load balancer con l'interruzione SSL (vedere Arresto di SSL/TLS dal load balancer (SSL frontend)).

Sebbene l'interruzione SSL frontend protegga la connessione tra il client e il load balancer, il protocollo SSL backend protegge la connessione tra il load balancer e i nodi di lavoro. Questa configurazione garantisce che il traffico rimanga cifrato anche durante il viaggio attraverso la rete cloud virtuale (VCN) interna, fornendo un ulteriore livello di difesa approfondita.

Quando si implementa il protocollo SSL backend, il load balancer decifra il traffico in entrata utilizzando un certificato frontend, esegue tutte le ispezioni o l'instradamento di livello 7 necessarie, quindi esegue di nuovo la cifratura del traffico prima di inviarlo ai pod di destinazione. Questo è un requisito comune per gli ambienti ad alta sicurezza, in cui il traffico in chiaro è limitato ad ogni hop.

oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"<cipher-suite-name>", "Protocols":["<tls-version>"]}'

oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'

La forma di un load balancer Oracle Cloud Infrastructure specifica la larghezza di banda totale massima (ovvero, in entrata e in uscita). Per impostazione predefinita, i load balancer vengono creati con una forma 100Mbps. Sono disponibili altre forme, tra cui 400Mbps e 8000Mbps.

Per specificare una forma alternativa per un load balancer, aggiungere la seguente annotazione nella sezione dei metadati del file manifest:

service.beta.kubernetes.io/oci-load-balancer-shape: <value>

dove value è la larghezza di banda della forma (ad esempio, 100Mbps, 400Mbps, 8000Mbps).

Ad esempio:

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-shape: 400Mbps
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Nell'area deve essere disponibile una quota di load balancer sufficiente per la forma specificata. Immettere il seguente comando kubectl per confermare che la creazione del load balancer non è riuscita a causa della mancanza di quota:

kubectl describe service <service-name>

Si noti che Oracle consiglia di implementare i servizi Kubernetes di tipo LoadBalancer come load balancer flessibili ed economici anziché come load balancer a forma fissa (dinamica) (vedere Specifica delle forme flessibili del load balancer).

La forma di un load balancer Oracle Cloud Infrastructure specifica la larghezza di banda totale massima (ovvero, in entrata e in uscita). Come descritto nella sezione Specifica delle forme alternative del load balancer, è possibile specificare forme diverse del load balancer.

Inoltre, puoi specificare una forma flessibile per un load balancer Oracle Cloud Infrastructure, definendo una larghezza di banda minima e massima per il load balancer.

Per specificare una forma flessibile per un load balancer, aggiungere le annotazioni riportate di seguito nella sezione dei metadati del file manifest.

service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "<min-value>"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "<max-value>"

Dove:

• "<min-value>" è la larghezza di banda minima per il load balancer, in Mbps (ad esempio, "10")
• "<max-value>" è la larghezza di banda massima per il load balancer, in Mbps (ad esempio, "100")

Tenere presente che non si include un'unità di misura quando si specificano valori di larghezza di banda per le forme flessibili del load balancer (a differenza delle forme predefinite). Ad esempio, specificare la larghezza di banda minima come 10 anziché come 10Mbps.

Ad esempio:

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-shape: "flexible"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "10"
    service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Quando si esegue il provisioning di un load balancer Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, è possibile specificare il tempo di inattività massimo (in secondi) consentito tra due operazioni di ricezione successive o due operazioni di invio successive tra il client e i server backend.

Per specificare in modo esplicito un tempo massimo di inattività, aggiungere la seguente annotazione nella sezione metadati del file manifesto:

service.beta.kubernetes.io/oci-load-balancer-connection-idle-timeout: <value>

dove value è il numero di secondi.

Ad esempio:

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-connection-idle-timeout: 100
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Se non si specifica in modo esplicito un tempo massimo di inattività, viene utilizzato un valore predefinito. Il valore predefinito dipende dal tipo di listener:

• per i listener TCP, il tempo massimo di inattività predefinito è di 300 secondi
• per i listener HTTP, il tempo massimo di inattività predefinito è di 60 secondi

Quando esegui il provisioning di un load balancer Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, puoi specificare il numero massimo di connessioni simultanee che il load balancer può effettuare ai server backend (nodi worker) nel set backend.

Per specificare in modo esplicito il numero massimo di connessioni simultanee consentite tra il load balancer e ogni singolo server backend nel set backend, aggiungere l'annotazione seguente nella sezione dei metadati del file manifesto:

oci-load-balancer.oraclecloud.com/backendset-backend-max-connections: "<value>"

dove <value> è un valore valido per il numero di connessioni consentite, come indicato di seguito.

• Numero compreso tra "256" e "65535" (inclusi). Se si specifica un numero al di fuori di questo intervallo (ad eccezione di 0), viene restituito un errore.
• "0". Se si specifica 0 come numero massimo di connessioni consentite, è consentito un numero infinito di connessioni tra il load balancer e ogni singolo server backend nel set backend.

Ad esempio:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  annotations:
    oci-load-balancer.oraclecloud.com/backendset-backend-max-connections: "256"
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: 80

Tenere presente quanto riportato di seguito.

• Il numero specificato per l'annotazione non viene utilizzato solo come valore della proprietà backendMaxConnections del set backend, ma viene ereditato anche da ogni singolo server backend come valore della relativa proprietà maxConnections. Di conseguenza, il numero specificato viene utilizzato come numero di connessioni consentite tra il load balancer e ogni singolo server backend nel set backend e non come numero totale complessivo di connessioni consentite tra il load balancer e il set backend.
• Se non si include l'annotazione nel manifesto (o successivamente si rimuove l'annotazione), è consentito un numero infinito di connessioni tra il load balancer e ciascun server backend.
• Per informazioni correlate sulla specifica del numero massimo di connessioni concorrenti al listener del load balancer consentite dallo stesso indirizzo IP di origine, vedere Specifica delle regole di connessione del listener massimo.

Quando Kubernetes Engine esegue il provisioning di un load balancer Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, puoi specificare il numero massimo di connessioni concorrenti al listener del load balancer che sono consentite dallo stesso indirizzo IP di origine. È possibile utilizzare un'annotazione per definire un valore predefinito per il numero massimo di connessioni listener che si applica a tutti gli indirizzi IP. L'annotazione definisce una regola di connessione del listener massima per il load balancer. Se non si imposta questo valore massimo predefinito, non è previsto alcun limite al numero di connessioni che un indirizzo IP può effettuare al listener.

Per ulteriori informazioni sul numero massimo di regole di connessione del listener, vedere Numero massimo di regole di connessione del listener nella documentazione del load balancer OCI.

Per specificare il numero massimo di connessioni listener concorrenti consentite dallo stesso indirizzo IP di origine, aggiungere l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets nella sezione dei metadati del file manifesto. Si noti che si specifica il valore dell'annotazione come JSON formattato, come indicato di seguito.

oci.oraclecloud.com/oci-load-balancer-rule-sets: |
  {
    "<rule-set-name>": {
      "items": [
        {
          "action": "IP_BASED_MAX_CONNECTIONS",
          "maxConnectionsPerIp": <value>
        }
      ]
    }
  }

dove:

• <rule-set-name> è il nome scelto per il set di regole (di lunghezza compresa tra 1 e 32 caratteri). Ad esempio, IpLimitRuleSet .
• <value> è il numero massimo di connessioni listener simultanee consentite dallo stesso indirizzo IP di origine.

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/oci-load-balancer-rule-sets: |
      {
        "IpLimitRuleSet": {
          "items": [
            {
              "action": "IP_BASED_MAX_CONNECTIONS",
              "maxConnectionsPerIp": 20
            }
          ]
        }
      }
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Questa configurazione crea un set di regole di connessione listener massimo denominato IpLimitRuleSet che limita ogni indirizzo IP di origine a un massimo di 20 connessioni concorrenti.

Per modificare successivamente il numero massimo di connessioni concorrenti, aggiornare l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets e riapplicare il file manifesto.

Quando Kubernetes Engine esegue il provisioning di un load balancer per un servizio Kubernetes di tipo LoadBalancer, è possibile specificare la dimensione massima dell'intestazione HTTP accettata dai listener del load balancer. È possibile specificare la dimensione massima dell'intestazione HTTP utilizzando un'annotazione per specificare la dimensione (in KB) del buffer utilizzato per leggere l'intestazione. I valori consentiti per la dimensione del buffer sono 8, 16, 32 e 64. L'annotazione definisce una regola di intestazione HTTP per il load balancer. La regola di intestazione HTTP si applica a tutti i listener del load balancer, su tutte le porte.

Per ulteriori informazioni sulle regole di intestazione HTTP, vedere Regole di intestazione HTTP nella documentazione di OCI Load Balancer.

Per specificare la dimensione massima dell'intestazione HTTP accettata dai listener del load balancer, aggiungere l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets nella sezione dei metadati del file manifest. Si noti che si specifica il valore dell'annotazione come JSON formattato, come indicato di seguito.

oci.oraclecloud.com/oci-load-balancer-rule-sets:  |
      {
        "<rule-set-name>": {
          "items": [
            {
              "action": "HTTP_HEADER",
              "httpLargeHeaderSizeInKB": <value>
            }
          ]
        }
      }

dove:

• <rule-set-name> è il nome scelto per il set di regole, con una lunghezza compresa tra 1 e 32 caratteri. Ad esempio, header-size .
• <value> è la dimensione massima dell'intestazione HTTP in KB ed è una delle seguenti: 8, 16, 32 o 64.

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/oci-load-balancer-rule-sets: |
      {
        "header-size": {
          "items": [
            {
              "action": "HTTP_HEADER",
              "httpLargeHeaderSizeInKB": 16
            }
          ]
        }
      }
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Per modificare successivamente la dimensione massima dell'intestazione HTTP, aggiornare l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets e riapplicare il file manifesto.

Quando Kubernetes Engine esegue il provisioning di un load balancer per un servizio Kubernetes di tipo LoadBalancer, è possibile definire il tipo di traffico accettato dal listener specificando il protocollo su cui il listener accetta le richieste di connessione.

Se non si specifica esplicitamente un protocollo, come valore predefinito viene utilizzato "TCP".

Per specificare in modo esplicito il protocollo del listener del load balancer quando Kubernetes Engine esegue il provisioning di un load balancer per un servizio Kubernetes di tipo LoadBalancer, aggiungere la seguente annotazione nella sezione dei metadati del file manifest:

service.beta.kubernetes.io/oci-load-balancer-backend-protocol: <value>

dove <value> è il protocollo che definisce il tipo di traffico accettato dal listener. Ad esempio "HTTP". I protocolli validi includono "HTTP", "TCP" e "GRPC".

Ad esempio:

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-backend-protocol: "HTTP"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Tenere presente che se si specifica GRPC come protocollo, è necessario configurare entrambi gli elementi riportati di seguito.

• SSL frontend, utilizzando le annotazioni service.beta.kubernetes.io/oci-load-balancer-ssl-ports, oci.oraclecloud.com/oci-load-balancer-ssl-listener-config e service.beta.kubernetes.io/oci-load-balancer-tls-secret. Per ulteriori informazioni, vedere Arresto di SSL/TLS presso il load balancer (SSL Frontend).
• SSL backend, utilizzando le annotazioni oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config e service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret. Per ulteriori informazioni, vedere Implementazione di SSL/TLS tra il load balancer e i nodi di lavoro (backend SSL).

Ad esempio:

apiVersion: v1
kind: Service
metadata:
  name: hello-grpc-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
    service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "GRPC"
    oci.oraclecloud.com/oci-load-balancer-listener-ssl-config: '{"CipherSuiteName":"oci-default-http2-ssl-cipher-suite-v1", "Protocols":["TLSv1.2"]}'
    oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-ssl-cipher-suite-v1", "Protocols":["TLSv1.2"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: ca-ser-secret
spec:
  type: LoadBalancer
  selector:
    app: hello-grpc
  ports:
    - port: 443
      name: grpc
      targetPort: 50051

Puoi utilizzare la funzione di gestione delle liste di sicurezza per configurare la modalità di gestione delle regole delle liste di sicurezza per un load balancer Oracle Cloud Infrastructure di cui Kubernetes Engine esegue il provisioning per un servizio Kubernetes di tipo LoadBalancer. Questa funzione è utile se non hai mai utilizzato Kubernetes o per le distribuzioni di base.

Per specificare in che modo la funzione di gestione delle liste di sicurezza Kubernetes gestisce le liste di sicurezza quando Kubernetes Engine esegue il provisioning di un load balancer per un servizio Kubernetes di tipo LoadBalancer, aggiungere la seguente annotazione nella sezione dei metadati del file manifesto:

service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: <value>

dove <value> è uno dei seguenti:

• "None": (consigliato) Nessuna gestione delle liste di sicurezza abilitata. È necessario impostare una regola di sicurezza che consenta il traffico in entrata verso le porte appropriate per gli intervalli di porte dei nodi, la porta di integrità kube-proxy e gli intervalli di porte per il controllo dello stato. Inoltre, devi impostare regole di sicurezza per consentire il traffico in entrata ai load balancer (vedere Regole di sicurezza per i load balancer e i load balancer di rete).
• "All": (predefinito) vengono gestite tutte le regole della lista di sicurezza necessarie per i servizi del load balancer.
• "Frontend": vengono gestite solo le regole della lista di sicurezza per i servizi di entrata nel load balancer. È necessario impostare una regola di sicurezza che consenta il traffico in entrata verso le porte appropriate per gli intervalli di porte dei nodi, la porta di integrità kube-proxy e gli intervalli di porte per il controllo dello stato.

Oracle consiglia di impostare in modo esplicito service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode su None.

Nei cluster con nodi gestiti, se non si specifica in modo esplicito una modalità di gestione o si specifica un valore non valido, vengono gestite tutte le regole della lista di sicurezza (equivalente a "All"). Tenere presente che in questo caso, Kubernetes Engine crea una regola di sicurezza che consente il traffico in entrata da 0.0.0.0/0 (o dagli intervalli di porte di origine specificati nel file manifest) alle porte del listener. Nei cluster con nodi virtuali, la gestione delle liste di sicurezza non viene mai abilitata e sarà sempre necessario configurare manualmente le regole di sicurezza (equivalente a "None").

Tenere presente che esistono limiti al numero di regole di entrata e uscita consentite in una lista di sicurezza (vedere Limiti della lista di sicurezza). Se il numero di regole di entrata o uscita supera il limite e <value> è impostato su "All" o "Frontend", la creazione o l'aggiornamento del load balancer non riesce.

Ad esempio:

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-security-list-management-mode: "Frontend"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx