Configurazione di un Application Load Balancer for VPC

Esponi la tua applicazione alla rete pubblica o privata configurando un servizio LoadBalancer Kubernetes nel tuo cluster. Quando rendi pubblica la tua app, viene creato automaticamente un VPC ALB ( Application Load Balancer for VPC ) all’interno del tuo VPC, al di fuori del cluster, che instrada le richieste verso la tua app. A questo punto, è possibile, se lo si desidera, registrare l'ALB VPC con un record DNS e un certific TLS. Gli ALB VPC supportano esclusivamente il protocollo TCP.

Non confondere l' Application Load Balancer for VPC con i bilanciatori di carico delle applicazioni Ingress Red Hat OpenShift on IBM Cloud. I bilanciatori di carico delle applicazioni per VPC (VPC ALB) vengono eseguiti all’esterno del cluster, all’interno della VPC, e vengono configurati tramite i servizi Kubernetes LoadBalancer creati dall’utente. Gli application load balancer(ALB)di Ingress sono controllori di Ingress eseguiti sui nodi worker del cluster.

Impostazione di un VPC ALB pubblico o privato

Prima di iniziare

Per consentire alla tua app di ricevere richieste pubbliche o private:

  1. Distribuisci la tua applicazione al cluster. Assicurati di aggiungere un'etichetta nella sezione dei metadati del tuo file di configurazione della distribuzione. Questa etichetta personalizzata identifica tutti i pod su cui viene eseguita la tua applicazione per includerli nel bilanciamento del carico.

  2. Creare un file YAML di configurazione per il servizio Kubernetes LoadBalancer. Nel file YAML, specificare l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type come "public" o "private". La sezione annotations nel file di esempio include solo alcune annotazioni disponibili. Per un elenco completo delle annotazioni VPC ALB necessarie e opzionali, vedere Annotazioni e specifiche.

    Per rendere il vostro VPC ALB facilmente identificabile, considerate di nominare il servizio nel formato <app_name>-vpc-alb-<VPC_zone>.

    apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "`<app_name>-vpc-alb-<VPC_zone>`"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
spec:
 type: LoadBalancer
 selector:     
    <selector_key>: <selector_value>
 ports:
   - name: http
     protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   - name: https
     protocol: TCP
     port: 443
     targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  externalTrafficPolicy: Local # Specify Local or Cluster.

  3. Crea il servizio LoadBalancer Kubernetes nel tuo cluster.

    oc apply -f myloadbalancer.yaml -n <namespace>

  4. Verifica che il servizio LoadBalancer Kubernetes sia stato creato correttamente nel tuo cluster. Al momento della creazione del servizio, il campo " LoadBalancer " (Ingress ) viene compilato con un nome host assegnato dall'ALB della VPC.

L'ALB della VPC richiede alcuni minuti per essere configurato nella tua VPC. Non è possibile accedere all'app utilizzando il nome host del servizio Kubernetes LoadBalancer finché l'ALB VPC non sarà stato completamente configurato.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Output della CLI di esempio per un servizio `LoadBalancer` pubblico:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

  1. Verifica che l'ALB della VPC sia stato creato correttamente nella tua VPC. Nell'output, verificare che l'ALB VPC presenti uno stato operativo (Operating Status ) pari a " online " e uno stato di provisioning (Provision Status ) pari a " active".

    ibmcloud is load-balancers

    Nell'esempio seguente, che riporta l'output della CLI, viene creato l'ALB VPC denominato " kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 " per il servizio " Kubernetes " LoadBalancer:

    ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default

  2. Se hai creato un servizio pubblico LoadBalancer, esegui il comando curl specificando il nome host del servizio Kubernetes LoadBalancer assegnato dall'ALB della VPC che hai individuato al punto 4. Esempio: 

    curl 06496f64-us-south.lb.appdomain.cloud:8080

    Output di esempio

    Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!

    Se hai creato un servizio LoadBalancer privato, devi essere connesso alla tua rete VPC privata per eseguire curl per il nome host.

Non eliminare le sottoreti che hai collegato al tuo cluster durante la sua creazione o quando aggiungi nodi di lavoro in una zona. Se elimini una sottorete VPC utilizzata dal tuo cluster, qualsiasi programma di bilanciamento del carico che utilizza gli indirizzi IP dalla sottorete potrebbe presentare dei problemi e potresti non essere in grado di creare nuovi programmi di bilanciamento del carico.

Gli ALB e gli NLB VPC che non sono associati a cluster Kubernetes o OpenShift possono essere aggiornati direttamente utilizzando i comandi "ibmcloud is" o la sezione " Infrastruttura VPC " nella console. Ad esempio, modificare la porta di un ascoltatore front-end o il valore di timeout del controllo di salute. Tuttavia, per i bilanciatori di carico VPC associati a cluster Kubernetes o OpenShift, eventuali aggiornamenti devono essere effettuati tramite annotazioni nella configurazione di Ingress. Il provider " IBM Cloud " esegue periodicamente la risincronizzazione con tutti gli ALB e gli NLB associati alla VPC, per garantire che il bilanciatore di carico in esecuzione sia conforme alla configurazione prevista da Ingress. Pertanto, se si apportano modifiche a tale bilanciatore di carico direttamente tramite VPC invece di utilizzare le annotazioni Ingress, tali modifiche vengono annullate.

Registrazione di un record DNS e di un certific TLS

L'ALB di VPC ( Application Load Balancer for VPC, VPC ALB) fornisce un nome host predefinito HTTP nel formato 1234abcd-<region>.lb.appdomain.cloud, tramite il quale è possibile accedere alla propria app. Tuttavia, se desideri un certificato TLS per il dominio della tua app a supporto di HTTPS, puoi creare un sottodominio fornito da IBM oppure utilizzare un dominio personalizzato sia per gli ALB delle VPC pubbliche che per quelli delle VPC private.

Dopo aver creato un sottodominio DNS per un nome host VPC ALB, non è possibile utilizzare i comandi nlb-dns health-monitor per creare un controllo di integrità personalizzato. Viene invece utilizzato il controllo di integrità predefinito del bilanciatore di carico VPC, previsto per il nome host predefinito dell'ALB VPC. Per ulteriori informazioni, consulta la documentazione VPC.

Prima di iniziare

  • Impostare un VPC ALB. Assicurati di definire una porta HTTPS nel servizio Kubernetes LoadBalancer che configura l'ALB VPC.
  • Per utilizzare il certificato " TLS " per accedere alla tua app tramite HTTPS, la tua app deve essere in grado di terminare le connessioni TLS.

Per registrare un hostname VPC ALB con un sottodominio DNS:

  1. Recuperare il nome host dell'ALB VPC eseguendo il comando get svc. Nell'output, cerca il nome host nella colonna EXTERNAL-IP. Ad esempio, 1234abcd-us-south.lb.appdomain.cloud.

    oc get svc -o wide

    Output di esempio

    NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
...
webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver

  2. Creare un sottodominio DNS personalizzato o fornito da IBM per il nome host del bilanciatore di carico.

    • Dominio personalizzato: inserisci il tuo dominio personalizzato e assegnagli un alias specificando l'IP esterno del bilanciatore di carico, nel formato 1234abcd-us-south.lb.appdomain.cloud come record di nome canonico (CNAME).

      1. Registra un dominio personalizzato lavorando con il tuo provider DNS (Domain Name Service) o il DNS IBM Cloud.
      2. Definisci un alias per il tuo dominio personalizzato specificando l'IP esterno del bilanciatore di carico come record di nome canonico (CNAME). Nell'esempio seguente, il bilanciatore di carico con l'IP esterno di 1234abcd-us-south.lb.appdomain.cloud è raggiungibile a www.your-custom-domain.com.
      Host/Servizio
      Il prefisso da cui si vuole raggiungere l'applicazione, ad esempio www.
      Tipo di risorsa
      Selezionare CNAME.
      TTL
      Scegliere un tempo di vita.
      Valore/obiettivo
      L'IP esterno LoadBalancer recuperato in precedenza. Ad esempio 1234abcd-us-south.lb.appdomain.cloud.. Quando si usa il DNS IBM Cloud, assicurarsi di inserire un punto finale.

    • IBM-sottodominio fornito: utilizzare i comandi nlb-dns per generare un sottodominio con un certificato TLS per il nome host dell'ALB della VPC. IBM Cloud si occupa di generare e gestire per conto dell'utente il certificato TLS con caratteri jolly per il sottodominio.

      1. Crea un sottodominio DNS e un certificato TLS.
        ibmcloud oc nlb-dns create vpc-gen2 --cluster CLUSTER_NAME_OR_ID --lb-host VPC_LB_HOSTNAME --type (public|private)
      2. Verifica che il dominio secondario sia stato creato. Per ulteriori informazioni, vedi Descrizione del formato del dominio secondario. 
        ibmcloud oc nlb-dns ls --cluster CLUSTER_NAME_OR_ID
        Output di esempio
        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>

  3. Se hai creato un sottodominio per un ALB VPC pubblico, apri un browser web e digita l'indirizzo URL per accedere alla tua app tramite il sottodominio, come nell'esempio www.your-custom-domain.com. Se hai creato un sottodominio per un ALB VPC privato, devi essere connesso alla tua rete VPC privata per verificare l'accesso al sottodominio.

Per utilizzare il certificato TLS per accedere alla tua app tramite HTTPS, assicurati di aver definito una porta HTTPS nel tuo servizio Kubernetes LoadBalancer. È possibile verificare che le richieste vengano correttamente instradate attraverso la porta HTTPS eseguendo il comando curl -v --insecure https://<domain>. Un errore di connessione indica che sul servizio non è aperta alcuna porta HTTPS. Inoltre, assicurati che la tua applicazione possa terminare le connessioni TLS. È possibile verificare che l'app si chiuda correttamente all'indirizzo TLS eseguendo il comando curl -v https://<domain>. Un errore di certificato indica che la tua applicazione non sta terminando correttamente le connessioni TLS.

Registrazione di un record DNS privato per un VPC ALB privato

Nella versione 4.15 o successiva è possibile utilizzare le seguenti annotazioni opzionali per associare un proprio DNS instance che serve un DNS personalizzato zone a un VPC ALB privato. A tal fine, devono essere impostate entrambe le annotazioni opzionali. Se non vengono specificati, i record DNS di tipo “ A ” relativi alla proprietà “ hostname ” di questo bilanciatore di carico vengono aggiunti alla zona DNS pubblica lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"
L' instance e DNS da associare a questo bilanciatore di carico. L'istanza specificata può trovarsi in una regione o in un account diverso, in base ai criteri IAM. Valori possibili: 9 ≤ lunghezza ≤ 512
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"
L' zone e DNS da associare a questo bilanciatore di carico. La zona specificata può trovarsi in una regione o in un account diverso, in base ai criteri IAM. Valori possibili: 1 ≤ lunghezza ≤ 128, Il valore deve corrispondere all'espressione regolare [1]*[a-z0-9]$

Prima di poter utilizzare questa funzione, è necessario eseguire le seguenti operazioni:

  • Creare la zona DNS che può essere vincolata a un bilanciatore di carico
  • Abilitare l'autorizzazione da servizio a servizio tra le LB VPC e i DNS Services
  • Aggiungere la VPC del cluster alle reti consentite della zona

Per informazioni dettagliate, consultare i documenti Integrazione di un bilanciatore di carico delle applicazioni con IBM Cloud DNS Services e Aggiungi una VPC come rete consentita alla zona DNS.

Esempio:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

Annotazioni e specifiche

Esaminare le annotazioni e le specifiche VPC ALB necessarie e facoltative.

Annotazioni e specifiche richieste

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "alb"
Annotazione per creare un VPC ALB. Se non si include service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features, il provisioning di un VPC ALB è predefinito.
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
(Richiesto per gli ALB VPC privati) Annotazione per specificare un servizio che accetta richieste pubbliche o private. Se questa annotazione non è inclusa, viene creato un VPC ALB pubblico.
externalTrafficPolicy
Specificare Cluster per inoltrare una richiesta a un nodo worker che contiene l'app pod. Questo nodo worker potrebbe trovarsi in una zona diversa. Per impostazione predefinita, questa annotazione è impostata su “ Cluster ”.
Specificare Local per impedire l'inoltro del traffico in entrata a un altro nodo. Questa opzione configura anche i controlli di salute di HTTP.
Si noti che per utilizzare l'IP di origine del client originale per gli ALB VPC, è necessario abilitare il protocollo PROXY con l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol".

Annotazioni e specifiche facoltative

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name
Includere un nome unico per rendere persistente il bilanciatore di carico VPC. I bilanciatori di carico VPC persistenti non vengono eliminati quando viene eliminato il cluster a cui appartengono. Per ulteriori informazioni, vedere Bilanciatori di carico VPC persistenti. Questa annotazione può essere impostata solo alla creazione del bilanciatore di carico. Non può essere utilizzato in un'operazione di aggiornamento.
service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
Abilita il protocollo PROXY. Il bilanciatore di carico passa le informazioni di connessione del client, tra cui l'indirizzo IP del client, l'indirizzo IP del server proxy ed entrambi i numeri di porta, nelle intestazioni delle richieste all'applicazione back-end. Si noti che l'applicazione back-end deve essere configurata per accettare il protocollo PROXY. Ad esempio, è possibile configurare un'applicazione NGINX in modo che accetti il protocollo PROXY seguendo questi passaggi.
service.kubernetes.io/ibm-load-balancer-cloud-provider-zone
Annotazione per specificare una zona VPC a cui è collegato il tuo cluster. Quando si specifica una zona in questa annotazione, si verificano due processi: (1) l'ALB VPC viene distribuito nella stessa sottorete della zona a cui sono connessi i nodi worker e (2) solo i nodi worker del cluster in questa zona sono configurati per ricevere traffico dall'ALB VPC. Per posizionare il programma di bilanciamento del carico in una zona specifica, devi specificare questa annotazione quando crei il programma di bilanciamento del carico. Se in seguito si modifica questa annotazione in una zona diversa, i nodi worker di ascolto e di backend vengono aggiornati automaticamente per adattarsi alla nuova zona. Se l'etichetta dedicated: edge è impostata sui nodi worker e si specifica questa annotazione, solo i nodi edge della zona specificata sono configurati per ricevere traffico. I nodi periferici presenti in altre zone e i nodi non periferici presenti nella zona specificata non ricevono traffico dal bilanciatore di carico. Per visualizzare le zone, esegui il comando ibmcloud ks zone ls --provider vpc-gen2``.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets
Annotazione per specificare una o più sottoreti su cui il servizio VPC ALB si distribuisce. Se specificata, questa annotazione ha la precedenza sull'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Senza questa annotazione, le sottoreti che il VPC ALB distribuisce si aggiornano automaticamente per corrispondere alle zone di un cluster se il cluster viene aggiornato da una regione a zona singola a una multizona o viceversa. Si noti che è possibile specificare una sottorete diversa nella stessa VPC rispetto alle sottoreti a cui è collegato il cluster. In questo caso, anche se l'ALB VPC viene distribuito su una sottorete diversa nella stessa VPC, l'ALB VPC può comunque instradare il traffico verso i nodi worker sulle sottoreti del cluster. Per vedere le sottoreti in tutti i gruppi di risorse, eseguire ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE. Questa annotazione può essere aggiunta o modificata per gli ALB VPC esistenti.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector
Annotazione per specificare un selettore di etichetta del nodo lavoratore. È possibile configurare nodi worker specifici nel cluster per ricevere il traffico specificando le chiavi di selezione delle etichette. È possibile includere un solo selettore di etichetta nell'annotazione e il selettore deve essere specificato nel formato "key=value". Se questa annotazione non è specificata, tutti i nodi worker del cluster sono configurati per ricevere traffico dall'ALB VPC. Questa annotazione ha la precedenza sull'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-zone e qualsiasi etichetta dedicated: edge sui nodi lavoratori viene ignorata. Per limitare il traffico a una zona specifica, si può usare questa annotazione per specificare i nodi worker in quella zona. Si noti che l'impostazione di una nuova etichetta su un nodo worker del cluster non configura automaticamente il nodo worker per ricevere il traffico; è necessario ricreare o aggiornare l'ALB della VPC affinché il nodo worker con la nuova etichetta riceva il traffico.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
Il protocollo di controllo dello stato di salute sulla risorsa VPC del bilanciatore di carico associata al servizio Kubernetes del bilanciatore di carico. Le opzioni disponibili sono http, https o tcp. Di solito, il protocollo di controllo dello stato di salute del VPC LB è determinato dal valore dell'impostazione externalTrafficPolicy nelle specifiche del servizio del bilanciatore di carico Kubernetes, tuttavia questa annotazione annulla questa logica. Questa annotazione fa sì che non alteri il comportamento di Kubernetes, e di kube-proxy in particolare, rispetto alle varie impostazioni di externalTrafficPolicy.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port
La porta dell' TCP e utilizzata per i controlli di integrità. Questa annotazione si applica solo se viene specificato anche ibm-load-balancer-cloud-provider-vpc-health-check-protocol.
Se il cluster non funziona Secure by Default, potrebbe essere necessario apportare le seguenti modifiche ai gruppi di sicurezza VPC applicati. Se il cluster funziona in modo sicuro per impostazione predefinita, queste modifiche vengono applicate automaticamente.
  • Se la porta specificata per il servizio " TCP " non rientra nell'intervallo di porte dei nodi " Kubernetes " (30.000-32.767), è necessario modificare il gruppo di sicurezza VPC applicato ai nodi di lavoro del cluster per consentire il traffico in entrata su tale porta.
  • Se questa annotazione viene applicata a un servizio di bilanciamento del carico di tipo " Kubernetes " associato a un VPC ALB, è necessario modificare le regole in uscita del gruppo di sicurezza assegnato al VPC ALB per consentire il traffico in uscita verso la porta TCP specificata.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path
Il percorso del controllo di salute URL per i controlli di salute HTTP e HTTPs. Questa annotazione si applica solo se ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostato su http o https. Il percorso URL deve essere nel formato di una richiesta di destinazione origin-form. Se questa annotazione non è specificata e l'annotazione ibm-load-balancer-cloud-provider-vpc-health-check-protocol è impostata su http o https, viene applicato il valore predefinito /.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay
Il numero di secondi da attendere tra i tentativi di controllo dello stato di salute. Per impostazione predefinita, questo valore è impostato su 5 e ha un minimo di 2 e un massimo di 60. Questo valore deve essere maggiore del valore ibm-load-balancer-cloud-provider-vpc-health-check-timeout, che è impostato di default su 2.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout
Il numero di secondi di attesa per una risposta a un controllo sanitario. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 59. Questo valore deve essere inferiore a ibm-load-balancer-cloud-provider-vpc-health-check-delay, che è impostato su 5 per impostazione predefinita.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries
Il numero massimo di tentativi di controllo dello stato di salute per il bilanciatore di carico VPC. Per impostazione predefinita, questo valore è impostato su 2 e ha un minimo di 1 e un massimo di 10.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout
Il timeout di connessione inattiva del listener in secondi. Il timeout di inattività predefinito dipende dalle impostazioni dell'account. Di solito, questo valore è 50. Tuttavia, alcuni account in elenco hanno impostazioni di timeout più ampie. Se non si imposta l'annotazione, i bilanciatori di carico utilizzano il timeout impostato nell'account. È possibile specificare esplicitamente il timeout impostando questa annotazione. Il minimo è 50. Il valore massimo è 7200.
service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"
Versione 4.17 o successive.
Registra l'indirizzo IP del bilanciatore di carico con il dominio Ingress specificato. Se il dominio specificato non esiste, viene creato un dominio che utilizza il provider gestito interno IBM (IBM NS1). Per creare un nuovo dominio, il nome deve essere unico per tutti i domini esistenti (non solo per quelli del cluster). L'eliminazione del servizio di load balancer rimuove l'indirizzo IP dal dominio. Tuttavia, la rimozione dell'annotazione non rimuove l'indirizzo IP dal dominio.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"
Versione 4.15 o successive.
L' instance e DNS da associare a questo bilanciatore di carico. Per ulteriori informazioni, vedere Registrazione di un record DNS privato.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"
Versione 4.15 o successive.
L' zone e DNS da associare a questo bilanciatore di carico. Per ulteriori informazioni, vedere Registrazione di un record DNS privato.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota
Il numero di nodi worker per zona a cui il bilanciatore di carico esegue il percorso. Il valore predefinito è 8. Nel caso di un cluster con nodi di lavoro distribuiti in tre zone, ciò comporta che il bilanciatore di carico indirizzi il traffico verso un totale di 24 nodi di lavoro. Il numero totale di nodi worker in tutte le zone verso cui il bilanciatore di carico esegue il percorso non può superare i 50. Se il cluster ha meno di 50 nodi worker in tutte le zone, specificare 0 per instradare a tutti i nodi worker in una zona.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group
Versione 1.30 o successive.
Un gruppo di sicurezza gestito dal cliente da aggiungere al bilanciatore di carico VPC. Se non si desidera utilizzare il gruppo di sicurezzaIBM, specificare un gruppo di sicurezza di cui si è proprietari e che si gestisce. Questa opzione rimuove il gruppo di sicurezza IBM e lo sostituisce con il gruppo di sicurezza specificato dall'utente. La rimozione dell'annotazione da un bilanciatore di carico esistente sostituisce il gruppo di sicurezza aggiunto con il gruppo di sicurezza IBM. È possibile aggiungere o rimuovere questa annotazione in qualsiasi momento. L'utente è responsabile della gestione del proprio gruppo di sicurezza e del suo aggiornamento.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic
Disponibile per i cluster che eseguono Secure by Default. per creare gruppi di sicurezza per ogni indirizzo IP di un ALB associato a una porta esterna specificata dall'utente. Queste regole vengono create nel gruppo di sicurezza del cluster e si aggiornano automaticamente se l'indirizzo IP del VPC ALB cambia. Specificare le porte esterne valide in un elenco separato da virgole, ad esempio 80,443. In questo esempio, se ogni ALB pubblico associato a ciascun valore di porta esterna ha due indirizzi IP, viene creata una regola in uscita per ogni indirizzo IP, per un totale di 4 nuove regole. È possibile aggiungere o rimuovere questa annotazione in qualsiasi momento.
selector
La chiave dell'etichetta (<selector_key>) e il valore (<selector_value>) che hai utilizzato nella sezione " spec.template.metadata.labels " del file YAML di distribuzione della tua app. Questa etichetta personalizzata identifica tutti i pod su cui viene eseguita la tua applicazione per includerli nel bilanciamento del carico.
port
La porta su cui è in ascolto il servizio.
targetPort
La porta su cui il servizio gestisce il traffico. L'applicazione in esecuzione nel pod deve essere in ascolto del traffico in entrata proveniente dall' TCP e su questa porta di destinazione. La porta di destinazione è spesso definita staticamente nell'immagine in esecuzione nel pod dell'applicazione. La porta di destinazione configurata nel pod è diversa dalla porta del nodo per il servizio e potrebbe anche essere diversa dalla porta esterna configurata sul VPC LB.

  1. a-z0-9- ↩︎