Kubernetes がコンテナ戦争に勝利する方法

[[281345]]

背景

パース

PaaS テクノロジーを一言でまとめると、「アプリケーション ホスティング」の機能を提供します。

初期の主流のアプローチは、AWS または OpenStack から仮想マシンをレンタルし、これらの仮想マシンを物理マシンとして使用して、スクリプトまたは手動でアプリケーションをデプロイすることでした。このプロセスにおいて、ローカル環境とクラウド環境の一貫性をどのように確保するかが大きな課題であり、クラウドコンピューティング サービスを提供する企業の中核的な競争力は、誰がより優れているかを競うことにあります。ある意味、PaaS の出現はより良い解決策です。

Cloud Foundry を例にとると、Cloud Foundry プロジェクトを仮想マシンにデプロイした後、ユーザーはアプリケーションをクラウドに簡単にアップロードできます。このプロセスを俯瞰すると、Cloud Foundry の中核は、一連のアプリケーションのパッケージ化と配布のメカニズムを提供することです。さまざまなプログラミング言語ごとに異なるパッケージ形式を定義します。実行可能ファイルや起動パラメータなどを圧縮パッケージにまとめ、Cloud Foundry ストレージ センターにアップロードできます。最後に、スケジューラが仮想マシンを選択し、仮想マシン上のエージェントがアプリケーションをダウンロードして起動します。

分散システム

ソフトウェアの規模が拡大し、ビジネス モデルが複雑になるにつれて、ユーザー数の増加、地域分散、システム パフォーマンスに対する厳しい要件により、サービス アーキテクチャは初期のモノリスから SOA へ、そして今日のマイクロサービスへと進化してきました。将来的には、サービスメッシュ、サーバーレスなどへと進化する可能性があります。

今日では、完全なバックエンド システムはもはやモノリシックなアプリケーション アーキテクチャではなくなっており、何年も前の DDD コンセプトが再び注目を集めています。今日のシステムは、異なる責任と機能を持つ複数のサービスに分割されています。サービス間の複雑な関係と単一マシンの単一ポイントのパフォーマンスボトルネックにより、導入と運用が非常に複雑になるため、大規模な分散システムを導入して運用する必要性が急務となっています。

コンテナ技術

前述の通り、Cloud Foundry などの PaaS では、ユーザーは言語やフレームワークごとに異なるパッケージング方法を区別する必要があります。この梱包プロセスは非常に悲惨です。現実はたいていもっと悪いです。アプリケーションがローカルで正常に動作する場合、リモート環境との不整合が原因でパッケージ化後にクラウドでデバッグし、最終的にアプリケーションを「スムーズに」実行できるようにする必要があります。

Docker の出現によってすべてが変わりました。この問題は画像の助けを借りて解決しました。 Docker は全力を尽くし、完全なオペレーティング システム ディレクトリをパッケージにパッケージ化しました。このような高度な統合により、クラウドとローカル環境間の高度な一貫性が保証され、いつでもどこでも簡単に移植できます。

ミラーという単純な機能だけで、Docker が PaaS に対する次元削減攻撃を完遂し、市場を占領したことは誰も知りませんでした。当時、いくつかのスマートテクノロジー企業が Docker に追随し、CaaS と呼ばれる独自のコンテナ クラスター管理プロジェクトを立ち上げました。

コンテナ テクノロジーは、分離を実現するために名前空間を使用し、制限を実現するために Cgroups を使用します。 Docker 実装では、コンテナの完全なシステム実行環境を提供するためにイメージが使用され、レイヤー設計を実装するために UnionFS が使用されます。

Docker コンテナはサンドボックス メカニズムを完全に使用し、それらの間にインターフェースはありません。 Docker を使用すると、プロセス、ネットワーク、マウント ポイント、ファイルの分離を実現し、ホスト リソースをより有効に活用できます。 Docker は非常に強力なので、ホストマシンの依存関係について心配する必要はありません。イメージが構築されると、すべてが可能になります。これが、Docker がコンテナ テクノロジーの標準となった理由です。したがって、Kubernetes ではデフォルトで Docker がコンテナとして使用されていることがわかります (rkt もサポートされています)。

クベネフィット

長い準備を経て、ようやくこの記事の主人公にたどり着きました。 Kubernetes について話す前に、Compose、Swarm、Machine について触れておく必要があります。実際、Kubernetes が市場を席巻する前から、コンテナ オーケストレーション機能のほとんどはすでに実現されていました。しかし、本当に大規模なシステムとなると、Mesosphere が開発した大規模クラスタ管理システム、さらにはその後継の Kubernetes に比べてはるかに劣ります。

コンテナ化とマイクロサービスの時代では、サービスとコンテナがますます増えています。 Docker はロゴのように海を自由に泳ぐクジラであり、Kubernetes は舵を取る船長のようにクジラを導き、秩序正しく管理します。このプロセスは実際にはコンテナ オーケストレーションです。

Kubernetes は Google から生まれ、その設計の多くは Borg から派生しています。これは、クラウド プラットフォーム内の複数のホスト上のコンテナ化されたアプリケーションを管理するためのオープン ソース プラットフォームです。 Kubernetes の目標は、コンテナ化されたアプリケーションの展開をシンプルかつ効率的にすることであり、アプリケーションの展開、計画、更新、保守のためのメカニズムを提供します。

まとめ

ここまでで、読者は Kubernetes の過去と現在について学びました。 PaaS の人気により、コンテナ技術の戦争が勃発しました。この戦争に勝つための鍵は強力なコンテナ オーケストレーション機能を持つことであり、Kubernetes が間違いなくこの戦争の勝者です。

デザインコンセプト

このセクションでは、Kubernetes の 4 つの設計コンセプトに焦点を当て、これらのプラクティスが何をもたらすかを見ていきます。

宣言文と命令文

宣言型と命令型は、まったく異なるプログラミング スタイルです。命令型 API では、「コンテナの実行」、「コンテナの停止」など、サーバーが実行するコマンドを直接発行できます。宣言型 API では、システムによって実行される操作を宣言し、システムはその状態に向かって進み続けます。

私たちがよく使用する SQL は宣言型言語です。必要な結果セットをデータベースに伝えます。データベースは、結果セットを取得して結果セットを返すための実行パスを設計するのに役立ちます。ご存知のとおり、データを取得するための処理手順を自分で記述するよりも、SQL 言語を使用してデータを取得する方がはるかに簡単です。

 apiバージョン: extensions/v1beta1
種類: デプロイメント
メタデータ:
名前: etcd オペレーター
仕様:
 レプリカ: 1
 テンプレート：
 メタデータ:
 ラベル:
名前: etcd オペレーター
 仕様:
 コンテナ:
 -名前: etcd-operator
 イメージ: quay.io/coreos/etcd-operator:v0.2.1
 環境:
 -名前: MY_POD_NAMESPACE
 値:
 フィールド参照:
 フィールドパス: metadata.namespace
 -名前: MY_POD_NAME
 値:
 フィールド参照:
 フィールドパス: metadata.name  

同じ YAML 設計を見てみましょう。これを使用すると、Kubernetes に最終的に何が必要かを伝えることができ、Kubernetes が目標を達成します。

宣言型 API により、システムがより堅牢になります。分散システムでは、どのコンポーネントでもいつでも障害が発生する可能性があります。コンポーネントが再開すると、何を実行するかを判断する必要がありますが、これは命令型 API では処理が難しい場合があります。しかし、宣言型 API を使用すると、コンポーネントは API サーバーの現在の状態を確認するだけで、何を実行する必要があるかを判断できます。

明示的なAPI

Kubernetes は透過的です。隠された内部 API はありません。つまり、Kubernetes システム内で対話するために使用される API は、Kubernetes と対話するために使用する API と同じです。

これを行う利点は、Kubernetes のデフォルト コンポーネントがニーズを満たせない場合に、既存の API を使用してカスタム機能を実装できることです。

非侵襲的

Docker コンテナ テクノロジーの人気により、Kubernetes は誰でもシームレスに使用できるようになりました。コンテナ化の時代では、アプリケーションをミラーリングすると、変更を加えることなく Kubernetes クラスターで実行できます。

Kubernetes は、パスワード、証明書、コンテナ イメージ情報、アプリケーションの起動パラメータなどを含むシークレットや構成などを保存する機能も提供します。このように、Kubernetes はこれらのものを Pod にフレンドリーな方法で注入し、元のアプリケーション コードを書き直したり大幅に変更したりすることなく、全員の作業負荷を軽減します。

ステートフル移行

ステートフル ストレージ シナリオでは、Kubernetes はどのようにしてサービスとストレージの分離を実現するのでしょうか?大規模な分散システムが複数のクラウドベンダーのストレージソリューションを使用すると仮定すると、開発者は基盤となるストレージ技術システムを意識せずに、便利な移植を実現するにはどうすればよいでしょうか。

この目標を達成するために、Kubernetes は PersistentVolumeClaim (PVC) および PersistentVolume (PV) API オブジェクトを導入しました。これらのオブジェクトは、ストレージの実装とストレージの使用を分離します。

PersistentVolumeClaim オブジェクトは、ユーザーが実装に依存しない方法でストレージを要求する手段として機能し、基盤となる PersistentVolume への依存関係の必要性を排除します。これにより、Kubernetes をクラスター間で移植できるようになります。

建築

まず最初に言及すべきことは、Kubernetes が非常に代表的な C/S アーキテクチャを使用しているということです。クライアントは、kubectl コマンドラインまたは RESTful インターフェースを使用して Kubernetes クラスターと対話できます。次の図は、Kubernetes の全体的なアーキテクチャをマクロの観点から示しています。各 Kubernetes クラスターは、マスター ノードと多数のノード ノードで構成されます。

マスター

マスターは Kubernetes クラスターの管理ノードであり、クラスターの管理とクラスター リソース データへのアクセスの提供を担当します。 Etcd ストレージ サービスがあり、API サーバー プロセス、コントローラー マネージャー サービス プロセス、およびスケジューラー サービス プロセスを実行し、作業ノード Node に関連付けられています。

Kubernetes API サーバーは、HTTP REST インターフェースを提供する主要なサービス プロセスです。これは、Kubernetes 内のすべてのリソースを追加、削除、変更、およびクエリするための唯一のエントリ ポイントです。これは、クラスター制御の入力プロセスでもあります。 Kubernetes コントローラー マネージャーは、すべての Kubernetes リソース オブジェクトの自動制御センターであり、クラスターを必要な最終状態に導きます。 Kubernetes Schedule は、Pod のスケジュールを管理するプロセスです。

ノード

Node は、Kubernetes クラスター アーキテクチャで Pod を実行するサービス ノードです。ノードは Kubernetes クラスター操作の単位であり、割り当てられた Pod の操作を実行するために使用され、Pod が実行されるホスト マシンです。名前、IP、システム リソース情報とともにマスター管理ノードに関連付けられます。 Docker Runtime、kubelet、kube-proxy を実行します。

Kubelet は、Pod のコンテナの作成、起動、停止、およびホストの現在のステータスの送信を担当します。 kube-proxy は、Kubernetes Service の通信および負荷分散メカニズムを実装する重要なコンポーネントです。 Docker ランタイムは、ローカル コンテナーの作成と管理を担当します。

実施原則

Kubernetes がどのように動作するかをできるだけ読者に理解してもらうために、ここでは具体的な実装の詳細については触れません。興味のある読者は、公式ウェブサイトのドキュメントを参照してください。ここでは、いくつかの概念と原則を説明するために、単純なアプリケーション展開の例を使用します。

Kubernetes クラスターを作成する

アーキテクチャを紹介する際に、Kubernetes クラスターはマスターとノードで構成されていることがわかります。

マスターは、アプリケーションのスケジュール設定、アプリケーション ステータスの変更、スケーリング、アプリケーションの更新/ダウングレードなど、すべてのクラスター動作を管理します。

ノードは仮想マシンまたは物理マシンになります。これはアプリケーションの「論理ホスト」です。各ノードには Kubelet があり、ノードとマスター間のやり取りを管理する役割を担っています。ノードには、Docker や rkt などのコンテナ操作機能も必要です。理論的には、Kubernetes のデプロイメントでは、実稼働環境のトラフィックを処理するために少なくとも 3 つのノードが必要です。

Kubernetes にアプリケーションをデプロイする必要がある場合は、マスター ノードに通知し、マスターは適切なノード ノードでコンテナを実行するようにスケジュールします。

Minikube を使用して、単一ノードの Kubernetes クラスターをローカルに構築できます。

アプリケーションをデプロイする

Kubernetes クラスターが作成されると、その上でコンテナ化されたアプリケーションを実行できるようになります。アプリケーションの作成方法と更新方法を Kubernetes マスターに指示するデプロイメントを作成する必要があります。

アプリケーション インスタンスが作成されると、デプロイメントはこれらのインスタンスを継続的に監視します。ノード上のポッドに障害が発生した場合、デプロイメントは自動的に新しいインスタンスを作成し、それを置き換えます。従来のスクリプト操作および保守方法と比較すると、この方法はより洗練されています。

kubectl コマンドまたは YAML ファイルを使用してデプロイメントを作成できます。作成時に、アプリケーション イメージと実行するインスタンスの数を指定する必要があり、Kubernetes が自動的に処理します。

ポッドとノードを表示する

以下は Pod と Node の紹介です。

デプロイメントを作成すると、Kubernetes はアプリケーション インスタンスを実行するための Pod を自動的に作成します。 Pod は、「論理ホスト」のような抽象的な概念であり、ストレージ、ネットワーク、同じ内部クラスター IP などのリソースを共有するアプリケーション コンテナーのコレクションを表します。

すべての Pod はノード上で実行する必要があります。ノードは「仮想マシン」であり、仮想マシンまたは物理マシンのいずれかになります。ノードには複数のポッドを含めることができ、Kubernetes はポッドを適切なノードに自動的にスケジュールします。

サービスとラベルセレクター

ポッドは死ぬ運命にあるため、ポッドにも独自のライフサイクルがあります。 Pod が停止すると、ReplicaSet は新しい Pod を作成し、適切なノードにスケジュールします。アクセスの問題を考慮してください。ポッドの交換には IP の変更が伴います。訪問者にとっては、変更された IP は妥当です。 Podノードが複数ある場合、SLBにどのようにアクセスするかも問題になります。サービスはこれらの問題を解決するために設計されています。

サービスは、論理ポッドのセットを定義し、それらにアクセスするためのポリシーを提供する抽象的な概念です。他のオブジェクトと同様に、サービスは kubectl または YAML を介して作成できます。サービスによって定義された Pod は、LabelSelector オプション (以下で説明) に書き込むことができます。 Podが指定されていない場合もあります。これはより複雑なので、興味のある読者は自分で情報を調べることができます。

サービスにはいくつかの種類があります:

• ClusterIP (デフォルト): クラスター内の内部 IP でサービスを公開します。このタイプでは、サービスにクラスター内からのみアクセスできるようになります。
• NodePort: 各ノードの IP と静的ポート (NodePort) を介してサービスを公開します。 NodePort サービスは、自動的に作成される ClusterIP サービスにルーティングされます。 NodePort サービスには、次のリクエストによってクラスターの外部からアクセスできます。
• LoadBalancer: クラウド プロバイダーのロード バランサーを使用してサービスを外部に公開します。外部ロード バランサは NodePort サービスと ClusterIP サービスにルーティングできます。
• ExternalName: CNAMEとその値を返す（外部DNSシナリオに適用可能）

ラベルとセレクターにより、Kubernetes は SQL に似た論理操作を実行できるようになります。たとえば、app=hello_word を含むすべてのオブジェクトを検索したり、(a,b,c) abc 内の app を含むすべてのオブジェクトを検索したりできます。

ラベルはオブジェクトにバインドされた K/V 構造です。作成時または後で定義でき、いつでも変更できます。

容量拡張アプリケーション

前述したように、デプロイメントを使用してインスタンスの数を増やすことができます。次の図は、元のクラスターの状態を示しています。

レプリカ（インスタンス数）を自由に変更して容量を拡張できます。デプロイメントのレプリカ値を変更すると、Kubernetesは以下に示すように、必要なインスタンス数に自動的に到達するのに役立ちます。

アプリを更新する

アプリケーションの更新は容量の拡張に似ています。デプロイメントでコンテナ イメージを変更すると、Kubernetes がアプリケーションの更新 (ブルーグリーン、カナリアなど) を支援します。この機能により、アプリケーション環境の切り替えやロールバック、ダウンタイムなしでの CI/CD の実装も可能になります。以下は展開プロセスです。新しく作成される Pod の最大数と使用できない Pod の最大数を指定できることに注意してください。

要約する

結局のところ、Kubernetes について大まかな理解はできているはずですが、Kubernetes にはこの記事で説明されているもの以外にも多くの機能があります。クラウド ネイティブの概念がますます明確になるにつれて、CNCF における現実的なプロジェクトとしての Kubernetes の重要性は明らかです。