このK8Sアーキテクチャ分析を書くのに10時間を費やしました

[51CTO.com からのオリジナル記事] インターネット技術の急速な発展に伴い、リクエストの高同時性とビジネスの多様性を処理するために、マイクロサービス アーキテクチャがすべての企業の標準になりました。

[[282303]]

画像はPexelsより

各マイクロサービスは Docker を通じてリリースされます。ビジネスが発展するにつれて、さまざまなコンテナがシステム全体に広がります。そのため、リソースのスケジュール、展開と運用、コンテナの容量の拡張と削減が、私たちが直面しなければならない問題となります。

Kubernetes は、コンテナ クラスターの管理プラットフォームとして広く使用されています。今日は、Kubernetes アーキテクチャの共通コンポーネントと動作原則を見てみましょう。

Kubernetes アーキテクチャの概要

Kubernetes はコンテナ クラスターを管理するためのプラットフォームです。管理クラスタなので、管理対象ノードが存在します。各 Kubernetes クラスターには、クラスター ノードの管理と制御を担当するマスターが存在します。

マスターを介して各ノードにコマンドを送信します。簡単に言えば、マスターは管理者であり、ノードは管理対象です。

ノードはマシンまたは仮想マシンになります。ノード上で複数のポッドを実行できます。 Pod は Kubernetes が管理する最小の単位で、各 Pod には複数のコンテナ (Docker) を含めることができます。

マスターとノードの関係は、次の Kubernetes アーキテクチャ図で確認できます。

Kubernetes アーキテクチャ図

通常、kubectl を介して Kubernetes にコマンドを発行し、APIServer を介してさまざまなプロセスを呼び出して、Node のデプロイと制御を完了します。

APIServer のコア機能は、コア オブジェクト (Pod、Service、RC など) を追加、削除、変更、およびクエリすることです。また、クラスター内のモジュール間のデータ交換のハブでもあります。

よく使われるAPI、アクセス（権限）制御、登録、情報保存（etcd）などの機能が含まれています。その下には、スケジュールされるポッドをノードにバインドし、バインド情報を etcd に書き込むスケジューラがあります。

etcd は APIServer に含まれており、リソース情報を保存するために使用されます。次はコントローラーマネージャーです。 Kubernetes が自動化されたシステムである場合、システムを制御するために一連の管理ルールが必要です。

コントローラー マネージャーはマネージャー、つまりコントローラーです。レプリカ、ノード、リソース、名前空間、サービスなどに対応する 8 つのコントローラーが含まれています。

次に、スケジューラはポッドをノードにスケジュールし、スケジュール後、kubelet がノードを管理します。

Kubelet は、マスターからノードに送信されたタスク (つまり、スケジューラのスケジュールタスク) を処理し、ポッドとポッド内のコンテナを管理するために使用されます。

リソースのスケジューリングが完了すると、kubelet プロセスは APIServer にノード情報を登録し、ノード情報をマスターに定期的に報告し、cAdvisor を通じてコン​​テナとノードのリソースを監視します。

マイクロサービスのデプロイメントは分散されるため、対応するポッドとコンテナのデプロイメントも分散されます。これらのポッドまたはコンテナを簡単に見つけられるように、リバース プロキシと負荷分散の実装を担当するサービス (kube-proxy) プロセスが導入されています。

上記は、Kubernetes アーキテクチャの簡単な説明であり、いくつかのコア概念と単純な情報フローが含まれています。

いくつかの機能は APIServer に含まれています。この図は、主に全員の記憶を容易にするために、公式ウェブサイトにある図よりも単純化されています。

後ほど、簡単な例を使って Kubernetes の概念の起源をより深く理解していただきます。

例から始める

Kubernetes を使用して 2 つのノードに Tomcat および MySQL サービスをデプロイすると仮定します。 Tomcat サービスは、水平拡張のために 2 つのインスタンス、つまり 2 つの Pod を生成します。

MySQL は 1 つのインスタンス、つまり 1 つの Pod のみをデプロイします。 Tomcat は外部ネットワークからアクセスでき、Tomcat は内部ネットワークから MySQL にアクセスできます。

例の図

ここではKubernetesとDockerのインストールが完了し、イメージファイルが準備されていることを前提としています。 Kubernetes がコンテナをデプロイおよび管理する方法に焦点を当てます。

kubectl と APIServer

上記の例が完了したので、2 つのアプリケーションをデプロイする必要があります。

まず、デプロイするアプリケーションに基づいてレプリケーション コントローラー (RC) を作成します。 RC は、アプリケーション レプリカの数、つまり Pod の数を宣言するために使用されます。

上記の例によると、Tomcat の RC は 2、MySQL の RC は 1 です。

kubectl は Kubernetes に指示を出すためのユーザー インターフェイスとして使用されるので、指示は「.yaml」構成ファイルに記述されます。

MySQL RC を記述する mysql-rc.yaml 構成ファイルを定義します。

 APIバージョン: V1
種類: レプリケーションコントローラ
メタデータ:
 name : mysql#RC の名前。グローバルに一意です。
仕様:
 replicas:1 #Podレプリカの予想数
セレクター:
アプリ:mysql
 テンプレート: #Pod テンプレート、このテンプレートを使用して Pod を作成します
メタデータ:
 ラベル:
 app:mysql#Podレプリカラベル
仕様:
 コンテナ:#コンテナ定義部分
     -名前:mysql
コンテナに対応するイメージ:mysql#DockerImage
      ポート:
      -containerPort:3306#コンテナアプリケーションがリッスンするポート番号
      Env:#コンテナに注入される環境変数
      -名前:MYSQL_ROOT_PASSWORD
      値:”123456”

上記の構成ファイルからわかるように、この RC の名前、予想されるコピー数、およびコンテナー内のイメージ ファイルを定義する必要があります。次に、クライアント CLI ツールとして kubectl を使用して、この構成ファイルを実行します。

kubectlを介してRC構成ファイルを実行する

上記のコマンドを実行すると、Kubernetes がレプリカ MySQL Pod をノードにデプロイするのに役立ちます。

この時点で結果を急いで確認しないでください。元のアーキテクチャ図に戻ると、kubectl がマスターの APIServer にコマンドを送信することがわかります。 APIServerの構造と情報の伝達について見てみましょう。

Kubernetes API サーバーは、マスター上で実行される kube-apiserver というプロセスを通じてサービスを提供します。

kube-apiserver プロセスには、REST サービスを提供するマスターのポート 8080 を介してアクセスできます。

したがって、コマンドライン ツール kubectl を介して Kubernetes API サーバーと対話することができ、それらの間のインターフェースは RESTful API です。

APIServer のアーキテクチャは、上から下に向かって 4 つのレイヤーに分かれています。

• API レイヤー: Kubernetes リソース オブジェクトの CRUD および Watch API をはじめ、ヘルス チェック、UI、ログ、パフォーマンス インジケーターなどの運用および保守監視に関連する API など、REST モードでさまざまな API インターフェースを主に提供します。
• アクセス制御層: ID 認証、リソースへのユーザー アクセス権の承認、アクセス ロジックの設定 (アドミッション コントロール) を担当します。
• レジストリ レイヤー: アクセスするリソース オブジェクトを選択します。 PS: Kubernetes は、Pod、Service、Deployment などのすべてのリソース オブジェクトをレジストリに保存します。
• etcd データベース: レプリカの作成に関する情報を保存します。 Kubernetes リソース オブジェクトを永続化するために使用されるキー値データベース。

APIServer 階層化アーキテクチャ図

kubectl が Create コマンドを使用して Pod を作成すると、API サーバーの API レイヤーを通じて対応する REST API メソッドが呼び出されます。

その後、権限制御層に入り、認証を通じて呼び出し元の ID を取得し、承認を通じて権限情報を取得します。

AdmissionControl で権限認証プラグインを構成して、プラグインを通じてリクエストの制約をチェックできます。たとえば、コンテナを起動する前にイメージをダウンロードしたり、特定の名前空間内のリソースを確認したりする必要があります。

mysql-rc.yaml で生成される Pod の数は 1 に設定されていることに注意してください。レジストリ レイヤーでは、作成される Kubernetes リソース オブジェクトとして、CoreRegistry リソースから Pod が取得されます。

次に、ノード、ポッド、コンテナの情報をetcdに保存します。ここでのetcdはクラスターになることができます。クラスター内の各ノード/ポッド/コンテナの情報を保存するため、必要に応じてバックアップするか、信頼性を保証する必要があります。

コントローラーマネージャー、スケジューラー、kubelet

以前は、kubectl を使用して、構成ファイルに従って API サーバーにコマンドを送信し、ノード上にポッドとコンテナーを作成していました。

APIServer では、プロセスは API 呼び出し、権限制御、リソース呼び出し、リソース保存を経由します。アプリケーションはまだ実際にはデプロイされていません。

展開プロセス全体を完了するには、コントローラー マネージャー、スケジューラー、および kubelet の支援が必要です。

共同作業を紹介する前に、Kubernetes のリスニング インターフェースを紹介する必要があります。上記の操作から、すべてのデプロイメント情報が etcd に書き込まれて保存されることがわかります。

実際、etcd はデプロイメント情報を保存するときに、APIServer に Create イベントを送信し、APIServer は etcd から送信されたイベントをリッスン (監視) します。他のコンポーネントも、APIServer によって送信されたイベントを監視 (監視) します。

Kubernetes は、上に示すように、この List-Watch メカニズムを使用してデータの同期を維持します。

• ここには 3 つの List-Watch があります。つまり、kube-controller-manager (マスター上で実行)、kube-scheduler (マスター上で実行)、および kublete (ノード上で実行) です。プロセスが開始されると、APIServer によって送信されるイベントをリッスン (監視) します。
• kubectl を使用して、コマンドラインから APIServer 上に Pod レプリカを作成します。
• このデプロイメント要求は記録され、etcd に保存されます。
• etcd は Pod 作成情報を受信すると、API サーバーに Create イベントを送信します。
• Kubecontrollermanager が APIServer のイベントをリッスンしているためです。このとき、APIServer は Create イベントを受信し、Kubecontrollermanager に送信します。
• Create イベントを受信した後、Kubecontrollermanager はレプリケーション コントローラーを呼び出して、ノード上に作成する必要があるレプリカの数を確認します。

上記の例では、MySQL アプリケーションにはレプリカが 1 つあり、Tomcat アプリケーションにはレプリカが 2 つあります。レプリカの数が RC で定義された数より少なくなると、レプリケーション コントローラは自動的にレプリカを作成します。つまり、レプリカの数を保証するのはコントローラーです。 PS: 容量の拡大と縮小の責任。

• コントローラー マネージャーが Pod レプリカを作成した後、APIServer は Pod の詳細情報を etcd に記録します。たとえば、ポッド内のレプリカの数やコンテナの内容などです。
• 同様に、etcd はイベントを通じて Pod の作成に関する情報を APIServer に送信します。
• Scheduler は APIServer をリッスン (監視) し、システム内で「ブリッジング」の役割を果たします。「ブリッジング」とは、作成された Pod イベントを受信し、それらのイベントに対応するノードを配置する役割を担うことを意味します。 「ブリッジング」とは、配置作業が完了した後、ノード上の kubelet サービス プロセスが後続の作業を引き継ぎ、Pod ライフサイクルの「後半」を担当することを意味します。

つまり、スケジューラの役割は、スケジューリングアルゴリズムと戦略に従って、スケジュールする Pod をクラスター内のノードにバインドし、バインド情報を etcd に書き込むことです。

• スケジューラはスケジュールを完了すると、より豊富な Pod 情報を更新します。 Pod レプリカの数だけでなく、レプリカの内容もわかります。どのノードにデプロイするかも把握します。
• 同様に、上記の Pod 情報を etcd に更新して保存します。
• etcd は更新成功イベントを APIServer に送信します。
• ここでの kubelet はノード上で実行されるプロセスであり、List-Watch 方式で APIServer によって送信された Pod 更新イベントをリッスン (監視) することに注意してください。実際、Pod を作成する作業はステップ 9 で完了しています。

kubelete がリッスンし続けるのはなぜですか?その理由は非常に単純です。この時点で、kubectl が元の MySQL RC コピーを 1 から 2 に拡張するコマンドを送信するとします。その後、プロセスが再度トリガーされます。

ノードのマネージャーとして、kubelet は最新の Pod デプロイメントに応じてノード リソースも調整します。

または、MySQL アプリケーションの RC 数は変更されていないが、イメージ ファイルがアップグレードされている場合、kubelet は自動的に最新のイメージ ファイルを取得してロードします。

上記のList-Watchの紹介により、これまで紹介したkubectlとAPIServerに加えて、Controller Manager、Scheduler、kubeletが導入されていることがわかります。

ここでは、それらの機能と原理を紹介します。

スケジューラ、コントローラマネージャ、Kubeletに焦点を当てる

コントローラーマネージャー

Kubernetes はクラスター内のさまざまなリソースを管理する必要があるため、リソースごとに異なるコントローラーを確立する必要があります。

各コントローラーは、監視メカニズムを通じて API サーバーからイベント (メッセージ) を取得します。これらは、API サーバーによって提供される (List-Watch) インターフェースを通じてクラスター内のリソースを監視し、リソースのステータスを調整します。

常にリソースを管理し調整する勤勉なマネージャーと考えてください。たとえば、MySQL が配置されているノードが予期せずクラッシュした場合、コントローラ マネージャーのノード コントローラが障害を適時に検出し、修復プロセスを実行します。

数百または数千のマイクロサービスが展開されているシステムでは、この機能は運用担当者に大いに役立ちます。このことから、Controller Manager は Kubernetes リソースのマネージャーであり、運用と保守の自動化の中核であることがわかります。

8つのコントローラーに分かれています。上記ではレプリケーション コントローラについて紹介しました。ここでは他のものをリストしますが、詳細には説明しません。

コントローラ マネージャー内のさまざまなコントローラは、さまざまなリソースの監視と管理を担当します。

スケジューラとkubelet

スケジューラの役割は、アルゴリズムと戦略に従ってスケジュールするポッドをノードにバインドし、その情報をetcdに保存することです。

スケジューラをスケジュール ルームに例えると、スケジュールするポッド、利用可能なノード、およびスケジュール アルゴリズムと戦略の 3 つに注意を払う必要があります。

簡単に言えば、スケジューリング アルゴリズム/戦略を通じて、ポッドを適切なノードに配置することです。このとき、Node 上の kubelet は、APIServer を介して Scheduler によって生成された Pod バインディング イベントをリッスンし、Pod の説明に従ってイメージ ファイルをロードしてコンテナを起動します。

つまり、スケジューラはどのノードにポッドを配置するかを考える責任があり、その決定を kubelet に伝え、kubelet はノードへのポッドのロードを完了します。

簡単に言えば、Scheduler がボスで Kubelet がワーカーであり、それらはすべて APIServer を介して情報を交換します。

スケジューラと kubelet の連携図

サービスとkubelet

上記の一連のプロセスを経て、最終的に Pod とコンテナがノードにデプロイされます。

MySQLの導入が成功しました

Kubernetes にデプロイされた Pod はどのようにして他の Pod にアクセスするのでしょうか?その答えは、Kubernetes Service メカニズムを通じて得られます。

Kubernetes のサービスは、サービスのアクセス エントリ アドレス (IP + ポート) を定義します。 Pod 内のアプリケーションは、このアドレスを通じて 1 つの Pod レプリカまたは Pod レプリカのグループにアクセスします。

サービスとバックエンドの Pod レプリカ クラスター間の接続は、ラベル セレクターを通じて実現されます。サービスによってアクセスされるポッドのグループには同じラベルが付けられるため、これらのポッドが同じグループに属していることがわかります。

ポッドはサービスを通じて他のポッドにアクセスする

MySQL サービス構成ファイル (mysql-svc.yaml) を次のように記述します。

 APIバージョン: v1
 kind: Service #作成されたリソースオブジェクトのタイプがServiceであることを示します
メタデータ:
 name : mysql#Service のグローバルに一意な名前
仕様:
利点:
 -port: 3306#サービスポート番号
 セレクター:#Pod を分類するために使用される、サービスに対応する Pod ラベル
   アプリ:mysql

通常どおり kubectl を実行してサービスを作成します。

次に、getsvc コマンドを使用してサービス情報を確認します。

ここでの Cluster-IP 169.169.253.143 は Kubernetes によって自動的に割り当てられます。 Pod が他の Pod にアクセスする必要がある場合は、Service の Cluster-IP とポートを使用する必要があります。

つまり、Cluster-IP と Port は Kubernetes クラスターの内部アドレスであり、クラスター内の Pod 間のアクセス用に提供されます。外部システムは、この Cluster-IP を介して Kubernetes 内のアプリケーションにアクセスできません。

上記のサービスは単なる概念であり、実際にサービスを実装するのは kube-proxy です。

kube-proxy の原理とメカニズムを理解することによってのみ、サービスの背後にある実装ロジックを真に理解することができます。

kube-proxy サービス プロセスは、Kubernetes クラスター内の各ノードで実行されます。このプロセスは、サービスのロードバランサーと見なすことができます。その主な機能は、サービスへのリクエストをバックエンドの複数のポッドに転送することです。

さらに、Service の Cluster-IP と NodePort は、iptables NAT 変換を通じて kube-proxy サービスによって実装されます。 kube-proxy は、操作中にサービスに関連する iptables ルールを動的に作成します。

iptables メカニズムはローカル kube-proxy ポートをターゲットとするため、kube-proxy コンポーネントは各ノードで実行する必要があります。

したがって、Kubernetes クラスター内では、サービスへのアクセス要求はどのノードでも開始できます。

クラスター内のkube-proxy（サービス）を介して他のポッドにアクセスする

MySQL サービスが Kubernetes 内の Tomcat から呼び出されるのと同様に、Kubernetes の外部から Tomcat を呼び出すにはどうすればよいでしょうか?

まず、設定ファイル myweb-rc.yaml を生成して確認します。

 APIバージョン: V1
種類: レプリケーションコントローラ
メタデータ:
 name : myweb#RC の名前。グローバルに一意です
仕様:
 replicas:2#予想されるPodレプリカの数。ここでの数は 2 です。2 つの Tomcat レプリカを作成する必要があります。
セレクター:
アプリ: myweb
 テンプレート: #Pod テンプレート、このテンプレートを使用して Pod を作成します
メタデータ:
 ラベル:
 app:myweb#Podレプリカラベル
仕様:
 コンテナ: #コンテナ定義部分
     -名前:mysql
コンテナに対応するイメージ:kubeguide/tomcat-app:v1#DockerImage
      ポート:
      -containerPort:8080#コンテナアプリケーションがリッスンするポート番号

kubectl の Create を使用して、myweb のレプリカを作成します。

コピーが作成されたら、対応するサービス構成ファイル myweb-svc.yaml を作成します。

 APIバージョン: v1
 kind: Service #作成されたリソースオブジェクトのタイプがServiceであることを示します
メタデータ:
 name : myweb#Service グローバルに一意な名前
仕様:
利点:
 -port: 8080#サービスポート番号
nodePort: 30001#これは、Kubernetes 内部アプリケーションへの外部ネットワーク アクセス用のポートです。
 セレクタ: #サービスに対応するPodラベルはPodを分類するために使用されます
   アプリ: myweb

同様に、kubectl で Create コマンドを実行して、サービス リソースを作成します。

上記の構成ファイルから、Tomcat のサービスに追加の nodePort 構成があり、その値が 30001 であることがわかります。

つまり、外部ネットワークはポート 30001 と NodeIP を介して Tomcat にアクセスできます。

コマンドを実行すると、「サービスを外部ネットワークに公開する場合は、ポート 30001 を通過できるようにファイアウォール ルールを設定する必要があります」という意味のプロンプトが表示されます。

Cluster-IP は仮想 IP であるため、Kubernetes 内の Pod 間の通信にのみ使用されます。

Node は物理ノードであるため、Kubernetes の外部から内部アプリケーションにアクセスするには、Node-IP と nodePort の組み合わせが必要です。

上記の構成に従って 2 つの Tomcat アプリケーションがデプロイされている場合、外部ネットワークからアクセスするときにどの Pod を選択する必要がありますか?これは、Kubernetes 外部のロードバランサーを通じて実現する必要があります。

Kubernetes 外部のロードバランサー

これは、Kubernetes の LoadBlancerService コンポーネントを使用して実現できます。クラウド プラットフォームを通じてロード バランサーを作成し、サービスを外部に公開するために適用します。

現在、LoadBlancerService コンポーネントがサポートするクラウド プラットフォームは、海外では GCE や DigitalOcean、中国では Alibaba Cloud、プライベート クラウドの OpenStack など、比較的充実しています。

使用の観点から見ると、サービスの type=NodePort を type=LoadBalancer に変更するだけで、Kubernetes は対応するロード バランサ インスタンスを自動的に作成し、外部クライアントが使用できるようにその IP アドレスを返します。

これまでに、MySQL (RC 1) と Tomcat (RC 2) が Kubernetes にデプロイされています。 Kubernetes 内の Pod は相互にアクセスでき、Kubernetes 内の Pod には外部ネットワークからもアクセス可能です。

ポッドはKubernetes内で相互にアクセスでき、インターネットからポッドにアクセスできる

さらに、Kubernetes はリソース モニターとして各ノードとコンテナ上で cAdvisor を実行します。リソースの使用状況とパフォーマンスを分析するためのツールであり、Docker コンテナをサポートしています。

Kubelet は cAdvisor を通じてノードとコンテナ (Docker) に関するデータを取得します。 cAdvisor は、CPU、メモリ、ファイル システム、ネットワークの使用状況に関する統計を自動的に収集します。

kubelet は Node のマネージャーとして、cAdvisor によって収集されたデータを REST API を通じて Kubernetes の他のリソースに公開し、Node/Pod 内のリソース使用状況を把握できるようにします。

要約する

マイクロサービスの急速な発展により、Kubernetes はマイクロサービス ガバナンス プラットフォームとして広く使用されるようになりました。開発期間が長く、サービス機能も多数あるため、一つ一つ列挙することはできません。

そのため、アプリケーション コピーを作成する簡単な例から始めて、各重要なコンポーネントの概念と基本原則を紹介します。

Kubernetes はコンテナ クラスターを管理するために使用されます。マスターは、APIServer、スケジューラ、コントローラ マネージャーを含むマネージャーです。

ノードはレプリカ デプロイメントのキャリアであり、複数の Pod が含まれ、各 Pod には複数のコンテナが含まれます。ユーザーは kubectl を使用して、マスター内の APIServer にデプロイメント コマンドを発行します。

コマンド本体は「.yaml」で終わる構成ファイルで、レプリカの種類、レプリカの数、名前、ポート、テンプレートなどの情報が含まれています。

APIServer はリクエストを受信すると、権限の検証 (特別な制御を含む)、作成するリソースの取得、コピー情報の etcd への保存などの操作を実行します。

APIServer は、リストウォッチ モード (イベントの送信と監視) でコントローラー マネージャー、スケジューラー、および kubelete と通信します。

コントローラ マネージャーは、etcd を通じて作成する必要があるリソースのレプリカの数を取得し、ポリシー分析のためにスケジューラーに送信します。

最後に、kubelet は最終的な Pod の作成とコンテナのロードを担当します。コンテナがデプロイされた後、サービスを通じてコン​​テナにアクセスし、リソースは cAdvisor を通じて監視されます。

著者: 崔昊

紹介: 16 年間の開発およびアーキテクチャの経験を持ち、HP 武漢デリバリー センターで技術専門家、需要アナリスト、プロジェクト マネージャーとして勤務し、その後、スタートアップ企業でテクノロジー/製品マネージャーとして勤務しました。学習が得意で、共有する意欲があります。現在は技術アーキテクチャと研究開発管理に重点を置いています。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]