Gestione dell'infrastruttura cloud utilizzando KPT

Last reviewed 2023-03-15 UTC
Questo tutorial introduce kpt, uno strumento open source di Google che ti consente di lavorare con le configurazioni Kubernetes (noto anche come manifest): pacchettizzale, eseguine il pull, aggiornale e modificale. kpt è un'alternativa agli strumenti basati su modelli se vuoi mantenere una chiara separazione tra configurazioni e operazioni relative a queste configurazioni. kpt consente di riutilizzare e condividere il codice che sta modificando o modificando le configurazioni.

Questo tutorial mostra anche come combinare kpt con altre soluzioni Google come Config Sync e i progetti per la sicurezza di GKE Enterprise. Che tu sia uno sviluppatore che lavora con Kubernetes o un Platform engineer che gestisce una piattaforma basata su Kubernetes, questo tutorial ti consente di scoprire come puoi usare kpt nei tuoi flussi di lavoro relativi a Kubernetes. Questo tutorial presuppone che tu conosca Kubernetes e Google Cloud.

La configurazione dichiarativa per l'infrastruttura cloud è una pratica consolidata nel settore IT. Offre una potente astrazione dei sistemi sottostanti. Questa astrazione ti evita di dover gestire dettagli e dipendenze di configurazione di basso livello. Pertanto, la configurazione dichiarativa presenta un vantaggio rispetto agli approcci imperativi, come le operazioni eseguite nelle interfacce grafiche e a riga di comando.

Il modello di risorse di Kubernetes è stato influente nel rendere mainstream gli approcci alla configurazione dichiarativa. Poiché l'API Kubernetes è completamente dichiarativa per natura, indichi a Kubernetes solo ciò che vuoi, non come ottenere ciò che vuoi. L'API Kubernetes ti consente di separare in modo chiaro la configurazione (che sia desiderata o reale) dalle operazioni sulla configurazione (aggiunta, rimozione e modifica degli oggetti). In altre parole, nel modello di risorse di Kubernetes, la configurazione è costituita da dati e non da codice.

Questa separazione della configurazione dalle operazioni presenta molti vantaggi: le persone e i sistemi automatizzati possono comprendere e lavorare alla configurazione, mentre il software che modifica la configurazione è facilmente riutilizzabile. Questa separazione consente inoltre di implementare facilmente una metodologia GitOps (come definita nel tutorial sulla distribuzione continua stile GitOps con Cloud Build).

In questo tutorial vedrai questa separazione tra la dichiarazione di configurazione e le operazioni di configurazione utilizzando kpt. Questo tutorial evidenzia le seguenti caratteristiche di kpt:

  • Gestione dei pacchetti: scaricare e aggiornare i pacchetti di configurazione di Kubernetes.
  • Funzioni: esegui parti di codice arbitrarie per modificare o convalidare le tue configurazioni.
  • Pipeline delle funzioni: un insieme di funzioni che l'autore del pacchetto ha incluso nel pacchetto.
  • Gestione delle risorse: applica, aggiorna ed elimina le risorse corrispondenti alle tue configurazioni in un cluster Kubernetes.

Obiettivi

  • Creare un cluster Google Kubernetes Engine (GKE).
  • Utilizza kpt per scaricare un insieme esistente di configurazioni Kubernetes.
  • Utilizza le funzioni kpt per personalizzare le configurazioni.
  • Applica la tua configurazione al cluster GKE.
  • Utilizza kpt per eseguire il pull di alcune modifiche upstream per la tua configurazione.
  • Utilizza kpt in uno scenario reale per proteggere il tuo cluster GKE.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

  • Google Kubernetes Engine

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Prima di iniziare

  1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

  2. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  3. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  4. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  5. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  6. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

  7. Configura Cloud Shell per utilizzare il tuo progetto:

    gcloud config set project PROJECT_ID

  8. In Cloud Shell, abilita le API Google Kubernetes Engine e Cloud Source Repositories:

    gcloud services enable container.googleapis.com \
   sourcerepo.googleapis.com

Al termine di questo tutorial, puoi evitare di continuare la fatturazione eliminando le risorse che hai creato. Per maggiori dettagli, consulta Pulizia.

Crea un cluster GKE

In questa sezione creerai il cluster GKE in cui eseguirai il deployment delle configurazioni nel tutorial.

  1. In Cloud Shell, crea un cluster GKE:

    gcloud container clusters create kpt-tutorial \
   --num-nodes=1 --machine-type=n1-standard-4 \
   --zone=us-central1-a --enable-network-policy

  2. Verifica di avere accesso al cluster. Il seguente comando restituisce informazioni sul nodo o sui nodi che si trovano nel cluster.

    kubectl get nodes

Applicazione di un pacchetto kpt

In questa sezione utilizzerai kpt per scaricare un insieme di configurazioni, personalizzarle e applicarle al cluster che hai creato nella sezione precedente. kpt deve essere installato nel tuo ambiente Cloud Shell. In caso contrario, installalo con i seguenti comandi:

  1. In Cloud Shell, installa kpt:

    sudo apt update && sudo apt-get install google-cloud-sdk-kpt

  2. Scarica un insieme di configurazioni di esempio. Per maggiori informazioni, consulta kpt pkg get.

    kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.9

    Il comando precedente scarica il pacchetto di esempio wordpress disponibile nel repository GitHub kpt, con la versione taggata v0.9.

  3. Esamina i contenuti del pacchetto: kpt pkg tree.

    kpt pkg tree wordpress

    L'output sarà simile al seguente:

    Package "wordpress"
├── [Kptfile]  Kptfile wordpress
├── [service.yaml]  Service wordpress
├── deployment
│   ├── [deployment.yaml]  Deployment wordpress
│   └── [volume.yaml]  PersistentVolumeClaim wp-pv-claim
└── Package "mysql"
    ├── [Kptfile]  Kptfile mysql
    ├── [deployment.yaml]  PersistentVolumeClaim mysql-pv-claim
    ├── [deployment.yaml]  Deployment wordpress-mysql
    └── [deployment.yaml]  Service wordpress-mysql

    Il pacchetto contiene due pacchetti: wordpress e un sottopacchetto wordpress/mysql, entrambi contengono un file di metadati Kptfile. Kptfile viene utilizzato solo da kpt stesso e dispone di dati sull'origine, sulla personalizzazione e sulla convalida a monte del pacchetto

  4. Aggiorna l'etichetta del pacchetto

    L'autore del pacchetto ha aggiunto una pipeline di rendering, che viene spesso utilizzata per trasmettere le personalizzazioni previste.

    less wordpress/Kptfile

    I contenuti dovrebbero avere il seguente aspetto:

    apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: wordpress
upstream:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt
    directory: /package-examples/wordpress
    ref: v0.9
  updateStrategy: resource-merge
upstreamLock:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt
    directory: /package-examples/wordpress
    ref: package-examples/wordpress/v0.9
    commit: b9ea0bca019dafa9f9f91fd428385597c708518c
info:
  emails:
    - kpt-team@google.com
  description: This is an example wordpress package with mysql subpackage.
pipeline:
  mutators:
    - image: gcr.io/kpt-fn/set-labels:v0.1
      configMap:
        app: wordpress
  validators:
    - image: gcr.io/kpt-fn/kubeval:v0.3

    Puoi usare il tuo editor preferito per modificare i parametri della funzione set-label da app: wordpress a app: my-wordpress

  5. Modifica il deployment MySQL wordpress/mysql/deployment.yaml utilizzando il tuo editor di codice preferito per cambiare la versione MySQL. Inoltre, per rafforzare ulteriormente la sicurezza, cambia la variabile MYSQL_ROOT_PASSWORD in MYSQL_PASSWORD e aggiungi le seguenti variabili:

    • MYSQL_USER
    • MYSQL_RANDOM_ROOT_PASSWORD
    • MYSQL_DATABASE

    Prima del:

    [...]
  containers:
    - name: mysql
      image: mysql:5.6
      ports:
        - name: mysql
          protocol: TCP
          containerPort: 3306
      env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
[...]

    Dopo il:

    [...]
  containers:
    - name: mysql
      image: mysql:8.0
      ports:
        - name: mysql
          protocol: TCP
          containerPort: 3306
      env:
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: MYSQL_RANDOM_ROOT_PASSWORD
          value: '1'
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_DATABASE
          value: wordpress
[...]

  6. Modifica il deployment di Wordpress wordpress/deployment/deployment.yaml utilizzando il tuo editor di codice preferito per cambiare la versione di Wordpress e aggiungere una variabile WORDPRESS_DB_USER.

    Prima del:

    [...]
  containers:
    - name: wordpress
      image: wordpress:6.1-apache
      ports:
        - name: wordpress
          protocol: TCP
          containerPort: 80
      env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
[...]

    Dopo il:

    [...]
  containers:
    - name: wordpress
      image: wordpress:4.8-apache
      ports:
        - name: wordpress
          protocol: TCP
          containerPort: 80
      env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: WORDPRESS_DB_USER
          value: wordpress
[...]

    A differenza degli strumenti che operano solo tramite parametri, kpt consente di modificare i file esistenti utilizzando un editor per poi unire gli aggiornamenti upstream. Puoi modificare direttamente deployment.yaml senza dover creare una patch o creare una funzione nella pipeline.

  7. Annota la configurazione con sample-annotation: sample-value.

    kpt fn eval wordpress --image gcr.io/kpt-fn/set-annotations:v0.1 \
  -- sample-annotation=sample-value

    L'output dovrebbe essere simile al seguente:

    [RUNNING] "gcr.io/kpt-fn/set-annotations:v0.1"
[PASS] "gcr.io/kpt-fn/set-annotations:v0.1"

    Per visualizzare la nuova annotazione, puoi esaminare qualsiasi valore di configurazione. Puoi vedere wordpress/service.yaml

    In questo esempio abbiamo eseguito una personalizzazione utilizzando una funzione in un modo non previsto dall'autore del pacchetto. kpt è in grado di supportare l'esecuzione di funzioni dichiarative e imperative per consentire un'ampia gamma di scenari.

    Se il pacchetto è stato sviluppato utilizzando Infrastructure as Code, dobbiamo andare al codice sorgente del pacchetto e modificare il codice.

  8. Esegui la pipeline e convalida le modifiche utilizzando kubeval tramite kpt.

    kpt fn render wordpress

    L'autore del pacchetto ha incluso un passaggio di convalida nella pipeline:

    ...
validators:
    - image: gcr.io/kpt-fn/kubeval:v0.3

    L'output riuscito di questa pipeline di rendering ha il seguente aspetto:

    Package "wordpress/mysql":
[RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
[PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s

Package "wordpress":
[RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
[PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s
[RUNNING] "gcr.io/kpt-fn/kubeval:v0.3"
[PASS] "gcr.io/kpt-fn/kubeval:v0.3" in 3.7s

Successfully executed 3 function(s) in 2 package(s).

    Questo passaggio è un esempio dei vantaggi del modello di risorse Kubernetes: poiché le tue configurazioni sono rappresentate in questo modello molto noto, puoi utilizzare gli strumenti Kubernetes esistenti come kubeval.

  9. Esamina le differenze tra la versione locale delle configurazioni e la configurazione upstream:

    kpt pkg diff wordpress

  10. Inizializza il pacchetto per il deployment:

    kpt live init wordpress

    Il comando precedente crea un inventario delle configurazioni presenti nel pacchetto. Tra le altre cose, kpt utilizza l'inventario per eliminare le configurazioni quando le rimuovi dal pacchetto. Per saperne di più, consulta kpt live.

  11. Crea un secret contenente la password MySQL:

    kubectl create secret generic mysql-pass --from-literal=password=foobar

  12. Applica le configurazioni al tuo cluster GKE:

    kpt live apply wordpress

    L'output sarà simile al seguente:

    installing inventory ResourceGroup CRD.
inventory update started
inventory update finished
apply phase started
service/wordpress apply successful
service/wordpress-mysql apply successful
deployment.apps/wordpress apply successful
deployment.apps/wordpress-mysql apply successful
persistentvolumeclaim/mysql-pv-claim apply successful
persistentvolumeclaim/wp-pv-claim apply successful
apply phase finished
reconcile phase started
service/wordpress reconcile successful
service/wordpress-mysql reconcile successful
deployment.apps/wordpress reconcile pending
deployment.apps/wordpress-mysql reconcile pending
persistentvolumeclaim/mysql-pv-claim reconcile pending
persistentvolumeclaim/wp-pv-claim reconcile pending
persistentvolumeclaim/wp-pv-claim reconcile successful
persistentvolumeclaim/mysql-pv-claim reconcile successful
deployment.apps/wordpress-mysql reconcile successful
deployment.apps/wordpress reconcile successful
reconcile phase finished
inventory update started
inventory update finished
apply result: 6 attempted, 6 successful, 0 skipped, 0 failed
reconcile result: 6 attempted, 6 successful, 0 skipped, 0 failed, 0 timed out

  13. Attendi qualche minuto, quindi verifica che tutto funzioni come previsto:

    kpt live status wordpress

    L'output sarà simile al seguente:

    inventory-88521939/deployment.apps/default/wordpress is Current: Deployment is available. Replicas: 1
inventory-88521939/persistentvolumeclaim/default/wp-pv-claim is Current: PVC is Bound
inventory-88521939/service/default/wordpress-mysql is Current: Service is ready
inventory-88521939/persistentvolumeclaim/default/mysql-pv-claim is Current: PVC is Bound
inventory-88521939/deployment.apps/default/wordpress-mysql is Current: Deployment is available. Replicas: 1
inventory-88521939/service/default/wordpress is Current: Service is ready

Aggiornamento del pacchetto locale in corso...

In questa sezione aggiorni la versione locale del pacchetto con alcune modifiche dal pacchetto upstream.

  1. Creare un repository Git per le tue configurazioni e configurare la tua email e il tuo nome. Per aggiornare il pacchetto è necessario un repository Git locale. Sostituisci YOUR_EMAIL con il tuo indirizzo email e sostituisci YOUR_NAME con il tuo nome.

    cd wordpress/
git init -b main
git config user.email "YOUR_EMAIL"
git config user.name "YOUR_NAME"

  2. Esegui il commit delle configurazioni:

    git add .
git commit -m "First version of Wordpress package"
cd ..

  3. Aggiorna il pacchetto locale. In questo passaggio, eseguirai il pull della versione v0.10 dall'upstream.

    kpt pkg update wordpress@v0.10

  4. Tieni presente che gli aggiornamenti provenienti dall'upstream vengono applicati al tuo pacchetto locale:

    cd wordpress/
git diff

    In questo caso, l'aggiornamento ha modificato il volume di deployment di Wordpress da 3Gi a 4Gi. Puoi anche vedere le tue modifiche.

  5. Esegui il commit delle modifiche:

    git commit -am "Update to package version v0.10"

  6. Applica la nuova versione del pacchetto:

    kpt live apply .

Rimozione di una risorsa e di un pacchetto

Poiché kpt monitora le risorse che crea, può eliminare risorse dal cluster quando elimini risorse dal pacchetto. Può anche rimuovere completamente un pacchetto dal cluster. In questa sezione rimuoverai una risorsa dal pacchetto, quindi il pacchetto.

  1. Rimuovi il file service.yaml dal pacchetto:

    git rm service.yaml
git commit -m "Remove service"

  2. Applica la modifica, quindi verifica che kpt abbia eliminato il servizio Wordpress:

    kpt live apply .
kubectl get svc

  3. Rimuovi il resto del pacchetto dal cluster, quindi verifica che non sia rimasto nulla nel cluster:

    kpt live destroy .
kubectl get deployment

Utilizzo di kpt per proteggere GKE

Il comando kpt live non è l'unico modo con cui puoi applicare un pacchetto a un cluster Kubernetes. In questa sezione utilizzerai kpt con Config Sync in uno scenario di base ma realistico. Lo strumento Config Sync consente di gestire la configurazione in modo centralizzato, uniforme e dichiarativo per tutti i cluster Kubernetes da un repository Git. GKE Enterprise (che utilizzerai in questo tutorial) include Config Sync.

I progetti per la sicurezza di GKE Enterprise forniscono una gamma di impostazioni di sicurezza predefinite per i carichi di lavoro basati su GKE Enterprise. In questa sezione, utilizzerai il progetto per la limitazione del traffico (e la sua directory nel repository GitHub). Utilizza kpt per scaricare il pacchetto default-deny. Il pacchetto utilizza i criteri di rete Kubernetes per negare tutto il traffico nel cluster GKE per impostazione predefinita (tranne per la risoluzione DNS). Per applicare le configurazioni, esegui il commit delle configurazioni nel repository Git di Config Sync.

Installa Config Sync

In questa sezione creerai il repository Git necessario a Config Sync e poi installerai Config Sync sul tuo cluster GKE.

  1. In Cloud Shell, utilizza Cloud Source Repositories per creare un repository Git per Config Sync:

    cd ~
gcloud source repos create config-management

  2. Genera una coppia di chiavi SSH per l'autenticazione nel repository Git:

    cd ~
ssh-keygen -t rsa -b 4096  -N '' \
   -f cloud_source_repositories_key

  3. Crea il secret di Kubernetes che contiene la chiave privata SSH per accedere al repository Git:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-file=ssh=cloud_source_repositories_key

  4. Visualizza la chiave pubblica e copiala:

    cat cloud_source_repositories_key.pub

  5. Vai a Cloud Source Repositories

    Gestisci chiavi SSH.

  6. Nella finestra di dialogo Registra chiave SSH visualizzata, inserisci i seguenti valori:

    1. Nel campo Nome chiave, inserisci config-management.
    2. Incolla la chiave pubblica nel campo Key (Chiave).
    3. Fai clic su Registrati.

  7. Clona il repository Git in Cloud Shell:

    gcloud source repos clone config-management
cd config-management
git checkout -b main

  8. Scarica lo strumento a riga di comando di Config Sync denominato nomos. nomos deve essere installato all'interno del tuo ambiente Cloud Shell. In caso contrario, installalo con i seguenti comandi:

    sudo apt update && sudo apt-get install google-cloud-sdk-nomos

  9. Inizializza il repository Config Sync:

    nomos init
git add .
git commit -m "Config Management directory structure"
git push -u origin main

  10. Esegui il deployment dell'operatore Config Sync:

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml /tmp/config-management-operator.yaml
kubectl apply -f /tmp/config-management-operator.yaml

Configura Config Sync

  1. Crea una risorsa personalizzata ConfigManagement per configurare Config Sync:

    PROJECT=$(gcloud config get-value project)
EMAIL=$(gcloud config get-value account)
cat <<EOF > /tmp/config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  clusterName: kpt-tutorial
  git:
    syncRepo: ssh://${EMAIL}@source.developers.google.com:2022/p/${PROJECT}/r/config-management
    syncBranch: main
    secretType: ssh
EOF
kubectl -n config-management-system \
    apply -f /tmp/config-management.yaml

    Per ulteriori opzioni di installazione, consulta la documentazione di Config Sync per l'installazione.

  2. In Cloud Shell, verifica che Config Sync funzioni correttamente:

    nomos status --contexts=$(kubectl config current-context)

    Questo comando restituisce lo stato SYNCED. L'inizializzazione di Config Sync potrebbe richiedere un po' di tempo. Se lo stato non viene aggiornato, attendi qualche minuto ed esegui nuovamente il comando.

Applica il progetto di sicurezza di GKE Enterprise

In questa sezione utilizzerai kpt per scaricare il pacchetto default-deny del progetto per la sicurezza di GKE Enterprise per il traffico limitato. Quindi puoi utilizzare Config Sync per applicare il pacchetto solo allo spazio dei nomi default.

  1. Scarica il pacchetto default-deny:

    cd ~
kpt pkg get https://github.com/GoogleCloudPlatform/anthos-security-blueprints.git/restricting-traffic/default-deny ./

    Puoi esplorare il contenuto del pacchetto: il file default-deny/Kptfile contiene i metadati del pacchetto, mentre il file default-deny/default-deny.yaml contiene un NetworkPolicy di Kubernetes, che è l'unica configurazione di questo progetto base.

  2. Utilizza kpt per copiare il contenuto del pacchetto nel repository Config Sync, quindi aggiungi etichette per personalizzarlo:

    kpt fn source default-deny/ | \
    kpt fn eval - --image=gcr.io/kpt-fn/set-annotations:v0.1 -- \
    anthos-security-blueprint=restricting-traffic | \
    kpt fn sink ~/config-management/namespaces/default/

    Come mostrato in questo esempio, puoi utilizzare le barre verticali per concatenare i comandi kpt fn. La concatenazione dei comandi kpt fn consente di leggere le configurazioni, modificarle come preferisci e scrivere il risultato. Puoi concatenare tutti i comandi kpt fn che vuoi.

  3. Crea il file namespace.yaml nel repository Config Sync:

    cat >> ~/config-management/namespaces/default/namespace.yaml <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: default
EOF

    Lo spazio dei nomi default esiste nel tuo cluster GKE, ma Config Sync non lo gestisce. Quando crei la directory e il file in questo passaggio, Config Sync può gestire lo spazio dei nomi. Per applicare il pacchetto a più spazi dei nomi contemporaneamente, puoi creare uno spazio dei nomi astratto.

  4. Verifica che i criteri di rete Kubernetes siano stati scritti nel repository Config Sync e che siano annotati con anthos-security-blueprint: restricting-traffic:

    cat config-management/namespaces/default/default-deny.yaml

    L'output sarà simile al seguente:

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata: # kpt-merge: /default-deny
  name: default-deny
  annotations:
    internal.kpt.dev/upstream-identifier: 'networking.k8s.io|NetworkPolicy|default|default-deny'
    anthos-security-blueprint: restricting-traffic
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          k8s-namespace: kube-system
      podSelector:
        matchExpressions:
        - key: k8s-app
          operator: In
          values: ["kube-dns", "node-local-dns"]
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

  5. Esegui il commit delle modifiche ed eseguine il push:

    cd ~/config-management/
git add namespaces/default/
git commit -m "Default deny"
git push

  6. Verifica che la nuova norma venga applicata:

    kubectl get networkpolicies

    Se il nuovo criterio non è presente, attendi qualche secondo ed esegui di nuovo il comando. Per impostazione predefinita, Config Sync aggiorna le configurazioni ogni 15 secondi. Se hai bisogno di ulteriori procedure di risoluzione dei problemi, esegui questo comando per ottenere informazioni su potenziali errori di Config Sync:

    nomos status --contexts=$(kubectl config current-context)

  7. Per testare il nuovo criterio, ottieni una shell in un pod in esecuzione all'interno dello spazio dei nomi default:

    kubectl -n default run -i --tty --rm test \
        --image=busybox --restart=Never -- sh

  8. Prova a inviare un ping a 8.8.8.8 e vedrai che non funziona, come previsto:

    ping -c 3 -W 1 8.8.8.8

    L'output sarà simile al seguente:

    PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

  9. Prova a eseguire una query sul server API Kubernetes e verifica che non funziona, come previsto:

    wget --timeout=3 https://${KUBERNETES_SERVICE_HOST}

    L'output sarà simile al seguente:

    Connecting to 10.3.240.1 (10.3.240.1:443)
wget: download timed out

  10. Esci dal pod:

    exit

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina le risorse

Se vuoi conservare il progetto Google Cloud che hai utilizzato in questo tutorial, puoi eliminare il repository Git e il cluster GKE. In Cloud Shell, esegui questi comandi:

gcloud source repos delete config-management --quiet
gcloud container clusters delete kpt-tutorial \
    --async --quiet --zone=us-central1-a

Passaggi successivi