Uso di script di inizializzazione cloud-init personalizzati per impostare i nodi gestiti

Scopri come scrivere script cloud-init personalizzati da eseguire sui nodi di lavoro nei cluster creati utilizzando Kubernetes Engine (OKE).

Cloud-init è il metodo standard di settore per l'inizializzazione delle istanze cloud, il provisioning dei sistemi per l'infrastruttura cloud privata e le installazioni bare metal. È supportato da tutti i principali provider di cloud pubblico, incluso Oracle Cloud Infrastructure (vedere Dati utente). Cloud-init esegue gli script per inizializzare e configurare le istanze. Per ulteriori informazioni su cloud-init, consulta la documentazione cloud-init.

Kubernetes Engine utilizza il cloud-init per impostare le istanze di computazione che ospitano nodi gestiti. Kubernetes Engine installa uno script di avvio predefinito su ogni istanza che ospita un nodo gestito. Quando l'istanza viene avviata per la prima volta, Cloud-init esegue lo script di avvio predefinito. Lo script di avvio predefinito contiene la seguente logica fornita dal motore Kubernetes:

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh

È possibile personalizzare lo script di avvio predefinito aggiungendo la propria logica allo script, prima o dopo la logica predefinita. La personalizzazione dello script di avvio predefinito consente, ad esempio:

configurare un criterio SELinux su tutti gli host dei nodi di lavoro per motivi di sicurezza e conformità
annullare l'assegnazione dell'IP pubblico effimero di un'istanza all'avvio e riassegnare l'istanza a un IP pubblico riservato
configurare un proxy aziendale
configurare proxy yum personalizzati
installare il software antivirus obbligatorio e altri strumenti di sicurezza

Se si personalizza lo script di avvio predefinito, non modificare la logica fornita da Kubernetes Engine.

È possibile personalizzare lo script di avvio predefinito quando si crea un nuovo cluster, si creano nuovi pool di nodi e si modificano i pool di nodi esistenti:

utilizzo della console (quando si crea un nuovo cluster, utilizzare il workflow 'Creazione personalizzata')
uso dell'interfaccia CLI
utilizzo dell'API

Lo script di avvio personalizzato viene eseguito al primo avvio di un'istanza che ospita un nodo di lavoro. Dopo aver personalizzato lo script di avvio predefinito, è consigliabile eseguire lo script Node Doctor per verificare che i nodi di lavoro nelle istanze appena avviate funzionino come previsto (vedere Risoluzione dei problemi dei nodi per i cluster Kubernetes mediante lo script Node Doctor).

Esempi di casi d'uso per script cloud-init personalizzati

Esempio 1: utilizzo di uno script cloud-init personalizzato per configurare SELinux (Security-Enhanced Linux) sui nodi gestiti

È possibile utilizzare uno script cloud-init personalizzato per configurare SELinux sui nodi gestiti. SELinux è un miglioramento della sicurezza di Linux che consente agli amministratori di limitare gli utenti e le applicazioni che possono accedere alle risorse in base alle regole di un criterio. SELinux aggiunge inoltre una maggiore granularità ai controlli di accesso.

SELinux può essere in uno dei due stati, abilitato o disabilitato. Quando è abilitato, SELinux può essere eseguito in una delle due modalità, ovvero applicativa o permissiva.

Per impostazione predefinita, SELinux è abilitato e impostato per l'esecuzione in modalità permissiva sui nodi di lavoro. Quando viene eseguito in modalità permissiva, SELinux non applica le regole di accesso ed esegue solo il log.

Se si desidera che SELinux applichi le regole di accesso, è possibile impostarne l'esecuzione in modalità di applicazione. Quando viene eseguito in modalità di applicazione, SELinux blocca le azioni che sono contrarie al criterio e registra un evento corrispondente nel log di controllo.

Per impostare l'esecuzione di SELinux in modalità di applicazione, utilizzare il seguente script cloud-init:

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh
setenforce 1
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

Per confermare lo stato e la modalità di SELinux in esecuzione su un nodo di lavoro, connettersi al nodo di lavoro e utilizzare il comando getenforce. Quando lo script cloud-init precedente è stato eseguito sui nodi di lavoro, il comando getenforce restituisce Enforcing.

Esempio 2: utilizzo di uno script cloud-init personalizzato per impostare NodeLocal DNSCache sui nodi gestiti

È possibile utilizzare uno script cloud-init personalizzato per configurare NodeLocal DNSCache sui nodi gestiti. NodeLocal DNSCache migliora le prestazioni DNS del cluster eseguendo un agente di inserimento nella cache DNS sui nodi di lavoro come daemon.

Se NodeLocal DNSCache non è abilitato, i pod nella modalità DNS ClusterFirst raggiungono un kube-dns serviceIP per le query DNS. Utilizzando le regole iptables, questa richiesta viene tradotta in un endpoint kube-dns/CoreDNS aggiunto da kube-proxy. Per ulteriori informazioni, consulta DNS for Services and Pods nella documentazione di Kubernetes.

Se NodeLocal DNSCache è abilitato, i pod raggiungono un agente di inserimento nella cache DNS in esecuzione sullo stesso nodo di lavoro, che consente loro di ignorare le regole DNAT iptables e il tracciamento della connessione. L'agente di inserimento nella cache locale esegue una query sul servizio kube-dns/CoreDNS per rilevare gli accessi alla cache non riusciti dei nomi host del cluster (suffisso cluster.local per impostazione predefinita).

Per configurare NodeLocal DNSCache, utilizzare il seguente script cloud-init. Sostituire CLUSTER DNS con un indirizzo IP di ascolto locale che non sia in conflitto con alcun elemento nel cluster. È disponibile un intervallo locale di collegamenti consigliato di 169.254.0.0/16 per IPv4 o dall'intervallo di indirizzi locali univoci di fd00::/8 per IPv6.

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh --cluster-dns "[CLUSTER DNS]"

Per confermare che la distribuzione di NodeLocal DNSCache è riuscita, connettersi a un nodo di lavoro e utilizzare il comando sudo systemctl status -l kubelet. Quando lo script cloud-init precedente è stato eseguito sui nodi di lavoro, il comando sudo systemctl status -l kubelet restituisce --cluster-dns come uno dei flag kubelet, impostato su un indirizzo di collegamento locale predefinito (ad esempio, 169.254.20.10).

Dopo aver creato i nodi utilizzando lo script cloud-init riportato sopra, distribuire l'agente di inserimento nella cache DNS seguendo i passi descritti nella sezione Utilizzo di NodeLocal DNSCache nei cluster Kubernetes della documentazione di Kubernetes. Una volta abilitato, un pod node-local-dns viene eseguito nello spazio di nomi kube-system su ciascuno dei nodi del cluster. Il pod node-local-dns viene eseguito CoreDNS in modalità cache, quindi tutte le metriche CoreDNS esposte dai diversi plugin sono disponibili in base ai singoli nodi.

Per eseguire il test della risoluzione DNS, utilizzare uno o più dei seguenti comandi (vedere Debugging DNS Resolution nella documentazione di Kubernetes). I comandi devono funzionare entrambi, nonché restituire l'indirizzo IP impostato dal flag --cluster-dns nello script cloud-init personalizzato:

kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml

kubectl exec -it dnsutils – nslookup kubernetes.default

kubectl exec -it dnsutils – cat /etc/resolv.conf

È possibile disabilitare NodeLocal DNSCache rimuovendo il daemonset ed eliminando il file manifesto nodelocaldns. È inoltre necessario annullare le modifiche apportate alla configurazione di kubelet.

Esempio 3: utilizzo di uno script di inizializzazione cloud personalizzato per impostare kubelet-extra-args sui nodi gestiti

È possibile utilizzare uno script di inizializzazione cloud personalizzato per configurare una serie di opzioni aggiuntive sul kubelet (l'agente nodo primario) nei nodi gestiti. Queste opzioni aggiuntive sono a volte indicate come kubelet-extra-args. Una di queste opzioni kubelet-extra-args è l'opzione per configurare il dettaglio del log del livello di debug.

Per configurare il livello di dettaglio del log del livello di debug, utilizzare il seguente script cloud-init:

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh --kubelet-extra-args "--v=4"

Per confermare l'impostazione del livello di dettaglio del log di debug, connettersi a un nodo di lavoro e utilizzare il comando sudo systemctl status -l kubelet. Quando lo script cloud-init precedente è stato eseguito sui nodi di lavoro, il comando sudo systemctl status -l kubelet restituisce il livello di dettaglio come 4. I registri kubelet contengono anche maggiori dettagli.

Esempio 4: utilizzo di uno script cloud-init personalizzato per riservare le risorse per i daemon di sistema Kubernetes e OS

È possibile utilizzare uno script cloud-init personalizzato per riservare risorse di CPU e memoria per i daemon di sistema Kubernetes (ad esempio kubelet e container runtime) e i daemon di sistema del sistema operativo (ad esempio sshd e systemd). Per riservare le risorse per i daemon di sistema Kubernetes e OS, includere i flag kubelet --kube-reserved e --system-reserved rispettivamente come opzioni kubelet-extra-args in uno script di inizializzazione cloud personalizzato.

Per riservare risorse per i daemon di sistema Kubernetes e OS, utilizzare il seguente script cloud-init:

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh --kubelet-extra-args "--kube-reserved=cpu=500m,memory=1Gi --system-reserved=cpu=100m,memory=100Mi"

Per ulteriori informazioni e per i valori consigliati per i flag kubelet --kube-reserved e --system-reserved, vedere Best Practice: Riserva le risorse per i daemon di sistema Kubernetes e OS.

Esempio 5: utilizzo di uno script cloud-init personalizzato e di oci-growfs per aumentare la dimensione della partizione del volume di avvio

È possibile utilizzare uno script cloud-init personalizzato per estendere la partizione per il volume di avvio dei nodi gestiti. Quando si creano e si aggiornano cluster e pool di nodi, è possibile specificare una dimensione personalizzata per i volumi di avvio dei nodi di lavoro. La dimensione del volume di avvio personalizzato specificata deve essere maggiore della dimensione predefinita del volume di avvio dell'immagine selezionata. Quando si aumenta la dimensione del volume di avvio, per sfruttare la dimensione del volume di avvio più grande, è necessario anche estendere la partizione per il volume di avvio.

Le immagini della piattaforma Oracle Linux includono il pacchetto oci-utils. È possibile utilizzare il comando oci-growfs di tale pacchetto in uno script cloud-init per estendere la partizione radice e quindi far crescere il file system.

Per estendere la partizione per il volume di avvio, utilizzare il seguente script cloud-init:

#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /usr/libexec/oci-growfs -y
bash /var/run/oke-init.sh

Per ulteriori informazioni, vedere Estensione della partizione per un volume di avvio.

Creazione di uno script cloud-init personalizzato

Per personalizzare lo script di avvio predefinito cloud-init fornito da Kubernetes Engine:

Crea un nuovo file di script contenente la logica predefinita fornita da Kubernetes Engine. È possibile effettuare le operazioni riportate di seguito.
- Selezionando l'opzione Scarica modello script di inizializzazione cloud personalizzato (nella sezione Opzioni avanzate del pool di nodi) quando si utilizza la finestra di dialogo Crea cluster personalizzato, Aggiungi pool di nodi o Modifica pool di nodi. Il file scaricato contiene la logica predefinita.
- Creando un nuovo file da zero con un tipo di file supportato da cloud-init (ad esempio .yaml) e aggiungendo la logica predefinita fornita da Kubernetes Engine. Ad esempio:
```
#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh
```
Prima o dopo la logica predefinita fornita da Kubernetes Engine, aggiungere la propria logica personalizzata al file di script. Non modificare la logica predefinita.

Ad esempio, per configurare il livello di dettaglio del log del livello di debug, è possibile aggiungere --kubelet-extra-args "--v=4" in modo che il file abbia l'aspetto seguente:
```
#!/bin/bash
curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh
bash /var/run/oke-init.sh --kubelet-extra-args "--v=4"
```
Per altri esempi, vedere Esempio di casi d'uso per gli script di inizializzazione cloud personalizzati.
Salvare il file di script cloud-init personalizzato creato.
Specificare il file di script cloud-init personalizzato quando si crea un nuovo cluster, si aggiunge un nuovo pool di nodi o si modifica un pool di nodi esistente:
- Utilizzo di Console
- Uso dell'interfaccia CLI
- Uso dell'API

Utilizzo di Console

Per utilizzare la console per fornire uno script cloud-init personalizzato per le istanze che ospitano nodi gestiti in un nuovo cluster, un nuovo pool di nodi o un pool di nodi esistente, effettuare le operazioni riportate di seguito.

Creare un file cloud-init valido in uno dei formati (ad esempio, cloud-config) e dei tipi di file (ad esempio, un file .yaml) supportati da cloud-init. Vedere Creazione di uno script cloud-init personalizzato.
Aprire il menu di navigazione e selezionare Developer Services. In Container e artifact, selezionare Cluster Kubernetes (OKE).
Scegliere un compartimento in cui si dispone dell'autorizzazione per lavorare.
Creare un nuovo cluster utilizzando il workflow 'Creazione personalizzata', aggiungere un nuovo pool di nodi a un cluster esistente oppure modificare un pool di nodi esistente.
Nella sezione Opzioni avanzate del pool di nodi della finestra di dialogo Crea cluster personalizzato, Aggiungi pool di nodi o Modifica pool di nodi (a seconda dei casi), specificare quanto segue.
- Script di inizializzazione: (facoltativo) script per l'avvio del cloud da eseguire su ogni istanza che ospita nodi di lavoro quando l'istanza viene avviata per la prima volta. Lo script specificato deve essere scritto in uno dei formati supportati da cloud-init (ad esempio, cloud-config) e deve essere un tipo di file supportato (ad esempio, .yaml). Specificare lo script come indicato di seguito.
  - Scegliere lo script di inizializzazione cloud: selezionare un file contenente lo script di inizializzazione cloud oppure trascinare il file nella casella.
  - Incolla script Cloud-Init: copiare il contenuto di uno script cloud-init e incollarlo nella casella.
  Se in precedenza non sono stati scritti script di inizializzazione cloud per l'inizializzazione dei nodi di lavoro nei cluster creati da Kubernetes Engine, potrebbe essere utile fare clic su Scarica modello script di inizializzazione cloud personalizzato. Il file scaricato contiene la logica predefinita fornita dal motore Kubernetes. È possibile aggiungere la propria logica personalizzata prima o dopo la logica predefinita, ma non modificare la logica predefinita. Per alcuni esempi, vedere Esempio di casi d'uso per gli script di inizializzazione cloud personalizzati.

Uso dell'interfaccia CLI

Per informazioni sull'uso dell'interfaccia CLI, vedere Command Line Interface (CLI). Per un elenco completo dei flag e delle opzioni disponibili per i comandi CLI, vedere il documento Command Line Reference.

Per utilizzare l'interfaccia CLI per fornire uno script di inizializzazione cloud personalizzato per le istanze che ospitano nodi di lavoro in un nuovo pool di nodi o in un pool di nodi esistente, effettuare le operazioni riportate di seguito.

Creare un file cloud-init valido in uno dei formati (ad esempio, cloud-config) e dei tipi di file (ad esempio, un file .yaml) supportati da cloud-init. Vedere Creazione di uno script cloud-init personalizzato.
Aprire un prompt dei comandi e immettere uno dei comandi seguenti per creare un nuovo pool di nodi oppure aggiornare un pool di nodi esistente, a seconda dei casi:
- oci ce node-pool create
- oci ce node-pool update
Oltre ai parametri obbligatori richiesti dal comando che si sta utilizzando:
1. Includere il parametro --node-image-id, anche se non si desidera specificare un'immagine personalizzata.
2. Includere il parametro facoltativo --node-metadata nel formato seguente:
```
--node-metadata '{"user_data": "'$(cat <cloud-init-file> | base64)'"}'
```
  Dove:
  - <cloud-init-file> è il nome del file cloud-init creato
  - base64 specifica che il file deve essere codificato con base64
  Ad esempio:
```
--node-metadata '{"user_data": "'$(cat my-custom-cloud-init.yaml | base64)'"}'
```

Esempio

Questo comando di esempio crea un nuovo pool di nodi denominato my-cloud-init-test-nodepool per un cluster esistente, con un singolo nodo Kubernetes 1.18.10 con una forma VM 2.1 su cui è in esecuzione Oracle Linux. Quando l'istanza che ospita il nodo di lavoro nel nuovo pool di nodi viene avviata per la prima volta, verrà eseguito uno script cloud-init personalizzato denominato my-custom-cloud-init.yaml:

oci ce node-pool create \
--cluster-id ocid1.cluster.oc1.iad.aaaa______m4w \
--name my-cloud-init-test-nodepool \
--node-image-id ocid1.image.oc1.iad.aaaa______zpq \
--compartment-id ocid1.tenancy.oc1..aaa______q4a \
--kubernetes-version v1.18.10 \
--node-shape VM.Standard2.1 \
--placement-configs "[   { \"availabilityDomain\": \"PKGK:US-ASHBURN-AD-1\", \"subnetId\": \"ocid1.subnet.oc1.iad.aaaa______kfa\"   }   ]" \
--size 1 \
--region us-ashburn-1 \
--node-metadata '{"user_data": "'$(cat my-custom-cloud-init.yaml | base64)'"}'

Documentazione di Oracle Cloud Infrastructure