超シンプルなKubernetes

Kubernetesでプロジェクトを開始するために必要なものすべて

マイクロサービス、クラウドコンピューティング、サーバーレスアーキテクチャの時代において、Kubernetes を理解し、その使用方法を学ぶことは非常に役立ちます。ただし、Kubernetes の公式ドキュメントは、特に初心者にとっては解読が難しい場合があります。次の一連の記事では、Kubernetes を簡略化して説明し、Azure、Amazon、Google Cloud、さらには IBM などのさまざまなクラウドプロバイダーを通じてマイクロサービスをデプロイするために Kubernetes を使用する方法の例を示します。

このシリーズの最初の記事では、Kubernetes で使用される最も重要な概念について説明します。次の記事では、構成ファイルの記述方法、Helm をパッケージマネージャーとして使用する方法、クラウドインフラストラクチャを作成する方法、Kubernetes を使用してサービスを簡単にオーケストレーションする方法について学習します。前回の記事では、ワークフロー全体を自動化するための CI/CD パイプラインを作成します。この情報があれば、あらゆるタイプのプロジェクトを開始し、堅牢なインフラストラクチャ/アーキテクチャを構築できるようになります。

始める前に、コンテナを使用すると、展開速度の向上からより高いレベルでの配信の一貫性まで、多くの利点があることを述べておきます。それでも、アプリケーションの一部だけをコンテナに入れると、コンテナオーケストレーションレイヤーの維持などのオーバーヘッドが発生するため、すべての用途にコンテナを使用するべきではありません。したがって、結論を急がず、代わりにプロジェクトの開始時にコスト/利益分析を作成してください。

Kubernetes の世界への旅を始めましょう!

ハードウェア

ノード

ノードは Kubernetes における最小の作業単位であり、CPU と RAM メモリを備えた任意のデバイスになります。たとえば、ノードはスマートウォッチ、スマートフォン、ラップトップ、さらには Raspberry Pi など何でもかまいません。クラウドプロバイダーと連携する場合、ノードは仮想マシンになります。したがって、ノードは単一のデバイスを抽象化したものです。

次の記事でわかるように、この抽象化の優れた点は、基盤となるハードウェア構造について知る必要がなく、ノードを使用するだけで済むため、インフラストラクチャがプラットフォームに依存しないことです。

> ノード

クラスタ

クラスターはノードのグループです。プログラムをクラスターにデプロイすると、個々のノードへの作業の分散が自動的に処理されます。より多くのリソースが必要な場合 (たとえば、より多くのメモリが必要な場合)、新しいノードをクラスターに追加して、作業を自動的に再分配することができます。

どのノードを気にすることなくクラスター上でコードを実行し、作業の分散は自動的に行われます。

> クラスター

永続ボリューム

コードはノード間で再配置される可能性があるため (たとえば、あるノードに十分なメモリがないため、十分なメモリを持つ別のノードに作業が再スケジュールされる)、ノードに保存されるデータは揮発性です。しかし、場合によってはデータを永続的に保存したいこともあります。この場合は永続ボリュームを使用する必要があります。永続ボリュームは、接続してデータを保存できる外付けハードドライブのようなものです。

Kubernetes はもともと、永続的なデータが別の場所に保存されるステートレスアプリケーションプラットフォームとして開発されました。プロジェクトが成熟するにつれて、多くの組織がステートフルアプリケーションにもこれを使いたいと考えるようになり、永続ボリューム管理が追加されました。仮想化の初期の頃と同様に、データベースサーバーは通常、この新しいアーキテクチャに移行される最初のサーバーではありません。その理由は、データベースは多くのアプリケーションの中核であり、貴重な情報が含まれている可能性があるため、ローカルデータベースシステムは依然として主に VM または物理サーバー上で実行されているからです。

では、永続ボリュームはいつ使用すべきでしょうか?この質問に答えるには、まずデータベースアプリケーションのさまざまな種類を理解する必要があります。

データ管理ソリューションは、次の 2 つのカテゴリに分けられます。

垂直に拡張可能 - MySQL、PostgreSQL、SQL Server などの従来の RDMS ソリューションを含む
水平方向に拡張可能 - ElasticSearchやHadoopベースのソリューションなどの「NoSQL」ソリューションを含む

垂直にスケーラブルなソリューション (MySQL、Postgres、Microsoft SQL など) は、コンテナーに配置しないでください。これらのデータベースプラットフォームでは、高い I/O、共有ディスク、ブロックストレージなどが必要であり、コンテナーベースのエコシステムでよく発生するクラスター内のノードの損失を適切に処理するようには設計されていません。

水平方向にスケーラブルなアプリケーション (Elastic、Cassandra、Kafka など) の場合、コンテナはデータベースクラスター内のノードの損失に耐えることができ、データベースアプリケーションを独立して再バランス調整できるため、コンテナを使用する必要があります。

一般的に、冗長ストレージ技術を使用し、データベースクラスター内のノードが失われても存続できる分散データベースをコンテナー化できますし、コンテナー化する必要があります (ElasticSearch は良い例です)。

ソフトウェア

容器

現代のソフトウェア開発の目標の 1 つは、同じホストまたはクラスター上でアプリケーションを相互に分離することです。仮想マシンはこの問題を解決する 1 つの方法です。しかし、仮想マシンには独自のオペレーティングシステムが必要なので、通常はギガバイト単位のサイズになります。

対照的に、コンテナはアプリケーション実行環境を相互に分離しますが、基盤となるオペレーティングシステムカーネルを共有します。つまり、コンテナは、コード、ランタイム、システムツール、システムライブラリ、設定など、アプリケーションを実行するために必要なすべてのものを保存するボックスのようなものです。コンテナは通常メガバイト単位で測定され、VM よりもはるかに少ないリソースを使用し、ほぼ瞬時に起動します。

ポッド

ポッドはコンテナのグループです。 Kubernetes では、作業の最小単位はポッドです。 Pod には複数のコンテナを含めることができますが、Kubernetes でのレプリケーションの単位は Pod であるため、通常は Pod ごとに 1 つのコンテナが使用されます。したがって、各コンテナを個別にスケーリングしたい場合は、コンテナ内にコンテナを追加できます。

展開

Deployment の主な役割は、Pod と ReplicaSets (同じ Pod の複数のコピーのコレクション) に対して宣言的な更新を提供することです。デプロイメントを使用すると、同じポッドのコピーを同時にいくつ実行できるかを指定できます。デプロイメントはポッドのマネージャーのようなもので、要求されたポッドの数を自動的に増やし、ポッドを監視し、障害が発生した場合にポッドを再作成します。各ポッドを個別に作成して管理する必要がないため、デプロイメントは役立ちます。

デプロイメントは通常、ステートレスアプリケーションに使用されます。ただし、永続ボリュームをデプロイメントボリュームに接続してステートフルにすることで、デプロイメントの状態を保存できます。

ステートフルセット

StatefulSet は Kubernetes の新しい概念であり、ステートフルアプリケーションを管理するためのリソースです。一連の Pod のデプロイメントとスケーリングを管理し、それらの Pod の順序と一意性に関する保証を提供します。これは Deployment に似ていますが、唯一の違いは、Deployment ではランダムな Pod 名を持つ Pod のセットが作成され、Pod の順序は重要ではないのに対し、StatefulSet では一意の命名規則と順序で Pod が作成される点です。したがって、example という名前の Pod のレプリカを 3 つ作成する場合、StatefulSet は example-0、example-1、example-2 という名前で Pod を作成します。この場合の最も重要な利点は、ペインの名前に頼ることができることです。

デーモンセット

DaemonSet は、Pod がクラスターのすべてのノードで実行されることを保証します。 DaemonSet は、クラスターにノードが追加または削除されると、コンテナーを自動的に追加または削除します。これは、クラスターの監視を手動で管理することなく、各ノードを常に監視できるようにするため、監視とログ記録に役立ちます。

サービス

Deployment は一連の Pod を実行し続ける役割を担い、Service は一連の Pod へのネットワークアクセスを有効にする役割を担います。サービスは、負荷分散、アプリケーション間のサービス検出、ゼロダウンタイムのアプリケーション展開をサポートする機能など、クラスター全体で標準化された重要な機能を提供します。各サービスには一意の IP アドレスと DNS ホスト名があります。サービスを使用するアプリケーションは、IP アドレスまたはホスト名のいずれかを使用するように手動で構成でき、トラフィックは適切なポッドに負荷分散されます。外部トラフィックのセクションでは、サービスタイプと、それらを使用して内部サービス間および外部の世界と通信する方法について詳しく説明します。

構成マップ

ステージ、開発、本番などの複数の環境にデプロイする場合、環境の違いにより、構成をアプリケーションに組み込むのは好ましくない方法です。理想的には、展開環境に合わせて構成を分離する必要があります。ここで ConfigMap が役立ちます。 ConfigMap を使用すると、構成アーティファクトをイメージコンテンツから分離して、コンテナー化されたアプリケーションを移植可能にすることができます。

外部トラフィック

クラスター内ですべてのサービスが実行されていますが、ここで問題になるのは、外部トラフィックをクラスターにどうやって取り込むかということです。外部トラフィックを処理するために使用できるサービスには、ClusterIP、NodePort、LoadBalancer の 3 種類があります。 4 番目の解決策は、イングレスコントローラーと呼ばれる別の抽象化レイヤーを追加することです。

クラスターIP

これは Kubernetes のデフォルトのサービスタイプであり、クラスター内の他のサービスと通信できるようになります。これは外部からのアクセスを目的としたものではありませんが、プロキシを使用したちょっとしたトリックにより、外部トラフィックが当社のサービスに影響を与える可能性があります。このソリューションは本番環境では使用せず、デバッグのみに使用してください。 ClusterIP として宣言されたサービスは、外部から直接表示することはできません。

ノードポート

この記事の最初の部分で説明したように、ポッドはノード上で実行されます。ノードは、ラップトップや仮想マシン (クラウドで作業している場合) などのさまざまなデバイスになります。各ノードには固定 IP アドレスがあります。サービスを NodePort として宣言すると、サービスはノードの IP アドレスを公開し、外部からアクセスできるようになります。これを本番環境で使用しても問題ありませんが、大規模なアプリケーション（多数のサービスがある）の場合、さまざまな IP アドレスをすべて手動で管理するのは面倒な場合があります。

ロードバランサー

LoadBalancer タイプのサービスを宣言すると、クラウドプロバイダーのロードバランサーを使用して外部に公開されます。この外部ロードバランサからのトラフィックがサービスポッドにルーティングされる方法は、クラスタープロバイダーによって異なります。これは非常に優れたソリューションであり、クラスター内の各ノードのすべての IP アドレスを管理する必要はなく、サービスごとにロードバランサーが 1 つだけあります。欠点は、サービスごとに個別のロードバランサーが必要になり、ロードバランサーインスタンスごとに料金が発生することです。

このソリューションは生産には非常に優れていますが、少々高価になる可能性があります。それでは、より安価な解決策を見てみましょう。

イングレス

Ingress はサービスではなく、クラスター内のサービスへの外部アクセスを管理する API オブジェクトです。これは、リバースプロキシおよびクラスターへの単一のエントリポイントとして機能し、リクエストを他のサービスにルーティングします。私は通常、SSL としても機能しながらリバースプロキシの役割を果たす NGINX Ingress Controller を使用します。イングレスを公開するには、ロードバランサーを使用するのが本番環境に最適なソリューションです。

このソリューションを使用すると、単一のロードバランサーを使用して任意の数のサービスを公開し、料金を可能な限り低く抑えることができます。