Documentazione di Oracle Cloud Infrastructure

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

Scopri come eseguire il provisioning di un load balancer OCI per un servizio Kubernetes di tipo LoadBalancer utilizzando Kubernetes Engine (OKE).

Un load balancer OCI è un proxy di livello 4 (TCP) e 7 (HTTP) OSI, che supporta funzioni quali l'interruzione SSL e i criteri di instradamento HTTP avanzati. Offre la massima flessibilità, con scalabilità reattiva su e giù. Puoi scegliere una larghezza di banda minima personalizzata e una larghezza di banda massima opzionale, entrambe comprese tra 10 Mbps e 8.000 Mbps. La larghezza di banda minima è sempre disponibile e fornisce prontezza immediata per i carichi di lavoro.

Per ulteriori informazioni sui load balancer OCI, vedere Panoramica del load balancer.

Il provisioning di un load balancer OCI per un servizio Kubernetes di tipo LoadBalancer consente di:

  • trasporto bilanciamento del carico Livello 4 e Livello 7 (TCP e HTTP) traffico
  • arrestare SSL/TLS nel load balancer

Quando Kubernetes Engine esegue il provisioning di un load balancer OCI per un servizio Kubernetes di tipo LoadBalancer, le regole di sicurezza per consentire il traffico in entrata e in uscita verso e dalla subnet del load balancer vengono create automaticamente per impostazione predefinita. Vedere Regole di sicurezza per i load balancer e i load balancer di rete.

Utilizzare le metriche del load balancer OCI per monitorare lo stato di un load balancer OCI di cui è stato eseguito il provisioning per un servizio Kubernetes di tipo LoadBalancer (vedere Metriche del load balancer).

Specifica dell'annotazione per un load balancer OCI

Per eseguire il provisioning di un load balancer Oracle Cloud Infrastructure per un servizio Kubernetes di tipo LoadBalancer, definire un servizio di tipo LoadBalancer che includa la seguente annotazione nella sezione dei metadati del file manifest:
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.

Interruzione di SSL/TLS nel load balancer

Quando Kubernetes Engine esegue il provisioning di un load balancer per un servizio Kubernetes di tipo LoadBalancer, è possibile specificare che si desidera arrestare SSL nel load balancer. Questa configurazione è nota come SSL frontend. Per implementare il protocollo SSL frontend, definire un listener in una porta come la 443 e associare un certificato SSL al listener.

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

In questo esempio viene fornita una panoramica della configurazione e della creazione di un load balancer con supporto SSL.

Prendere in considerazione il seguente file di configurazione, nginx-demo-svc-ssl.yaml, che definisce una distribuzione Nginx ed espone tramite un load balancer che serve http sulla porta 80 e https sulla porta 443. Questo esempio crea un load balancer Oracle Cloud Infrastructure definendo un servizio con un tipo di LoadBalancer (type: LoadBalancer).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    oci.oraclecloud.com/oci-load-balancer-listener-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.3"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 80

Le annotazioni del load balancer sono di particolare importanza, come descritto qui.

Le porte su cui supportare il traffico https sono definite dal valore dell'annotazione service.beta.kubernetes.io/oci-load-balancer-ssl-ports. È possibile dichiarare più porte SSL utilizzando una lista separata da virgole per il valore dell'annotazione. Ad esempio, è possibile impostare il valore dell'annotazione su "443, 3000" per supportare il protocollo SSL sulle porte 443 e 3000.

La suite di cifratura da utilizzare con il load balancer è definita dal valore dell'annotazione oci.oraclecloud.com/oci-load-balancer-listener-ssl-config. Le suite di cifratura determinano la sicurezza, la compatibilità e la velocità del traffico HTTPS (per ulteriori informazioni, vedere Suite di cifratura per i load balancer). È possibile specificare sia il nome della suite di cifratura (ad esempio, oci-default-http2-TLS-12-13-ssl-cipher-suite-v1) che la versione TLS (ad esempio, TLSv1.3). È possibile specificare una suite di cifratura predefinita preconfigurata da Oracle Cloud Infrastructure (vedere Suite di cifratura predefinite del load balancer) o una suite di cifratura creata personalmente. Se non si include l'annotazione oci.oraclecloud.com/oci-load-balancer-listener-ssl-config, ma si include l'annotazione service.beta.kubernetes.io/oci-load-balancer-tls-secret, viene utilizzata la suite di cifratura oci-default-ssl-cipher-suite-v1.

Il segreto TLS richiesto, ssl-certificate-secret, deve essere creato in Kubernetes. In questo esempio viene creato e utilizzato un certificato autofirmato. Tuttavia, in un ambiente di produzione, lo scenario più comune è quello di utilizzare un certificato pubblico firmato da un'autorità di certificazione.

Il comando seguente crea un certificato autofirmato, tls.crt, con la chiave corrispondente, tls.key:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"

Ora che hai creato il certificato, devi memorizzarlo e la sua chiave come segreto in Kubernetes. Il nome del segreto deve corrispondere al nome dell'annotazione service.beta.kubernetes.io/oci-load-balancer-tls-secret della definizione del load balancer. Utilizzare il comando seguente per creare un segreto TLS in Kubernetes, i cui valori di chiave e certificato sono impostati rispettivamente da --key e --cert.

kubectl create secret tls ssl-certificate-secret --key tls.key --cert tls.crt

È necessario creare il segreto Kubernetes prima di poter creare il servizio, poiché il servizio fa riferimento al segreto nella relativa definizione. Creare il servizio utilizzando il comando seguente:

kubectl create -f manifests/demo/nginx-demo-svc-ssl.yaml

Guardare il servizio e attendere l'assegnazione di un indirizzo IP pubblico (EXTERNAL-IP) al servizio Nginx (nginx-service) immettendo:

kubectl get svc --watch

L'output del comando precedente mostra l'IP del load balancer da utilizzare per connettersi al servizio.


NAME            CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
nginx-service   192.0.2.1      198.51.100.1     80:30274/TCP   5m

Il load balancer è ora in esecuzione. Ciò significa che ora è possibile accedere al servizio come indicato di seguito.

  • utilizzando http, immettendo:
    curl http://198.51.100.1
  • uso di https, immettendo:
    curl --insecure https://198.51.100.1

    Il flag "--insecure" viene utilizzato per accedere al servizio utilizzando https a causa dell'uso di certificati autofirmati in questo esempio. Non utilizzare questo flag in un ambiente di produzione in cui il certificato pubblico è stato firmato da un'autorità di certificazione.

Nota: quando si elimina un cluster, un load balancer creato in modo dinamico quando viene creato un servizio non verrà rimosso. Prima di eliminare un cluster, eliminare il servizio, che a sua volta comporterà la rimozione del load balancer. La sintassi di questo comando è la seguente:

kubectl delete svc SERVICE_NAME

Ad esempio, per eliminare il servizio dall'esempio precedente, immettere:

kubectl delete svc nginx-service

Aggiornamento dei certificati TLS dei load balancer esistenti

Per aggiornare il certificato TLS di un load balancer esistente, effettuare le operazioni riportate di seguito.
  1. Ottenere un nuovo certificato TLS. In un ambiente di produzione, lo scenario più comune è quello di utilizzare un certificato pubblico firmato da un'autorità di certificazione.

  2. Crea un nuovo segreto Kubernetes. Ad esempio, immettendo:

    kubectl create secret tls new-ssl-certificate-secret --key new-tls.key --cert new-tls.crt
  3. Modificare la definizione del servizio in modo che faccia riferimento al nuovo segreto Kubernetes modificando l'annotazione service.beta.kubernetes.io/oci-load-balancer-tls-secret nella configurazione del servizio. Ad esempio:
    
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: new-ssl-certificate-secret
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 80
  4. Aggiornare il servizio. Ad esempio, immettendo:
    kubectl apply -f new-nginx-demo-svc-ssl.yaml

Implementazione di SSL/TLS tra il load balancer e i nodi di lavoro

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 lavoratore) nel set backend. Questa configurazione è nota come SSL backend. Per implementare il protocollo SSL backend, associare un certificato SSL al set backend del load balancer.

Tenere presente che è possibile implementare la cifratura SSL point-to-point completa tra i client e i pod dell'applicazione 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 interruzione SSL (vedere Arresto di SSL/TLS nel load balancer).

Le suite di cifratura determinano la sicurezza, la compatibilità e la velocità del traffico HTTPS (per ulteriori informazioni, vedere Suite di cifratura per i load balancer). Per specificare la suite di cifratura da utilizzare con il set backend del load balancer, aggiungere la seguente annotazione nella sezione dei metadati del file manifest:

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

Dove:

  • "CipherSuiteName":"<cipher-suite-name>" è il nome di una suite di cifratura predefinita preconfigurata da Oracle Cloud Infrastructure (vedere Suite di cifratura predefinite del load balancer) o di una suite di cifratura creata personalmente. Ad esempio, "CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1"
  • "Protocols":["<tls-version>"] specifica una o più versioni TLS in una lista delimitata da virgole. Ad esempio, "Protocols":["TLSv1.2", "TLSv1.3"]

Ad esempio:

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"]}'

Se non si include l'annotazione oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config ma si include l'annotazione service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret, viene utilizzata la suite di cifratura oci-wider-compatible-ssl-cipher-suite-v1.

Per specificare il certificato da associare al set backend, aggiungere la seguente annotazione nella sezione metadati del file manifest:

service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: <value>

dove <value> è il nome di un segreto Kubernetes creato per contenere un certificato firmato e la chiave privata del certificato. Tenere presente che è necessario creare il segreto Kubernetes prima di poter creare il servizio, poiché il servizio fa riferimento al segreto nella relativa definizione.

Nell'esempio riportato di seguito viene creato e utilizzato un certificato con firma automatica, che in genere è accettabile per la comunicazione interna tra il load balancer e il set backend. Tuttavia, se lo si preferisce, è possibile utilizzare un certificato pubblico firmato da un'autorità di certificazione.

Ad esempio:

  1. Generare una chiave privata immettendo:

    openssl genrsa -out ca.key 2048

  2. Generare un certificato immettendo:

    openssl req -x509 -new -nodes -key ca.key -subj "/CN=nginxsvc/O=nginxsvc" -days 10000 -out ca.crt

  3. Memorizza il certificato e la chiave come segreti in Kubernetes immettendo:

    kubectl create secret generic ca-ser-secret --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key --from-file=ca.crt=ca.crt
  4. Definire una distribuzione Nginx ed esporla tramite un load balancer che serve http sulla porta 80 e https sulla porta 443.
Questo esempio crea un load balancer Oracle Cloud Infrastructure definendo un servizio di tipo LoadBalancer (type: LoadBalancer. 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
---
apiVersion: v1
metadata:
  name: nginx-service
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    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"]}'
    service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: ca-ser-secret
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443" 
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 443

La comunicazione tra il load balancer e i nodi di lavoro nel set backend viene cifrata utilizzando la chiave e il certificato memorizzati nel segreto Kubernetes ca-ser-secret creato in precedenza.

Specifica delle forme alternative 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). 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).

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

Specifica del timeout di connessione al load balancer

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

Specifica delle regole di intestazione HTTP

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. Per specificare la dimensione massima dell'intestazione HTTP, utilizzare 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 viene utilizzata per definire 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.

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 e riapplicare il file manifesto.

Quando si applica un file manifesto contenente l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets, tenere presente che Kubernetes Engine presuppone la gestione di tutti i set di regole del load balancer. Kubernetes Engine non solo aggiunge il set di regole di intestazione HTTP specificato dall'annotazione, ma elimina anche qualsiasi altro set di regole attualmente associato al load balancer. Notare i punti riportati di seguito:

  • Se in seguito si desidera eliminare il set di regole di intestazione HTTP del load balancer, specificare un oggetto JSON vuoto come valore dell'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets come indicato di seguito.

    oci.oraclecloud.com/oci-load-balancer-rule-sets: "{}"

    Quando si specifica un oggetto JSON vuoto come valore dell'annotazione, Kubernetes Engine elimina tutti i set di regole associati al load balancer e rinuncia alla gestione dei set di regole del load balancer.

  • Se si rimuove semplicemente l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets dal manifesto e si applica il manifesto, Kubernetes Engine interrompe la gestione dei set di regole del load balancer. Tenere presente che se si rimuove l'annotazione, Kubernetes Engine non elimina alcun set di regole associato al load balancer.

Se si apportano modifiche dirette ai set di regole del load balancer (sconsigliato) anziché utilizzare l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets, tenere presente il punto riportato di seguito. Se successivamente si applica un file manifesto contenente l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets, Kubernetes Engine aggiunge il set di regole di intestazione HTTP specificato dall'annotazione ed elimina qualsiasi altro set di regole associato al load balancer. Pertanto, se si desidera conservare le modifiche dirette apportate ai set di regole del load balancer, non includere l'annotazione oci.oraclecloud.com/oci-load-balancer-rule-sets nel file manifesto.

Specifica dei protocolli del listener

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, che utilizza 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 nel load balancer.
  • SSL backend, che utilizza 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.

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

Specifica delle opzioni di gestione delle liste di sicurezza durante il provisioning di un load balancer OCI

Nota

Potresti riscontrare problemi di scalabilità e di altro tipo se utilizzi la funzione di gestione delle liste di sicurezza Kubernetes in distribuzioni complesse e con strumenti come Terraform. Per questi motivi, Oracle sconsiglia di utilizzare la funzione di gestione degli elenchi di sicurezza Kubernetes negli ambienti di produzione.

Tenere inoltre presente che la possibilità di utilizzare gli elenchi di sicurezza per gestire le regole di sicurezza non sarà più valida nelle prossime release. Per questo motivo, Oracle consiglia di utilizzare i gruppi di sicurezza di rete (NSG) e l'annotazione oci.oraclecloud.com/security-rule-management-mode (vedere Specifica delle opzioni di gestione delle regole di sicurezza per i load balancer e i load balancer di rete).

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