백업 및 복원

프로세스

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
3. OADP Operator 를 선택하고 설치를 클릭합니다.
4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.

프로세스

1. AWS S3 버킷을 생성합니다.

   $ aws s3api create-bucket \
       --bucket <bucket> \ 1
       --region <bucket_region> 2

   1

   S3 버킷 이름을 지정합니다.

   2

   S3 버킷 영역을 지정합니다(예: us-east-1).

2. IAM 사용자 velero를 생성합니다.

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

3. EC2 EBS 스냅샷 정책을 생성합니다.

   $ cat > velero-ec2-snapshot-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           }
       ]
   }
   EOF

4. 하나 또는 모든 S3 버킷에 대한 AWS S3 액세스 정책을 생성합니다.

   $ cat > velero-s3-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::<bucket>/*" 1
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket",
                   "s3:GetBucketLocation",
                   "s3:ListBucketMultipartUploads"
               ],
               "Resource": [
                   "arn:aws:s3:::<bucket>" 2
               ]
           }
       ]
   }
   EOF

   1 2

   단일 S3 버킷에 대한 액세스 권한을 부여하려면 버킷 이름을 지정합니다. 모든 AWS S3 버킷에 대한 액세스 권한을 부여하려면 다음 예제와 같이 버킷 이름 대신 *를 지정합니다.

   출력 예

   "Resource": [
       "arn:aws:s3:::*"

5. EC2 EBS 정책을 velero에 연결합니다.

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

6. AWS S3 정책을 velero에 연결합니다.

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero-s3 \
     --policy-document file://velero-s3-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>, 1
           "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
       }
   }

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 애플리케이션을 설치하기 전에 credentials-velero 파일을 사용하여 AWS의 Secret 오브젝트를 생성합니다.

프로세스

1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

3. YAML 보기를 클릭하고 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가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.

   3

   버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.

   4

   여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.

   5

   생성한 Secret 오브젝트의 이름을 지정합니다. 이 값을 지정하지 않으면 기본 이름 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.

   6

   PV를 백업하기 위해 CSI 스냅샷 또는 Restic을 사용하는 경우 스냅샷 위치를 지정할 필요가 없습니다.

   7

   스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.

4. 생성을 클릭합니다.

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 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
3. OADP Operator 를 선택하고 설치를 클릭합니다.
4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.

프로세스

1. AZURE_RESOURCE_GROUP 변수를 설정합니다.

   $ AZURE_RESOURCE_GROUP=Velero_Backups

2. Azure 리소스 그룹을 생성합니다.

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

   1

   위치를 지정합니다.

3. AZURE_STORAGE_ACCOUNT_ID 변수를 설정합니다.

   $ AZURE_STORAGE_ACCOUNT_ID=velerobackups

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

5. BLOB_CONTAINER 변수를 설정합니다.

   $ BLOB_CONTAINER=velero

6. Azure Blob 스토리지 컨테이너를 생성합니다.

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

7. 스토리지 계정 액세스 키를 가져옵니다.

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

8. 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 파일에 서비스 주체 자격 증명만 포함된 경우 내부 이미지를 백업할 수 없습니다.

   데이터 보호 애플리케이션을 설치하기 전에 credentials-velero 파일을 사용하여 Azure용 Secret 오브젝트를 생성합니다.

절차

1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

3. YAML 보기를 클릭하고 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가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.

   3

   Azure 리소스 그룹을 지정합니다.

   4

   Azure 스토리지 계정 ID를 지정합니다.

   5

   Azure 서브스크립션 ID를 지정합니다.

   6

   이 값을 지정하지 않으면 기본 이름 cloud-credentials-azure 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.

   7

   버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.

   8

   여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.

   9

   PV를 백업하기 위해 CSI 스냅샷 또는 Restic을 사용하는 경우 스냅샷 위치를 지정할 필요가 없습니다.

4. 생성을 클릭합니다.

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 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
3. OADP Operator 를 선택하고 설치를 클릭합니다.
4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.

절차

1. gsutil에 로그인합니다.

   $ gsutil init

   출력 예

   Welcome! This command will take you through the configuration of gcloud.
   
   Your current configuration has been set to: [default]
   
   To continue, you must login. Would you like to login (Y/n)?

2. BUCKET 변수를 설정합니다.

   $ BUCKET=<bucket> 1

   1

   버킷 이름을 지정합니다.

3. 스토리지 버킷을 생성합니다.

   $ gsutil mb gs://$BUCKET/

4. PROJECT_ID 변수를 활성 프로젝트로 설정합니다.

   $ PROJECT_ID=`gcloud config get-value project`

5. Velero IAM 서비스 계정을 생성합니다.

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

6. SERVICE_ACCOUNT_EMAIL 변수를 생성합니다.

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

7. ROLE_PERMISSIONS 변수를 생성합니다.

   $ 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
   )

8. velero.server 사용자 정의 역할을 생성합니다.

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

9. 프로젝트에 IAM 정책 바인딩을 추가합니다.

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

10. IAM 서비스 계정을 업데이트합니다.

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

11. IAM 서비스 계정 키를 현재 디렉터리의 credentials-velero 파일에 저장합니다.

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

    Data Protection 애플리케이션을 설치하기 전에 credentials-velero 파일을 사용하여 GCP용 Secret 오브젝트를 생성합니다.

절차

1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

3. YAML 보기를 클릭하고 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가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.

   3

   이 값을 지정하지 않으면 기본 이름 cloud-credentials-gcp 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.

   4

   버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.

   5

   여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.

   6

   PV를 백업하기 위해 CSI 스냅샷 또는 Restic을 사용하는 경우 스냅샷 위치를 지정할 필요가 없습니다.

   7

   스냅샷 위치는 PV와 동일한 리전에 있어야 합니다.

4. 생성을 클릭합니다.

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 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
3. OADP Operator 를 선택하고 설치를 클릭합니다.
4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.

절차

1. 적절한 OpenShift Container Storage 배포 가이드를 사용하여 OpenShift Container Storage를 배포합니다.

2. NooBaa 사용자 지정 리소스에서 describe 명령을 실행하여 S3 엔드포인트 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY를 가져옵니다.

   MCG를 MTC 웹 콘솔에 복제 리포지토리로 추가하려면 이러한 값이 필요합니다.

절차

1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

3. YAML 보기를 클릭하고 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가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.

   3

   S3 끝점의 URL을 지정합니다.

   4

   이 값을 지정하지 않으면 기본 이름 cloud-credentials 가 사용됩니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다.

   5

   버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.

   6

   여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.

4. 생성을 클릭합니다.

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 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
3. OADP Operator 를 선택하고 설치를 클릭합니다.
4. openshift-adp 프로젝트에서 설치를 클릭하여 Operator를 설치합니다.
5. Operator → 설치된 Operator 를 클릭하여 설치를 확인합니다.

절차

1. Operator → 설치된 Operator를 클릭하고 OADP Operator를 선택합니다.
2. 제공된 API 아래의 DataProtectionApplication 상자에서 인스턴스 생성 을 클릭합니다.

3. YAML 보기를 클릭하고 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가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 대한 Restic을 구성합니다.

   5

   백업 공급자를 지정합니다.

   6

   백업 공급자에 기본 플러그인을 사용하는 경우 보안에 올바른 기본 이름(예: cloud-credentials-gcp )을 지정해야 합니다. 사용자 지정 이름을 지정하면 백업 위치에 사용자 정의 이름이 사용됩니다. Secret 이름을 지정하지 않으면 기본 이름이 사용됩니다.

   7

   버킷을 백업 스토리지 위치로 지정합니다. 버킷이 Velero 백업의 전용 버킷이 아닌 경우 접두사를 지정해야 합니다.

   8

   여러 용도로 버킷이 사용되는 경우 Velero 백업의 접두사(예: velero )를 지정합니다.

4. 생성을 클릭합니다.

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 표현식(예: 0 7 * * ) 매일 7:00에 백업을 수행합니다.

   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. 스냅샷 위치가 PV와 동일한 지역에 있도록 DataProtectionApplication 매니페스트의 spec.snapshotLocations.velero.config.region 키 값을 편집합니다.
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 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오. $ etcdctl endpoint health 명령은 교체 절차가 완료되고 새 멤버가 추가될 때까지 제거된 멤버를 나열합니다.

   4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 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 멤버의 시크릿(secrets)을 나열합니다.

      $ 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는 자동으로 확장됩니다.

   설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine 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. 이전 단계의 새 시스템 이름을 사용하도록 metadata.selfLink 필드를 업데이트합니다.

         apiVersion: machine.openshift.io/v1beta1
         kind: Machine
         metadata:
           ...
           selfLink: /apis/machine.openshift.io/v1beta1/namespaces/openshift-machine-api/machines/clustername-8qw5l-master-3
           ...

      4. spec.providerID 필드를 삭제합니다.

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

      5. metadata.annotations 및 metadata.generation 필드를 제거합니다.

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

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

   이전 명령의 출력에 두 개의 pod만 나열되는 경우 수동으로 etcd 재배포를 강제 수행할 수 있습니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

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

   1

   forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

2. 정확히 세 개의 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 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      이전 명령의 출력에 세 개 이상의 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. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.

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

      이러한 값은 프로세스의 뒷부분에서 필요하므로 비정상 etcd 멤버의 ID와 이름을 기록해 두십시오.

   4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 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 멤버의 시크릿(secrets)을 나열합니다.

      $ 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. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.

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

   3. etcd pod가 중지되었는지 확인합니다.

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

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

   4. kubelet 매니페스트 디렉토리에서 기존 Kubernetes API 서버 pod 파일을 이동합니다.

      $ 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로 액세스하거나 웹 콘솔의 터미널 창을 사용할 수 있습니다.

      $  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의 세부 사항을 검토하여 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가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

12. etcd를 강제로 재배포합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

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

    1

    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 실행하면 기존 노드가 초기 부트 스트랩 확장과 유사한 새 pod를 사용하기 시작합니다.

13. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

14. 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

15. 모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 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의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.

   $ oc describe csr <csr_name> 1

   1

   <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

3. 각각의 유효한 node-bootstrapper CSR을 승인합니다.

   $ oc adm certificate approve <csr_name>

4. 사용자 프로비저닝 설치의 경우 CSR을 제공하는 각 유효한 kubelet을 승인합니다.

   $ oc adm certificate approve <csr_name>