Sauvegarde et restauration

Procédure

1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Utilisez le champ Filter by keyword pour trouver le OADP Operator.
3. Sélectionnez le site OADP Operator et cliquez sur Install.
4. Cliquez sur Install pour installer l'opérateur dans le projet openshift-adp.
5. Cliquez sur Operators → Installed Operators pour vérifier l'installation.

Procédure

1. Définir la variable BUCKET:

   $ BUCKET=<your_bucket>

2. Définir la variable REGION:

   $ REGION=<your_region>

3. Créez un seau AWS S3 :

   $ aws s3api create-bucket \
       --bucket $BUCKET \
       --region $REGION \
       --create-bucket-configuration LocationConstraint=$REGION 1

   1

   us-east-1 ne prend pas en charge LocationConstraint. Si votre région est us-east-1, omettez --create-bucket-configuration LocationConstraint=$REGION.

4. Créer un utilisateur IAM :

   aws iam create-user --user-name velero 1

   1

   Si vous souhaitez utiliser Velero pour sauvegarder plusieurs clusters avec plusieurs buckets S3, créez un nom d'utilisateur unique pour chaque cluster.

5. Créer un fichier velero-policy.json:

   $ cat > velero-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}/*"
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket",
                   "s3:GetBucketLocation",
                   "s3:ListBucketMultipartUploads"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}"
               ]
           }
       ]
   }
   EOF

6. Attachez les politiques pour donner à l'utilisateur velero les permissions minimales nécessaires :

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero \
     --policy-document file://velero-policy.json

7. Créer une clé d'accès pour l'utilisateur velero:

   $ aws iam create-access-key --user-name velero

   Exemple de sortie

   {
     "AccessKey": {
           "UserName": "velero",
           "Status": "Active",
           "CreateDate": "2017-07-31T22:24:41.576Z",
           "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
           "AccessKeyId": <AWS_ACCESS_KEY_ID>
     }
   }

8. Créer un fichier credentials-velero:

   $ cat << EOF > ./credentials-velero
   [default]
   aws_access_key_id=<AWS_ACCESS_KEY_ID>
   aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
   EOF

   Vous utilisez le fichier credentials-velero pour créer un objet Secret pour AWS avant d'installer l'application de protection des données.

Procédure

1. Cliquez sur Operators → Installed Operators et sélectionnez l'opérateur OADP.
2. Sous Provided APIs, cliquez sur Create instance dans la boîte DataProtectionApplication.

3. Cliquez sur YAML View et mettez à jour les paramètres du manifeste DataProtectionApplication:

   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
     name: <dpa_sample>
     namespace: openshift-adp
   spec:
     configuration:
       velero:
         defaultPlugins:
           - openshift 1
           - aws
       restic:
         enable: true 2
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - name: default
         velero:
           provider: aws
           default: true
           objectStorage:
             bucket: <bucket_name> 4
             prefix: <prefix> 5
           config:
             region: <region>
             profile: "default"
           credential:
             key: cloud
             name: cloud-credentials 6
     snapshotLocations: 7
       - name: default
         velero:
           provider: aws
           config:
             region: <region> 8
             profile: "default"

   1

   Le plugin openshift est obligatoire.

   2

   Définissez false si vous souhaitez désactiver l'installation de Restic. Restic déploie un ensemble de démons, ce qui signifie que chaque nœud de travailleur a des pods Restic en cours d'exécution. Vous configurez Restic pour les sauvegardes en ajoutant spec.defaultVolumesToRestic: true au CR Backup.

   3

   Spécifie le sélecteur de nœud à fournir à Restic podSpec.

   4

   Spécifiez un bac comme emplacement de stockage des sauvegardes. Si le bac n'est pas un bac dédié aux sauvegardes Velero, vous devez spécifier un préfixe.

   5

   Spécifiez un préfixe pour les sauvegardes Velero, par exemple, velero, si le seau est utilisé à des fins multiples.

   6

   Indiquez le nom de l'objet Secret que vous avez créé. Si vous ne spécifiez pas cette valeur, le nom par défaut, cloud-credentials, est utilisé. Si vous spécifiez un nom personnalisé, celui-ci est utilisé pour l'emplacement de sauvegarde.

   7

   Il n'est pas nécessaire de spécifier un emplacement d'instantané si vous utilisez des instantanés CSI ou Restic pour sauvegarder des PV.

   8

   L'emplacement de l'instantané doit être situé dans la même région que les PV.

4. Cliquez sur Create.

5. Vérifiez l'installation en consultant les ressources de l'OADP :

   $ oc get all -n openshift-adp

   Exemple de sortie

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/restic-9cq4q                                         1/1     Running   0          94s
   pod/restic-m4lts                                         1/1     Running   0          94s
   pod/restic-pv4kr                                         1/1     Running   0          95s
   pod/velero-588db7f655-n842v                              1/1     Running   0          95s
   
   NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
   
   NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/restic   3         3         3       3            3           <none>          96s
   
   NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
   deployment.apps/velero                              1/1     1            1           96s
   
   NAME                                                           DESIRED   CURRENT   READY   AGE
   replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

Procédure

1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Utilisez le champ Filter by keyword pour trouver le OADP Operator.
3. Sélectionnez le site OADP Operator et cliquez sur Install.
4. Cliquez sur Install pour installer l'opérateur dans le projet openshift-adp.
5. Cliquez sur Operators → Installed Operators pour vérifier l'installation.

Procédure

1. Connectez-vous à Azure :

   $ az login

2. Définir la variable AZURE_RESOURCE_GROUP:

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. Créez un groupe de ressources Azure :

   $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 1

   1

   Précisez votre lieu de résidence.

4. Définir la variable AZURE_STORAGE_ACCOUNT_ID:

   $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"

5. Créez un compte de stockage Azure :

   $ az storage account create \
       --name $AZURE_STORAGE_ACCOUNT_ID \
       --resource-group $AZURE_RESOURCE_GROUP \
       --sku Standard_GRS \
       --encryption-services blob \
       --https-only true \
       --kind BlobStorage \
       --access-tier Hot

6. Définir la variable BLOB_CONTAINER:

   $ BLOB_CONTAINER=velero

7. Créez un conteneur de stockage Azure Blob :

   $ az storage container create \
     -n $BLOB_CONTAINER \
     --public-access off \
     --account-name $AZURE_STORAGE_ACCOUNT_ID

8. Obtenir la clé d'accès au compte de stockage :

   $ AZURE_STORAGE_ACCOUNT_ACCESS_KEY=`az storage account keys list \
     --account-name $AZURE_STORAGE_ACCOUNT_ID \
     --query "[?keyName == 'key1'].value" -o tsv`

9. Créez un rôle personnalisé doté des autorisations minimales requises :

   AZURE_ROLE=Velero
   az role definition create --role-definition '{
      "Name": "'$AZURE_ROLE'",
      "Description": "Velero related permissions to perform backups, restores and deletions",
      "Actions": [
          "Microsoft.Compute/disks/read",
          "Microsoft.Compute/disks/write",
          "Microsoft.Compute/disks/endGetAccess/action",
          "Microsoft.Compute/disks/beginGetAccess/action",
          "Microsoft.Compute/snapshots/read",
          "Microsoft.Compute/snapshots/write",
          "Microsoft.Compute/snapshots/delete",
          "Microsoft.Storage/storageAccounts/listkeys/action",
          "Microsoft.Storage/storageAccounts/regeneratekey/action"
      ],
      "AssignableScopes": ["/subscriptions/'$AZURE_SUBSCRIPTION_ID'"]
      }'

10. Créer un fichier credentials-velero:

    $ cat << EOF > ./credentials-velero
    AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
    AZURE_TENANT_ID=${AZURE_TENANT_ID}
    AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
    AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
    AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
    AZURE_STORAGE_ACCOUNT_ACCESS_KEY=${AZURE_STORAGE_ACCOUNT_ACCESS_KEY} 1
    AZURE_CLOUD_NAME=AzurePublicCloud
    EOF

    1

    Obligatoire. Vous ne pouvez pas sauvegarder les images internes si le fichier credentials-velero ne contient que les informations d'identification du principal du service.

    Vous utilisez le fichier credentials-velero pour créer un objet Secret pour Azure avant d'installer l'application de protection des données.

Procédure

1. Cliquez sur Operators → Installed Operators et sélectionnez l'opérateur OADP.
2. Sous Provided APIs, cliquez sur Create instance dans la boîte DataProtectionApplication.

3. Cliquez sur YAML View et mettez à jour les paramètres du manifeste DataProtectionApplication:

   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
     name: <dpa_sample>
     namespace: openshift-adp
   spec:
     configuration:
       velero:
         defaultPlugins:
           - azure
           - openshift 1
       restic:
         enable: true 2
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - velero:
           config:
             resourceGroup: <azure_resource_group> 4
             storageAccount: <azure_storage_account_id> 5
             subscriptionId: <azure_subscription_id> 6
             storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
           credential:
             key: cloud
             name: cloud-credentials-azure  7
           provider: azure
           default: true
           objectStorage:
             bucket: <bucket_name> 8
             prefix: <prefix> 9
     snapshotLocations: 10
       - velero:
           config:
             resourceGroup: <azure_resource_group>
             subscriptionId: <azure_subscription_id>
             incremental: "true"
           name: default
           provider: azure

   1

   Le plugin openshift est obligatoire.

   2

   Définissez false si vous souhaitez désactiver l'installation de Restic. Restic déploie un ensemble de démons, ce qui signifie que chaque nœud de travailleur a des pods Restic en cours d'exécution. Vous configurez Restic pour les sauvegardes en ajoutant spec.defaultVolumesToRestic: true au CR Backup.

   3

   Spécifie le sélecteur de nœud à fournir à Restic podSpec.

   4

   Spécifiez le groupe de ressources Azure.

   5

   Indiquez l'identifiant du compte de stockage Azure.

   6

   Indiquez l'identifiant de l'abonnement Azure.

   7

   Si vous ne spécifiez pas cette valeur, le nom par défaut, cloud-credentials-azure, est utilisé. Si vous spécifiez un nom personnalisé, celui-ci est utilisé pour l'emplacement de la sauvegarde.

   8

   Spécifiez un bac comme emplacement de stockage des sauvegardes. Si le bac n'est pas un bac dédié aux sauvegardes Velero, vous devez spécifier un préfixe.

   9

   Spécifiez un préfixe pour les sauvegardes Velero, par exemple, velero, si le seau est utilisé à des fins multiples.

   10

   Il n'est pas nécessaire de spécifier un emplacement d'instantané si vous utilisez des instantanés CSI ou Restic pour sauvegarder des PV.

4. Cliquez sur Create.

5. Vérifiez l'installation en consultant les ressources de l'OADP :

   $ oc get all -n openshift-adp

   Exemple de sortie

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/restic-9cq4q                                         1/1     Running   0          94s
   pod/restic-m4lts                                         1/1     Running   0          94s
   pod/restic-pv4kr                                         1/1     Running   0          95s
   pod/velero-588db7f655-n842v                              1/1     Running   0          95s
   
   NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
   
   NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/restic   3         3         3       3            3           <none>          96s
   
   NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
   deployment.apps/velero                              1/1     1            1           96s
   
   NAME                                                           DESIRED   CURRENT   READY   AGE
   replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

Procédure

1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Utilisez le champ Filter by keyword pour trouver le OADP Operator.
3. Sélectionnez le site OADP Operator et cliquez sur Install.
4. Cliquez sur Install pour installer l'opérateur dans le projet openshift-adp.
5. Cliquez sur Operators → Installed Operators pour vérifier l'installation.

Procédure

1. Connectez-vous à GCP :

   $ gcloud auth login

2. Définir la variable BUCKET:

   bUCKET=<bucket> 1

   1

   Indiquez le nom de votre seau.

3. Créez le seau de stockage :

   $ gsutil mb gs://$BUCKET/

4. Définissez la variable PROJECT_ID sur votre projet actif :

   $ PROJECT_ID=$(gcloud config get-value project)

5. Créer un compte de service :

   $ gcloud iam service-accounts create velero \
       --display-name "Velero service account"

6. Dressez la liste de vos comptes de service :

   $ gcloud iam service-accounts list

7. Définissez la variable SERVICE_ACCOUNT_EMAIL pour qu'elle corresponde à sa valeur email:

   $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --filter="displayName:Velero service account" \
       --format 'value(email)')

8. Attachez les politiques pour donner à l'utilisateur velero les permissions minimales nécessaires :

   $ ROLE_PERMISSIONS=(
       compute.disks.get
       compute.disks.create
       compute.disks.createSnapshot
       compute.snapshots.get
       compute.snapshots.create
       compute.snapshots.useReadOnly
       compute.snapshots.delete
       compute.zones.get
   )

9. Créez le rôle personnalisé velero.server:

   $ gcloud iam roles create velero.server \
       --project $PROJECT_ID \
       --title "Velero Server" \
       --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

10. Ajouter une politique IAM au projet :

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server

11. Mettre à jour le compte de service IAM :

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

12. Enregistrer les clés du compte de service IAM dans le fichier credentials-velero dans le répertoire actuel :

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    Vous utilisez le fichier credentials-velero pour créer un objet Secret pour GCP avant d'installer l'application de protection des données.

Procédure

1. Cliquez sur Operators → Installed Operators et sélectionnez l'opérateur OADP.
2. Sous Provided APIs, cliquez sur Create instance dans la boîte DataProtectionApplication.

3. Cliquez sur YAML View et mettez à jour les paramètres du manifeste DataProtectionApplication:

   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
     name: <dpa_sample>
     namespace: openshift-adp
   spec:
     configuration:
       velero:
         defaultPlugins:
           - gcp
           - openshift 1
       restic:
         enable: true 2
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - velero:
           provider: gcp
           default: true
           credential:
             key: cloud
             name: cloud-credentials-gcp 4
           objectStorage:
             bucket: <bucket_name> 5
             prefix: <prefix> 6
     snapshotLocations: 7
       - velero:
           provider: gcp
           default: true
           config:
             project: <project>
             snapshotLocation: us-west1 8

   1

   Le plugin openshift est obligatoire.

   2

   Définissez false si vous souhaitez désactiver l'installation de Restic. Restic déploie un ensemble de démons, ce qui signifie que chaque nœud de travailleur a des pods Restic en cours d'exécution. Vous configurez Restic pour les sauvegardes en ajoutant spec.defaultVolumesToRestic: true au CR Backup.

   3

   Spécifie le sélecteur de nœud à fournir à Restic podSpec.

   4

   Si vous ne spécifiez pas cette valeur, le nom par défaut, cloud-credentials-gcp, est utilisé. Si vous spécifiez un nom personnalisé, celui-ci est utilisé pour l'emplacement de la sauvegarde.

   5

   Spécifiez un bac comme emplacement de stockage des sauvegardes. Si le bac n'est pas un bac dédié aux sauvegardes Velero, vous devez spécifier un préfixe.

   6

   Spécifiez un préfixe pour les sauvegardes Velero, par exemple, velero, si le seau est utilisé à des fins multiples.

   7

   Il n'est pas nécessaire de spécifier un emplacement d'instantané si vous utilisez des instantanés CSI ou Restic pour sauvegarder des PV.

   8

   L'emplacement de l'instantané doit être situé dans la même région que les PV.

4. Cliquez sur Create.

5. Vérifiez l'installation en consultant les ressources de l'OADP :

   $ oc get all -n openshift-adp

   Exemple de sortie

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/restic-9cq4q                                         1/1     Running   0          94s
   pod/restic-m4lts                                         1/1     Running   0          94s
   pod/restic-pv4kr                                         1/1     Running   0          95s
   pod/velero-588db7f655-n842v                              1/1     Running   0          95s
   
   NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
   
   NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/restic   3         3         3       3            3           <none>          96s
   
   NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
   deployment.apps/velero                              1/1     1            1           96s
   
   NAME                                                           DESIRED   CURRENT   READY   AGE
   replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

Procédure

1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Utilisez le champ Filter by keyword pour trouver le OADP Operator.
3. Sélectionnez le site OADP Operator et cliquez sur Install.
4. Cliquez sur Install pour installer l'opérateur dans le projet openshift-adp.
5. Cliquez sur Operators → Installed Operators pour vérifier l'installation.

Procédure

1. Obtenez le point de terminaison S3, AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY en exécutant la commandedescribe sur la ressource personnalisée NooBaa.

2. Créer un fichier credentials-velero:

   $ cat << EOF > ./credentials-velero
   [default]
   aws_access_key_id=<AWS_ACCESS_KEY_ID>
   aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
   EOF

   Vous utilisez le fichier credentials-velero pour créer un objet Secret lorsque vous installez l'application de protection des données.

Procédure

1. Cliquez sur Operators → Installed Operators et sélectionnez l'opérateur OADP.
2. Sous Provided APIs, cliquez sur Create instance dans la boîte DataProtectionApplication.

3. Cliquez sur YAML View et mettez à jour les paramètres du manifeste DataProtectionApplication:

   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
     name: <dpa_sample>
     namespace: openshift-adp
   spec:
     configuration:
       velero:
         defaultPlugins:
           - aws
           - openshift 1
       restic:
         enable: true 2
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - velero:
           config:
             profile: "default"
             region: minio
             s3Url: <url> 4
             insecureSkipTLSVerify: "true"
             s3ForcePathStyle: "true"
           provider: aws
           default: true
           credential:
             key: cloud
             name: cloud-credentials 5
           objectStorage:
             bucket: <bucket_name> 6
             prefix: <prefix> 7

   1

   Le plugin openshift est obligatoire.

   2

   Définissez false si vous souhaitez désactiver l'installation de Restic. Restic déploie un ensemble de démons, ce qui signifie que chaque nœud de travailleur a des pods Restic en cours d'exécution. Vous configurez Restic pour les sauvegardes en ajoutant spec.defaultVolumesToRestic: true au CR Backup.

   3

   Spécifie le sélecteur de nœud à fournir à Restic podSpec.

   4

   Spécifiez l'URL du point de terminaison S3.

   5

   Si vous ne spécifiez pas cette valeur, le nom par défaut, cloud-credentials, est utilisé. Si vous spécifiez un nom personnalisé, celui-ci est utilisé pour l'emplacement de la sauvegarde.

   6

   Spécifiez un bac comme emplacement de stockage des sauvegardes. Si le bac n'est pas un bac dédié aux sauvegardes Velero, vous devez spécifier un préfixe.

   7

   Spécifiez un préfixe pour les sauvegardes Velero, par exemple, velero, si le seau est utilisé à des fins multiples.

4. Cliquez sur Create.

5. Vérifiez l'installation en consultant les ressources de l'OADP :

   $ oc get all -n openshift-adp

   Exemple de sortie

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/restic-9cq4q                                         1/1     Running   0          94s
   pod/restic-m4lts                                         1/1     Running   0          94s
   pod/restic-pv4kr                                         1/1     Running   0          95s
   pod/velero-588db7f655-n842v                              1/1     Running   0          95s
   
   NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
   
   NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/restic   3         3         3       3            3           <none>          96s
   
   NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
   deployment.apps/velero                              1/1     1            1           96s
   
   NAME                                                           DESIRED   CURRENT   READY   AGE
   replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

Procédure

1. Dans la console web d'OpenShift Container Platform, cliquez sur Operators → OperatorHub.
2. Utilisez le champ Filter by keyword pour trouver le OADP Operator.
3. Sélectionnez le site OADP Operator et cliquez sur Install.
4. Cliquez sur Install pour installer l'opérateur dans le projet openshift-adp.
5. Cliquez sur Operators → Installed Operators pour vérifier l'installation.

Procédure

1. Cliquez sur Operators → Installed Operators et sélectionnez l'opérateur OADP.
2. Sous Provided APIs, cliquez sur Create instance dans la boîte DataProtectionApplication.
3. Cliquez sur YAML View et mettez à jour les paramètres du manifeste DataProtectionApplication:
4. Cliquez sur Create.

5. Vérifiez l'installation en consultant les ressources de l'OADP :

   $ oc get all -n openshift-adp

   Exemple de sortie

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/restic-9cq4q                                         1/1     Running   0          94s
   pod/restic-m4lts                                         1/1     Running   0          94s
   pod/restic-pv4kr                                         1/1     Running   0          95s
   pod/velero-588db7f655-n842v                              1/1     Running   0          95s
   
   NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
   
   NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/restic   3         3         3       3            3           <none>          96s
   
   NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
   deployment.apps/velero                              1/1     1            1           96s
   
   NAME                                                           DESIRED   CURRENT   READY   AGE
   replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

Procédure

1. Récupérez les CR backupStorageLocations en entrant la commande suivante :

   $ oc get backupStorageLocations -n openshift-adp

   Exemple de sortie

   NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
   openshift-adp   velero-sample-1   Available   11s              31m

2. Créez un CR Backup, comme dans l'exemple suivant :

   apiVersion: velero.io/v1
   kind: Backup
   metadata:
     name: <backup>
     labels:
       velero.io/storage-location: default
     namespace: openshift-adp
   spec:
     hooks: {}
     includedNamespaces:
     - <namespace> 1
     includedResources: [] 2
     excludedResources: [] 3
     storageLocation: <velero-sample-1> 4
     ttl: 720h0m0s
     labelSelector: 5
     - matchLabels:
         app=<label_1>
     - matchLabels:
         app=<label_2>
     - matchLabels:
         app=<label_3>
     orlabelSelectors: 6
     - matchLabels:
         app=<label_1>
     - matchLabels:
         app=<label_2>
     - matchLabels:
         app=<label_3>

   1

   Spécifier un tableau d'espaces de noms à sauvegarder.

   2

   Facultatif : Spécifiez un tableau de ressources à inclure dans la sauvegarde. Les ressources peuvent être des raccourcis (par exemple, "po" pour "pods") ou être entièrement qualifiées. Si rien n'est spécifié, toutes les ressources sont incluses.

   3

   Facultatif : Spécifiez un tableau de ressources à exclure de la sauvegarde. Les ressources peuvent être des raccourcis (par exemple, "po" pour "pods") ou être entièrement qualifiées.

   4

   Indiquez le nom du CR backupStorageLocations.

   5

   Sauvegarde des ressources qui ont toutes les étiquettes spécifiées.

   6

   Sauvegarde des ressources qui ont une ou plusieurs des étiquettes spécifiées.

3. Vérifiez que l'état de la CR Backup est Completed:

   $ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'

Procédure

1. Configurez un secret Restic en créant un fichier .yaml comme suit :

   apiVersion: v1
   kind: Secret
   metadata:
     name: <secret_name>
     namespace: openshift-adp
   type: Opaque
   stringData:
     RESTIC_PASSWORD: <secure_restic_password>

   Note

   Par défaut, l'opérateur recherche un secret nommé dm-credential. Si vous utilisez un nom différent, vous devez le spécifier dans une application de protection des données (DPA) CR à l'aide de dpa.spec.features.dataMover.credentialName.

2. Créez un DPA CR similaire à l'exemple suivant. Les plugins par défaut incluent CSI.

   Exemple de demande de protection des données (DPA) CR

   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
     name: velero-sample
     namespace: openshift-adp
   spec:
     features:
       dataMover:
         enable: true
         credentialName: <secret_name> 1
     backupLocations:
       - velero:
           config:
             profile: default
             region: us-east-1
           credential:
             key: cloud
             name: cloud-credentials
           default: true
           objectStorage:
             bucket: <bucket_name>
             prefix: <bucket_prefix>
           provider: aws
     configuration:
       restic:
         enable: <true_or_false>
       velero:
         defaultPlugins:
           - openshift
           - aws
           - csi

   1

   Ajoutez le nom secret Restic de l'étape précédente. Si cela n'est pas fait, le nom secret par défaut dm-credential est utilisé.

   L'opérateur OADP installe deux définitions de ressources personnalisées (CRD), VolumeSnapshotBackup et VolumeSnapshotRestore.

   Exemple VolumeSnapshotBackup CRD

   apiVersion: datamover.oadp.openshift.io/v1alpha1
   kind: VolumeSnapshotBackup
   metadata:
     name: <vsb_name>
     namespace: <namespace_name> 1
   spec:
     volumeSnapshotContent:
       name: <snapcontent_name>
     protectedNamespace: <adp_namespace>
     resticSecretRef:
       name: <restic_secret_name>

   1

   Spécifiez l'espace de noms dans lequel le cliché instantané du volume existe.

   Exemple VolumeSnapshotRestore CRD

   apiVersion: datamover.oadp.openshift.io/v1alpha1
   kind: VolumeSnapshotRestore
   metadata:
     name: <vsr_name>
     namespace: <namespace_name> 1
   spec:
     protectedNamespace: <protected_ns> 2
     resticSecretRef:
       name: <restic_secret_name>
     volumeSnapshotMoverBackupRef:
       sourcePVCData:
         name: <source_pvc_name>
         size: <source_pvc_size>
       resticrepository: <your_restic_repo>
       volumeSnapshotClassName: <vsclass_name>

   1

   Spécifiez l'espace de noms dans lequel le cliché instantané du volume existe.

   2

   Indiquez l'espace de noms dans lequel l'opérateur est installé. La valeur par défaut est openshift-adp.

3. Vous pouvez sauvegarder un instantané de volume en procédant comme suit :

   1. Créer un CR de sauvegarde :

      apiVersion: velero.io/v1
      kind: Backup
      metadata:
        name: <backup_name>
        namespace: <protected_ns> 1
      spec:
        includedNamespaces:
        - <app_ns>
        storageLocation: velero-sample-1

      1

      Indiquez l'espace de noms dans lequel l'opérateur est installé. L'espace de noms par défaut est openshift-adp.

   2. Attendez jusqu'à 10 minutes et vérifiez si l'état de VolumeSnapshotBackup CR est Completed en entrant les commandes suivantes :

      $ oc get vsb -n <app_ns>

      $ oc get vsb <vsb_name> -n <app_ns> -o jsonpath="{.status.phase}"

      Un instantané est créé dans le magasin d'objets configuré dans le DPA.

      Note

      Si l'état de VolumeSnapshotBackup CR devient Failed, reportez-vous aux registres Velero pour le dépannage.

4. Vous pouvez restaurer un instantané de volume en procédant comme suit :

   1. Supprimez l'espace de noms de l'application et le site volumeSnapshotContent qui a été créé par le plugin Velero CSI.

   2. Créez un CR Restore et définissez restorePVs comme true.

      Exemple Restore CR

      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: <restore_name>
        namespace: <protected_ns>
      spec:
        backupName: <previous_backup_name>
        restorePVs: true

   3. Attendez jusqu'à 10 minutes et vérifiez si l'état de VolumeSnapshotRestore CR est Completed en entrant la commande suivante :

      $ oc get vsr -n <app_ns>

      $ oc get vsr <vsr_name> -n <app_ns> -o jsonpath="{.status.phase}"

   4. Vérifiez si les données et les ressources de votre application ont été restaurées.

      Note

      Si l'état de VolumeSnapshotRestore CR devient "Échec", reportez-vous aux journaux Velero pour le dépannage.

Procédure

1. Récupérer les CR de backupStorageLocations:

   $ oc get backupStorageLocations -n openshift-adp

   Exemple de sortie

   NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
   openshift-adp   velero-sample-1   Available   11s              31m

2. Créez un CR Schedule, comme dans l'exemple suivant :

   $ cat << EOF | oc apply -f -
   apiVersion: velero.io/v1
   kind: Schedule
   metadata:
     name: <schedule>
     namespace: openshift-adp
   spec:
     schedule: 0 7 * * * 1
     template:
       hooks: {}
       includedNamespaces:
       - <namespace> 2
       storageLocation: <velero-sample-1> 3
       defaultVolumesToRestic: true 4
       ttl: 720h0m0s
   EOF

   1

   cron expression to schedule the backup, for example, 0 7 * * * to perform a backup every day at 7:00.

   2

   Tableau des espaces de noms à sauvegarder.

   3

   Nom du CR backupStorageLocations.

   4

   Facultatif : Ajoutez la paire clé-valeur defaultVolumesToRestic: true si vous sauvegardez des volumes avec Restic.

3. Vérifiez que l'état de Schedule CR est Completed après l'exécution de la sauvegarde programmée :

   $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'

Procédure

1. Créez un CR Restore, comme dans l'exemple suivant :

   apiVersion: velero.io/v1
   kind: Restore
   metadata:
     name: <restore>
     namespace: openshift-adp
   spec:
     backupName: <backup> 1
     includedResources: [] 2
     excludedResources:
     - nodes
     - events
     - events.events.k8s.io
     - backups.velero.io
     - restores.velero.io
     - resticrepositories.velero.io
     restorePVs: true

   1

   Nom du CR Backup.

   2

   Facultatif. Spécifiez un tableau de ressources à inclure dans le processus de restauration. Les ressources peuvent être des raccourcis (par exemple, "po" pour "pods") ou être entièrement qualifiées. Si rien n'est spécifié, toutes les ressources sont incluses.

2. Vérifiez que l'état du CR Restore est Completed en entrant la commande suivante :

   $ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'

3. Vérifiez que les ressources de sauvegarde ont été restaurées en entrant la commande suivante :

   $ oc get all -n <namespace> 1

   1

   Namespace que vous avez sauvegardé.

4. Si vous utilisez Restic pour restaurer les objets DeploymentConfig ou si vous utilisez des crochets post-restauration, exécutez le script de nettoyage dc-restic-post-restore.sh en entrant la commande suivante :

   bash dc-restic-post-restore.sh <restore-name>

   Note

   Au cours du processus de restauration, les plug-ins OADP Velero réduisent les objets DeploymentConfig et restaurent les pods en tant que pods autonomes pour éviter que le cluster ne supprime les pods DeploymentConfig restaurés immédiatement après la restauration et pour permettre aux hooks Restic et post-restauration de terminer leurs actions sur les pods restaurés. Le script de nettoyage supprime ces pods déconnectés et met à l'échelle tous les objets DeploymentConfig jusqu'au nombre approprié de répliques.

   Exemple 4.1. dc-restic-post-restore.sh script de nettoyage

   #!/bin/bash
   set -e
   
   # if sha256sum exists, use it to check the integrity of the file
   if command -v sha256sum >/dev/null 2>&1; then
     CHECKSUM_CMD="sha256sum"
   else
     CHECKSUM_CMD="shasum -a 256"
   fi
   
   label_name () {
       if [ "${#1}" -le "63" ]; then
   	echo $1
   	return
       fi
       sha=$(echo -n $1|$CHECKSUM_CMD)
       echo "${1:0:57}${sha:0:6}"
   }
   
   OADP_NAMESPACE=${OADP_NAMESPACE:=openshift-adp}
   
   if [[ $# -ne 1 ]]; then
       echo "usage: ${BASH_SOURCE} restore-name"
       exit 1
   fi
   
   echo using OADP Namespace $OADP_NAMESPACE
   echo restore: $1
   
   label=$(label_name $1)
   echo label: $label
   
   echo Deleting disconnected restore pods
   oc delete pods -l oadp.openshift.io/disconnected-from-dc=$label
   
   for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}')
   do
       IFS=',' read -ra dc_arr <<< "$dc"
       if [ ${#dc_arr[0]} -gt 0 ]; then
   	echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]}
   	cat <<EOF | oc patch dc  -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin
   spec:
     replicas: ${dc_arr[2]}
     paused: ${dc_arr[3]}
   EOF
       fi
   done

Solution

1. Modifiez la valeur de la clé spec.snapshotLocations.velero.config.region dans le manifeste DataProtectionApplication afin que l'emplacement de l'instantané se trouve dans la même région que le PV.
2. Créez un nouveau CR Backup.

Solution

1. Récupérer les détails du CR Backup:

   $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
     backup describe <backup>

2. Supprimer le CR Backup:

   oc delete backup <backup> -n openshift-adp

   Il n'est pas nécessaire de nettoyer l'emplacement de sauvegarde car un CR Backup en cours n'a pas téléchargé de fichiers vers le stockage d'objets.

3. Créez un nouveau CR Backup.

Solution

1. Supprimer le CR Backup:

   oc delete backup <backup> -n openshift-adp

2. Si nécessaire, nettoyez les données stockées sur le site BackupStorageLocation pour libérer de l'espace.

3. Appliquez l'étiquette velero.io/csi-volumesnapshot-class=true à l'objet VolumeSnapshotClass:

   oc label volumesnapshotclass/<snapclass_name> velero.io/csi-volumesnapshot-class=true

4. Créez un nouveau CR Backup.

1. Créez un groupe supplémentaire pour Restic sur le volume de données NFS.
2. Activez le bit setgid sur les répertoires NFS pour que la propriété du groupe soit héritée.

3. Ajoutez le paramètre spec.configuration.restic.supplementalGroups et l'identifiant du groupe au manifeste DataProtectionApplication, comme dans l'exemple suivant :

   spec:
     configuration:
       restic:
         enable: true
         supplementalGroups:
         - <group_id> 1

   1

   Indiquez l'ID du groupe supplémentaire.

4. Attendez que les pods Restic redémarrent pour que les changements soient appliqués.

1. Version préférée du cluster destination
2. Version préférée du cluster source
3. Version commune non préférée prise en charge avec la priorité de version Kubernetes la plus élevée

Procédure

1. Retirer l'élément malsain.

   1. Choisissez un pod qui est not sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Exemple de sortie

      etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

   2. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'est pas sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

   3. Consulter la liste des membres :

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      Notez l'ID et le nom du membre etcd malsain, car ces valeurs seront nécessaires plus tard dans la procédure. La commande $ etcdctl endpoint health listera le membre supprimé jusqu'à ce que la procédure de remplacement soit terminée et qu'un nouveau membre soit ajouté.

   4. Supprimez le membre etcd malsain en fournissant l'ID à la commande etcdctl member remove:

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d

      Exemple de sortie

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346

   5. Consultez à nouveau la liste des membres et vérifiez que le membre a bien été supprimé :

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      Vous pouvez maintenant quitter le shell du nœud.

      Important

      Après avoir supprimé le membre, le cluster peut être inaccessible pendant une courte période, le temps que les instances etcd restantes redémarrent.

2. Désactivez la garde du quorum en entrant la commande suivante :

   $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

   Cette commande permet de s'assurer que vous pouvez recréer les secrets et déployer les pods statiques avec succès.

3. Supprime les anciens secrets du membre etcd malsain qui a été supprimé.

   1. Liste les secrets du membre etcd malsain qui a été supprimé.

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1

      1

      Saisissez le nom du membre etcd malsain dont vous avez pris note plus tôt dans cette procédure.

      Il y a un pair, un serveur et un secret de métrique, comme le montre la sortie suivante :

      Exemple de sortie

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
      etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
      etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

   2. Supprime les secrets du membre etcd malsain qui a été supprimé.

      1. Supprimer le secret de l'homologue :

         $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal

      2. Supprimer le secret de service :

         $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal

      3. Supprimer le secret des métriques :

         $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal

4. Supprimer et recréer la machine du plan de contrôle. Une fois cette machine recréée, une nouvelle révision est forcée et etcd se met automatiquement à l'échelle.

   Si vous utilisez une infrastructure fournie par l'installateur ou si vous avez utilisé l'API Machine pour créer vos machines, suivez ces étapes. Sinon, vous devez créer le nouveau master en utilisant la même méthode que celle utilisée pour le créer à l'origine.

   1. Obtenir la machine pour le membre en mauvaise santé.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
      clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
      clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
      clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
      clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
      clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
      clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      1

      Il s'agit de la machine du plan de contrôle pour le nœud malsain, ip-10-0-131-183.ec2.internal.

   2. Enregistrez la configuration de la machine dans un fichier sur votre système de fichiers :

      $ oc get machine clustername-8qw5l-master-0 \ 1
          -n openshift-machine-api \
          -o yaml \
          > new-master-machine.yaml

      1

      Indiquez le nom de la machine du plan de contrôle pour le nœud malsain.

   3. Modifiez le fichier new-master-machine.yaml créé à l'étape précédente pour lui attribuer un nouveau nom et supprimer les champs inutiles.

      1. Retirer toute la section status:

         status:
           addresses:
           - address: 10.0.131.183
             type: InternalIP
           - address: ip-10-0-131-183.ec2.internal
             type: InternalDNS
           - address: ip-10-0-131-183.ec2.internal
             type: Hostname
           lastUpdated: "2020-04-20T17:44:29Z"
           nodeRef:
             kind: Node
             name: ip-10-0-131-183.ec2.internal
             uid: acca4411-af0d-4387-b73e-52b2484295ad
           phase: Running
           providerStatus:
             apiVersion: awsproviderconfig.openshift.io/v1beta1
             conditions:
             - lastProbeTime: "2020-04-20T16:53:50Z"
               lastTransitionTime: "2020-04-20T16:53:50Z"
               message: machine successfully created
               reason: MachineCreationSucceeded
               status: "True"
               type: MachineCreation
             instanceId: i-0fdb85790d76d0c3f
             instanceState: stopped
             kind: AWSMachineProviderStatus

      2. Changez le nom du champ metadata.name.

         Il est recommandé de conserver le même nom de base que l'ancienne machine et de remplacer le numéro de fin par le prochain numéro disponible. Dans cet exemple, clustername-8qw5l-master-0 est remplacé par clustername-8qw5l-master-3.

         Par exemple :

         apiVersion: machine.openshift.io/v1beta1
         kind: Machine
         metadata:
           ...
           name: clustername-8qw5l-master-3
           ...

      3. Supprimer le champ spec.providerID:

           providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f

   4. Supprimez l'objet BareMetalHost en exécutant la commande suivante, en remplaçant <host_name> par le nom de l'hôte à nu du nœud malsain :

      oc delete bmh -n openshift-machine-api <host_name>

   5. Supprimez la machine du membre malsain en exécutant la commande suivante, en remplaçant <machine_name> par le nom de la machine du plan de contrôle du nœud malsain, par exemple clustername-8qw5l-master-0:

      $ oc delete machine -n openshift-machine-api <nom_de_la_machine>

   6. Vérifiez que la machine a été supprimée :

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
      clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
      clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
      clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
      clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
      clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

   7. Créez la nouvelle machine à l'aide du fichier new-master-machine.yaml:

      $ oc apply -f new-master-machine.yaml

   8. Vérifiez que la nouvelle machine a été créée :

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
      clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
      clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
      clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running 1
      clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
      clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
      clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      1

      La nouvelle machine, clustername-8qw5l-master-3, est en cours de création et sera prête lorsque la phase passera de Provisioning à Running.

      La création de la nouvelle machine peut prendre quelques minutes. L'opérateur du cluster etcd se synchronisera automatiquement lorsque la machine ou le nœud reviendra à un état sain.

5. Réactivez la garde du quorum en entrant la commande suivante :

   $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

6. Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande :

   $ oc get etcd/cluster -oyaml

7. Si vous utilisez OpenShift à nœud unique, redémarrez le nœud. Sinon, vous risquez de rencontrer l'erreur suivante dans l'opérateur de cluster etcd :

   Exemple de sortie

   EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Vérification

1. Vérifiez que tous les pods etcd fonctionnent correctement.

   Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

   $ oc -n openshift-etcd get pods -l k8s-app=etcd

   Exemple de sortie

   etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
   etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
   etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

   Si la sortie de la commande précédente n'indique que deux pods, vous pouvez forcer manuellement un redéploiement d'etcd. Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

   $ oc patch etcd cluster -p='{"spec" : {\i1}"forceRedeploymentReason" : \N-"recovery-'\N"$( date --rfc-3339=ns )'\N'\N"}'' -type=merge} --type=merge 1

   1

   La valeur forceRedeploymentReason doit être unique, c'est pourquoi un horodatage est ajouté.

2. Vérifiez qu'il y a exactement trois membres etcd.

   1. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'était pas sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

   2. Consulter la liste des membres :

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      Si la sortie de la commande précédente répertorie plus de trois membres etcd, vous devez supprimer avec précaution le membre indésirable.

      Avertissement

      Veillez à supprimer le bon membre etcd ; la suppression d'un bon membre etcd peut entraîner une perte de quorum.

Procédure

1. Arrêter le pod etcd de crashlooping.

   1. Déboguer le nœud qui fait du crashlooping.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      oc debug node/ip-10-0-131-183.ec2.internal 1

      1

      Remplacez ce nom par le nom du nœud malsain.

   2. Changez votre répertoire racine en /host:

      sh-4.2# chroot /host

   3. Déplacer le fichier pod etcd existant hors du répertoire kubelet manifest :

      sh-4.2# mkdir /var/lib/etcd-backup

      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/

   4. Déplacez le répertoire de données etcd vers un autre emplacement :

      sh-4.2# mv /var/lib/etcd/ /tmp

      Vous pouvez maintenant quitter le shell du nœud.

2. Retirer l'élément malsain.

   1. Choisissez un pod qui est not sur le nœud affecté.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Exemple de sortie

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

   2. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'est pas sur le nœud affecté.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

   3. Consulter la liste des membres :

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      | b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      Notez l'ID et le nom du membre etcd malsain, car ces valeurs seront nécessaires plus tard dans la procédure.

   4. Supprimez le membre etcd malsain en fournissant l'ID à la commande etcdctl member remove:

      sh-4.2# etcdctl member remove 62bcf33650a7170a

      Exemple de sortie

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346

   5. Consultez à nouveau la liste des membres et vérifiez que le membre a bien été supprimé :

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      Vous pouvez maintenant quitter le shell du nœud.

3. Désactivez la garde du quorum en entrant la commande suivante :

   $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

   Cette commande permet de s'assurer que vous pouvez recréer les secrets et déployer les pods statiques avec succès.

4. Supprime les anciens secrets du membre etcd malsain qui a été supprimé.

   1. Liste les secrets du membre etcd malsain qui a été supprimé.

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1

      1

      Saisissez le nom du membre etcd malsain dont vous avez pris note plus tôt dans cette procédure.

      Il y a un pair, un serveur et un secret de métrique, comme le montre la sortie suivante :

      Exemple de sortie

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
      etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
      etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

   2. Supprime les secrets du membre etcd malsain qui a été supprimé.

      1. Supprimer le secret de l'homologue :

         $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal

      2. Supprimer le secret de service :

         $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal

      3. Supprimer le secret des métriques :

         $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal

5. Forcer le redéploiement de etcd.

   Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

   $ oc patch etcd cluster -p='{"spec" : {\i1}"forceRedeploymentReason" : \N "single-master-recovery-'\N"$( date --rfc-3339=ns )'\N"}'' -type=merge} --type=merge 1

   1

   La valeur forceRedeploymentReason doit être unique, c'est pourquoi un horodatage est ajouté.

   Lorsque l'opérateur de cluster etcd effectue un redéploiement, il s'assure que tous les nœuds du plan de contrôle disposent d'un pod etcd fonctionnel.

6. Réactivez la garde du quorum en entrant la commande suivante :

   $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

7. Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande :

   $ oc get etcd/cluster -oyaml

8. Si vous utilisez OpenShift à nœud unique, redémarrez le nœud. Sinon, vous risquez de rencontrer l'erreur suivante dans l'opérateur de cluster etcd :

   Exemple de sortie

   EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Procédure

1. Vérifiez et supprimez le membre malsain.

   1. Choisissez un pod qui est not sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

      Exemple de sortie

      etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
      etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
      etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>

   2. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'est pas sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0

   3. Consulter la liste des membres :

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      | ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+

      Notez l'ID et le nom du membre etcd malsain, car ces valeurs seront nécessaires plus tard dans la procédure. La commande etcdctl endpoint health listera le membre supprimé jusqu'à ce que la procédure de remplacement soit terminée et que le nouveau membre soit ajouté.

   4. Supprimez le membre etcd malsain en fournissant l'ID à la commande etcdctl member remove:

      Avertissement

      Veillez à supprimer le bon membre etcd ; la suppression d'un bon membre etcd peut entraîner une perte de quorum.

      sh-4.2# etcdctl member remove 7a8197040a5126c8

      Exemple de sortie

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b

   5. Consultez à nouveau la liste des membres et vérifiez que le membre a bien été supprimé :

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      | ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+

      Vous pouvez maintenant quitter le shell du nœud.

      Important

      Après avoir supprimé le membre, le cluster peut être inaccessible pendant une courte période, le temps que les instances etcd restantes redémarrent.

2. Désactivez la garde du quorum en entrant la commande suivante :

   $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

   Cette commande permet de s'assurer que vous pouvez recréer les secrets et déployer les pods statiques avec succès.

3. Supprimez les anciens secrets du membre etcd malsain qui a été supprimé en exécutant les commandes suivantes.

   1. Liste les secrets du membre etcd malsain qui a été supprimé.

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2

      Saisissez le nom du membre etcd malsain dont vous avez pris note plus tôt dans cette procédure.

      Il y a un pair, un serveur et un secret de métrique, comme le montre la sortie suivante :

      etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
      etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
      etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m

   2. Supprime les secrets du membre etcd malsain qui a été supprimé.

      1. Supprimer le secret de l'homologue :

         $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd
         
         secret "etcd-peer-openshift-control-plane-2" deleted

      2. Supprimer le secret de service :

         $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd
         
         secret "etcd-serving-metrics-openshift-control-plane-2" deleted

      3. Supprimer le secret des métriques :

         $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd
         
         secret "etcd-serving-openshift-control-plane-2" deleted

4. Supprimer la machine du plan de contrôle.

   Si vous exécutez une infrastructure fournie par l'installateur ou si vous avez utilisé l'API Machine pour créer vos machines, suivez ces étapes. Sinon, vous devez créer le nouveau nœud de plan de contrôle en utilisant la même méthode que celle utilisée pour le créer à l'origine.

   1. Obtenir la machine pour le membre en mauvaise santé.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
      examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 1
      examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
      examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
      examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
      examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

      1

      Il s'agit de la machine du plan de contrôle pour le nœud malsain, examplecluster-control-plane-2.

   2. Enregistrez la configuration de la machine dans un fichier sur votre système de fichiers :

      $ oc get machine examplecluster-control-plane-2 \ 1
          -n openshift-machine-api \
          -o yaml \
          > new-master-machine.yaml

      1

      Indiquez le nom de la machine du plan de contrôle pour le nœud malsain.

   3. Modifiez le fichier new-master-machine.yaml créé à l'étape précédente pour lui attribuer un nouveau nom et supprimer les champs inutiles.

      1. Retirer toute la section status:

         status:
           addresses:
           - address: ""
             type: InternalIP
           - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.373
             type: InternalDNS
           - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.371
             type: Hostname
           lastUpdated: "2020-04-20T17:44:29Z"
           nodeRef:
             kind: Machine
             name: fe80::4adf:37ff:feb0:8aa1%ens1f1.372
             uid: acca4411-af0d-4387-b73e-52b2484295ad
           phase: Running
           providerStatus:
             apiVersion: machine.openshift.io/v1beta1
             conditions:
             - lastProbeTime: "2020-04-20T16:53:50Z"
               lastTransitionTime: "2020-04-20T16:53:50Z"
               message: machine successfully created
               reason: MachineCreationSucceeded
               status: "True"
               type: MachineCreation
             instanceId: i-0fdb85790d76d0c3f
             instanceState: stopped
             kind: Machine

5. Changez le nom du champ metadata.name.

   Il est recommandé de conserver le même nom de base que l'ancienne machine et de remplacer le numéro de fin par le prochain numéro disponible. Dans cet exemple, examplecluster-control-plane-2 est remplacé par examplecluster-control-plane-3.

   Par exemple :

   apiVersion: machine.openshift.io/v1beta1
   kind: Machine
   metadata:
     ...
     name: examplecluster-control-plane-3
     ...

   1. Supprimer le champ spec.providerID:

        providerID: baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135

   2. Supprimer les champs metadata.annotations et metadata.generation:

        annotations:
          machine.openshift.io/instance-state: externally provisioned
        ...
        generation: 2

   3. Supprimer les champs spec.conditions, spec.lastUpdated, spec.nodeRef et spec.phase:

        lastTransitionTime: "2022-08-03T08:40:36Z"
      message: 'Drain operation currently blocked by: [{Name:EtcdQuorumOperator Owner:clusteroperator/etcd}]'
      reason: HookPresent
      severity: Warning
      status: "False"
      
      type: Drainable
      lastTransitionTime: "2022-08-03T08:39:55Z"
      status: "True"
      type: InstanceExists
      
      lastTransitionTime: "2022-08-03T08:36:37Z"
      status: "True"
      type: Terminable
      lastUpdated: "2022-08-03T08:40:36Z"
      nodeRef:
      kind: Node
      name: openshift-control-plane-2
      uid: 788df282-6507-4ea2-9a43-24f237ccbc3c
      phase: Running

6. Assurez-vous que l'opérateur Bare Metal est disponible en exécutant la commande suivante :

   $ oc get clusteroperator baremetal

   Exemple de sortie

   NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
   baremetal   4.12.0    True        False         False      3d15h

7. Supprimez l'ancien objet BareMetalHost en exécutant la commande suivante :

   $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api

   Exemple de sortie

   baremetalhost.metal3.io "openshift-control-plane-2" deleted

8. Supprimez la machine du membre malsain en exécutant la commande suivante :

   $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2

   Après avoir supprimé les objets BareMetalHost et Machine, le contrôleur Machine supprime automatiquement l'objet Node.

   Si la suppression de la machine est retardée pour une raison quelconque ou si la commande est entravée et retardée, vous pouvez forcer la suppression en supprimant le champ finalizer de l'objet machine.

   Important

   N'interrompez pas l'effacement de la machine en appuyant sur Ctrl c. Vous devez laisser la commande se dérouler jusqu'à son terme. Ouvrez une nouvelle fenêtre de terminal pour éditer et supprimer les champs du finalisateur.

   1. Modifiez la configuration de la machine en exécutant la commande suivante :

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2

   2. Supprimez les champs suivants dans la ressource personnalisée Machine, puis enregistrez le fichier mis à jour :

      finalizers:
      - machine.machine.openshift.io

      Exemple de sortie

      machine.machine.openshift.io/examplecluster-control-plane-2 edited

9. Vérifiez que la machine a été supprimée en exécutant la commande suivante :

   $ oc get machines -n openshift-machine-api -o wide

   Exemple de sortie

   NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
   examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
   examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
   examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
   examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

10. Vérifiez que le nœud a été supprimé en exécutant la commande suivante :

    $ oc get nodes
    
    NAME                     STATUS ROLES   AGE   VERSION
    openshift-control-plane-0 Ready master 3h24m v1.25.0
    openshift-control-plane-1 Ready master 3h24m v1.25.0
    openshift-compute-0       Ready worker 176m v1.25.0
    openshift-compute-1       Ready worker 176m v1.25.0

11. Créez le nouvel objet BareMetalHost et le secret pour stocker les informations d'identification BMC :

    $ cat <<EOF | oc apply -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: openshift-control-plane-2-bmc-secret
      namespace: openshift-machine-api
    data:
      password: <password>
      username: <username>
    type: Opaque
    ---
    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: openshift-control-plane-2
      namespace: openshift-machine-api
    spec:
      automatedCleaningMode: disabled
      bmc:
        address: redfish://10.46.61.18:443/redfish/v1/Systems/1
        credentialsName: openshift-control-plane-2-bmc-secret
        disableCertificateVerification: true
      bootMACAddress: 48:df:37:b0:8a:a0
      bootMode: UEFI
      externallyProvisioned: false
      online: true
      rootDeviceHints:
        deviceName: /dev/sda
      userData:
        name: master-user-data-managed
        namespace: openshift-machine-api
    EOF

    Note

    Le nom d'utilisateur et le mot de passe peuvent être trouvés dans les secrets de l'autre hôte bare metal. Le protocole à utiliser dans bmc:address peut être obtenu à partir d'autres objets bmh.

    Important

    Si vous réutilisez la définition de l'objet BareMetalHost à partir d'un hôte de plan de contrôle existant, ne laissez pas le champ externallyProvisioned sur true.

    Les objets du plan de contrôle BareMetalHost existants peuvent avoir l'indicateur externallyProvisioned défini sur true s'ils ont été provisionnés par le programme d'installation d'OpenShift Container Platform.

    Une fois l'inspection terminée, l'objet BareMetalHost est créé et disponible pour être approvisionné.

12. Vérifier le processus de création à l'aide des objets disponibles sur BareMetalHost:

    $ oc get bmh -n openshift-machine-api
    
    NAME                      STATE                  CONSUMER                      ONLINE ERROR   AGE
    openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
    openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
    openshift-control-plane-2 available              examplecluster-control-plane-3 true         47m
    openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
    openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

    1. Créez la nouvelle machine du plan de contrôle à l'aide du fichier new-master-machine.yaml:

       $ oc apply -f new-master-machine.yaml

    2. Vérifiez que la nouvelle machine a été créée :

       $ oc get machines -n openshift-machine-api -o wide

       Exemple de sortie

       NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
       examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 1
       examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
       examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
       examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
       examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

       1

       La nouvelle machine, clustername-8qw5l-master-3, est en cours de création et sera prête après le changement de phase de Provisioning à Running.

       La création de la nouvelle machine devrait prendre quelques minutes. L'opérateur du cluster etcd se synchronisera automatiquement lorsque la machine ou le nœud reviendra à un état sain.

    3. Vérifiez que l'hôte bare metal est provisionné et qu'aucune erreur n'est signalée en exécutant la commande suivante :

       $ oc get bmh -n openshift-machine-api

       Exemple de sortie

       $ oc get bmh -n openshift-machine-api
       NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
       openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
       openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
       openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
       openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
       openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

    4. Vérifiez que le nouveau nœud est ajouté et prêt à fonctionner en exécutant la commande suivante :

       $ oc get nodes

       Exemple de sortie

       $ oc get nodes
       NAME                     STATUS ROLES   AGE   VERSION
       openshift-control-plane-0 Ready master 4h26m v1.25.0
       openshift-control-plane-1 Ready master 4h26m v1.25.0
       openshift-control-plane-2 Ready master 12m   v1.25.0
       openshift-compute-0       Ready worker 3h58m v1.25.0
       openshift-compute-1       Ready worker 3h58m v1.25.0

13. Réactivez la garde du quorum en entrant la commande suivante :

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

14. Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande :

    $ oc get etcd/cluster -oyaml

15. Si vous utilisez OpenShift à nœud unique, redémarrez le nœud. Sinon, vous risquez de rencontrer l'erreur suivante dans l'opérateur de cluster etcd :

    Exemple de sortie

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Vérification

1. Vérifiez que tous les pods etcd fonctionnent correctement.

   Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

   $ oc -n openshift-etcd get pods -l k8s-app=etcd

   Exemple de sortie

   etcd-openshift-control-plane-0      5/5     Running     0     105m
   etcd-openshift-control-plane-1      5/5     Running     0     107m
   etcd-openshift-control-plane-2      5/5     Running     0     103m

   Si la sortie de la commande précédente n'indique que deux pods, vous pouvez forcer manuellement un redéploiement d'etcd. Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

   $ oc patch etcd cluster -p='{"spec" : {\i1}"forceRedeploymentReason" : \N-"recovery-'\N"$( date --rfc-3339=ns )'\N'\N"}'' -type=merge} --type=merge 1

   1

   La valeur forceRedeploymentReason doit être unique, c'est pourquoi un horodatage est ajouté.

   Pour vérifier qu'il y a exactement trois membres etcd, connectez-vous au conteneur etcd en cours d'exécution, en indiquant le nom d'un pod qui n'était pas sur le nœud affecté. Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

   $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0

2. Consulter la liste des membres :

   sh-4.2# etcdctl member list -w table

   Exemple de sortie

   +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
   |        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
   +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
   | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
   | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
   | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
   +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+

   Note

   Si la sortie de la commande précédente répertorie plus de trois membres etcd, vous devez supprimer avec précaution le membre indésirable.

3. Vérifiez que tous les membres d'etcd sont sains en exécutant la commande suivante :

   # etcdctl endpoint health --cluster

   Exemple de sortie

   https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
   https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
   https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms

4. Validez que tous les nœuds sont à la dernière révision en exécutant la commande suivante :

   $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

   AllNodesAtLatestRevision

Procédure

1. Sélectionnez un hôte du plan de contrôle à utiliser comme hôte de restauration. Il s'agit de l'hôte sur lequel vous exécuterez l'opération de restauration.

2. Établir une connectivité SSH avec chacun des nœuds du plan de contrôle, y compris l'hôte de reprise.

   Le serveur API Kubernetes devient inaccessible après le démarrage du processus de restauration, de sorte que vous ne pouvez pas accéder aux nœuds du plan de contrôle. Pour cette raison, il est recommandé d'établir une connectivité SSH à chaque hôte du plan de contrôle dans un terminal séparé.

   Important

   Si vous n'effectuez pas cette étape, vous ne pourrez pas accéder aux hôtes du plan de contrôle pour terminer la procédure de restauration, et vous ne pourrez pas récupérer votre cluster à partir de cet état.

3. Copiez le répertoire de sauvegarde etcd sur l'hôte du plan de contrôle de reprise.

   Cette procédure suppose que vous avez copié le répertoire backup contenant le snapshot etcd et les ressources pour les pods statiques dans le répertoire /home/core/ de votre hôte de plan de contrôle de récupération.

4. Arrêtez les pods statiques sur tous les autres nœuds du plan de contrôle.

   Note

   Il n'est pas nécessaire d'arrêter manuellement les pods sur l'hôte de récupération. Le script de récupération arrêtera les pods sur l'hôte de récupération.

   1. Accéder à un hôte du plan de contrôle qui n'est pas l'hôte de reprise.

   2. Déplacer le fichier pod etcd existant hors du répertoire kubelet manifest :

      $ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp

   3. Vérifiez que les pods etcd sont arrêtés.

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      La sortie de cette commande doit être vide. Si ce n'est pas le cas, attendez quelques minutes et vérifiez à nouveau.

   4. Déplacez le fichier pod du serveur API Kubernetes existant hors du répertoire kubelet manifest :

      $ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

   5. Vérifiez que les pods du serveur API Kubernetes sont arrêtés.

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

      La sortie de cette commande doit être vide. Si ce n'est pas le cas, attendez quelques minutes et vérifiez à nouveau.

   6. Déplacez le répertoire de données etcd vers un autre emplacement :

      $ sudo mv /var/lib/etcd/ /tmp

   7. Répétez cette étape sur chacun des autres hôtes du plan de contrôle qui n'est pas l'hôte de reprise.
5. Accéder à l'hôte du plan de contrôle de récupération.

6. Si le proxy à l'échelle du cluster est activé, assurez-vous que vous avez exporté les variables d'environnement NO_PROXY, HTTP_PROXY, et HTTPS_PROXY.

   Astuce

   Vous pouvez vérifier si le proxy est activé en examinant la sortie de oc get proxy cluster -o yaml. Le proxy est activé si les champs httpProxy, httpsProxy et noProxy ont des valeurs définies.

7. Exécutez le script de restauration sur l'hôte du plan de contrôle de récupération et indiquez le chemin d'accès au répertoire de sauvegarde etcd :

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

   Exemple de sortie de script

   ...stopping kube-scheduler-pod.yaml
   ...stopping kube-controller-manager-pod.yaml
   ...stopping etcd-pod.yaml
   ...stopping kube-apiserver-pod.yaml
   Waiting for container etcd to stop
   .complete
   Waiting for container etcdctl to stop
   .............................complete
   Waiting for container etcd-metrics to stop
   complete
   Waiting for container kube-controller-manager to stop
   complete
   Waiting for container kube-apiserver to stop
   ..........................................................................................complete
   Waiting for container kube-scheduler to stop
   complete
   Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
   starting restore-etcd static pod
   starting kube-apiserver-pod.yaml
   static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
   starting kube-controller-manager-pod.yaml
   static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
   starting kube-scheduler-pod.yaml
   static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

   Note

   Le processus de restauration peut entraîner l'entrée des nœuds dans l'état NotReady si les certificats des nœuds ont été mis à jour après la dernière sauvegarde etcd.

8. Vérifiez que les nœuds sont dans l'état Ready.

   1. Exécutez la commande suivante :

      $ oc get nodes -w

      Exemple de sortie

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.25.0
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.25.0
      host-172-25-75-40   Ready   master         3d20h   v1.25.0
      host-172-25-75-65   Ready   master         3d20h   v1.25.0
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.25.0
      host-172-25-75-79   Ready   worker         3d20h   v1.25.0
      host-172-25-75-86   Ready   worker         3d20h   v1.25.0
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.25.0

      Il peut s'écouler plusieurs minutes avant que tous les nœuds ne communiquent leur état.

   2. Si des nœuds sont dans l'état NotReady, connectez-vous aux nœuds et supprimez tous les fichiers PEM du répertoire /var/lib/kubelet/pki sur chaque nœud. Vous pouvez vous connecter aux nœuds par SSH ou utiliser la fenêtre de terminal de la console web.

      $  ssh -i <ssh-key-path> core@<master-hostname>

      Exemple de répertoire pki

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

9. Redémarrer le service kubelet sur tous les hôtes du plan de contrôle.

   1. À partir de l'hôte de récupération, exécutez la commande suivante :

      $ sudo systemctl restart kubelet.service

   2. Répétez cette étape sur tous les autres hôtes du plan de contrôle.

10. Approuver les RSC en attente :

    1. Obtenir la liste des CSR actuels :

       $ oc get csr

       Exemple de sortie

       NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
       csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
       csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
       csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
       csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
       ...

       1 2

       Un CSR de service kubelet en attente (pour les installations fournies par l'utilisateur).

       3 4

       Un CSR node-bootstrapper en attente.

    2. Examinez les détails d'un CSR pour vérifier qu'il est valide :

       oc describe csr <csr_name> 1

       1

       <csr_name> est le nom d'un CSR figurant dans la liste des CSR actuels.

    3. Approuver chaque CSR node-bootstrapper valide :

       $ oc adm certificate approve <csr_name>

    4. Pour les installations fournies par l'utilisateur, approuver chaque CSR de service kubelet valide :

       $ oc adm certificate approve <csr_name>

11. Vérifiez que le plan de contrôle à membre unique a bien démarré.

    1. Depuis l'hôte de récupération, vérifiez que le conteneur etcd est en cours d'exécution.

       $ sudo crictl ps | grep etcd | grep -v operator

       Exemple de sortie

       3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. Depuis l'hôte de récupération, vérifiez que le pod etcd est en cours d'exécution.

       $ oc -n openshift-etcd get pods -l k8s-app=etcd

       Note

       Si vous essayez d'exécuter oc login avant d'exécuter cette commande et que vous recevez l'erreur suivante, attendez quelques instants pour que les contrôleurs d'authentification démarrent et réessayez.

       Unable to connect to the server: EOF

       Exemple de sortie

       NAME                                             READY   STATUS      RESTARTS   AGE
       etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

       Si l'état est Pending, ou si la sortie indique plus d'un pod etcd en cours d'exécution, attendez quelques minutes et vérifiez à nouveau.

    Note

    N'effectuez l'étape suivante que si vous utilisez le plugin réseau OVNKubernetes.

12. Supprimer les objets nœuds associés aux hôtes du plan de contrôle qui ne sont pas l'hôte du plan de contrôle de reprise.

    oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>

13. Vérifier que le Cluster Network Operator (CNO) redéploie le plan de contrôle OVN-Kubernetes et qu'il ne référence plus les mauvaises adresses IP des contrôleurs. Pour vérifier ce résultat, vérifiez régulièrement la sortie de la commande suivante. Attendez qu'elle renvoie un résultat vide avant de passer à l'étape suivante.

    $ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<wrong_master_ip_1>|<wrong_master_ip_2>'

    Note

    Cela peut prendre au moins 5 à 10 minutes pour que le plan de contrôle OVN-Kubernetes soit redéployé et que la commande précédente renvoie une sortie vide.

14. Désactivez la garde du quorum en entrant la commande suivante :

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    Cette commande permet de s'assurer que vous pouvez recréer les secrets et déployer les pods statiques avec succès.

15. Redémarrez les pods Kubernetes d'Open Virtual Network (OVN) sur tous les hôtes.

    Note

    Les webhooks de validation et de mutation des admissions peuvent rejeter les pods. Si vous ajoutez d'autres webhooks dont l'adresse failurePolicy est Fail, ils peuvent rejeter des pods et le processus de restauration peut échouer. Vous pouvez éviter cela en sauvegardant et en supprimant les webhooks lors de la restauration de l'état de la grappe. Une fois l'état du cluster restauré avec succès, vous pouvez réactiver les webhooks.

    Vous pouvez également définir temporairement failurePolicy sur Ignore pendant la restauration de l'état de la grappe. Une fois l'état de la grappe restauré avec succès, vous pouvez définir failurePolicy sur Fail.

    1. Supprimez la base de données en direction du nord (nbdb) et la base de données en direction du sud (sbdb). Accédez à l'hôte de reprise et aux nœuds de plan de contrôle restants à l'aide de Secure Shell (SSH) et exécutez la commande suivante :

       $ sudo rm -f /var/lib/ovn/etc/*.db

    2. Supprimez tous les pods du plan de contrôle OVN-Kubernetes en exécutant la commande suivante :

       $ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes

    3. Assurez-vous que tous les pods du plan de contrôle OVN-Kubernetes sont à nouveau déployés et sont dans un état Running en exécutant la commande suivante :

       $ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes

       Exemple de sortie

       NAME                   READY   STATUS    RESTARTS   AGE
       ovnkube-master-nb24h   4/4     Running   0          48s
       ovnkube-master-rm8kw   4/4     Running   0          47s
       ovnkube-master-zbqnh   4/4     Running   0          56s

    4. Supprimez tous les pods ovnkube-node en exécutant la commande suivante :

       $ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done

    5. Assurez-vous que tous les pods ovnkube-node sont à nouveau déployés et sont dans un état Running en exécutant la commande suivante :

       $ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node

16. Supprimer et recréer les autres machines du plan de contrôle qui ne sont pas des machines de récupération, une par une. Une fois les machines recréées, une nouvelle révision est forcée et etcd passe automatiquement à l'échelle supérieure.

    • Si vous utilisez une installation bare metal fournie par l'utilisateur, vous pouvez recréer une machine de plan de contrôle en utilisant la même méthode que celle utilisée pour la créer à l'origine. Pour plus d'informations, voir "Installation d'un cluster fourni par l'utilisateur sur bare metal".

      Avertissement

      Ne supprimez pas et ne recréez pas la machine pour l'hôte de récupération.

    • Si vous utilisez une infrastructure fournie par l'installateur ou si vous avez utilisé l'API Machine pour créer vos machines, procédez comme suit :

      Avertissement

      Ne supprimez pas et ne recréez pas la machine pour l'hôte de récupération.

      Pour les installations bare metal sur une infrastructure fournie par l'installateur, les machines du plan de contrôle ne sont pas recréées. Pour plus d'informations, voir "Remplacement d'un nœud de plan de contrôle bare-metal".

      1. Obtenir la machine de l'un des hôtes du plan de contrôle perdus.

         Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

         $ oc get machines -n openshift-machine-api -o wide

         Exemple de sortie :

         NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
         clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         Il s'agit de la machine du plan de contrôle de l'hôte du plan de contrôle perdu, ip-10-0-131-183.ec2.internal.

      2. Enregistrez la configuration de la machine dans un fichier sur votre système de fichiers :

         $ oc get machine clustername-8qw5l-master-0 \ 1
             -n openshift-machine-api \
             -o yaml \
             > new-master-machine.yaml

         1

         Indiquez le nom de la machine du plan de contrôle pour l'hôte du plan de contrôle perdu.

      3. Modifiez le fichier new-master-machine.yaml créé à l'étape précédente pour lui attribuer un nouveau nom et supprimer les champs inutiles.

         1. Retirer toute la section status:

            status:
              addresses:
              - address: 10.0.131.183
                type: InternalIP
              - address: ip-10-0-131-183.ec2.internal
                type: InternalDNS
              - address: ip-10-0-131-183.ec2.internal
                type: Hostname
              lastUpdated: "2020-04-20T17:44:29Z"
              nodeRef:
                kind: Node
                name: ip-10-0-131-183.ec2.internal
                uid: acca4411-af0d-4387-b73e-52b2484295ad
              phase: Running
              providerStatus:
                apiVersion: awsproviderconfig.openshift.io/v1beta1
                conditions:
                - lastProbeTime: "2020-04-20T16:53:50Z"
                  lastTransitionTime: "2020-04-20T16:53:50Z"
                  message: machine successfully created
                  reason: MachineCreationSucceeded
                  status: "True"
                  type: MachineCreation
                instanceId: i-0fdb85790d76d0c3f
                instanceState: stopped
                kind: AWSMachineProviderStatus

         2. Changez le nom du champ metadata.name.

            Il est recommandé de conserver le même nom de base que l'ancienne machine et de remplacer le numéro de fin par le prochain numéro disponible. Dans cet exemple, clustername-8qw5l-master-0 est remplacé par clustername-8qw5l-master-3:

            apiVersion: machine.openshift.io/v1beta1
            kind: Machine
            metadata:
              ...
              name: clustername-8qw5l-master-3
              ...

         3. Supprimer le champ spec.providerID:

            providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f

         4. Supprimer les champs metadata.annotations et metadata.generation:

            annotations:
              machine.openshift.io/instance-state: running
            ...
            generation: 2

         5. Supprimer les champs metadata.resourceVersion et metadata.uid:

            resourceVersion: "13291"
            uid: a282eb70-40a2-4e89-8009-d05dd420d31a

      4. Supprimer la machine de l'hôte du plan de contrôle perdu :

         oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1

         1

         Indiquez le nom de la machine du plan de contrôle pour l'hôte du plan de contrôle perdu.

      5. Vérifiez que la machine a été supprimée :

         $ oc get machines -n openshift-machine-api -o wide

         Exemple de sortie :

         NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal   aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      6. Créez une machine en utilisant le fichier new-master-machine.yaml:

         $ oc apply -f new-master-machine.yaml

      7. Vérifiez que la nouvelle machine a été créée :

         $ oc get machines -n openshift-machine-api -o wide

         Exemple de sortie :

         NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         La nouvelle machine, clustername-8qw5l-master-3, est en cours de création et sera prête après le changement de phase de Provisioning à Running.

         La création de la nouvelle machine peut prendre quelques minutes. L'opérateur du cluster etcd se synchronisera automatiquement lorsque la machine ou le nœud reviendra à un état sain.

      8. Répétez ces étapes pour chaque hôte du plan de contrôle perdu qui n'est pas l'hôte de récupération.

17. Dans une fenêtre de terminal séparée, connectez-vous au cluster en tant qu'utilisateur ayant le rôle cluster-admin en entrant la commande suivante :

    $ oc login -u <cluster_admin> 1

    1

    Pour <cluster_admin>, indiquez un nom d'utilisateur avec le rôle cluster-admin.

18. Forcer le redéploiement de etcd.

    Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

    $ oc patch etcd cluster -p='{"spec" : {\i1}"forceRedeploymentReason" : \N-"recovery-'\N"$( date --rfc-3339=ns )'\N'\N"}'' -type=merge} --type=merge 1

    1

    La valeur forceRedeploymentReason doit être unique, c'est pourquoi un horodatage est ajouté.

    Lorsque l'opérateur du cluster etcd effectue un redéploiement, les nœuds existants sont démarrés avec de nouveaux pods, comme lors de la mise à l'échelle initiale.

19. Réactivez la garde du quorum en entrant la commande suivante :

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

20. Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande :

    $ oc get etcd/cluster -oyaml

21. Vérifier que tous les nœuds sont mis à jour avec la dernière révision.

    Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    Examinez la condition d'état NodeInstallerProgressing pour etcd afin de vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1

    1

    Dans cet exemple, le dernier numéro de révision est 7.

    Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.

22. Une fois etcd redéployé, forcez de nouveaux déploiements pour le plan de contrôle. Le serveur API Kubernetes se réinstallera sur les autres nœuds car le kubelet est connecté aux serveurs API à l'aide d'un équilibreur de charge interne.

    Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez les commandes suivantes.

    1. Forcer un nouveau déploiement pour le serveur API Kubernetes :

       $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       Vérifier que tous les nœuds sont mis à jour avec la dernière révision.

       $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       Examinez l'état de NodeInstallerProgressing pour vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       Dans cet exemple, le dernier numéro de révision est 7.

       Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.

    2. Forcer un nouveau déploiement pour le gestionnaire de contrôleur Kubernetes :

       $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       Vérifier que tous les nœuds sont mis à jour avec la dernière révision.

       $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       Examinez l'état de NodeInstallerProgressing pour vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       Dans cet exemple, le dernier numéro de révision est 7.

       Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.

    3. Forcer un nouveau déploiement pour le planificateur Kubernetes :

       $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       Vérifier que tous les nœuds sont mis à jour avec la dernière révision.

       $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       Examinez l'état de NodeInstallerProgressing pour vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       Dans cet exemple, le dernier numéro de révision est 7.

       Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.

23. Vérifiez que tous les hôtes du plan de contrôle ont démarré et rejoint le cluster.

    Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    Exemple de sortie

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

Procédure

1. Obtenir la liste des CSR actuels :

   $ oc get csr

   Exemple de sortie

   NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
   csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
   csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
   csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
   csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
   ...

   1 2

   Un CSR de service kubelet en attente (pour les installations fournies par l'utilisateur).

   3 4

   Un CSR node-bootstrapper en attente.

2. Examinez les détails d'un CSR pour vérifier qu'il est valide :

   oc describe csr <csr_name> 1

   1

   <csr_name> est le nom d'un CSR figurant dans la liste des CSR actuels.

3. Approuver chaque CSR node-bootstrapper valide :

   $ oc adm certificate approve <csr_name>

4. Pour les installations fournies par l'utilisateur, approuver chaque kubelet valide servant de CSR :

   $ oc adm certificate approve <csr_name>

1. Sur le cluster de gestion 1, que vous pouvez considérer comme le cluster de gestion source, le plan de contrôle et les travailleurs interagissent en utilisant l'API DNS externe. L'API DNS externe est accessible et un équilibreur de charge se trouve entre les clusters de gestion.

   

2. Vous prenez un instantané du cluster hébergé, qui comprend etcd, le plan de contrôle et les nœuds de travail. Au cours de ce processus, les nœuds de travail continuent d'essayer d'accéder à l'API DNS externe même si elle n'est pas accessible, les charges de travail sont en cours d'exécution, le plan de contrôle est sauvegardé dans un fichier manifeste local et etcd est sauvegardé dans un seau S3. Le plan de données est actif et le plan de contrôle est en pause.

   

3. Sur le cluster de gestion 2, que vous pouvez considérer comme le cluster de gestion de destination, vous restaurez etcd à partir du seau S3 et restaurez le plan de contrôle à partir du fichier manifeste local. Au cours de ce processus, l'API DNS externe est arrêtée, l'API du cluster hébergé devient inaccessible et tous les travailleurs qui utilisent l'API sont incapables de mettre à jour leurs fichiers manifestes, mais les charges de travail sont toujours en cours d'exécution.

   

4. L'API DNS externe est à nouveau accessible et les nœuds de travail l'utilisent pour passer au cluster de gestion 2. L'API DNS externe peut accéder à l'équilibreur de charge qui pointe vers le plan de contrôle.

   

5. Sur le cluster de gestion 2, le plan de contrôle et les nœuds de travail interagissent en utilisant l'API DNS externe. Les ressources sont supprimées du cluster de gestion 1, à l'exception de la sauvegarde S3 de etcd. Si vous essayez de configurer à nouveau le cluster hébergé sur le cluster de gestion 1, cela ne fonctionnera pas.

   

Procédure

1. Créez un fichier configmap pour déclarer le cluster de gestion des sources en entrant cette commande :

   $ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}

2. Arrêtez la réconciliation dans le cluster hébergé et dans les pools de nœuds en entrant ces commandes :

   PAUSED_UNTIL="true"
   oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
   oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator

   PAUSED_UNTIL="true"
   oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
   oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge
   oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator

3. Sauvegardez etcd et téléchargez les données vers un panier S3 en exécutant ce script bash :

   Astuce

   Enveloppez ce script dans une fonction et appelez-le à partir de la fonction principale.

   # ETCD Backup
   ETCD_PODS="etcd-0"
   if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
     ETCD_PODS="etcd-0 etcd-1 etcd-2"
   fi
   
   for POD in ${ETCD_PODS}; do
     # Create an etcd snapshot
     oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db
     oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db
   
     FILEPATH="/${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
     CONTENT_TYPE="application/x-compressed-tar"
     DATE_VALUE=`date -R`
     SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}"
   
     set +x
     ACCESS_KEY=$(grep aws_access_key_id ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
     SECRET_KEY=$(grep aws_secret_access_key ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g")
     SIGNATURE_HASH=$(echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac "${SECRET_KEY}" -binary | base64)
     set -x
   
     # FIXME: this is pushing to the OIDC bucket
     oc exec -it etcd-0 -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- curl -X PUT -T "/var/lib/data/snapshot.db" \
       -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \
       -H "Date: ${DATE_VALUE}" \
       -H "Content-Type: ${CONTENT_TYPE}" \
       -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \
       https://${BUCKET_NAME}.s3.amazonaws.com/${HC_CLUSTER_NAME}-${POD}-snapshot.db
   done

   Pour plus d'informations sur la sauvegarde d'etcd, voir "Sauvegarde et restauration d'etcd sur un cluster hébergé".

4. Sauvegardez les objets Kubernetes et OpenShift Container Platform en entrant les commandes suivantes. Vous devez sauvegarder les objets suivants :

   • HostedCluster et NodePool objets de l'espace de noms HostedCluster
   • HostedCluster secrets de l'espace de noms HostedCluster
   • HostedControlPlane de l'espace de noms du plan de contrôle hébergé
   • Cluster de l'espace de noms du plan de contrôle hébergé
   • AWSCluster, AWSMachineTemplate, et AWSMachine de l'espace de noms du plan de contrôle hébergé
   • MachineDeployments, MachineSets, et Machines de l'espace de noms du plan de contrôle hébergé

   • ControlPlane secrets de l'espace de noms du plan de contrôle hébergé

     mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}
     chmod 700 ${BACKUP_DIR}/namespaces/
     
     # HostedCluster
     echo "Backing Up HostedCluster Objects:"
     oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
     echo "--> HostedCluster"
     sed -i '' -e '/^status:$/,$d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
     
     # NodePool
     oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
     echo "--> NodePool"
     sed -i '' -e '/^status:$/,$ d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml
     
     # Secrets in the HC Namespace
     echo "--> HostedCluster Secrets:"
     for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do
         oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml
     done
     
     # Secrets in the HC Control Plane Namespace
     echo "--> HostedCluster ControlPlane Secrets:"
     for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do
         oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml
     done
     
     # Hosted Control Plane
     echo "--> HostedControlPlane:"
     oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yaml
     
     # Cluster
     echo "--> Cluster:"
     CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
     oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yaml
     
     # AWS Cluster
     echo "--> AWS Cluster:"
     oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yaml
     
     # AWS MachineTemplate
     echo "--> AWS Machine Template:"
     oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yaml
     
     # AWS Machines
     echo "--> AWS Machine:"
     CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})
     for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml
     done
     
     # MachineDeployments
     echo "--> HostedCluster MachineDeployments:"
     for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
         mdp_name=$(echo ${s} | cut -f 2 -d /)
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml
     done
     
     # MachineSets
     echo "--> HostedCluster MachineSets:"
     for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
         ms_name=$(echo ${s} | cut -f 2 -d /)
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml
     done
     
     # Machines
     echo "--> HostedCluster Machine:"
     for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
         m_name=$(echo ${s} | cut -f 2 -d /)
         oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml
     done

5. Nettoyez les itinéraires ControlPlane en entrant cette commande :

   $ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all

   En entrant cette commande, vous permettez à l'opérateur ExternalDNS de supprimer les entrées Route53.

6. Vérifiez que les entrées de Route53 sont propres en exécutant ce script :

   function clean_routes() {
   
       if [[ -z "${1}" ]];then
           echo "Give me the NS where to clean the routes"
           exit 1
       fi
   
       # Constants
       if [[ -z "${2}" ]];then
           echo "Give me the Route53 zone ID"
           exit 1
       fi
   
       ZONE_ID=${2}
       ROUTES=10
       timeout=40
       count=0
   
       # This allows us to remove the ownership in the AWS for the API route
       oc delete route -n ${1} --all
   
       while [ ${ROUTES} -gt 2 ]
       do
           echo "Waiting for ExternalDNS Operator to clean the DNS Records in AWS Route53 where the zone id is: ${ZONE_ID}..."
           echo "Try: (${count}/${timeout})"
           sleep 10
           if [[ $count -eq timeout ]];then
               echo "Timeout waiting for cleaning the Route53 DNS records"
               exit 1
           fi
           count=$((count+1))
           ROUTES=$(aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} --max-items 10000 --output json | grep -c ${EXTERNAL_DNS_DOMAIN})
       done
   }
   
   # SAMPLE: clean_routes "<HC ControlPlane Namespace>" "<AWS_ZONE_ID>"
   clean_routes "${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}" "${AWS_ZONE_ID}"

Procédure

1. Vérifiez que le nouveau cluster de gestion ne contient aucun espace de noms du cluster que vous restaurez en entrant ces commandes :

   # Just in case
   export KUBECONFIG=${MGMT2_KUBECONFIG}
   BACKUP_DIR=${HC_CLUSTER_DIR}/backup
   
   # Namespace deletion in the destination Management cluster
   $ oc delete ns ${HC_CLUSTER_NS} || true
   $ oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || true

2. Recréez les espaces de noms supprimés en entrant ces commandes :

   # Namespace creation
   $ oc new-project ${HC_CLUSTER_NS}
   $ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}

3. Rétablissez les secrets dans l'espace de noms HC en entrant cette commande :

   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*

4. Restaurez les objets dans l'espace de noms du plan de contrôle HostedCluster en entrant ces commandes :

   # Secrets
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-*
   
   # Cluster
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*

5. Si vous récupérez les nœuds et le pool de nœuds pour réutiliser les instances AWS, restaurez les objets dans l'espace de noms du plan de contrôle HC en entrant ces commandes :

   # AWS
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-*
   
   # Machines
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-*
   $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*

6. Restaurez les données etcd et le cluster hébergé en exécutant ce script bash :

   ETCD_PODS="etcd-0"
   if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then
     ETCD_PODS="etcd-0 etcd-1 etcd-2"
   fi
   
   HC_RESTORE_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-restore.yaml
   HC_BACKUP_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml
   HC_NEW_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-new.yaml
   cat ${HC_BACKUP_FILE} > ${HC_NEW_FILE}
   cat > ${HC_RESTORE_FILE} <<EOF
       restoreSnapshotURL:
   EOF
   
   for POD in ${ETCD_PODS}; do
     # Create a pre-signed URL for the etcd snapshot
     ETCD_SNAPSHOT="s3://${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db"
     ETCD_SNAPSHOT_URL=$(AWS_DEFAULT_REGION=${MGMT2_REGION} aws s3 presign ${ETCD_SNAPSHOT})
   
     # FIXME no CLI support for restoreSnapshotURL yet
     cat >> ${HC_RESTORE_FILE} <<EOF
       - "${ETCD_SNAPSHOT_URL}"
   EOF
   done
   
   cat ${HC_RESTORE_FILE}
   
   if ! grep ${HC_CLUSTER_NAME}-snapshot.db ${HC_NEW_FILE}; then
     sed -i '' -e "/type: PersistentVolume/r ${HC_RESTORE_FILE}" ${HC_NEW_FILE}
     sed -i '' -e '/pausedUntil:/d' ${HC_NEW_FILE}
   fi
   
   HC=$(oc get hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} -o name || true)
   if [[ ${HC} == "" ]];then
       echo "Deploying HC Cluster: ${HC_CLUSTER_NAME} in ${HC_CLUSTER_NS} namespace"
       oc apply -f ${HC_NEW_FILE}
   else
       echo "HC Cluster ${HC_CLUSTER_NAME} already exists, avoiding step"
   fi

7. Si vous récupérez les nœuds et le pool de nœuds pour réutiliser les instances AWS, restaurez le pool de nœuds en entrant cette commande :

   oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*

Procédure

1. Mettez à l'échelle les objets deployment et statefulset en entrant ces commandes :

   # Just in case
   export KUBECONFIG=${MGMT_KUBECONFIG}
   
   # Scale down deployments
   oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
   oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all
   sleep 15

2. Supprimez les objets NodePool en entrant les commandes suivantes :

   NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}')
   if [[ ! -z "${NODEPOOLS}" ]];then
       oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
       oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS}
   fi

3. Supprimez les objets machine et machineset en entrant ces commandes :

   # Machines
   for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do
       oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
       oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
   done
   
   oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || true

4. Supprimez l'objet cluster en entrant ces commandes :

   # Cluster
   C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
   oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
   oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all

5. Supprimez les machines AWS (objets Kubernetes) en entrant ces commandes. Ne vous préoccupez pas de la suppression des machines AWS réelles. Les instances cloud ne seront pas affectées.

   # AWS Machines
   for m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)
   do
       oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true
       oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true
   done

6. Supprimez les objets de l'espace de noms HostedControlPlane et ControlPlane HC en entrant ces commandes :

   # Delete HCP and ControlPlane HC NS
   oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'
   oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all
   oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true

7. Supprimez les objets de l'espace de noms HostedCluster et HC en entrant ces commandes :

   # Delete HC and HC Namespace
   oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true
   oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME}  || true
   oc delete ns ${HC_CLUSTER_NS} || true

1. Chargez la variable d'environnement KUBECONFIG avec le chemin kubeconfig du cluster hébergé.

2. Entrez cette commande :

   $ oc delete pod -n openshift-ovn-kubernetes --all

Procédure

1. Remplacez les variables du script suivant par vos propres informations :

   # Fill the Common variables to fit your environment, this is just a sample
   SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub
   BASE_PATH=${HOME}/hypershift
   BASE_DOMAIN="aws.sample.com"
   PULL_SECRET_FILE="${HOME}/pull_secret.json"
   AWS_CREDS="${HOME}/.aws/credentials"
   CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica
   HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift
   HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift
   HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"}
   NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2}
   
   # MGMT Context
   MGMT_REGION=us-west-1
   MGMT_CLUSTER_NAME="${USER}-dev"
   MGMT_CLUSTER_NS=${USER}
   MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}"
   MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig"
   
   # MGMT2 Context
   MGMT2_CLUSTER_NAME="${USER}-dest"
   MGMT2_CLUSTER_NS=${USER}
   MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}"
   MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig"
   
   # Hosted Cluster Context
   HC_CLUSTER_NS=clusters
   HC_REGION=us-west-1
   HC_CLUSTER_NAME="${USER}-hosted"
   HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}"
   HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig"
   BACKUP_DIR=${HC_CLUSTER_DIR}/backup
   
   BUCKET_NAME="${USER}-hosted-${MGMT_REGION}"
   
   # DNS
   AWS_ZONE_ID="Z026552815SS3YPH9H6MG"
   EXTERNAL_DNS_DOMAIN="guest.jpdv.aws.kerbeross.com"

2. Enregistrez le script dans votre système de fichiers local.

3. Exécutez le script en entrant la commande suivante :

   source <env_file>

   où : env_file est le nom du fichier dans lequel vous avez enregistré le script.