Kubernetes (k8s) の理論的概要

「コンテナ化されたアプリケーション」を自動的にデプロイ、スケーリング、管理するためのオープンソースシステム。
K8S は、複数のコンテナ化されたプログラム (Docker など) の自動運用と保守を担当するクラスターであり、非常に豊富なエコシステムを備えたコンテナオーケストレーションフレームワークツールであることがわかります。

2. K8の起源

K8Sは、GoogleのBorgシステム（Borgシステム、Google社内で使用されている大規模コンテナオーケストレーションツール）をプロトタイプとしてベースにしており、後にBorgのアイデアを用いてGO言語で書き直され、オープンソースとしてCNCF財団に寄贈された。

Cloud Native Foundation (CNCF) は 2015 年 12 月に設立され、Linux Foundation と提携しています。CNCF が最初に開発したプロジェクトは Kubernetes で、コンテナーの普及により、Kubernetes はコンテナーオーケストレーションツールの事実上の標準になりました。

意味: この言葉はギリシャ語の操舵手とパイロットに由来します。

公式ウェブサイト：https://kubernetes.io

GitHub：https://github.com/kubernetes/kubernetes

3. なぜ K8S を使用するのですか?

従来のバックエンド展開方法を想像してみてください。プログラムパッケージ (実行可能バイナリファイル、構成ファイルなどを含む) をサーバーに配置し、起動スクリプトを実行してプログラムを実行し、同時にデーモンスクリプトを起動して定期的に実行します。プログラムの実行ステータスを確認し、必要に応じて再起動します。プログラムをプルアップします。

サービスリクエストの数が増加し、デプロイされたサービスが応答できなくなったらどうなるかを想像してください。従来のアプローチでは、リクエスト量、メモリ、CPU がしきい値を超えてアラームが発行された場合、運用保守担当者がすぐにサーバーを数台追加し、サービスをデプロイした後、負荷分散に接続して共有することがよくありました。既存サービスのプレッシャー。
問題が発生します。アラームの監視からサービスの展開まで、人間の介入が必要です。では、サービスを自動的に展開、更新、アンインストール、拡張、縮小する方法はあるのでしょうか?
そして、これが K8S が行うべきことです。コンテナ化された (Docker) プログラムの運用と保守管理を自動化します。

K8S は Google のオープンソースコンテナクラスタ管理システムであり、Docker などのコンテナテクノロジに基づいて、コンテナ化されたアプリケーションの展開と運用、リソーススケジューリング、サービスディスカバリ、動的スケーリングなどの一連の完全な機能を提供し、大規模なアプリケーションの効率を向上させます。コンテナクラスター管理の利便性。

4. Kubernetesの機能

●ホスト間でコンテナを整理します。
●ハードウェアリソースを最大限に活用し、エンタープライズアプリケーションのニーズを最大限に高めます。
●制御および自動化アプリケーションの導入とアップグレード。
●ステートフルアプリケーション用のストレージをマウントおよび追加します。
● コンテナ化されたアプリケーションとそのリソースをオンラインでスケールアップまたはスケールダウンします。
●宣言型コンテナ管理により、デプロイされたアプリケーションがデプロイ方法に従って確実に動作します。
●自動レイアウト、自動再起動、自動レプリケーション、自動スケーリングにより、アプリケーションの状態確認と自己修復を実現します。
●複数のコンテナに対してサービス検出と負荷分散を提供するため、ユーザーはコンテナ IP の問題を考慮する必要がありません。

2: Kubernetes クラスターのアーキテクチャとコンポーネント

1. Kubernetes クラスターのアーキテクチャとコンポーネント

K8S はマスター/スレーブデバイスモデル (マスター/スレーブアーキテクチャ)に属します。つまり、マスターノードはクラスターのスケジューリング、管理、運用と保守を担当し、スレーブノードはクラスター内のコンピューティングワークロードノードです。。
K8Sでは一般にメインノードをマスターノード、スレーブノードをワーカーノードと呼び、各ノードにはマスターからワークロードが割り当てられます。

マスターコンポーネントはクラスター内の任意のコンピューターで実行できますが、マスターノードは別のサーバーを占有することをお勧めします。マスターはクラスター全体の頭脳であるため、マスターが配置されているノードがダウンするか使用できなくなると、すべての制御コマンドが無効になります。マスターに加えて、K8S クラスター内の他のマシンはワーカーノードと呼ばれ、ノードがダウンすると、そのノード上のワークロードはマスターによって自動的に他のノードに転送されます。

2. コアコンポーネント - マスターコンポーネント

（1）APIサーバーでした

Kubernetes API を公開するために使用され、リソースのリクエストまたは呼び出し操作は、kube-apiserver によって提供されるインターフェイスを通じて実行されます。HTTP Restful API はインターフェイスサービスを提供するために使用され、オブジェクトリソースのすべての追加、削除、変更、クエリ、監視操作は API サーバーに渡されて処理され、Etcd ストレージに送信されます。

API Server は K8S のリクエストエントリサービスであることがわかります。API サーバーは、(UI インターフェイスまたは CLI コマンドラインツールから) すべての K8S リクエストを受信し、ユーザーの特定のリクエストに従って動作するように他のコンポーネントに通知する責任があります。API サーバーは、K8S クラスターアーキテクチャの頭脳であると言えます。

（2）Kubeコントローラーマネージャー

運用管理コントローラは、K8S クラスタ内の通常のタスクを処理するバックグラウンドスレッドであり、K8S クラスタ内のすべてのリソースオブジェクトの自動制御センターです。
K8S クラスターでは、1 つのリソースがコントローラーに対応し、コントローラーマネージャーがこれらのコントローラーを管理します。

これは、API サーバーを通じてクラスター全体のステータスを監視し、クラスターが期待どおりの動作状態にあることを確認する一連のコントローラーで構成されています。たとえば、ノードが予期せずクラッシュした場合、コントローラーマネージャーは即座に自動化されたエラーを検出して実行します。クラスタが常に良好な状態にあることを確認するための修復プロセス。期待される動作状態。

これらのコントローラーには主に
ノードコントローラーが含まれます。ノードの障害の検出と応答を担当します。
•レプリケーションコントローラー: クラスター内の RC (リソースオブジェクトレプリケーションコントローラー) に関連付けられたポッドコピーの数が常に事前設定値を維持することを保証します。これは、クラスター内に N 個の Pod インスタンスのみが存在することを保証するものと理解できます。N は、RC で定義された Pod コピーの数です。
•エンドポイントコントローラー: エンドポイントオブジェクトを入力し (つまり、サービスとポッドを接続し)、サービスと対応するポッドのコピーの変更を監視する責任を負います。エンドポイントはサービスによって公開されるアクセスポイントであると理解できますが、サービスにアクセスする必要がある場合は、そのエンドポイントを知る必要があります。
•サービスアカウントとトークンコントローラー: 新しい名前空間のデフォルトアカウントと API アクセストークンを作成します。
•ResourceQuota コントローラー (リソースクォータコントローラー) : 指定されたリソースオブジェクトがシステムの物理リソースを常に過剰に占有しないようにします。
•Namespace Controller (ネームスペースコントローラー) : ネームスペースのライフサイクルを管理します。
•サービスコントローラー：K8Sクラスターと外部クラウドプラットフォーム間のインターフェースコントローラー。

（3）Kubeスケジューラ

これはリソースのスケジューリングを担当するプロセスであり、スケジューリングアルゴリズムに従って、新しく作成された Pod に適切な Node ノードを選択します。

これは、すべての K8S Node ノードのスケジューラとして理解できます。ユーザーがサービスをデプロイしたい場合、スケジューラは、スケジューリングアルゴリズムに基づいて、ポッドをデプロイするのに最適なノードを選択します。
•述語
•優先順位

API サーバーは、ポッドのバッチを作成するリクエストを受け取ります。API サーバーは、コントローラーマネージャーに、事前に設定されたテンプレートに従ってポッドを作成するように依頼します。コントローラーマネージャーは、API サーバーを通じてスケジューラーにアクセスし、最適なノードを選択します。新しく作成されたポッドのノード。たとえば、このポッドの実行には 2C4G リソースが必要で、スケジューラは事前選択ポリシーを通じてポリシーを満たさないノードノードを除外します。Node ノードの残りのリソースは API サーバーに報告され、etcd に保存されます。API サーバーはメソッドを呼び出して etcd 内のすべての Node ノードの残りのリソースを検索し、それを Pod に必要なリソースと比較します。ノードのリソースが不足している場合、または事前選択戦略の条件を満たしていない場合は、事前選択を通過できません。事前選択段階で選別されたノードは、事前選択段階の最適化戦略に従ってスコア付けおよびランク付けされ、最も高いスコアを持つノードが選択されます。たとえば、リソースが豊富で負荷が小さいノードは、より高いランクを持つ可能性があります。

3. ストレージセンターの構成

（1）etcd

K8Sストレージサービス。etcd は、K8S のキー設定とユーザー設定を保存する分散キー/値ストレージシステムです。K8S の API サーバーのみが読み取りおよび書き込み権限を持ち、他のコンポーネントはデータの読み取りおよび書き込みのために API サーバーインターフェイスを渡す必要があります。

4. ノードコンポーネント

（1）キュベレット

Node ノードの監視者および Master ノードとの通信者。Kubelet は、ノードノードにインストールされたマスターノードの「アイライナー」であり、ノードノードで実行されているサービスのステータスを API サーバーに定期的に報告し、マスターノードからの指示を受け入れて調整措置を講じます。

マスターノードから自身のノード上のポッドの予期されるステータス(実行するコンテナ、実行中のレプリカの数、ネットワークやストレージの構成方法など)を取得し、コンテナエンジンと直接対話して実装します。コンテナのライフサイクル管理自身のノード上のポッドのステータスが異なる場合、期待される状態に一貫性がない場合は、対応するコンテナプラットフォームインターフェイス (つまり、Docker インターフェイス) を呼び出してこの状態に到達します。

イメージとコンテナのクリーンアップを管理して、ノード上のイメージがディスク領域全体を占有しないように、また、終了したコンテナが多くのリソースを占有しないようにします。

概要:
Kubernetes クラスターでは、kubelet サービスプロセスが各ノード (ワーカーノードとも呼ばれます) で開始されます。このプロセスは、マスターによってこのノードに割り当てられたタスクを処理し、ポッドとポッド内のコンテナを管理するために使用されます。各 kubelet プロセスは、ノード自身の情報を API サーバーに登録し、定期的にノードリソースの使用状況をマスターに報告し、cAdvisor を通じてコンテナとノードのリソースを監視します。

（2）代理の場合

ポッドネットワークプロキシは各ノードノードに実装されます。ノードノードは Kubernetes Service リソースのキャリアであり、ネットワークルールと 4 層のロードバランシングを維持する責任を負います。サービスマッピングアクセスを実装するための iptables および ipvs へのルールの作成を担当します。

Kube-Proxy 自体は Pod に直接ネットワークを提供するのではなく、Pod のネットワークは Kubelet によって提供され、実際には仮想 Pod クラスターネットワークを維持します。
Kube-apiserver は Kubernetes Service を更新し、Kube-Proxy を監視することでエンドポイントを維持します。

K8S クラスター内のマイクロサービスの負荷分散は、Kube プロキシによって実装されます。Kube-proxy は、K8S クラスター内のロードバランサーです。これは、K8S の各ノードで Kube プロキシコンポーネントを実行する分散プロキシサーバーです。

(3) ドッカーまたはロケット

コンテナエンジンはコンテナを実行し、ローカルコンテナの作成と管理を担当します。
kubernetes がノードへのポッドをスケジュールすると、ノード上の kubelet が docker に特定のコンテナーを開始するように指示します。その後、kubelet は docker を通じてコンテナ情報を継続的に収集し、それをマスターノードに送信します。Docker はコンテナイメージをプルし、通常どおりコンテナを開始または停止します。唯一の違いは、これが各ノードの管理者によって手動で実行されるのではなく、自動化されたシステムによって制御されることです。

5. Kubernetes の中心的な概念

Kubernetesには、ポッド、ラベル、サービス、レプリケーションコントローラーなど、さまざまな種類のリソースオブジェクトが含まれています。

すべてのリソースオブジェクトは、Kubernetes が提供する kubectl ツールを介して追加、削除、変更、確認などを行うことができ、永続ストレージとして etcd に保存されます。

実はKubernetsは、etcdストレージに保存されている予想されるリソースの状態と、現在の環境における実際のリソースの状態との差異を追跡・比較することで、自動制御や自動エラー修正などの高度な機能を実現する、高度に自動化されたリソース制御システムです。

（1）ポッド

ポッドは、Kubernetes によって作成またはデプロイされる最小/単純な基本単位であり、クラスター上で実行されているプロセスを表します。
ポッドはエンドウ豆のさやとして理解でき、同じポッド内の各コンテナはエンドウ豆です。

ポッドは 1 つ以上のコンテナで構成され、ポッド内のコンテナはネットワーク、ストレージ、コンピューティングリソースを共有し、同じ Docker ホスト上で実行されます。
複数のコンテナを Pod 内で実行できます。これは SideCar モードとも呼ばれます。実稼働環境では、単一のコンテナー、または強い相関性と相補性を持つ複数のコンテナーでポッドを形成します。

同じポッド内のコンテナはローカルホストを介して相互にアクセスでき、ポッド内のすべてのデータボリュームをマウントできますが、異なるポッド間のコンテナはローカルホストを介してアクセスできず、他のポッドのデータボリュームをマウントすることもできません。

(2) ポッドコントローラー

ポッドコントローラーはポッド起動用のテンプレートであり、K8S で起動されたポッドが常にユーザーの期待 (コピー数、ライフサイクル、ヘルスステータスチェックなど) に従って実行されるようにするために使用されます。

K8S は多数のPod コントローラーを提供しており、以下が一般的に使用されます。
• デプロイメント: ステートレスアプリケーションのデプロイメント。Deployment の役割は、Pod と ReplicaSet を管理および制御し、ユーザーが期待する状態で実行されるように制御することです。

•Replicaset : 予想される Pod レプリカの数を確保します。ReplicaSet の役割は、Pod を管理および制御し、それらが適切に動作するように制御することです。ただし、ReplicaSet は Deployment によって制御されます。

Deployment はゼネコンであり、主に以下のワーカー Pod の作業を監督し、ユーザーが必要とする数の Pod が常に動作していることを確認する責任を負っていることがわかります。ワーカーポッドが使用不能になっていることがわかった場合は、すぐに新しいポッドを引き込んで置き換えます。ReplicaSetはゼネコンの下請け会社です。
K8S ユーザーの観点から見ると、ユーザーは Deployment デプロイメントサービスを直接操作することになり、Deployment がデプロイされると、K8S は必要な ReplicaSet と Pod を自動的に生成します。ユーザーは、ReplicaSet ではなく、Deployment のみを気にする必要があります。
リソースオブジェクトレプリケーションコントローラーは ReplicaSet の前身であり、サービスをデプロイするためにレプリケーションコントローラーの代わりに Deployment を使用することが公式に推奨されています。

•Daemonset : すべてのノードが同じタイプの Pod を実行していることを確認し、各ノードでそのような Pod が 1 つ実行されていることを確認し、通常、システムレベルのバックグラウンドタスクを実装するために使用されます。

•Statefulset : ステートフルなアプリケーションのデプロイメント

•ジョブ: 1 回限りのタスク。ユーザーの設定に従って、ジョブが管理するポッドは、タスクが正常に完了すると自動的に終了します。

•Cronjob : 定期的にスケジュールされたタスク

（3）ラベル

タグは、リソースオブジェクトの分類と管理を容易にする K8S 独自の管理方法です。
ラベルは、ノード、ポッド、サービス、RC などのさまざまなリソースオブジェクトに添付でき、オブジェクトの関連付け、クエリ、フィルターに使用されます。
ラベルはキーと値のペアであり、キーと値はユーザーによって指定されます。
リソースオブジェクトは任意の数のラベルを定義でき、同じラベルを任意の数のリソースオブジェクトに追加したり、オブジェクトの作成後に動的に追加または削除したりすることもできます。
多次元リソースグループ管理機能は、1 つ以上の異なるラベルを指定されたリソースオブジェクトにバンドルすることによって実現できます。

Label と同様にAnnotationもあります。
違いは、有効なタグ値は 63 文字以下である必要があり、空であるか、英数字 ([a-z0-9A-Z]) で開始および終了する必要があり、ダッシュ (-)、アンダースコア (_) を含めることができることです。、ドット (.) および文字または数字。コメント値には文字数制限はありません。

(4) ラベルセレクター（ラベルセレクター）

リソースオブジェクトのラベルを定義することは、リソースオブジェクトにラベルを与えることと同じであり、ラベルセレクター (ラベルセレクター) を使用して、特定のラベルを持つリソースオブジェクトをクエリおよびフィルターできます。
現在、タグセレクターには 2 種類あります。1 つは等価関係 (等しい、等しくない) に基づくもの、もう 1 つはセットの関係 (属する、属さない、存在する) に基づくものです。

（5）サービス

K8S クラスターでは、各 Pod には個別の IP アドレスが割り当てられますが、Pod にはライフサイクルがあるため (作成可能で、破棄後に再起動されない)、ビジネスの変化によりいつでも変更される可能性があります。その結果、Pod が破棄されると、この IP アドレスも失われます。

サービスは、この問題を解決するために使用される中心的な概念です。
K8S のサービスは、私たちがよく言う「サービス」を意味するのではなく、ゲートウェイ層に似ており、同じサービスを提供するポッドのグループの外部アクセスインターフェイスおよびトラフィックバランサーとみなすことができます。
サービスがどのポッドで動作するかは、ラベルセレクターを通じて定義されます。
K8S クラスターでは、Service は、同じサービスを提供する Pod のグループの外部アクセスインターフェイスとみなすことができます。クライアントがアクセスする必要があるサービスは Service オブジェクトです。各サービスには固定の仮想 IP (この IP はクラスター IP とも呼ばれます) があり、バックエンドポッドに自動的かつ動的にバインドされます。すべてのネットワークリクエストはサービスの仮想 IP に直接アクセスし、サービスは自動的にバックエンドに転送します。。
安定した外部アクセス方法を提供することに加えて、サービスはロードバランサーとしても機能し、リクエストトラフィックをすべてのバックエンドサービスに自動的に分散します。サービスは顧客に対して透過的に水平に拡張できます。)
サービス機能を実現する鍵となるのがkube-proxyです。kube-proxy は各ノードで実行され、API サーバーのサービスオブジェクトの変更を監視します。ネットワークは、ユーザースペース (廃止)、iptables (廃止寸前)、ipvs (推奨) の 3 つのトラフィックスケジューリングモードを通じて実装できます。、最高のパフォーマンス）転送。

サービスはK8Sサービスの中核であり、サービスの詳細を保護し、サービスのインターフェースを統一的に外部に公開することで、まさに「マイクロサービス」を実現します。たとえば、サービス A には 3 つのコピー、つまり 3 つの Pod がデプロイされていますが、ユーザーは Service の入り口に注意するだけで済み、どの Pod をリクエストするかを気にする必要はありません。
利点は非常に明白です。一方で、外部ユーザーは、Pod 上のサービスの予期しないクラッシュや K8S の Pod の再起動によって引き起こされる IP の変更を認識する必要がありません。また、外部ユーザーは、Pod によって引き起こされる IP の変更を認識する必要もありません。アップグレードやサービス変更による交換。

（6）イングレス

サービスは主に K8S クラスタ内のネットワークトポロジを担当しますが、クラスタの外部からクラスタの内部にどのようにアクセスするのでしょうか? 現時点では Ingress が必要です。Ingress は K8S クラスター全体のアクセス層であり、クラスター内外の通信を担当します。
Ingress は、K8S クラスターの OSI ネットワーク参照モデルの下で動作するレイヤー 7 アプリケーションであり、外部に公開されるインターフェイスであり、一般的なアクセス方法は http/https です。
サービスは、IP+ポートの形式で、第 4 層でのみトラフィックスケジューリングを実行できます。Ingress は、さまざまなビジネスドメインおよびさまざまな URL アクセスパスでビジネストラフィックをスケジュールできます。
例: クライアントは http://www.qhw.com:port ---> Ingress ---> Service ---> Pod をリクエストします。

（7）氏名

K8S は内部で「リソース」を使用して各論理概念 (機能) を定義するため、各「リソース」には独自の「名前」が必要です。
「リソース」には、API バージョン (apiversion)、カテゴリ (kind)、メタデータ (metadata)、定義リスト (spec)、ステータス (status) およびその他の構成情報が含まれます。
「名前」は通常、「リソース」の「メタデータ」情報で定義されます。同じ名前空間内で一意である必要があります。

（8）名前空間

プロジェクトの増加、人員の増加、クラスタ規模の拡大に伴い、K8S内のさまざまな「リソース」を論理的に分離する手法が必要になります、それがNamespaceです。
名前空間は、K8S クラスターを、リソースを共有できない複数の仮想クラスターグループに分割するために生まれました。
異なる名前空間内の「リソース」の名前は同じにすることができますが、同じ名前空間内の同じタイプの「リソース」の「名前」を同じにすることはできません。
K8S の名前空間を適切に使用すると、クラスター管理者は K8S に提供されるサービスをより適切に分類、管理、参照できるようになります。
K8S にデフォルトで存在する名前空間には、default、kube-system、kube-public などが含まれます。
K8S で特定の「リソース」をクエリするには、対応する名前空間を取得する必要があります。

6. k8s ワークフロー

1. ユーザーは、認証を通じて kube apiserver にリクエストを送信し、ポッドリクエストを作成します。

2. apiserver は関連情報を etcd に書き込みます。

3. apiserver は kube コントローラーマネージャーを見つけて、対応するポッドリソースを作成します。

4. コントローラーマネージャーは、apiserver を通じて etcd 内のデータを読み取り、対応するポッド情報を見つけます。

5. apiserver は、ポッドをスケジュールするスケジューラを見つけます。ポッドの転送先に関して、apiserver は etcd のデータを読み取って関連するノード情報を取得し、ポッドの実行に最適なノードを見つけます。最後に、スケジューラは、ポッドをスケジュールします。事前選択戦略とアルゴリズムによる優先戦略ポッドの実行をスケジュールする必要があるノードを計算します。

6. スケジューラーは、apiserver を通じて対応するノード上の kubelet コンポーネントを見つけ、このコンポーネントを通じてポッドを作成および維持し、関連するコンテナーが docker を通じて作成されます。

7. 次に、これらのポッドは、kube プロキシを介してクラスターを形成するように関連付けられます。kube プロキシは、サービスリソースを使用して、統合 IP アドレスを使用してそれらを公開します。外部ユーザーは、この IP アドレスを使用して、ポッド内で実行されているサービスにアクセスできます。

8. Kubelet は、このノードで実行されているリソースの数、およびポッド関連のステータスと情報を監視し、それらを apiserver に送信します。apiserver は、その情報を etcd に書き込んで保存します。ポッドのメンテナンスはコントローラーマネージャーによって行われ、ポッドの数がプリセット数を満たさない場合、対応するプリセット数を作成してポッドの合計数を確保します。

3: K8s のインストール

1. 一般的な K8S のインストールおよび展開方法

（1）Minikube

Minikube は、単一ノードのマイクロ K8S をローカルですばやく実行できるツールで、K8S の一部の機能を学習およびプレビューするためにのみ使用されます。
デプロイメントアドレス: https://kubernetes.io/docs/setup/minikube

（2）キューブ管理者

Kubeadm は、K8S クラスターを迅速に展開するための kubeadm init および kubeadm join を提供するツールでもあり、これは比較的簡単です。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

2. バイナリのインストールと展開

本番環境の最初の選択肢は、公式から配布バージョンのバイナリパッケージをダウンロードし、各コンポーネントと自己署名 TLS 証明書を手動でデプロイして K8S クラスターを形成する方法で、初心者に推奨されます。
https://github.com/kubernetes/kubernetes/releases

Kubeadm は展開のしきい値を下げますが、多くの詳細がブロックされるため、問題のトラブルシューティングが困難になります。より簡単に、より制御しやすくしたい場合は、バイナリパッケージを使用して Kubernetes クラスターをデプロイすることをお勧めします。手動でのデプロイは手間がかかりますが、プロセス中に多くの動作原則を学ぶことができ、後のメンテナンスにも役立ちます。

3. k8s デプロイメントバイナリと高可用性の違い

●バイナリデプロイメントは
、デプロイが難しく、管理が容易で、クラスタ拡張性能が高く、
安定性が高く、クラスタ規模が一定の規模（数百ノード、数万ポッド）に達すると、バイナリの安定性がバイナリの安定性より高くなります。 kubeadm のデプロイメント
。障害が発生すると、ホストマシンのプロセスも開始されます。

●kubeadm デプロイメントは
デプロイは簡単ですが、管理は困難です。
コンポーネントとサービスをコンテナで管理できます。障害の回復時間はバイナリよりも遅くなります。障害が発生すると、ホストを起動し、次にプロセスを起動し、最後にプロセスを起動します
。コンテナを使用してクラスターを復元できるようにします。バイナリよりも遅いです。

要約する

ansible アプリケーションレベルのマルチマシンオーケストレーションツール
docker コンテナエンジンコンテナランタイム
dockerfile ビルドイメージ
docker compose シングルマシンコンテナクラスタオーケストレーションツール

docker swarm Docker のコンテナマルチマシンオーケストレーションツールは、Docker コンテナクラスタの管理とスケジューリングを実現するツールです
kubernetes Google のコンテナマルチマシンオーケストレーションツールは市場シェアの 80% 以上を占め、コンテナオーケストレーションツールのデファクトスタンダードとなっています
mesos + マラソン mesos : クラスター内の複数のホストのハードウェアリソースを均一にスケジュールおよび管理できる分散リソース管理フレームワークマラソン
: コンテナーサービスのスケジュールと実行に使用される Mesos のコンテナーオーケストレーションフレームワーク

K8Sにはどのようなコンポーネントが含まれていますか?
K8S にはマスターノードとワーカーノードの 2 種類のノードが
マスターノードには apiserver コントローラーマネージャースケジューラが、k8s クラスターのデータベースとして etcd が使用され、
ノードノードには kubelet kube-proxy コンテナエンジン/コンテナランタイム (docker、containerd) が搭載されています。）。

コンポーネントは何をするのでしょうか?
apiserver : すべてのサービスリクエストに対する統一されたアクセスの入り口です
コントローラーマネージャー: コントローラーマネージャーは、ポッドレプリカセット、名前空間、エンドポイント、ノード、デプロイされたコントローラーなどのリソースオブジェクトの管理、K8S クラスター全体のステータスの監視を担当しますクラスターが予想される動作状態であることを確認します。スケジューラー:
リソーススケジューラー。ポッドリソースのスケジューリングを担当し、スケジューリングアルゴリズム (事前選択戦略、優先戦略) を通じてデプロイされたポッドに最適なノードを選択します。 etcd: K8Sクラスターデータベースは、K8S クラスターのすべての重要な情報を保存する役割を担う、キーと値のストレージ構造を備えた分散データベースです。読み取りおよび書き込み権限を持つのは apiserver のみです
。

kubelet : マスターからリクエストを受信し、ポッドとコンテナを作成および管理し、コンテナエンジンと対話してコンテナのライフサイクルを管理します。ノードリソース情報とポッドの実行ステータスを収集し、マスターの apiserver にレポートし
ます。リソースのキャリア、ポッドのネットワークプロキシの実装、ネットワークルールと 4 層のロードバランシング作業の維持
コンテナエンジン/コンテナランタイム: コンテナを実行します

K8S でポッドを作成するためのワークフローは何ですか?
1) ユーザーは、クライアントを通じてマスターノード上の API サーバーにポッド作成リクエストを送信します。
2) API サーバーは、まずリクエスト情報を etcd に書き込んで保存し、次に、ポッドリソースを作成するコントローラーマネージャーを見つけます。次に、
コントローラーマネージャーは、API サーバーを介してスケジューラーにアクセスし、新しく作成されたポッドに最適なノードを選択します
。スケジューリングアルゴリズムの選択戦略と最適化戦略
5) 次に、API サーバーを通じて対応するノードを見つけますノード上の kubelet がポッドを作成および管理します
6) kubelet はコンテナエンジンと対話して、ポッドのライフサイクルを管理しますポッド/コンテナ
7) ユーザーは、apiserver を通じて kube-proxy にネットワークルールを書き込み、サービスリソースを作成し、ポッドコントロールを実装することもできます。サービスの検出とロードバランシング

K8S リソースオブジェクト
Pod: K8S が作成および管理できる最小単位です。ポッドには 1 つ以上のアプリケーションコンテナを含めることができ、ポッド内のコンテナはネットワークやストレージなどのリソースを共有します。
ポッドコントローラー:

デプロイメント: ステートレスアプリケーションをデプロイします。マネジメントも担当

レプリカセット(期待どおりにポッドのコピー数を維持する) とポッド (コンテナ化されたアプリケーションプロセス)
statefulset : ステートフルアプリケーションをデプロイする
daemonset : すべてのノードに同じ Pod をデプロイする
job : 短期タスク Pod を一度にデプロイする、Pod
Cronjob: 短期タスク用のポッドは定期的にデプロイされ、タスクの実行後にポッドは自動的に終了します。

1: K8 の概要

1. K8sの機能