4.13. トラブルシューティング

手順

1. 次のコマンドのいずれかを実行して、BSL のリストを取得します。

   1. OpenShift CLI を使用する場合:

      $ oc get backupstoragelocation -A

   2. Velero CLI を使用する場合:

      $ velero backup-location get -n <OADP_Operator_namespace>

2. BSL のリストを使用し、次のコマンドを実行して各 BSL のマニフェストを表示し、各マニフェストにエラーがないか調べます。

   $ oc get backupstoragelocation -n <namespace> -o yaml

解決方法

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 を作成します。

4. Velero バックアップの詳細を表示します。

   $ velero backup describe <backup-name> --details

解決方法

1. Backup CR を削除します。

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

2. 必要に応じて、BackupStorageLocation に保存されているデータをクリーンアップして、領域を解放します。

3. ラベル velero.io/csi-volumesnapshot-class=true を VolumeSnapshotClass オブジェクトに適用します。

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

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

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

3. spec.configuration.nodeAgent.supplementalGroups パラメーターとグループ ID を DataProtectionApplication マニフェストに追加します。次に例を示します。

   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   # ...
   spec:
     configuration:
       nodeAgent:
         enable: true
         uploaderType: restic
         supplementalGroups:
         - <group_id> 1
   # ...

   1

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

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

解決方法

1. DPA カスタムリソース (CR) で、Velero サーバーの restore-resource-priorities フィールドを確認または設定して、securitycontextconstraints がリソースのリストの pods の前に順番にリストされていることを確認します。

   $ oc get dpa -o yaml

   DPA CR の例

   # ...
   configuration:
     restic:
       enable: true
     velero:
       args:
         restore-resource-priorities: 'securitycontextconstraints,customresourcedefinitions,namespaces,storageclasses,volumesnapshotclass.snapshot.storage.k8s.io,volumesnapshotcontents.snapshot.storage.k8s.io,volumesnapshots.snapshot.storage.k8s.io,datauploads.velero.io,persistentvolumes,persistentvolumeclaims,serviceaccounts,secrets,configmaps,limitranges,pods,replicasets.apps,clusterclasses.cluster.x-k8s.io,endpoints,services,-,clusterbootstraps.run.tanzu.vmware.com,clusters.cluster.x-k8s.io,clusterresourcesets.addons.cluster.x-k8s.io' 1
       defaultPlugins:
       - gcp
       - openshift

   1

   既存のリストアリソース優先順位リストがある場合は、その既存のリストを完全なリストと組み合わせてください。

2. デプロイメントの警告が発生しないように、Fixing PodSecurity Admission warnings for deployments で説明されているように、アプリケーション Pod のセキュリティー標準が調整されていることを確認します。アプリケーションがセキュリティー標準に準拠していない場合は、SCC に関係なくエラーが発生する可能性があります。 

手順

1. openshift-monitoring namespace で cluster-monitoring-config ConfigMap オブジェクトを編集します。

   $ oc edit configmap cluster-monitoring-config -n openshift-monitoring

2. data セクションの config.yaml フィールドで、enableUserWorkload オプションを追加または有効にします。

   apiVersion: v1
   data:
     config.yaml: |
       enableUserWorkload: true 1
   kind: ConfigMap
   metadata:
   # ...

   1

   このオプションを追加するか、true に設定します

3. しばらく待って、openshift-user-workload-monitoring namespace で次のコンポーネントが稼働しているかどうかを確認して、ユーザーワークロードモニタリングのセットアップを検証します。

   $ oc get pods -n openshift-user-workload-monitoring

   出力例

   NAME                                   READY   STATUS    RESTARTS   AGE
   prometheus-operator-6844b4b99c-b57j9   2/2     Running   0          43s
   prometheus-user-workload-0             5/5     Running   0          32s
   prometheus-user-workload-1             5/5     Running   0          32s
   thanos-ruler-user-workload-0           3/3     Running   0          32s
   thanos-ruler-user-workload-1           3/3     Running   0          32s

4. openshift-user-workload-monitoring に user-workload-monitoring-config ConfigMap が存在することを確認します。存在する場合、この手順の残りの手順はスキップしてください。

   $ oc get configmap user-workload-monitoring-config -n openshift-user-workload-monitoring

   出力例

   Error from server (NotFound): configmaps "user-workload-monitoring-config" not found

5. ユーザーワークロードモニタリングの user-workload-monitoring-config ConfigMap オブジェクトを作成し、2_configure_user_workload_monitoring.yaml ファイル名に保存します。

   出力例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |

6. 2_configure_user_workload_monitoring.yaml ファイルを適用します。

   $ oc apply -f 2_configure_user_workload_monitoring.yaml
   configmap/user-workload-monitoring-config created

手順

1. openshift-adp-velero-metrics-svc サービスが存在することを確認します。これには、ServiceMonitor オブジェクトのセレクターとして使用される app.kubernetes.io/name=velero ラベルが含まれている必要があります。

   $ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero

   出力例

   NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
   openshift-adp-velero-metrics-svc   ClusterIP   172.30.38.244   <none>        8085/TCP   1h

2. 既存のサービスラベルと一致する ServiceMonitor YAML ファイルを作成し、そのファイルを 3_create_oadp_service_monitor.yaml として保存します。サービスモニターは openshift-adp-velero-metrics-svc サービスが存在する openshift-adp namespace に作成されます。

   ServiceMonitor オブジェクトの例

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     labels:
       app: oadp-service-monitor
     name: oadp-service-monitor
     namespace: openshift-adp
   spec:
     endpoints:
     - interval: 30s
       path: /metrics
       targetPort: 8085
       scheme: http
     selector:
       matchLabels:
         app.kubernetes.io/name: "velero"

3. 3_create_oadp_service_monitor.yaml ファイルを適用します。

   $ oc apply -f 3_create_oadp_service_monitor.yaml

   出力例

   servicemonitor.monitoring.coreos.com/oadp-service-monitor created

手順

1. サンプル OADPBackupFailing アラートを含む PrometheusRule YAML ファイルを作成し、4_create_oadp_alert_rule.yaml として保存します。

   OADPBackupFailing アラートのサンプル

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: sample-oadp-alert
     namespace: openshift-adp
   spec:
     groups:
     - name: sample-oadp-backup-alert
       rules:
       - alert: OADPBackupFailing
         annotations:
           description: 'OADP had {{$value | humanize}} backup failures over the last 2 hours.'
           summary: OADP has issues creating backups
         expr: |
           increase(velero_backup_failure_total{job="openshift-adp-velero-metrics-svc"}[2h]) > 0
         for: 5m
         labels:
           severity: warning

   このサンプルでは、アラートは次の条件で表示されます。

   • 過去 2 時間に失敗した新しいバックアップの数が 0 より大きく増加しており、その状態が少なくとも 5 分間継続します。
   • 最初の増加時間が 5 分未満の場合、アラートは Pending 状態になり、その後、Firing 状態に変わります。

2. 4_create_oadp_alert_rule.yaml ファイルを適用して、openshift-adp namespace に PrometheusRule オブジェクトを作成します。

   $ oc apply -f 4_create_oadp_alert_rule.yaml

   出力例

   prometheusrule.monitoring.coreos.com/sample-oadp-alert created