クラウドネイティブ導入2年間で運用と開発で遭遇した6つの落とし穴

1運用・保守側からの教訓

運用保守側の中心的な目標は、Kubernetes クラスターの安定性を確保することです。 Kubernetes クラスターを構築する過程で、2 つの重大な問題が発生しました。 1 つはコンテナ内でのゾンビプロセスの生成であり、もう 1 つはカーネルのバグによって Kubelet 負荷が急増したことです。

1.1コンテナがゾンビプロセスを生成する

ウェブターミナルのゾンビプロセスは、長い間私たちを悩ませてきた問題です。開発者がポッドを再起動すると、クラスター内に Not Ready ステータスのノードが時々あることがわかります。これは非常に奇妙で不可解です。その後、Bash プロセスが多すぎると containerd-shim のバグが発生することが判明しました。問題の原因と結果を一緒に分析しましょう。

問題の説明

クラスターの通常の運用中、運用および保守担当者は、クラスターノードから定期的に Not Ready アラームを受信します。準備完了でない状態が一定期間続くと、Kubernetes クラスターは自動的に保護メカニズムをトリガーし、サービスの高可用性を維持するためにマシン全体を移行します。

ノードのステータスが「準備ができていません」に変わる理由は多数あります。調査の結果、ノード上に終了状態のポッドがいくつかあり、そのステータスが「準備ができていない」に変わっていることがわかりました。これらのポッドのステータスは終了中のままであり、正常に終了することはできません。同時に、Node 上で docker ps コマンドを実行すると、コマンドが正常に出力できず、Docker が結果を返すのを待っていることがわかります。 Kubelet はコンテナの状態を検出するために Docker 関連のコマンドにも依存しているため、Kubelet 内のヘルスチェックがタイムアウトし、ノードの状態が Not Ready としてマークされます。 docker ps コマンドが停止するのはなぜですか?さらに調査を進めたところ、問題のあるすべてのノードにゾンビプロセスが存在し、これらのゾンビプロセスは継続的に終了状態にあるポッドによって作成されたことが判明しました。

原因

開発者がコンテナログをリアルタイムでデバッグおよび表示できるように、パブリッシングプラットフォームでは Web ターミナル機能が提供されており、R&D 担当者はブラウザーでコンテナに直接アクセスし、さまざまなコマンドを実行できます。

Web ターミナルは、WebSocket テクノロジーを通じてバックエンドサービスに接続します。バックエンドサービスは、API Server が提供する exec API (client-go を通じて実装) を呼び出し、コンテナ内で Bash プロセスを起動し、Bash プロセスの標準入力ストリームと標準出力ストリームを WebSocket に接続することで、最終的に Web テクノロジに基づくターミナルを実現します。

問題は Bash プロセスにあります。図 17-1 に示すように、プロセスはコンテナの親プロセス (Pid 0) から派生したものではなく、containerd-shim から派生したものなので、コンテナがシャットダウンされると、Bash プロセスはコンテナの親プロセスから送信された終了信号を受信できません。 Kubelet が containerd-shim に通知するのを待つ必要があり、containerd-shim はコンテナ内のすべてのプロセスに killall コマンドを送信し、これらのプロセスが終了するのを待ちます。

図17-1 Bashゾンビプロセスの概略図

このステップを実装する場合、containerd-shim は長さ 32 のブロッキングチャネル (Golang のデータ構造) を使用して、子プロセスの終了イベントをリッスンします。子プロセスが多数ある場合、トリガーされた終了イベントによってチャネル全体が満たされ、containerd-shim でデッドロックがトリガーされ、子プロセスが正しくリサイクルされなくなり、ゾンビプロセスが生成されます。 containerd-shim がデッドロックした後、Kubelet が docker inspect コマンドを実行してコンテナのステータスを確認すると、対応するスレッドが中断され、最終的にノードが Not Ready 状態になります。

解決

問題を特定した後、その問題を解決するための重要なアイデアは、containerd-shim の下で派生した子 Bash プロセスの数を減らすことです。この問題は 4 つのステップで解決します。

Web 端末コードを最適化します。ユーザーがブラウザウィンドウを閉じた後 (WebSocket 接続が切断された後)、図 17-2 に示すように、CTRL+C と終了コマンドを Bash プロセスに送信することをシミュレートし、Bash プロセスがアクティブに終了するようにトリガーします。
Web ターミナルのタイムアウトを設定します。 Web ターミナルが 10 分間アイドル状態 (WebSocket でデータが送信されない) になると、自動的に終了するようにトリガーされます。
ユーザーが Vim などのターミナル入力ストリームを捕捉するコマンドを使用する場合、手順 1 の方法を使用して Bash プロセスを終了できなくなります。30 分以上存続している Bash プロセスをアクティブにクリーンアップするために、各ノードにスケジュールされたタスクを追加しました。
exec プローブの使用を避け、代わりに HTTP プローブを使用するようにしてください。 Exec プローブは containerd-shim の下に子プロセスも生成するため、子プロセスが多すぎる可能性が高くなります。

図17-2 exitコマンドによるターミナルプロセスの強制終了

1.2カーネルバグにより Kubelet の負荷が急増

問題の説明

テストフェーズでは、クラスターが一定期間実行された後、開発者が新しいアプリケーションをリリースすると、Pod の作成が非常に遅くなり、Web ターミナル接続がタイムアウトし、Prometheus データが頻繁に失われ、クラスターホストの CPU 負荷が急上昇することが判明しました。

問題分析

ポッド作成プロセスからトラブルシューティングを開始しました。 kubectl describe コマンドを使用して Pod 作成プロセスを表示したところ、Pod リソースオブジェクトの作成から特定のノードへのスケジュールまでの時間が非常に短く、スケジューラに問題がないことがわかりました。 Pod のスケジュールが完了した後、Kubelet がイメージをプルしてコンテナを作成するのに長い時間がかかります。 Kubelet に問題があると思われます。確認してみると、Kubelet が使用する CPU タイムスライスが時折 400% 程度に達し、システムコールが最大 40% と高い割合を占めていることがわかりました。次に、Kubelet の CPU パフォーマンスの分析を始めました。

GitHub にも同様の問題があります。https ://github.com/google/cadvisor/issues/1774

Red Hat もこのバグについて https://bugzilla.redhat.com/show_bug.cgi?id=1795049 で議論しています。

ブログ記事は非常に長く、要点は次のように要約されます。

Kubernetes クラスターでは、ネットワーク遅延が 100 ミリ秒まで上昇する可能性があります。これは、カーネルが (memcg_stat_show で) 非常に多くの作業を実行し、ネットワーク依存関係がソフトに中断されるためです。この記事の例は、私たちが遭遇したシナリオと似ています。

これは、cAdvisor が /sys/fs/cgroup/memory/memory.stat から監視データを取得するためです。

解決

シェルコマンドを使用して期間を確認します。継続時間が 1 秒以上、または 10 秒以上である場合は、現在のシステムカーネルに上記のバグがあると判断できます。
シェルコマンド /proc/sys/vm/drop_caches> を使用するとネットワーク遅延を削減できますが、これは一時的な解決策にすぎません。
Kubelet が cAdvisor を使用して Cgroup 情報を収集するのを無効にします。これにより、一部の監視データが失われます。
カーネルバージョンをアップグレードします。

このうち、解決策 1、2、3 は一時的な解決策です。カーネルバージョンをアップグレードするソリューション 4 を使用することをお勧めします。カーネルバージョンを 4.19.113-300.el7.x86_64 にアップグレードすると、この問題は回避されました。

開発側からの2つの教訓

運用・保守面での多くの落とし穴に加え、開発面でも多くの困難な問題に直面しました。

2.1運用上の問題（使用パターンや習慣の変化）

プラットフォーム推進の初期段階では、新プラットフォームは旧プラットフォームに比べてあらゆる面で大きく改善されていたものの、プラットフォームの推進は満足のいく成果を達成しませんでした。ここでの主な要因としては、開発習慣、移行コスト、新製品に対する信頼の欠如などが挙げられます。そのため、インフラチームは徹底的なユーザー調査と分析を行った後、主に技術的手段と人的手段という2つの側面からプラットフォームのプロモーションを積極的に展開することを決定しました。

技術面では、コードリポジトリのワンクリック移行や古いプラットフォームの構成ファイルのワンクリックホスティングなどの効率化ツールを提供し、ユーザーが古いプラットフォームから新しいプラットフォームに低コストで移行できるようにし、面倒な操作によるユーザーの忍耐力を無駄にしないようにします。

人事レベルでは、会社の各ビジネステクノロジーチームに専任の担当者が割り当てられ、作業を推進し、ビジネスチームがアプリケーション移行を段階的に進めるのを支援します。このステップは非効率的に思えるかもしれませんが、実際には非常にうまく機能します。人と人との間で直接コミュニケーションをとることで、ビジネスラインの技術チーム間で新しいプラットフォームに対する信頼を構築しやすくなります。いくつかのアプリケーションの移行を支援した後、その後の移行はすべて各事業ラインの研究開発担当者によって独立して実行されるため、実際の時間コストは高くありません。同時に、ビジネスラインの段階的な移行を支援するプロセスにおいて、ユーザーの視点から製品のインタラクション効果を観察することができます。このプロセスは、プラットフォーム内の多くの欠陥を見つけるのにも役立ち、プラットフォームのさらなる最適化を大幅に促進します。

2.2 IPホワイトリストアクセス制御

コンテナ化されたアプリケーションの展開の過程では、アクセス認証の問題を解決する際に IP ホワイトリストに過度に依存するなど、既存のアーキテクチャの不合理さも明らかになりました。 IP ホワイトリストは、初期段階ではニーズを満たす低コストの認証メカニズムですが、柔軟性に欠け、拡張性に欠けるなどの問題があります。たとえば、アップストリームアプリケーションのデプロイメントインスタンスが変更または拡張されたときに、ダウンストリームアプリケーションが IP ホワイトリストを時間内に変更できず、アクセス拒否が発生してオンライン障害が発生する可能性が高くなります。同時に、IP ホワイトリストは、特に IP がリサイクルされ、他のアプリケーションに再割り当てされる可能性があるため、十分に安全な認証メカニズムではありません。元の IP の認証が時間内にリサイクルされない場合、権限漏洩が発生する可能性があります。

アプリケーションがコンテナ化された後、ネイティブネットワークソリューションを直接使用するため、コンテナが再スケジュールされた後にコンテナの IP が変更され、IP ホワイトリスト認証メカニズムは使用できません。この目的のために、私たちは訪問者とサービスプロバイダーの両方から始めて、3段階の変革計画を策定しました。

最初の段階では、プロキシレイヤーが追加されます。アクセス側とサービスプロバイダーの間に Nginx プロキシサーバーを展開し、Kubernetes Ingress の IP アドレスをサービスプロバイダーのアップストリームクライアントアドレスとして使用し、アップストリームクライアントが Nginx の対応するドメイン名にアクセスするように構成しました。アクセスパーティが変更され、元のサービスプロバイダーのドメイン名がプロキシサーバーのドメイン名に置き換えられます。変換後、サービスプロバイダーの観点から観察される訪問者の IP は、プロキシサーバーの IP になります。このとき、プロキシサーバーの IP がサービスプロバイダーの IP ホワイトリストに設定されると、訪問者の IP がどのように変更されても、サービスプロバイダーの IP ホワイトリストによって制限されなくなります。

2 番目の段階は、サービスプロバイダーの変革を実現することです。実装の最初のフェーズが完了すると、アクセス側はコンテナ化の変革を達成しますが、サービスプロバイダー側にはセキュリティの抜け穴が残ります。新しく追加されたプロキシ層 IP が取得されれば、コンテナ化変換が完了したばかりのアプリケーションに偽装し、このアプリケーションとしてサービスプロバイダーを呼び出すことができます。第 2 フェーズでは、プロキシ層によってもたらされるセキュリティリスクに対抗するために、API キーや対称署名などの IP に依存しないアクセス制御メカニズムをサポートするようにサービスプロバイダーを変革する必要があります。

第三段階は、訪問側の変化です。サービスプロバイダーが IP に依存しないアクセス制御メカニズムを完成した後、アクセスパーティは新しいアクセス制御方法をサポートするために変更を加える必要があります。この時点で、訪問者はサービスプロバイダーのアドレスをプロキシサーバーからサービスプロバイダーの実際のアドレスに戻すことができます。検証期間が経過すると、アクセス側はプロキシサーバーの IP を IP ホワイトリストから削除し、最終的に変換計画全体を完了できます。

2.3スムーズなトラフィック移行

プラットフォーム推進の初期段階では、テストされた新しいアプリケーションに加えて、多数のアプリケーションが旧リリースプラットフォームからコンテナ化されたプラットフォームに移行されました。移行プロセス中は、ユーザーが古いプラットフォームから新しいプラットフォームにトラフィックをスムーズかつ段階的に移行できるように支援する必要があります。

Kubernetes Ingress IP を元の Nginx プロキシに追加し、一定期間グレースケールリリースを実行して、トラフィックの 100% が Kubernetes に移行されるまで、Kubernetes トラフィックの重みを徐々に増やしていきました。切り替えの初期段階では、DNS を直接調整するのではなく、次の Nginx 構成コードスニペットのように、ドメイン名のアップストリームクライアントに Ingress IP を追加します。

10.16.55.* セグメントはアプリケーションの元のサービスノードであり、10.216.15.96 と 10.216.15.196 は Ingress の IP アドレスです。ドメイン名のアップストリームクライアントに Ingress IP を追加すると、設定した重みパラメータに従ってトラフィックを複数のノードに均等に分散できます。 Ingress ノードの重み値を徐々に増やし、元のアプリケーションノードの重み値を 0 に減らすことで、一定期間実行した後、DNS 構成を Ingress に直接解決して、トラフィックの最終的な切り替えを完了できます。

切り替えプロセス中は、注意が必要な以下の問題があります。

移行プロセス中に新しい要件が開始されると、ビジネスラインの R&D は、新しいプラットフォームと古いプラットフォームの両方で同時にオンラインになる必要があります。元のプラットフォームのアプリケーションコードを更新することを忘れないでください。
プロキシの追加レイヤーが追加されるため、外部から観測されるコンテナの応答時間は実際の時間よりも長くなります。この場合、アプリケーション自体のパフォーマンス指標を観察し、古いプラットフォーム上のアプリケーションと比較する必要があります。
追加のプロキシレイヤーは、応答時間に影響を与えるだけでなく、追加の応答ログも記録します。つまり、アクセスは元の Nginx サーバーに 1 回記録され、Ingress サーバーに 1 回記録されます。移行プロセス中に、これらの統計エラーを完全に排除することは困難です。

2.4ブランチはオンラインになった後に削除する必要がありますか?

Aone Flow ブランチモデルは柔軟ですが、コードリポジトリに多数の短命ブランチが作成されます。定期的にクリーンアップする必要があるブランチには 2 種類あります。

1 つ目はリリースブランチです。機能ブランチがリリースブランチから分離されるたびに、図 17-3 に示すように、対応する環境のリリースブランチが再作成されます。

図17-3 機能ブランチを終了し、リリースブランチを再構築する

機能ブランチ (feature/001) が終了したら、新しいリリースブランチ (release/daily/20211105) を作成します。この時点で、古いリリースブランチ (release/daily/20211102) のライフサイクルは終了し、機能ブランチ (feature/002) の後続のコミットは新しいリリースブランチ (release/daily/20211105) にマージされます。この時点で、古いリリースブランチは安全に削除できます。

リリースブランチを削除しても通常はコードが失われることはありませんが、リリースブランチでコードマージの競合が解決されている場合は、マージの競合を解決するためのこの部分の作業を新しいリリースブランチで再度実行する必要があることに注意してください。以前に機能ブランチで競合を解決した場合は、再度解決する必要はありません。これは、ブランチの競合が発生した場合に機能ブランチで競合を解決することを推奨する理由でもあります。

クリーンアップする必要がある 2 番目のタイプのブランチは、機能ブランチです。機能ブランチが公式環境にリリースされ、トランクブランチにマージされた後、機能ブランチは削除可能としてマークできます。再構築後すぐに削除できるリリースブランチとは異なり、機能ブランチには遅延削除戦略を採用し、履歴で凍結された機能ブランチを毎週クリーンアップします。

起動された機能ブランチをすぐに削除してみませんか?これは、機能ブランチがメインブランチにマージされているにもかかわらず、オンラインになった後にコードにバグが見つかり、時間内に修正する必要がある可能性があるためです。現時点で最も効率的な方法は、バグが導入された機能ブランチのコードを修正し、すぐに回帰テストを実行してから、オンラインに戻って修正することです。ただし、機能ブランチが起動されると、そのステータスは凍結としてマークされ、オンラインに戻すことはできません。このとき、リリースプラットフォームは、凍結された機能ブランチをすばやくコピーし、オンライン修復用の新しいブランチを取得できます。機能ブランチをオンラインになった直後に削除すると、これは不可能になります。

Ziroom は、クラウドネイティブ実装の全プロセスを詳細に公式にレビューしました。これは、Shen Jian、Sun Xuan、Qiao Xinliang、Shi Haifeng を含む 17 人の専門家によって推奨されている、クラウドネイティブと DevOps の実践に関する標準的な読み物です。

追加の応答ログが記録されます。つまり、アクセスは元の Nginx サーバーに 1 回記録され、Ingress サーバーに 1 回記録されます。移行プロセス中に、これらの統計エラーを完全に排除することは困難です。