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

この権限拒否エラーは、既定のストレージ クラスがワークロードに適していない可能性があることを示しており、Kubernetes バージョン 1.19.x 以降で実行されている Linux ワークロードで発生します。 セキュリティのベスト プラクティスに従って、多くの Linux ワークロードでポッドに securityContext fsGroup の設定が指定されています。 既定のストレージ クラスでは fstype (=ext4) パラメーターが指定されていないため、Azure Local の AKS でワークロードを開始できません。そのため、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 サービスを再起動することです。 再起動後、クラスターは実行中の状態になります。

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

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

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

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

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

根本原因

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

対応策

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

AKS Arc リリースと Azure Local の最新の AKS ニュースの詳細については、 AKS リリース ページをサブスクライブしてください。

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

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

   sudo systemctl disable --now mdsd
   

2. ジュネーブ エージェントが正常に無効にされたことを確認します。

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

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

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

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

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

次のステップ

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