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

Découvrez comment écrire des scripts cloud-init personnalisés à exécuter sur les noeuds de processus actif des clusters créés à l'aide de Kubernetes Engine (OKE).

Cloud-init est la méthode standard du secteur pour l'initialisation des instances cloud, les systèmes de provisionnement pour l'infrastructure de cloud privé et les installations bare metal. Elle est prise en charge par tous les principaux fournisseurs de cloud public, y compris Oracle Cloud Infrastructure (reportez-vous à Données utilisateur). Cloud-init exécute des scripts pour initialiser et configurer des instances. Pour plus d'informations sur cloud-init, reportez-vous à la documentation 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 stratégie SELinux sur tous les hôtes de noeud de processus actif à 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, puis réaffecter l'instance en tant qu'adresse IP publique réservée
configurer un proxy d'entreprise
configurer des proxies 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'un cluster, de la création de pools de noeuds et de la modification de pools de noeuds existants :

à l'aide de la console (lors de la création d'un cluster, utilisez le workflow Création personnalisée)
à l'aide de l'interface de ligne de commande
utilisation de l'API

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

Exemples de cas d'utilisation pour les scripts d'initialisation cloud personnalisés

Exemple 1 : utilisation d'un script cloud-init personnalisé pour configurer SELinux (Linux amélioré en fonction de 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é apportée à Linux qui permet aux administrateurs de limiter l'accès des utilisateurs et des applications aux ressources en fonction des règles d'une stratégie. SELinux ajoute également une granularité plus fine aux contrôles d'accès.

SELinux peut avoir l'un des deux états suivants : activé ou désactivé. Lorsqu'elle est activée, SELinux peut s'exécuter dans l'un des deux modes suivants : application ou permissivité.

Par défaut, SELinux est activé et défini pour être exécuté en mode permissif sur les noeuds de processus actif. Lors de l'exécution en mode permissif, SELinux n'impose pas de règles d'accès et n'effectue que la journalisation.

Si vous voulez que SELinux applique les règles d'accès, vous pouvez définir son exécution en mode de mise en application. Lors de l'exécution en mode de mise en application, SELinux bloque les actions qui sont contraires à la stratégie et consigne un événement correspondant dans le journal d'audit.

Pour définir l'exécution de SELinux en mode de mise en 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 en cours d'exécution sur un noeud de processus actif, connectez-vous au noeud de processus actif et utilisez la commande getenforce. Lorsque le script cloud-init ci-dessus a été exécuté sur les noeuds de processus actif, la commande getenforce renvoie Enforcing.

Exemple 2 : utilisation d'un script cloud-init personnalisé pour définir NodeLocal DNSCache sur des 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 les performances DNS de cluster en exécutant un agent de mise en mémoire cache DNS sur les noeuds de processus actif en tant que jeu de démons.

Si NodeLocal DNSCache n'est pas activé, les pods en mode DNS ClusterFirst atteignent un fichier serviceIP kube-dns pour les requêtes DNS. A l'aide de règles iptables, cette demande est convertie en adresse kube-dns/CoreDNS ajoutée par kube-proxy. Pour plus d'informations, reportez-vous à DNS pour les services et les pods dans la documentation Kubernetes.

Si NodeLocal DNSCache est activé, les pods contactent un agent de mise en cache DNS exécuté sur le même noeud de processus actif, ce qui leur permet d'ignorer les règles DNAT iptables et le suivi de connexion. L'agent de mise en cache local interroge le service kube-dns/CoreDNS à la recherche d'échecs de cache des noms d'hôte de cluster (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'entre pas en collision avec un élément du cluster. Il existe une plage locale de liens recommandée de 169.254.0.0/16 pour IPv4 ou de la plage 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 vérifier que NodeLocal DNSCache a été déployé, connectez-vous à un noeud de processus actif et utilisez la commande sudo systemctl status -l kubelet. Lorsque le script cloud-init ci-dessus a été exécuté sur des noeuds de processus actif, la commande sudo systemctl status -l kubelet renvoie --cluster-dns comme l'un des indicateurs de kubelet, défini sur 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 dans Utilisation de NodeLocal DNSCache dans les clusters Kubernetes dans la documentation Kubernetes. Une fois activé, un pod node-local-dns s'exécute dans l'espace de noms kube-system sur chacun des noeuds de cluster. Le pod node-local-dns exécute CoreDNS en mode cache, de sorte que toutes les mesures CoreDNS affichées par les différents modules d'extension sont disponibles par noeud.

Pour tester la résolution DNS, utilisez une ou plusieurs des commandes suivantes (reportez-vous à Débogage de la résolution DNS dans la documentation Kubernetes). Les commandes doivent fonctionner et également générer 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 daemonset et 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 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. L'une de ces options kubelet-extra-args est l'option permettant de configurer le niveau de détail du journal de débogage.

Pour configurer le niveau de détail du journal de 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 la définition de la verbosité du journal de niveau débogage, connectez-vous à un noeud de processus actif et utilisez la commande sudo systemctl status -l kubelet. Lorsque le script cloud-init ci-dessus a été exécuté sur des noeuds de processus actif, la commande sudo systemctl status -l kubelet renvoie le niveau de détail 4. Les journaux de kubelet contiennent également plus de détails.

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

Vous pouvez utiliser un script cloud-init personnalisé pour réserver des ressources de CPU et de mémoire aux démons système Kubernetes (tels que kubelet et container runtime) et aux démons système de système d'exploitation (tels que sshd et systemd). Afin de réserver des ressources pour les démons système de 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 système de système d'exploitation et 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, reportez-vous à Meilleure pratique : réserver des ressources pour les démons système de système d'exploitation et Kubernetes.

Exemple 5 : utilisation d'un script cloud-init personnalisé et d'oci-growfs pour augmenter la taille de la partition de volume d'initialisation

Vous pouvez utiliser un script cloud-init personnalisé pour étendre la partition du volume d'initialisation des noeuds gérés. Lorsque vous créez et mettez à jour des clusters et des pools de noeuds, vous pouvez indiquer une taille personnalisée pour les volumes d'initialisation de noeud de processus actif. La taille de volume d'initialisation personnalisée que vous spécifiez doit être supérieure à la taille de volume d'initialisation par défaut de l'image que vous sélectionnez. Lorsque vous augmentez la taille du volume d'initialisation, pour bénéficier de la plus grande taille, vous devez également étendre la partition pour le volume d'initialisation.

Les images de plate-forme Oracle Linux incluent le package oci-utils. Vous pouvez utiliser la commande oci-growfs de ce package dans un script cloud-init pour étendre la partition racine, puis développer le système de fichiers.

Pour étendre la partition du volume d'initialisation, 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, reportez-vous à Extension de la partition pour un volume d'initialisation.

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

Pour personnaliser le script de démarrage cloud-init par défaut fourni par Kubernetes Engine, procédez comme suit :

Créez un fichier script contenant la logique par défaut fournie par Kubernetes Engine. Pour ce faire :
- En sélectionnant l'option Télécharger le modèle de script d'initialisation de cloud personnalisé (dans la section Options avancées du pool de noeuds) lorsque vous utilisez la boîte de dialogue Créer un cluster personnalisé, Ajouter un pool de noeuds ou Modifier un pool 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
```
Avant ou après la logique par défaut fournie par Kubernetes Engine, ajoutez votre propre logique personnalisée au fichier script. Ne modifiez pas la logique par défaut.

Par exemple, pour configurer le niveau de verbosité du journal de débogage, vous pouvez ajouter --kubelet-extra-args "--v=4", de sorte que le fichier ressemble à ce qui 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 consulter d'autres exemples, reportez-vous à Exemples de cas d'utilisation de scripts Cloud-init personnalisés.
Enregistrez le fichier de script cloud-init personnalisé que vous avez créé.
Spécifiez le fichier de script cloud-init personnalisé lorsque vous créez un cluster, ajoutez un pool de noeuds ou modifiez un pool de noeuds existant :
- Utilisation de la console
- Utilisation de l'interface de ligne de commande
- Utilisation de l'API

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 un nouveau cluster, un nouveau pool de noeuds ou un pool de noeuds existant, procédez comme suit :

Créez un fichier cloud-init valide, dans l'un des formats (par exemple, cloud-config) et des types de fichier (par exemple, un fichier .yaml) pris en charge par cloud-init. Reportez-vous à Création d'un script cloud-init personnalisé.
Ouvrez le menu de navigation et sélectionnez Services de développeur. Sous Conteneurs et artefacts, sélectionnez Clusters Kubernetes (OKE).
Choisissez un compartiment sur lequel vous êtes autorisé à travailler.
Créez un cluster à l'aide du workflow Création personnalisée, ajoutez un nouveau pool de noeuds à un cluster existant ou modifiez un pool de noeuds existant.
Dans la section Options avancées du pool de noeuds de la boîte de dialogue Créer un cluster personnalisé, Ajouter un pool de noeuds ou Modifier un pool de noeuds (le cas échéant), indiquez les informations suivantes :
- Script d'initialisation : (facultatif) script permettant à cloud-init d'être exécuté sur chaque instance hébergeant des noeuds de processus actif lors du premier démarrage de l'instance. 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 :
  - Choisir un script Cloud-Init : sélectionnez un fichier contenant le script cloud-init ou glissez-déplacez 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 encore écrit de scripts cloud-init pour initialiser les noeuds de processus actif dans les clusters créés par Kubernetes Engine, il peut être utile de cliquer sur 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 obtenir des exemples, reportez-vous à Exemples d'utilisation pour les scripts Cloud-init personnalisés.

Utilisation de l'interface de ligne de commande

Pour obtenir des informations sur l'utilisation de l'interface de ligne de commande, reportez-vous à Interface de ligne de commande (CLI). Afin d'obtenir la liste complète des indicateurs et des options disponibles pour les commandes de l'interface de ligne de commande, reportez-vous à Référence de 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 processus actif dans un nouveau pool de noeuds ou dans un pool de noeuds existant, procédez comme suit :

Créez un fichier cloud-init valide, dans l'un des formats (par exemple, cloud-config) et des types de fichier (par exemple, un fichier .yaml) pris en charge par cloud-init. Reportez-vous à Création d'un script cloud-init personnalisé.
Ouvrez une invite de commande et entrez l'une des commandes suivantes pour créer un pool de noeuds ou mettre à jour un pool de noeuds existant, selon le cas :
- oci ce node-pool create
- oci ce node-pool update
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 indiquer d'image personnalisée.
2. Incluez le paramètre facultatif --node-metadata au 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 pool de noeuds nommé my-cloud-init-test-nodepool pour un cluster existant, avec un seul noeud Kubernetes 1.18.10 doté d'une forme VM 2.1 exécutant Oracle Linux. Lorsque l'instance hébergeant le noeud de processus actif dans le nouveau pool de noeuds démarre pour la première fois, elle exécute un script cloud-init personnalisé appelé 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)'"}'

Documentation Oracle Cloud Infrastructure