Kubernetes アプリケーションの問題に対する一般的なトラブルシューティングのアイデア

[[428799]]

この記事はWeChatの公開アカウント「Mingge's IT Essays」から転載したもので、著者はIT Minggeです。この記事を転載する場合は、Mingge の IT Essays 公開アカウントにご連絡ください。

みなさんこんにちは、ミン兄弟です！

この記事では、Kubernetes アプリケーションの問題に対する一般的なトラブルシューティングのアイデアを紹介し、そのような問題に対するオンライン トラブルシューティングの事例を共有し、読者の利益のためにその背後にある関連知識を要約します。お互いに励まし合いましょう！

1. 技術動向の背景

ビッグデータのさらなる発展における 1 つのトレンドは、ビッグデータとクラウド コンピューティングのさらなる統合 (最下層でストレージとコンピューティングを分離したアーキテクチャの優先、最下層でオブジェクト ストレージの優先など)、展開アーキテクチャでのハイブリッド クラウドとマルチクラウドのシナリオのサポート、クラウド コンピューティングの採用とクラウド ネイティブへの移行であることがわかっています。

基盤となる特定のテクノロジー スタックに対応して、さまざまな主流のビッグ データ プラットフォームと基盤となるビッグ データ コンポーネントが、Kubernetes と Docker に代表されるコンテナー シリーズのテクノロジー スタックをサポートし始めているという事実に反映されています。

したがって、ビッグデータ実践者は、スキル不足のためにビッグデータ関連の問題のトラブルシューティングに困ることがないよう、継続的にスキルセットを拡大し、Kubernetes と Docker の基本知識と一般的なコマンドを習得する必要があります。

技術的観点から見たビッグデータ産業の発展動向

ここでは、ビッグデータ プラットフォームにおける Docker コンテナ関連の障害のトラブルシューティングのケース スタディを共有し、読者の利益のために、このような問題の背後にある知識とトラブルシューティングのアイデアを紹介したいと思います。お互いに励まし合いましょう！

2 問題の症状

StarRing ビッグデータ プラットフォーム TDH では、Zookeeper サービスを正常に起動できません。 TDH では、各サービスは実際には k8s の制御下にある Docker コンテナ内で実行されていることがわかっています。 kubectl get pods -owide |grep -i zoo を実行すると、次の図に示すように、対応するポッドのステータスが CrashLoopBackOff であることがわかります。

ポッドクラッシュループバックオフ

3 舞台裏: CrashLoopBackOff とは何ですか?

ポッドは CrashloopBackOff 状態です。これは、ポッド内のコンテナが起動され、その後クラッシュし、その後自動的に再起動されましたが、再びクラッシュし、というように (起動、クラッシュ、起動、クラッシュ) というサイクルが繰り返されていることを意味します。

注: ポッド内のコンテナが自動的に再起動される理由は、実際には PodSpec の restartPolicy によって指定されます。デフォルトの構成項目は「常に」です。これは、障害発生後に自動的に再起動することを意味します。

• PodSpec には、ポッド内のすべてのコンテナに適用される Always、OnFailure、Never の値を持つ restartPolicy フィールドがあり、デフォルト値は Always です。
• restartPolicy は、同じノード上の kubelet によるコンテナの再起動のみを参照します (したがって、ポッドが別のノードで再スケジュールされると、再起動回数はリセットされます)。
• kubelet によって再起動された失敗したコンテナは、5 分を上限とする指数バックオフ遅延 (10 秒、20 秒、40 秒…) で再起動され、正常に実行されてから 10 分後にリセットされます。

4 舞台裏: CrashLoopBackOff エラーが発生するのはなぜですか?

ポッドの CrashLoopBackOff エラーは非常によく発生します。このエラーはさまざまな理由で発生する可能性があります。主な理由は次のとおりです。

• Kubernetes クラスターのデプロイメントに問題があります。
• ポッドまたはポッドの下のコンテナの一部のパラメータが正しく構成されていません。
• ポッド内のコンテナで実行されているアプリケーションは、複数回の再起動後も失敗した状態のままになります。

5 舞台裏: ポッド コンテナの基盤となるアプリケーションのトラブルシューティング方法

ポッド コンテナの下部で実行されているアプリケーションが失敗した場合、一般的なトラブルシューティングのアイデアは次のようになります。

• ステップ1: コマンドkubectl describe pod xxxを使用してポッドの詳細情報を取得します。
• ステップ2: kubectl logs xxx コマンドを使用して、ポッドコンテナの基盤となるアプリケーションのログを表示します。
• ステップ3: ポッドコンテナの基盤となるアプリケーションの他のログファイルをさらに取得して表示し、問題の原因をさらに詳しく調べます。

質問がある友達もいるかもしれません。上記の手順 2 と 3 はどちらも、ポッド コンテナーの基盤となるアプリケーションのログを表示することです。違いは何ですか?

実際、手順 2 と 3 では、最下層にあるアプリケーションの異なるログ ファイルが表示されます。基礎となる詳細は、Kubernetes のログ メカニズムと、ポッドの最下層にあるアプリケーションがログを書き込む場所に関連しています。

• kubectl logs は、コンテナの標準出力 stdout と標準エラー stderr のログをポッドの下部に表示します。
• アプリケーションによって他のファイルに書き込まれたログは、kubectl ログでは表示できません。ログ ファイルのパスを取得して自分で表示する必要があります。
• K8s では、アプリケーションがコンテナの標準出力 stdout と標準エラー stderr にログを書き込むことを推奨しています。
• コンテナ内のアプリケーションは、コンテナの標準出力 stdout と標準エラー stderr にログを直接書き込むことができます。
• コンテナ内のアプリケーションがコンテナの標準出力 stdout と標準エラー stderr にログを直接書き込むことができない、または書き込むのが不便な場合は、サイドカー モードを使用して、アプリケーションのコンテナが配置されているポッドに別のサイドカー コンテナをデプロイできます。サイドカー コンテナーは、アプリケーションのログ ファイルを読み取り、標準出力 stdout と標準エラー stderr に出力する役割を担います。
• 最下層では、k8s は各ノードで実行されている kubelet を通じてノード内のすべてのコンテナの stdout および stderr ログを収集し、それらを kubelet によって管理されるローカル ファイルに書き込みます。
• ユーザーが kubectl logs xx コマンドを実行すると、コマンドは最下層のコンテナの対応するノード上の kubelet を呼び出して、ログを取得するために管理しているローカル ログ ファイルを取得します。
• ユーザーは kubectl log xxx を使用してアプリケーション ログを取得します。これにより、k8s クラスター内の対応するノードにログインして対応するログを表示するという面倒な操作が省かれ、優れたトラバーサルが実現します。

追伸ここで説明するのは、k8s コンテナで実行されているアプリケーションのログです。アプリケーション ログに加えて、実際には、docker、kubelet、kube-proxy、kube-apiserver、kube-scheduler、etcd など、k8s クラスター全体のシステム コンポーネントのログが多数あります。

6. トラブルシューティングとレビュー

上記の一般的なトラブルシューティングのアイデアに従って、CrashLoopBackOff の問題のトラブルシューティング プロセスを確認しましょう。

6.1: トラブルシューティングの確認: kubeclt describe pod xxx コマンドを使用してポッドの詳細情報を取得します。

以下はコマンド出力の部分的なスクリーンショットです。出力のイベント部分から、ポッドがノードに正常に割り当てられ、イメージが正常にプルされ、コンテナが正常に作成されて起動されたが、コンテナ内のプログラムが実行に失敗し、最終的にポッドが BackOff 状態になったという情報を取得できます。

kubectl-describe-pod

このコマンドの詳細な出力は次のとおりです。

 kubectl はポッド zookeeper-server-license-7fbfc544fc-h8nn9 を記述します。
名前: zookeeper-server-license-7fbfc544fc-h8nn9
名前空間:デフォルト 
優先度: 0
優先度クラス名: <なし>
ノード: uf30-tdh3-regression/10.20.159.115
開始時間: 2021年10月11日(月) 16:56:30 +0800
ラベル: name =zookeeper-server-license
                    ポッドテンプレートハッシュ=3969710097
                    podConflictName=zookeeper サーバー ライセンス
注釈: <なし>
ステータス: 実行中
IP: 10.20.159.115
制御者: ReplicaSet/zookeeper-server-license-7fbfc544fc
コンテナ:
  動物園管理サーバライセンス:
    コンテナ ID: docker://0887c97ab185f1b004759e8c85b48631f511cb43088424190c3f27c715bb8414
    画像: transwarp/zookeeper:transwarp-6.0.2-final
    イメージ ID: docker-pullable://transwarp/zookeeper@sha256:19bf952dedc70a1d82ba9dd9217a2b7e34fc018561c2741d8f6065c0d87f8a10
    ポート: <なし>
    引数:
      ブート
      ライセンスノード
    状態: 終了
      理由: エラー
      終了コード: 1
      開始: 2021年10月11日(月) 17:12:09 +0800
      終了: 2021年10月11日(月) 17:12:10 +0800
最終状態: 終了
      理由: エラー
      終了コード: 1
      開始: 2021年10月11日(月) 17:07:07 +0800
      終了: 2021年10月11日(月) 17:07:08 +0800
    準備完了: False  
    再起動回数: 8
    環境：
      ZOOKEEPER_CONF_DIR: /etc/license/conf
    マウント:
      /etc/license/confからconf (rw)
      /etc/localtime タイムゾーンから(rw)
      /etc/tos/conf を tosから(rw)
      /etc/transwarp/confからtranswarphosts (rw)
      /usr/lib/transwarp/plugins プラグインから(rw)
      /var/license データから(rw)
      /var/log/license/ ログから(rw)
      /var/run/secrets/kubernetes.io/serviceaccountから デフォルト-token-g42jt (ro)
      mountbindからの/vdir (rw)
条件：
  タイプ ステータス
  初期化済み  
  準備完了  
  PodScheduled真  
ボリューム:
  データ：
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /var/license
    ホストパスタイプ:
  conf:
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /etc/license/conf
    ホストパスタイプ:
  ログ：
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /var/log/license/
    ホストパスタイプ:
  マウントバインド:
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /transwarp/mounts/license
    ホストパスタイプ:
  プラグイン:
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /usr/lib/transwarp/plugins
    ホストパスタイプ:
  タイムゾーン:
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /etc/localtime
    ホストパスタイプ:
  トランスワーフォスト:
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /etc/transwarp/conf
    ホストパスタイプ:
  利用規約:
    タイプ: HostPath (ベアホストディレクトリボリューム)
    パス: /etc/tos/conf
    ホストパスタイプ:
デフォルト-token-g42jt:
    タイプ: シークレット (シークレットが設定されたボリューム)
    シークレット名:デフォルト-token-g42jt
    オプション: false  
 QoS クラス: BestEffort
ノードセレクター: zookeeper-server-license= true  
許容範囲: node.kubernetes.io/ not -ready:NoExecuteが300 秒間有効
                 node.kubernetes.io/unreachable:NoExecute が300 秒間続く
イベント:
  タイプ 理由 年齢送信元 メッセージ
---- ------ ---- ---- -------  
  正常な SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「default-token-g42jt」のMountVolume.SetUp が成功しました 
  正常な SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「conf」のMountVolume.SetUp が成功しました 
  正常な SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「tos」のMountVolume.SetUp が成功しました 
  正常な SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「mountbind」のMountVolume.SetUp が成功しました 
  正常な SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「transwarphosts」のMountVolume.SetUp が成功しました 
  正常 SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「log」のMountVolume.SetUp が成功しました 
  正常な SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「plugin」のMountVolume.SetUp が成功しました 
  正常 SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「data」のMountVolume.SetUp が成功しました 
  正常な SuccessfulMountVolume 15m kubelet、uf30-tdh3-regressionボリューム「timezone」のMountVolume.SetUp が成功しました 
  通常スケジュール 15 分デフォルト-scheduler zookeeper-server-license-7fbfc544fc-h8nn9をuf30-tdh3-regressionに正常に割り当てました
  通常 15m をプルしました (15m で x3) kubelet、uf30-tdh3-regression イメージ「transwarp/zookeeper:transwarp-6.0.2-final」を正常にプルしました 
  通常 15m 作成 (15m で x3) kubelet、uf30-tdh3-regression コンテナ作成
  正常 15m 開始 (15m で x3) kubelet、uf30-tdh3-regression コンテナを開始
  通常のプル 15m (15m を超える x4) kubelet、uf30-tdh3-regression プル イメージ"transwarp/zookeeper:transwarp-6.0.2-final"  
  警告バックオフ 44 秒 (15 分で x70) kubelet、uf30-tdh3-regression バックオフ、失敗したコンテナの再起動

6.2 トラブルシューティングとレビュー: ポッドコンテナの基盤となるアプリケーションのログを表示するには、kubectl logs xxx コマンドを使用します。

次に、コマンド kubectl logs xxx を使用して、ポッド コンテナの基盤となるアプリケーションのログを表示し、問題の原因を特定します。このコマンドの出力は以下のようになります。

上の画像からわかるように、残念ながら、このコマンドの出力では問題の根本的な原因は明らかになりません。

基礎となるログ メカニズムの観点から、StarRing TDH の zk アプリケーションは標準出力 stdout と標準エラー stderr にログを印刷しないため、kubectl logs xxx は対応するログを表示できません。

さらに調査する必要があります。

6.3 トラブルシューティングとレビュー: ポッドコンテナの基盤となるアプリケーションの他のログファイルをさらに取得して表示し、問題の原因をさらに深く調べます。

問題をさらにトラブルシューティングするには、まず、ポッド コンテナーの基盤となるアプリケーションの他のログ ファイルのパスを取得する必要があります。

tdh はクローズドソースなので、アプリケーションのソースコードを表示することはできません。公式の顧客に連絡することなく、コマンド kubectl describe pod xxx を使用してポッドがマウントされているボリュームを表示し、パスを推測して検証し、特定のログ ファイルを取得できます。 (トラブルシューティングでは、大胆な推測と慎重な検証が重要です!)

コマンド出力の部分的なスクリーンショットは次のとおりです。パス /var/log/license がマウントされていることがわかります。

次に、ログ ファイル /var/log/license をチェックして、問題の原因をさらに詳しく調べます。このファイルはローカル ファイル システム内のファイルであり、表示するには対応するノードにログインする必要があることに注意してください。以下はログ ファイルの主要なスクリーンショットです。

ログから、問題の原因が判明しました。zk の下部にあるローカル ファイル システムに保存されているファイル /var/license/version-2/snapshot.70000007a が破損していたため、起動できませんでした。

 2021-10-11 17:07:08,330 エラー org.apache.zookeeper.server.persistence.Util: [myid:16] - [main:Util@239] -最終 取引は部分的でした。
 2021-10-11 17:07:08,331 エラー org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@453] - できません 負荷 データベース ディスク上
java.io.EOFException がjava.io.DataInputStream.readInt(DataInputStream.java:392)で発生しました

ログファイルの詳細は次のとおりです。

末尾 -50 /var/log/license/zookeeper.log
 2021-10-11 17:07:08,203 INFO org.apache.zookeeper.server.DatadirCleanupManager: [myid:16] - [main:DatadirCleanupManager@101] - パージタスクは 予定されていません。
 2021-10-11 17:07:08,212 INFO org.apache.zookeeper.server.quorum.QuorumPeerMain: [myid:16] - [main:QuorumPeerMain@127] - クォーラムピアを開始しています
2021-10-11 17:07:08,221 INFO org.apache.zookeeper.server.NIOServerCnxnFactory: [myid:16] - [main:NIOServerCnxnFactory@94] -ポート 0.0.0.0/0.0.0.0:2291にバインド
2021-10-11 17:07:08,235 INFO org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@913] - tickTimeが設定されました  9000まで
2021-10-11 17:07:08,235 INFO org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@933] - minSessionTimeoutが設定されました  -1に
2021-10-11 17:07:08,235 INFO org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@944] - maxSessionTimeoutが設定されました  -1に
2021-10-11 17:07:08,236 INFO org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@959] - initLimit が設定されました  10まで
2021-10-11 17:07:08,285 INFO org.apache.zookeeper.server.persistence.FileSnap: [myid:16] - [main:FileSnap@83] - スナップショット /var/license/version-2/snapshot.70000007a を読み込んでいます
2021-10-11 17:07:08,330 エラー org.apache.zookeeper.server.persistence.Util: [myid:16] - [main:Util@239] -最終 取引は部分的でした。
 2021-10-11 17:07:08,331 エラー org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@453] - できません 負荷 データベース ディスク上
EOF例外
java.io.DataInputStream.readInt(DataInputStream.java:392)で
org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)で
org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIteratorにあります。次へ(FileTxnLog.java:625)
 org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.init(FileTxnLog.java:529)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.<init>(FileTxnLog.java:504)で
org.apache.zookeeper.server.persistence.FileTxnLogにあります。読み取り(FileTxnLog.java:341)
 org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:132)で
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)で
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:417)で
org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:409)で
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:151)で
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)で
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)で
2021-10-11 17:07:08,332 エラー org.apache.zookeeper.server.quorum.QuorumPeerMain: [myid:16] - [main:QuorumPeerMain@89] - 予期しない例外が発生し、異常終了しました
java.lang.RuntimeException:クォーラム サーバーを実行できません
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:454)で
org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:409)で
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:151)で
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111)で
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)で
原因: java.io.EOFException
 java.io.DataInputStream.readInt(DataInputStream.java:392)で
org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)で
org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIteratorにあります。次へ(FileTxnLog.java:625)
 org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.init(FileTxnLog.java:529)で
org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.<init>(FileTxnLog.java:504)で
org.apache.zookeeper.server.persistence.FileTxnLogにあります。読み取り(FileTxnLog.java:341)
 org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:132)で
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)で
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:417)で
        ...さらに4件

7 問題解決

上記の一般的なトラブルシューティングのアイデアを通じて、ログをチェックし、問題の原因を見つけました。zk の下部にあるローカル ファイル システムに保存されているファイル /var/license/version-2/snapshot.70000007a が破損していたため、起動できませんでした。クラスターには複数の zk ノードがあり、他のノードの zk は正常に起動されているため、問題のあるノードの上記ディレクトリにあるデータファイルを削除し、ノードの zk を再起動することができます。再起動後、ノードの zk は他のノードからローカルにデータをコピーし、外部に正常にサービスを提供できるようになります。

zk の下部にあるローカル ファイル システムに保存されているファイルは、正常ノードと問題ノードで比較されます。スクリーンショットは次のとおりです。

良好なノード上のzkデータ

不良ノード上の zk データ

上記の方法によると、ディレクトリをクリアして zk を再起動すると、kubectl get pods でサービスが正常であることが示されます。スクリーンショットは次のとおりです。

修正後のポッドを取得する

注: 実際、zk はローカル データ ファイルをクリーンアップするためのシステム ツール zkCleanup.sh も提供しています。著者はこのツールを使用せず、問題のあるノードのローカル ファイルを手動でバックアップしてクリアしました。このツールを自分で試すことができます。

zkクリーンアップ

8 知識の要約

• ビッグデータ実践者は、スキル不足によりビッグデータ関連の問題のトラブルシューティングに圧倒されることがないよう、常にスキルセットを拡大し、Kubernetes と Docker の基本知識と一般的なコマンドを習得する必要があります。
• ポッドは CrashloopBackOff 状態です。これは、ポッド内のコンテナが起動され、その後クラッシュし、その後自動的に再起動したが再びクラッシュし、というように (起動、クラッシュ、起動、クラッシュ) というサイクルが繰り返されていることを意味します。
• ポッド コンテナの下部で実行されているアプリケーションが失敗した場合、一般的なトラブルシューティングのアイデアは次のようになります。

ステップ 1: kubectl describe pod xxx コマンドを使用して、ポッドに関する詳細情報を取得します。

ステップ 2: kubectl logs xxx コマンドを使用して、ポッド コンテナーの下部にあるアプリケーションのログを表示します。

ステップ 3: ポッド コンテナーの基盤となるアプリケーションの他のログ ファイルをさらに取得して表示し、問題の原因をさらに詳しく調べます。

• kubectl logs は、コンテナの標準出力 stdout と標準エラー stderr のログをポッドの下部に表示します。 kubectl logs は、アプリケーションによって他のファイルに書き込まれたログを表示できません。ログ ファイルのパスを取得して自分で表示する必要があります。
• K8s では、アプリケーションがコンテナの標準出力 stdout と標準エラー stderr にログを書き込むことを推奨しています。
• コンテナ内のアプリケーションは、コンテナの標準出力 stdout と標準エラー stderr にログを直接書き込むことができます。コンテナ内のアプリケーションがコンテナの標準出力 stdout と標準エラー stderr にログを直接書き込むことができない、または書き込むのが不便な場合は、サイドカー モードを使用して、アプリケーションのコンテナが配置されているポッドに別のサイドカー コンテナをデプロイできます。サイドカー コンテナーは、アプリケーションのログ ファイルを読み取り、標準出力 stdout と標準エラー stderr に出力する役割を担います。
• 最下層では、k8s は各ノードで実行されている kubelet を通じてノード内のすべてのコンテナの stdout および stderr ログを収集し、それらを kubelet によって管理されるローカル ファイルに書き込みます。
• ユーザーが kubectl logs xx コマンドを実行すると、コマンドは最下層のコンテナの対応するノード上の kubelet を呼び出して、ログを取得するために管理しているローカル ログ ファイルを取得します。
• ユーザーは kubectl log xxx を使用してアプリケーション ログを取得します。これにより、k8s クラスター内の対応するノードにログインして対応するログを表示するという面倒な操作が省かれ、非常に便利になります。
• 問題を解決するには、大胆な推測を行い、それを慎重に検証する必要があります。