Kubernetesとは何かを1つの記事で学ぶ

Kubernetes とは何ですか?

Borg システムは、Google 内で広く使用されているコンテナ管理システムです。初期には、セキュリティ分離を実現するために Chroot Jail が使用され、後に Namespace が使用されました。 CGroup を使用してリソースの分離を実現しました。

Google が Kubernetes のオープンソースバージョンをリリースしたのはなぜですか?私の個人的な理解は次のとおりです。

オープンソースコミュニティの力を活用して、Googleがまだ解決していない問題を解決する
クラウドネイティブのパイの一部を手に入れよう
クラウドネイティブの開発を推進します。結局のところ、Google は長年コンテナ分野で活動してきました。

Kubernetes には次の特性があります。

移植性: パブリッククラウド、プライベートクラウド、ハイブリッドクラウド、マルチクラウドアーキテクチャを完全にサポート
拡張可能: モジュール式、プラグイン可能、マウント可能、構成可能で、さまざまな拡張形式をサポートします。
自己修復: アプリケーションの状態を維持し、自己再起動、自己複製、自己スケールを行うことができ、宣言型構文を通じて強力な自己修復機能を提供します。

Kubernetes を使用すると、顧客のニーズに迅速かつ効率的に対応できます。

アプリケーションを迅速かつ予測通りに導入
アプリケーションを即座に拡張する機能
既存のサービスに影響を与えずに新機能をシームレスにリリース
ハードウェアリソースを最適化し、コストを削減

Kubernetes は宣言型システムです。宣言型システムと命令型システムには本質的な違いがあります。いわゆる宣言型システムは、何をするか、つまり、どのような期待が達成されるかを伝え、それをどのように達成するかがシステムの業務であることに重点を置いています。一方、命令型システムでは、特定の目標またはタスクが対応する規則または手順に従って達成されることが求められ、その達成方法に重点が置かれます。

命令形は「どのように」を強調します。タスクを段階的に完了する方法をコンピューターに指示する必要があります。このシナリオでは、コンピューターは「知性」を持たず、タスクを機械的に完了します。タスクの結果に関しては、プログラマーのレベルによって異なります。

宣言的なスタイルでは、「何」が強調されます。コンピュータに何を望んでいるかを伝えるだけで、コンピュータが自動的にそれを実行します。この時点で、コンピューターはある程度の「知能」を備えています。もちろん、宣言型スタイルがすべてのニーズを満たすとは限りません。

日常業務では、命令型プログラミングがより一般的です。このタイプのプログラミングは実装が簡単で、開発には特定の手順のみが必要です。ただし、特定の状況では、宣言型プログラミングの方が命令型プログラミングよりも便利です。実際、ほとんどの宣言型言語は、特定のタスクのためのドメイン固有言語、つまり DSL です。

最も一般的な宣言型言語は SQL です。必要な結果セットをコンピューターに伝えるだけで、データベースが結果セットを取得して結果を返す実行パスの設計を支援します。

Kubernetes は宣言型システムです。 Kubernetes を使用する場合、ユーザーは A->B->C などのワークフローを定義する必要はありません。代わりに、期待される状態を直接記述することができ、Kubernetes はユーザーがその状態を実現できるように支援します。ユーザーは、この状態をどのように達成するかについて心配する必要はありません。この設計により、Kubernetes は使いやすくなり、より堅牢になり、柔軟性とスケーラビリティも向上します。

Kubernetes アーキテクチャ

Kubernetes は全体として、次のようにマスタースレーブアーキテクチャになっています。

で：

etcd はクラスター全体のステータスを保存し、API サーバーだけが通信できるデータベースです。
apiserver は、リソース操作の唯一のエントリポイントを提供し、認証、承認、アクセス制御、API 登録、検出などのメカニズムを提供します。
コントローラーマネージャーは、障害検出、自動拡張、ローリングアップデートなど、クラスターの状態を維持する役割を担います。
スケジューラは、事前に決められたスケジューリング戦略に従ってリソースをスケジュールし、対応するマシンにポッドをディスパッチする役割を担います。
Kubelet はコンテナのライフサイクルを維持する役割を担い、ボリューム (CSI) とネットワーク (CNI) の管理も担当します。
コンテナランタイムは、イメージ管理と、ポッドおよびコンテナの実際の操作 (CRI) を担当します。
kube-proxy は、サービスに対してクラスター内でのサービス検出と負荷分散を提供する役割を担います。
レジストリはコンテナイメージを保存するミラーウェアハウスです
Kubectlとダッシュボードはどちらもクライアントツールです

上記のアーキテクチャは論理アーキテクチャです。実際の運用アプリケーションでは、高可用性を実現するために、アーキテクチャがそれに応じて調整されます。調整対象はマスターノードであり、次のようになります。

主な変更点は次のとおりです。

（１）マスターノードを単一ノードから複数ノードに変更し、負荷分散のためkube-apiserverの前にロードバランサーを追加しました。 LB を介して通信されるその他のコンポーネント。

（２）マスターノードの障害によるetcdの影響を受けないように、etcdとマスターノードを分離する

Kubernetes アーキテクチャの設計原則は次のとおりです。

APIServerのみがEtcdストレージに直接アクセスでき、他のサービスはKubernetes APIを介してクラスターのステータスにアクセスする必要があります。
原則として、単一ノードの障害はクラスターの状態に影響を与えません。
新しい要求がない場合、すべてのコンポーネントは障害回復後に受信した最後の要求を引き続き実行する必要があります。
すべてのコンポーネントは必要な状態をメモリ内に保持する必要があります。 APIServer は状態を Etcd ストレージに書き込み、他のコンポーネントは APIServer を通じて更新され、すべての変更をリッスンし、最終的にコントローラーマネージャーによって調整されます。
ポーリングよりもイベントリスニングを優先する

Kubernetesの重要なコンポーネント

上記では、Kubernetes の全体的なアーキテクチャを紹介し、各コンポーネントの機能を簡単に紹介しましたが、それらの間の具体的な関係については詳しく説明していません。それでは、コンポーネントとそれらがどのように連携するかを見てみましょう。

（1）kubectlクライアントはまずCLIコマンドをRESTful API呼び出しに変換し、それをkube-apiserverに送信します。

（2）認証、認可、アクセス検証後、kube-apiserverはタスクメタデータをetcdに保存します。次に、kube-scheduler はタスクをスケジュールし、スケジュール結果を kube-apiserver に返します。

（３）kube-schedulerがスケジューリングに適したターゲットノードを返すと、kube-apiserverはタスクのノード情報をetcdに保存し、タスクを作成します。

（4）この時点で、ターゲットノードのkubeletはapiserverをリッスンしています。このノードに新しいタスクをスケジュールする必要があることを検出すると、kubelet はローカルランタイムを通じてタスクコンテナを作成し、ジョブを実行します。

（5）その後、kubeletはタスクステータスなどの情報をapiserverに返し、etcdに保存します。

（6）kube-proxyはapiserverも監視します。ネットワークポリシー関連の操作がある場合、対応する iptables または ipvs ルールがローカルマシンに作成されます。

（7）タスクが実行されると、コントロールマネージャが有効になり、タスクが期待どおりの状態を維持することが保証されます。

主な構成要素は次のとおりです。

その他
API サーバー
コントローラーマネージャー
スケジューラ
クベレット
Kube プロキシ

その他

Etcd は、一貫性と高可用性を兼ね備えたキー値ストレージです。サービス検出、共有構成、一貫性の保証に使用できます。 Kubernetes では、Etcd は Kubernetes のすべての API オブジェクトを保存する唯一のストレージです。

実稼働レベルの Kubernetes では、etcd は通常、クラスターとして存在します。セキュリティ上の理由から、API サーバーからのみアクセスできます。

API サーバー

API サーバーは Kubernetes の最も重要なコアコンポーネントの 1 つであり、次の機能を提供します。

次のようなクラスター管理用の REST API インターフェイスを提供します。

認証
承認
アクセス

他のモジュールのデータ相互作用と通信のためのハブを提供します
API サーバーは Etcd データキャッシュを提供し、Etcd へのクラスターアクセスを削減します。

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

Kubernetes はバックグラウンドでさまざまなコントローラープロセスを実行し、サービス構成が変更されると (たとえば、ポッドが実行されるイメージを置き換えたり、構成 yaml ファイル内のパラメーターを変更したりする場合)、コントローラーはその変更を検出し、新しい望ましい状態に向けて作業を開始します。

論理的には、各コントローラーは個別のプロセスですが、複雑さを軽減するために、すべて同じ実行可能ファイルにコンパイルされ、単一のプロセスで実行されます。コントローラーには以下が含まれます。

ノードコントローラ: ノードに障害が発生したときに通知と応答を行う
ジョブコントローラ: 1 回限りのタスクを表すジョブオブジェクトを監視し、それらのタスクを完了まで実行するためのポッドを作成します。
エンドポイントコントローラ: エンドポイントオブジェクトを設定します (つまり、サービスとポッドを追加します)
サービスアカウントとトークンコントローラー: 新しい名前空間のデフォルトアカウントと API アクセストークンを作成する

以下は、デプロイメントコントローラーとレプリカセットコントローラーのワークフローです。

スケジューラ

kube-scheduler は、実行中のノードを指定していない新しく作成された Pod を監視し、Pod を実行するノードを決定する役割を担います。たとえば、アプリケーションに 1 GB のメモリと 2 つの CPU コアが必要な場合、そのアプリケーションのポッドは少なくともそれらのリソースを持つノードにスケジュールされます。スケジューラは、ポッドをスケジュールする必要があるたびに実行されます。スケジューラは、使用可能なリソースの合計と、各ノード上の既存のワークロードに割り当てられているリソースを認識する必要があります。スケジュールの決定では、個々のポッドとポッドのコレクションのリソース要件、ハードウェア/ソフトウェア/ポリシーの制約、アフィニティとアンチアフィニティの仕様、データの局所性、ワークロード間の干渉、および期限が考慮されます。

スケジュールは次の 3 つの段階に分かれています。

予測: 事前選択段階。ビジネス要件を満たせないノードを除外する
優先度: 最適化段階で最適なノードが選択されます。
バインド: バインドフェーズ。最適なノードとポッドをバインドしてスケジュールを完了します。

クベレット

Kubelet は各ノードのコアコンポーネントの 1 つであり、ノードのリソースオブジェクトの管理を担当します。

さまざまなソースからポッドリストを取得し、オンデマンドでポッドを開始および停止します。

Pod マニフェストは、ローカルファイルディレクトリ、指定された HTTP サーバー、API サーバーなどから取得できます。

Kubeletはコンテナランタイム、ネットワーク、ストレージをCRI、CNI、CSIに抽象化します。

ノードのヘルスステータスとリソース情報を報告する責任があります
ポッドのヘルスチェックとステータスレポートを担当

Kube プロキシ

kube-proxy は、クラスター内のすべてのノードで実行され、Kubernetes サービスコンセプトの一部を実装するネットワークプロキシです。個々のホストのサブネット化を処理し、サービスを外部に公開するために使用されます。クラスター内のさまざまな分離されたネットワークにわたって、リクエストを適切なポッド/コンテナに転送します。 kube-proxy はノード上のネットワークルールを管理します。これらのネットワークルールにより、クラスター内外のネットワークセッションから Pod とのネットワーク通信が可能になります。オペレーティングシステムがパケットフィルタリングレイヤーを提供し、それが利用可能な場合、kube-proxy はそれを介してネットワークルールを実装します。それ以外の場合、kube-proxy はトラフィック自体のみを転送します。