1. Kubernetes の概要
1. Kubernetes とは何ですか?
「コンテナ化されたアプリケーション」を自動的にデプロイ、スケーリング、管理するためのオープンソース システム
K8S は、複数のコンテナ化されたプログラム (Docker など) の自動運用と保守を担当するクラスターであり、非常に豊富なエコシステムを備えたコンテナ オーケストレーション フレームワーク ツールであることがわかります。
由来：
k8S は、Google の Borg システム (Google 社内で使用されている大規模コンテナ オーケストレーション ツールである Borg システム) をプロトタイプとしてベースにしており、後に Borg のアイデアを使用して G0 言語で書き直され、オープンソースとして CNCF 財団に寄贈されました。
意味：
この言葉はギリシャ語の操舵手とパイロットに由来します。
公式ウェブサイト：
GitHub: GitHub - kubernetes/kubernetes: 本番グレードのコンテナのスケジューリングと管理
2. なぜ K8S を使用するのですか?
従来のバックエンド展開方法を想像してみてください。プログラム パッケージ (実行可能バイナリ ファイル、構成ファイルなどを含む) をサーバーに配置し、起動スクリプトを実行してプログラムを実行し、同時にデーモン スクリプトを起動して、プログラムの実行ステータスを定期的に確認し、必要に応じてプログラムを再起動します
サービスのリクエスト量が増加し、デプロイされたサービスが応答できなくなったらどうなるかを想像してみてください。従来のアプローチでは、リクエスト量、メモリ、CPU がしきい値を超えてアラームが発行された場合、運用保守担当者がすぐにいくつかのサービスを追加します。サービスが良好になったら、負荷分散に接続して既存のサービスの負荷を分散します。
そこで問題が発生します: アラームの監視からサービスの展開まで、人間の介入が必要です! では、サービスの展開、更新、アンインストール、拡張、縮小を自動的に完了する方法はあるのでしょうか?
これが K8S が行うべきことです。コンテナ (Docker) プログラムの運用と保守を自動化します。K8s の目標は、コンテナ化されたアプリケーションのデプロイをシンプルかつ効率的にすることです。
K8S は、裸の Docker のいくつかの問題点を解決します。
●単一マシンで使用した場合、効果的にクラスタリングすることができません。
●コンテナ数が増えると管理コストが増加します。
●効果的な災害復旧および自己修復メカニズムがない
●事前に設定されたオーケストレーションテンプレートがなければ、迅速かつ大規模なコンテナのスケジューリングを実現できません。
●統合された構成管理センターツールがない
●コンテナのライフサイクル管理ツールがない
●グラフィカルな運用保守管理ツールがない
k8s は、コンテナ オーケストレーション、リソース スケジューリング、エラスティック スケーリング、デプロイメント管理、サービス ディスカバリなどの一連の機能を提供します。
3. k8sの特徴
●伸縮性に優れています。
コマンド、UI を使用するか、CPU 使用率に基づいてアプリケーション インスタンスを自動的かつ迅速に拡張および縮小し、アプリケーション ビジネスのピーク時の同時実行時の高可用性を確保します。ビジネスのピーク時が低いときにリソースをリサイクルし、最小限のコストでサービスを実行します。
●自己修復性
ノードに障害が発生した場合は障害が発生したコンテナを再起動し、予想される数のレプリカを確保するために置き換えて再デプロイします。ヘルスチェックに失敗し、オンライン サービスが中断されないように準備が整うまでクライアント要求を処理しないコンテナを強制終了します。
●サービスの検出と負荷分散
K8s は、複数のコンテナに統合されたアクセス入口 (内部 IP アドレスと DNS 名) を提供し、関連するすべてのコンテナの負荷を分散するため、ユーザーはコンテナ IP の問題を考慮する必要がありません。
●自動リリース（デフォルトのローリングリリースモード）とロールバック
K8S はローリング アップデート戦略を使用してアプリケーションを更新し、すべての Pod を同時に削除するのではなく、一度に 1 つの Pod を更新します。更新プロセス中に問題が発生した場合、アップグレードが影響を与えないように、変更はロールバックされます。仕事。
●一元的な構成管理とキー管理
画像内の機密データを公開することなく機密データとアプリケーション構成を管理し、機密データのセキュリティを向上させます。また、一般的に使用される構成の一部を K8S に保存して、アプリケーションの使用を容易にすることができます。
●ストレージオーケストレーション、プラグインストレージをサポートし、プラグインストレージリソースを手配します。
外部ストレージ システムのマウントは、ローカル ストレージ、パブリック クラウド (AWS など)、ネットワーク ストレージ (NFS、Glusterfs、Ceph など) を問わず、クラスター リソースの一部として使用され、ストレージ使用の柔軟性が大幅に向上します。
●タスクバッチ処理実行中
ワンタイムタスクとスケジュールされたタスクを提供: バッチデータの処理と分析のシナリオに対応します
2. k8s クラスターのアーキテクチャとコンポーネント
K8s はマスター/スレーブ デバイス モデル (マスター/スレーブ アーキテクチャ) に属します。つまり、マスター ノードはクラスターのスケジューリング、管理、運用と保守を担当し、スレーブ ノードはクラスター内のコンピューティング ワークロード ノードです。 。
K8Sでは一般にメインノードをマスターノード、スレーブノードをワーカーノードと呼び、各ノードにはマスターからワークロードが割り当てられます。
マスター コンポーネントはクラスター内の任意のコンピューターで実行できますが、マスター ノードは別のサーバーを占有することをお勧めします。
マスターはクラスター全体の頭脳であるため、マスターが配置されているノードがダウンしているか使用できない場合、すべての制御コマンドが無効になります。
マスターに加えて、K8s クラスター内の他のマシンはワーカー ノードと呼ばれ、ノードがダウンすると、そのノード上のワークロードはマスターによって自動的に他のノードに転送されます。
1. マスターコンポーネント
マスター: クラスター制御管理ノード。すべてのコマンドはマスターによって処理されます。
●Kube-apiserver
Kubernetes API を公開するために使用され、リソースのリクエストや呼び出し操作は kube-apiserver によって提供されるインターフェイスを通じて実行されます。HTTP レストフル API
インターフェイス サービスを提供します。オブジェクト リソースのすべての追加、削除、変更、監視操作は API サーバーに渡されて処理され、Etcd ストレージに送信されます。
API Server は K8S のリクエストエントリサービスであることがわかります。API サーバーは、(UI インターフェイスまたは CLI コマンド ライン ツールからの) すべての K8S リクエストを受信する責任があります。
その後、ユーザーの特定の要求に従って、他のコンポーネントが動作するように通知されます。API サーバーは、K8S クラスター アーキテクチャの頭脳であると言えます。
●Kube コントローラーマネージャー
運用管理コントローラは、K8S クラスタ内の通常のタスクを処理するバックグラウンド スレッドであり、K8S クラスタ内のすべてのリソース オブジェクトの自動制御センターです。
K8S クラスタでは、リソースはコントローラに対応し、コントローラ マネージャはこれらのコントローラの管理を担当します。
これは、APIServer を通じてクラスター全体のステータスを監視し、クラスターが期待どおりの動作状態にあることを確認する一連のコントローラーで構成されています。たとえば、ノードが予期せずクラッシュした場合、コントローラー マネージャーはすぐに検出して自動修復プロセスを実行します。クラスターが常に期待どおりの動作状態にあることを確認します。
これらのコントローラーには主に次のものが含まれます。
●ノードコントローラー: ノード障害の検出と対応を担当します。
●レプリケーション コントローラー: ポッドがクラスター内の RC (リソース オブジェクト レプリケーション コントローラー) に関連付けられていることを確認する責任を負います。
部数は常にデフォルト値のままです。これは、クラスター内に N 個の Pod インスタンスのみが存在することを保証するものと理解できます。N は、RC で定義された Pod コピーの数です。
●エンドポイント コントローラー: エンドポイント オブジェクトを入力し (つまり、サービスとポッドを接続します)、サービスと対応するポッドのコピーの変更を監視する責任を負います。
エンドポイントはサービスによって公開されるアクセス ポイントであると理解できますが、サービスにアクセスする必要がある場合は、そのエンドポイントを知る必要があります。
●サービス アカウントとトークン コントローラー (サービス アカウントとトークン コントローラー): 新しい名前空間のデフォルト アカウントと API アクセス トークンを作成します。
●ResourceQuota コントローラー (リソース クォータ コントローラー): 指定されたリソース オブジェクトがシステムの物理リソースを常に過剰に占有しないようにします。
●Namespace Controller: 名前空間のライフサイクルを管理します。
●サービスコントローラー：K8Sクラスターと外部クラウドプラットフォーム間のインターフェースコントローラー
●Kubeスケジューラー
これはリソースのスケジューリングを担当するプロセスであり、スケジューリング アルゴリズムに従って、新しく作成された Pod に適切な Node ノードを選択します。
これは、すべての K8S Node ノードのスケジューラとして理解できます。ユーザーがサービスをデプロイしたい場合、スケジューラは、スケジューリング アルゴリズムに基づいて、ポッドをデプロイするのに最適なノードを選択します。
●予算戦略（述語）
●優先事項
2. ストレージセンターの構成 - etcd
K8Sストレージサービス
etcd は、K8S のキー設定とユーザー設定を保存する分散キー/値ストレージ システムです。K8S の API サーバーのみが読み取りおよび書き込み権限を持ちます。他のコンポーネントは、API サーバー インターフェイスを通じてデータの読み取りおよび書き込みを行う必要があります。
3. ワーカーノードコンポーネント
3.1 ノードノードのワークフロー:
ノードが正しくインストールされ、構成され、上記の主要なプロセスで開始されている場合、ノード ノードを kubernetes クラスターに動的に追加できます。デフォルトでは、kubelet 自体がマスターに登録されます。これは、推奨されるノード管理方法でもありますKubernetesによって。
ノードがクラスター管理スコープに含まれると、kubelet は定期的に自身の状況をマスターに報告するだけでなく、以前にどの Pod が実行されていたかなども報告します。これにより、マスターは各ノードのリソース使用状況を把握し、効率的なサービスを実装できるようになります。バランスの取れたリソース スケジューリング戦略。
ノードが時間通りに情報を報告できない場合、マスターによって切断されたと判断され、ノードのステータスは「準備完了」としてマークされ、マスターはワークロード転送プロセスをトリガーします。
●キュベレット
Node ノードの監視者および Master ノードとの通信者。Kubelet は、ノード ノードにインストールされたマスター ノードの「アイライナー」であり、定期的に API サーバーに自身を報告します。
ノードノードで実行されているサービスのステータスを確認し、マスターノードからの指示を受け入れて調整措置を講じます。
マスター ノードから独自のノード上のポッドの予想されるステータス (実行中のコンテナー、実行中のレプリカの数、ネットワークまたはストレージの構成方法など) を取得します。
コンテナ エンジンと直接対話して、コンテナ ライフ サイクル管理を実装します。自分のノード上のポッドのステータスが予期されたステータスと一致しない場合は、対応するコンテナ プラットフォーム インターフェイス (つまり、docker インターフェイス) を呼び出して、このステータスを実現します。
イメージとコンテナのクリーンアップを管理して、ノード上のイメージがディスク領域全体を占有しないように、また、終了したコンテナが多くのリソースを占有しないようにします。
●Kube-プロキシ
ポッド ネットワーク エージェントは各ノード ノードに実装されます。これは Kubernetes Service リソースのキャリアであり、ネットワーク ルールと 4 層の負荷分散を維持する責任を負います。サービス マッピング アクセスを実装するための iptables および ipvs へのルールの作成を担当します。
Kube-Proxy 自体は Pod に直接ネットワークを提供するのではなく、Kubelet によって提供され、実際には仮想 Pod クラスター ネットワークを維持します。
Kube-apiserver は Kubernetes Service を更新し、Kube-Proxy を監視することでエンドポイントを維持します。
K8S クラスター内のマイクロサービスの負荷分散は、Kube プロキシによって実装されます。Kube-proxy は、K8S クラスター内のロード バランサーです。これは、K8S の各ノードで Kube プロキシ コンポーネントを実行する分散プロキシ サーバーです。
●docker エンジン (docker または rocket)
コンテナ エンジンはコンテナを実行し、ローカル コンテナの作成と管理を担当します。
3. K8s のコアコンセプト
Kubernetes には、ポッド、ラベル、サービス、レプリケーション コントローラーなど、多くの種類のリソース オブジェクトが含まれています。
すべてのリソース オブジェクトは、Kubernetes が提供する kubectl ツールを使用して追加、削除、変更、確認などを行うことができ、永続ストレージとして etcd に保存できます。
Kubernets は、実際には高度に自動化されたリソース制御システムであり、etcd ストレージに保存されている予想されるリソースの状態と、現在の環境における実際のリソースの状態との差異を追跡および比較することで、自動制御や自動エラー修正などの高度な機能を実現します。
●ポッド
ポッドは、Kubernetes によって作成またはデプロイされる最小/単純な基本単位であり、クラスター上で実行されているプロセスを表します。
ポッドはエンドウ豆のさやとして理解でき、同じポッド内の各コンテナはエンドウ豆です。
ポッドは 1 つ以上のコンテナで構成され、ポッド内のコンテナはネットワーク、ストレージ、コンピューティング リソースを共有し、同じ Docker ホスト上で実行されます。
複数のコンテナを Pod 内で実行できます。これは、サイドカー モード (sideCara) モードとも呼ばれます。実稼働環境では、単一のコンテナー、または強い相関性と相補性を持つ複数のコンテナーでポッドを形成します。
同じポッド間のコンテナはローカルホスト経由で相互にアクセスでき、ポッド内のすべてのデータ ボリュームをマウントできますが、異なるポッド間のコンテナはローカルホスト経由でアクセスしたり、他のポッドのデータ ボリュームをマウントしたりすることはできません。
●ポッドコントローラー（5つの主要コントローラー）
ポッド コントローラーはポッド起動用のテンプレートであり、K8S で起動されたポッドが常にユーザーの期待 (コピー数、ライフ サイクル、ヘルス ステータス チェックなど) に従って実行されるようにするために使用されます。
K8S は多数の Pod コントローラーを提供しており、以下が一般的に使用されます。
●デプロイメント: ステートレスなアプリケーションのデプロイメント。Deployment の役割は、Pod と Replicaset を管理および制御し、ユーザーが期待する状態で実行されるように制御することです。
●レプリカセット: 予想されるポッド レプリカ数を確保します。Replicaset の役割は、Pod を管理および制御し、それらが適切に動作するように制御することです。ただし、Replicaset はデプロイメントによって制御されます。
Deployment はゼネコンであり、主に以下のワーカー Pod の作業を監督し、ユーザーが必要とする数の Pod が常に動作していることを確認する責任を負っていることがわかります。
ワーカー ポッドが使用不能になっていることがわかった場合は、すぐに新しいポッドを引き込んで置き換えます。ReplicaSetはゼネコンの下請け会社です。
K8S ユーザーの観点から見ると、ユーザーは Deployment デプロイメント サービスを直接操作することになり、Deployment がデプロイされると、K8S は必要な ReplicaSet と Pod を自動的に生成します。
ユーザーは、ReplicaSet ではなくデプロイメントのみを気にする必要があります。
リソース オブジェクト レプリケーション コントローラーは ReplicaSet の前身であり、サービスをデプロイするにはレプリケーション コントローラーの代わりにデプロイメントを使用することが公式に推奨されています。
●Daemonset: すべてのノードが同じタイプの Pod を実行していることを確認し、各ノードでそのような Pod が 1 つ実行されていることを確認し、通常、システム レベルのバックグラウンド タスクを実装するために使用されます。
●Statefulset: ステートフルなアプリケーションのデプロイメント
●仕事：単発の仕事。ユーザーの設定に従って、ジョブが管理するポッドは、タスクが正常に完了すると自動的に終了します。
●Cronjob：定期的にスケジュールされたタスク
●ラベル
タグは、リソース オブジェクトの分類と管理を容易にする K8S 独自の管理方法です。
ラベルは、ノード、ポッド、サービス、RC などのさまざまなリソース オブジェクトに添付でき、オブジェクトの関連付け、クエリ、フィルターに使用されます。
ラベルはキーと値のペアであり、キーと値はユーザーによって指定されます。
リソース オブジェクトでは、任意の数のラベルを定義できます。同じラベルを任意の数のリソース オブジェクトに追加することもできます。また、オブジェクトの作成後に動的に追加または削除することもできます。
多次元リソース グループ管理機能は、1 つ以上の異なるラベルを指定されたリソース オブジェクトにバンドルすることによって実現できます。
Labelと同様にAnnotation(注釈)もあります
違いは、有効なタグ値は 63 文字以下である必要があり、空であるか、英数字 ([a-z0-9A-Z]) で開始および終了する必要があり、ダッシュ (-)、アンダースコア (_) を含めることができることです。 、ドット (.) および文字または数字。注釈値には文字数制限がありません
●ラベルセレクター(Label selector)
リソース オブジェクトのラベルを定義することは、ラベルを与えることと同じです。その後、ラベル セレクター (ラベル セレクター) を使用して、特定のラベルを持つリソース オブジェクトをクエリおよびフィルターできます。
現在、タグ セレクターには 2 種類あります。1 つは等価関係 (等しい、等しくない) に基づくもの、もう 1 つはセットの関係 (に属する、属さない、存在する) に基づくものです。
●サービス
K8S クラスターでは、各 Pod には個別の IP アドレスが割り当てられますが、Pod にはライフサイクルがあるため (作成可能で、破棄後に再起動されない)、ビジネスの変化によりいつでも変更される可能性があります。その結果、Pod が破壊されると、この IP アドレスも消えてしまいますが、この問題を解決するために使用される中心的な概念がサービスです。
K8S のサービスは、私たちがよく「サービス」と呼ぶものを意味するのではなく、ゲートウェイ層に近いものであり、同じサービスを提供するポッドのグループの外部アクセス インターフェイスおよびトラフィック バランサーとみなすことができます。ラベルを介してセレクターによって定義されます。
K8S クラスターでは、Service は、同じサービスを提供する Pod のグループの外部アクセス インターフェイスとみなすことができます。クライアントがアクセスする必要があるサービスは Service オブジェクトです。
各サービスには固定仮想 IP (この IP はクラスター IP とも呼ばれます) があり、バックエンド ポッドに自動的かつ動的にバインドされます。すべてのネットワーク リクエストはサービスの仮想 IP に直接アクセスし、サービスはそれを自動的に次のポッドに転送します。バックエンド。
安定した外部アクセス方法を提供することに加えて、サービスはロード バランサーとしても機能し、リクエスト トラフィックをすべてのバックエンド サービスに自動的に分散します。サービスは顧客に対して透過的に水平に拡張できます。)
サービス機能を実現する鍵となるのがkube-proxyです。kube-proxy は各ノードで実行され、API サーバー内のサービス オブジェクトの変更を監視します。
ネットワーク転送は、ユーザースペース (廃止予定)、iptables (廃止寸前)、および ipvs (推奨、最高のパフォーマンス) の 3 つのトラフィック スケジューリング モードを通じて実現できます。
サービスはK8Sサービスの中核であり、サービスの詳細を保護し、サービスのインターフェースを統一的に外部に公開することで、まさに「マイクロサービス」を実現します。たとえば、サービスの 1 つである A は 3 つのサービスを導入しました。
Pod は 3 つ、つまり 3 つありますが、ユーザーは 1 つの Service の入り口に注目するだけでよく、どの Pod をリクエストすればよいかを気にする必要がありません。
利点は非常に明らかです。一方で、外部ユーザーは、Pod 上のサービスの予期しないクラッシュや K8S による Pod の再起動によって引き起こされる IP の変更を認識する必要がなく、また、外部ユーザーは、アップグレードとサービスの変更 IP の変更。
●イングレス
サービスは主に K8S クラスター内のネットワーク トポロジを担当しますが、クラスターの外部からクラスターの内部にどのようにアクセスするのでしょうか? このとき、Ingress が必要になります。
Ingress は K8S クラスター全体のアクセス層であり、クラスター内外の通信を担当します。
Ingress は、OSI ネットワーク参照モデルに基づいて K8S クラスターで動作するレイヤー 7 アプリケーションです。外部に公開されたインターフェイスです。一般的なアクセス方法は http/https です。
サービスは、IP+ポートの形式で、第 4 層でのみトラフィック スケジューリングを実行できます。Ingress は、さまざまなビジネス ドメインおよびさまざまな URL アクセス パスでビジネス トラフィックをスケジュールできます。
例: クライアントは http://www.ly.com:port ---> Ingress ---> Service ---> Pod をリクエストします。
●名前
K8S は内部的に「リソース」を使用して各論理概念 (機能) を定義するため、各「リソース」には独自の「名前」が必要です。
「リソース」には、APIのバージョン（apiversion）、カテゴリ（kind）、メタデータ（metadata）、定義リスト（spec）、ステータス（status）などの構成情報が含まれます。
「名前」は通常、「リソース」の「メタデータ」情報で定義されます。同じ名前空間内で一意である必要があります
●名前空間
プロジェクトの増加、人員の増加、クラスタ規模の拡大に伴い、K8S内のさまざまな「リソース」を論理的に分離する手法が必要になります、それがNamespaceです。
名前空間は、K8S クラスターをリソースを共有できない数千の仮想クラスター グループに分割するために生まれました。
異なる名前空間内の「リソース」の名前は同じにすることができますが、同じ名前空間内の同じタイプの「リソース」の「名前」を同じにすることはできません。
K8S 名前空間を適切に使用すると、クラスター管理者は、K8S に提供されるサービスをより適切に分類、管理、参照できるようになります。
K8S のデフォルトの名前空間には、default、kube-system、kube-public などが含まれます。
K8S で特定の「リソース」をクエリするには、対応する名前空間を取得する必要があります。
k8s のアーキテクチャとワークフロー
マスターノード: APIサーバーシュスケジューラコントローラマネージャ
ワーカーノード ノード: kubelet kube-proxy docker エンジン
ワークフローまたは各コンポーネントの機能:
1. ユーザーがクライアント経由で API サーバーにリクエストを送信すると、API サーバーはリクエストを受信してポッドのバッチを作成し、ポッド データを etcd に保存します。
2. コントローラーマネージャーは API サーバー経由で etcd を読み取り、事前設定されたテンプレートに従ってポッドを作成します。コントローラーマネージャーは API サーバーを使用して、新しく作成されたポッドに適切なノードを選択するようにスケジューラーに要求します。
3. スケジューラは、予算戦略と最適化戦略に基づいて最適なノードを選択し、API サーバーを通じて対応するノード上の kubelet を見つけます。
4. Kubelet は、スケジューリング結果に基づいて Pod の作成操作を実行し、ノードを監視すると同時に、実行中の自ノードのサービス状態を API サーバーに定期的に報告し、etcd に保存します。
5. ノード上のコンテナは、Kubelet の指示に従ってポッドの作成を具体的に実装します。
6. ノード node 上の kube-proxy は、Kubernetes Service リソースのキャリアであるポッドのネットワーク プロキシを実装するために使用されます。顧客は、kube-proxy によって提供される IP を介してポッド内のビジネスにアクセスできます。