Kubernetes トラブルシューティングの実践記録

テスト環境でクラスターアラームを受信したら、Kubernetes クラスターにログインしてトラブルシューティングを行います。

ポッドを表示

kube-system node2 上の calico ポッドに異常がないか確認します。

詳細情報を確認すると、node2 にストレージスペースがなく、cgroup がリークされていることがわかります。

ストレージを表示

サーバーのストレージ情報を表示するには、node2 にログインします。現在はまだ十分なスペースがあります。

クラスターが使用する分散ストレージは Ceph なので、Ceph クラスターのステータスを確認します。

Ceph の修正

現在、Ceph クラスターに異常があり、ノード 2 の cgroup リークが発生している可能性があります。Ceph クラスターを手動で修復します。

データの不整合とは、オブジェクトのサイズが正しくないか、回復後にレプリカでオブジェクトが失われることを意味します。データの不整合によりスクラブエラーが発生する可能性があります。

Ceph の保存プロセス中に、特別な理由により、オブジェクト情報のサイズが物理ディスク上の実際のサイズデータと一致しない場合があり、クリーンアップが失敗する可能性もあります。

図からわかるように、ページ番号 1.7c に問題があり、修復する必要があります。

ページの修正:

 ceph pg 修復 1.7c

修復後、しばらく待ってから再度確認し、Ceph クラスターが修復されたことを確認します。

ポッドの修復の実行

異常なポッドを削除します。コントローラーが存在するため、最新の Pod が再度プルアップされます。

ポッドを確認すると、以前と同じです。分析の結果、ノード 2 の cgroup が Ceph の異常によりリークされている可能性があることがわかりました。オンラインで検索して再コンパイルします。

Google で検索してみたところ、問題は基本的に https://github.com/rootsongjc/kubernetes-handbook/issues/313 にある問題と同じであることがわかりました。可能性のある存在は次のとおりです。

システムカーネルを確認すると、バージョンが低いことがわかります。

断層の再配置

最後に、runc ロジックはコンテナの起動時にコンテナの kmem アカウンティングをデフォルトでオンにするため、3.10 カーネルでリークが発生する可能性があります。

ここで問題を解決するには、スペースが残っていない状態でサーバーを再起動する必要があります。この問題は、一定期間内に大量の Pod を削除すると発生する可能性があります。

最初のアイデアは、将来のクラスター管理の概要では、ノードを削除してノードを再起動することでサーバーを修復できるというものです。

ノード2のメンテナンス

ノード2をスケジュール不可としてマークする

kubectl コルドン node02

ノード2のポッドを削除する

kubectl ドレイン node02 --delete-local-data --ignore-daemonsets --force

--delete-local-data ローカルデータを削除します。emptyDir も削除されます。
--ignore-daemonsets DeamonSet を無視します。そうでない場合、DeamonSet は削除後に自動的に再構築されます。
--force force パラメータがない場合、ノード上の ReplicationController、ReplicaSet、DaemonSet、StatefulSet、または Job のみが削除されます。 force パラメータを使用すると、すべての Pod が削除されます。

現在、基本ノード2のすべてのPodは削除されています。

デフォルトの移行と異なるのは、Pod が終了する前に再構築されることです。このときのサービス中断時間 = 再構築時間 + サービス起動時間 + 準備プローブ検出正常時間。 1/1 にサービスが正常に実行されるまでお待ちください。そのため、単一のコピーで移行する場合、サービスの終了は避けられません。

ノード02を再起動

再起動後、node02は修復されました。

node02を復元します。

node02 を復元し、通常どおりスケジュールします。