手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、OADP Operator を検索します。
3. OADP Operator を選択し、Install をクリックします。
4. Install をクリックして、openshift-adp プロジェクトに Operator をインストールします。
5. Operators → Installed Operators をクリックして、インストールを確認します。

手順

1. BUCKET 変数を設定します。

   $ BUCKET=<your_bucket>

2. REGION 変数を設定します。

   $ REGION=<your_region>

3. AWS S3 バケットを作成します。

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

   1

   us-east-1 は LocationConstraint をサポートしていません。お住まいの地域が us-east-1 の場合は、--create-bucket-configuration LocationConstraint=$REGION を省略してください。

4. IAM ユーザーを作成します。

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

   1

   Velero を使用して複数の S3 バケットを持つ複数のクラスターをバックアップする場合は、クラスターごとに一意のユーザー名を作成します。

5. 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. ポリシーを添付して、velero ユーザーに必要な権限を付与します。

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

7. velero ユーザーのアクセスキーを作成します。

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

   出力例

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

8. credentials-velero ファイルを作成します。

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

   Data Protection Application をインストールする前に、credentials-velero ファイルを使用して AWS の Secret オブジェクトを作成します。

手順

1. Operators → Installed Operators をクリックして、OADP Operator を選択します。
2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。

3. YAML View をクリックして、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
     backupLocations:
       - name: default
         velero:
           provider: aws
           default: true
           objectStorage:
             bucket: <bucket_name> 3
             prefix: <prefix> 4
           config:
             region: <region>
             profile: "default"
           credential:
             key: cloud
             name: cloud-credentials 5
     snapshotLocations: 6
       - name: default
         velero:
           provider: aws
           config:
             region: <region> 7
             profile: "default"

   1

   OpenShift Container Platform クラスターでネームスペースをバックアップおよび復元するには、openshift プラグインが必須です。

   2

   Restic のインストールを無効にする場合は、false に設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードで Restic Pod が実行されていることを意味します。バックアップ用に Restic を設定するには、Backup CR に spec.defaultVolumesToRestic: true を追加します。

   3

   バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。

   4

   バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例: velero)。

   5

   作成した Secret オブジェクトの名前を指定します。この値を指定しない場合は、デフォルト名の cloud-credentials が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。

   6

   CSI スナップショットまたは Restic を使用して PV をバックアップする場合は、スナップショットの場所を指定する必要はありません。

   7

   スナップショットの場所は、PV と同じリージョンにある必要があります。

4. Create をクリックします。

5. OADP リソースを表示して、インストールを確認します。

   $ oc get all -n openshift-adp

   出力例

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
   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
   service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s
   
   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/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
   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/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、OADP Operator を検索します。
3. OADP Operator を選択し、Install をクリックします。
4. Install をクリックして、openshift-adp プロジェクトに Operator をインストールします。
5. Operators → Installed Operators をクリックして、インストールを確認します。

手順

1. Azure にログインします。

   $ az login

2. AZURE_RESOURCE_GROUP 変数を設定します。

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. Azure リソースグループを作成します。

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

   1

   場所を指定します。

4. AZURE_STORAGE_ACCOUNT_ID 変数を設定します。

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

5. 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. BLOB_CONTAINER 変数を設定します。

   $ BLOB_CONTAINER=velero

7. Azure Blob ストレージコンテナーを作成します。

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

8. ストレージアカウントのアクセスキーを取得します。

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

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

   必須。credentials-velero ファイルにサービスプリンシパル認証情報のみが含まれている場合は、内部イメージをバックアップすることはできません。

   Data Protection Application をインストールする前に、credentials-velero ファイルを使用して Azure の Secret オブジェクトを作成します。

手順

1. Operators → Installed Operators をクリックして、OADP Operator を選択します。
2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。

3. YAML View をクリックして、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
     backupLocations:
       - velero:
           config:
             resourceGroup: <azure_resource_group> 3
             storageAccount: <azure_storage_account_id> 4
             subscriptionId: <azure_subscription_id> 5
             storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
           credential:
             key: cloud
             name: cloud-credentials-azure  6
           provider: azure
           default: true
           objectStorage:
             bucket: <bucket_name> 7
             prefix: <prefix> 8
     snapshotLocations: 9
       - velero:
           config:
             resourceGroup: <azure_resource_group>
             subscriptionId: <azure_subscription_id>
             incremental: "true"
           name: default
           provider: azure

   1

   OpenShift Container Platform クラスターでネームスペースをバックアップおよび復元するには、openshift プラグインが必須です。

   2

   Restic のインストールを無効にする場合は、false に設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードで Restic Pod が実行されていることを意味します。バックアップ用に Restic を設定するには、Backup CR に spec.defaultVolumesToRestic: true を追加します。

   3

   Azure リソースグループを指定します。

   4

   Azure ストレージアカウント ID を指定します。

   5

   Azure サブスクリプション ID を指定します。

   6

   この値を指定しない場合は、デフォルト名の cloud-credentials-azure が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。

   7

   バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。

   8

   バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例: velero)。

   9

   CSI スナップショットまたは Restic を使用して PV をバックアップする場合は、スナップショットの場所を指定する必要はありません。

4. Create をクリックします。

5. OADP リソースを表示して、インストールを確認します。

   $ oc get all -n openshift-adp

   出力例

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
   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
   service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s
   
   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/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
   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/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、OADP Operator を検索します。
3. OADP Operator を選択し、Install をクリックします。
4. Install をクリックして、openshift-adp プロジェクトに Operator をインストールします。
5. Operators → Installed Operators をクリックして、インストールを確認します。

手順

1. GCP にログインします。

   $ gcloud auth login

2. BUCKET 変数を設定します。

   $ BUCKET=<bucket> 1

   1

   バケット名を指定します。

3. ストレージバケットを作成します。

   $ gsutil mb gs://$BUCKET/

4. PROJECT_ID 変数をアクティブなプロジェクトに設定します。

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

5. サービスアカウントを作成します。

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

6. サービスアカウントを一覧表示します。

   $ gcloud iam service-accounts list

7. email の値と一致するように SERVICE_ACCOUNT_EMAIL 変数を設定します。

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

8. ポリシーを添付して、velero ユーザーに必要な権限を付与します。

   $ 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. velero.server カスタムロールを作成します。

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

10. IAM ポリシーバインディングをプロジェクトに追加します。

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

11. IAM サービスアカウントを更新します。

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

12. IAM サービスアカウントのキーを現在のディレクトリーにある credentials-velero ファイルに保存します。

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

    Data Protection Application をインストールする前に、credentials-velero ファイルを使用して GCP の Secret オブジェクトを作成します。

手順

1. Operators → Installed Operators をクリックして、OADP Operator を選択します。
2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。

3. YAML View をクリックして、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
     backupLocations:
       - velero:
           provider: gcp
           default: true
           credential:
             key: cloud
             name: cloud-credentials-gcp 3
           objectStorage:
             bucket: <bucket_name> 4
             prefix: <prefix> 5
     snapshotLocations: 6
       - velero:
           provider: gcp
           default: true
           config:
             project: <project>
             snapshotLocation: us-west1 7

   1

   OpenShift Container Platform クラスターでネームスペースをバックアップおよび復元するには、openshift プラグインが必須です。

   2

   Restic のインストールを無効にする場合は、false に設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードで Restic Pod が実行されていることを意味します。バックアップ用に Restic を設定するには、Backup CR に spec.defaultVolumesToRestic: true を追加します。

   3

   この値を指定しない場合は、デフォルトの名前である cloud-credentials-gcp が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。

   4

   バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。

   5

   バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例: velero)。

   6

   CSI スナップショットまたは Restic を使用して PV をバックアップする場合は、スナップショットの場所を指定する必要はありません。

   7

   スナップショットの場所は、PV と同じリージョンにある必要があります。

4. Create をクリックします。

5. OADP リソースを表示して、インストールを確認します。

   $ oc get all -n openshift-adp

   出力例

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
   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
   service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s
   
   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/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
   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/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、OADP Operator を検索します。
3. OADP Operator を選択し、Install をクリックします。
4. Install をクリックして、openshift-adp プロジェクトに Operator をインストールします。
5. Operators → Installed Operators をクリックして、インストールを確認します。

手順

1. NooBaa カスタムリソースで describe コマンドを実行して、S3 エンドポイントである AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY を取得します。

2. credentials-velero ファイルを作成します。

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

   Data Protection Application をインストールする際に、credentials-velero ファイルを使用して Secret オブジェクトを作成します。

手順

1. Operators → Installed Operators をクリックして、OADP Operator を選択します。
2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。

3. YAML View をクリックして、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
     backupLocations:
       - velero:
           config:
             profile: "default"
             region: minio
             s3Url: <url> 3
             insecureSkipTLSVerify: "true"
             s3ForcePathStyle: "true"
           provider: aws
           default: true
           credential:
             key: cloud
             name: cloud-credentials 4
           objectStorage:
             bucket: <bucket_name> 5
             prefix: <prefix> 6

   1

   OpenShift Container Platform クラスターでネームスペースをバックアップおよび復元するには、openshift プラグインが必須です。

   2

   Restic のインストールを無効にする場合は、false に設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードで Restic Pod が実行されていることを意味します。バックアップ用に Restic を設定するには、Backup CR に spec.defaultVolumesToRestic: true を追加します。

   3

   S3 エンドポイントの URL を指定します。

   4

   この値を指定しない場合は、デフォルト名の cloud-credentials が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。

   5

   バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。

   6

   バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例: velero)。

4. Create をクリックします。

5. OADP リソースを表示して、インストールを確認します。

   $ oc get all -n openshift-adp

   出力例

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
   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
   service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s
   
   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/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
   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/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、OADP Operator を検索します。
3. OADP Operator を選択し、Install をクリックします。
4. Install をクリックして、openshift-adp プロジェクトに Operator をインストールします。
5. Operators → Installed Operators をクリックして、インストールを確認します。

手順

1. Operators → Installed Operators をクリックして、OADP Operator を選択します。
2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。

3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
     name: <dpa_sample>
     namespace: openshift-adp
   spec:
     configuration:
       velero:
         defaultPlugins:
           - gcp 1
           - csi 2
           - openshift 3
       restic:
         enable: true 4
     backupLocations:
       - velero:
           provider: gcp 5
           default: true
           credential:
             key: cloud
             name: <default_secret> 6
           objectStorage:
             bucket: <bucket_name> 7
             prefix: <prefix> 8

   1

   必要に応じて、バックアッププロバイダーのデフォルトのプラグイン (gcp など) を指定します。

   2

   CSI スナップショットを使用して PV をバックアップする場合は、csi のデフォルトプラグインを指定します。csi プラグインは、Velero CSI ベータスナップショット API を使用します。スナップショットの場所を設定する必要はありません。

   3

   OpenShift Container Platform クラスターでネームスペースをバックアップおよび復元するには、openshift プラグインが必須です。

   4

   Restic のインストールを無効にする場合は、false に設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードで Restic Pod が実行されていることを意味します。バックアップ用に Restic を設定するには、Backup CR に spec.defaultVolumesToRestic: true を追加します。

   5

   バックアッププロバイダーを指定します。

   6

   バックアッププロバイダーにデフォルトのプラグインを使用する場合は、Secret に正しいデフォルトの名前を指定する必要があります (例: cloud-credentials-gcp)。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。Secret 名を指定しない場合は、デフォルトの名前が使用されます。

   7

   バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。

   8

   バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例: velero)。

4. Create をクリックします。

5. OADP リソースを表示して、インストールを確認します。

   $ oc get all -n openshift-adp

   出力例

   NAME                                                     READY   STATUS    RESTARTS   AGE
   pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
   pod/oadp-velero-sample-1-aws-registry-5d6968cbdd-d5w9k   1/1     Running   0          95s
   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
   service/oadp-velero-sample-1-aws-registry-svc              ClusterIP   172.30.130.230   <none>        5000/TCP   95s
   
   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/oadp-velero-sample-1-aws-registry   1/1     1            1           96s
   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/oadp-velero-sample-1-aws-registry-5d6968cbdd   1         1         1       96s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

手順

1. backupStorageLocations CR を取得します。

   $ oc get backupStorageLocations

   出力例

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

2. 次の例のように、Backup CR を作成します。

   apiVersion: velero.io/v1
   kind: Backup
   metadata:
     name: <backup>
     labels:
       velero.io/storage-location: default
     namespace: openshift-adp
   spec:
     hooks: {}
     includedNamespaces:
     - <namespace> 1
     storageLocation: <velero-sample-1> 2
     ttl: 720h0m0s

   1

   バックアップする名前空間の配列を指定します。

   2

   backupStorageLocations CR の名前を指定します。

3. Backup CR のステータスが Completed したことを確認します。

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

手順

1. backupStorageLocations CR を取得します。

   $ oc get backupStorageLocations

   出力例

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

2. 次の例のように、Schedule CR を作成します。

   $ 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 式。たとえば、毎日 7:00 にバックアップを実行する場合は 0 7 * * * です。

   2

   バックアップを作成する名前空間の配列。

   3

   backupStorageLocations CR の名前。

   4

   オプション: Restic を使用してボリュームをバックアップする場合は、キーと値のペア defaultVolumesToRestic: true を追加します。

3. スケジュールされたバックアップの実行後に、Schedule CR のステータスが Completed となっていることを確認します。

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

手順

1. 次の例のように、Restore CR を作成します。

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

   1

   Backup CR の名前

2. Restore CR のステータスが Completed したことを確認します。

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

3. バックアップリソースが復元されたことを確認します。

   $ oc get all -n <namespace> 1

   1

   バックアップした名前空間。

解決方法

1. DataProtectionApplication マニフェストの spec.snapshotLocations.velero.config.region キーの値を編集して、スナップショットの場所が PV と同じリージョンにあるようにします。
2. 新しい Backup CR を作成します。

解決方法

1. Backup CR の詳細を取得します。

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

2. Backup CR を削除します。

   $ oc delete backup <backup> -n openshift-adp

   進行中の Backup CR はファイルをオブジェクトストレージにアップロードしていないため、バックアップの場所をクリーンアップする必要はありません。

3. 新しい Backup CR を作成します。

1. NFS データボリューム上に Restic の補足グループを作成します。
2. NFS ディレクトリーに setgid ビットを設定して、グループの所有権が継承されるようにします。

3. 次の例のように、spec.configuration.restic.supplementalGroups パラメーターおよびグループ ID を DataProtectionApplication マニフェストに追加します。

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

   1

   補助グループ ID を指定します。

4. Restic Pod が再起動し、変更が適用されるまで待機します。

解決方法

1. ReplicationController、DeploymentConfig、および TemplateInstances リソースを除外する Restore CR を作成します。

   $ velero restore create --from-backup=<backup> -n openshift-adp \ 1
     --include-namespaces <namespace> \ 2
     --exclude-resources replicationcontroller,deploymentconfig,templateinstances.template.openshift.io \
     --restore-volumes=true

   1

   Backup CR の名前を指定します。

   2

   Backup CR で include-namespaces を指定します。

2. Restore CR のステータスが Completed したことを確認します。

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

3. ReplicationController および DeploymentConfig リソースを含む Restore CR を作成します。

   $ velero restore create --from-backup=<backup> -n openshift-adp \
     --include-namespaces <namespace> \
     --include-resources replicationcontroller,deploymentconfig \
     --restore-volumes=true

4. Restore CR のステータスが Completed したことを確認します。

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

5. バックアップリソースが復元されたことを確認します。

   $ oc get all -n <namespace>

手順

1. 正常でないメンバーを削除します。

   1. 影響を受けるノード上に ない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

      出力例

      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. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

   3. メンバーの一覧を確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        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 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。$ etcdctl endpoint health コマンドは、補充手順が完了し、新しいメンバーが追加されるまで、削除されたメンバーを一覧表示します。

   4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d

      出力例

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346

   5. メンバーの一覧を再度表示し、メンバーが削除されたことを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        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 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      これでノードシェルを終了できます。

      重要

      メンバーを削除した後、残りの etcd インスタンスが再起動している間、クラスターに短時間アクセスできない場合があります。

2. 削除された正常でない etcd メンバーの古いシークレットを削除します。

   1. 削除された正常でない etcd メンバーのシークレットを一覧表示します。

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

      1

      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。

      出力例

      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. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。

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

      2. 提供シークレットを削除します。

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

      3. メトリクスシークレットを削除します。

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

3. コントロールプレーンマシン (別名マスターマシン) を削除し、再作成します。このマシンが再作成されると、新規リビジョンが強制的に実行され、etcd は自動的にスケールアップします。

   インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成する際に使用した方法と同じ方法を使用して新規マスターを作成する必要があります。

   1. 正常でないメンバーのマシンを取得します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

      出力例

      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

      これは正常でないノードのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。

   2. マシン設定をファイルシステムのファイルに保存します。

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

      1

      正常でないノードのコントロールプレーンマシンの名前を指定します。

   3. 直前の手順で作成された new-master-machine.yaml ファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。

      1. 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. metadata.name フィールドを新規の名前に変更します。

         古いマシンと同じベース名を維持し、最後の番号を次に利用可能な番号に変更することが推奨されます。この例では、clustername-8qw5l-master-0 は clustername-8qw5l-master-3 に変更されています。

         以下に例を示します。

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

      3. spec.providerID フィールドを削除します。

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

      4. metadata.annotations および metadata.generation フィールドを削除します。

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

      5. metadata.resourceVersion および metadata.uid フィールドを削除します。

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

   4. 正常でないメンバーのマシンを削除します。

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

      1

      正常でないノードのコントロールプレーンマシンの名前を指定します。

   5. マシンが削除されたことを確認します。

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

      出力例

      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

   6. new-master-machine.yaml ファイルを使用して新規マシンを作成します。

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

   7. 新規マシンが作成されたことを確認します。

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

      出力例

      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

      新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

      新規マシンが作成されるまでに数分の時間がかかる場合があります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

検証

1. すべての etcd Pod が適切に実行されていることを確認します。

   クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

   $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

   出力例

   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

   直前のコマンドの出力に 2 つの Pod のみが一覧表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

   1

   forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

2. 3 つの etcd メンバーがあることを確認します。

   1. 実行中の etcd コンテナーに接続し、影響を受けるノードになかった Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

   2. メンバーの一覧を確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        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 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。

      警告

      必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。

手順

1. クラッシュループしている etcd Pod を停止します。

   1. クラッシュループしているノードをデバッグします。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

      1

      これを正常でないノードの名前に置き換えます。

   2. ルートディレクトリーをホストに切り替えます。

      sh-4.2# chroot /host

   3. 既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。

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

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

   4. etcd データディレクトリーを別の場所に移動します。

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

      これでノードシェルを終了できます。

2. 正常でないメンバーを削除します。

   1. 影響を受けるノード上に ない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

      出力例

      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. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

   3. メンバーの一覧を確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        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 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。

   4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。

      sh-4.2# etcdctl member remove 62bcf33650a7170a

      出力例

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346

   5. メンバーの一覧を再度表示し、メンバーが削除されたことを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        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 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      これでノードシェルを終了できます。

3. 削除された正常でない etcd メンバーの古いシークレットを削除します。

   1. 削除された正常でない etcd メンバーのシークレットを一覧表示します。

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

      1

      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。

      出力例

      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. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。

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

      2. 提供シークレットを削除します。

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

      3. メトリクスシークレットを削除します。

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

4. etcd の再デプロイメントを強制的に実行します。

   クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

   1

   forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

   etcd クラスター Operator が再デプロイを実行する場合、すべてのコントロールプレーンノード (別名マスターノード) に機能する etcd Pod があることを確認します。

手順

1. リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作を実行するホストです。

2. リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。

   Kubernetes API サーバーは復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。

   重要

   この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。

3. etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。

   この手順では、etcd スナップショットおよび静的 Pod のリソースを含む backup ディレクトリーを、リカバリーコントロールプレーンホストの /home/core/ ディレクトリーにコピーしていることを前提としています。

4. 他のすべてのコントロールプレーンノードで静的 Pod を停止します。

   注記

   リカバリーホストで Pod を手動で停止する必要はありません。リカバリースクリプトは、リカバリーホストの Pod を停止します。

   1. リカバリーホストではないコントロールプレーンホストにアクセスします。

   2. 既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。

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

   3. etcd Pod が停止していることを確認します。

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

      コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。

   4. 既存の Kubernetes API サーバー Pod ファイルを kubelet マニフェストディレクトリーから移動します。

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

   5. Kubernetes API サーバー Pod が停止していることを確認します。

      $ sudo crictl ps | grep kube-apiserver | grep -v operator

      コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。

   6. etcd データディレクトリーを別の場所に移動します。

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

   7. リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
5. リカバリーコントロールプレーンホストにアクセスします。

6. クラスター全体のプロキシーが有効になっている場合は、 NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートしていることを確認します。

   ヒント

   oc get proxy cluster -o yaml の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、および noProxy フィールドに値が設定されている場合に有効にされます。

7. リカバリーコントロールプレーンホストで復元スクリプトを実行し、パスを etcd バックアップディレクトリーに渡します。

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

   スクリプトの出力例

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

   注記

   最後の etcd バックアップの後にノード証明書が更新された場合、復元プロセスによってノードが NotReady 状態になる可能性があります。

8. ノードをチェックして、Ready 状態であることを確認します。

   1. 以下のコマンドを実行します。

      $ oc get nodes -w

      出力例

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

      すべてのノードが状態を報告するのに数分かかる場合があります。

   2. NotReady 状態のノードがある場合は、ノードにログインし、各ノードの /var/lib/kubelet/pki ディレクトリーからすべての PEM ファイルを削除します。ノードに SSH 接続するか、Web コンソールのターミナルウィンドウを使用できます。

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

      サンプル 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. すべてのコントロールプレーンホストで kubelet サービスを再起動します。

   1. リカバリーホストから以下のコマンドを実行します。

      $ sudo systemctl restart kubelet.service

   2. 他のすべてのコントロールプレーンホストでこの手順を繰り返します。

10. 保留中の CSR を承認します。

    1. 現在の CSR の一覧を取得します。

       $ oc get csr

       出力例

       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

       保留中の kubelet サービス CSR (ユーザーがプロビジョニングしたインストール用)。

       3 4

       保留中の node-bootstrapper CSR。

    2. CSR の詳細をレビューし、これが有効であることを確認します。

       $ oc describe csr <csr_name> 1

       1

       <csr_name> は、現行の CSR の一覧からの CSR の名前です。

    3. それぞれの有効な node-bootstrapper CSR を承認します。

       $ oc adm certificate approve <csr_name>

    4. ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。

       $ oc adm certificate approve <csr_name>

11. 単一メンバーのコントロールプレーンが正常に起動していることを確認します。

    1. リカバリーホストから etcd コンテナーが実行中であることを確認します。

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

       出力例

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

    2. リカバリーホストから、etcd Pod が実行されていることを確認します。

       $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

       注記

       このコマンドを実行する前に oc login の実行を試行し、以下のエラーを受信すると、認証コントローラーが起動し、再試行するまでしばらく待機します。

       Unable to connect to the server: EOF

       出力例

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

       ステータスが Pending の場合や出力に複数の実行中の etcd Pod が一覧表示される場合、数分待機してから再度チェックを行います。

    3. リカバリーホストではない喪失したコントロールプレーンホストで、このステップを繰り返します。

12. 他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。これらのマシンが再作成されると、新規リビジョンが強制的に実行され、etcd は自動的にスケールアップします。

    インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成したときと同じ方法で、新しいコントロールプレーンノードを作成する必要があります。

    警告

    リカバリーホストのマシンを削除し、再作成しないでください。

    1. 失われたコントロールプレーンホストのいずれかのマシンを取得します。

       クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

       出力例:

       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

       これは、失われたコントロールプレーンホストのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。

    2. マシン設定をファイルシステムのファイルに保存します。

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

       1

       失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。

    3. 直前の手順で作成された new-master-machine.yaml ファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。

       1. 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. metadata.name フィールドを新規の名前に変更します。

          古いマシンと同じベース名を維持し、最後の番号を次に利用可能な番号に変更することが推奨されます。この例では、clustername-8qw5l-master-0 は clustername-8qw5l-master-3 に変更されています。

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

       3. spec.providerID フィールドを削除します。

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

       4. metadata.annotations および metadata.generation フィールドを削除します。

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

       5. metadata.resourceVersion および metadata.uid フィールドを削除します。

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

    4. 失われたコントロールプレーンホストのマシンを削除します。

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

       1

       失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。

    5. マシンが削除されたことを確認します。

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

       出力例:

       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. new-master-machine.yaml ファイルを使用して新規マシンを作成します。

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

    7. 新規マシンが作成されたことを確認します。

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

       出力例:

       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

       新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

       新規マシンが作成されるまでに数分の時間がかかる場合があります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

    8. リカバリーホストではない喪失したコントロールプレーンホストで、これらのステップを繰り返します。

13. 別のターミナルウィンドウで、以下のコマンドを使用して cluster-admin ロールが割り当てられたユーザーとしてクラスターにログインします。

    $ oc login -u <cluster_admin> 1

    1

    <cluster_admin> については、cluster-admin ロールでユーザー名を指定します。

14. etcd の再デプロイメントを強制的に実行します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

    1

    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

    etcd クラスター Operator が再デプロイメントを実行すると、初期ブートストラップのスケールアップと同様に、既存のノードが新規 Pod と共に起動します。

15. すべてのノードが最新のリビジョンに更新されていることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

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

    etcd の NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1

    1

    この例では、最新のリビジョン番号は 7 です。

    出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

16. etcd の再デプロイ後に、コントロールプレーンの新規ロールアウトを強制的に実行します。kubelet が内部ロードバランサーを使用して API サーバーに接続されているため、Kubernetes API サーバーは他のノードに再インストールされます。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    1. Kubernetes API サーバーの新規ロールアウトを強制的に実行します。

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

       すべてのノードが最新のリビジョンに更新されていることを確認します。

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

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

    2. Kubernetes コントローラーマネージャーの新規ロールアウトを強制的に実行します。

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

       すべてのノードが最新のリビジョンに更新されていることを確認します。

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

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

    3. Kubernetes スケジューラーの新規ロールアウトを強制的に実行します。

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

       すべてのノードが最新のリビジョンに更新されていることを確認します。

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

       NodeInstallerProgressing 状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力には AllNodesAtLatestRevision が表示されます。

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       この例では、最新のリビジョン番号は 7 です。

       出力に 2 nodes are at revision 6; 1 nodes are at revision 7 などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。

17. すべてのコントロールプレーンホストが起動しており、クラスターに参加していることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep etcd

    出力例

    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

手順

1. 現在の CSR の一覧を取得します。

   $ oc get csr

   出力例

   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

   保留中の kubelet サービス CSR (ユーザーがプロビジョニングしたインストール用)。

   3 4

   保留中の node-bootstrapper CSR。

2. CSR の詳細をレビューし、これが有効であることを確認します。

   $ oc describe csr <csr_name> 1

   1

   <csr_name> は、現行の CSR の一覧からの CSR の名前です。

3. それぞれの有効な node-bootstrapper CSR を承認します。

   $ oc adm certificate approve <csr_name>

4. ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。

   $ oc adm certificate approve <csr_name>