この記事は、AKS Arc のストレージ関連の問題のトラブルシューティングと解決に役立ちます。
永続ボリューム要求を構成すると、"エージェントを初期化できません。 エラー: mkdir /var/log/agent: アクセス許可が拒否されました"
この権限拒否エラーは、既定のストレージ クラスがワークロードに適していない可能性があることを示しており、Kubernetes バージョン 1.19.x 以降で実行されている Linux ワークロードで発生します。 セキュリティのベスト プラクティスに従って、多くの Linux ワークロードでポッドに securityContext fsGroup
の設定が指定されています。 既定のストレージ クラスでは パラメーターが指定 fstype (=ext4)
されていないため、AKS on Azure Stack HCI でワークロードを開始できません。そのため、Kubernetes はワークロードによって要求された に基づいて fsGroup
ファイルと永続ボリュームの所有権を変更できません。
この問題を解決するには、PVC のプロビジョニングに使用できるカスタム ストレージ クラスを定義します。
コンテナー ストレージ インターフェイス ポッドが "ContainerCreating" 状態でスタックしている
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 ポッドやデプロイなどを開始できません。
重要
この問題は、2022 年 4 月から 2023 年 3 月までのリリースで 2023 年 4 月 18 日以降に作成されたすべての新しい Mariner 管理ノードとターゲット クラスター ノードに影響する可能性があります。 この問題は、2023-05-09 リリース以降で修正されています。
この問題は、ディスク領域の割り当てや新しいファイルの書き込みを伴う操作に影響を与える可能性があるため、"ディスク領域/リソースの不足" エラーが適切なヒントです。 この問題が特定のノードに存在する場合にチェックするには、次のシェル コマンドを実行します。
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 ノードごとに次の手順を実行します。
次のシェル コマンドを使用して Geneva エージェントをオフにします。
sudo systemctl disable --now mdsd
Geneva エージェントが正常に無効になっていることを確認します。
sudo systemctl status mdsd
次のコマンドを使用して、蓄積されたファイルを削除します。
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
ノードを再起動します。
sudo reboot
ストレージ ポッドがクラッシュし、ログに 'createSubDir' パラメーターが無効であることが示されている
デプロイに SMB または NFS CSI ドライバーがインストールされていて、古いバージョンから 5 月のビルドにアップグレードすると、エラーが発生する可能性があります。 と呼ばれる createSubDir
パラメーターの 1 つが受け入れられなくなりました。 これがデプロイに適用される場合は、次の手順に従ってストレージ クラスのエラーを解決します。
このエラーが発生すると、ストレージ ポッドがクラッシュし、ログに createSubDir
パラメーターが無効であることが示されます。
ストレージ クラスを再作成します。
永続ボリュームを作成するときに、ボリュームをマウントしようとして失敗する
AKS Arc 環境で永続ボリュームまたは永続ボリューム要求を削除すると、同じ共有にマップするために新しい永続ボリュームが作成されます。 ただし、ボリュームをマウントしようとすると、マウントは失敗し、ポッドが NewSmbGlobalMapping failed
エラーでタイムアウトします。
新しいボリュームをマウントできない問題を回避するには、Windows ノードに SSH で接続し、Remove-SMBGlobalMapping
を実行して、ボリュームに対応する共有を指定します。 このコマンドを実行すると、ボリュームのマウント試行が成功します。