Gérer une infrastructure cloud à l'aide de kpt

Last reviewed 2023-03-15 UTC
Ce tutoriel présente kpt, un outil Open Source de Google qui vous permet d'empaqueter, d'extraire, de mettre à jour et de modifier les configurations Kubernetes (également appelées fichiers manifestes. Il s'agit d'une alternative aux outils basés sur des modèles lorsque vous souhaitez clairement distinguer les configurations des opérations portant sur ces configurations. Kpt permet de réutiliser et de partager le code qui agit sur les configurations (pour les modifier ou les inspecter).

Ce tutoriel explique également comment associer kpt à d'autres solutions Google, telles que Config Sync et les plans de sécurité GKE Enterprise. Que vous soyez un développeur utilisant Kubernetes ou un ingénieur de plate-forme gérant une plate-forme basée sur Kubernetes, ce tutoriel vous explique comment utiliser kpt dans vos propres workflows associés à Kubernetes. Dans ce tutoriel, nous partons du principe que vous connaissez Kubernetes et Google Cloud.

La configuration déclarative de l'infrastructure cloud est une pratique bien établie dans le secteur informatique. Elle apporte une abstraction performante des systèmes sous-jacents. Cette abstraction vous évite d'avoir à gérer les dépendances et les détails des configurations de bas niveau. La configuration déclarative présente donc un avantage par rapport aux approches impératives, telles que les opérations effectuées dans les interfaces graphiques et les interfaces de ligne de commande.

Le modèle de ressource Kubernetes a contribué à généraliser les approches de configurations déclaratives. L'API Kubernetes étant entièrement déclarative par nature, vous ne lui dites que ce que vous souhaitez, et non la façon d'y parvenir. L'API Kubernetes vous permet de distinguer clairement la configuration (souhaitée ou réelle) des opérations portant sur cette configuration (ajout, suppression et modification d'objets). En d'autres termes, dans le modèle de ressource Kubernetes, la configuration correspond à des données, et non à du code.

La distinction entre la configuration et les opérations présente plusieurs avantages : les personnes et les systèmes automatisés sont capables de comprendre et d'utiliser la configuration, et le logiciel qui modifie la configuration est facilement réutilisable. Elle vous permet également de facilement mettre en œuvre une méthodologie GitOps (telle que définie dans le tutoriel Livraison continue de type GitOps avec Cloud Build).

Dans ce tutoriel, vous allez découvrir cette distinction entre la déclaration de configuration et les opérations portant sur la configuration à l'aide de kpt. Ce tutoriel présente les fonctionnalités suivantes de kpt :

  • Gestion des packages : téléchargement et mise à jour des packages de configuration Kubernetes
  • Fonctions : exécution de fragments de code arbitraires pour modifier ou valider des configurations
  • Pipeline de fonction : ensemble de fonctions que l'auteur du package a incluses avec le package.
  • Gestion des ressources : application, mise à jour et suppression des ressources correspondant aux configurations d'un cluster Kubernetes.

Objectifs

  • Créer un cluster Google Kubernetes Engine (GKE)
  • Télécharger un ensemble existant de configurations Kubernetes à l'aide de kpt
  • Utilisez les fonctions kpt pour personnaliser les configurations.
  • Appliquer une configuration au cluster GKE
  • Importer des modifications en amont de votre configuration à l'aide de kpt
  • Utiliser kpt dans un scénario concret pour renforcer la sécurité du cluster GKE

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

  • Google Kubernetes Engine

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

  1. Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

  2. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  3. Vérifiez que la facturation est activée pour votre projet Google Cloud.

  4. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  5. Vérifiez que la facturation est activée pour votre projet Google Cloud.

  6. Dans la console Google Cloud, activez Cloud Shell.

    Activer Cloud Shell

    En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

  7. Configurez Cloud Shell pour utiliser votre projet :

    gcloud config set project PROJECT_ID

  8. Dans Cloud Shell, activez les API Google Kubernetes Engine et Cloud Source Repositories :

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

Une fois que vous avez terminé ce dernier, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour plus d'informations, consultez la section Nettoyer.

Créer un cluster GKE

Dans cette section, vous allez créer le cluster GKE dans lequel vous déploierez les configurations dans la suite de ce tutoriel.

  1. Dans Cloud Shell, créez 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. Vérifiez que vous avez accès au cluster. La commande suivante renvoie des informations sur les nœuds du cluster.

    kubectl get nodes

Appliquer un package kpt

Dans cette section, vous allez utiliser kpt pour télécharger un ensemble de configurations, les personnaliser et les appliquer au cluster créé dans la section précédente. kpt doit être installé dans votre environnement Cloud Shell. Si ce n'est pas le cas, installez-le à l'aide des commandes suivantes:

  1. Dans Cloud Shell, installez kpt :

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

  2. Téléchargez un exemple d'ensemble de configurations. Pour en savoir plus, consultez les sections sur kpt pkg get

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

    La commande ci-dessus télécharge l'exemple de package wordpress disponible dans le dépôt GitHub kpt, dans la version avec le tag v0.9.

  3. Examinez le contenu du package : kpt pkg tree.

    kpt pkg tree wordpress

    La sortie ressemble à ceci :

    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

    Le package contient deux packages de niveau supérieur wordpress et un sous-package wordpress/mysql. Ces deux packages contiennent un fichier de métadonnées Kptfile. La valeur Kptfile n'est consommée que par kpt elle-même et dispose de données sur la source en amont, la personnalisation et la validation du package.

  4. Mettre à jour le libellé du package

    L'auteur du package a ajouté un pipeline de rendu souvent utilisé pour transmettre les personnalisations attendues.

    less wordpress/Kptfile

    Le contenu doit ressembler à ceci :

    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

    Vous pouvez utiliser votre éditeur favori pour passer les paramètres de la fonction de libellé défini de app: wordpress à app: my-wordpress.

  5. Modifiez le déploiement MySQL wordpress/mysql/deployment.yaml à l'aide de l'éditeur de code de votre choix pour modifier la version MySQL. En outre, pour renforcer la sécurité, remplacez la variable MYSQL_ROOT_PASSWORD par MYSQL_PASSWORD et ajoutez les variables suivantes:

    • MYSQL_USER
    • MYSQL_RANDOM_ROOT_PASSWORD
    • MYSQL_DATABASE

    Avant :

    [...]
  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
[...]

    Après :

    [...]
  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. Modifiez le déploiement WordPress wordpress/deployment/deployment.yaml à l'aide de l'éditeur de code de votre choix afin de modifier la version WordPress et d'ajouter une variable WORDPRESS_DB_USER.

    Avant :

    [...]
  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
[...]

    Après :

    [...]
  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
[...]

    Contrairement aux outils qui ne fonctionnent que par le biais du paramètre kpt, vous pouvez modifier des fichiers existants à l'aide d'un éditeur, puis fusionner les mises à jour en amont. Vous pouvez modifier directement deployment.yaml sans avoir à créer de correctif ni de fonction dans le pipeline.

  7. Annotez la configuration avec sample-annotation: sample-value.

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

    Le résultat devrait ressembler à ceci :

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

    Pour afficher la nouvelle annotation, vous pouvez examiner n'importe quelle valeur de configuration, par exemple wordpress/service.yaml.

    Dans cet exemple, nous avons effectué une personnalisation à l'aide d'une fonction que l'auteur du package n'avait pas planifiée. kpt est compatible avec l'exécution de fonctions déclaratives et impératives, ce qui permet un large éventail de scénarios.

    Si ce package a été développé en utilisant l'infrastructure-as-code, nous devrons accéder à la source du package et modifier le code.

  8. Exécutez le pipeline et validez les modifications à l'aide de kubeval via kpt.

    kpt fn render wordpress

    L'auteur du package a inclus une étape de validation dans le pipeline.

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

    Le résultat positif de ce pipeline de rendu est semblable à ceci :

    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).

    Cette étape illustre les avantages du modèle de ressource Kubernetes : comme vos configurations sont représentées dans ce modèle bien connu, vous pouvez utiliser des outils Kubernetes existants tels que kubeval.

  9. Examinez les différences entre votre version locale des configurations et la configuration en amont :

    kpt pkg diff wordpress

  10. Initialisez le package pour le déploiement :

    kpt live init wordpress

    La commande ci-dessus crée un inventaire des configurations incluses dans le package. kpt utilise, entre autres, l'inventaire pour restreindre les configurations lorsque vous les supprimez du package. Pour en savoir plus, consultez la page kpt live.

  11. Créez un secret contenant le mot de passe MySQL :

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

  12. Appliquez les configurations au cluster GKE :

    kpt live apply wordpress

    La sortie ressemble à ceci :

    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. Patientez quelques minutes, puis vérifiez que tout fonctionne comme prévu :

    kpt live status wordpress

    La sortie ressemble à ceci :

    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

Mettre à jour votre package local

Dans cette section, vous allez mettre à jour votre version locale du package avec certaines modifications du package en amont.

  1. Créez un dépôt Git pour vos configurations, et définissez votre adresse e-mail et votre nom. Vous devez disposer d'un dépôt Git local pour pouvoir mettre à jour le package. Remplacez YOUR_EMAIL par votre adresse e-mail et YOUR_NAME par votre nom.

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

  2. Validez vos configurations :

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

  3. Mettez à jour votre package local. Au cours de cette étape, vous récupérez la version v0.10 du package en amont.

    kpt pkg update wordpress@v0.10

  4. Vous pouvez constater que les mises à jour du package en amont sont appliquées à votre package local :

    cd wordpress/
git diff

    Dans ce cas, la mise à jour fait passer le volume de déploiement WordPress de 3 Gi à 4 Gi. Vous pouvez également voir vos propres modifications.

  5. Validez vos modifications :

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

  6. Appliquez la nouvelle version du package :

    kpt live apply .

Supprimer une ressource et un package

Étant donné que kpt surveille les ressources qu'il crée, il peut les supprimer du cluster lorsque vous les supprimez du package. Il peut également supprimer complètement un package du cluster. Dans cette section, vous allez supprimer une ressource du package, puis le package entier.

  1. Supprimez le fichier service.yaml du package :

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

  2. Appliquez la modification, puis vérifiez que kpt a supprimé le service  :

    kpt live apply .
kubectl get svc

  3. Supprimez les éléments restants du package dans le cluster, puis vérifiez que celui-ci est vide :

    kpt live destroy .
kubectl get deployment

Utiliser kpt pour renforcer la sécurité de votre cluster GKE

La commande kpt live n'est pas le seul moyen d'appliquer un package à un cluster Kubernetes. Dans cette section, vous allez utiliser kpt avec Config Sync dans un scénario basique, mais réaliste. L'outil Config Sync vous permet de gérer votre configuration de manière centralisée, uniforme et déclarative pour tous vos clusters Kubernetes à partir d'un dépôt Git. GKE Enterprise (que vous utilisez dans ce tutoriel) inclut Config Sync.

Les plans de sécurité GKE Enterprise fournissent un ensemble de paramètres de sécurité pré-installés pour vos charges de travail basées sur GKE Enterprise. Dans cette section, vous utilisez le plan de restriction de trafic (et son répertoire dans le dépôt GitHub). Vous téléchargez le package default-deny à l'aide de kpt. Le package utilise les règles de réseau Kubernetes pour refuser l'intégralité du trafic dans votre cluster GKE (sauf pour la résolution DNS). Pour appliquer les configurations, vous allez effectuer leur commit dans le dépôt Git Config Sync.

Installer Config Sync

Dans cette section, vous allez créer le dépôt Git dont Config Sync a besoin, puis installer Config Sync sur votre cluster GKE.

  1. Dans Cloud Shell, créez un dépôt Git pour Config Sync à l'aide de Cloud Source Repositories :

    cd ~
gcloud source repos create config-management

  2. Générez une paire de clés SSH pour vous authentifier auprès du dépôt Git :

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

  3. Créez le secret Kubernetes contenant la clé SSH privée requise pour accéder au dépôt 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. Affichez la clé publique, puis copiez-la :

    cat cloud_source_repositories_key.pub

  5. Accéder à Cloud Source Repositories

    Page Gérer les clés SSH

  6. Dans la boîte de dialogue Register SSH Key (Enregistrer la clé SSH) qui s'affiche, saisissez les valeurs suivantes :

    1. Dans le champ Nom de la clé, saisissez config-management.
    2. Dans le champ Clé, collez la clé publique.
    3. Cliquez sur Enregistrer.

  7. Clonez le dépôt Git dans Cloud Shell :

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

  8. Téléchargez l'outil de ligne de commande Config Sync appelé nomos. nomos doit être installé dans votre environnement Cloud Shell. Si ce n'est pas le cas, installez-le à l'aide des commandes suivantes:

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

  9. Initialisez le dépôt Config Sync :

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

  10. Déployez Config Sync Operator :

    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

Configurer Config Sync

  1. Créez une ressource personnalisée ConfigManagement pour configurer 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

    Pour plus d'options d'installation, consultez la documentation Installer Sync.

  2. Dans Cloud Shell, vérifiez que Config Sync fonctionne correctement :

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

    Cette commande renvoie l'état SYNCED. L'initialisation de Config Sync peut prendre un certain temps. Si l'état n'est pas mis à jour, patientez quelques minutes, puis exécutez à nouveau la commande.

Appliquer le plan de sécurité GKE Enterprise

Dans cette section, vous allez utiliser kpt pour télécharger le package default-deny du plan de sécurité GKE Enterprise visant à restreindre le trafic. Vous utiliserez ensuite Config Sync pour n'appliquer le package qu'à l'espace de noms default.

  1. Téléchargez le package default-deny :

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

    Vous pouvez explorer le contenu du package : le fichier default-deny/Kptfile contient les métadonnées du package et le fichier default-deny/default-deny.yaml contient une ressource Kubernetes NetworkPolicy (seule configuration du plan).

  2. Utilisez kpt pour copier le contenu du package dans le dépôt Config Sync, puis ajoutez des libellés pour le personnaliser :

    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/

    Comme le montre cet exemple, vous pouvez utiliser des barres verticales pour relier les commandes kpt fn. Le fait de relier les commandes kpt fn vous permet de lire les configurations, de les modifier à votre guise et d'écrire le résultat. Vous pouvez relier autant de commandes kpt fn que vous le souhaitez.

  3. Créez le fichier namespace.yaml dans le dépôt Config Sync :

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

    L'espace de noms default se trouve dans votre cluster GKE, mais Config Sync ne le gère pas. Lorsque vous créez le répertoire et le fichier à cette étape, vous configurez Config Sync pour gérer l'espace de noms. Pour appliquer simultanément le package à plusieurs espaces de noms, vous pouvez créer un espace de noms abstrait.

  4. Vérifiez que les ressources Kubernetes NetworkPolicies ont été écrites dans le dépôt Config Sync et qu'elles sont annotées avec anthos-security-blueprint: restricting-traffic :

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

    La sortie ressemble à ceci :

    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. Validez et appliquez les modifications :

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

  6. Vérifiez que la nouvelle règle est appliquée :

    kubectl get networkpolicies

    Si la nouvelle règle n'est pas présente, patientez quelques secondes, puis exécutez à nouveau la commande. Config Sync met à jour les configurations toutes les 15 secondes par défaut. Si vous devez appliquer une procédure de dépannage supplémentaire, exécutez la commande suivante pour obtenir des informations sur les éventuelles erreurs Config Sync :

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

  7. Pour tester la nouvelle règle, ouvrez une interface système dans un pod qui s'exécute dans l'espace de noms default :

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

  8. Essayez de pinguer 8.8.8.8 et vérifiez que cela ne fonctionne pas, comme prévu :

    ping -c 3 -W 1 8.8.8.8

    La sortie ressemble à ceci :

    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. Interrogez le serveur d'API Kubernetes et vérifiez qu'il ne fonctionne pas, comme prévu :

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

    La sortie ressemble à ceci :

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

  10. Fermez le pod :

    exit

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer le projet

  1. Dans la console Google Cloud, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer les ressources

Si vous souhaitez conserver le projet Google Cloud utilisé dans ce tutoriel, vous pouvez supprimer le dépôt Git et le cluster GKE. Dans Cloud Shell, exécutez les commandes suivantes :

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

Étapes suivantes