Kubernetesクラスターのアーキテクチャを分かりやすいに解析

Kubernetes の概要

Golang で書かれたコンテナ オーケストレーション アプリケーションは、Google 内での数十年にわたるコンテナ オーケストレーションの経験の要約に基づいています。これはオープン ソースであり、CNCF の最初の製品でもあります。ちなみに、CNCF によって発売された 2 番目の製品は、Prometheus クラウドネイティブ モニタリングです応用。

CNCF公式サイト

Kubernetes クラスターのアーキテクチャ

Kubernetes は、サーバー - クライアントの形式の典型的な 2 層アーキテクチャに属します。
1. マスターは主に 3 つのコンポーネントで構成されます。API サーバー、コントローラーマネージャー、スケジューラー、およびクラスター状態ストレージ用の Etcd ストレージサービスであり、クラスター全体のコントロールプレーンを構成します。
2. Node ノードには主に、Kubelet、Kube Proxy、コンテナランタイム (Docker が最も一般的に使用される実装) の 3 つのコンポーネントが含まれており、これらはさまざまなアプリケーション コンテナを運び、実行します。

コンピューティング インターフェイスとストレージ インターフェイスは、マスター上の API サーバーを通じて公開されます。クライアントは API を通じてアプリケーション実行リクエストを送信し、マスターはスケジューリング アルゴリズムを通じてそれを特定のワーカー ノードに自動的に割り当て、Pod オブジェクトの形式で実行します。マスターは、ワーカー ノードの追加、障害、削除などの変更によるポッドへの影響を自動的に処理します。

マスター: コントロールノード

API Server

• クラスター全体の API ゲートウェイ。関連アプリケーションは kube-apiserver です。

• http/https プロトコルに基づいた REST スタイルで提供され、ほぼすべての機能が「リソース」と関連する「オブジェクト」に抽象化されます。

• 宣言型 API。オブジェクトの「最終状態」を宣言するためにのみ使用され、特定のビジネス ロジックは各リソースに関連するコントローラーによって完了されます。

• ステートレス、データは etcd に保存されます。

Cluster Store

• クラスター状態データストレージシステム。通常は etcd を指します。

• APIサーバーとのみ対話します

Controller-Manager

• API を通じてクライアントによって送信された最終ステートメントを実現する責任を負い、対応するアプリケーションは kube-controller-manager です。

• API オブジェクトの「実際の状態」は、「望ましい状態」に近づくか等しくなるように、一連のステップを通じて関連コードによって駆動されます。ループモードで作業する

Scheduler

• スケジューラー。ポッドに最適な実行ノードを選択 (現時点で評価) します。

• 関連プログラムは kube-scheduler です

WorkerNode: 作業ノード

Kubelet

• 各ワーカーノード上の Kubernetes クラスターのエージェント、対応するプログラムは kubelet

• マスターによって送信された命令を受信して​​実行し、現在のノード上のポッド オブジェクトにバインドされているコンテナをスケジューラによって管理します。

• API サーバー経由で Pod リソース定義を受信するか、ノードのローカル ディレクトリから静的な Pod 設定をロードします。

• CRI 準拠のコンテナ ランタイムを利用して Pod 関連のコンテナを管理および監視する

Kube Proxy

• 各ワーカーノード上で実行され、サービスリソースの定義をノードのローカル実装に変換することに特化します。

• iptables モード: サービス リソースの定義を、現在のノードの観点に適応する iptables ルールに変換します。

• ipvs モード: サービス リソースの定義を ipvs と現在のノードの観点に適応するいくつかの iptables ルールに変換します。

• Serviceネットワーク内のPodネットワークを通過するための鍵です

クラスター内のサービス数が多い場合、iptables の構成は ipvs よりも簡単ですが、生成されるサービス ルールは冗長であり、クラスター内のサービス数が多い場合、iptables ルールの数は膨大になります。パフォーマンスへの影響は無視できないため、ipvs の使用を大幅に改善できます iptables の類似ルールを減らし、パフォーマンスを向上させます

Kubernetes アドオン

Kubernetes アタッチメントの違いは、アタッチメントは独立して実行でき、アプリケーションに依存しないことです。

Kubernetes クラスターの機能を拡張する役割を担うアプリケーション。通常は Pod の形式で Kubernetes クラスター上でホストされ、実行されます。

必要なプラグイン

• Network Plugin：ネットワーク プラグインは、CNI インターフェイスを介して、ポッドに専用の通信ネットワークを提供する役割を果たし、複数の実装があります。

• Cluster DNS: クラスター DNS サーバー。サービスの登録、検出、名前解決を担当します。現在の実装は CoreDNS です。

重要なプラグイン

• Ingress コントローラー: Ingress コントローラーは、Ingress リソースに特定の実装を提供し、http/https プロトコルのレイヤー 7 ルーティングとトラフィック スケジューリングを実装する責任を負い、複数の実装があります。

• Dashboard: Web ベースの UI

• 指標監視システム: Prometheus

• ロギング システム: ELK、PLG など。

ネットワーク プラグインは多数あり、プラグインの選択はクラウド ネイティブ エンジニアの重要な責任の 1 つです
• Network Plugin：Flannel、ProjectCalico、Cilium、WeaveNet、...
• Cluster DNS：SkyDNS、KubeDNS、CoreDNS、...
• Ingress Controller：Ingress Nginx、Traefik、Contour、Kone、Gloo、APISIX Ingress、...
• Dashboard：Kubernetes Dashboard、Kuboard、...

Kubernetes アプリケーション オーケストレーションの基本的な動作ロジック

Kubernetes は本質的に「アプリケーション中心」の最新のアプリケーション インフラストラクチャであり、Podはアプリケーションの実行とアプリケーションのスケジューリングのための最小の論理ユニットです。

基本的に、ネットワーク、IPC、UTS の名前空間とストレージ リソースを共有するコンテナのセット

• 物理マシンまたは仮想マシンとして考えると、各コンテナはそのホスト上のプロセスになります。

• 各コンテナはネットワーク プロトコル スタック、ネットワーク デバイス、ルート、IP アドレス、ポートなどを共有しますが、マウント、PID、およびユーザーは依然として分離されています。ファイル、プロセス、ユーザー名前空間はデフォルトで分離されており、PID 共有は明示的に宣言する必要があります

• 各ポッドは、「ホスト」の外部ストレージとして「ボリューム」を接続することもできます。これは、ポッドのライフサイクルから独立しており、ポッド内のすべてのコンテナで共有できます。

削除後にリソースマニフェストを通じて再作成できる「不変インフラストラクチャ」をシミュレートします。

• ポッドの作成と更新時には、削除と再構築の方法が採用されており、これにより資産履歴記録が効果的に確立され、状態の遡及が容易になります。

• 動的であり、誤った削除やホスト障害などの例外を許容します。

• ストレージボリュームにより、データがポッドのライフサイクルを超えて保存できるようになります。

設計の観点からは、「非常に親密な」関係を持つアプリケーションのみを、異なるコンテナーの形式で同じ Pod 内で実行する必要があります。

• 各 Pod のコンテナは Pause 名前空間を共有します。これは一時停止状態にあり、リソースを占有しないコンテナです。主な目的は、通常の使用のために Pod コンテナに追加する必要がある名前空間を Pod に提供することです。

Serviceリソースの設計ロジック

ポッドは動的であり、その IP アドレスは構成リストに基づいて再構築後に再割り当てされるため、サービス検出メカニズムのサポートが必要です。

Kubernetes はサービス リソースと DNS サービス (CoreDNS) をサービス検出に使用します。
• サービスは、同じサービスを提供するポッドのグループにロード バランシング メカニズムを提供でき、その IP アドレス (サービス IP、クラスター IP とも呼ばれる) がクライアント トラフィック エントリになります。
• Service オブジェクトはクラスター内の各ノードに存在し、個々のノードの障害によって失われることはなく、Pod に固定のフロントエンド エントリを提供できます。
• サービスは、ラベル セレクター (Label Selector) を使用して、Pod オブジェクトのラベル (Label) をフィルターして照合し、Pod を検出します。「ラベルセレクターフィルターに一致するラベルを持つポッドのみ」

Podとワークロード コントローラー

ポッドは、実行中のアプリケーションの原子単位です。そのライフサイクル管理とヘルス ステータスの監視は、kubelet によって実行されます。更新、スケーリング、再構築などのアプリケーション オーケストレーション機能は、専用のコントローラーによって実装する必要があります。このタイプのコントローラーは、ワークロード タイプのコントローラーです。

ロード コントローラーは、ラベル セレクターを通じて Pod ラベルをフィルター処理して、関連付けを完了します。

負荷コントローラの重心として。
• 選択したポッドが目的の数と正確に一致することを確認する「数が足りない場合はPodテンプレートに従って作成し、数を超える場合は冗長なオブジェクトを破棄する」
• 構成で定義されたスケールアップとスケールダウン
• ポリシーと構成に従ってアップデートを適用する

ワークロード コントローラーに基づいて、同じ名前のリソースを作成します
ReplicaSet和Deployment - ステートレスア　プリケーションを調整する
DaemonSet - システムレベル　アプリケーションを調整する
StatefulSet - ステートフルア　プリケーションを調整する
Job和CronJob - 定期的なタスク アプリケーションを調整する

アプリケーションのデプロイ

オーケストレーション要件に従って適切なタイプのワークロード コントローラーを選択する

適切な数の Pod オブジェクトが実行されるようにするワークロード コントローラー オブジェクトを作成する

Service オブジェクトを作成して、Pod オブジェクトのグループに固定アクセス エントリを提供します。

Service オブジェクトのサービスへのアクセスをリクエストします

クラスター内の通信トラフィックは East-West トラフィックとも呼ばれ、クライアントもクラスター上の Pod オブジェクトです

サービスとクラスタ外部のクライアント間の通信トラフィックはノースサウストラフィックと呼ばれ、クライアントはクラスタ外部のプロセスです
• クラスター上のポッドは、クラスター外部のサービス プロセスと通信することもできます。

Kubernetes ネットワークの基本

Kubernetesネットワークモデル

Kubernetes クラスターにはノード、ポッド、サービス用の 3 つのネットワークが存在します。
• ワーカーの交換を完了する

3 つのネットワークはカーネルを介して 3 つのネットワークのルーティング公開を完了でき、その後 3 つのネットワークは通信します。「ノード ネットワークは当社でカスタマイズする必要があります。ポッド ネットワークは CNI ツールによって生成され、ユーザー指定のネットワーク セグメントのみが必要です。サービスは Kubernetes 自体によって管理され、ユーザー指定のネットワーク セグメントのみが必要です。」

• ノードカーネル内のルーティングモジュール、iptables/netfilter、ipvs がネットワーク間のトラフィック転送を完了します。

クラスター内部にアクセスする方法：
　　クラスター内のノードネットワーク内のホスト -> ホストはクラスター内のサービスネットワークに転送される -> 配布プロセスはサービスネットワークによって実行される -> クラスター内のポッドネットワーク
外部からクラスター内部にアクセスする方法：
　　外部からクラスタ内部にアクセスする方法は、まずノードネットワーク内の特定のホストにアクセスし、ホスト経由でサービスネットワークに転送し、最後にサービスネットワークが分散処理を行って最終的にポッドに到達します。通信網：
（クラスタ外 -> クラスタ内のノードネットワーク上のホスト -> ホストはクラスタ内のServiceネットワークに転送される -> Serviceネットワークは分散処理に使用される -> クラスタ内のPodネットワーク）

• ノードネットワーク
クラスターノード間の通信ネットワーク。クラスターの外部エンドポイントとの通信を開始する役割を果たします。

各マスター ノードとノード ノードの間にはネットワーク カード接続があります。クロスルーティングがない場合、これらはデフォルトで同じレイヤ 2 ネットワーク内にあります。クロスルーティングの場合、デフォルト ノードはレイヤ 3 ネットワーク内またはレイヤ 3 ネットワーク内にあります。レイヤ 2 ネットワーク。 これらのネットワークにノードとインターフェイスの数を事前に計画する必要があります。その後、Kubernetes クラスターをデプロイできます。

各ノードのネットワークとアドレスは、Kubernetes によって管理されるのではなく、Kubernetes の展開前に構成する必要があるため、管理者が手動で行うか、ホスト仮想化管理プログラムの助けを借りて行う必要があります。

• ポッドネットワーク
クラスター上の Pod オブジェクトに提供されるネットワーク

これは Pod 間に存在し、各 Pod の仮想 NIC インターフェイスには特定のアドレスがあります。 使用するネットワークプラグインに応じて、デフォルトのアドレスも異なります
例えば：
Flannel を使用する場合、ポッドのデフォルト IP は 10.244.0.0/12 です。
ProjectCalico を使用すると、ポッドのデフォルト IP は 192.168.0.0/12 になります。

仮想ネットワークは、Flannel、Calico、Cilium などの CNI ネットワーク プラグインを通じて実現する必要があります。

• サービスネットワーク
Kubernetesクラスタのデプロイ時に指定すると、各Serviceオブジェクトが使用するアドレスがこのネットワークから割り当てられます。

サービスネットワークのネットワークセグメントとノードネットワークセグメントは異なるネットワークに属します。
サービス ネットワークはどのノードにも存在しません。クラスター展開に特定のツールを使用すると、デフォルトのネットワーク セグメント 10.96.0.0/12 が存在します。

Service オブジェクトの IP アドレスが、関連する iptables または ipvs ルールに存在する

Kubernetes クラスター自体によって管理される

Kubernetesクラスタの通信フロー

Kubernetesネットワークには主に4種類の通信トラフィックがある
• 同じポッド内のコンテナ間通信 - ループバックインターフェース
• ポッド間の通信
• ポッドとサービス間の通信
• クラスターの外部トラフィックとサービス間の通信

ポッドは直接通信できるのに、通信用のネットワークを分散するためにサービスに依存する理由：
ポッド ノードはいつでも削除および再構築でき、ネットワークは動的です。 Pod を検出するには、Pod サービス登録センターとサービス検出バスが必要であり、Service がこれらのタスクを処理します。複数のサービスがある場合、Service は自動的にロード バランシングを実行します。

ポッドネットワークは、CNI 仕様と互換性のあるサードパーティのネットワーク プラグインを利用して完成させる必要があり、これらのプラグインは次の機能要件を満たす必要があります。
• すべての Pod は NAT メカニズムを経由せずに直接通信できます。
• すべてのノードは、NAT メカニズムを使用せずにすべての Pod と直接通信できます。
• すべての Pod オブジェクトが同じフラット ネットワーク上にある