コンテナオーケストレーション技術Kubernetesの包括的な分析

この記事はWeChatの公開アカウント「建築改善への道」から転載したもので、著者は建築改善への道です。この記事を転載する場合は、Road to Architecture Improvement の公開アカウントまでご連絡ください。

1. コンテナオーケストレーション技術

コンテナ オーケストレーションとは、複数のコンテナの展開、管理、監視を指します。

コンテナ オーケストレーション テクノロジが存在する理由は、実は、ビジネス量の増加とシステムの複雑化に伴うサービス展開の進化と密接に関係しています。次の図は、サービス展開方法の進化プロセスを示しています。

システム リソースのより効率的な使用、一貫した動作環境、より容易な移行と拡張、その他多くの利点により、コンテナーの導入はますます主流になっています。

Docker はオープンソースで広く使用されているコンテナ エンジンです。実際の運用環境では、複数の物理ホスト間でコンテナ リソースを調整することが、解決すべき主な問題になります。この問題は総称してコンテナ オーケストレーションと呼ばれます。

コンテナ分野における現在の議論の焦点は、コンテナ ホスト グループ管理にコンテナ オーケストレーション機能をどのように提供するかということです。

現在人気のあるコンテナ オーケストレーション ツールには、Docker Swarm、Kubernetes、Mesos+Marathon などがあります。コンテナの使用における中心的な問題は、コンテナ オーケストレーションと、コンテナをデプロイおよび管理する方法です。 Docker Swarm、Kubernetes、Mesos+Marathon はすべてコンテナのデプロイ、管理、スケーリングに使用できますが、3 つのオーケストレーション ツールはそれぞれ異なる問題とユースケースに重点を置いています。

2. Kubernetesを使い始める

2.1 Kubernetesの概要

Kubernetes (k8s とも呼ばれる) は、コンテナの展開、管理、容量拡張など、コンテナに必要なオーケストレーション機能をユーザーに提供できます。

Kubernetes のオーケストレーション機能を使用すると、ユーザーは複数のコンテナのアプリケーション サービスを構築し、これらのコンテナをクラスター間でスケジュールおよびスケーリングし、これらのコンテナを管理して長期的に健全性状態を検出できます。

2.2 Kubernetes で何ができるのか?

Kubernetes は主に以下の機能をユーザーに提供します。

• サービス検出と負荷分散: Kubernetes は、DNS 名またはクラスター IP アドレスを使用してコンテナを公開できます。コンテナに入るトラフィックが大きい場合、Kubernetes は負荷分散を使用してトラフィックを均等に分散し、サービスを安定させることができます。
• ストレージ オーケストレーション: Kubernetes を使用すると、ローカル ストレージ、パブリック クラウド プロバイダーなど、選択したストレージ システムを自動的にマウントできます。
• 自動デプロイとロールバック: Kubernetes を使用すると、デプロイされたコンテナの望ましい状態を記述でき、制御された速度で実際の状態を望ましい状態に変更できます。たとえば、新しいコンテナを自動的に作成し、既存のコンテナを削除して、そのすべてのリソースを新しいコンテナに使用することができます。
• コンピューティングを自動的にパックする: Kubernetes では、各コンテナに必要な CPU とメモリ (RAM) を指定できます。コンテナがリソース要求を指定すると、Kubernetes はコンテナのリソースの管理についてより適切な決定を下すことができます。
• 修正: Kubernetes はコンテナを再起動したり、コンテナを置き換えたり、定義されたヘルスチェックを満たさないコンテナを強制終了したりできますが、これらの機能はクライアントには見えません。
• シークレットと構成の管理: Kubernetes を使用すると、パスワード、OAuth トークン、SSH キーなどの機密情報を保存および管理できます。コンテナ イメージを再構築したり、スタック構成でシークレットを公開したりすることなく、シークレットとアプリケーション構成をデプロイおよび更新できます。

2.3 なぜ Kubernetes なのか?

基本に戻って: なぜ Kubernetes なのか?

スケーラビリティ

Kubernetes は非常にスケーラブルです。 K8s には、Pod、Deployment、StatefulSets、Secrets、ConfigMaps などのリソースのセットが組み込まれています。ユーザーと開発者は、「カスタム リソース定義」の形式でさらにカスタム リソースを追加することもできます。 Kubernetes の拡張性のもう 1 つの形態は、開発者が独自の Operator を作成できる機能です。これにより、ユーザーは Kubernetes API と通信してカスタム リソース定義を自動的に管理できます。

強力なコミュニティ

Kubernetes の人気のもう一つの重要な側面は、その強力なコミュニティです。 Kubernetes は、2015 年にバージョン 1.0 でベンダー中立の財団に寄贈されました。 Kubernetes は Github 上で最もアクティブなプロジェクトの 1 つであり、すべてのプロジェクトの上位 0.01% にランクされています。プロジェクトが進むにつれて、Kubernetes のさまざまな領域を対象としたさまざまなコミュニティ SIG (Special Interest Groups) も登場します。新しい機能を継続的に追加し、よりユーザーフレンドリーなサービスを実現しています。

テクノロジーとイノベーション

Kubernetes は、Borg の 15 年にわたる集中的な開発と生産実践の成果である Google の Borg オープンソース テクノロジーに基づいています。過去数年間、Kubernetes では毎年 3 ～ 4 回のメジャー リリースとマイナー リリースが行われてきました。新機能の導入ペースは鈍っておらず、クラスター オペレーターはさまざまなワークロードをより柔軟に実行できます。ソフトウェア エンジニアは、アプリケーションを本番環境に直接デプロイするための制御も強化されます。

3. Kubernetesの構成と基本原則

3.1 Kubernetes クラスター

上の図から、クラスターは主に 2 つの部分で構成されていることがわかります。

• マスター ノード (コントロール プレーンとも呼ばれます) は、Kubernetes クラスターの頭脳です。

これらには次のコンポーネントが含まれます。

• API サーバー: システム全体の外部インターフェイスであり、クライアントや他のコンポーネントによって呼び出され、「ビジネス ホール」に相当します。
• Etcd: API サーバーのバックエンド データ ストレージ。Kubernetes クラスターのデータ センターに相当します。
• スケジューラ: クラスター内のリソースのスケジュールを担当し、「スケジュール ルーム」に相当します。
• コントローラー マネージャー: Kubernetes クラスター内のリソースが必要に応じて実行されるようにするコントロール マネージャー。

2. ノード ノードのグループ (ワーカー ノードとも呼ばれます) は、主にポッドの操作を担当します。

主なコンポーネントは次のとおりです。

• Kubelet: マスターノードと対話して特定のタスクを実行します。
• Kubelet: マスターノードと対話して特定のタスクを実行します。
• Kube-proxy: Kubernetes クラスター内の負荷分散を担当します。
• Container-runtime: docker、rkt、その他のコンテナ実装標準を含むコンテナランタイム環境を提供し、コンテナの操作、起動、シャットダウンなどを担当します。
• Pod: k8s の最小のスケジューリング単位。ポッドには 1 つ以上のコンテナーを含めることができます。ポッドはコンテナの集合として理解できます。

3.2 マスターノードと操作メカニズム

マスター ノードには、Api サーバー、スケジューラ、コントローラ マネージャー、Etcd が含まれていることがわかります。

以下では、これらのコンポーネントを一つずつ紹介します。

API サーバー

Kubernetes API サーバーは、クラスターの統合された入り口であり、さまざまなコンポーネントのコーディネーターです。 HTTP API とのインターフェース サービスを提供します。すべてのオブジェクト リソースの追加、削除、変更、クエリ、および監視操作は、最初に API サーバーによって処理され、次のステップで Etcd に保存されます。

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

コントローラー マネージャーは Kubernetes のリソース マネージャーです。沢山あります

ノード、ポッドレプリカ、サービスエンドポイント、名前空間、サービスアカウントなどのリソース

ServiceAccount など。コントローラー マネージャーは、これらのリソースの実際の動作状態が期待どおりの状態になるように、これらのリソースを管理する責任があります。

その他

Etcd は、主に共有構成とサービス検出に使用される、可用性の高いキー値ストレージ システムです。これは Go で記述されており、強力な一貫性を確保するために Raft コンセンサス アルゴリズムを通じてログのレプリケーションを処理します。

Etcd は、Kubernetes クラスターのデータ センターとして理解でき、Pod、サービス、その他のオブジェクト情報などのクラスターのステータス情報を保存するために使用されます。 Etcd は主に API サーバーと対話します。操作コマンドを受信すると、API サーバーは情報を Etcd に保存します。以下のポッド ステータス フローからわかるように、API サーバーは完全なポッド情報を構築し、その情報を etcd に保存します。

スケジューラ

Scheduler は、Kubernetes クラスター内のスケジューラです。スケジューラの機能は、特定のスケジューリング アルゴリズムとスケジューリング戦略に従って、スケジュールする Pod をクラスター内の適切なノードにバインドし、API サーバーを呼び出してバインド情報を etcd に書き込むことです。スケジューラはシステム全体において重要な役割を果たします。アップストリーム機能は、コントローラー マネージャーによって作成された新しい Pod を受信し、それが定着するためのターゲット ノードを配置する役割を担います。ダウンストリーム機能は、ノードの配置作業が完了した後、ターゲットノード上の kubelet サービスプロセスが Scheduler の後続の作業を引き継ぎます。

3.3 ノードと動作メカニズム

ノードには主に Kubelet、Kube-proxy、Pod が含まれますが、その中で最も重要なのは Pod です。

以下、一つずつ紹介していきます。

クベレット

Kubelet はノード上のマスターのエージェントです。各ノードは kubelet プロセスを開始します。このプロセスは、マスターからノードに送信されたタスクを処理し、ポッドとポッド内のコンテナを管理するために使用されます。各 kubelet プロセスは、API サーバーにノード情報を登録し、ノード リソースの使用状況をマスターに定期的に報告し、コンテナとノードのリソースを監視します。

kubelet が起動すると、API サーバーを介してノード情報を登録し、定期的に新しいノード情報を API サーバーに送信します。 API サーバーは情報を受け取った後、それを etcd に書き込みます。 Kubelet は etcd を監視し、Pod 上のすべての操作は kubelet によって監視されます。このノードにバインドされた新しい Pod が見つかった場合、Pod リストの要件に従って Pod が作成されます。ローカル Pod が変更されていることが判明した場合、kubelet は対応する変更を加えます。たとえば、Pod 内のコンテナを削除する場合、ローカル コンテナ ランタイムを操作することでコンテナが削除されます。

Kube プロキシ

kube-proxy サービス プロセスは、Kubernetes クラスター内の各ノードで実行されます。その主な機能は、サービスへのアクセス要求をバックエンドの複数の Pod インスタンスに転送することです。 kube-proxy は本質的にはリバース プロキシのようなものです。各ノードで実行されている kube-proxy は、サービスの透過プロキシおよびロードバランサーと考えることができます。 kube-proxy は、API サーバー内のサービスとエンドポイントの情報も監視し、構成された iptables ルールを通じて iptables 経由でリクエストをポッドに直接転送します。

ポッド

Pod は最小のデプロイメント ユニットです。 Pod は 1 つ以上のコンテナーで構成されます。 Pod 内のコンテナはストレージとネットワークを共有し、同じ Docker ホスト上で実行されます。

ポッド構造の概略図は次のとおりです。

一時停止ルート コンテナーと 1 つ以上のビジネス コンテナーで構成されていることがわかります。

Kubernetes の一時停止コンテナは、主に各業務コンテナに対して以下の機能を提供します。

• PID 名前空間: Pod 内のさまざまなアプリケーションは、他のアプリケーションのプロセス ID を参照できます。
• ネットワーク名前空間: Pod 内の複数のコンテナが同じ IP とポート範囲にアクセスできます。
• IPC 名前空間: Pod 内の複数のコンテナは、システム IPC または POSIX メッセージ キューを使用して通信できます。
• UTS名前空間: ポッド内の複数のコンテナがホスト名を共有するボリューム(共有ストレージボリューム)

Pod 内の複数のビジネス コンテナは、一時停止コンテナのネットワーク スタックとボリューム マウントを共有します。

ビジネス コンテナーはこれらのリソースを共有するため、同じ Pod 内のコンテナーは localhost 経由でのみ相互に通信でき、コンテナー間の通信とデータ交換がより効率的になります。設計時にこの機能を最大限に活用して、密接に関連するサービス プロセスのグループを同じ Pod に配置できます。

3.4 ポッド数とバージョン管理

ReplicationController は、コンテナ アプリケーションのレプリカの数が常にユーザー定義のレプリカの数に維持されるようにするために使用されます。つまり、コンテナが異常終了した場合、それを置き換える新しい Pod が自動的に作成されます。

新しいバージョンの Kubernetes では、ReplicationController の代わりに ReplicaSet を使用することをお勧めします。 ReplicaSet ReplicaSet は本質的には ReplicationController と違いはありませんが、名前が異なり、ReplicaSet はセットセレクターをサポートしています。 ReplicaSet は単独で使用することもできますが、通常は Deployment を使用して ReplicaSet を自動的に管理することが推奨されるため、他のメカニズムとの非互換性を心配する必要はありません。 Deployment は、Pod と ReplicaSet の宣言的な定義方法を提供し、以前の ReplicationController を置き換えて、アプリケーションを便利に管理します。展開の典型的なシナリオ: ローリングアップデート

デプロイメントでは、ローリング アップデートだけでなく、ロールバックも実行できます。 V2 にアップグレードした後にサービスが利用できなくなった場合は、V1 にロールバックできます。

3.5 ポッド作成プロセス

Kubernetes の各コンポーネントの動作プロセスを理解するために、Pod の作成を例に挙げてみましょう。

• API サーバーはクラスターに Pod を作成するコマンドを送信し、API サーバーは YAML ファイル内の構成属性情報 (メタデータ) を etcd に書き込みます。
• apiserver は、ポッドを作成する準備をするためにウォッチ メカニズムをトリガーし、その情報をスケジューラに転送します。スケジューラはスケジューリング アルゴリズムを使用してノードを選択し、ノード情報を API サーバーに送信します。 apiserver はバインドされたノード情報を etcd に書き込みます。
• API サーバーは、watch メカニズムを通じて kubelet を呼び出し、ポッド情報を指定して、docker run コマンドをトリガーし、コンテナを作成します。
• 作成が完了すると、kubelet にフィードバックが与えられ、kubelet はポッドのステータス情報を API サーバーに送信し、API サーバーはポッドのステータス情報を etcd に書き込みます。
• この時点で、Pod が実際に作成されます。何らかの理由で Pod に問題が発生した場合、クラスター内のコントローラー マネージャーは API サーバーに作成リクエストを開始します。

4. Kubernetes サービスの公開

Pod が正常に作成され、適切に管理できるようになったので、クライアントはどのようにして対応する Pod を見つけて、そのサービスを呼び出すことができるでしょうか?

Kubernetes は、サービスを公開する複数の方法をサポートしています。

以下では、広く使用されている 3 つのサービス公開方法として、ClusterIP、NodePort、Ingress を紹介します。 ClusterIP と NodePort は Service リソース タイプに属し、Ingress は Ingress リソース タイプに属します。

4.1 サービス - ClusterIP サービスの公開

Kubernetes クラスターは、対応するクラスター IP を Pod のグループに割り当て、ドメイン名を生成します。サービスに対応するポッドには、クラスター IP またはドメイン名を通じてクラスター内でアクセスできます。

このタイプはクラスター内でのみアクセスでき、デフォルトの ServiceType でもあります。

 apiバージョン: v1kind :サービス仕様:
 メタデータ:
 名前: my - service
 セレクター:
 アプリ:私のアプリ
 タイプ: ClusterIP
 ポート:
 -名前: http
 ポート: 80
 ターゲットポート: 8080
 プロトコル: TCP

上記の例では、ClusterIP サービスを定義しています。 ClusterIP のポート 80 へのトラフィックは Pod (targetPort 構成項目) のポート 8080 に転送され、app: my-app ラベルを持つ Pod がサービスに使用可能なノードとしてサービスに追加されます。

一般的な使用シナリオ:

クラスター内でのサービスの公開。

4.2 サービス - NodePort サービスの公開

NodePort は、固定ポート番号でサービスをクラスターの外部に公開します。クラスター外部からサービスにアクセスできるようになります。クラスターの外部からサービスにアクセスするには、クラスターの IP アドレスと NodePort で指定されたポートを使用する必要があります。

NodePort サービスを作成すると、クラスター内のすべてのノードでポートが開きます。

NodePort サービスを作成すると、ClusterIP サービスも自動的に作成されます。 NodePort はポート上のトラフィックを ClusterIP サービスにルーティングします。

一般的な使用シナリオ:

NodePort を使用すると、開発環境やテスト環境でサービスをすばやくセットアップしたり、TCP または UDP サービスを公開したりできますが、NodePort は非 HTTP 標準ポートを使用するため、HTTP サービスを公開するには最適な選択肢ではありません。

4.3 イングレスサービスの公開

Ingress は、実際には Service とはまったく異なるリソースです。これは、サービス上のプロキシ レイヤーと見なされます。通常、Ingress は HTTP ルーティング構成を提供するために Service の前に使用されます。これにより、外部 URL、ドメインベースの仮想ホスティング、SSL、負荷分散を設定できます。

Ingress リソースが機能するには、クラスターで実行中の Ingress コントローラーが必要です。コントローラー マネージャー コントローラーとは異なり、Ingress コントローラーはクラスターで自動的に起動されません。 Ingress コントローラーとして機能するさまざまな外部コンポーネントを選択できます。

たとえば、nginx-ingress は、nginx サーバーをリバース プロキシとして使用して、トラフィックを次のサービスにルーティングします。

一般的な使用シナリオ:

http および https リクエストからのトラフィックを処理でき、複数のドメイン名からのトラフィックを処理できます。 1 つの IP で複数のアプリケーションを公開したり、同じドメイン名に対して異なる URI をサポートしたり、証明書やその他の機能をサポートしたりできます。使用シナリオは非常に幅広いです。

5. 企業におけるKubernetes

中小企業から大手インターネット企業まで、リソースの利用率を高め、コスト削減と効率化を実現するには、Kubernetes を利用して自動化された運用・保守環境を構築することが最適な選択肢となっています。

次の図は、エンタープライズ サービス クラウド プラットフォームが実現しているクラウド アーキテクチャ機能の青写真であり、サービス コンテナ化がクラウド プラットフォーム基盤の基本機能となっています。コンテナ オーケストレーションと管理の最も基本的な機能に基づいて、容量拡張や電流制限などの運用 API と、ログ記録や監視などの監視可能な API を実装します。上位機能層は、これらの API を通じて、サービス構築、展開、トラフィック制御などの機能を提供できます。

アーキテクチャ図全体において、Kubernetes が重要な役割を果たしていることがわかります。

コンテナ オーケストレーション管理の実装の詳細から、下の図に示すように、7 層の負荷の後、リクエストは Ingress コントローラーのセットにヒットします。コンテナの IP アドレスは頻繁に変更されるため、Ingress は上方向の変更をブロックします。リクエストが Ingress に到達すると、Kubernetes によって制御されます。 Kubernetes は、リクエストを対応するサービスの Pod にルーティングします。同じサービスには複数の Pod があり、これらの Pod も異なる物理マシンに分散されます。現在、Beike は登録に Eureka を使用しています。各ポッドに対応するサービスノードがEurekaに登録されます。サービス A がサービス B を呼び出す必要がある場合、サービス A のポッドを要求した後、Eureka (現在は Eureka+DNS を通じて実装されています) 上のサービス B のポッドのノードを検索します。アップストリーム サービス Pod 情報を取得した後、サービス B の Pod 上のサービスを直接呼び出します。