オペレーター必読: Kubernetes プラットフォームアーキテクチャ

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

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

アジャイルで弾力性のあるスケーリング機能: 数分で弾力的なスケーリング応答を実現できる仮想マシンとは異なり、コンテナアプリケーションは数秒、さらには数ミリ秒で弾力的なスケーリング応答を実現できます。
インテリジェントなサービス障害自己修復機能: コンテナアプリケーションには非常に強力な自己修復機能があり、アプリケーションの障害を自動的に削除して再構築できます。
大規模なレプリケーションおよび配信機能: コンテナアプリケーションの標準化された配信製品は、クロスプラットフォーム、クロスリージョン、クラウドエッジ統合の大規模なレプリケーション、配信、展開機能を実現できます。

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

Kubernetesは典型的な マスタースレーブ分散アーキテクチャ、 による集中管理ノード（マスターノード）、分散ワーカーノード（ワーカーノード）同様に 補助ツール 構成。

1. 集中管理ノード

クラスターのスケジュールと管理を行う集中管理ノード。 4 つのコアコンポーネント:

API サーバー: クラスターゲートウェイの役割を引き受け、外部ユーザー向けの統合認証および承認サービスを実装し、ノード/ポッドリソースプロキシチャネルも管理します。
スケジューラ: リソーススケジューラは、Kubernetes のデフォルトのスケジューラに加えて、カスタムスケジューラもサポートします。
など: クラスターのステータスは、Zookeeper のキー値ストレージと同様に均一に保存されます。
コントローラーマネージャー: コントロールマネージャーは、自己修復、容量拡張、アプリケーションライフサイクル管理、サービス検出、ルーティング、サービスバインディングなどの機能を実装します。 Kubernetes は、レプリケーションコントローラー、ノードコントローラー、名前空間コントローラー、サービスコントローラー、エンドポイントコントローラー、永続コントローラー、デーモンセットコントローラーなどのコントローラーをデフォルトで提供します。

2. 分散作業ノード

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

クベレット: 管理ノードと通信してコマンドの実行をトリガーし、ドライバーネットワーク、ストレージ、コンテナーランタイムを管理します。
Kube プロキシ: サービス検出は DNS を通じて行われ、アクセスは iptables ルールの助けを借りてサービス IP に向けられ、高可用性の負荷分散機能を実現するために適切なバックエンドアプリケーションにリダイレクトされます。
コンテナランタイム: コンテナランタイム。 Kubernetesプラットフォームの適応性を拡大し、エコシステム全体を標準化するために、 ネットワークとストレージのCNIおよびCSI標準 拡大の CRIとOCIはコンテナイメージとコンテナランタイムを標準化します 拡大;現在、CRI は docker、rkt、cri-o、frankti、kata-containers、clear-containers などのコンテナランタイムをサポートしています。

3. 補助ツール

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

kubectl APIサーバーの相互作用を通じて、 クラスター管理用のコマンドラインツール。
ダッシュボードそれはKubernetesのウェブです ユーザー管理監視インターフェース。
コアDNS これは、スケーラブルなDNSサーバーであり、 クラスターサービス検出機能。

2. Kubernetes のコアコンセプト

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

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

ポッドの起動プロセスから、ポッドコンテナは主に コンテナの一時停止、コンテナの初期化 同様に アプリコンテナ 3 種類のコンテナ:

一時停止コンテナ: インフラコンテナとも呼ばれる Pod は、Pause Container を使用して Pod 内の複数のコンテナのネットワークを共有します。一時停止コンテナが最初に起動され、ポッドの一意の IP アドレスとさまざまなネットワークリソースがバインドされます。他のコンテナは一時停止に参加することで開始されますコンテナのネットワーク名前空間は、ネットワーク共有を実現するために使用されます。 Pause は C 言語で実装されています。画像は非常に小さく、約 700 KB しかなく、常に一時停止状態になっています。公式イメージは gcr.io/google_containers/pause-amd64:3.0 で、カスタマイズもサポートされています。
初期化コンテナ: 1つ以上のカスタムポッドを使用できます 初期化コンテナ 、 順番に始める コンテナを適用する前に、スクリプトの実行、共有ディレクトリへのファイルのコピー、ログの収集、アプリケーションの監視など、いくつかの補助タスクを開始および実行します。補助機能をメインのビジネスコンテナから分離して、独立したリリースと機能の再利用を実現します。 Readiness Probe をサポートしていないことを除いて、その他の機能は通常のコンテナと一致しています。
アプリコンテナ: ポッドの業務を実際に行うコンテナは、通常は独立して稼働します。マイクロサービスガバナンスが必要な場合は、サイドカーコンテナーと一緒に実行されます。初期化コンテナが起動したら、 アプリコンテナーは並行して起動します。 しかし、すべてを待つ必要があります アプリコンテナ Pod 全体は、Ready 状態にある場合にのみ正常に起動したと見なされます。

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

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

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

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

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

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

構成マップ: 主に、Springboot アプリケーションプロパティ構成ファイルデータなどのアプリケーション構成データを保存するための構成センターとして使用されますが、スペースサイズは 1 MB に制限されています。
秘密：この機能はConfigMapに似ています。データパスワード、トークン、証明書など、アプリケーションの機密データを保存するために使用されます。ConfigMap と組み合わせて使用できます。スペースサイズも 1MB に制限されます。
ホストパス: 使用するには、Node ノードのローカルファイルシステムパスをポッドコンテナーにマップします。 emptyDir との違いは、Pod が削除された後、ユーザーの設定によっては HostPath 内のデータがクリアされない可能性があることです。
ツリー内ネットワークストレージ: ネットワークストレージは Pod のライフサイクルに従い、ストレージプラグインを通じてさまざまな種類のストレージに接続します。 FlexVolume では、カスタム開発ドライバーがポッドで使用するためにボリュームをクラスターノードにマウントできますが、そのライフサイクルはポッドと同期されます。
PersistentVolumeClaim ネットワークストレージ: 独立したライフサイクルを持ち、ストレージアウトツリープラグインを通じてさまざまなタイプのストレージに接続できます。現在サポートされているストレージプラグインの種類には、FlexVolume と CSI が含まれます。

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

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

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

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 を通じて外部ネットワークアクセス機能を構築します。

インド国立情報学研究所コンテナネットワーク仕様は 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 など、多くのオープンソースネットワークコンポーネントが存在します。各コンポーネントには独自の利点と適用可能なシナリオがあり、統一されたコンポーネントとソリューションを形成することは困難です。

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

クベネフィット 作業負荷 アプリケーションの管理、展開、リリースを実現し、Kubernetes のアプリケーション中心のコンセプトを実践します。 Kubernetes は、さまざまなシナリオのニーズを満たすために、Deployment、StatefulSet、ReplicaSet、Job、CronJob、DaemonSet など、複数のタイプのワークロードをサポートしています。

デプロイメントとレプリカセット: オリジナルを交換する レプリケーションコントローラ オブジェクト、管理展開 ステートレスアプリケーション Deployment は異なるバージョンの ReplicaSet を管理し、ReplicaSet は同じバージョンの Pod を管理します。デプロイメントを通じて ReplicaSet の最終的なコピー数を調整することにより、コントローラーは実行中の Pod の実際の数を予想される数と一致するように維持し、Pod に障害が発生した場合に自動的に再起動または回復します。
ステートフルセット: 展開の管理 ステートフルアプリケーション、 作成された Pod には、仕様に従って作成された永続的な識別子が付与されます。識別子は、Pod が移行または破棄されて再起動された後も保持されます。たとえば、各 Pod にはシリアル番号があり、シリアル番号によって作成、更新、または削除できます。 Pod には一意のネットワーク識別子 (ホスト名) または専用のストレージ PV があり、グレースケールのリリースなどをサポートします。
デーモンセット: 実行中の各ノードを管理および展開する ガーディアンミッション、 監視、ログ収集など。新しく追加されたノードも実行され、削除されたノードは削除する必要があります。タグを指定してノードを実行することも可能です。
ジョブと Cronjob: 仕事は1回限り タスク、 1 つ以上の Pod を作成し、Pod が正常に実行されるか終了するかを監視できます。 Pod の状態に基づいて、繰り返し回数、同時実行数、再起動戦略を設定します。 Cronjobは スケジュールされたスケジュール ジョブでは、実行時間、待機時間、並列実行の有無、実行数の制限を指定できます。

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

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

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

レプリケーションコントローラー: クラスター内の RC に関連付けられた Pod レプリカの数が常に事前設定された値のままであることを確認します。
リソースクォータコントローラー: Kubernetes 内のリソースオブジェクトが常に過剰なシステム物理リソースを占有しないようにします。コンテナ、ポッド、名前空間の 3 つのレベルがあります。
名前空間コントローラー: API サーバーを通じて定期的に名前空間情報を読み取ります。名前空間が API によって正常に削除されたとマークされている場合 (つまり、削除期間 DeletionTimestamp が設定されている場合)、名前空間のステータスは「終了中」に設定され、etcd に保存されます。同時に、Namespace の下の ServiceAccount、RC、Pod などのリソースオブジェクトを削除します。
エンドポイントコントローラー: エンドポイントは、サービスに対応するすべての Pod コピーのアクセスアドレスです。エンドポイントコントローラーは主に、サービスと対応するポッドコピーの変更を監視し、エンドポイントオブジェクトコントローラーを生成および維持する役割を担います。

デプロイメントコントローラー: デプロイメントは ReplicaSet を制御し、ReplicaSet は Pod を制御します。 デプロイメントコントローラー ドライバーが期待された状態に達すると、デプロイメントコントローラーは DeploymentInformer、ReplicaSetInformer、および PodInformer の 3 つのリソースを監視します。

さらにKubernetes v1.6では、 クラウドコントローラーマネージャー (CCM) Alibaba パブリッククラウド基本製品との接続をサポートします。

結論

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

デザインコンセプトの観点から、 Kubernetesは以下に基づいています アプリケーション中心 建設の概念、下インフラストラクチャの違いを遮断し、基盤となる基本リソースの統一されたスケジュールとオーケストレーションを実現します。上コンテナイメージを通じてアプリケーションを標準化し、アプリケーションロードの自動展開を実現します。 真ん中 Kubernetes の共通オーケストレーション機能、オープン API、カスタム CRD 拡張機能を通じて;

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

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

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

<<: QingCloudストレージが全面的にアップグレードされ、自社開発のQingStor U10000がさらなるデータ容量を解放

>>: オープンソースはイノベーションの可能性を刺激し、RHEL 9 は「イノベーションセンター」を定義します