Eseguire automaticamente il bootstrap dei nodi GKE con DaemonSet

Questo tutorial mostra come personalizzare i nodi di un cluster Google Kubernetes Engine (GKE) utilizzando DaemonSets. Un DaemonSet garantisce che tutti i nodi (o quelli selezionati) eseguano una copia di un pod. Questo approccio ti consente di utilizzare gli stessi strumenti per orchestrare i carichi di lavoro che utilizzi per modificare i nodi GKE.

Se gli strumenti e i sistemi che utilizzi per inizializzare i cluster sono diversi da quelli che utilizzi per eseguire i workload, aumenti l'impegno necessario per gestire l'ambiente. Ad esempio, se utilizzi uno strumento di gestione della configurazione per inizializzare i nodi del cluster, ti affidi a una procedura esterna all'ambiente di runtime in cui vengono eseguiti gli altri workload.

Lo scopo di questo tutorial è aiutare gli amministratori di sistema, gli ingegneri di sistema o gli operatori dell'infrastruttura a semplificare l'inizializzazione dei cluster Kubernetes.

Attenzione: la personalizzazione dei nodi GKE può comportare un comportamento involontario che potrebbe influire negativamente sull'integrità dei tuoi carichi di lavoro e nodi. Non tutte le personalizzazioni sono supportate. Assicurati di implementare test approfonditi di qualsiasi personalizzazione prima di eseguirne il deployment sui cluster che eseguono carichi di lavoro di produzione.

Prima di leggere questa pagina, assicurati di avere familiarità con:

• Kubernetes
• GKE
• Docker
• chroot

In questo tutorial imparerai a utilizzare etichette e selettori Kubernetes per scegliere la procedura di inizializzazione da eseguire in base alle etichette applicate a un nodo. In questi passaggi, implementi un DaemonSet da eseguire solo sui nodi a cui è stata applicata l'etichetta default-init. Tuttavia, per dimostrare la flessibilità di questo meccanismo, potresti creare un altropool di nodil e applicare l'etichetta alternative-init ai nodi di questo nuovo pool. Nel cluster, puoi quindi eseguire il deployment di un altro DaemonSet configurato per essere eseguito solo sui nodi con l'etichetta alternative-init.

Inoltre, puoi eseguire più procedure di inizializzazione su ogni nodo, non solo una. Puoi sfruttare questo meccanismo per strutturare meglio le procedure di inizializzazione, separando chiaramente le preoccupazioni di ciascuna.

In questo tutorial, a titolo di esempio, la procedura di inizializzazione esegue le seguenti azioni su ogni nodo etichettato con l'etichetta default-init:

1. Collega un disco aggiuntivo al nodo.
2. Installa un insieme di pacchetti e librerie utilizzando il gestore di pacchetti del sistema operativo del nodo.
3. Carica un insieme di moduli kernel Linux.

Esegui il bootstrap dell'ambiente

In questa sezione, imparerai a:

1. Abilita le API Cloud necessarie.
2. Esegui il provisioning di un service account con privilegi limitati per i nodi nel cluster GKE.
3. Prepara il cluster GKE.
4. Concedi all'utente i privilegi di amministrazione del cluster.

Abilita Cloud APIs

1. Apri Cloud Shell.

   APRI Cloud Shell

2. Seleziona il progetto Google Cloud :

   gcloud config set project project-id
   

   Sostituisci project-id con l'ID del progettoGoogle Cloud che hai creato o selezionato per questo tutorial.

3. Attiva l'API Google Kubernetes Engine:

   gcloud services enable container.googleapis.com
   

Provisiona un account di servizio per gestire i cluster GKE

In questa sezione crei un service account associato ai nodi del cluster. In questo tutorial, i nodi GKE utilizzano questo account di servizio anziché quello predefinito. Come best practice, concedi al account di servizio solo i ruoli e le autorizzazioni di accesso necessari per eseguire l'applicazione.

I ruoli richiesti per il account di servizio sono i seguenti:

• Ruolo Visualizzatore Monitoring (roles/monitoring.viewer). Questo ruolo concede accesso di sola lettura alla console e all'API Cloud Monitoring.
• Ruolo Monitoring Metric Writer (roles/monitoring.metricWriter). Questo ruolo consente di scrivere dati di monitoraggio.
• Ruolo Writer log (roles/logging.logWriter). Questo ruolo concede autorizzazioni sufficienti per scrivere i log.
• Ruolo Utente service account (roles/iam.serviceAccountUser). Questo ruolo consente di accedere ai service account in un progetto. In questo tutorial, la procedura di inizializzazione simula l'identità delaccount di serviziot per eseguire operazioni con privilegi.
• Ruolo Amministratore Compute (roles/compute.admin). Questo ruolo fornisce il controllo completo di tutte le risorse Compute Engine. In questo tutorial, il service account ha bisogno di questo ruolo per collegare dischi aggiuntivi ai nodi del cluster.

Per eseguire il provisioning di un account di servizio:

1. In Cloud Shell, inizializza una variabile di ambiente che memorizza il nome delaccount di serviziot:

   GKE_SERVICE_ACCOUNT_NAME=ds-init-tutorial-gke
   

2. Crea un account di servizio:

   gcloud iam service-accounts create "$GKE_SERVICE_ACCOUNT_NAME" \
     --display-name="$GKE_SERVICE_ACCOUNT_NAME"
   

3. Inizializza una variabile di ambiente che memorizza il nome dell'account email del account di servizio:

   GKE_SERVICE_ACCOUNT_EMAIL="$(gcloud iam service-accounts list \
       --format='value(email)' \
       --filter=displayName:"$GKE_SERVICE_ACCOUNT_NAME")"
   

4. Associa i ruoli Identity and Access Management (IAM) al account di servizio:

   gcloud projects add-iam-policy-binding \
       "$(gcloud config get-value project 2> /dev/null)" \
       --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
       --role roles/compute.admin
   gcloud projects add-iam-policy-binding \
       "$(gcloud config get-value project 2> /dev/null)" \
       --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
       --role roles/monitoring.viewer
   gcloud projects add-iam-policy-binding \
       "$(gcloud config get-value project 2> /dev/null)" \
       --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
       --role roles/monitoring.metricWriter
   gcloud projects add-iam-policy-binding \
       "$(gcloud config get-value project 2> /dev/null)" \
       --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
       --role roles/logging.logWriter
   gcloud projects add-iam-policy-binding \
       "$(gcloud config get-value project 2> /dev/null)" \
       --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
       --role roles/iam.serviceAccountUser
   

Prepara il cluster GKE

In questa sezione avvii il cluster GKE, concedi le autorizzazioni e completi la configurazione del cluster.

Per questo tutorial, un cluster con un numero relativamente basso di nodi piccoli di uso generale è sufficiente per dimostrare il concetto. Crea un cluster con un node pool (quello predefinito). Poi etichetti tutti i nodi nel pool di nodi predefinito con l'etichetta default-init.

• In Cloud Shell, crea e avvia un cluster GKE regionale:

  gcloud container clusters create ds-init-tutorial \
      --enable-ip-alias \
      --image-type=ubuntu_containerd \
      --machine-type=n1-standard-2 \
      --metadata disable-legacy-endpoints=true \
      --node-labels=app=default-init \
      --node-locations us-central1-a,us-central1-b,us-central1-c \
      --no-enable-basic-auth \
      --no-issue-client-certificate \
      --num-nodes=1 \
      --location us-central1 \
      --service-account="$GKE_SERVICE_ACCOUNT_EMAIL"
  

Nota: la procedura di inizializzazione dei nodi deve tenere conto degli strumenti disponibili nel sistema operativo sottostante. In questo caso, ad esempio, i nodi del cluster GKE eseguono Ubuntu, consentendoti di utilizzare tutti gli strumenti installati per Ubuntu, come il gestore di pacchetti APT.

Esegui il deployment del DaemonSet

In questa sezione, imparerai a:

1. Crea il ConfigMap che memorizza la procedura di inizializzazione.
2. Esegui il deployment del DaemonSet che pianifica ed esegue la procedura di inizializzazione.

DaemonSet esegue le seguenti operazioni:

1. Configura un volume che rende disponibile il contenuto di ConfigMap ai container gestiti da DaemonSet.
2. Configura i volumi per le aree del file system privilegiate del nodo del cluster sottostante. Queste aree consentono ai contenitori pianificati da DaemonSet di interagire direttamente con il nodo che li esegue.
3. Pianifica ed esegue un init container che esegue la procedura di inizializzazione e poi viene terminato al termine.
4. Pianifica ed esegue un container che rimane inattivo e non consuma risorse.

Il container inattivo garantisce che un nodo venga inizializzato una sola volta. I DaemonSet sono progettati in modo che tutti i nodi idonei eseguano una copia di un pod. Se utilizzi un container normale, questo esegue la procedura di inizializzazione e viene terminato al termine. Per progettazione, DaemonSet riprogramma il pod. Per evitare la "ripianificazione continua", DaemonSet esegue prima la procedura di inizializzazione in un contenitore init, quindi lascia un contenitore in esecuzione.

Nota: in questo tutorial, implementi una procedura di inizializzazione "una tantum". Potresti implementare un'altra procedura che monitora costantemente lo stato del nodo e agisce di conseguenza per ottenere una soluzione di "auto-ripristino".

La seguente procedura di inizializzazione contiene operazioni privilegiate e non privilegiate. Utilizzando chroot, puoi eseguire i comandi come se li stessi eseguendo direttamente sul nodo, non solo all'interno di un container.

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: entrypoint
  labels:
    app: default-init
data:
  entrypoint.sh: |
    #!/usr/bin/env bash

    set -euo pipefail

    DEBIAN_FRONTEND=noninteractive
    ROOT_MOUNT_DIR="${ROOT_MOUNT_DIR:-/root}"

    echo "Installing dependencies"
    apt-get update
    apt-get install -y apt-transport-https curl gnupg lsb-release

    echo "Installing gcloud SDK"
    export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)"
    echo "deb https://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
    apt-get update
    apt-get install -y google-cloud-sdk

    echo "Getting node metadata"
    NODE_NAME="$(curl -sS http://metadata.google.internal/computeMetadata/v1/instance/name -H 'Metadata-Flavor: Google')"
    ZONE="$(curl -sS http://metadata.google.internal/computeMetadata/v1/instance/zone -H 'Metadata-Flavor: Google' | awk -F  "/" '{print $4}')"

    echo "Setting up disks"
    DISK_NAME="$NODE_NAME-additional"

    if ! gcloud compute disks list --filter="name:$DISK_NAME" | grep "$DISK_NAME" > /dev/null; then
        echo "Creating $DISK_NAME"
        gcloud compute disks create "$DISK_NAME" --size=1024 --zone="$ZONE"
    else
        echo "$DISK_NAME already exists"
    fi

    if ! gcloud compute instances describe "$NODE_NAME" --zone "$ZONE" --format '(disks[].source)' | grep "$DISK_NAME" > /dev/null; then
        echo "Attaching $DISK_NAME to $NODE_NAME"
        gcloud compute instances attach-disk "$NODE_NAME" --device-name=sdb --disk "$DISK_NAME" --zone "$ZONE"
    else
        echo "$DISK_NAME is already attached to $NODE_NAME"
    fi

    # We use chroot to run the following commands in the host root (mounted as the /root volume in the container)
    echo "Installing nano"
    chroot "${ROOT_MOUNT_DIR}" apt-get update
    chroot "${ROOT_MOUNT_DIR}" apt-get install -y nano

    echo "Loading Kernel modules"
    # Load the bridge kernel module as an example
    chroot "${ROOT_MOUNT_DIR}" modprobe bridge
...

Nota: i comandi che intendi eseguire nell'ambito della procedura di inizializzazione devono essere disponibili nei container in cui viene eseguito DaemonSet. Ti consigliamo di installarli nel container o di fornirli montando i volumi necessari dal nodo del cluster.

Ti consigliamo di esaminare attentamente ogni procedura di inizializzazione, perché potrebbe alterare lo stato dei nodi del cluster. Solo un piccolo gruppo di persone dovrebbe avere il diritto di modificare queste procedure, perché possono influire notevolmente sulla disponibilità e sulla sicurezza dei tuoi cluster.

Attenzione :in questo tutorial, esegui il deployment di ConfigMap e DaemonSet nello spazio dei nomi predefinito. In un ambiente di produzione, ti consigliamo di utilizzare uno spazio dei nomi dedicato per separare queste attività di inizializzazione dal resto dei tuoi carichi di lavoro. Inoltre, ti consigliamo di utilizzare il controllo dell'accesso basato sui ruoli per proteggere le risorse in questo spazio dei nomi dedicato.

Per eseguire il deployment di ConfigMap e DaemonSet:

1. In Cloud Shell, cambia la directory di lavoro in $HOME:

   cd "$HOME"
   

2. Clona il repository Git che contiene gli script e i file manifest per eseguire il deployment e configurare la procedura di inizializzazione:

   git clone https://github.com/GoogleCloudPlatform/solutions-gke-init-daemonsets-tutorial
   

3. Cambia la directory di lavoro impostandola sulla directory del repository appena clonato:

   cd "$HOME"/solutions-gke-init-daemonsets-tutorial
   

4. Crea un ConfigMap per contenere lo script di inizializzazione del nodo:

   kubectl apply -f cm-entrypoint.yaml
   

5. Esegui il deployment di DaemonSet:

   kubectl apply -f daemon-set.yaml
   

   Attenzione: questo DaemonSet esegue il deployment di un container init con privilegi. Per questo motivo, per questo tutorial devi utilizzare un cluster non di produzione.

6. Verifica che l'inizializzazione del nodo sia completata:

   kubectl get ds --watch
   

   Attendi che DaemonSet venga segnalato come pronto e aggiornato, come indicato da un output simile al seguente:

   NAME              DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   node-initializer   3         3         3         3            3          <none>  2h
   

Convalida e verifica la procedura di inizializzazione

Dopo che ogni nodo del cluster contrassegnato con l'etichetta default-init esegue la procedura di inizializzazione, puoi verificare i risultati.

Nota: in questo esempio, i risultati vengono verificati manualmente. In un ambiente di produzione, ti consigliamo di configurare il sistema di monitoraggio in modo che monitori continuamente il cluster per verificare che la procedura di inizializzazione venga eseguita correttamente su ogni nodo appena aggiunto, anziché fare affidamento alla verifica manuale.

Per ogni nodo, la procedura di verifica controlla quanto segue:

1. Un disco aggiuntivo è collegato e pronto per essere utilizzato.
2. I pacchetti e le librerie installati del gestore dei pacchetti del sistema operativo del nodo.
3. I moduli kernel vengono caricati.

Esegui la procedura di verifica:

• In Cloud Shell, esegui lo script di verifica:

  kubectl get nodes -o=jsonpath='{range .items[?(@.metadata.labels.app=="default-init")]}{.metadata.name}{" "}{.metadata.labels.failure-domain\.beta\.kubernetes\.io/zone}{"\n"}{end}' | while IFS= read -r line ; do ./verify-init.sh $line < /dev/null; done
  

  Attendi l'esecuzione dello script e verifica che ogni nodo sia stato inizializzato correttamente, come indicato da un output simile al seguente:

  Verifying gke-ds-init-tutorial-default-pool-5464b7e3-nzjm (us-central1-c) configuration
  Disk configured successfully on gke-ds-init-tutorial-default-pool-5464b7e3-nzjm (us-central1-c)
  Packages installed successfully in gke-ds-init-tutorial-default-pool-5464b7e3-nzjm (us-central1-c)
  Kernel modules loaded successfully on gke-ds-init-tutorial-default-pool-5464b7e3-nzjm (us-central1-c)
  Verifying gke-ds-init-tutorial-default-pool-65baf745-0gwt (us-central1-a) configuration
  Disk configured successfully on gke-ds-init-tutorial-default-pool-65baf745-0gwt (us-central1-a)
  Packages installed successfully in gke-ds-init-tutorial-default-pool-65baf745-0gwt (us-central1-a)
  Kernel modules loaded successfully on gke-ds-init-tutorial-default-pool-65baf745-0gwt (us-central1-a)
  Verifying gke-ds-init-tutorial-default-pool-6b125c50-3xvl (us-central1-b) configuration
  Disk configured successfully on gke-ds-init-tutorial-default-pool-6b125c50-3xvl (us-central1-b)
  Packages installed successfully in gke-ds-init-tutorial-default-pool-6b125c50-3xvl (us-central1-b)
  Kernel modules loaded successfully on gke-ds-init-tutorial-default-pool-6b125c50-3xvl (us-central1-b)