次の方法で共有

正常なノードの準備ができていない状態のトラブルシューティング

  • [アーティクル]

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

前提条件

現象

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

kubectl describe nodes

原因

kubelet は準備完了状態の投稿を停止しました。

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

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

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

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

すべてのクラスター ノードが [準備ができていない] 状態に後退した場合は、ネットワーク レベルで変更が発生したかどうかをチェックします。 ネットワーク レベルの変更の例には、次のものが含まれます。

  • ドメイン ネーム システム (DNS) の変更
  • ファイアウォール ポートの変更
  • ネットワーク セキュリティ グループ (NSG) を追加しました

ネットワーク レベルで変更があった場合は、必要な修正を行います。 問題を修正した後、実行されているノードを停止して再起動します。 これらの修正後もノードが正常な状態のままである場合は、残りの手順を安全にスキップできます。

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

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

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

診断で基になる問題が検出されない場合は、残りの手順を安全にスキップできます。

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

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

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

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

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

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

  • 余分な送信 IP アドレスと割り当てられた送信ポートを使用して、SNAT ポートの枯渇を軽減する必要があるかどうかを評価します。 詳細については、「 マネージド送信パブリック IP の数をスケーリングする 」および 「割り当てられた送信ポートを構成する」を参照してください。

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

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

  • 仮想マシン (VM) スケール セットで IOPS を増やすには、新しいノード プールをデプロイしてディスク サイズを変更します。

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

  • エフェメラル OS の使用を検討してください。

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

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

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

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

  • ノードの状態は [準備ができていません] に変わりますが、修復子によって再起動され、復旧できます。

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

    pthread_create失敗: さまざまなプロセスでリソースを一時的に使用できない

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

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

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

代わりに、問題のあるアプリケーションを特定し、適切なアクションを実行します。 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. パラメーターを使用して、kubelet 内のポッドで許可される PID の最大数を --pod-max-pids 構成します。 この構成では、各ポッドの pids.max cgroup 内の設定を設定します。 および パラメーターを--system-reserved--kube-reserved使用して、それぞれシステムと kubelet の制限を構成することもできます。

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

注:

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

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

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

詳細