Documentation sur Oracle Cloud Infrastructure

Utilisation de scripts d'initialisation personnalisés cloud-init pour configurer des noeuds gérés

Découvrez comment écrire des scripts cloud-init personnalisés à exécuter sur les noeuds de travail des grappes que vous avez créées à l'aide de Kubernetes Engine (OKE).

Cloud-init est la méthode standard de l'industrie pour l'initialisation d'instance en nuage, les systèmes de provisionnement pour l'infrastructure en nuage privée et les installations sans système d'exploitation. Il est pris en charge par tous les principaux fournisseurs de nuage public, notamment Oracle Cloud Infrastructure (voir Données d'utilisateur). Cloud-init exécute des scripts pour initialiser et configurer les instances. Pour plus d'informations sur cloud-init, consultez la documentation sur cloud-init.

Kubernetes Engine utilise cloud-init pour configurer les instances de calcul hébergeant les noeuds gérés. Kubernetes Engine installe un script de démarrage par défaut sur chaque instance hébergeant un noeud géré. Lorsque l'instance démarre pour la première fois, cloud-init exécute le script de démarrage par défaut. Le script de démarrage par défaut contient la logique suivante fournie par Kubernetes Engine :

#!/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

Vous pouvez personnaliser le script de démarrage par défaut en ajoutant votre propre logique au script, avant ou après la logique par défaut. La personnalisation du script de démarrage par défaut vous permet, par exemple :

  • configurer une politique SELinux sur tous les hôtes de noeud de travail à des fins de sécurité et de conformité
  • annuler l'affectation de l'adresse IP publique éphémère d'une instance au démarrage et réaffecter plutôt une adresse IP publique réservée à l'instance
  • configurer un mandataire d'entreprise
  • configurer des mandataires yum personnalisés
  • installer un logiciel antivirus obligatoire et d'autres outils de sécurité

Si vous personnalisez le script de démarrage par défaut, ne modifiez pas la logique fournie par Kubernetes Engine.

Vous pouvez personnaliser le script de démarrage par défaut lors de la création d'une grappe, de la création de nouveaux groupes de noeuds et de la modification de groupes de noeuds existants :

  • à l'aide de la console (lors de la création d'une grappe, utilisez le flux de travail de création personnalisée)
  • utilisation de l'interface de ligne de commande
  • utilisation de l'API

Le script de démarrage personnalisé s'exécute lorsqu'une instance hébergeant un noeud de travail démarre pour la première fois. Après avoir personnalisé le script de démarrage par défaut, il est conseillé d'exécuter le script Node Doctor pour vérifier que les noeuds de travail des instances nouvellement démarrées fonctionnent comme prévu (voir Dépannage des problèmes de noeud pour les grappes Kubernetes à l'aide du script Node Doctor).

Exemples d'utilisation pour les scripts Cloud-init personnalisés

Exemple 1 : Utilisation d'un script Cloud-init personnalisé pour configurer SELinux (Linux optimisé pour la sécurité) sur des noeuds gérés

Vous pouvez utiliser un script cloud-init personnalisé pour configurer SELinux sur les noeuds gérés. SELinux est une amélioration de la sécurité de Linux qui permet aux administrateurs de restreindre les utilisateurs et les applications qui peuvent accéder aux ressources en fonction des règles d'une politique. SELinux ajoute également une granularité plus fine aux contrôles d'accès.

SELinux peut avoir l'un des deux états, Activé ou Désactivé. Lorsqu'il est activé, SELinux peut s'exécuter dans l'un des deux modes suivants : Application ou Permissive.

Par défaut, SELinux est activé et réglé pour s'exécuter en mode permissif sur les noeuds de travail. Lors de l'exécution en mode permissif, SELinux n'applique pas les règles d'accès et effectue uniquement la journalisation.

Si vous voulez que SELinux applique des règles d'accès, vous pouvez le régler pour qu'il s'exécute en mode d'application. Lors de l'exécution en mode d'application, SELinux bloque les actions contraires à la politique et enregistre un événement correspondant dans le journal de vérification.

Pour définir SELinux à exécuter en mode d'application, utilisez le script cloud-init suivant :

#!/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

Pour confirmer le statut et le mode de SELinux qui s'exécute sur un noeud de travail, connectez-vous au noeud de travail et utilisez la commande getenforce. Lorsque le script cloud-init ci-dessus a été exécuté sur les noeuds de travail, la commande getenforce retourne Enforcing.

Exemple 2 : Utilisation d'un script Cloud-init personnalisé pour définir NodeLocal DNSCache sur les noeuds gérés

Vous pouvez utiliser un script cloud-init personnalisé pour configurer NodeLocal DNSCache sur les noeuds gérés. NodeLocal DNSCache améliore la performance du DNS de grappe en exécutant un agent de mise en mémoire cache DNS sur les noeuds de travail en tant que jeu de démons.

Si NodeLocal DNSCache n'est pas activé, les pods en mode DNS ClusterFirst communiquent avec un kube-dns serviceIP pour les interrogations DNS. À l'aide de règles iptables, cette demande est traduite en un point d'extrémité kube-dns/CoreDNS ajouté par kube-proxy. Pour plus d'informations, voir DNS pour les services et les pods dans la documentation sur Kubernetes.

Si NodeLocal DNSCache est activé, les pods communiquent avec un agent de mise en mémoire cache DNS s'exécutant sur le même noeud de travail, ce qui leur permet de contourner les règles DNAT iptables et le suivi de connexion. L'agent de mise en mémoire cache local interroge le service kube-dns/CoreDNS pour détecter les échecs de mémoire cache des noms d'hôte de grappe (suffixe cluster.local par défaut).

Pour configurer NodeLocal DNSCache, utilisez le script cloud-init suivant. Remplacez CLUSTER DNS par une adresse IP d'écoute locale qui n'est en conflit avec rien dans la grappe. Il existe un intervalle local de liens recommandé de 169.254.0.0/16 pour IPv4 ou à partir de l'intervalle d'adresses locales uniques de fd00 : :/8 pour 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]"

Pour confirmer que NodeLocal DNSCache a été déployé, connectez-vous à un noeud de travail et utilisez la commande sudo systemctl status -l kubelet. Lorsque le script cloud-init ci-dessus a été exécuté sur les noeuds de travail, la commande sudo systemctl status -l kubelet retourne --cluster-dns comme l'un des indicateurs kubelet, réglé à une adresse de lien local par défaut (par exemple, 169.254.20.10).

Après avoir créé des noeuds à l'aide du script cloud-init ci-dessus, déployez l'agent de mise en mémoire cache DNS en suivant les étapes décrites sous Utilisation de NodeLocal DNSCache dans les grappes Kubernetes dans la documentation sur Kubernetes. Une fois activé, un pod node-local-dns s'exécute dans l'espace de noms kube-system sur chacun des noeuds de la grappe. Le pod node-local-dns exécute CoreDNS en mode de mémoire cache, de sorte que toutes les mesures CoreDNS exposées par les différents plugiciels sont disponibles par noeud.

Pour tester la résolution DNS, utilisez une ou plusieurs des commandes suivantes (voir Débogage de la résolution DNS dans la documentation sur Kubernetes). Les commandes doivent fonctionner et afficher l'adresse IP définie par l'indicateur --cluster-dns dans le script cloud-init personnalisé : 

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

Vous pouvez désactiver NodeLocal DNSCache en supprimant le jeu de démons et en supprimant le manifeste nodelocaldns. Vous devez également annuler les modifications apportées à la configuration du kubelet.

Exemple 3 : Utilisation d'un script Cloud-init personnalisé pour définir des kubelet-extra-args sur des noeuds gérés

Vous pouvez utiliser un script cloud-init personnalisé pour configurer un certain nombre d'options supplémentaires sur le kubelet (agent de noeud principal) sur les noeuds gérés. Ces options supplémentaires sont parfois appelées kubelet-extra-args. Entre autres, l'utilisation des options kubelet-extra-args vous permet de :

  • configurer la verbosité du journal au niveau du débogage
  • utiliser des couleurs de noeud pour appliquer des politiques de planification

Utilisation de kubelet-extra-args pour configurer la verbosité du journal au niveau du débogage :

Pour configurer la verbosité du journal au niveau du débogage, utilisez le script cloud-init suivant :

#!/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"

Pour confirmer le paramètre de la verbosité de la journalisation au niveau du débogage, connectez-vous à un noeud de travail et utilisez la commande sudo systemctl status -l kubelet. Lorsque le script cloud-init ci-dessus a été exécuté sur les noeuds de travail, la commande sudo systemctl status -l kubelet retourne le niveau de verbosité 4. Les journaux de kubelet contiennent également plus de détails.

Utilisation de kubelet-extra-args pour ajouter des teintes de noeud :

Pour ajouter des couleurs de noeud pour appliquer des politiques de programmation, utilisez le script cloud-init suivant :

#!/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 "--register-with-taints=mytaint1=true:NoSchedule,mytaint2=true:NoSchedule"

Seuls les pods ayant une tolérance pour les deux teintes (la teinte mytaint1=true:NoSchedule et la teinte mytaint2=true:NoSchedule) seront programmés pour s'exécuter sur le noeud de travail.

Exemple 4 : Utilisation d'un script personnalisé Cloud-init pour réserver des ressources pour Kubernetes et les démons du système d'exploitation

Vous pouvez utiliser un script cloud-init personnalisé pour réserver des ressources d'UC et de mémoire pour les démons du système Kubernetes (tels que kubelet et container runtime) et les démons du système d'exploitation (tels que sshd et systemd). Pour réserver des ressources pour les démons du système d'exploitation et Kubernetes, incluez les indicateurs de kubelet --kube-reserved et --system-reserved respectivement en tant qu'options kubelet-extra-args dans un script cloud-init personnalisé.

Pour réserver des ressources pour les démons du système d'exploitation et de Kubernetes, utilisez le script cloud-init suivant :

#!/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"

Pour plus d'informations et pour connaître les valeurs recommandées pour les indicateurs de kubelet --kube-reserved et --system-reserved, voir Meilleures pratiques : Réserver les ressources pour les démons système Kubernetes et OS.

Exemple 5 : Utilisation d'un script personnalisé Cloud-init et d'oci-growfs pour augmenter la taille de la partition de volume de démarrage

Vous pouvez utiliser un script cloud-init personnalisé pour étendre la partition du volume de démarrage des noeuds gérés. Lorsque vous créez et mettez à jour des grappes et des groupes de noeuds, vous pouvez spécifier une taille personnalisée pour les volumes de démarrage des noeuds de travail. La taille du volume de démarrage personnalisé que vous spécifiez doit être supérieure à la taille du volume de démarrage par défaut de l'image que vous sélectionnez. Lorsque vous augmentez la taille du volume de démarrage, pour tirer parti de la taille du volume de démarrage supérieure, vous devez également étendre la partition du volume de démarrage .

Les images de plate-forme Oracle Linux incluent l'ensemble oci-utils. Vous pouvez utiliser la commande oci-growfs de cet ensemble dans un script cloud-init pour étendre la partition racine, puis agrandir le système de fichiers.

Pour étendre la partition pour le volume de démarrage, utilisez le script cloud-init suivant :

#!/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

Pour plus d'informations, voir Extension de la partition pour un volume de démarrage.

Création d'un script cloud-init personnalisé

Pour personnaliser le script de démarrage cloud-init par défaut fourni par Kubernetes Engine :

  1. Créez un fichier de script contenant la logique par défaut fournie par Kubernetes Engine. Vous pouvez procéder de deux façons :
    • En sélectionnant l'option Télécharger le modèle de script Cloud-Init personnalisé (dans la section Options avancées du groupe de noeuds) lors de l'utilisation de la boîte de dialogue Créer une grappe personnalisée, Ajouter un groupe de noeuds ou Modifier le groupe de noeuds. Le fichier que vous téléchargez contient la logique par défaut.
    • En créant un nouveau fichier à partir de zéro avec un type de fichier pris en charge par cloud-init (tel que .yaml) et en ajoutant la logique par défaut fournie par Kubernetes Engine. Par exemple :
      #!/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

  2. Avant ou après la logique par défaut fournie par Kubernetes Engine, ajoutez votre propre logique personnalisée au fichier de script. Ne modifiez pas la logique par défaut.

    Par exemple, pour configurer la verbosité de la journalisation au niveau du débogage, vous pouvez ajouter --kubelet-extra-args "--v=4" afin que le fichier se présente comme suit :

    #!/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"

    Pour d'autres exemples, voir Exemples d'utilisation pour les scripts Cloud-init personnalisés.

  3. Enregistrez le fichier de script cloud-init personnalisé que vous avez créé.
  4. Spécifiez le fichier de script cloud-init personnalisé lorsque vous créez une grappe, ajoutez un nouveau groupe de noeuds ou modifiez un groupe de noeuds existant :

Utilisation de la console

Pour utiliser la console afin de fournir un script cloud-init personnalisé pour les instances hébergeant des noeuds gérés dans une nouvelle grappe, un nouveau groupe de noeuds ou un groupe de noeuds existant :

  1. Créez un fichier cloud-init valide dans l'un des formats (par exemple, cloud-config) et les types de fichier (par exemple, un fichier .yaml) pris en charge par cloud-init. Voir Création d'un script Cloud-init personnalisé.
  2. Dans la page de liste Grappes, créez une grappe à l'aide du flux de création personnalisée, ajoutez un nouveau groupe de noeuds à une grappe existante ou modifiez un groupe de noeuds existant. Si vous avez besoin d'aide pour trouver la page de liste, voir Liste des grappes.
  3. Dans la section Options avancées du groupe de noeuds de la boîte de dialogue Créer une grappe personnalisée, Ajouter un groupe de noeuds ou Modifier le groupe de noeuds (le cas échéant), spécifiez :
    • Script d'initialisation : Script pour cloud-init à exécuter sur chaque instance hébergeant des noeuds de travail lorsque l'instance démarre pour la première fois. Le script que vous spécifiez doit être écrit dans l'un des formats pris en charge par cloud-init (par exemple, cloud-config) et doit être un type de fichier pris en charge (par exemple, .yaml). Spécifiez le script comme suit :
      • Sélectionner un script Cloud-Init : Sélectionnez un fichier contenant le script cloud-init ou glissez-déposez le fichier dans la zone.
      • Coller le script Cloud-Init : Copiez le contenu d'un script cloud-init et collez-le dans la zone.

      Si vous n'avez pas écrit auparavant de scripts cloud-init pour initialiser les noeuds de travail dans les grappes créées par Kubernetes Engine, il peut être utile de sélectionner Télécharger le modèle de script cloud-init personnalisé. Le fichier téléchargé contient la logique par défaut fournie par Kubernetes Engine. Vous pouvez ajouter votre propre logique personnalisée avant ou après la logique par défaut, mais ne modifiez pas la logique par défaut. Pour des exemples, voir Exemples de cas d'utilisation pour les scripts Cloud-init personnalisés.

Utilisation de l'interface de ligne de commande

Pour des informations sur l'utilisation de l'interface de ligne de commande, voir Interface de ligne de commande. Pour une liste complète des indicateurs et les options disponibles pour les commandes de l'interface de ligne de commande, voir Informations de référence sur la ligne de commande.

Pour utiliser l'interface de ligne de commande afin de fournir un script cloud-init personnalisé pour les instances hébergeant des noeuds de travail dans un nouveau groupe de noeuds ou dans un groupe de noeuds existant :

  1. Créez un fichier cloud-init valide dans l'un des formats (par exemple, cloud-config) et les types de fichier (par exemple, un fichier .yaml) pris en charge par cloud-init. Voir Création d'un script Cloud-init personnalisé.
  2. Ouvrez une invite de commande et entrez l'une des commandes suivantes pour créer un nouveau groupe de noeuds ou mettre à jour un groupe de noeuds existant, selon le cas :
    • oci ce node-pool create
    • oci ce node-pool update
  3. En plus des paramètres obligatoires requis par la commande que vous utilisez :
    1. Incluez le paramètre --node-image-id, même si vous ne voulez pas spécifier d'image personnalisée.
    2. Incluez le paramètre facultatif --node-metadata dans le format suivant :
      --node-metadata '{"user_data": "'$(cat <cloud-init-file> | base64)'"}'
      où :
      • <cloud-init-file> est le nom du fichier cloud-init que vous avez créé
      • base64 indique que le fichier doit être encodé en base64

      Par exemple :

      --node-metadata '{"user_data": "'$(cat my-custom-cloud-init.yaml | base64)'"}'

Exemple

Cet exemple de commande crée un nouveau groupe de noeuds nommé my-cloud-init-test-nodepool pour une grappe existante, avec un seul noeud Kubernetes 1.18.10 qui a une forme de machine virtuelle 2.1 exécutant Oracle Linux. Lorsque l'instance hébergeant le noeud de travail dans le nouveau groupe de noeuds démarre pour la première fois, un script cloud-init personnalisé nommé my-custom-cloud-init.yaml est exécuté :

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)'"}'