正常なノードの状態が [準備完了ではない] に変更された場合のトラブルシューティング

  • [アーティクル]

この記事では、ノードがしばらく正常な状態になった後に、Azure Kubernetes Service (AKS) クラスター ノードの状態が Not Ready に変わるシナリオについて説明します。 この記事では、特定の原因の概要を説明し、考えられる解決策を示します。

前提条件

現象

正常な状態 (実行中のすべてのサービス) を持つクラスター ノードの状態が、予期せず Not Ready に変わります。 ノードの状態を表示するには、次の kubectl describe コマンドを実行します。

kubectl describe nodes

原因

kubeletはReady状態の投稿を停止しました。

kubectl describe nodes コマンドの出力を調べて、Conditions フィールドと、Capacity および Allocatable ブロックを見つけます。 これらのフィールドの内容は期待どおりに表示されますか? (たとえば、 Conditions フィールドには、 message プロパティに "kubelet is post ready status" 文字列が含まれていますか?この場合、ノードに直接 Secure Shell (SSH) アクセス権がある場合は、最近のイベントを確認してエラーを理解してください。 /var/log/messages ファイル内を確認します。 または、次のシェル コマンドを実行して、kubelet とコンテナー デーモンのログ ファイルを生成します。

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

これらのコマンドを実行した後、メッセージとデーモン ログ ファイルでエラーの詳細を確認します。

ソリューション

手順 1: ネットワーク レベルの変更を確認する

すべてのクラスター ノードが 準備ができていません 状態に後退した場合は、ネットワーク レベルで変更が発生したかどうかを確認します。 ネットワーク レベルの変更の例を次に示します。

  • ドメイン ネーム システム (DNS)変更
  • ポート、完全修飾ドメイン名 (FQDN) などのファイアウォール規則の変更。
  • 追加されたネットワーク セキュリティ グループ (NSG)
  • AKS トラフィックのルート テーブル構成を適用または変更しました

ネットワーク レベルで変更があった場合は、必要な修正を行います。 ノードに直接 Secure Shell (SSH) アクセス権がある場合は、 curl または telnet コマンドを使用して、 AKS 送信要件への接続を確認。 問題を修正したら、ノードを停止して再起動します。 これらの修正後もノードが正常な状態のままである場合は、残りの手順を安全にスキップできます。

手順 2: ノードを停止して再起動する

少数のノードのみが 準備ができていない 状態に後退した場合は、ノードを停止して再起動するだけです。 このアクションだけでは、ノードが正常な状態に戻る可能性があります。 次に、 Azure Kubernetes Service 診断の概要 を確認して、次のような問題があるかどうかを確認します。

  • ノード 障害
  • 送信元ネットワーク アドレス変換 (SNAT)故障
  • ノードの 1 秒あたりの入出力操作 (IOPS) のパフォーマンスの問題
  • その他の問題

診断が基になる問題を検出せず、ノードが準備完了状態に戻った場合は、残りの手順を安全にスキップできます。

手順 3: パブリック AKS API クラスターの SNAT の問題を修正する

AKS 診断では、SNAT の問題が明らかになっていませんか? その場合は、必要に応じて、次のアクションの一部を実行します。

  • 接続が長時間アイドル状態のままかどうかを確認し、既定のアイドル タイムアウトに依存してポートを解放します。 接続がこの動作を示す場合は、既定のタイムアウトを 30 分から短縮する必要があります。

  • アプリケーションで送信接続を作成する方法を決定します。 たとえば、コード レビューやパケット キャプチャを使用していますか?

  • このアクティビティが想定される動作を表すのか、代わりにアプリケーションの動作が誤っていることを示しているかを判断します。 Azure Monitor でメトリックとログを使用して、調査結果を実証します。 たとえば、SNAT 接続メトリックとして Failed カテゴリを使用できます。

  • 適切なパターンに従っているかどうかを評価します。

  • 追加のアウトバウンドIPアドレスとより多くの割り当てられたアウトバウンドポートを使用してSNATポート枯渇を軽減すべきかどうかを評価してください。 詳細については、「マネージド送信パブリック IP の数をスケーリングする割り当てられた送信ポートを構成するを参照してください。

SNAT ポートの削除のトラブルシューティング方法の詳細については、「 AKS ノードでの SNAT ポート不足のトラブルシューティングを参照してください。

手順 4: IOPS パフォーマンスの問題を修正する

AKS 診断で IOPS パフォーマンスを低下させる問題が明らかになった場合は、必要に応じて次のアクションを実行します。

  • 仮想マシン (VM) スケール セットの IOPS を増やすには、新しいノード プールをデプロイすることで IOPS パフォーマンスを向上させる、より大きなディスク サイズを選択します。 VMSS の直接サイズ変更はサポートされていません。 ノード プールのサイズ変更の詳細については、「 Azure Kubernetes Service (AKS)でノード プールを使用する」を参照してください。

  • ノード SKU のサイズを増やして、より多くのメモリと CPU 処理能力を実現します。

  • Ephemeral OS の使用を検討してください。

  • ポッドの CPU とメモリの使用量を制限します。 これらの制限は、ノードの CPU 消費やメモリ不足の状況を防ぐのに役立ちます。

  • スケジュール トポロジメソッドを使用して、ノードを追加し、ノード間で負荷を分散します。 詳細については、「 Pod トポロジの拡散制約を参照してください。

手順 5: スレッドの問題を修正する

kubelets や containerd ランタイムなどの Kubernetes コンポーネントは スレッド処理に大きく依存し、新しいスレッドを定期的に生成します。 新しいスレッドの割り当てが失敗した場合、次のように、このエラーがサービスの準備に影響する可能性があります。

  • ノードの状態は Not Ready に変わりますが、修復によって再起動され、復旧できます。

  • /var/log/messages および /var/log/syslog ログ ファイルでは、次のエラー エントリが繰り返し発生します。

    pthread_create失敗: リソースは、さまざまなプロセスで一時的に使用できません

    引用されるプロセスには、コンテナー化され、場合によっては kubelet が含まれます。

  • pthread_createエラー エントリがログ ファイルに書き込まれた直後に、ノードの状態が Not Ready に変わります。

プロセス ID (PID) はスレッドを表します。 ポッドで使用できる PID の既定の数は、オペレーティング システムによって異なる場合があります。 ただし、既定の数値は少なくとも 32,768 です。 この量は、ほとんどの状況で十分な PID を超えています。 高い PID リソースに関する既知のアプリケーション要件はありますか。 そうでない場合は、8 倍の 262,144 個の PID まで増加しても、リソースの多いアプリケーションに対応するには不十分な場合があります。

代わりに、問題のあるアプリケーションを特定し、適切なアクションを実行します。 VM サイズの増加や AKS のアップグレードなど、他のオプションを検討してください。 これらのアクションは問題を一時的に軽減できますが、問題が再び表示されないという保証ではありません。

各コントロール グループ (cgroup) のスレッド数を監視し、上位 8 つの cgroup を出力するには、次のシェル コマンドを実行します。

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

詳細については、「 プロセス ID の制限と予約」を参照してください。

Kubernetes には、ノード レベルで PID 枯渇を管理するための 2 つの方法が用意されています。

  1. --pod-max-pids パラメーターを使用して、kubelet 内のポッドで許可される PID の最大数を構成します。 この構成では、各ポッドの cgroup 内の pids.max 設定を設定します。 --system-reservedパラメーターと --kube-reserved パラメーターを使用して、それぞれシステムと kubelet の制限を構成することもできます。

  2. PID ベースの削除を構成します。

Note

既定では、これらのメソッドはどちらも設定されていません。 さらに、現在、AKS ノード プールの Node 構成を使用してどちらの方法も構成することはできません。

手順 6: 上位のサービス レベルを使用する

より高いサービス レベルを使用して、AKS API サーバーの高可用性を確保できます。 詳細については、 Azure Kubernetes Service (AKS) アップタイム SLA を参照してください。

詳細