Kubernetes システム アーキテクチャの進化とその背後にある理由

この記事は、Kubernetes アーキテクチャの設計意図、Kubernetes システムのアーキテクチャ開発と進化、そしてその背後にある原動力を理解するのに役立ちます。

1. 背景

すべてのプラットフォームは、プラットフォームに何を含めるべきか、何を含めるべきでないかについての避けられない問題に直面しますが、Kubernetes も例外ではありません。コンテナをデプロイおよび管理するためのプラットフォームとして、Kubernetes はユーザーのすべての問題を解決することはできませんし、そうすべきでもありません。 Kubernetes は、ユーザーがコンテナ化されたアプリケーションを実行したり、それらの拡張機能を構築したりできる基本的な機能を提供する必要があります。この記事の目的は、Kubernetes アーキテクチャの設計意図を明確にし、Kubernetes の進化と将来の開発の青写真を説明することです。

この記事では、Kubernetes システム アーキテクチャの進化とその背後にある理由について説明します。 Kubernetes システムを拡張またはカスタマイズしたい開発者は、このドキュメントをガイドとして使用し、拡張機能をどこにどのように実装できるかを理解する必要があります。アプリケーション開発者が大規模で移植性があり、将来性も考慮した Kubernetes アプリケーションを開発する必要がある場合は、Kubernetes の将来の進化と開発を理解するためにこのドキュメントも参照する必要があります。

論理的には、Kubernetes のアーキテクチャは次のレベルに分かれています。

• コア層 (Nucleus): 基本的な REST メカニズム、セキュリティ、ポッド、コンテナ、ネットワーク インターフェイス、ストレージ ボリューム管理などの標準 API と実行メカニズムを提供します。これらの API と実行は、インターフェースを通じて拡張できます。コア層は必要であり、システムの中核部分です。
• アプリケーション管理レイヤー: 自己修復機能、柔軟な拡張、サービス検出、負荷分散、トラフィック ルーティングなどの基本的な展開とルーティングを提供します。このレイヤーは、一般的にサービス オーケストレーションと呼ばれます。これらの関数はデフォルトの実装を提供しますが、一貫した置き換えが可能です。
• ガバナンス レイヤー: シングル テナントおよびマルチ テナント、メトリック、インテリジェントな容量拡張とプロビジョニング、承認スキーム、ネットワーク スキーム、クォータ スキーム、ストレージ ポリシーの表現と適用など、高度な自動化とポリシー適用を提供します。これらはすべてオプションであり、他のソリューションを通じて実現できます。
• インターフェース レイヤー: Kubernetes API と対話するための共通ライブラリ、ツール、ユーザー インターフェース、およびシステムを提供します。
• エコシステム: これには Kubernetes に関連するすべてのものが含まれますが、厳密に言えば、Kubernetes の一部ではありません。 CI/CD、ミドルウェア、ロギング、監視、データ処理、PaaS、サーバーレス/FaaS システム、ワークフロー、コンテナ ランタイム、イメージ リポジトリ、ノードおよびクラウド プロバイダー管理などが含まれます。

2. システムの階層化

Linux にカーネル、コア システム ライブラリ、オプションのユーザー レベル ツールがあるのと同様に、Kubernetes にも機能とツールのレイヤーがあります。開発者にとってこれらのレベルを理解することは非常に重要です。 Kubernetes API、概念、および機能は、次のレイヤー図に示されています。

2.1 核: APIと実行

コア層には、コア API と実行エンジンが含まれています。

これらの API と関数は、アップストリーム Kubernetes コードベースによって実装され、システムの上位層に必要な最小限の機能と概念のセットから構成されます。

アップストリーム Kubernetes コードベースによって実装されるこれらの API と関数には、高レベルのシステムを構築するために必要な最小限の機能と概念のセットが含まれています。これらは明確に指定され、文書化されており、コンテナ化されたすべてのアプリケーションで使用されます。開発者は、コンテンツは常に存在しており、そのコンテンツは安定していて退屈なものになるはずだと安心して想定できます。

2.1.1 APIとクラスターコントロールパネル

Kubernetes クラスターは、Kubernetes API サーバーを通じて公開され、永続リソースの追加、削除、変更、クエリをサポートする一連の REST API を提供します。これらの API はコントロール パネルのハブとして機能します。

Kubernetes API 規則 (パス規則、標準メタデータなど) に従う REST API は、共有 API サービス (認証、承認、監査ログ) のメリットを自動的に享受でき、汎用クライアント コードでそれらを操作できます。

システムの最下層として、上位層が機能を追加できるように、必要な拡張メカニズムをサポートする必要があります。さらに、シングルテナントおよびマルチテナントのアプリケーション シナリオをサポートする必要があります。コア層は、セキュリティ モデルを損なうことなく上位層が新しいスコープを拡張できるように十分な柔軟性も提供する必要があります。

Kubernetes は、次の基本的な API とセマンティクスがなければ適切に動作しません。

認証: 認証メカニズムは非常に重要なタスクです。 Kubernetes では、サーバーとクライアントの両方で認証される必要があります。 API サーバーは、基本認証 (ユーザー名/パスワード) (これは将来廃止される予定です)、X.509 クライアント証明書、OpenID Connect トークン、およびベアラー トークンをサポートしています。 kubeconfig のサポートにより、クライアントは上記のさまざまな認証モードを使用できます。サードパーティの認証システムは、TokenReview API を実装し、認証 Webhook を構成することによってそれを呼び出すことができます。これにより、非標準の認証メカニズムを通じて利用可能なクライアントの数を制限できます。

• TokenReview API（フックと同じメカニズム）は、Kubeletなどの外部認証チェックを有効にすることができます。
• ポッドIDは「サービスアカウント」を通じて提供される
• ServiceAccount API (コントローラーによって作成され、アクセス アドミッション コントローラーによって挿入されるデフォルトの ServiceAccount シークレットを含む)。

承認:サードパーティの承認システムは、SubjectAccessReview API を実装し、承認 Webhook を構成することでそれを呼び出すことができます。

SubjectAccessReview (フックと同じメカニズム)、LocalSubjectAccessReview、および SelfSubjectAccessReview API を使用すると、Kubelet やその他のコントローラーなどの外部権限チェックが可能になります。

• REST セマンティクス、監視、永続性と一貫性の保証、API のバージョン管理、デフォルト、検証
• NIY: 対処が必要な API の欠陥:
• 契約違反の混乱
• セキュリティの欠如
• オーケストレーションサポート
• イベント駆動型自動化のサポート
• クリーンアンインストール

NIY: 組み込みのアドミッション制御セマンティクス、同期アドミッション制御フック、非同期リソース初期化 - パブリッシャー、システムインテグレーター、およびクラスタ管理者は追加のポリシーと自動化を実装します。

NIY: API の登録と公開 (API の集約、追加の API の登録、サポートされている API の公開、サポートされている操作、ペイロード、結果スキーマの詳細の取得など)。

NIY: ThirdPartyResource および ThirdPartyResourceData API (またはその後継)、サードパーティのストレージおよび拡張 API のサポート。

NIY: クラスタが完全に存在し、正しく動作しているかどうかを判断するための Componentstatuses API のスケーラブルで可用性の高い代替手段: ExternalServiceProvider (コンポーネント登録)

エンドポイント API、コンポーネントの蓄積ニーズ、API サーバーエンドポイントの自己公開、高可用性、アプリケーション層ターゲットの公開

名前空間 API、ユーザー リソースのスコープ、名前空間のライフサイクル (例: 一括削除)

イベントAPIは、状態の変化やエラーなどの重要なイベントの報告や、イベントのガベージコレクションに使用されます。

NIY: カスケード削除ガベージ コレクター、ファイナライズ、および孤立化

NIY: ホストからコンポーネントを自動的に追加し、それらをクラスターに動的に構成して、実行中のクラスターから機能を抽出するには、組み込みのアドオン マネージャーが必要です。

• アドオンはクラスターサービスであり、クラスターの一部として管理される必要があります。
• ユーザー名と競合しないように、kube-system 名前空間で実行できます。

API サーバーはクラスターへのゲートウェイとして機能します。定義上、API サーバーはクラスター外部のクライアントからアクセス可能である必要がありますが、ノードとポッドはクラスター外部のクライアントからアクセスできません。クライアントはAPIサーバーを認証し、それを要塞およびプロキシ/チャネルとして使用して、/proxyおよび/portforward APIを介してノードとポッドにアクセスします。

未定: 証明書、具体的には kubele 証明書の作成を可能にする CertificateSigningRequest API。

理想的には、コア API サーバーは最小限必要な API のみをサポートし、追加機能は集約、フック、初期化子、およびその他の拡張メカニズムを通じて提供される必要があります。集中型の非同期コントローラーは、ガベージ コレクションと同様に、コントローラー マネージャーと呼ばれる別のプロセスで実行されることに注意してください。

API サーバーは次の外部コンポーネントに依存します。

• 永続的な状態ストレージ (etcd または他の対応するシステム。複数のインスタンスが存在する場合があります)
• API サーバーは以下に依存します。
• アイデンティティプロバイダ
• TokenReview API実装者
• SubjectAccessReview API実装者

2.1.2 実行

Kubernetes で最も重要なコントローラーは kubelet であり、これは Pod と Node API の主な実装者です。これらの API がなければ、Kubernetes はキー値ストレージによってサポートされる REST アプリケーション フレームワークのみになります (後で、API マシンは最終的に別のプロジェクトになる可能性があります)。

Kubernetes は、デフォルトでスタンドアロン アプリケーション コンテナーとローカル モードを実装します。

Kubernetes は、複数のコンテナとストレージ ボリュームを管理する Pod を提供します。ポッドは Kubernetes における最も基本的な実行単位です。

Kubelet API セマンティクスには以下が含まれます。

Kubernetes 実行ユニットである Pod API には以下が含まれます。

1) ポッド実現可能性のアドミッション制御は、ポッド API のポリシー (リソース要求、ノード セレクター、ノード/ポッドのアフィニティとアンチアフィニティ、テイントと許容値) に基づいています。 API アドミッション コントロールはポッドを拒否したり、追加のスケジューリング制約を追加したりできますが、ポッドが最終的にどのノードで実行されるかを決定するのはスケジューラや DaemonSet ではなく、Kubelet です。

2) コンテナとストレージボリュームのセマンティクスとライフサイクル

3) ポッド IP アドレスの割り当て (各ポッドにはルーティング可能な IP アドレスが必要です)

4) ポッドを特定のセキュリティスコープ（ServiceAccountなど）に接続するためのメカニズム

5) ストレージボリュームソース:

• 空のディレクトリ
• ホストパス
• 秘密
• 構成マップ
• 下向きAPI
• NIY: コンテナとイメージボリューム (gitRepo の廃止)
• NIY: ローカルストレージ、開発および本番アプリのマニフェストに複雑なテンプレートや個別の構成は不要
• flexVolume (組み込みのクラウドプロバイダー固有のストレージボリュームを置き換える必要があります)

6) サブリソース: バインディング、ステータス、実行、ログ、アタッチ、ポート転送、プロキシ

• NIY: 可用性とブートストラップ API リソース チェックポイント

コンテナイメージとログのライフサイクル

• サードパーティの暗号化管理を可能にするSecret API
• コンポーネント構成とPod参照用のConfigMap API
• ポッドのホストであるNode API

a.一部の構成では、クラスタ管理者にのみ表示されることがあります。

• ノードとポッドのネットワークとその制御（ルーティング コントローラ）
• ノードのインベントリ、健全性、到達可能性（ノード コントローラ）

b.クラウドプロバイダー固有のノードインベントリ機能は、プロバイダー固有のコントローラーに分離する必要があります。

• ポッド終了ガベージコレクション
• ストレージボリュームコントローラ

紀元前クラウド プロバイダー固有のアタッチ/デタッチ ロジックは、プロバイダー固有のコントローラーに分離する必要があります。 API からプロバイダー固有のストレージ ボリューム ソースを抽出する方法が必要です。

• 永続ボリュームAPI

d. NIY: 少なくともローカルストレージでサポートされている

• PersistentVolumeClaim API について

コントローラー マネージャーによって実行されるポッド終了ガベージ コレクションなどの非同期機能を一元化します。

現在、コントロール フィルターと kubelet は「クラウド プロバイダー」インターフェースを呼び出して、インフラストラクチャ レイヤーから情報を照会し、インフラストラクチャ リソースを管理します。ただし、Kubernetes はこれらのタッチポイント (問題) を外部コンポーネントに抽象化しようとしています。外部コンポーネントでは、満たされないアプリケーション/コンテナ/OS レベルのリクエスト (PODS、PersistentVolumeClaims など) が外部の「動的プロビジョニング」システムへのシグナルとして使用され、インフラストラクチャがこれらのリクエストを満たすことができるようになります。また、Kubernetes ではインフラストラクチャ リソース (Node、PersistentVolumes など) を使用してこれらのリクエストが表現されるため、Kubernetes はリクエストとインフラストラクチャ リソースを結び付けることができます。

kubelet の場合、次の拡張可能なコンポーネントに依存します。

• 画像登録
• コンテナランタイムインターフェースの実装
• コンテナネットワークインターフェースの実装
• FlexVolume 実装 (図の「CVI」)

また、次の要因に依存する可能性があります:

• NIY: サードパーティの暗号化管理システム (例: Vault)
• NIY: 資格情報の作成および変換コントローラー

2.2 アプリケーション層: デプロイメントとルーティング

アプリケーション管理および構成レイヤーは、自己修復、スケーラビリティ、アプリケーション ライフサイクル管理、サービス検出、負荷分散、ルーティング (サービス オーケストレーションおよびサービス ファブリックとも呼ばれます) を提供します。これらの API と機能は、すべての Kubernetes ディストリビューションに必要です。 Kubernetes はこれらの API のデフォルト実装を提供する必要がありますが、代替実装を使用することもできます。アプリケーション層 API がなければ、ほとんどのコンテナ化されたアプリケーションは実行できません。

Kubernetes の API は、IaaS のようなコンテナ中心のインフラストラクチャと、すべてのワークロードのオーケストレーション (自己修復、スケーリング、更新、終了) をサポートするライフサイクル コントローラーを提供します。これらのアプリケーション管理、構成、検出、ルーティング API と機能には、次のものが含まれます。

• デフォルトのスケジューラは、Pod API のスケジューリング ポリシー (リソース要求、nodeSelector、ノードとポッドのアフィニティ/非アフィニティ、テイントと許容値) を実装します。スケジューラは、クラスターの内外で独立したプロセスとして実行できます。

NIY: 再スケジューラーは、スケジュールされたポッドをリアクティブかつプロアクティブに削除し、他のノードに置き換えて再スケジュールできるようにします。

継続的に実行されるアプリケーション: このタイプのアプリケーションは、宣言的な更新、カスケード削除、および孤立/採用のサポートを使用してリリース (ロールバック) できる必要があります。 DaemonSet に加えて、水平拡張もサポートする必要があります。

1. サブリソース（ステータス、スケーリング、ロールバック）を含むステートレス アプリケーションの更新を調整するデプロイメント API
2. DaemonSet API、クラスター サービス、サブリソース (ステータス) を含む
3. StatefulSet API、サブリソース（状態、拡張）を含むステートフルアプリケーション
4. PodTemplate APIは、DaemonSetとStatefulSetによって変更履歴を記録するために使用されます。

バッチアプリケーションの終了: これには、終了したジョブの自動削除 (NIY) が含まれる必要があります。

• ジョブ API (GC に関する議論)
• CronJob API について

検出、負荷分散、ルーティング

1. クラスター IP アドレスの割り当て、サービス割り当てマッピングの修復、kube-proxy または同等のものを介した負荷分散サービス、エンドポイントの自動作成、メンテナンス、削除などのサービス API。 NIY: 負荷分散サービスはオプションであり、サポートされている場合は適合テストに合格する必要があります。
2. 内部 L7 (NIY) を含む Ingress API
3. サービスDNS。 DNS は公式の Kubernetes スキーマを使用します。

アプリケーション層は以下に依存できます。

• アイデンティティ プロバイダー (クラスター アイデンティティおよび/またはアプリケーション アイデンティティ)
• NIY: クラウド プロバイダー コントローラーの実装
• イングレスコントローラ
• スケジューラと再スケジューラ向けの代替ソリューション
• DNS サービスの代替ソリューション
• kube-proxy の代替ソリューション
• ワークロード コントローラの代替ソリューションおよび/または支援 (特にリリース戦略のスケーリング)

2.3 ガバナンス層: 自動化とポリシーの適用

ポリシーの適用と高度な自動化。これらの API と機能はアプリケーションを実行するためのオプションであり、他のソリューションによって実装する必要があります。

サポートされている各 API/関数は、エンタープライズ運用、セキュリティ、ガバナンスのシナリオの一部として適用されます。

少なくとも次のユースケースをサポートする、クラスターの可能な構成と検出のデフォルト戦略を提供する必要があります。

• 単一テナント/単一ユーザー クラスター
• マルチテナントクラスタ
• 生産と開発のクラスター
• 入居者の多い遊び場群
• コンピューティング/アプリケーション サービスを他者に再販するためのセグメント化されたクラスター

注意すべき点:

1. リソースの使用
2. ノード内部セグメンテーション
3. エンドユーザー
4. 管理者
5. サービス品質 (DoS)

自動化 API と機能:

• メトリクス API (水平/垂直自動スケーリング スケジューラ)
• 水平ポッド自動スケーリング API
• NIY: 垂直ポッド自動スケーリング API
• 自動クラスタ拡張とノードプロビジョニング
• PodDisruptionBudget API について
• 少なくとも 1 つの工場出荷時のソース タイプを備えた動的ストレージ ボリュームのプロビジョニング

1. デフォルトのストレージボリュームタイプの実装が少なくとも1つあるStorageClass API

• 動的負荷分散プロビジョニング
• NIY: ポッドプリセット API
• NIY: サービス ブローカー/カタログ API
• NIY: テンプレートおよびテンプレートインスタンス API

ポリシー API と関数:

認可: ABAC および RBAC 認可ポリシー ソリューション

1. RBAC、次のAPIを実装します: Role、RoleBinding、ClusterRole、ClusterRoleBinding

• LimitRange API について
• リソースクォータ API
• PodSecurityPolicy API について
• ImageReview API について
• ネットワークポリシー API

管理は以下に依存します。

• ネットワークポリシーの強制メカニズム
• 交換、水平および垂直ポッド拡張
• クラスターの自動スケーリングとノードプロバイダー
• ダイナミックボリュームプロバイダー
• 動的負荷分散プロバイダー
• メトリクス監視パイプラインまたはその代替
• サービスエージェント

2.4 インターフェース層: クラスライブラリとツール

これらのメカニズムは、アプリケーション バージョンを配布する場合に推奨され、ユーザーはこれを使用してアプリケーションをダウンロードしてインストールすることもできます。これらには、公式 Kubernetes プロジェクトによって開発された共通のライブラリ、ツール、システム、インターフェースが含まれており、リリースに使用できます。

1. Kubectl — kubectl は多くのクライアント ツールの 1 つであり、Kubernetes は一般的に使用される重要な機能を API に移動することで Kubectl をよりスリムにすることを目指しています。これは、Kubernetes バージョン間での正しい操作を容易にし、API の拡張性を促進して API 中心の Kubernetes エコシステム モデルを維持し、他のクライアント、特に非 GO クライアントを簡素化するために必要です。

• クライアント ライブラリ (例: client-go、client-python)
• クラスターフェデレーション (API サーバー、コントローラー、kubefed)
• ダッシュボード
• 舵

これらのコンポーネントは以下に依存します。

• Kubectl 拡張機能
• Helm 拡張機能

2.5 エコシステム

Kubernetes には明確な境界が定義されている領域が数多くあります。ただし、Kubernetes は、コンテナ化されたアプリケーションのデプロイと管理に必要な共通機能を提供する必要があります。しかし、原則として、Kubernetes は、機能が Kubernetes の一般的なオーケストレーション機能を補完する領域では、ユーザーの選択を維持します。特に、独自の競争上の優位性を持つ分野、特にさまざまなニーズや好みに対応できる多数のソリューション。 Kubernetes は、これらのソリューション用のプラグイン API を提供したり、複数のバックエンドによって実装される共通 API を公開したり、そのようなソリューションが対象とすることができる API を公開したりすることができます。明示的なインターフェースを必要とせずに、Kubernetes を使用して機能をきれいに構成できる場合があります。

さらに、Kubernetes の一部と見なされる場合、コンポーネントは Kubernetes の設計規則に従う必要があります。たとえば、プライマリ インターフェースが Kubenetes API アプローチと互換性のないドメイン固有言語 (Puppet、Open Policy Agent など) を使用するシステムは、Kubernetes で使用できますが、Kubernetes の一部とは見なされません。同様に、複数のプラットフォームをサポートするように設計されたソリューションは、Kubernetes API プロトコルに準拠していない可能性があるため、Kubernetes の一部とは見なされません。

内部コンテナ イメージ: Kubernetes はコンテナ イメージの内容を提供しません。コンテナ イメージにデプロイされるように設計されているものは、直接 Kubernetes の一部とは見なされません。たとえば、言語固有のフレームワークなどです。

Kubernetes上で

1. 永続的な統合とデプロイメント (CI/CD): Kubernetes では、ソース コードからイメージに移行する機能は提供されません。 Kubernetes はソースコードをデプロイせず、アプリケーションをビルドしません。ユーザーとプロジェクトは、独自のニーズに応じて永続的な統合と永続的なデプロイメントのワークフローを選択できます。 Kubernetes の目標は、CI/CD の動作を指示するのではなく、CI/CD の使用を容易にすることです。

2. アプリケーション ミドルウェア: Kubernetes は、メッセージ キューや SQL データベースなどの組み込みインフラストラクチャとしてアプリケーション ミドルウェアを提供しません。ただし、簡単にプロビジョニング、検出、アクセスできるようにする汎用メカニズムを提供することができます。理想的には、これらのコンポーネントは Kubernetes 上でのみ実行されます。

3. ログ記録と監視:ログ記録と監視のメカニズムは Kubernetes クラスターの重要な部分ですが、Kubernetes 自体はログの集約や包括的なアプリケーション監視機能を提供しておらず、テレメトリ分析やアラート システムもありません。

4. データ処理プラットフォーム:データ処理プラットフォームとしては、Spark と Hadoop がよく知られていますが、市場には他にも多くのシステムが存在します。

5. アプリケーション固有のオペレーター: Kubernetes は、一般的なカテゴリのアプリケーションのワークロード管理をサポートします。

6. サービスとしてのプラットフォーム (PaaS): Kubernetes は PaaS の基盤を提供します。

7. Function as a Service (FaaS): PaaS に似ていますが、Faa はコンテナーと言語固有のアプリケーション フレームワークに侵入します。

8. ワークロード オーケストレーション: 「ワークフロー」は非常に幅広く多様な分野であり、通常は特定のユース ケース シナリオ (データ フロー図、データ駆動型処理、デプロイメント パイプライン、イベント駆動型自動化、ビジネス プロセス実行、iPAAS など) と特定の入力およびイベント ソースのソリューションを対象としており、通常はコードを記述して実装する必要があります。

9. ドメイン固有言語を構成する:ドメイン固有言語は、高レベルの API やツールを階層化するのに適しておらず、通常、表現力、テスト可能性、親しみやすさ、ドキュメント化が制限されています。それらは構成の生成を複雑にし、相互運用性と構成可能性の間でトレードオフする傾向があります。それらは依存関係の管理を複雑にし、抽象化とカプセル化を破壊してしまうことがよくあります。

10. Kompose: Kompose は、Docker Compose から Kubernetes への移行を支援し、シンプルなユースケースを提供するアダプタ ツールです。 Kompose は Kubernetes の規則には従わず、手動で保守される DSL に基づいています。

11. ChatOps:チャット サービス用のアダプタ ツールでもあります。

Kubernetesのサポート

1. コンテナ ランタイム: Kubernetes 自体はコンテナ ランタイム環境を提供しませんが、選択したコンテナ ランタイムをプラグインするためのインターフェイスを提供します。

2. イメージリポジトリ: Kubernetes 自体はコンテナイメージを提供しません。 Harbor、Nexus、docker レジストリを通じてイメージ リポジトリを構築し、クラスターに必要なコンテナ イメージをプルできます。

3. クラスター状態ストレージ:クラスターの動作状態を保存するために使用されます。たとえば、デフォルトでは Etcd が使用されますが、他のストレージ システムも使用できます。

4. ネットワーク:コンテナ ランタイムと同様に、Kubernetes はさまざまなネットワーク プラグインにアクセスするためのコンテナ ネットワーク インターフェイス (CNI) を提供します。

5. ファイルストレージ:ローカルファイルシステムとネットワークストレージ

6. ノード管理: Kubernetes は、包括的なマシン構成、メンテナンス、管理、または自己修復システムを提供または採用していません。通常、異なるパブリック/プライベート クラウド、異なるオペレーティング システム、および可変および不変のインフラストラクチャ向けです。

7. クラウド プロバイダー: IaaS のプロビジョニングと管理。

8. クラスターの作成と管理:コミュニティでは、minikube、kubeadm、bootkube、kube-aws、kops、kargo、kubernetes-anywhere など、多くのツールが開発されています。ツールの多様性からわかるように、クラスターの展開と管理 (アップグレードなど) には万能のソリューションはありません。とはいえ、共通のビルディング ブロック (安全な Kubelet レジストリなど) とアプローチ (特にセルフホスティング) により、このようなツールに必要なカスタム オーケストレーションの量は削減されます。

その後、Kubernetes エコシステムを構築し、関連するソリューションを統合して、上記のニーズを満たすことを目指しています。

マトリックス管理

オプション、構成可能なデフォルト、拡張機能、プラグイン、アドオン、プロバイダー固有の機能、バージョン管理、機能の検出、依存関係の管理。

Kubernetes はオープンソースのツールボックスであるだけでなく、一般的なクラスターやサービスの運用環境でもあります。 Kubernetes では、ほとんどのユーザーとユースケースがアップストリーム バージョンを使用することが想定されているため、Kubernetes は再構築することなくさまざまなシナリオを処理できるほど拡張可能である必要があります。

拡張性のギャップがコードフォークの主な要因であり、上流のクラスターライフサイクル管理ソリューションのギャップが現在の Kubernetes ディストリビューションの主な要因であった一方で、オプション機能 (アルファ API、プロバイダー固有の API など)、構成可能性、プラグイン可能性、拡張性の存在により、このコンセプトは避けられないものとなっています。

ただし、ユーザーが Kubernetes 上でアプリケーションをデプロイおよび管理できるようにし、開発者が Kubernetes クラスター上に Kubernetes 拡張機能を構築できるようにするには、Kubernetes クラスターまたはディストリビューションについて想定できる必要があります。基本的な前提が満たされない場合は、利用可能な機能を発見し、使用するための機能要件 (依存関係) を表現する方法を見つける必要があります。

アドオンを含むクラスター コンポーネントは、コンポーネント登録 API を介して登録し、/componentstatuses を介して検出する必要があります。

組み込み API、集約 API、登録済みのサードパーティ リソースを、検出および OpenAPI (Savigj.JSON) エンドポイント経由で検出できるようにします。前述のように、LoadBalancer タイプのサービスのクラウド サービス プロバイダーは、ロード バランサー API が存在するかどうかを判断する必要があります。

StorageClass と同様に、拡張機能とそのオプションは FoeClass リソースを介して登録する必要があります。ただし、fooClassName は、パラメータの説明、型 (整数と文字列など)、検証の制約 (ranger または regexp など)、およびデフォルト値を使用して拡張 API から参照されます。これらの API は、動的ストレージ ボリュームのプロビジョニング (空でない storageclass.provisioner フィールドで示される) などの関連機能の存在を構成/公開し、担当するコントローラーを識別する必要があります。このような API は、少なくともスケジューラ クラス、イングレス コントローラ クラス、Flex ストレージ ボリューム クラス、コンピューティング リソース クラス (GPU、その他のアクセラレータなど) に追加する必要があります。

既存のネットワーク ストレージ ボリュームをフレックス ストレージ ボリュームに変換すると、この方法ではストレージ ボリューム ソースが上書きされます。将来的には、LoadBalancer サービスのように抽象化をすべての環境に実装する必要がない場合でも (つまり、API が最も一般的な機能に対応する必要がない場合でも)、API は汎用の抽象化のみを提供する必要があります。

NIY: 登録と発見のために以下のメカニズムを開発する必要があります。

• 入場制御プラグインとフック（組み込み API を含む）
• 認証プラグイン
• 認証プラグインとフック
• 初期化とファイナライザ
• スケジューラ拡張機能
• ノードラベルとクラスタートポロジ

NIY: 単一の API およびきめ細かい機能のアクティブ化/非アクティブ化は、次のメカニズムによって解決できます。

• すべてのコンポーネントの構成は、コマンド ライン フラグからバージョン管理された構成に変換されています。
• 動的な再構成、段階的なロールアウト、およびイントロスペクションを容易にするために、ほとんどの構成データを ConfigMap に保存することが意図されています。
• すべての/複数のコンポーネントに共通する構成は、独自の構成オブジェクトに分離する必要があります。これには機能ゲートウェイ メカニズムが含まれる必要があります。
• 応答しないノード上の Pod を削除する前に待機するデフォルトの時間など、意味的に意味のある設定用の API を追加する必要があります。

NIY: 複数のコンポーネント (HA クラスター内の同じコンポーネントのレプリカを含む) のアップグレードに依存するバージョン管理操作の問題は、次の方法で対処する必要があります。

• すべての新機能にフラグゲートウェイを作成する
• これらの機能は、最初に登場したマイナー バージョンでは常にデフォルトで無効になっています。
• 機能を有効にするための構成パッチを提供します。

これらの機能は、次のマイナー リリースではデフォルトで有効になります。

• NIY: また、古くなったノードに警告したり、ノードがアップグレードされるまでマスターのアップグレード (パッチ リリースを除く) を防止したりするメカニズムも必要です。
• NIY: フィールド レベルのバージョン管理により、新しい API フィールドやアルファ API フィールドの大量アクティブ化、不適切に記述された古いクライアントによる新しいフィールドのブロックの防止、成熟した API 定義の増殖を伴わない非アルファ API の進化などのソリューションが容易になります。

Kubernetes API サーバーは、サポートされていないリソース フィールドとクエリ パラメータを無視しますが、不明な API や未登録の API は無視しません (実装されていない API や非アクティブな API は無効になっていることに注意してください)。これにより、クラスターの複数のバージョン間で構成を再利用できるようになりますが、予期しない結果が生じることもよくあります。 Kubctl は、サーバーの Wagger/OpenAPI 仕様を使用したオプションの検証をサポートしています。このようなオプションの検証は、サーバー (NYY) によって提供される必要があります。さらに、ユーザーの利便性のために、共有リソース マニフェストでは、kubectl やその他のクライアントによって検証できる最小の Kubernetes バージョン要件を指定する必要があります。

サービス カタログ メカニズム (NIY) は、S3 互換のクラスター ストレージなどのアプリケーション レベルのサービスが存在することをアサートできる必要があります。

安全関連システムの階層化

Kubernetes クラスターを適切に保護し、安全に拡張できるようにするには、システムのコンポーネントによっていくつかの基本概念が定義され、合意される必要があります。 ***セキュリティの観点から見ると、Kubernetes は一連のリングであり、各レイヤーが後続のレイヤーに機能を提供するものと考えてください。

• コア API を保存するための 1 つ以上のデータ ストレージ システム (etcd)
• コアAPI
• 信頼性の高いリソース用の API (システム ポリシー)
• 委任された信頼 API とコントローラ (ユーザーは、ユーザーに代わってアクションを実行するために API/コントローラへのアクセスを許可します)、クラスター全体またはより狭い範囲で
• 信頼できない/スコープ指定されたAPIとコントローラおよびユーザーワークロードを異なるスコープで実行する

下位層が上位層に依存すると、セキュリティ モデルが崩壊し、システムが複雑になります。管理者は操作の簡素化のためにこれを行うことを選択できますが、これは意識的な選択でなければなりません。簡単な例としては、etcd が挙げられます。etcd にデータを書き込むことができるすべてのコンポーネントがクラスター全体に存在し、あらゆるアクター (信頼性の高いリソースを侵害できるユーザー) がほぼどこからでも段階的なアップグレードを実行できます。実際には一部がクラッシュする可能性があっても、上記のレイヤーをプロセスの各レイヤー (etcd->apiservers+controller->コア セキュリティ拡張->委任拡張->ユーザー ワークロード) ごとに異なるマシン セットに分割します。

上記のレイヤーが同心円を定義する場合、重複する円や独立した円が存在することも可能です。たとえば、管理者は、クラスター ワークロードはアクセスできるが、プラットフォームは暗黙的にアクセスできない代替のシークレット ストレージ ソリューションを選択できます。これらの円の交点はワークロードを実行するマシンである傾向があり、ノードには通常の機能に必要な権限以上の権限があってはなりません。

最後に、どのレイヤーでも拡張機能を介して新しい機能を追加する場合は、その動作の影響を伝えるためにベスト プラクティスに従う必要があります。

拡張機能を介してシステムに機能を追加すると、その目的は何ですか？

• システムをより安全にします
• クラスター内のすべての人に新しい「生産品質」APIを有効にする
• クラスターのサブセットで共通のタスクを自動化する
• ユーザーにAPIを提供する管理されたワークロード（Spark、データベースなど）を実行します

それらは3つの主要なカテゴリに分かれています。

1. クラスタリングに必要な（したがって、コアの近くで実行する必要があり、障害の存在下で運用上のトレードオフが発生する必要があります）
2. すべてのクラスターユーザーにさらされる（適切にリースする必要があります）
3. クラスターユーザーのサブセットにさらされます（従来の「アプリケーション」ワークロードのように実行されます）

管理者を簡単にだまして拡張中に新しいクラスターレベルのセキュリティルールをインストールできる場合、レイヤー化は壊れてシステムが脆弱です。

この記事の翻訳者は、Beijing Shenzhou Aerospace Software Technology Co.、LtdのプロダクトマネージャーであるJi Xiangyuanです。