K8Sクラスタが1万規模に達したときに、アリババは、どのように、システムのパフォーマンスの問題のさまざまなコンポーネントを解決するには？

著者|アリクラウドプラットフォームコンテナ上級技術専門家（精神によって）Cengfanソング

この論文は、大量生産環境でアリババ着陸Kubernetes、クラスタサイズと対応するソリューションに遭遇する典型的な問題のプロセスを説明し、コンテンツは、いくつかの性能と安定性etcdの、KUBE-apiserverのKUBEコントローラを含んでいます強化は、これらの重要な機能強化がKubernetes内部アリババワンクラスタノードが2019年に滑らかキーリンクス618大きなプロモーションをサポートすることができます。

背景

アリババ最古のAIシステム（2013）が始まったことから、クラスタ管理システムは2018年包括的なアプリケーションKubernetesのアーキテクチャの進化のラウンドを受けた、この時期の話は非常にエキサイティングで、チャンスは一人であることをあなたにシェアを与えること。ここではコミュニティにし、企業内の包括的な勝利をKubernetesが、アプリケーションKubernetesに遭遇した問題の種類に注意の焦点になる、と私たちはキー何の最適化を行う理由を議論することはできないように、システムの進化の過程を無視します。

Alibabaの生産環境、何百万ものネットワーク全体のレベルで、より10K以上のアプリケーションのコンテナコンテナ、ホスト上で実行されているユニットの数十万人。Alibabaのコア電気事業支援サービスはダース、数十数千ノードの最大のクラスタをクラスタ化します。Kubernetes着陸過程で、規模の点で、このような大規模な生産レベルに適用Kubernetesする方法として、課題の多くに直面しました。

ローマは、クラスタ内のノード10Kと推定Kubernetesが、我々はクラスタアリの生産状況を組み合わせたボトルネックのパフォーマンスを、理解するために、一日にして成らず、規模に達すると予想されています。

• 20ワットのポッド
• 100ワットのオブジェクト

私たちは、コンテナを通じてKubemarkプロセスをより起動モード（50）、大規模なクラスタベースKubemarkシミュレーションプラットフォームを構築し、コンテナ200個の4cをシミュレートkubeletの10Kノードを使用しています。あなたが共通の負荷シミュレーションクラスタを実行すると、私たちは、このようなスケジュールの遅延ポッドなど、いくつかの基本的な操作を見つけることは驚異10Sは非常に不安定な状態でこのレベル、およびクラスタに達し、非常に高いです。

Kubernetesノードクラスタが10Kに達したとき、システムの様々な構成要素は、対応するパフォーマンスの問題を持っている、など。

1. etcdは、紙面の都合で同時にKubernetes保存された多数のオブジェクトを運ぶことができない、読み取りが多数発生し、レイテンシを書き、サービス拒否の状況を作成します。
2. APIサーバークエリポッド/ノードの遅延が非常に高く、同時クエリは、バックエンド・etcdのOOMに対処することができます。
3. コントローラは、最新の変更、より長い待ち時間の処理にAPIサーバーから時間的に知覚できない、例外が再起動を発生した場合に、復旧時間のサービスには数分かかります。
4. スケジューラ高遅延、低スループット、アリ・ビジネス日々の運用や保守のニーズに適応することができませんでしたが、極端なシーン大きなプロモーション状態をサポートすることはできません。

etcd改善

これらの問題に対処するために、あらゆる点でアリクラウドコンテナプラットフォームは、大規模Kubernetesシーンでパフォーマンスを向上させるために多大な努力をしました。

第etcdレベルは、データベースKubernetesストアオブジェクトとして、その影響はKubernetesクラスタの性能にとって重要です。

• 改善の最初のバージョンは、我々はデータがTAIRクラスタをダンプすることで、etcd etcdを格納したデータの量が増加します。しかし、このアプローチは、重大な欠点は、追加のTAIRクラスターでいる、データのセキュリティクラスタの運用および保守の複雑さを増す大きなチャレンジですが、そのデータモデルの整合性がいかだレプリケーショングループ、犠牲に基づくものではありませんデータのセキュリティ。

• 改善の第二のバージョンは、我々は、異なるタイプのオブジェクトによって異なるetcdクラスタAPIサーバーを格納します。内側から見Etcd、それは異なるデータディレクトリに対応し、それによって単一のクラスタに格納されたデータの量を減らす、異なるバックエンドetcdに異なるディレクトリによってルーティングされたデータは、スケーラビリティを向上etcd。

• 改善の3番目のバージョンは、我々はアルゴリズムの分散etcdページページbboltデシベル底のスケーラビリティに影響を与える重要な問題を内部原則etcdの実現を詳細に調べるとが見つかりました：etcd成長に格納されるデータの量、bboltとして、パフォーマンスが大幅に減少デシベルリニアサーチ「n個の連続したメモリページのページ長」インチ

この問題を解決するために、我々はsegregratedハッシュマップの、ハッシュマップの連続ページ・サイズが開始ページのid値としてキー、連続したページであるベースの空きページ管理アルゴリズムを設計しました。性能を大幅に向上、segregratedハッシュマップのアイドルを見つけるために、チェックしてこのページをO（1）を実現。ブロックが解除されると、新しいアルゴリズムが試行するとアドレスが隣接するページをマージし、segregratedハッシュマップを更新します。アルゴリズムのより詳細な分析はCNCFに掲載されているブログボーエンを見ることができます：

https://www.cncf.io/blog/2019/05/09/performance-optimization-of-etcd-in-web-scale-data-scenario/

この改良されたアルゴリズムを介して、我々は大幅にスケールetcd格納されたデータを向上100ギガバイトに推奨2ギガバイトから拡張記憶空間をetcdでき、読み、大幅な遅延の増加なしに書くこと。また、我々はまた、協力して、Googleのエンジニアがetcdいかだ学習者（飼育係の観測など）/完全同時読み取りおよびその他の機能、強化されたセキュリティを開発し、リード上のパフォーマンスデータを書き込みしています。これらの改善は、オープンソースコミュニティのバージョンがetcd 3.4でリリースされます貢献してきました。

APIサーバーの改善

効率的なノードのハートビート

Kubernetesクラスタでは、大きなコアの問題に拡散されるの影響を効果的にハートビート・ノードに対処する方法です。典型的な運用環境（非trival）において、kubelet 10Sはすべてのハートビートを報告し、各ハートビート要求の内容は、二つをもたらす15キロバイト（数十メートルミラーノードを含む、及びボリューム情報複数）に達します大きな問題：

1. ハートビート要求はetcdクラスタの10kのノードにノードオブジェクトを更新トリガ、トランザクションを生成します。これらのアップデートは、（変更履歴を記録しますetcd）のほぼ1ギガバイト/分を記録します。
2. APIサーバーCPUのオーバーヘッドのハートビート要求の高いCPUの消費量、ノードのノードが非常に大きい、シリアライズ/デシリアライズのオーバーヘッド多大は80％で占められAPIサーバーのCPU時間を超えています。

この問題を解決するために、Kubernetes新しい導入build-in Lease API 、密接つまり、画像上、ノードオブジェクトから分社情報心拍に関連しますLease 。もともとkubelet一度ターゲット・ノードにアップグレードするすべての10Sを更新：

1. 各リース10S更新されたオブジェクトは、生存オブジェクトリースの状態に応じかどうかを決定するために、ノード、ノードコントローラの生存可能な状態を示しました。
2. 互換性を考慮して、一回毎に60秒目標ノードを更新するために減少し、そのようなEviction_ _Manager等は、元の論理演算を追従し続けることができます。

のでLease 、オブジェクトが非常に小さいので、更新は、ノードオブジェクトを更新するコストよりもはるかに少ないです。このメカニズムを通じてkubernetesは、大幅にCPUのオーバーヘッドのAPIサーバーを低減するだけでなく、大幅にトランザクションログのetcd多数、数千ノードのスケールに1000年から延長し、そのサイズの成功を低減し、機能Kubernetes-1.14のコミュニティでデフォルトで有効にされています。

APIサーバーの負荷分散

パフォーマンスと可用性の考慮事項については、生産クラスタでは、多くの場合、複数のノードの高可用性クラスタをKubernetesを展開。複数のAPI Serverはバランスがとれていない場合、またはクラスタノードをアップグレードする際には、部分的に、特に再起動失敗の間しかし、高可用性クラスタの実際の動作では、負荷が発生することがあります。このクラスタは、もともと直面APIサーバーの配分の圧力の利用可能性によって計画された、多くの圧力に安定性をもたらしていますが、極端な場合には、すべての圧力が長いシステムでは、応答時間を結果として、ノードに戻ってきた、とさえストライキこれは、順番にノードアバランシェ崩壊の原因となります。

以下の図は、すべての圧力がAPI Serverの1つにヒットした場合のクラスタ内で、3つのノードのクラスタは、APIサーバーのアップグレードシミュレーションで測定された圧力を示し、CPUのオーバーヘッドは、その2つの他のノードよりもはるかに高いです。

負荷分散の問題を解決するため、自然のアイデアは、ロードバランサを高めることです。メインロードクラスタハートビート処理ノードでは、上記の説明で述べたように、我々はAPIサーバとkubeletの真ん中に増加LB、2つの典型的なアイデアがあります。

1. APIサーバー測定増加ポンド、ポンド、クラウド・ベンダーは、一般的に配信Kubernetesクラスタを接続しているすべてのkubeletsは、このモデルです。
2. 増加のポンド測定kubeletは、APIサーバーによって選択されたLB。

圧力環境の検証を測定することにより増加ポンドことが判明し、上記の問題を解決することはできません、我々は深さにKubernetes内の通信メカニズムを理解する必要があります。深い研究にKubernetesは、接続認証TLSオーバーヘッドを解決するために、Kubernetesクライアントは接続は、クライアントが、ほとんどの場合、同じTLSは下で作業しているウォッチャー「同じTLSで再接続しよう」ということを保証するための努力の多くを作ったことがわかりましたこの接続は、それがスイッチのAPIサーバーの再接続の結果として起きるを引き起こす可能性が場合にのみ例外が発生します。その結果、リアAPIサーバーに接続されているkubelet、基本的にスイッチングをロードしませんが発生したときに、私たちが見たものです。この問題を解決するために、我々は3つの側面に最適化されています：

1. APIサーバー：クライアントが信頼できるではないことを前提とし、要求が敗北し、オーバーロードさから身を守るために必要です。負荷は、送信、閾値自体を超えたときに409 - too many requests 後退通知クライアントと、それ自体の負荷は、クライアント接続要求が拒否さ閉じることによって、より高い閾値を超えた場合に、
2. クライアント：一定の期間では、頻繁に受け409 、定期的にAPIサーバーの完全な改造を切り替える接続を再確立接続切替APIサーバーを再確立しようとしたとき、
3. 運用・保守レベル、我々は持参し、ジッタへのアップグレード・プロセスを回避するためにmaxSurge = 3つの方法を設定することによって、APIサーバーをアップグレードします。

図の下部に示すモニターを左としてすばやく自動的に平衡状態に戻すことができる再起動つのノード（図ジッタ）を表示しながら、APIサーバーの拡張バージョンは、実質的に負荷分散を行うことができます。

リストウォッチ＆キャッシャ

リストウォッチはKubernetesサーバがクライアントと通信コア内の機構であり、情報は更新されたデータ内のすべてのオブジェクトをetcd etcdを見るために内部反射によってAPIサーバーを変更し、メモリに保存され、コントローラ/もクライアントをkubelets同様のメカニズムにより、データの変更をサブスクライブします。

リストウォッチのメカニズムが直面している中心的な問題は、そのデータを確保するためにどのようにクライアントとサーバー間の通信の切断は、グローバルバージョン番号がでKubernetesにインクリメントさ採択再接続、中に失われていない場合には、resourceVersion 達成すること。リフレクターの下に示されているように、これは、反射器は、現在のサーバのバージョンを知らせるデータの現在のバージョンに同期されている保存された（5）再配線すると、開始位置メモリ記録で過去のデータを必要に応じ最近の変更に基づいてサーバーのクライアントコンピューティング（7 ）。

それはすべての非常にシンプルで信頼性の高いように見えますが、...

内部的には、オブジェクトの各タイプは、名前の中に保存されているAPIサーバでstorage オブジェクト、例えば、そこに次のようになります。

1. ポッドストレージ
2. ノードストレージ
3. Configmapストレージ
4. ...

各タイプは、特定の遅れウォッチャーを（等シナリオを再試行）をサポートする限られた記憶キュー、最寄り変化記憶オブジェクトを有します。一般的に、種類のすべてのタイプのスペースは、バージョン番号をインクリメント共有（1、2、3、...、N）、すなわち、上記のように、PODオブジェクトのバージョン番号が連続保証しないだけの保証をインクリメントします。のみポッドの部分に関心のあるデータを同期させるためにクライアントリストウォッチ・メカニズムを使用する場合は上記のように、最も一般的kubeletと彼らの注意は、唯一の懸念のみkubeletグリーンポッド（2,5）、関連したポッドノード。

ストレージは、限られたキュー（FIFO）、更新ポッドキューなので、古い変更はキューから除去されます。かかわらず5が除去された後にクライアントがこの時間APIサーバ5と最小電流キューで決定することができない、再接続する場合、クライアントとの更新キューは、クライアントの進行は、RV = 5残っている場合の、上記のように（7かどうかをクライアントとの間に変更するために、知覚が必要）があるので、クライアントが返すtoo old version err すべてのデータクライアントの再リストをトリガします。この問題を解決するために、のKubernetes紹介Watch bookmark メカニズム：

ブックマークは、核となるアイデアをまとめたタイムリーな更新のための反射の必要性の内部バージョン番号を更新するキュークライアント認知必要がなかった場合でも、クライアントとサーバ間の「ハートビート」を維持することです。上記のように、適切なサーバに、クライアントへ= 12最新バージョンRVのバージョン番号に後ろように、クライアントサーバーをプッシュします。ブックマークは、（パフォーマンスに数回向上させるために）再同期再起動API Serverイベントは、元の3％まで低減することができる必要が、機能アリクラウドコンテナプラットフォームは、コミュニティKubernetes-1.15のバージョンにリリースされました。

キャッシャ＆インデックス

図に示すように、リストウォッチに加えて、他のクライアント・アクセス・モードは、直接クエリAPIサーバです。クライアントが複数のAPI Serverノード間で一貫性のあるデータを読み取ることを確実にするために、API Serverクライアントクエリは、データのetcdを取得することによってサポートされます。パフォーマンスの観点から、これが質問のカップルを提起します：

1. インデックスをサポートしていないことができ、クラスタポッド内のクエリ・ノードは、ポッドのすべてを取得する必要があり、コストが膨大です。
2. 単一のクエリ要求が多すぎるデータの要求 - 応答モデルetcdは、大量のメモリを消費するため、APIサーバ間のデータのクエリの量を制限し、通常は要求し、ページングモードを通じて大量のデータを完了するために、etcd問い合わせ、ページングは​​パフォーマンスが大幅に低下し、ラウンドトリップタイムをもたらします。
3. 一貫性を確保するために、API Serverクエリetcdが使用されQuorum read 、このクエリのコストは、クラスタレベルで、それが拡張することはできません。

この問題を解決するために、我々は、APIサーバとデータの連携の仕組みを設計し、以下のように、以下のようにクライアントがキャッシュAPIサーバー、原則を通じて一貫性のあるデータを取得できることを確認etcd、全体的なワークフローは次のとおりです。

1. T0クライアント照会APIサーバーでは、
2. APIサーバーの要求は、データのRVの@ T0の現在のバージョンを取得etcd。
3. データの進捗状況を更新し、リフレクターバージョンを待つAPIサーバーの要求は、RVの@ t0のに達しました。
4. ユーザの要求に応じてキャッシュを通じ。

そのような名前空間のノード名/キャッシュ応答によってインデックス付けラベルのためのサポートとして、ユーザが要求したときに、このアプローチは、モデルクライアント（約引数を所有することができます興味を持って）の一貫性を破壊しない、我々は、柔軟なクエリ機能を高めることができます。この増強は有意に典型的には、このようなクエリのような他の操作の効率として、0.3秒の元5Sから億の単位は（ノード名インデックスをトリガ）クラスタのサイズを小さくするノードを取得する時にノードを記述する、読み出しAPIサーバー要求処理能力を向上させますまた、我々は指数関数的に成長しました。

コントローラのフェイルオーバー

クラスタ生産の10Kノードは、ほぼ万人のオブジェクトとコントローラの店舗は、APIサーバーとデシリアライズのオーバーヘッドから取得したオブジェクトを無視することはできません、それは、コントローラが仕事を再開再起動するまで数分かかる場合がありますこれはアリババサイズの企業が受け入れられないです。システム可用性のコンポーネントのアップグレードの影響を低減するために、我々は以下に示すようにプログラムを通じてこの問題を解決するために、ここで、単一のシステム停止時間のためのコントローラのアップグレードを削減しようとする必要があります。

1. データコントローラが予め必要とされるロード、スタンバイ制御情報提供を事前に開始。
2. メインコントローラがアップグレードすると、すぐに仕事を引き継ぐために準備をトリガー、リーダーリースを解放するためのイニシアチブを取るでしょう。

このプログラムを通じて、私たちは、ちょうどリーダーのリースを待って準備異常なダウンタイムは、（デフォルトの15S）の有効期限が切れた場合でも、セカンドレベル（<2Sアップグレード）にデータを再同期するために数分かかるする必要が時間割り込みコントローラを減らしません。パフォーマンスへの影響コントローラーのAPIサーバーの復旧を削減しながら、この機能拡張により、大幅に、コントローラのMTTRを低減します。プログラムはまた、スケジューラに適用されます。

カスタマイズされたスケジューラ

歴史的な理由に、アリババのスケジューラは、拡張スケジューラ]セクションを展開していなかったので、シェアとの関係、今回のアーキテクチャの自習を使用しています。以下に示すようにここだけは、2つの基本的な考え方を共有します：

1. 等価クラス：典型的なユーザ要求の拡張が一次容量拡大容器が複数である、我々は、等価クラス、バッチ処理に分割して、キューに保留中の要求、述語/優先順位の数を大幅に削減します。
2. リラックスしたランダム化は、単一のスケジューリング要求の場合は、クラスタ内の候補ノードが非常に大きい場合、我々は解決精度を犠牲にして（その後の処理スケジュールを入力するために十分なノードに選択した後、クラスタ内のすべてのノードを評価する必要はありません。スケジューリングのパフォーマンスを向上させます）。

概要

アリババは、機能強化と最適化の一連の、Kubernetesが正常に含め、本番環境に適用され、シングルノードクラスタに10000大規模を実現します。

1. 最後に、インデックスおよびデータ分離、データの断片etcd記憶容量を増強する他の方法を介して、ブロックを改善することにより、分配bbolt DBストレージエンジンアルゴリズム、ストア内のシーンのために大量のデータをetcdパフォーマンスが大幅に向上、単一etcdクラスタのサポートの下にあるetcd大幅にシステムアーキテクチャの全体的な複雑さを簡素化、大規模クラスタをKubernetes。
2. Kubernetes軽量ハートビート、HA API Serverノードの下に複数のクラスタのバランスの改善負荷を着陸することにより、ListWatchメカニズムは、ブックマークを高め、ほとんどが安定している方法の大規模なクラスタ化インデックスにし、キャッシュによってリストKubernetesのパフォーマンスのボトルネックを頭痛改善可能なワンを実行しているノードのクラスタ。
3. 切り替え中断時間は、クラスタ全体の可用性を向上させたときに、ホットスタンバイとして大幅コントローラ/スケジューラサービスを短縮します。
4. ランダムプロセスと同値クラス緩和アルゴリズム：2つのアイデアのスケジューラRESEARCH最も効果的なパフォーマンスの最適化から、アリババ。

機能強化のこのシリーズを通して、アリババが正常に最も内側のコアビジネスは、数千ノードのKubernetesクラスタ上で実行され、618 2019 Lynxの大きなプロモーションのテストを経験しています。

著者について：

Zengfanソング（愛称：スピリットによる）、そしてそうアリネイティブアプリケーションプラットフォームの上級技術専門家。

私たちは、分散システムの設計・開発に豊富な経験を持っています。お問い合わせは、規模の何千ものスケジューリングシステム管理ノード数百人を担当していましたので、この領域でのクラスタリソーススケジューリングでは、クラスタリソースのスケジューリング、リソース隔離コンテナ、混合ワークロード部門の実務経験の豊富があります。現在の秋には、大規模な内部Kubernetesアリのために主に責任がある、アリはKubernetesは、リソースの利用効率とアプリケーションの公開クラスタと安定した支持2018と2019618二から一一大きなプロモーションを向上させる、コアの電力事業の内部に適用されます。

**「アリババクラウドネイティブマイクロチャネルパブリック番号（ID：Alicloudnative）フォーカスマイクロサービスで、サーバレス、コンテナ、サービスメッシュ及び他の技術分野、クラウド人気のある技術トレンドのネイティブを中心に、クラウドネイティブの大規模な着陸の練習は、ほとんどがクラウドネイティブ開発を理解してくださいノー公共の技術。「**