AKS Arc でストレージを管理するときの既知の問題とエラーを修正する

この権限拒否エラーは、既定のストレージ クラスがワークロードに適していない可能性があることを示しており、Kubernetes バージョン 1.19.x 以降で実行されている Linux ワークロードで発生します。 セキュリティのベスト プラクティスに従って、多くの Linux ワークロードでポッドに securityContext fsGroup の設定が指定されています。 既定のストレージ クラスでは パラメーターが指定 fstype (=ext4) されていないため、AKS on Azure Stack HCI でワークロードを開始できません。そのため、Kubernetes はワークロードによって要求された に基づいて fsGroup ファイルと永続ボリュームの所有権を変更できません。

この問題を解決するには、PVC のプロビジョニングに使用できるカスタム ストレージ クラスを定義します。

Kubernetes バージョン 1.16.10 で新しい Kubernetes ワークロード クラスターが作成され、1.16.15 に更新されました。 更新後、csi-msk8scsi-node-9x47m ポッドは ContainerCreating 状態でスタックし、kube-proxy-qqnkr ポッドは次の出力に示すように終了状態でスタックしました。

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m  

kubelet が不良状態で終了し、API サーバーとは通信できなくなったため、唯一の解決策は kubelet サービスを再起動することです。 再起動後、クラスターは実行中の状態になります。

作成されたクラッシュ ダンプ ログからディスク ストレージをいっぱいにすることができます。 これは、ジュネーブ エージェントクライアント証明書の有効期限が切れているためです。 症状は次のようになります。

• サービスの開始に失敗します。
• リソースが不足しているため、Kubernetes ポッドやデプロイなどを開始できません。

この問題は、ディスク領域の割り当てや新しいファイルの書き込みを伴う操作に影響を与える可能性があるため、"ディスク領域/リソースの不足" エラーが適切なヒントです。 この問題が特定のノードに存在する場合にチェックするには、次のシェル コマンドを実行します。

clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/

このコマンドは、診断ファイルによって消費されたストレージ領域を報告します。

根本原因

サービス エンドポイントに対する Geneva エージェントの認証に使用されるクライアント証明書の有効期限が切れた場合、エージェントがクラッシュし、クラッシュ ダンプが発生します。 エージェントのクラッシュ/再試行ループは、初回起動時に約 5 秒であり、タイムアウトはありません。 つまり、ノードのファイル システムに新しいファイル (約 330 MB) が数秒ごとに作成され、ディスク ストレージが迅速に消費される可能性があります。

対応策

推奨される軽減策は、更新された証明書を持つ最新リリースバージョン 1.10.18.10425 にアップグレードすることです。 これを行うには、AKS-HCI ホストを更新する前に、まず ワークロード クラスター を サポートされているマイナー バージョン に手動でアップグレードします。

AKS Arc リリースとすべての最新の AKS-HCI ニュースの詳細については、 AKS リリース ページを購読してください。

アップグレードがオプションでない場合は、 mdsd サービスをオフにすることができます。 Mariner ノードごとに次の手順を実行します。

1. 次のシェル コマンドを使用して Geneva エージェントをオフにします。

   sudo systemctl disable --now mdsd
   

2. Geneva エージェントが正常に無効になっていることを確認します。

   sudo systemctl status mdsd
   

3. 次のコマンドを使用して、蓄積されたファイルを削除します。

   sudo find /var/lib/systemd/coredump/ -type f -mmin +1 -exec rm -f {} \;
   sudo find /run/systemd/propagate -name 'systemd-coredump@*' -delete
   sudo journalctl --rotate && sudo journalctl --vacuum-size=500M
   

4. ノードを再起動します。

   sudo reboot
   

デプロイに SMB または NFS CSI ドライバーがインストールされていて、古いバージョンから 5 月のビルドにアップグレードすると、エラーが発生する可能性があります。 と呼ばれる createSubDirパラメーターの 1 つが受け入れられなくなりました。 これがデプロイに適用される場合は、次の手順に従ってストレージ クラスのエラーを解決します。

このエラーが発生すると、ストレージ ポッドがクラッシュし、ログに createSubDir パラメーターが無効であることが示されます。

ストレージ クラスを再作成します。

AKS Arc 環境で永続ボリュームまたは永続ボリューム要求を削除すると、同じ共有にマップするために新しい永続ボリュームが作成されます。 ただし、ボリュームをマウントしようとすると、マウントは失敗し、ポッドが NewSmbGlobalMapping failed エラーでタイムアウトします。

新しいボリュームをマウントできない問題を回避するには、Windows ノードに SSH で接続し、Remove-SMBGlobalMapping を実行して、ボリュームに対応する共有を指定します。 このコマンドを実行すると、ボリュームのマウント試行が成功します。

次の手順

• トラブルシューティングの概要
• Windows Admin Center の既知の問題