ByteDanceのクラウドネイティブ保護システムの実践

背景

企業におけるKubernetesの大規模な使用と実装により、「ビジネス-ミドルプラットフォーム-インフラストラクチャ」の階層化されたテクノロジーシステムが徐々に形成されてきました。この階層化により、プラットフォーム層とインフラストラクチャ層の複雑な概念が隠蔽され、アプリケーションはビジネス層の開発に集中できるようになりますが、同時に、上位層アプリケーションの安定性が基盤となるインフラストラクチャのサポートに大きく依存することになり、大規模クラスターにおけるインフラストラクチャの安定性に大きな課題が生じます。

• クラスターの規模が大きいため、小さな問題でも無限に拡大され、システムリスクをもたらす可能性があります。
• シナリオの複雑さと多様性により、運用および保守業務における予期しない動作を完全に回避することも困難になります。

これには、Kubernetes によって管理されるリソースとオブジェクトに対して、より効果的な極度のリスク保護を提供し、誤操作、コンポーネントのバージョンと構成のエラー、または制御コードのバグによって引き起こされるビジネスへの回復不可能な影響を軽減することが求められます。

Kubernetes は、厳格な RBAC 検証メカニズム、PodDisruptionBudget (PDB) を使用した Eviction API の検証、比較的豊富な Admission Plugins など、一連の保護メカニズムをネイティブに提供していますが、実際の運用環境では、カバーできないシナリオがまだ多くあることがわかります。

このような状況において、ByteDance は Kubernetes システムを内部的に拡張および変革し、一連の防御検証措置と運用上の制約を追加して、Kubernetes 上で実行されるビジネスに強力な安定性サポートを提供し、極端なリスクを軽減しました。

保護強化

Kubernetes はかなり複雑な分散システムですが、そのアーキテクチャ設計の核となる考え方は依然として非常にシンプルです。 Kubernetes は、APIServer を通じてクラスターのステータスにアクセスして変更するための統合 API インターフェースを提供します。さまざまな自動化コンポーネントは、標準化された方法でクラスターと通信して継続的にデータを取得し、現在のクラスターの状態と予想されるクラスターの状態の差をローカルで計算して一連の変更操作を導き出すことができます。最後に、これらのステータスの変更は kubelet を介して各ノードで実行され、クラスターを期待される状態に移行させます。

Kubernetesコンポーネント間の相互作用と動作状況は、大きく分けて以下の3つの層に分けられることがわかります。

• KV ストレージ システム (etcd、Kine、Kubebrain など) と apiserver 間の相互作用により、キー値レベルの読み取りおよび書き込み操作とイベント監視が提供されます。
• apiserver は、API リクエストを通じて、さまざまな組み込みまたは追加のコントローラー/オペレーター (および apiserver とユーザー間) と対話します。
• apiserver とスタンドアロン ノード コンポーネント間の相互作用。

上記の階層化に基づいて、一連の共通のシステムリスクを具体的に選別し、極端なリスクを軽減するためにそれらを強化するための適切な措置を講じることができます。

データ保護

ストレージと API サーバー間の相互作用のリスクは、主にデータの破損や損失などのデータ異常に焦点を当てています。ストレージ システムは Kubernetes の中核であり、イベント駆動型分散システム全体の基礎となります。データ異常が発生すると、直接的または間接的に一連の障害が発生する可能性があります。具体的には、次のような一般的な極端なリスクの問題が含まれますが、これらに限定されません。

• ストレージ クラスターの操作およびメンテナンス エラーによりストレージがオフラインになり、Kubernetes クラスター全体が使用できなくなりました。
• 管理者は、API サーバーによる検証なしに etcd 内のデータを直接削除します。これにより、名前空間、デプロイメント、ポッドなどの予期しない主要オブジェクトが直接削除され、オブジェクトのカスケード削除がトリガーされ、ビジネスに広範囲にわたる損害が発生する可能性があります。
• 管理者が誤って etcd 内のデータを変更したため、データ形式が破損し、apiserver がデータをデコードできなくなりました。

これらの問題に対処するために、生産環境で一連の対策を講じました。まず、ストレージクラスターの運用保守やデータ操作を可能な限り標準化し、ストレージシステム側でTLS双方向認証を有効にし、Kubernetes以外のユーザーによるストレージへの直接アクセスを回避することで、データの破損や損失のリスクを軽減するようにしました。次に、ストレージを定期的にバックアップしました。極端なケースでは、回復不可能なデータ損失が発生した場合でも、バックアップに基づいてデータを迅速に復元し、損失の影響を軽減できます。さらに、他のコンポーネントを強化することで、データの異常に起因する予期しないイベントがビジネスに直接与える影響を最小限に抑えています。

操縦面保護

自動化コンポーネントと API サーバー間の相互作用のリスクは、主に予期しない操作に焦点が当てられています。通常の状況では、ユーザーまたはプラットフォームは予想される状態を API サーバーに送信し、他の内部コンポーネントは現在の状態と予想される状態の違いに基づいて一連のアクションを即座に導出し、それによってクラスターを変更します。間違った期待状態が送信されると、クラスターはターゲット状態に向かってすぐに不可逆的に変化します。

この種の問題に対する主な保護戦略は、主要なオブジェクトの操作にいくつかの追加の制限を課すことです。たとえば、誤操作や制御コードのバグによるリスクの可能性を減らすために、操作中にいくつかの冗長操作を行って二重チェック メカニズムを形成する必要があります。具体的には、操作保護は、Kubernetes によってネイティブに提供される ValidatingAdmissionWebhook 拡張メカニズムを通じて実現されます。ラベルと注釈を使用して、保護する必要がある主要なオブジェクトをマークし、セレクター構成を通じてこれらの主要なオブジェクトと対応する操作をフィルター処理します。保護の目的を達成するために、Webhook に一連の制約を実装します。これには、次の戦略が含まれますが、これらに限定されません。

• 名前空間や CRD などのルート オブジェクトのカスケード削除を防止します。削除されると、他の派生オブジェクトに対して連鎖的な削除操作がトリガーされます。したがって、誤操作による連鎖的な削除操作によって引き起こされる壊滅的な結果を回避するために、Webhook でこれらのタイプのキー オブジェクトの削除をインターセプトします。
• 明示的なレプリカの変更重要なワークロード リソースのレプリカの数を調整する必要がある場合、レプリカの数を誤って 0 に減らさないようにするために、UPDATE または PATCH リクエストを通じてレプリカの数を調整するときに、二重チェックとして予想される調整値を書き込む特定のアノテーションをオブジェクトに明示的に追加する必要もあります。 Webhook では、重要なワークロード オブジェクトが変更されたときの.spec.replicasフィールドの値が、アノテーションで指定された値と一致しているかどうかを確認し、重要なワークロード レプリカの数の変更が意図的かつ明示的であることを確認します。
• 明示的なリソースの削除重要なワークロード オブジェクトを削除する必要がある場合は、オブジェクトを削除する前に、変更操作によってワークロード コピーの数を 0 に減らす必要があります。この制約により、重要なワークロード オブジェクトの一部が確認なしに削除され、さらに多くのカスケード削除操作がトリガーされてビジネスに損害を与える可能性があるなどの誤操作を回避できます。
• 特定の業務においては、業務仕様の変更に対して厳しい変更イベント期間制限が設けられています。たとえば、企業では、イメージや環境変数などの構成の変更は、忙しくない時間帯にのみ受け付けます。これにより、仕様変更によって発生する潜在的な問題とそれに伴う業務中断のリスクを軽減できます。 CRD を通じて、変更可能なウィンドウや変更可能なフィールドなどの制約を定義し、ユーザーに公開します。ユーザー設定に基づいて、Webhook で対応するチェックを実行します。これにより、障害が発生した場合に影響を受けるエンドユーザーが可能な限り少なくなり、障害処理時間が比較的十分に確保され、潜在的な損失が最小限に抑えられ、システムリスクが軽減されます。

さらに、オンラインの運用環境では、OOM、大規模なキャッシュ侵入などのクライアントの異常やその他の問題が発生することがよくあります。これらの異常は、多くの場合、非常にコストのかかる読み取り要求を大量にトリガーし、コントロール プレーンの異常や雪崩を引き起こします。異常なオンライン トラフィックから保護するために、ユーザーの行動に一定の制限を課し、非常にコストのかかるリードスルー行動を禁止しました。次に、kube-apiserver のトラフィック特性に合わせて特別にカスタマイズされた 7 層ゲートウェイ KubeGateway をコントロール パネルの前に配置しました。 kube-apiserver の負荷の不均衡の問題を解決し、リクエストのルーティング、転送、電流制限、劣化などを含む kube-apiserver リクエストの完全な管理を実現し、Kubernetes クラスターの可用性を大幅に向上させます。さらに、Kubernetes の監査ログを拡張し、監査ログにトラフィック関連の情報を追加し、これをもとに分析してユーザーポートレートを取得しました。異常なシナリオでは、ユーザー ポートレート、トラフィック監視インジケーター、コントロール プレーンの前の 7 層ゲートウェイ KubeGateway のフロー制限機能を組み合わせて、コントロール プレーンに大きな負荷をかけるクライアントのフローを制御し、雪崩のリスクを最小限に抑えます。

ノード保護

ほとんどのシナリオでは、ポッドの削除は 2 段階で実行する必要があります。まず、集中型コントローラーまたはユーザーが削除要求を開始してポッドを削除済みとしてマークし (つまり、DeletionTimestamp を追加します)、次に kubelet がビジネスの適切な終了を開始する責任を負います。ビジネスが終了してリソースが解放された後、kubelet は APIServer によって提供されるインターフェースを通じてポッドを完全に削除します。ただし、実際の運用では、次のような例外により kubelet がビジネス ポッドを予期せず終了する可能性のある多くの問題が発生します。

• 構成エラーまたはコードバグにより、kubelet は再起動後に実行中のビジネス ポッドを拒否し、ビジネスに損害を与えます。
• コントロール プレーン ストレージ内のデータ破損またはその他の異常により、kubelet は、実際にローカルで実行されているポッドが、コントロール プレーンによって提供され、ローカルで実行する必要があるポッドと一致していないことを検出し、予期しないビジネス終了を引き起こします。

この種の問題に対処するために、私たちは、承認、ハウスキーピング、その他の側面をカバーする一連の変更を kubelet に加えました。 kubelet を変更することで、ポッド削除操作に事前制約を追加します。重要なポッドを削除しようとすると、まずポッドが明示的に削除対象としてマークされているかどうかを確認します。ポッドが削除対象としてマークされていない場合、kubelet はポッドの削除操作をトリガーできません。この明示的な削除制約に基づいて、Kubernetes のさまざまなコンポーネントの異常によって引き起こされるノードレベルでの業務運用リスクを大幅に軽減できます。

まとめ

本番環境では、主に Kubernetes コンポーネント間の相互作用プロセスに基づいて主要なリスクを特定して選別し、主要なオブジェクトに特定のラベルと注釈を付けて、強化するための対策を講じます。

• データ保護は主に、運用と保守を制限し、データ アクセス ポータルを統合し、さまざまなストレージ操作を標準化してリスクを軽減します。
• コントロール プレーンの保護は、主に ValidatingAdmissionWebhook をカスタマイズすることによって拡張されます。いくつかの重要なオブジェクトを変更する場合、誤操作のリスクを軽減するために、いくつかの冗長な操作と検証を積極的に導入する必要があります。
• ノード保護は主に、kubelet を変更し、キーポッドが明示的に削除されることを厳密に制限し、極端な状況でのシステムリスクを軽減することによって実現されます。

応用事例

ByteDance は、パーソナライズされたシナリオをサポートするために、ネイティブ Kubernetes エコシステムに基づいてさらに多くの機能をカスタマイズしました。全体的な研究開発、反復、配信の効率は非常に高く、クラスターの安定性にとって大きな課題となります。配送プロセスの仕様を厳密に管理したとしても、異常な状況下での極度の異常リスクを完全に排除することは不可能です。 ByteDanceクラウドネイティブチームは、実際のプロセスで発生した障害事例やシナリオ要件と組み合わせて、メタクラスター、コントロールプレーン、データプレーン、ビジネスカスタマイズなど、複数の角度から比較的包括的な防御システムを構築し、大規模なオンライン事故の発生を効果的に回避しました。

Data Guard: メタクラスタのカスケード削除

ByteDance 内には多くのクラスターが存在します。自動化された運用保守やクラスタ管理を実現するためには、業務クラスタの状態を記述するメタクラスタを構築する必要があります。この場合、メタクラスター自体の異常により、より広範囲の障害が発生する可能性があります。 ByteDance の初期の頃は、クラスターには保護機能が欠けていました。 SRE は運用および保守プロセス中に高い権限を使用しすぎたため、リージョン メタ クラスター内のノード ステータスを記述するために使用される CRD を誤って削除しました。傍受する防御システムがなかったため、CRD を削除するとすべての CR のカスケード削除がトリガーされ、メタ クラスター コントローラーはほぼすべてのノードをオフラインにする必要があると判断し、すべてのポッドが物理的にシャットダウンされます。この障害により、最終的に単一リージョンの運用クラスターで 30 分以内に 30,000 を超えるノードが継続的にマークおよび削除されることになりました。実際に 9,000 個のノードを削除した後、損失は時間内に停止しました。影響は大きく、手動のストップロスウィンドウは非常に短かったです。この場合、防衛システムへのアクセスにより、複数の地点で防衛能力が発揮される。

• 事前傍受: CRD を重要としてマークすることで、すべてのデータが誤って削除されることによる連鎖的な問題を回避します。
• クラスターのオフライン フロー制御: 大規模なクラスターのオフラインは、通常、一般的な運用および保守操作ではありません。異常なカスケード削除が発生した場合でも、障害ドメインを可能な限り制御できるように、ノードオフラインの頻度と安全レベルを制御します。
• データのバックアップと復元: 物理オブジェクトが削除された場合でも、バックアップ データを通じてすぐに復元できます。

コントロールプレーン保護: 異常なトラフィックの識別とフロー制限

コントロール プレーンの異常は通常、不合理なクライアントの動作と不正確なサーバー リソースの推定によって発生します。シナリオの複雑さときめ細かいガバナンスの欠如により、さまざまな理由により、サーバーは最終的に過負荷になります。通常、この現象は、大量のクライアント リスト要求と APIServer OOM を伴い、さらにすべてのクライアントの再リストがトリガーされ、クラスター雪崩が発生するまでの悪循環を形成します。コントロール プレーンでの極端な異常に対して、ByteDance はレイヤー 7 ゲートウェイに接続し、フルリンクの自動トラフィック トレースを調整することで、柔軟でインテリジェントな API 要求保護を実装します。

• 通常フロー制御: クライアントとリソース オブジェクトの組み合わせと通常フロー分析に基づいてフロー制御ルールをカスタマイズし、サーバーへの瞬間的な大量のリクエストによる負荷を回避します。
• 災害復旧シナリオのブレーカー: クラスターに明らかな異常が発生したり、雪崩が発生したりした場合は、手動のブレーカーによって損失が停止され、電流制限が徐々に解除されてクラスターが正常な状態に戻ります。

ノード保護: 異常なバージョンアップグレードにより大規模な排除が発生

コントロール プレーンと比較すると、データ プレーンのバージョンと構成は通常より複雑で多様であり、反復もより頻繁に行われ、不適切なコンポーネントの操作とメンテナンスにより予期しない極端なリスクが発生する可能性が高くなります。 SRE Kubelet バージョンのアップグレード中に、予期しないコロケーション リソース構成が適用されました。 Kubelet が再起動された後、リソース所有権の識別が誤っていたために障害が発生したため、多数の実行中のポッドが削除されました。同時に、ネイティブ削除 API が PDB によって傍受され、ビジネス キャパシティの大きな損失が発生することが予想されました。しかし、オンライン保護機能のおかげで、最終的には深刻なオンライン問題は発生しませんでした。この場合、アクセス防御システムは、スタンドアロン マシンと中央マシンの両方で防御機能を提供できます。

• 単一マシンのインターセプト: すでに実行状態にあるコア サービスの場合、明示的な削除のみが API を通じてマークされるように、明示的な削除タグがデフォルトで追加されます (deletetionTimestamp の設定)。これにより、データ プレーンの異常リリース後にビジネス インスタンスの動作が影響を受けないことが保証され、人による介入に十分な時間が確保されます。
• 中央インターセプト: 予期しないポッド削除動作がビジネスに影響を及ぼさないように、検証用に 2 つの API (Delete と DeleteCollection) をコア サービスに追加します。

その後の計画

ByteDance の保護対策は、今後 Volcano Engine VKE 製品に徐々に統合され、クラウド サービスのより信頼性の高い安定性保証が提供される予定です。さらに、クラウド ネイティブ保護の機能強化を継続し、クラウド サービスに安定性リスクをもたらす可能性のある次のようなシナリオを統合して解決します。

• コントロール プレーンの Delete pod API 保護の組み込み PDB 保護メカニズムは Evict pod API でのみ機能し、検証のパフォーマンスが低下します。 PDB オブジェクトが多数ある場合、Evict pod API の時間消費は大幅に低下し、リクエストの待ち時間は Delete pod よりも大幅に長くなります。そのため、多くのコンポーネントは、プリエンプションを開始するスケジューラなど、意図的に Evict pod を使用せず、直接 Delete pod を使用します。コントロール プレーンの Delete pod には組み込みチェックがほとんどないため、このインターフェイスを直接使用すると、ビジネス ポッドの健全な比率が予想よりも低くなり、ビジネスの正常な運用に影響する可能性があります。このようなリスクを回避するには、一方では Evict ポッドのパフォーマンスを最適化し、他方では拡張機能を通じて Delete ポッド操作のより厳格な検証を実行して、ビジネスを実行しているポッドの健全な割合が予想よりも低くならないようにする必要があります。
• 収束静的検証戦略現在、コントロール プレーンで行っている保護作業は、主に Validating Admission Webhook メカニズムに依存しています。一方では、API サーバーがリクエストを処理するときに追加の外部プロセスが導入され、レイテンシとエラーの可能性が増加します。その一方で、クラスタの運用と保守の複雑さもある程度増大します。 Kubernetes バージョン 1.26 では、リクエストに対していくつかの静的チェックを実行するために CEL (Common Expression Language) の使用をサポートする新しい Admission Plugin が導入されました。今後、コントロール プレーン保護の冗長な動作チェックの一部を CEL に移行し、上記の問題を改善する予定です。
• シナリオに合わせた保護戦略Redis や分散トレーニングなどのストレージ環境を持つ企業では、オーケストレーション モデルや運用・保守ソリューションにおいてカスタマイズ要件が比較的多くあります。そのため、防御システムは、ビジネス特性に基づいた固有の極端に異常なリスクに合わせて、より洗練された戦略（ストレージシャーディング、垂直リソース調整、インサイチュ再起動など）を補完・改善する必要があります。

要約する

この記事では、主にByteDanceの社内運用環境でKubernetesを適用する際に発見された主なシステムリスクを紹介し、一連の保護対策を提案します。具体的には、Kubernetes コンポーネントの相互作用プロセスの観点から開始し、それをデータ、コントロール プレーン、ノードの 3 つのレベルに分割します。また、制御コンポーネントの誤操作やバージョンエラーなど、よくある問題についても具体的な例を挙げて説明します。これらのよくある問題に対応するために、コンポーネントのアクセス権の制限、冗長操作や関連する検証の積極的な追加など、当社が構築した一連の防御策を簡単に紹介します。これらの防御策を通じて、既知の問題がビジネスにもたらすリスクを軽減し、ビジネスに安定した基本サービスを提供することができます。

必要な防御強化対策に加えて、毎日のクラスターメンテナンスのための標準化された変更プロセスも重要です。クラスタサイズを制御し、十分なグレースケール検証を実施することで、障害の影響範囲を縮小できます。生産環境においては、システムの自己防衛策や標準化された運用・保守などのさまざまな手段を総合的に活用することによってのみ、リスクや障害損失を最大限まで最小限に抑えることができます。