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

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

1.k8sの起源

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

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

公式ウェブサイト: Kubernetes

GitHub： GitHub - kubernetes/kubernetes: プロダクショングレードのコンテナのスケジューリングと管理

2. なぜ k8s を使用するのですか?

従来のバックエンド展開方法を想像してください。プログラムパッケージ (実行可能バイナリファイル、構成ファイルなどを含む) を配置し、プログラムをプルアップします。

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

3.k8sの主な機能

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

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

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

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

1.マスターコンポーネント

1.1Kube APIサーバー

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

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

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

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

コントローラーの種類:

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

1.3Kube スケジューラ

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

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

述語
優先戦略（優先順位）

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

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

2.1 立方体

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

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

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

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

2.2Kubeプロキシ

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

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

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

2.3ドッカーまたはロケット

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

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

3.1etcd

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

3. k8s の Pod 作成ワークフロー

ユーザーは、クライアント経由でマスターノード上の apiserver にポッドを作成するリクエストを送信します。
apiserver はまずリクエスト情報を etcd に書き込んで保存し、次にコントローラーマネージャーを見つけて、事前に設定されたリソース構成テンプレートに従って Pod リソースを作成します。
次に、コントローラーマネージャーは API サーバー経由でスケジューラーにアクセスし、新しく作成されたポッドに最適なノードを選択します。
スケジューラは、スケジューリングアルゴリズムの事前選択戦略と最適化戦略を通じて、スケジューリングに最適なノードを選択します。
次に、apiserver を通じて対応するノード上の kubelet を見つけて、ポッドを作成および管理します。
kubelet はコンテナエンジンと対話して、ポッド/コンテナのライフサイクルを管理します。
ユーザーは、apiserver を通じて kube-proxy にネットワークルールを記述し、サービスリソースを作成し、サービスの検出とポッドのロードバランシングを実現することもできます。

4. K8s のコアコンセプト

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

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

Kubernetes は、実際には高度に自動化されたリソース制御システムであり、etcd ストレージに格納されているリソースの期待状態と、現在の環境における実際のリソース状態との差異を追跡および比較することで、自動制御や自動エラー修正などの高度な機能を実現します。

1.ポッド

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

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

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

2.ポッドコントローラー

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

K8S は多数の Pod コントローラーを提供しており、以下が一般的に使用されます。

導入: ステートレスアプリケーションの導入。Deployment の役割は、Pod と ReplicaSet を管理および制御し、ユーザーが期待する状態で実行されるように制御することです。
レプリカセット: 予想されるポッドレプリカ数を確保します。ReplicaSet の役割は、Pod を管理および制御し、それらが適切に動作するように制御することです。ただし、ReplicaSet は Deployment によって制御されます。
Daemonset: すべてのノードが同じタイプのポッドを実行していることを確認し、各ノードでそのようなポッドが 1 つ実行されていることを確認します。これは通常、システムレベルのバックグラウンドタスクを実装するために使用されます。
Statefulset: ステートフルアプリケーションのデプロイメント
仕事: 1 回限りのタスク。ユーザーの設定に従って、ジョブが管理するポッドは、タスクが正常に完了すると自動的に終了します。
Cronjob: 定期的にスケジュールされたタスク

デプロイメントと Replicatset の関係:

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

3.ラベル

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

ラベルと注釈の違い:
違いは、有効なラベル値は 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 です。
サービスは第 4 層でのみトラフィックスケジューリングを実行でき、表現形式は ip+port です。Ingress は、さまざまなビジネスドメインおよびさまざまな URL アクセスパスでビジネストラフィックをスケジュールできます。
例: クライアントは http://www.kgc.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 で特定の「リソース」をクエリするには、対応する名前空間を取得する必要があります。

9. k8s リソース構成情報:

Apliverison: k8s の各リソースオブジェクトで使用される API インターフェイスのバージョン
Kind: リソースオブジェクトのタイプ
Maledala: 名前リソース名、名前空間名前空間などのリソースオブジェクトのメタデータ。ラベルラベル、アニレーションコメント
仕様: リソースオブジェクトのリソース構成リスト (構成属性) (コピー数、ミラー名、データボリューム、ラベルセレクターなど)。
ステータス: リソースオブジェクトの現在の実行ステータス情報

Kubernetes のアーキテクチャとワークフロー

1. Kubernetes の概要