なぜ私は `UnresponsiveMountHelperContainerUtility` エラーFile Storage for VPC ?

仮想プライベートクラウド

ゾーン単位の dp2 プロファイル File Storage for VPC を使用して転送中暗号化（EIT）を実装したアプリが、 UnresponsiveMountHelperContainerUtility エラーにより失敗します。

EIT（転送中暗号化）を使用して、応答しないVPCファイルストレージシステムのトラブルシューティングを行います。

次のようなエラーメッセージが表示されます：

Code: UnresponsiveMountHelperContainerUtility,
Description: Failed to mount target because unable to make connection to mount helper container service.,
BackendError: Failed to send EIT based request. Failed with error:
  Post "http://unix/api/mount": dial unix /var/lib/ibmshare.sock: connect: no such file or directory,
Action: Check if EIT is enabled from storage operator.
  Run command 'kubectl edit configmap addon-vpc-file-csi-driver-configmap -n kube-system'
  and set 'ENABLE_EIT' flag to 'true'.

ワーカープールでEITが有効になっていないか、アプリのポッドがEITが有効になっていないワーカープールのノードにスケジューリングされているかのいずれかです。以下の条件のいずれかが満たされる：

ENABLE_EIT configmap内の false または EIT_ENABLED_WORKER_POOLS が空になっている。
ポッドが実行されているワーカープールが、 EIT_ENABLED_WORKER_POOLS に一覧表示されていません。
RHCOSのワーカーノードでは、EITパッケージはインストールされていますが、それらを有効にするための再起動はまだ行われていません。
RHCOSのワーカーノードにおいて、以前のアンインストールと再インストールのサイクルが、その間に再起動を行わずに実行されたため、パッケージが「すでにレイヤー化済み」という破損した状態のまま残ってしまいました。

問題の解決

原因を特定し、解決するには、以下の手順を実行してください。

EITが有効になっているノードを確認する

file-csi-driver-status のコンフィグマップを確認し、どのノードに EIT パッケージがインストールされているかを確認するとともに、設定に誤りがないかを確認してください。

status configmap について説明し、どのノードで EIT が有効になっているかを確認してください。「 EIT_ENABLED_WORKER_NODES 」キーを探してください。このキーには、ワーカープールの名前と、EITのインストールが完了したノードのIPアドレスが一覧表示されています。
```
oc describe cm file-csi-driver-status -n kube-system
```
出力例:
```
EIT_ENABLED_WORKER_NODES:
----
default:
- 10.240.0.89
- 10.240.0.87
- 10.240.0.88
```
値が空の場合は、まだどのノードにもEITが導入されていないことを意味します。
ENABLE_EIT が true に設定されていること、および対象のワーカープールが EIT_ENABLED_WORKER_POOLS にリストされていることを確認してください。
```
oc describe cm addon-vpc-file-csi-driver-configmap -n kube-system
```

EITが有効になっているノード上で、アプリのPodが実行されていることを確認してください

各ポッドを一覧表示して、どのノードにスケジューリングされているかを確認し、前のセクションの一覧と照らし合わせて確認してください。

所有しているポッドの一覧を作成し、各ポッドが実行されているノードのIPアドレスを記録してください。
```
oc get pods -A -o wide
```
ステップ1で作成した EIT_ENABLED_WORKER_NODES リストと、ノードのIPアドレスを照合してください。ポッドが、そのリストに含まれていないノード上にある場合は、次のいずれかの操作を行ってください：
- ノードセレクタまたはアフィニティルールを使用して、ポッドをEIT対応ノードに移動します。
- そのノードを含むワーカープールを、ConfigMap内の EIT_ENABLED_WORKER_POOLS に追加し、オペレーターによる再調整が完了するのを待ちます。

OSごとの考慮事項

必要なパッケージのインストール方法は、ワーカーノードのオペレーティングシステムによって異なります。

Ubuntu およびRHEL

リブートは不要です。パッケージはインストール後、直ちに有効になります。ノードのIPアドレスが EIT_ENABLED_WORKER_NODES に表示されており、かつポッドがそのノード上にある場合、EITは正常に動作するはずです。それでもソケットが見つからない場合は、ストレージオペレーターのPodログを確認し、インストールエラーがないか確認してください。

oc logs -n kube-system -l app=ibm-vpc-file-csi-operator --tail=100

RHCOS / CoreOS

RHCOSは不変のオペレーティングシステムです。ノードのIPアドレスがすでに EIT_ENABLED_WORKER_NODES に表示されている場合でも、 ノードを再起動するまでパッケージは有効になりません。

Node 「EIT対応」と表示されるが、マウントは依然として失敗する

EIT_ENABLED_WORKER_NODES にノードの IP アドレスが記載されているにもかかわらず、「 UnresponsiveMountHelperContainerUtility 」というエラーが表示される場合は、パッケージのインストール以降、そのノードが再起動されていないことを意味します。 /var/lib/ibmshare.sock ソケットは、再起動が終わるまでは存在しません。

再起動が保留中であることを確認するには、影響を受けるノードで次のコマンドを実行してください：

OpenShift CLI を使用して、問題が発生しているノードでデバッグシェルを開きます。
```
oc debug node/<nodeName>
```
デバッグシェル内で、EITパッケージがステージング済みであるが、まだアクティブになっていないかどうかを確認してください。
```
chroot /host
rpm-ostree status
```
出力結果の中から、「 mount-helper 」および「 mount-helper-container 」が記載されている、保留中またはステージング中のレイヤーを探してください。パッケージが「 (booted) 」とマークされていないレイヤーに表示されている場合、それらを有効にするには再起動が必要です。

次回の起動に向けてステージングされたパッケージを示す出力例：
```
State: idle
Deployments:
  ● ostree-unverified-registry:...
    ...
    LayeredPackages: mount-helper mount-helper-container
  ostree-unverified-registry:...  (booted)
    ...
```

この問題を解決するには、実行中のワークロードへの影響を避けるため、影響を受けている RHCOS ノードのデータをすべて排出してから再起動してください。

EIT_ENABLED_WORKER_NODES に記載されているノードの IP アドレスと照合して、各ノードのワーカー ID を特定してください。
```
ibmcloud ks workers --cluster CLUSTER_ID
```
再起動の前に、ノードをドレインして、実行中のすべてのポッドを安全に終了させます。
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

電源が切れたノードを再起動してください。

ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID

ノードがオンラインに戻り、「 Ready 」状態になったら、アンコードン処理を実行して、そのノード上で再びワークロードがスケジューリングされるようにします。
```
oc uncordon <node-name>
```

RHCOS上で、「already layered」というエラーが発生し、ジョブのインストールに失敗する

以前にRHCOSワーカープールでEITをアンインストールした後、その間にノードを再起動せずにEITを再度有効にした場合、ストレージオペレーターのインストールジョブが、次のようなエラーで失敗する可能性があります：

error: Packages are already layered: mount-helper-<version>.rpm mount-helper-container-<version>.rpm

これは、 rpm-ostree uninstall が削除をステージングするだけだからです。再起動が行われるまでは、これらのパッケージは現在のブートレイヤーに残ったままになります。オペレーターが rpm-ostree install を再度実行しようとすると、パッケージはすでにインストール済みとして認識されます。

この問題を解決するには：

再起動の前に、ノードをドレインして、実行中のすべてのポッドを安全に終了させます。
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```
保留中のアンインストールを適用するには、RHCOSノードを再起動してください。
```
ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID
```
ノードがオンラインに戻り、「 Ready 」状態になったら、アンコードン処理を実行して、そのノード上で再びワークロードがスケジューリングされるようにします。
```
oc uncordon <node-name>
```
ノードがオンラインに戻った後、以前にインストールされていたパッケージは消えてしまいます。ストレージ運用担当者は、次の照合サイクルで自動的にそれらを再インストールします。通常、この処理は数分以内に完了します。
EIT_ENABLED_WORKER_NODES でオペレーターがノードの EIT 対応を報告した後、ノードのデータを完全に削除して再起動し、新しくインストールされたパッケージを有効にしてから、Cordon を解除してください。

RHCOSのアンインストールから再インストールまでの完全な手順は、次のとおりです。アンインストール後に再起動 → オペレーターによる再インストール → 有効化のために再度再起動。

EIT対応のワーカープールに新しいノードが追加されました

EIT_ENABLED_WORKER_POOLS にすでに登録されているワーカープールに新しいノードが参加すると、ストレージオペレーターは、次の調整サイクル中にその新しいノードに EIT パッケージを自動的にインストールします。コンフィグマップの更新は必要ありません。

RHCOS ノードの場合、EIT が有効になるには、インストール後にノードのデータを完全に削除して再起動する必要があります。稼働中のワークロードへの影響を最小限に抑えるため、ノードのデータを排出してから再起動し、その後、接続を解除してください。ノードが再起動されるまで、EIT対応のPVCを使用し、その新しいノードにスケジューリングされたポッドはすべて、同じ「 UnresponsiveMountHelperContainerUtility 」エラーが発生します。 Ubuntu (IKS) および RHEL (ROKS) ノードでは、新しいノードを追加する際に再起動は必要ありません。

なぜ私は UnresponsiveMountHelperContainerUtility エラーFile Storage for VPC ?