Kubernetes コンテナ プラットフォーム アーキテクチャの解釈

1. Kubernetesコンテナプラットフォームアーキテクチャの解釈

Kubernetes は、大規模な分散コンテナ化されたソフトウェア アプリケーションを管理するオープン ソースのコンテナ オーケストレーション プラットフォームです。これは、クラウド コンピューティングの開発と進化における革命的な進歩です。 Kubernetes は、Borg の独自のコントローラと Omega の柔軟なスケジューラを組み合わせた、Google の第 3 世代コンテナ管理システムです。 Kubernetes 内のアプリケーションは、環境から完全に分離されたコンテナ イメージにパッケージ化され、アプリケーションを自動的に構成し、リソース割り当ての追跡を維持します。

Kubernetes は、アプリケーション中心の技術アーキテクチャとコンセプトです。インフラストラクチャの違いを下位レベルで保護し、基礎となる基本リソースの統一されたスケジュールとオーケストレーションを実現します。コンテナ イメージを通じてアプリケーションを上位に標準化し、アプリケーション ロードの自動展開を実現します。中間では、クラウドネイティブのオペレーティング システム機能を構築し、Kubernetes の一般的なオーケストレーション機能、オープン API、カスタム CRD 拡張機能を通じて新しいクラウド コンピューティング インターフェイスを形成します。これにより、R&D チームは、標準化され、弾力性があり、信頼性が高く、疎結合で、管理と保守が容易なアプリケーション システムを迅速に構築し、配信効率を向上させ、運用と保守の複雑さを軽減できます。 Kubernetes には、技術アーキテクチャの観点から 3 つの機能があります。

俊敏で柔軟なスケーリング機能: 数分単位でしかスケールアップおよびスケールダウンできない仮想マシンとは異なり、コンテナ アプリケーションは数秒、さらには数ミリ秒単位でスケールアップおよびスケールダウンできます。

インテリジェントなサービス障害の自己修復機能: コンテナ アプリケーションは非常に強力な自己修復機能を備えており、アプリケーション障害の自動除去と再構築を実現できます。

大規模なレプリケーションおよび配信機能: コンテナ アプリケーション向けの標準化された配信製品により、クロスプラットフォーム、クロスリージョン、クラウド エッジ統合の大規模なレプリケーション、配信、および展開機能を実現できます。

1.1. Kubernetes の全体的なアーキテクチャ

Kubernetes は、集中管理ノード (マスター ノード)、分散ワーカー ノード (ワーカー ノード)、および補助ツールで構成される、典型的なマスター スレーブ分散アーキテクチャです。

集中管理ノードはクラスターのスケジュールと管理を行います。これには 4 つのコア コンポーネントがあります。

API サーバー: クラスターのゲートウェイとして機能し、外部ユーザー向けの統合認証および承認サービスを実装し、ノード/ポッド リソース プロキシ チャネルも管理します。

スケジューラ: リソース スケジューラ。デフォルトの Kubernetes スケジューラに加えて、カスタム スケジューラもサポートします。

ETCD: クラスター ステータスの統合ストレージ、Zookeeper に似たキー値ストレージ。

コントローラ マネージャー: コントローラ マネージャーは、自己修復、容量拡張、アプリケーション ライフサイクル管理、サービス検出、ルーティング、サービス バインディングなどの機能を実装します。 Kubernetes は、レプリケーション コントローラー、ノード コントローラー、名前空間コントローラー、サービス コントローラー、エンドポイント コントローラー、永続コントローラー、デーモンセット コントローラーなどのコントローラーをデフォルトで提供します。

ビジネス アプリケーション コンテナーを実行する分散ワーカー ノード。デフォルトでは、次の 3 つのコア コンポーネントが実行されます。

Kubelet: 管理ノードと通信してコマンドの実行をトリガーし、ドライバー ネットワーク、ストレージ、コンテナー ランタイムを管理します。

Kube Proxy: DNS を介してサービス検出を実装し、iptables ルールを使用してサービス IP へのアクセスをガイドし、適切なバックエンド アプリケーションにリダイレクトして、高可用性の負荷分散機能を実現します。

コンテナ ランタイム: コンテナ ランタイム。 Kubernetes プラットフォームの適応性を拡大し、エコシステム全体を標準化するために、CNI および CSI 標準を使用してネットワークとストレージの拡張を標準化します。 CRI および OCI 標準は、コンテナ イメージとコンテナ ランタイムの拡張を標準化するために使用されます。現在、CRI でサポートされているコンテナ ランタイムには、docker、rkt、cri-o、frankti、kata-containers、clear-containers が含まれます。

主にクラスタ管理とネットワーク拡張を支援する補助ツール:

kubectl は、API サーバーと対話してクラスター管理を実装するコマンドライン ツールです。

ダッシュボードは、Kubernetes の Web ユーザー管理および監視インターフェースです。

Core DNS は、クラスター サービス検出機能を実装するスケーラブルな DNS サーバーです。

1.2.Kubernetesのコアコンセプト

1.2.1. Kubernetes の最小のスケジューリング単位である POD コンテナ グループ

Pod は、Kubernetes の最小のスケジューリングおよびリソース割り当て単位です。ポッドは互いに分離されています。通常、Pod 内では 1 つのコンテナのみを実行することをお勧めします。いくつかのコンテナが密接に結合されている場合、複数のコンテナを同じ Pod で実行して、スケジュールと管理を簡単に行うことができます。 Pod は実行中のアプリケーションのインスタンスです。アプリケーションの水平スケーラビリティは、複数の Pod を同時に実行することによって実現されます。ポッド自体には自己回復機能はありません。スケジュールまたは操作が失敗した場合、管理ノードのコントローラーは、Pod の再起動、再構築、移行などの操作を実行するために構成をトリガーする必要があります。

Pod の起動プロセスの観点から見ると、Pod コンテナは主に、一時停止コンテナ、初期化コンテナ、アプリ コンテナの 3 種類のコンテナで構成されます。

一時停止コンテナ: インフラコンテナとも呼ばれます。 Pod は Pause Container を使用して、Pod の複数のコンテナ間でのネットワーク共有を実現します。一時停止コンテナが最初に起動され、ポッドの一意の IP アドレスとさまざまなネットワーク リソースにバインドされます。他のコンテナは、Pause Container の Network 名前空間に参加することでネットワーク共有を実現します。 Pause は C 言語で実装されています。画像は非常に小さく、約 700 KB しかなく、常に一時停止状態になっています。公式イメージは gcr.io/google_containers/pause-amd64:3.0 で、カスタマイズもサポートされています。

Init コンテナ: Pod 内の 1 つ以上の Init コンテナをカスタマイズし、順番に起動できます。これらはアプリケーション コンテナーの前に起動され、スクリプトの実行、共有ディレクトリへのファイルのコピー、ログの収集、アプリケーションの監視などの補助的なタスクを実行します。補助機能をメインのビジネス コンテナーから分離して、独立したリリースと機能の再利用を実現します。 Readiness Probe をサポートしていないことを除いて、その他の機能は通常のコンテナと一致しています。

アプリコンテナ: Pod の業務を実際に実行するコンテナ。通常は独立して実行されます。マイクロサービスガバナンスなどの要件がある場合は、Sidecar Container と一緒に実行されます。 Init コンテナが起動すると、App コンテナが並行して起動されますが、すべての App コンテナが準備完了状態になるまで、Pod 全体は正常に起動されません。

POD リソースの分離の観点から見ると、Pod コンテナは主に Linux が提供する Namespace および Cgroup 機能によって実装されます。名前空間はプロセス間の分離を実装し、Cgroup はプロセス リソースの制御を実装します。名前空間は、ipc、uts、net、mnt、pid などのさまざまなリソース空間で構成されます。

CRI は Kubernetes v1.5 で導入され、Kubelet をコンテナ ランタイムから分離します。 CRI は、コンテナとイメージのサービス インターフェースを定義します。コンテナのランタイムとイメージのライフサイクルは互いに分離されているため、RuntimeService と ImageService という 2 つのサービスが定義されています。 RuntimeService には主に、Sandbox と Container の管理 gRPC インターフェースが含まれます。サンドボックスは、上記の Pod 起動プロセスで説明した一時停止コンテナーです。現在、CRI をサポートするバックエンドには、cri-o、cri-containerd、rkt、frakti、docker が含まれます。 cri-o は、RedHat によって開始され、オープンソース化されたコミュニティ主導のコンテナ ランタイムです。軽量で、Kubernetes 専用に設計されています。その主な目的は、Kubernetes クラスターのコンテナ ランタイムとして Docker を置き換えることです。

1.2.2.ボリュームストレージ、Kubernetes の複雑なストレージアーキテクチャ

ストレージは非常に重要であり、エコシステムとテクノロジーの両方が比較的複雑な分野でもあります。 Linux と Windows のエコシステムだけでも 20 を超えるファイル システムをサポートしています。 Kubernetes ストレージ アーキテクチャの設計は継続的に進化し、改善されてきました。できるだけ多くのストレージ プラットフォームとの互換性を確保するために、Kubernetes はデフォルトでツリー内プラグインの形式でさまざまな種類のストレージ システムに接続します。また、カスタム ストレージ サービスを実装するための FlexVolume および CSI プラグインに基づくツリー外プラグインもサポートします。

Kubernetes ストレージの場合、基本的なアプリケーション構成ファイルの読み取りとパスワード キーの管理という 3 つの主な使用シナリオがあります。アプリケーションのストレージ状態、データ アクセス、および異なるアプリケーション間のデータ共有。現在 Kubernetes でサポートされているボリューム プラグインは次のとおりです。

空のディレクトリ: ライフサイクルは Pod のライフサイクルと一致します。 Pod が削除されると、emptyDir 内のデータは自動的にクリアされます。現在、emptyDir は、メモリ、ラージ ページ メモリ、およびノー​​ド上で Pod が配置されているファイル システムのタイプをサポートしています。

ConfigMap: 主に Springboot アプリケーションのプロパティ構成ファイル データなどのアプリケーション構成データを格納する構成センターとして使用されますが、スペース サイズは 1 MB に制限されています。

Secret: ConfigMap と同様に、データ パスワード、トークン、証明書などの機密アプリケーション データを保存するために使用されます。ConfigMap と組み合わせて使用​​でき、サイズも 1 MB に制限されています。

HostPath: Node ノードのローカル ファイル システム パスをポッド コンテナーにマッピングして使用します。 emptyDir との違いは、Pod が削除された後、ユーザーの設定によっては HostPath 内のデータがクリアされない可能性があることです。

ツリー内ネットワーク ストレージ: ネットワーク ストレージは Pod のライフ サイクルに従い、ストレージ プラグインを通じてさまざまな種類のストレージに接続します。 FlexVolume では、カスタム開発ドライバーがポッドで使用するためにボリュームをクラスターノードにマウントできますが、そのライフサイクルはポッドと同期されます。

PersistentVolumeClaim ネットワーク ストレージ: 独立したライフ サイクルを持ち、ストレージ アウトツリー プラグインを通じてさまざまな種類のストレージに接続できます。現在サポートされているストレージ プラグインの種類には、FlexVolume と CSI が含まれます。

PV、PVC、StorageClass の導入により、リソースの管理と制御がより柔軟になり、チームの責任が明確になり、R&D 担当者は基盤となるストレージの詳細に注意を払うことなく、ストレージ要件 (IO、容量、アクセス モードなど) のみを考慮する必要があります。複雑な基礎の詳細はすべて、プロのクラスタ管理およびストレージ管理者によって完了されます。

CSI は、コンテナにストレージ サービスを提供する一連の標準ストレージ管理インターフェイスを確立するために、Kubernetes バージョン 1.9 で導入されました。これにより、Kubernetes プラットフォームとストレージ サービス ドライバーを完全に分離できるようになります。 CSI は主に、CSI コントローラー サーバーと CSI ノード サーバーの 2 つの部分で構成されます。コントローラ サーバーは主に、作成、削除、マウント、アンマウントなどの制御機能を実装します。 Node Server は主に Node ノードのマウントおよびアンマウント操作を実装します。

CSI コントローラー サーバーと外部 CSI SideCar は Unix ソケットを介して通信します。 CSI ノード サーバーと Kubelet も Unix ソケットを介して通信します。 CSI 実装クラスもますます充実してきています。たとえば、ExpandCSIVolumes はファイル システムの拡張を実現できます。 VolumeSnapshotDataSource はデータ ボリュームのスナップショットを実現できます。 VolumePVCDataSource はカスタム PVC データ ソースを実装します。 CSIInlineVolume は、Volume 内のいくつかの CSI ドライバーを定義します。 Alibaba Cloud には、Alibaba Cloud Disk、NAS、CPFS、OSS、LVM などのオープンソースの CSI ストレージ プラグインもあります。

1.2.3. IngressとService、繁栄するKubernetesネットワーク

Kubernetes コンテナ ネットワークは非常に複雑で、Pod ネットワーク、サービス ネットワーク、クラスター IP、NodePort、LoadBalancer、Ingress など、多くの概念が関係します。このため、Kubernetes ネットワーク参照 TCP/IP プロトコル スタックは 4 つのレイヤーに抽象化されています。

レイヤー 0: ノード ネットワークは比較的単純です。これは、Kubernetes ノード (物理マシンまたは仮想マシン) 間の通常の IP アドレス指定と相互通信を保証するネットワークです。これは通常、基盤となる (パブリック クラウドまたはデータ センター) ネットワーク インフラストラクチャによってサポートされます。

レイヤー 1: Pod は Kubernetes の最小のスケジューリング単位です。 Pod ネットワークは、Kubernetes クラスター内のすべての Pod (同じノード上の Pod と異なるノード上の Pod を含む) が論理的に同じプレーン ネットワークにあり、相互に IP アドレスを割り当てて通信できることを保証します。これはコンテナ ネットワークの最も複雑な部分です。さまざまなコンテナ ネットワーク プラグインを通じてさまざまなネットワーク要件を満たし、CNI 標準化を通じてネットワークのカスタマイズ機能を実現します。

レイヤー 3: 各 Pod には IP がありますが、同一 Pod のグループに対する統一された安定したアクセス アドレスの問題を解決し、バックエンド Pod アプリケーション サービスにリクエストを均等に分散するために、Pod のライフサイクルと一致しています。 Kubernetes は、サービス検出および負荷分散機能を実装するためにサービス ネットワークを導入します。基礎レイヤーは、Kube-Proxy+iptables 転送を通じて実装されます。これは、アプリケーションに非侵入的で、プロキシを貫通せず、追加のパフォーマンス損失もありません。

レイヤー 4: Kubernetes サービス ネットワークはクラスターの内部ネットワークであり、クラスターの外部からはアクセスできません。内部サービスにアクセスするには、外部に公開する必要があります。 Kubernetes は、NodePort、LoadBalancer、Ingress を通じて外部ネットワーク アクセス機能を構築します。

CNI は、CoreOS によって最初に開始されたコンテナ ネットワーク仕様であり、Kubernetes ネットワーク プラグインの基礎となっています。コンテナを作成する際、Container Runtime は最初にネットワーク名前空間を作成し、次に CNI プラグインを呼び出してネットワーク名前空間のネットワークを構成し、最後にコンテナ内でプロセスを開始します。 CNI プラグインは、CNI プラグインと IPAM プラグインの 2 つの部分で構成されています。

CNI プラグイン: 2 つの基本インターフェースを含むコンテナ ネットワークの構成と管理を担当します。

ネットワーク構成: AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)

ネットワークのクリーンアップ: DelNetwork(net NetworkConfig, rt RuntimeConf) エラー

IPAM プラグイン: ホストローカルおよび DHCP を含むコンテナ IP アドレスの割り当てを担当します。

コンテナネットワーク技術も進化と発展を続けています。コミュニティには、Flannel、Calico、Cilium、OVN など、多くのオープンソース ネットワーク コンポーネントが存在します。各コンポーネントには独自の利点と適用可能なシナリオがあり、統一されたコンポーネントとソリューションを形成することは困難です。

1.2.4.ワークロード、Kubernetes アプリケーション中心のコンセプト

Kubernetes は、ワークロードを通じてアプリケーションの管理、展開、リリースを実装することで、Kubernetes のアプリケーション中心の概念を実装します。 Kubernetes は、さまざまなシナリオのニーズを満たすために、Deployment、StatefulSet、ReplicaSet、Job、CronJob、DaemonSet など、複数のタイプのワークロードをサポートしています。

デプロイメントとレプリカセット: ステートレス アプリケーションを管理およびデプロイするには、元の ReplicationController オブジェクトを置き換えます。 Deployment は異なるバージョンの ReplicaSet を管理し、ReplicaSet は同じバージョンの Pod を管理します。 ReplicaSet の最終的なコピー数は、デプロイメントを通じて調整されます。コントローラーは、実行中のポッドの実際の数を予想される数と一致させ、ポッドに障害が発生した場合は自動的に再起動または回復します。

StatefulSet: ステートフル アプリケーションを管理およびデプロイします。作成されたポッドには、仕様に従って作成された永続的な識別子が付けられます。識別子は、Pod が移行または破棄されて再起動された後も保持されます。たとえば、各 Pod にはシリアル番号があり、シリアル番号によって作成、更新、または削除できます。 Pod には一意のネットワーク識別子 (ホスト名) または専用のストレージ PV があり、グレースケールのリリースなどをサポートします。

DaemonSet: 監視やログ収集など、各ノードで実行されるデーモン タスクを管理および展開します。新しく追加されたノードも実行され、削除されたノードは削除する必要があります。タグを指定してノードを実行することも可能です。

ジョブと Cronjob: ジョブは、1 つ以上のポッドを作成し、ポッドが正常に実行されるか終了するかを監視できる 1 回限りのタスクです。 Pod の状態に基づいて、繰り返し回数、同時実行数、再起動戦略を設定します。 Cronjob は、実行時間、待機時間、並列実行の有無、実行回数を指定できるスケジュールジョブです。

Kubernetes エコシステムには、追加の操作を提供するサードパーティのワークロードもいくつかあります。 CRD を使用してワークロードをカスタマイズすることもできます。また、デバイス プラグインによって駆動されるハードウェア ワークロードもありますが、これについては後続の章で詳しく説明します。

1.2.5.コントローラー、Kubernetes集中制御管理センター

Kubernetes の集中制御センターとして、コントローラー マネージャーは、クラスターのノード、ポッド レプリカ、サービス エンドポイント、名前空間、サービス アカウント、およびリソース クォータのリソース管理を担当します。 API サーバー インターフェースを通じて、クラスター内の各リソース オブジェクトの状態をリアルタイムで監視します。障害が発生してシステムの状態が変化すると、システムは直ちにそれを「予想される状態」に修復しようとします。

レプリケーション コントローラー: クラスター内の RC に関連付けられた Pod レプリカの数が常に事前設定された値のままであることを確認します。

ResourceQuota コントローラー: Kubernetes 内のリソース オブジェクトが常に過剰なシステム物理リソースを占有しないようにします。コンテナ、ポッド、名前空間の 3 つのレベルがあります。

名前空間コントローラー: API サーバーを通じて名前空間情報を定期的に読み取ります。名前空間が API によって正常に削除されたとマークされている場合 (つまり、削除の期限 DeletionTimestamp が設定されている場合)、名前空間のステータスは「終了中」に設定され、etcd に保存されます。同時に、Namespace の下の ServiceAccount、RC、Pod などのリソース オブジェクトを削除します。

エンドポイント コントローラー: エンドポイントは、サービスに対応するすべての Pod コピーのアクセス アドレスです。エンドポイント コントローラーは主に、サービスと対応するポッド コピーの変更を監視し、エンドポイント オブジェクト コントローラーを生成および維持する役割を担います。

デプロイメント コントローラー: デプロイメントは ReplicaSet を制御し、ReplicaSet は Pod を制御します。デプロイメント コントローラーは、目的の状態を制御します。デプロイメント コントローラーは、DeploymentInformer、ReplicaSetInformer、および PodInformer の 3 つのリソースを監視します。

さらに、Kubernetes v1.6では、Alibabaパブリッククラウドの基本製品とのドッキングをサポートするためにCloud Controller Manager（CCM）が導入されました。これについては後で詳しく説明します。

1.3.まとめ

まとめると、Kubernetes は強力なコンテナ オーケストレーション システムであるだけでなく、ツールとサービスの巨大なエコシステム、クラウド ネイティブ時代のオペレーティング システムを推進し、クラウド コンピューティングの新しいインターフェイスを形成します。

設計コンセプトの観点から見ると、Kubernetes はアプリケーション中心のコンセプトです。インフラストラクチャの違いを下位レベルで保護し、基盤となる基本リソースの統一されたスケジューリングとオーケストレーションを実現します。コンテナイメージを通じてアプリケーションを上位に標準化し、アプリケーション負荷の自動展開を実現します。中間では、Kubernetes の一般的なオーケストレーション機能、オープン API、カスタム CRD 拡張機能を使用します。

技術的なアーキテクチャの観点から見ると、Kubernetes は、マスター制御ノードと水平にスケーラブルなワーカーノードで構成される、典型的な分散マスター スレーブ アーキテクチャです。マスターは集中制御と管理を実装し、ワーカーは分散操作を実装します。これは、Openstack アーキテクチャや SpringCloud をベースに開発されたマイクロサービス ビジネス アプリケーションとほとんど変わりません。

設計パターンの観点から、Kubernetes は多数のモデル (プリミティブ、リソース オブジェクト、構成、一般的に使用される CRD) を定義し、構成管理モデルを通じてクラスター リソース制御を実装します。モデルは複雑ですが、レイヤー（コア層、分離およびサービス アクセス層、スケジューリング層、リソース層）ごとに段階的に理解することができます。

プラットフォーム拡張の点では、Kubernetes は API、オープン スタンダード (CNI、CSI、CRI など)、CRD が開発されたオープンで拡張可能なプラットフォームです。単なるランタイムプラットフォームではなく、運用・保守のための開発プラットフォームでもあります。

この記事はWeChatの公開アカウント「Juzijia」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合はJuzijia公式アカウントまでご連絡ください。