Remplacement des volumes d'initialisation des noeuds de processus actif

Si vous avez ajouté un noeud autogéré à un cluster et que vous effectuez ensuite une rotation des informations d'identification du cluster, le remplacement du volume d'initialisation du noeud autogéré nécessite des étapes supplémentaires (en plus de celles décrites dans Remplacement des volumes d'initialisation des noeuds de processus actif). Les étapes supplémentaires sont requises car le certificat d'autorité de certification du cluster est référencé dans le script cloud-init de noeuds autogérés.

Supposons que vous avez déjà effectué la rotation du certificat CA du cluster auquel un noeud autogéré a été ajouté, en suivant les instructions de la section Rotation des informations d'identification de cluster. Si vous souhaitez à présent remplacer le volume d'initialisation du noeud autogéré, vous devez d'abord modifier le script cloud-init du noeud autogéré. Vous devez remplacer le certificat CA précédent du cluster référencé dans le script par le certificat CA actuel du cluster. Suivez les étapes ci-après :

1. Obtenez les détails de l'instance de calcul hébergeant le noeud autogéré en saisissant ce qui suit :

   oci compute instance get --instance-id <instance-ocid>

   Par exemple :

   oci compute instance get --instance-id ocid1.instance.oc1.phx.any______blra

   Des détails sur l'instance de calcul sont renvoyés.

2. Localisez l'OCID du volume d'initialisation (indiqué dans source-details dans la sortie de la commande oci compute instance get) et notez-le en saisissant la commande suivante :

   oci compute instance get --instance-id <instance-ocid> --query 'data."source-details"."boot-volume-id"' --raw-output
   

   Par exemple :

   oci compute instance get --instance-id ocid1.instance.oc1.phx.any______blra --query 'data."source-details"."boot-volume-id"' --raw-output
   

   Exemple de sortie :

   ocid1.bootvolume.oc1.phx.aaaa______g4a

   Vous utiliserez l'OCID de volume d'initialisation ultérieurement.

3. Localisez les valeurs metadata affichées dans la sortie comme suit :

   "metadata": {
   "ssh_authorized_keys": "<key-value>",
   "user_data": "<existing-base64-encoded-init-script>"
   }

   ssh_authorized_keys est présent lorsque l'accès SSH au noeud a été configuré (ce qui est généralement le cas, mais pas toujours).

   Par exemple :

   "metadata": {
   "ssh_authorized_keys": "ssh-rsa AAAA_____ example@acme.com",
   "user_data": "IyEv___1234___PSIK"
   }

   La valeur de user_data est le script cloud-init utilisé à l'origine pour ajouter l'instance de calcul au cluster en tant que noeud autogéré, au format encodé en base64. Le script cloud-init indique l'adresse privée d'API Kubernetes du cluster et le précédent certificat d'autorité de certification encodé en base64 du cluster.
4. Copiez les valeurs ssh_authorized_keys et user_data et enregistrez-les dans un nouveau fichier nommé metadata.json, en saisissant la commande suivante :

   oci compute instance get --instance-id <instance-ocid> --query 'data.metadata' --raw-output > metadata.json

   Exemple de fichier metadata.json :

   {
   "ssh_authorized_keys": "ssh-rsa AAAA_____ user@acme.com",
   "user_data": "IyEv___1234___PSIK"
   }

5. Copiez la valeur de user_data (script cloud-init d'origine encodé en base64) et décodez-la en saisissant la commande suivante :

   echo "<existing-base64-encoded-init-script>" | base64 --decode

   Par exemple :

   echo "IyEv___1234___PSIK" | base64 --decode

   La sortie décodée est le script cloud-init d'origine. Par exemple :

   #!/usr/bin/env bash
   bash /etc/oke/oke-install.sh \
     --apiserver-endpoint "10.0.0.12" \
     --kubelet-ca-cert "LS0txxxx______Cg=="

   La valeur de --kubelet-ca-cert est le certificat CA précédent du cluster, au format encodé en base64.

6. Enregistrez la sortie décodée en tant que fichier texte nommé my-cloud-init-file.
7. Obtenez le certificat CA actuel du cluster (c'est-à-dire le certificat CA du cluster après rotation) en saisissant :

   oci ce cluster create-kubeconfig --cluster-id <cluster-ocid> --region <region-identifier> --file - | grep -oE "LS0t.*"

   Le certificat d'autorité de certification encodé en base64 en cours du cluster est renvoyé sous forme de chaîne alphanumérique longue, en commençant par les caractères LS0t. Par exemple :

   LS0tyyyy______aP==

8. Dans le script cloud-init que vous avez enregistré dans my-cloud-init-file, remplacez la valeur d'origine de --kubelet-ca-cert par le certificat d'autorité de certification encodé en base64 en cours, puis enregistrez le fichier.

   Par exemple :

   #!/usr/bin/env bash
   bash /etc/oke/oke-install.sh \
     --apiserver-endpoint "10.0.0.12" \
     --kubelet-ca-cert "LS0tyyyy______aP=="

9. Base64 encode le script cloud-init mis à jour dans my-cloud-init-file. Par exemple, entrez la commande suivante :

   base64 my-cloud-init-file

   Le script cloud-init mis à jour est encodé en base64 et renvoyé sous la forme d'une longue chaîne alphanumérique. Par exemple :

   IyEv___5678___PSIK

10. Mettez à jour le fichier metadata.json que vous avez créé précédemment, comme suit :

    • Le cas échéant, conservez la valeur de ssh_authorized_keys inchangée.
    • Remplacez la valeur de user_data par la chaîne alphanumérique codée en base64 que vous venez de créer à partir du script cloud-init mis à jour.

    Par exemple :

    {
          "ssh_authorized_keys": "ssh-rsa AAAA_____ user@acme.com",
          "user_data": "IyEv___5678___PSIK"
    }

11. Utilisez l'OCID de volume d'initialisation que vous avez noté précédemment pour obtenir des détails sur le volume d'initialisation existant, en saisissant la commande suivante :

    oci bv boot-volume get --boot-volume-id <boot-volume-ocid> --query 'data.{ "image_id": "image-id", "kms_key_id": "kms-key-id", "boot-volume-size-in-gbs": "boot-volume-size-in-gbs" }' --raw-output

    Par exemple :

    oci bv boot-volume get --boot-volume-id ocid1.bootvolume.oc1.phx.aaaa______g4a --query 'data.{ "image_id": "image-id", "kms_key_id": "kms-key-id", "boot-volume-size-in-gbs": "boot-volume-size-in-gbs" }' --raw-output

    Exemple de sortie :

    {
      "image_id": "ocid1.image.oc1.phx.aaaa____cra",
      "boot-volume-size-in-gbs": 100,
      "kms_key_id": null
    }

12. Utilisez la sortie pour indiquer les mêmes valeurs pour les propriétés source-details de l'instance de calcul dans un nouveau fichier json nommé my-instance-source-details.json, au format suivant :

    {
    "image-id": "<returned-bv-image-ocid>",
    "source-type": "image",
    "boot-volume-size-in-gbs": <returned-bv-size>,
    "kms_key_id": <returned-bv-kms-key-ocid>
    "isPreserveBootVolumeEnabled": true
    }

    Vous n'avez pas besoin d'inclure de propriétés de volume d'initialisation dans le fichier my-instance-source-details.json qui présentent une valeur null dans la sortie de la commande oci bv boot-volume get. Par exemple, si le volume d'initialisation n'est pas chiffré avec une clé gérée par l'utilisateur, la valeur de kms_key_id est affichée sous la forme null.

    Par exemple :

    {
    "image-id": "ocid1.image.oc1.phx.aaaa____cra",
    "source-type": "image",
    "boot-volume-size-in-gbs": 100,
    "isPreserveBootVolumeEnabled": true
    }

    Vous devez fournir une valeur pour image-id afin de mettre à jour les propriétés user_data (en particulier, pour mettre à jour le script cloud-init avec le nouveau certificat d'autorité de certification).

13. Mettez à jour les détails de l'instance de calcul hébergeant le noeud autogéré en saisissant

    oci compute instance update --instance-id ocid1.instance.oc1.phx.any______blra --metadata file://metadata.json --source-details file://my-instance-source-details.json
     

14. Vérifiez que l'instance de calcul hébergeant le noeud autogéré a la valeur mise à jour pour user_data, en saisissant ce qui suit :

    oci compute instance get --instance-id <instance-ocid>

    Par exemple :

    oci compute instance get --instance-id ocid1.instance.oc1.phx.any______blra

    Les détails mis à jour sur l'instance de calcul hébergeant le noeud autogéré sont renvoyés.

    {
      "data": {
        ...
        "metadata": {
          "ssh_authorized_keys": "ssh-rsa AAAA_____ user@acme.com",
          "user_data": "IyEv___5678___PSIK"
        ...

    Une fois la valeur user_data mise à jour vers le fichier cloud-init encodé en base64 contenant le nouveau certificat d'autorité de certification de cluster, vous pouvez désormais remplacer le volume d'initialisation du noeud autogéré.

15. Remplacez le volume d'initialisation du noeud autogéré en saisissant la commande suivante :

    oci ce cluster replace-boot-volume-cluster-node --cluster-id <cluster-ocid> --node-id <instance-ocid> [OPTIONS]

    Par exemple :

    oci ce cluster replace-boot-volume-cluster-node --cluster-id ocid1.cluster.oc1.phx.aaaa______xoq --node-id ocid1.instance.oc1.phx.any______blra --node-eviction-settings "{\"evictionGraceDuration\": \"PT0M\",\"isForceActionAfterGraceDuration\": true}"

    Pour plus d'informations, reportez-vous à Remplacement des volumes d'initialisation des noeuds de processus actif.