【クラウドネイティブ】Kubernetesコンテナオーケストレーションツール

Kubernetes という言葉は、操舵手とパイロットを意味するギリシャ語に由来しています。中国ではk8sとも呼ばれます（kとsの間に8文字があることから名付けられました。「国産プログラマーのユーモア」）。「コンテナ化されたアプリケーション」を自動的にデプロイ、スケーリング、管理するためのオープンソースシステム。K8S は、複数のコンテナ化されたプログラム (Docker など) の自動運用と保守を担当するクラスターであり、非常に豊富なエコシステムを備えたコンテナオーケストレーションフレームワークツールであることがわかります。

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

1.2 Docker オーケストレーションと k8s オーケストレーションの比較

クラスターのマスター/スレーブ冗長性なしで、単一のマシンでのみ使用できます。
コンテナ数が多いと管理コストがかかる
災害復旧や自己修復メカニズムがない
事前に設定された取り決めはなく、大規模なスケジュールを設定することはできません。
統合された管理および構成センターがない
グラフィカルインターフェースなし
ライフサイクル管理センターがない

1.3 従来のバックエンド展開と k8s の比較

従来の展開

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

このとき、一度サービスのリクエスト量が増加すると、デプロイしたサービスでは対応できなくなり、リクエスト量やメモリ、CPUが閾値を超えてアラームが発せられた場合、運用保守担当者が即時追加するというのが従来のアプローチでした。さらにいくつかのサーバーを追加し、サービスをデプロイした後、負荷分散にアクセスして既存のサービスの負荷を分散します。問題が発生します。アラームの監視からサービスの展開まで、人間の介入が必要です。サービスを自動的に展開、更新、アンインストール、拡張、縮小する方法はありません

k8sの展開

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

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

（1） apiserverでした

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 コントローラー: 指定されたリソースオブジェクトがシステムの物理リソースを常に過剰に占有しないようにします。

名前空間コントローラー: 名前空間のライフサイクルを管理します。

サービスコントローラー: K8S クラスターと外部クラウドプラットフォーム間のインターフェイスコントローラー。

（3）Kubeスケジューラ

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

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

• 述語
• 優先順位

API サーバーは、ポッドのバッチを作成するリクエストを受け取ります。API サーバーは、コントローラーマネージャーに、事前に設定されたテンプレートに従ってポッドを作成するように依頼します。コントローラーマネージャーは、API サーバーを通じてスケジューラーにアクセスし、最適なノードを選択します。新しく作成されたポッドのノード。

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

2.2 k8s 構成ストレージセンター

etcd は k8s のストレージサービスセンターです

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

2.3 k8sのノードコンポーネント

（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 はコンテナイメージをプルし、通常どおりコンテナを開始または停止します。唯一の違いは、これが各ノードの管理者によって手動で実行されるのではなく、自動化されたシステムによって制御されることです。

3. K8s のコアコンセプト

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

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

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

3.1 ポッドの理解、適用、作成プロセス

ポッドは、Kubernetes によって作成またはデプロイされる最小/単純な基本単位であり、クラスター上で実行されているプロセスを表します。ポッドはエンドウ豆のさやとして理解でき、同じポッド内の各コンテナはエンドウ豆です。ポッドは 1 つ以上のコンテナで構成され、ポッド内のコンテナはネットワーク、ストレージ、コンピューティングリソースを共有し、同じ Docker ホスト上で実行されます。

複数のコンテナを Pod 内で実行できます。これは SideCar モードとも呼ばれます。実稼働環境では、単一のコンテナー、または強い相関性と相補性を持つ複数のコンテナーでポッドを形成します。同じポッド内のコンテナはローカルホスト経由で相互にアクセスでき、ポッド内のすべてのデータボリュームをマウントできますが、異なるポッド間のコンテナはローカルホスト経由でアクセスしたり、他のポッドのデータボリュームをマウントしたりすることはできません。

ポッドを作成するための K8S ワークフロー

(1) ユーザーはクライアント経由でマスターノード上の apiserver にポッド作成リクエストを送信します。

(2) apiserver はまず関連するリクエスト情報を etcd に書き込み、次にコントローラーマネージャーを見つけます。

事前設定されたリソーステンプレートに基づいてポッドマニフェストを作成する

(3) 次に、コントローラーマネージャーは API サーバーを通じてスケジューラーを見つけます。

新しく作成したポッドに最適なノードを選択します

(4) スケジューラは、スケジューリングアルゴリズムの事前選択戦略と最適化戦略を通じて、最適なノードノードを選択します。

(5) 次に、apiserver を通じて対応する Node ノード上の kubelet を見つけて、ポッドを作成および管理します。

(6) Kubelet はコンテナエンジンと直接対話して、コンテナのライフサイクルを管理します。

(7) ユーザーは、kube-proxy でホストされるサービスリソースを作成することにより、関連するネットワークルールを作成します。

ポッドのサービス検出と負荷分散を実装する

ポッドコントローラー

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

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

• 導入: ステートレスアプリケーションの導入。Deployment の役割は、Pod と ReplicaSet を管理および制御し、ユーザーが期待する状態で実行されるように制御することです。

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

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

• Statefulset: ステートフルなアプリケーションの展開

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

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

3.2 ラベルラベル

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

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

3.3 ラベルセレクター（ラベルセレクター）

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

3.4 サービス

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 の変更を認識する必要もありません。アップグレードやサービス変更による交換。

3.5 進入

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

プロセスは大まかに次のとおりです。クライアントが要求したドメイン名 ---> Ingress (7 層プロキシ) ---> サービス (4 層プロキシ) ---> Pod

3.5 名前

K8S は内部で「リソース」を使用して各論理概念 (機能) を定義するため、各「リソース」には独自の「名前」が必要です。

「リソース」には、API バージョン (apiversion)、カテゴリ (kind)、メタデータ (metadata)、定義リスト (spec)、ステータス (status) およびその他の構成情報が含まれます。
「名前」は通常、「リソース」の「メタデータ」情報で定義されます。同じ名前空間内で一意である必要があります。

3.6 名前空間

プロジェクトの増加、人員の増加、クラスタ規模の拡大に伴い、K8S内のさまざまな「リソース」を論理的に分離する手法が必要になります、それがNamespaceです。

名前空間は、K8S クラスターを、リソースを共有できない複数の仮想クラスターグループに分割するために生まれました。

異なる名前空間内の「リソース」の名前は同じにすることができますが、同じ名前空間内の同じタイプの「リソース」の「名前」を同じにすることはできません。

K8S の名前空間を適切に使用すると、クラスター管理者は K8S に提供されるサービスをより適切に分類、管理、参照できるようになります。

K8S にデフォルトで存在する名前空間には、default、kube-system、kube-public などが含まれます。

K8S で特定の「リソース」をクエリするには、対応する名前空間を取得する必要があります。

4. 一般的な K8S 導入方法

4.1 k8s の一般的な導入方法

●Minikube
Minikube是一个工具，可以在本地快速运行一个单节点微型K8S，仅用于学习、预览K8S的一些特性使用。
部署地址：https://kubernetes.io/docs/setup/minikube

●Kubeadm
Kubeadm也是一个工具，提供kubeadm init和kubeadm join，用于快速部署K8S集群，相对简单。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

●二进制安装部署
生产首选，从官方下载发行版的二进制包，手动部署每个组件和自签TLS证书，组成K8S集群，新手推荐。
https://github.com/kubernetes/kubernetes/releases


Kubeadm降低部署门槛，但屏蔽了很多细节，遇到问题很难排查。如果想更容易可控，推荐使用二进制包部署Kubernetes集群，虽然手动部署麻烦点，期间可以学习很多工作原理，也利于后期维护。

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

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

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