Kubernetes アーキテクチャとコアコンポーネント

この記事では、Kubernetes のコア コンポーネントとは何か、アーキテクチャ図とフロー チャートはどのようなものか、kubectl と kubelet はよく混同されるのか、宣言型 API と命令型 API の違いは何かなどについて詳しく説明します。

1. Kubernetes クラスターの概要

1.1 概要

Kubernetes は、共有ネットワークを使用して複数のホスト (物理サーバーまたは仮想マシン) をクラスター化するコンテナ オーケストレーション プラットフォームです。マスターノードとワーカーノードに分かれています。マスターはクラスター全体の管理を担当し、ワーカーはリクエストを受信して​​ポッド (コンテナ コレクション) の形式でワークロードを実行する役割を担います。次の図は、Kubernetes クラスターの動作モードの概略図です。

マスターはクラスターのゲートウェイであり中心です。クライアントに API 呼び出しを提供し、各リソース オブジェクトが常にユーザーの期待する状態に近いことを保証し、指定されたノードに Pod を最適な方法でスケジュールし、他のコンポーネント間の通信を調整する役割を担います。これは、クライアントがクラスターにアクセスするための唯一のエントリ ポイントです。実稼働環境では通常、冗長性と負荷分散のために複数のマスターがデプロイされます。

ワーカーノードは、マスターからの指示を受信し、それに応じてポッドオブジェクトを作成または破棄するほか、ルーティングやトラフィック転送などのタスクも担当します。実稼働環境では、マイクロサービスの数が増えたり、ビジネス アプリケーションが拡張したりすると、それに応じてワーカーの数も増加します。

要約すると、Kubernetes はすべてのワーカー ノードのリソース (CPU、ディスク、メモリ、ネットワークなど) を統合してより強力な「サーバー」を形成し、マスターの API インターフェイスを通じてクラスターのコンピューティング インターフェイスとストレージ インターフェイスを公開します。次に、マスターは、スケジューリング アルゴリズムを通じてクライアントから要求されたワークロードを特定のノードに割り当て、ポッド上のワーカー ノードの追加、障害、削除などの変更の影響を自動的に処理します。

Kubernetes は、基盤となるホスト クラスター上に構築された「クラウド ネイティブ アプリケーション オペレーティング システム」であり、コンテナーはその上で実行されるプロセスです。

Kubernetes 内の各オブジェクトは、一意の識別子として「名前」を使用します。名前の分離と再利用、およびリソースの分離を目的として、「名前空間」がスコープとして使用されます。

1.2.宣言型APIを通じて

クラウドネイティブアプリケーションを開発する場合、宣言型 API が主に使用されます。この方法はシンプルで使いやすく、プログラマーはビジネス開発に集中できるようになります。

アプリケーションを実行する際、ユーザーは API を通じてビジネス アプリケーションの最終状態 (たとえば、Nginx アプリケーションのインスタンスを 6 つ実行するなど) を宣言するだけで、Kubernetes がアプリケーション自体の実行インスタンス数、ルーティング ポリシー、アクセス ポリシー、ストレージなど、後続のすべてのタスクを完了します。

以下は宣言型 YAML の例です。 Kubernetes は、コマンドライン ツール kubectl を使用したリクエストの送信もサポートしています。

 apiVersion: v1 kind: Pod metadata: name: busybox namespace: test labels: app: busybox spec: containers: - name: busybox image: busybox

2. Kubernetes クラスター アーキテクチャ

Kubernetes はサーバー クライアント アーキテクチャに属します。マスターノードは、主に API サーバー (kube-apiserver)、コントローラー マネージャー (Kube-controller-manager)、スケジューラー (kube-scheduler) の 3 つのコンポーネントと、クラスターのステータスを保存するための etcd ストレージ サービスで構成されます。これらはクラスター全体のコントロール プレーンを構成します。

ワーカー ノードには主に、kubelet、kube-proxy、コンテナー ランタイム (以前は Docker が一般的な実装でした) の 3 つのコンポーネントが含まれており、さまざまなアプリケーション コンテナーを運び、実行します。コンポーネントは以下の図に示されています。

2.1 マスターコンポーネント

マスターはクラスターの頭脳です。 Kubernetes のすべてのオブジェクト レコードを維持し、オブジェクトのステータスを管理し、クラスター内のさまざまなリソース オブジェクトの管理操作に応答し、各リソース オブジェクトの実際のステータスが必要なステータスと一致することを確認します。コントロール プレーンのコンポーネントとその主な機能は次のとおりです。

2.1.1、API サーバー

API サーバーは Kubernetes コントロール プレーンのフロントエンドであり、デプロイメント、スケーリング、ローリング アップデートなど、さまざまな種類のアプリケーションのライフサイクル オーケストレーションをサポートします。これはクラスター全体のゲートウェイ インターフェイスでもあり、すべての REST 要求を受信、検証、応答し、結果のステータスを (etcd) に保存するために使用されます。

2.1.2 クラスター状態ストレージ

Kubernetes クラスターのすべてのステータス情報は etcd に保存する必要があります。 etcd は、サービス検出、共有構成、一貫性の保証 (データベース マスター ノードの選択、配布など) に使用できる分散キー値ストアです。

etcd は、保存されているデータへの変更を監視し、プッシュするための監視 (warch) メカニズムも提供します。 API サーバーは、Kubernetes クラスター内で etcd と通信できる唯一のコンポーネントです。この監視メカニズムをカプセル化し、それを使用して他のコンポーネントと効率的に連携します。これは、Zookeeper の助けを借りて複数のアプリケーション サーバーが連携するのと似ています。

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

コントローラーは、API サーバーを介してクライアントから送信されたリクエストを実装する役割を担います。 API オブジェクトの現在の状態を期待される状態に近づけます。 Kubernetes は、Node、Pod、Server、Endpoint、ServiceAccount、Token など、数十種類のオブジェクトを駆動するコントローラーを提供します。

2.1.4 スケジューラ

Kubernetes システムでのスケジューリングとは、API サーバーが受信した各ポッドのリクエストを作成し、それをクラスター内の最適な動作ノードと一致させることを意味します。 kube-scheduler はデフォルトのスケジューラです。スケジュールの考慮事項には、ハードウェア、ソフトウェア、ポリシーの制約、アフィニティと反アフィニティ、テイント、その他の特性が含まれます。

2.2 ワーカーノードコンポーネント

ワーカー ノード コンポーネントは、クラスターの手動労働者です。数百または数千のコンテナ化されたアプリケーションを実行するために十分なリソースを確保するために、クラスターには通常、複数のワーカー ノードがあります。各ノードは定期的にステータスの変更をマスターに報告し、マスターの管理を受け入れます。

2.2.1、クベレット

Kubelet は Kubernetes で最も重要なコンポーネントの 1 つです。これは各ノード上で実行される「ノード エージェント」サービスです。マスターから送信された指示を受信して​​実行するほか、現在のノード上の Pod オブジェクトのコンテナやその他のタスクを管理する役割を担います。 API サーバーから Pod リソース定義を受信し、コンテナ ランタイムを通じてコン​​テナを作成、起動、監視することをサポートします。

kubelet は、現在のノード上の各 Pod のヘルス ステータスを継続的に監視し、いずれかの Pod に問題がある場合は再構築します。同時に、彼らはタイムリーにマスターとコミュニケーションを取り、自分の状況をマスターに報告します。

2.2.2 コンテナランタイム環境

Pod はコンテナのコレクションであり、基盤となるコンテナ ランタイムが実際にコンテナを実行する役割を担います。 Kubelet は、CRI (Container Runtime Interface) を通じて、docker、containerd、CRI-O、runC、Kata など、複数のタイプの OCI コンテナ ランタイムをサポートします。

2.2.3、kube-プロキシ

kube-proxy は、クラスター内の各ノードで実行する必要があるサービス プロセスです。 API サーバー上のサービス リソース オブジェクトを、現在のノード上の iptables または (および) ipvs ルールに変換します。これらのルールは、サービス オブジェクト ClusterIP に送信されたトラフィックをそのバックエンド Pod エンドポイントに分散できます。

kube-proxy は Kubernetes のコア ネットワーク コンポーネントです。本質的には、Pod プロキシやロード バランサーのようなもので、クラスター内のノード、サービス、および Pod オブジェクト間の通信を確保する役割を果たします。

2.3.グラフィカルアーキテクチャ

上の図に示すように:

• 開発・運用・保守担当者は、kubectl コマンドまたは Kubernetes が提供するクライアント SDK を使用して、apiserver が提供するインターフェースを呼び出すことができます。
• apiserver インターフェースを呼び出した後、Kubernetes はリソース定義情報を etcd データベースに保存します。リソース定義情報は期待される状態です。
• 定義情報を受け取った後、コントローラー マネージャーは、期待される状態を実際の状態に変更し、実際の状態を etcd データベースに書き込むように努めます。
• 定義情報がスケジューラモジュールによってスケジュールされていない場合、実際の状態はスケジュール保留中になります。スケジューラがポッドをユーザーが指定したノードにスケジュールすると、実際の状態はポッドの実際の実行状態になります。
• スケジューラが「ポッドをどのノードにスケジュールするか」という情報を etcd データベースに書き込むと、ノード上の kubelet はリストウォッチ メカニズムを使用してこの情報を受信します。その後、kubelet は受信した情報に従ってポッド定義情報を実行し、ポッドを起動します。
• マスターノードを含む各ノードに kube-proxy サービスが存在します。 kube-proxy モジュールは、クラスターのトラフィックの入り口として使用できます。
• コンテナ ランタイムは最終的にコンテナ プロセスの実行を担当するため、各ノードにはコンテナ ランタイム (docker、containerd など) がインストールされている必要があります。

3. コア拡張コンポーネント

一般的に使用されるコア拡張コンポーネントは次のとおりです。

3.1 ネットワークプラグイン

ネットワークプラグインは必須コンポーネントであり、よく使われるものとしてはFlannel、Calicoなどがあります。私は主にCalicoを使用しています。クラウドベンダーは通常、VPC と組み合わせた独自の実装を持っています。

3.2 コアDNS

Kubernetes は名前解決とサービス検出に DNS アプリケーションを使用し、バージョン 1.11 以降ではデフォルトで CoreDNS を使用します。以前のバージョンでは、kube-dns が使用されていました。

3.3 ダッシュボード

Kubernetes クラスターを視覚化するための WebUI。ダッシュボードを使用すると、クラスター内のノード、名前空間、ボリューム、ClusterRole、ジョブなどのクラスター内のリソース オブジェクトに関する詳細情報を取得したり、これらのリソース オブジェクトを作成または変更したりできます。

3.4.コンテナリソース監視システム

監視システムは、分散アプリケーションにとって重要なインフラストラクチャです。 Kubernetes の一般的な指標監視コンポーネントには、Metrics-Server、Prometheus などがあります。

3.5 クラスタログシステム

ログ記録システムは、観察可能な分散アプリケーションを構築するためのインフラストラクチャであり、開発者が問題を発見して特定するのに役立ちます。 Kubernetes で一般的に使用されるログ システムは、ElasticSearch、Fluentd、Kibana (EFK) の組み合わせによって提供されるソリューション、または ELK などのソリューションを使用することです。

3.6 イングレスコントローラ

Ingress リソースは、Kubernetes がクラスター外部からクラスター内に HTTP トラフィックを導入するために使用するリソースの一種です。トラフィック ルールと構成のセットを制御するためにのみ使用されます。 「トラフィック侵入」は実行できないため、Ingress コントローラによって使用される必要があります。一般的に使用される Ingress コントローラーには、Nginx などがあります。

上記の添付ファイルのうち、CoreDNS、監視システム、ログ記録システム、Ingress コントローラーなどの基本的なサポート サービスは、通常、クラスター内にインストールされます。ダッシュボードは、ユーザーの効率性とエクスペリエンスを向上させる視覚化ツールであり、通常はクラスターの外部に独立してインストールされます。

4. ちょっとした質問

4.1.宣言型 API と命令型 API

一方は結果に焦点を当て、もう一方はプロセスに焦点を当てます。

宣言型プログラミング: 最終結果に重点を置きます。結果をどのように達成するかは、特定の言語の基本的なコンポーネント機能によって異なります。プログラマーは、どのように行うかではなく、何を行うかを指定するだけで済みます。宣言型プログラミングは、データベースや構成管理ソフトウェアでよく使用されます。リレーショナル データベースの SQL 言語は、最も典型的な代表例の 1 つです。

命令型プログラミング: 手続き型プログラミングと呼ぶ方が適切です。プログラマーは、物事を実行するための具体的な手順を指定する必要があり、結果を達成するプロセスにさらに注意を払う必要があります。

4.2. kubectl と kubelet の違い

初心者は kubectl と kubelet の違いがわからないことがよくあります。上記から、次のことがわかります。

kubectl は、API サーバー インターフェースを呼び出すために使用される軽量の Kubernetes クライアントであり、通常はマスター ノードにインストールされます。

Kubelet は各ノードにインストールされるエージェントであり、マスターと効率的に通信し、マスターが発行したタスクを完了し、タスクと自身のステータスを報告するために使用されます。