백업 및 복원

절차

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

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

절차

1. Operators → 설치된 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
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - name: default
         velero:
           provider: aws
           default: true
           objectStorage:
             bucket: <bucket_name> 4
             prefix: <prefix> 5
           config:
             region: <region>
             profile: "default"
           credential:
             key: cloud
             name: cloud-credentials 6
     snapshotLocations: 7
       - name: default
         velero:
           provider: aws
           config:
             region: <region> 8
             profile: "default"

   1

   openshift 플러그인은 필수입니다.

   2

   Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 Restic을 구성합니다.

   3

   Restic podSpec에 제공할 노드 선택기를 지정합니다.

   4

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

   5

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

   6

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

   7

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

   8

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

절차

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 OADP Operator 를 찾습니다.
3. OADP Operator 를 선택하고 설치를 클릭합니다.
4. openshift-adp 프로젝트에서 Operator를 설치하려면 설치를 클릭합니다.
5. Operators → 설치된 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. 필요한 최소 권한이 있는 사용자 지정 역할을 생성합니다.

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

10. 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. Operators → 설치된 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
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - velero:
           config:
             resourceGroup: <azure_resource_group> 4
             storageAccount: <azure_storage_account_id> 5
             subscriptionId: <azure_subscription_id> 6
             storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY
           credential:
             key: cloud
             name: cloud-credentials-azure  7
           provider: azure
           default: true
           objectStorage:
             bucket: <bucket_name> 8
             prefix: <prefix> 9
     snapshotLocations: 10
       - velero:
           config:
             resourceGroup: <azure_resource_group>
             subscriptionId: <azure_subscription_id>
             incremental: "true"
           name: default
           provider: azure

   1

   openshift 플러그인은 필수입니다.

   2

   Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 Restic을 구성합니다.

   3

   Restic podSpec에 제공할 노드 선택기를 지정합니다.

   4

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

   5

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

   6

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

   7

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

   8

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

   9

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

   10

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

절차

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

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

절차

1. Operators → 설치된 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
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - velero:
           provider: gcp
           default: true
           credential:
             key: cloud
             name: cloud-credentials-gcp 4
           objectStorage:
             bucket: <bucket_name> 5
             prefix: <prefix> 6
     snapshotLocations: 7
       - velero:
           provider: gcp
           default: true
           config:
             project: <project>
             snapshotLocation: us-west1 8

   1

   openshift 플러그인은 필수입니다.

   2

   Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 Restic을 구성합니다.

   3

   Restic podSpec에 제공할 노드 선택기를 지정합니다.

   4

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

   5

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

   6

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

   7

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

   8

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

절차

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

절차

1. NooBaa 사용자 정의 리소스에서 describe 명령을 실행하여 S3 끝점, AWS_ACCESS_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

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

절차

1. Operators → 설치된 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
         podConfig:
           nodeSelector: <node selector> 3
     backupLocations:
       - velero:
           config:
             profile: "default"
             region: minio
             s3Url: <url> 4
             insecureSkipTLSVerify: "true"
             s3ForcePathStyle: "true"
           provider: aws
           default: true
           credential:
             key: cloud
             name: cloud-credentials 5
           objectStorage:
             bucket: <bucket_name> 6
             prefix: <prefix> 7

   1

   openshift 플러그인은 필수입니다.

   2

   Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 Restic을 구성합니다.

   3

   Restic podSpec에 제공할 노드 선택기를 지정합니다.

   4

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

   5

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

   6

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

   7

   버킷이 여러 용도로 사용되는 경우 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/restic-9cq4q                                         1/1     Running   0          94s
   pod/restic-m4lts                                         1/1     Running   0          94s
   pod/restic-pv4kr                                         1/1     Running   0          95s
   pod/velero-588db7f655-n842v                              1/1     Running   0          95s
   
   NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
   
   NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/restic   3         3         3       3            3           <none>          96s
   
   NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
   deployment.apps/velero                              1/1     1            1           96s
   
   NAME                                                           DESIRED   CURRENT   READY   AGE
   replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

절차

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

절차

1. Operators → 설치된 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:
           - kubevirt 1
           - gcp 2
           - csi 3
           - openshift 4
       restic:
         enable: true 5
         podConfig:
           nodeSelector: <node selector> 6
     backupLocations:
       - velero:
           provider: gcp 7
           default: true
           credential:
             key: cloud
             name: <default_secret> 8
           objectStorage:
             bucket: <bucket_name> 9
             prefix: <prefix> 10

   1

   선택 사항: kubevirt 플러그인이 OpenShift Virtualization과 함께 사용됩니다.

   2

   필요한 경우 백업 공급자의 기본 플러그인을 지정합니다(예: gcp ).

   3

   CSI 스냅샷을 사용하여 PV를 백업하는 경우 csi 기본 플러그인을 지정합니다. csi 플러그인은 Velero CSI 베타 스냅샷 API 를 사용합니다. 스냅샷 위치를 구성할 필요가 없습니다.

   4

   openshift 플러그인은 필수입니다.

   5

   Restic 설치를 비활성화하려면 false 로 설정합니다. Restic은 데몬 세트를 배포합니다. 즉, 각 작업자 노드에 Restic pod가 실행됩니다. Backup CR에 spec.defaultVolumesToRestic: true 를 추가하여 백업에 Restic을 구성합니다.

   6

   Restic podSpec에 제공할 노드 선택기 지정

   7

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

   8

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

   9

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

   10

   버킷이 여러 용도로 사용되는 경우 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/restic-9cq4q                                         1/1     Running   0          94s
   pod/restic-m4lts                                         1/1     Running   0          94s
   pod/restic-pv4kr                                         1/1     Running   0          95s
   pod/velero-588db7f655-n842v                              1/1     Running   0          95s
   
   NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
   
   NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   daemonset.apps/restic   3         3         3       3            3           <none>          96s
   
   NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
   deployment.apps/velero                              1/1     1            1           96s
   
   NAME                                                           DESIRED   CURRENT   READY   AGE
   replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
   replicaset.apps/velero-588db7f655                              1         1         1       96s

절차

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
     includedResources: [] 2
     excludedResources: [] 3
     storageLocation: <velero-sample-1> 4
     ttl: 720h0m0s
     labelSelector: 5
     - matchLabels:
         app=<label_1>
     - matchLabels:
         app=<label_2>
     - matchLabels:
         app=<label_3>
     orlabelSelectors: 6
     - matchLabels:
         app=<label_1>
     - matchLabels:
         app=<label_2>
     - matchLabels:
         app=<label_3>

   1

   백업할 네임스페이스의 배열을 지정합니다.

   2

   선택 사항: 백업에 포함할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우 'po')이거나 정규화될 수 있습니다. 지정하지 않으면 모든 리소스가 포함됩니다.

   3

   선택 사항: 백업에서 제외할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우 'po')이거나 정규화될 수 있습니다.

   4

   backupStorageLocations CR의 이름을 지정합니다.

   5

   지정된 레이블이 모두 있는 백업 리소스입니다.

   6

   지정된 레이블이 하나 이상 있는 백업 리소스입니다.

3. Backup CR의 상태가 Completed 인지 확인합니다.

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

절차

1. 다음과 같이 .yaml 파일을 생성하여 Restic 시크릿을 구성합니다.

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

   참고

   기본적으로 Operator는 dm-credential 이라는 시크릿을 찾습니다. 다른 이름을 사용하는 경우 dpa.spec.features.dataMover.credentialName 을 사용하여 DPA(Data Protection Application) CR을 통해 이름을 지정해야 합니다.

2. 다음 예와 유사한 DPA CR을 생성합니다. 기본 플러그인에는 CSI가 포함됩니다.

   DPA(Data Protection Application) CR 예

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

   1

   이전 단계의 Restic 시크릿 이름을 추가합니다. 이 작업을 수행하지 않으면 기본 시크릿 이름 dm-credential 이 사용됩니다.

   OADP Operator는 두 개의 CRD(사용자 정의 리소스 정의), VolumeSnapshotBackup 및 VolumeSnapshotRestore 를 설치합니다.

   VolumeSnapshotBackup CRD의 예

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

   1

   볼륨 스냅샷이 존재하는 네임스페이스를 지정합니다.

   VolumeSnapshotRestore CRD의 예

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

   1

   볼륨 스냅샷이 존재하는 네임스페이스를 지정합니다.

   2

   Operator가 설치된 네임스페이스를 지정합니다. 기본값은 openshift-adp 입니다.

3. 다음 단계를 수행하여 볼륨 스냅샷을 백업할 수 있습니다.

   1. 백업 CR을 생성합니다.

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

      1

      Operator가 설치된 네임스페이스를 지정합니다. 기본 네임스페이스는 openshift-adp 입니다.

   2. 최대 10분 정도 기다린 후 다음 명령을 입력하여 VolumeSnapshotBackup CR 상태가 완료되었는지 확인합니다.

      $ oc get vsb -n <app_ns>

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

      오브젝트는 DPA에서 구성된 오브젝트 저장소에서 생성됩니다.

      참고

      VolumeSnapshotBackup CR의 상태가 실패 가 되는 경우 문제를 해결하려면 Velero 로그를 참조하십시오.

4. 다음 단계를 수행하여 볼륨 스냅샷을 복원할 수 있습니다.

   1. Velero CSI 플러그인에서 생성한 애플리케이션 네임스페이스 및 volumeSnapshotContent 를 삭제합니다.

   2. Restore CR을 생성하고 restorePV 를 true 로 설정합니다.

      Restore CR의 예

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

   3. 최대 10분 정도 기다린 후 다음 명령을 입력하여 VolumeSnapshotRestore CR 상태가 완료되었는지 확인합니다.

      $ oc get vsr -n <app_ns>

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

   4. 애플리케이션 데이터 및 리소스가 복원되었는지 확인합니다.

      참고

      VolumeSnapshotRestore CR의 상태가 'Failed'가 되면 문제 해결을 위해 Velero 로그를 참조하십시오.

절차

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
     includedResources: [] 2
     excludedResources:
     - nodes
     - events
     - events.events.k8s.io
     - backups.velero.io
     - restores.velero.io
     - resticrepositories.velero.io
     restorePVs: true

   1

   Backup CR의 이름입니다.

   2

   선택 사항: 복원 프로세스에 포함할 리소스 배열을 지정합니다. 리소스는 바로 가기(예: 'pods'의 경우 'po')이거나 정규화될 수 있습니다. 지정하지 않으면 모든 리소스가 포함됩니다.

2. 다음 명령을 입력하여 Restore CR의 상태가 Completed 인지 확인합니다.

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

3. 다음 명령을 입력하여 백업 리소스가 복원되었는지 확인합니다.

   $ oc get all -n <namespace> 1

   1

   백업한 네임스페이스입니다.

4. Restic을 사용하여 DeploymentConfig 오브젝트를 복원하거나 post-restore 후크를 사용하는 경우 다음 명령을 입력하여 dc-restic-post-restore.sh cleanup 스크립트를 실행합니다.

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

   참고

   복원 프로세스 과정에서 OADP Velero 플러그인은 DeploymentConfig 오브젝트를 축소하고 Pod를 독립 실행형 Pod로 복원하여 클러스터가 복원 시 복원된 DeploymentConfig Pod를 즉시 삭제하지 못하도록 하고 Restic 및 post-restore 후크를 허용하여 복원된 Pod에서 작업을 완료할 수 있습니다. cleanup 스크립트는 이러한 연결이 끊긴 Pod를 제거하고 DeploymentConfig 오브젝트를 적절한 복제본 수로 백업합니다.

   예 4.1. dc-restic-post-restore.sh cleanup script

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

해결책

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. Backup CR을 삭제합니다.

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

2. 필요하면 BackupStorageLocation 에서 저장된 데이터를 정리하여 공간을 확보합니다.

3. VolumeSnapshotClass 오브젝트에 velero.io/csi-volumesnapshot-class=true 라벨을 적용합니다.

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

4. 새 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. 대상 클러스터의 기본 버전
2. source_ 클러스터의 기본 버전
3. Kubernetes 버전 우선 순위가 가장 높은 일반적인 지원되지 않는 버전

프로세스

1. 비정상적인 멤버를 제거합니다.

   1. 영향을 받는 노드에 없는 pod를 선택합니다.

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

      $ oc -n openshift-etcd get pods -l k8s-app=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. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

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

   이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

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

   설치 프로그램에서 제공한 인프라를 실행 중이거나 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. spec.providerID 필드를 삭제합니다.

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

   4. 다음 명령을 실행하여 BareMetalHost 오브젝트를 삭제하고 < host_name >을 비정상 노드의 베어 메탈 호스트 이름으로 교체합니다.

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

   5. 다음 명령을 실행하여 비정상 멤버의 머신을 삭제하고 < machine_name >을 비정상 노드의 컨트롤 플레인 시스템의 이름으로 교체합니다(예: clustername-8qw5l-master -0).

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

   6. 시스템이 삭제되었는지 확인합니다.

      $ 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

   7. new-master-machine.yaml 파일을 사용하여 새 시스템을 만듭니다.

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

   8. 새 시스템이 생성되었는지 확인합니다.

      $ 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는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

5. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

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

6. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

   $ oc get etcd/cluster -oyaml

7. 단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에서 다음 오류가 발생할 수 있습니다.

   출력 예

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

검증

1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

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

   $ oc -n openshift-etcd get pods -l k8s-app=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. 루트 디렉토리를 /host 로 변경합니다.

      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 -n openshift-etcd get pods -l k8s-app=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. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

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

   이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

4. 삭제된 비정상 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

5. 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가 작동하는지 확인합니다.

6. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

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

7. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

   $ oc get etcd/cluster -oyaml

8. 단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에서 다음 오류가 발생할 수 있습니다.

   출력 예

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

절차

1. 비정상 멤버를 확인하고 제거합니다.

   1. 영향을 받는 노드에 없는 pod를 선택합니다.

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

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

      출력 예

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

   2. 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다.

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

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

   3. 멤버 목록을 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

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

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

   4. etcdctl member remove 명령에 ID를 지정하여 비정상적인 etcd 멤버를 제거합니다.

      주의

      올바른 etcd 멤버를 제거하십시오. etcd 멤버를 제거하면 쿼럼이 손실될 수 있습니다.

      sh-4.2# etcdctl member remove 7a8197040a5126c8

      출력 예

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b

   5. 멤버 목록을 다시 표시하고 멤버가 제거되었는지 확인합니다.

      sh-4.2# etcdctl member list -w table

      출력 예

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

      이제 노드 쉘을 종료할 수 있습니다.

      중요

      멤버를 제거한 후 나머지 etcd 인스턴스가 재부팅되는 동안 잠시 동안 클러스터에 연결할 수 없습니다.

2. 다음 명령을 입력하여 쿼럼 보호기를 끄십시오.

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

   이 명령을 사용하면 보안을 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

3. 다음 명령을 실행하여 제거된 비정상 etcd 멤버의 이전 암호를 제거합니다.

   1. 삭제된 비정상 etcd 멤버의 시크릿(secrets)을 나열합니다.

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

      이 프로세스의 앞부분에서 기록한 비정상 etcd 멤버의 이름을 전달합니다.

      다음 출력에 표시된대로 피어, 서빙 및 메트릭 시크릿이 있습니다.

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

   2. 제거된 비정상 etcd 멤버의 시크릿을 삭제합니다.

      1. 피어 시크릿을 삭제합니다.

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

      2. 서빙 시크릿을 삭제합니다.

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

      3. 메트릭 시크릿을 삭제합니다.

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

4. 컨트롤 플레인 시스템을 삭제합니다.

   설치 프로그램에서 제공한 인프라를 실행 중이거나 Machine API를 사용하여 컴퓨터를 만든 경우 다음 단계를 수행합니다. 그렇지 않으면 원래 생성하는 데 사용된 방법과 동일한 방법으로 새 컨트롤 플레인 노드를 생성해야 합니다.

   1. 비정상 멤버의 컴퓨터를 가져옵니다.

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

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

      출력 예

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

      1

      비정상 노드의 컨트롤 플레인 시스템 예cluster-control-plane-2.

   2. 시스템 설정을 파일 시스템의 파일에 저장합니다.

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

      1

      비정상 노드의 컨트롤 플레인 시스템의 이름을 지정합니다.

   3. 이전 단계에서 만든 new-master-machine.yaml 파일을 편집하여 새 이름을 할당하고 불필요한 필드를 제거합니다.

      1. 전체 status 섹션을 삭제합니다.

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

5. metadata.name 필드를 새 이름으로 변경합니다.

   이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서 examplecluster-control-plane-2 는 examplecluster-control-plane-3 으로 변경되었습니다.

   예를 들어 다음과 같습니다.

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

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

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

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

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

   3. spec.conditions,spec.lastUpdated,spec.nodeRef 및 spec.phase 필드를 제거합니다.

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

6. 다음 명령을 실행하여 Bare Metal Operator를 사용할 수 있는지 확인합니다.

   $ oc get clusteroperator baremetal

   출력 예

   NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
   baremetal   4.10.x    True        False         False      3d15h

7. 다음 명령을 실행하여 이전 BareMetalHost 오브젝트를 제거합니다.

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

   출력 예

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

8. 다음 명령을 실행하여 비정상 멤버의 시스템을 삭제합니다.

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

   BareMetalHost 및 Machine 오브젝트를 제거한 후 머신 컨트롤러에서 Node 오브젝트를 자동으로 삭제합니다.

   어떤 이유로든 머신 삭제가 지연되거나 명령이 차단되고 지연되면 machine object finalizer 필드를 제거하여 강제로 삭제할 수 있습니다.

   중요

   Ctrl+c 를 눌러 머신 삭제를 중단하지 마십시오. 명령이 완료될 수 있도록 허용해야 합니다. 새 터미널 창을 열어 편집하여 종료자 필드를 삭제합니다.

   1. 다음 명령을 실행하여 머신 구성을 편집합니다.

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

   2. Machine 사용자 정의 리소스에서 다음 필드를 삭제한 다음 업데이트된 파일을 저장합니다.

      finalizers:
      - machine.machine.openshift.io

      출력 예

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

9. 다음 명령을 실행하여 시스템이 삭제되었는지 확인합니다.

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

   출력 예

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

10. 다음 명령을 실행하여 노드가 삭제되었는지 확인합니다.

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

11. 새 BareMetalHost 오브젝트와 시크릿을 생성하여 BMC 자격 증명을 저장합니다.

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

    참고

    사용자 이름과 암호는 다른 베어 메탈 호스트의 시크릿에서 찾을 수 있습니다. bmc:address 에 사용할 프로토콜은 다른 bmh 개체에서 가져올 수 있습니다.

    중요

    기존 컨트롤 플레인 호스트에서 BareMetalHost 오브젝트 정의를 재사용하는 경우 external Provisioned 필드를 true 로 설정하지 마십시오.

    기존 컨트롤 플레인 BareMetalHost 오브젝트는 OpenShift Container Platform 설치 프로그램에서 프로비저닝한 경우 외부Provisioned 플래그를 true 로 설정할 수 있습니다.

    검사가 완료되면 BareMetalHost 오브젝트가 생성되고 프로비저닝할 수 있습니다.

12. 사용 가능한 BareMetalHost 오브젝트를 사용하여 생성 프로세스를 확인합니다.

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

    1. new-master-machine.yaml 파일을 사용하여 새 컨트롤 플레인 시스템을 생성합니다.

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

    2. 새 시스템이 생성되었는지 확인합니다.

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

       출력 예

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

       1

       새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비 상태가 됩니다.

       새 시스템을 생성하는 데 몇 분이 걸릴 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

    3. 베어 메탈 호스트가 프로비저닝되고 다음 명령을 실행하여 오류가 보고되지 않았는지 확인합니다.

       $ oc get bmh -n openshift-machine-api

       출력 예

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

    4. 다음 명령을 실행하여 새 노드가 추가되고 준비 상태에 있는지 확인합니다.

       $ oc get nodes

       출력 예

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

13. 다음 명령을 입력하여 쿼럼 보호기를 다시 켭니다.

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

14. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml

15. 단일 노드 OpenShift를 사용하는 경우 노드를 다시 시작합니다. 그렇지 않으면 etcd 클러스터 Operator에서 다음 오류가 발생할 수 있습니다.

    출력 예

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

검증

1. 모든 etcd pod가 올바르게 실행되고 있는지 확인합니다.

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

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

   출력 예

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

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

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

   1

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

   정확히 세 개의 etcd 멤버가 있는지 확인하려면 실행중인 etcd 컨테이너에 연결하고 영향을 받는 노드에 없는 pod 이름을 전달합니다. 클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

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

2. 멤버 목록을 확인합니다.

   sh-4.2# etcdctl member list -w table

   출력 예

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

   참고

   이전 명령의 출력에 세 개 이상의 etcd 멤버가 나열된 경우 원하지 않는 멤버를 신중하게 제거해야 합니다.

3. 다음 명령을 실행하여 모든 etcd 멤버가 정상인지 확인합니다.

   # etcdctl endpoint health --cluster

   출력 예

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

4. 다음 명령을 실행하여 모든 노드가 최신 버전인지 확인합니다.

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

   AllNodesAtLatestRevision

절차

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 -n openshift-etcd get pods -l k8s-app=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가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

       참고

       OVNKubernetes CNI(Container Network Interface) 플러그인을 사용하는 경우에만 다음 단계를 수행합니다.

12. 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 재시작합니다.

    1. northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트 및 나머지 컨트롤 플레인 노드에 액세스하고 다음 명령을 실행합니다.

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

    2. 다음 명령을 실행하여 모든 OVN-Kubernetes 컨트롤 플레인 Pod를 삭제합니다.

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

    3. 모든 OVN-Kubernetes 컨트롤 플레인 Pod가 다시 배포되어 다음 명령을 실행하여 Running 상태인지 확인합니다.

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

       출력 예

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

    4. 다음 명령을 실행하여 ovnkube-node Pod를 모두 삭제합니다.

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

    5. 모든 ovnkube-node Pod가 다시 배포되어 다음 명령을 실행하여 Running 상태인지 확인합니다.

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

13. 복구되지 않는 다른 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성합니다. 머신을 다시 생성한 후 새 버전이 강제되고 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-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. 복구 호스트가 아닌 각 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.

14. 별도의 터미널 창에서 다음 명령을 입력하여 cluster-admin 역할의 사용자로 클러스터에 로그인합니다.

    $ oc login -u <cluster_admin> 1

    1

    <cluster_admin>은 cluster-admin 역할을 사용하여 사용자 이름을 지정합니다.

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

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

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

    1

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

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

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

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

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

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

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

    $ oc -n openshift-etcd get pods -l k8s-app=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>