Amazon EKS で EBS CSI ドライバーを使用するトポロジー対応ボリュームプロビジョニングを作成およびトラブルシューティングする方法を教えてください。

簡単な説明

Amazon EBS コンポーネントを使用する Amazon EKS のクラウドインフラストラクチャトポロジを設定してトラブルシューティングするには、次の手順を実行してください。

1. **EBS CSI ** アドオンが正しく設定されているか確認します。
2. トポロジー対応の実装でストレージクラスを構成します。
3. ポッドとワークロードを作成してから、トポロジー対応のシナリオをテストします。
4. EBS CSI コントローラーエラーのトラブルシューティングを行います。

解決策

**注意事項:**AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新の AWS CLI バージョンを使用しているかどうか確認してください。

EBS CSI アドオンが正しく設定されているか確認してください

注意事項:EBS ボリュームプロビジョニングには EBS CSI プロビジョナー ebs.csi.aws.com を使用するのがベストプラクティスです。また、トポロジー対応ボリュームを実装する場合は、ツリー内の Kubernetes プロビジョナーkubernetes.io/aws-ebsの代わりに EBS CSI プロビジョナーを使用してください。

EBS CSI アドオンが正しく設定されているか確認するには、次の手順を実行してください。

1.    CSI ドライバーがインストールされているか確認します。インストールされていない場合は、 Amazon EBS CSI ドライバーを参照して CSI ドライバーをインストールします。

2.    サービスアカウントの AWS ID およびアクセス管理 (IAM) ロールに最低限の EBS ボリュームアクション権限があるかを確認します。

**注意事項:**サービスアカウントには、サービスアカウントの IAM ロール (IRSA) を注釈する必要があります。サービスアカウントに IRSA という注釈を付けない場合、Amazon EBS CSI ドライバはデフォルトでワーカーノードの IAM ロールを引き継ぎます。CSI ドライバがデフォルトでワーカーノードの IAM ロールに設定されている場合は、AWS マネジメントコンソールで必要な IAM ロール権限を設定します。

トポロジー対応実装によるストレージクラスの設定

1.    次のコマンドを実行してストレージクラスをデプロイします。必要に応じて、特定のデプロイ要件に合わせてマニフェストを編集します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/storageclass.yaml

マニフェストの例:

**注意事項:**マニフェストの属性を、ユースケース固有の属性に置き換えてください。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

**注意事項:**トポロジー対応の実装では、必ず allowedTopologiesオプションを設定してください。このオプションを削除すると、正しいアベイラビリティーゾーンが推測され、Amazon EBS CSI コントローラーがポッドがスケジュールされているボリュームを作成します。

2.    PV クレームを作成するには、次のいずれかのオプションを使用してください。

**(オプション 1) **デプロイされたストレージクラスマニフェストで指定されているプロファイルタイプのボリュームをリクエストする pv-claim を作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/claim.yaml

(オプション 2) 永続ボリュームマニフェストで指定されている利用可能な EBS ボリュームを使用する pv-claim を作成します。オプション ** StorageClassName: ** を空の文字列、""、 に変更し、必要に応じてnodeAffinityブロックを変更してください。

kubectl apply -f https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning/manifests

**注意事項:**オプション 1 またはオプション 2 では、ボリュームのアベイラビリティーゾーンにノードがない場合、デプロイは失敗します。これは、スケジューラーがトポロジーの制限に動的に適応できないためです。

ポッドとワークロードを作成し、トポロジーを意識したシナリオをテストする

**ポッドの作成 **

1.    以前の pv-claim を使用するテストポッドを作成します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/pod.yaml

注意事項:****ストレージクラスまたは永続ボリューム内の ** AllowedTopologies で ** topology.ebs.csi.aws.com/zone を使用すると、ポッドは設定マニフェストで指定されているアベイラビリティーゾーンに配置されます。そのアベイラビリティーゾーンに利用可能なノードがない場合、ポッドは保留のままになります。

2.    以下の getおよびdescribe pod コマンドを実行して、デプロイメントのステータスを確認します。

kubectl get pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

**注意事項:****EXAMPLE\ _POD\ _NAME ** を自分のポッドの名前に置き換えてください。

ワークロードの作成

1.    次のコマンドを実行して、以前の pv-claim を使用する **statefulSet ** ワークロードを作成します。

kubectl apply -f https://gist.githubusercontent.com/AbeOwlu/b8641d2f58810789986ab775f00c7780/raw/9144ae5385dfd98d4739e99983346fbdd28eaa2d/statefulset.yaml

2.    次の get および describe コマンドを実行して、statefulSet ワークロードのステータスを確認します。

kubectl get statefulset,pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

注意事項:****statefulSet ** コントローラーは、AWS リージョン us-east-2b と us-east-2c のボリュームに対するポッドのボリュームリクエストに応えるために、いくつかの pv-claim を作成します。終了時のstatefulSets** が永続ボリュームをクリーンアップする保証はないため、別のアベイラビリティーゾーンに再スケジュールされた statefulSet ポッドにボリュームが再プロビジョニングされない可能性があります。

**トポロジーを意識したシナリオのテスト **

(オプション) 別のアベイラビリティーゾーンのノード交換がどのように処理されるかをテストするには、指定した AZ のノードをスケールダウンしてノードのリシャッフルをシミュレートします。次に、別の AZ の新しいノードをスケールアップします。完了したら、「ポッドの作成」 セクションと「ワークロードの作成」 セクションを参照してください。

デプロイ問題のシミュレートに関する出力例:

from: default-scheduler : message: 0/4 nodes are available: 1 node(s) had volume node affinity conflict, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.

スタックしたポッドを修正するには、指定したアベイラビリティーゾーンのノードを再度スケールアップして、ボリュームノードのアフィニティコンフリクトエラーを解決します。

**注意事項:予定されているアベイラビリティーゾーンで新しいノードをスケールアップする場合、リコンサイラーの実行が失敗したためにデプロイが失敗する可能性があります。トラブルシューティングの手順については、次のセクション「EBS CSI コントローラーエラーのトラブルシューティング」**を参照してください。

EBS CSI コントローラーエラーのトラブルシューティング

ポッドチャーンとノードリサイクルをシミュレートした EBS CSI エラーの例:

from: default-scheduler : message: 0/5 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate

1.    問題を特定するには、ポッドについて説明し、イベントのエラーログエントリを確認します。前述のエラー例では、5 つのノードのうちの 4 つは、ノードの汚染とトポロジーまたはアフィニティ構成が原因でスケジュールできないというメッセージが表示されています。また、正しいアベイラビリティーゾーンで実行されていた最後のノードは、バインドできる永続ボリュームを見つけられませんでした。

2.    この問題を切り分けるには、pv-claim バインドのステータスを確認してください。

kubectl describe persistentvolumeclaim <PVC_NAME>

**注意事項:**pv-claim のステータスは [待ち]、[バインド済み] 、[無効] 、または [見つかりません] です。次の例では、pv-claim はドライバーがボリュームを作成するのを待っています。待機中、pv-claim はターゲットノードにバインドされません。

`from: ebs.csi.aws.com_ebs-csi-controller- : message:  failed to get target node: node "ip-10-0-60-85.ec2.internal" not found`  
`waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator`

3.    ebs-csi-controllerポッドのcsi-provisionerコンテナログを確認してください。

kubectl logs ebs-csi-controller-<RANDOM_HASH> -c csi-provisioner -n kube-system

次の出力はエラーイベントの例です。

Retrying syncing claim "claim-id", failure 343 error syncing claim "claim-id": failed to get target node: node "ip-10-0-60-85.ec2.internal" not found

注意事項:前述のメッセージと同様のエラーイベントが発生した場合、pv-claim リコンサイラーは選択したターゲットノードアノテーションを見つけられませんでした。pv-claim が正常に同期できるように、このアノテーションを削除してください。

4.    選択したターゲットノードアノテーションを削除するには、次のコマンドを実行します。選択したノードのアノテーションを削除するには、必ず pv-claim マニフェストに出力をコピーして保存してください。

kubectl edit  persistentvolumeclaims ebs-claim | grep -v "volume.kubernetes.io/selected-node:"

上記のトラブルシューティング手順で問題が解決しない場合は、分離されたコンテナワークロードからログを収集し、AWS サポートに連絡してください。GitHub リポジトリで関連する問題を検索することもできます。