Kubernetes の概念

Amazon Elastic Kubernetes Service (Amazon EKS) は、オープンソースの Kubernetes プロジェクトをベースとした AWS マネージドサービスです。Amazon EKS サービスが AWS クラウドとどのように統合するのかについて (特に Amazon EKS クラスターを初めて作成する場合は)、理解しておくべき点がいくつかありますが、Amazon EKS クラスターを一度起動して実行した後の使用方法は、他の Kubernetes クラスターを使う場合とほとんど同じです。そのため、Kubernetes クラスターの管理とワークロードのデプロイを開始するには、少なくとも Kubernetes の概念の基本について理解しておく必要があります。

このページでは、Kubernetes 概念を Kubernetes を利用する理由、クラスター、ワークロード の 3 つのセクションに分けます。1 つめのセクションでは、Kubernetes のサービス、特に Amazon EKS のようなマネージドサービスとしてこれを実行する場合の利点について説明します。ワークロードのセクションでは、Kubernetes アプリケーションの構築、保存、実行、管理の方法について説明します。クラスターのセクションでは、Kubernetes クラスターを構成しているさまざまなコンポーネントと、Kubernetes クラスターを作成して管理するときのユーザーの責任について説明します。

このコンテンツに含まれているリンクをクリックすると、Amazon EKS と Kubernetes の両方のドキュメントに記載されている Kubernetes の概念について解説したページが開き、ここで取り上げたトピックをさらに深く掘り下げることができます。Amazon EKS がどのように Kubernetes コントロールプレーンとコンピューティング機能を実装するかの詳細については、「Amazon EKS アーキテクチャ」を参照してください。

Kubernetes を利用する理由

Kubernetes は、ミッションクリティカルで本番稼働品質のコンテナ化アプリケーションを実行するときの可用性とスケーラビリティを向上させることを目的に設計されました。1 台のマシン上で Kubernetes を実行するのではなく (実行可能ではありますが)、需要に応じて拡張または縮小する複数のコンピュータを横断してアプリケーションを実行できるようにすれば、Kubernetes は上記の目標を達成できます。Kubernetes には、以下を簡単に行えるようにする機能があります。

• アプリケーションを複数のマシンにデプロイする (ポッドにデプロイされたコンテナを使用)

• コンテナの状態をモニタリングし、障害が発生したコンテナを再起動する

• 負荷に基づいてコンテナをスケールアップ/スケールダウンする

• コンテナを新しいバージョンで更新する

• コンテナ間でリソースを割り当てる

• マシン間でトラフィックを分散する

Kubernetes でこのタイプの複雑なタスクを自動化すれば、アプリケーションデベロッパーは、インフラストラクチャのことを心配せずに、アプリケーションワークロードの構築と改善に専念できます。デベロッパーは通常、YAML 形式の設定ファイルを作成し、そこにアプリケーションの望ましい状態を記述します。これには、実行するコンテナ、リソースの上限、ポッドレプリカの数、CPU/メモリの割り当て、アフィニティールールなどが含まれます。

Kubernetes の属性

上記の目標を達成するため、Kubernetes は次の属性を使用します。

• コンテナ化 - Kubernetes はコンテナオーケストレーションツールです。Kubernetes を使用するには、最初にアプリケーションをコンテナ化する必要があります。アプリケーションの種類に応じて、これはマイクロサービスのセット、バッチジョブ、その他形式のいずれかになります。それにより、アプリケーションで、ツールの巨大なエコシステムを含む Kubernetes ワークフローを利用することができます。そこでは、コンテナをイメージとしてコンテナレジストリに保存したり、Kubernetes クラスターにデプロイしたり、利用可能なノード上で実行したりすることができます。個々のコンテナを Kubernetes クラスターにデプロイする前に、Docker または別のコンテナランタイムを使ってローカルのコンピュータ上で構築しテストすることができます。

• スケーラブル - アプリケーションの需要が、それらのアプリケーションを実行しているインスタンスのキャパシティを超える場合、Kubernetes をスケールアップできます。必要に応じて、Kubernetes は、アプリケーションに追加の CPU やメモリが必要かどうかを判断し、自動的に利用可能な容量を拡張するか、既存の容量を追加で利用します。アプリケーションでより多くのインスタンスを実行するための十分なコンピューティングがある場合は、ポッドレベルでスケーリングを実行することができます (水平ポッド自動スケーリング)。あるいは、容量の増加に対応するためにより多くのノードを起動する必要がある場合は、ノードレベルでスケーリングを実行することができます (Cluster Autoscaler または Karpenter)。容量が不要になると、これらのサービスは不要なポッドを削除して、不要なノードをシャットダウンすることができます。

• 使用可能 - アプリケーションまたはノードが異常な状態になったり使用できなくなったりすると、Kubernetes で実行中のワークロードを、使用可能な別のノードに移動できます。この問題は、ワークロードを実行しているワークロードまたはノードの実行中のインスタンスを削除すれば、強制的に解決できます。ここでのポイントは、ワークロードを現在の場所で実行できなくなったときは、他の場所で起動できるという点です。

• 宣言型 - Kubernetes はアクティブな照合を使用して、クラスターに宣言した状態が、実際の状態と一致していることを常にチェックします。Kubernetes オブジェクトをクラスターに適用すると、通常は YAML 形式の設定ファイルを通じて、例えばクラスター上で実行するワークロードの起動をリクエストすることができます。設定は後で変更可能で、新しいバージョンのコンテナを使用したり、メモリをさらに割り当てたりすることができます。Kubernetes は、望ましい状態にするために必要なことを実行します。例えば、ノードの起動や停止、ワークロードの停止および再起動、更新したコンテナの取得などを実行します。

• コンポーザブル - アプリケーションは通常、複数のコンポーネントで構成されているため、これら一連のコンポーネント (通常は複数のコンテナで表されます) をまとめて管理できるようにしておくことをお勧めします。Docker Compose では Docker を使ってこれを直接実行できますが、Kubernetes では Kubernetes Kompose コマンドを使って実行できます。その方法の例については、「Translate a Compose File to Kubernetes Resources」を参照してください。

• 拡張可能 - 独自のソフトウェアとは異なり、オープンソースの Kubernetes プロジェクトは、ニーズに合わせて Kubernetes を自由に拡張できるように設計されています。API と設定ファイルは、直接変更することができます。サードパーティーがインフラストラクチャとエンドユーザー Kubernetes 機能の両方を拡張するときは、独自の Controller を作成することが推奨されます。Webhook を使用すると、クラスタールを設定して、ポリシーを適用し、状況の変化に対応することができます。Kubernetes クラスターを拡張する方法の詳細については、「Kubernetes を拡張する」を参照してください。

• ポータブル - 多くの組織では、アプリケーションのニーズをすべて同じ方法で管理できることから、自社での Kubernetes の運用を標準化しています。デベロッパーは、コンテナ化されたアプリケーションを同じパイプラインを使って構築し、保存することができます。これらのアプリケーションは、オンプレミス、クラウド上、レストランの POS 端末、企業のリモートサイトに分散されている IOT デバイスなどで実行している Kubernetes クラスターにデプロイできます。オープンソースであるため、このような特殊な Kubernetes ディストリビューションを、その管理に必要なツールと併せて開発することが可能です。

Kubernetes の管理

Kubernetes ソースコードは無料で入手できるため、Kubernetes を自分の機器を使ってインストールし、管理することができます。ただし、セルフマネージド型の Kubernetes には運用に関する専門知識が必要であり、維持していくには時間と労力がかかります。そのため、本番環境のワークロードをデプロイする人の大半が、独自のテスト済み Kubernetes ディストリビューションと、Kubernetes の専門家のサポートを備えた、クラウドプロバイダー (Amazon EKS など) またはオンプレミスプロバイダー (Amazon EKS Anywhere など) を利用しています。これらを利用することで、以下のようなクラスターのメンテナンスに必要な未分化で手間のかかる作業の多くを軽減しています。

• ハードウェア - 要件に応じて Kubernetes を実行できるハードウェアがない場合、AWS Amazon EKS などのクラウドプロバイダーを利用すると初期費用を節約できます。Amazon EKS では、コンピュータインスタンス (Amazon Elastic Compute Cloud)、独自のプライベート環境 (Amazon VPC)、一元的なアイデンティティと権限管理 (IAM)、ストレージ (Amazon EBS) など、AWS で提供されている最善のクラウドリソースを利用できます。AWS は、コンピュータ、ネットワーク、データセンター、および、Kubernetes の実行に必要なその他すべての物理コンポーネントを管理します。同様に、需要が最も高い日に最大容量を処理できるようにデータセンターを計画しておく必要はありません。Amazon EKS Anywhere やその他のオンプレミスの Kubernetes クラスターの場合、Kubernetes デプロイに使用されるインフラストラクチャの管理はお客様の責任となりますが、引き続き AWS を使って Kubernetes を最新の状態に保つことができます。

• コントロールプレーン管理 - Amazon EKS は、AWS がホストしている Kubernetes コントロールプレーンのセキュリティと可用性を管理します。コンテナのスケジュール設定、アプリケーションの可用性の管理、その他の重要なタスクはこのコントロールプレーンが行うため、ユーザーはアプリケーションのワークロードに専念できます。クラスターが故障した場合、AWS には、実行状態に復元するための方法がいくつかあります。Amazon EKS Anywhere の場合、コントロールプレーンを自分で管理することになります。

• テスト済みのアップグレード - クラスターをアップグレードするときは、Amazon EKS または Amazon EKS Anywhere を使って、Kubernetes ディストリビューションのテスト済みバージョンを用意できます。

• アドオン - 拡張して Kubernetes と連携するように構築された数百ものプロジェクトがあり、クラスターのインフラストラクチャに追加したり、ワークロードの実行を支援するために使用したりできます。これらのアドオンを自分で構築して管理する代わりに、AWS には、クラスターで使用できる Amazon EKS アドオンAmazon EKS アドオンが用意されています。Amazon EKS Anywhere には、多くの一般的なオープンソースプロジェクトのビルドを含む、キュレーションパッケージがあります。そのため、ユーザーは、ソフトウェアを自分で構築したり、重要なセキュリティパッチ、バグ修正、アップグレードを管理したりする必要はありません。同様に、デフォルトの設定がニーズを満たしていれば、通常、それらのアドオンの設定はほとんど必要ありません。アドオンを使用してクラスターを拡張する方法については、「拡張クラスター」を参照してください。

実行中の Kubernetes

以下の図は、Kubernetes 管理者またはアプリケーションデベロッパーが Kubernetes クラスターを作成して使用する際に実行する主要なアクティビティを示したものです。そのプロセスにおいて、基盤となるクラウドプロバイダーの例として AWS クラウドを使用し、Kubernetes のコンポーネントがどのように相互作用するかを説明しています。

Kubernetes 管理者は、クラスターが構築されるプロバイダーのタイプに固有のツールを使用して、Kubernetes クラスターを作成します。この例では、Amazon EKS という マネージドの Kubernetes サービスを提供する AWS クラウドをプロバイダーとして使用します。このマネージドサービスは、クラスターの作成に必要なリソースを自動的に割り当てます。これには、クラスター用の 2 つの新しい Virtual Private Cloud (Amazon VPC) の作成、ネットワークのセットアップ、クラウド内のアセットを管理するための Kubernetes アクセス許可のマッピング、コントロールプレーンサービスを実行する場所があることの確認、ワークロードを実行する Kubernetes ノードとしての 0 個以上の Amazon EC2 インスタンスの割り当てなどが含まれます。AWS は、コントロールプレーン用に Amazon VPC 自体を 1 つ管理し、もう 1 つの Amazon VPC には、ワークロードを実行するカスタマーノードが含まれます。

Kubernetes 管理者が今後行うタスクの多くは、kubectl などの Kubernetes ツールを使って行われます。このツールは、クラスターのコントロールプレーンに直接サービスをリクエストします。その場合、クラスターに対してクエリや変更を行う方法は、任意の Kubernetes クラスターに対して行う場合の方法と非常によく似ています。

このクラスターにワークロードをデプロイする場合、アプリケーションデベロッパーは、いくつかのタスクを実行することができます。デベロッパーは、アプリケーションを 1 つ以上のコンテナイメージに構築し、そのイメージを、Kubernetes クラスターにアクセスできるコンテナレジストリにプッシュする必要があります。AWS には、それを行うための Amazon Elastic Container Registry (Amazon ECR) というレジストリがあります。

このアプリケーションを実行するには、デベロッパーは、レジストリからどのコンテナを取得するか、それらのコンテナをポッドにどのようにラップするかなど、アプリケーションの実行方法をクラスターに指示する YAML 形式の設定ファイルを作成します。コントロールプレーン (スケジューラー) は、コンテナを 1 つ以上のノードにスケジュールし、各ノードのコンテナランタイムが必要なコンテナーを実際にプルして実行します。また、デベロッパーは Application Load Balancer を設定することで、各ノードで実行されている利用可能なコンテナにトラフィックを分散し、パブリックネットワーク上で外部から利用できるようにアプリケーションを公開することもできます。これで、アプリケーションを使用したいユーザーが、アプリケーションエンドポイントに接続してアクセスできるようになります。

以下のセクションでは、これらの各機能について、Kubernetes のクラスターとワークロードの観点から詳しく説明します。

クラスター

ジョブに Kubernetes クラスターの起動および管理が含まれる場合は、Kubernetes クラスターの作成、強化、管理、削除の方法を理解しておく必要があります。また、クラスターを構成しているコンポーネントと、それらのコンポーネントを維持するために行うべきことについても、知っておく必要があります。

クラスターを管理するツールは、Kubernetes のサービスと基盤となるハードウェアプロバイダーとの重複を処理します。そのため、これらのタスクの自動化は、Kubernetes プロバイダー (Amazon EKS や Amazon EKS Anywhere など) が、そのプロバイダーに固有のツールを使って行うのが一般的です。例えば、Amazon EKS クラスターを起動する場合は eksctl create cluster を使用できますが、Amazon EKS Anywhere には eksctl anywhere create cluster を使用できます。これらのコマンドは Kubernetes クラスターを作成しますが、プロバイダー固有のものであるため、Kubernetes プロジェクト自体には含まれていないことに注意してください。

クラスターの作成および管理ツール

Kubernetes プロジェクトには、Kubernetes クラスターを手動で作成するためのツールが用意されています。したがって、Kubernetes を単一のマシンにインストールしたり、マシン上でコントロールプレーンを実行したり、ノードを手動で追加したりする場合は、「Kubernetes Install Tools」に一覧表示されている kind、minikube、kubeadm などの CLI ツールを使用できます。クラスターの作成と管理のライフサイクル全体を簡素化して自動化するには、Amazon EKS や Amazon EKS Anywhere など、定評のある Kubernetes プロバイダーがサポートしているツールを使用するとはるかに簡単になります。

AWS クラウドでは、Amazon EKS クラスターを、eksctl などの CLI ツールや、Terraform などのより宣言的なツールを使用して作成することができます (「Amazon EKS Blueprints for Terraform」を参照)。クラスターは、AWS Management Console を使用して作成することもできます。Amazon EKS で利用できる機能の一覧は「Amazon EKS の機能」を参照してください。Amazon EKS がお客様に代わって引き受ける Kubernetes の責任には、以下が含まれます。

• マネージドコントロールプレーン - AWS は、コントロールプレーンをユーザーに代わって管理し、AWS アベイラビリティーゾーン全体で利用可能にするため、Amazon EKS クラスターが利用可能かつスケーラブルになります。

• ノード管理 - ノードを手動で追加する代わりに、マネージドノードグループを使用してノードライフサイクルを簡素化するマネージドノードグループまたは Karpenter を使用して、必要に応じて Amazon EKS でノードを自動的に作成できます。マネージドノードグループは、Kubernetes クラスター自動スケーリングと統合されています。ノード管理ツールを使用すると、スポットインスタンスやノード統合などによりコストを節約したり、ワークロードのデプロイ方法やノードの選択方法を設定するスケジューリング機能を使って、可用性を活用することができます。

• クラスターネットワーク - eksctl は、CloudFormation テンプレートを使用して、Kubernetes クラスター内のコントロールプレーンとデータプレーン (ノード) コンポーネント間に、ネットワークを設定します。また、内部と外部の通信を行うためのエンドポイントも設定します。詳細については、「De-mystifying cluster networking for Amazon EKS worker nodes」を参照してください。Amazon EKS 内のポッド間の通信は、EKS Pod Identity がポッドに AWS サービスへのアクセス権を付与する方法を学ぶAmazon EKS Pod Identity を使用して行われます。これによりポッドは、認証情報やアクセス許可を管理する AWS クラウドの方法を利用できるようになります。

• アドオン - Amazon EKS を使用すると、Kubernetes クラスターをサポートするために一般的に使用される、ソフトウェアコンポーネントを構築して追加する必要がなくなります。例えば、AWS マネジメントコンソールから Amazon EKS クラスターを作成すると、Amazon EKS Amazon EKS クラスターで kube-proxy を管理するkube-proxy、Kubernetes 用の Amazon VPC CNIAmazon VPC CNI プラグイン、Amazon EKS クラスターで DNS の CoreDNS を管理するCoreDNS アドオンが、自動的に追加されます。利用可能なアドオンも含む、これらのアドオンの詳細については、「Amazon EKS アドオン」を参照してください。

クラスターをオンプレミスのコンピュータとネットワーク上で実行できるように、Amazon は Amazon EKS Anywhere を提供しています。AWS クラウドをプロバイダーにする代わりに、Amazon EKS Anywhere を VMware vSphere、ベアメタル (Tinkerbell プロバイダー)、Snow、CloudStack、Nutanix の各プラットフォームで、独自の機器を使用して実行することを選択できます。

Amazon EKS Anywhere は、Amazon EKS で使用されているものと同じ Amazon EKS Distro ソフトウェアをベースにしています。ただし、Amazon EKS Anywhere は、Amazon EKS Anywhere クラスター内のマシンのライフサイクル全体を管理するために、Kubernetes クラスター API (CAPI) インターフェイスのさまざまな実装に依存しています (vSphere の場合は CAPV、CloudStack の場合は CAPC など)。クラスター全体がユーザーの機器上で実行されるため、ユーザーは、コントロールプレーンの管理とデータのバックアップの責任を追加で負うことになります (本ドキュメントで後述する etcd を参照)。

クラスターコンポーネント

Kubernetes クラスターコンポーネントは、コントロールプレーンとワーカーノードという 2 つの主要な領域に分かれています。コントロールプレーンコンポーネントはクラスターを管理し、その API へのアクセスを提供します。ワーカーノード (単にノードとも呼ばれます) は、実際のワークロードを実行する場所です。ノードコンポーネントは、各ノード上で実行されるサービスで構成され、コントロールプレーンと通信してコンテナを実行します。クラスターのワーカーノードのセットは、データプレーンと呼ばれます。

コントロールプレーン

コントロールプレーンは、クラスターを管理する一連のサービスで構成されています。これらのサービスはすべて 1 台のコンピュータで実行される場合もあれば、複数のコンピュータに分散される場合もあります。内部的には、これらはコントロールプレーンインスタンス (CPI) と呼ばれます。CPI の実行方法は、クラスターの規模と、高可用性の要件に応じて異なります。クラスターの需要が増えると、コントロールプレーンサービスはスケールしてそのサービスのインスタンスを増やし、リクエストはインスタンス間で負荷分散されます。

Kubernetes コントロールプレーンのコンポーネントが実行するタスクには、以下が含まれます。

• クラスターコンポーネント (API サーバー) との通信 (API サーバー) - API サーバー (kube-apiserver) は、クラスターへのリクエストをクラスターの内部と外部の両方から行えるようにするために Kubernetes API を公開します。つまり、クラスターのオブジェクト (ポッド、サービス、ノードなど) を追加または変更するリクエストは、ポッドを実行する kubectl のリクエストなどの外部コマンドから送信することができます。同様に、ポッドのステータスを kubelet サービスにクエリするときのように、API サーバーからクラスター内のコンポーネントに対してリクエストを実行することができます。

• クラスターに関するデータの保存 (*etcd キーバリューストア)* - etcd サービスは、クラスターの現在の状態を追跡するという重要な役割を担っています。etcd サービスにアクセスできなくなると、ワークロードはしばらく実行し続けますが、クラスターの状態を更新したりクエリしたりすることはできなくなります。そのため、重要なクラスターは通常、複数の負荷分散された etcd サービスのインスタンスを同時に実行し、データの損失や破損に備えて、etcd キーバリューストアのバックアップを定期的に行っています。Amazon EKS では、これはすべてデフォルトで自動的に処理されます。Amazon EKS Anywhere は、etcd のバックアップと復元の手順を公開しています。「etcd`https://etcd.io/docs/v3.5/learning/data_model/[Data Model] to learn how `etcd がデータを管理する」を参照してください。

• ノードへのポッドのスケジュール (スケジューラー) - Kubernetes での、ポッドの起動または停止のリクエストは、Kubernetes スケジューラー (kube-scheduler) に送信されます。クラスターにはポッドを実行できるノードが複数含まれている場合があるため、どのノード (レプリカの場合は複数のノード) でポッドを実行するかは、スケジューラーが決定します。リクエストされたポッドを既存のノードで実行するための十分な容量がない場合、他のポッドをプロビジョニングしていなければそのリクエストは失敗します。プロビジョニングには、新しいノードを自動的に起動してワークロードを処理するマネージドノードグループを使用してノードライフサイクルを簡素化するマネージド型ノードグループや Karpenter などのサービスを有効化する作業が含まれます。

• コンポーネントを目的の状態に維持する (コントローラーマネージャー) - Kubernetes コントローラーマネージャーは、クラスターの状態をモニタリングしたり、クラスターに変更を加えて期待される状態に戻したりするデーモンプロセス (kube-controller-manager) として実行されます。特に、statefulset-controller、endpoint-controller、cronjob-controller、node-controller など、さまざまな Kubernetes オブジェクトを監視するいくつかのコントローラーがあります。

• クラウドリソースの管理 (Cloud Controller Manager) - Kubernetes と、基盤となるデータセンターリソースのリクエストを実行するクラウドプロバイダーとのやり取りは、Cloud Controller Manager(cloud-controller-manager) が処理します。Cloud Controller Manager が管理するコントローラーには、ルートコントローラー (クラウドネットワークルートの設定用)、サービスコントローラー (クラウドのロードバランシングサービスを使用するためのもの)、ノードライフサイクルコントローラー (クラウド API を使用してライフサイクル全体でノードを Kubernetes と同期させるためのもの) があります。

ワーカーノード (データプレーン)

単一ノード Kubernetes クラスターの場合、ワークロードはコントロールプレーンと同じマシンで実行します。ただし、より標準的な構成では、Kubernetes ワークロードを実行するための専用の個別のコンピュータシステム (ノード) を 1 つ以上用意します。

Kubernetes クラスターを初めて作成する場合、作成ツールによっては、(既存のコンピュータシステムを識別するか、プロバイダーに新しいコンピュータシステムを作成させることによって) 特定の数のノードをクラスターに追加するように設定できるものがあります。これらのシステムにワークロードを追加する前に、以下の機能を実装するためのサービスを各ノードに追加します。

• 各ノードの管理 (*kubelet)* - API サーバーは、各ノードで実行されている kubelet サービスと通信し、ノードが正しく登録され、スケジューラーからリクエストされたポッドが実行されていることを確認します。kubelet は、ポッドマニフェストを読み取り、ローカルシステム上で Pod が必要とするストレージボリュームやその他の機能を設定できます。また、ローカルで実行されているコンテナの状態もチェックすることができます。

• ノードでコンテナを実行する (コンテナランタイム) - 各ノードのコンテナランタイムは、ノードに割り当てられた各ポッドに対してリクエストされたコンテナを管理します。つまり、適切なレジストリからコンテナイメージをプルし、そのコンテナを実行して停止し、コンテナに関するクエリに応答することができます。デフォルトのコンテナランタイムは containerd です。Kubernetes 1.24 以降、コンテナランタイムとして使用できる Docker (dockershim) の特別な統合は、Kubernetes から削除されました。ローカルシステム上でコンテナをテストおよび実行する際は、引き続き Docker を使用することができますが、Kubernetes で Docker を使用するには、各ノードに Docker Engine をインストールして Kubernetes で使用する必要があります。

• コンテナ間のネットワークを管理する (kube-proxy) - ポッド間の通信をサポートできるようにするために、Kubernetes はサービスと呼ばれる機能を使用して、それらのポッドに関連付けられた IP アドレスとポートを追跡するポッドネットワークを設定します。kube-proxy サービスは、各ノードで実行し、ポッド間でその通信を可能にします。

拡張クラスター

クラスターをサポートするために Kubernetes に追加できるサービスがいくつかありますが、それらはコントロールプレーンでは実行されません。それらのサービスは、多くの場合、kube-system 名前空間のノードで直接実行されるか、独自の名前空間で実行されます (サードパーティーのサービスプロバイダーではよく行われています)。一般的な例が、クラスターに DNS サービスを提供する CoreDNS サービスです。クラスターの kube-system でどのクラスターサービスが実行されているのかを確認する方法については、「Discovering builtin services」を参照してください。

クラスターに追加できるアドオンには、さまざまな種類があります。クラスターを健全な状態に保つには、ログ記録、監査、メトリクスなどの作業を実行できる、クラスターのパフォーマンスをモニタリングし、ログを表示するオブザーバビリティ機能を追加します。この情報があれば、多くの場合、同じオブザーバビリティインターフェイスを使用して、発生した問題をトラブルシューティングすることができます。こうしたタイプのサービスには、Amazon GuardDuty、Amazon CloudWatch でクラスターデータをモニタリングするCloudWatch、AWS Distro for OpenTelemetry、Amazon VPC CNIAmazon VPC CNI plugin for Kubernetes、Grafana Kubernetes Monitoring などがあります。クラスターのためにアプリケーションデータを保存するストレージでは、Amazon EKS のアドオンには Amazon EBS で Kubernetes ボリュームを保存するAmazon Elastic Block Store CSI ドライバー (ブロックストレージデバイスの追加用)、Amazon EFS で伸縮自在なファイルシステムを保存するAmazon Elastic File System CSI ドライバー (ファイルシステムストレージの追加用)、サードパーティー製ストレージのアドオン (FSx for NetApp ONTAP を使用して高性能アプリケーションを保存するAmazon FSx for NetApp ONTAP CSI ドライバーなど) などがあります。

使用可能な Amazon EKS アドオンの完全なリストについては、「Amazon EKS アドオン」を参照してください。

ワークロード

Kubernetes では、ワークロードは「Kubernetes で実行中のアプリケーション」と定義されています。そのアプリケーションは、ポッド内のコンテナとして実行される、一連のマイクロサービスで構成されていますが、バッチジョブやその他の種類のアプリケーションとして実行される場合もあります。Kubernetes は、それらのオブジェクトを設定またはデプロイするために行われたリクエストを確実に実行する役割を担います。アプリケーションをデプロイするユーザーは、コンテナの構築方法、ポッドの定義方法、デプロイに使用する方法を学ぶ必要があります。

コンテナ

Kubernetes にデプロイして管理するアプリケーションワークロードの最も基本的な要素がポッドです。ポッドは、アプリケーションのコンポーネントを格納する方法であるだけでなく、ポッドの属性を記述する仕様を定義する方法でもあります。RPM や Deb パッケージは、Linux システム用のソフトウェアをまとめてパッケージ化しますが、それ自体はエンティティとしては動作しません。

ポッドはデプロイ可能な最小のユニットであるため、通常は 1 つのコンテナしか格納できません。しかし、コンテナが密結合している場合は、複数のコンテナを 1 つのポッドに含めることができます。例えばウェブサーバーコンテナは、ログ記録、モニタリング、またはウェブサーバーコンテナと密結合したその他のサービスを提供できるサイドカータイプのコンテナとともに、ポッドにパッケージ化できます。この場合、同じポッド内にあることで、そのポッドが実行している各インスタンスでは、両方のコンテナが常に同じノードで実行されることになります。同様に、ポッド内のすべてのコンテナは同じ環境を共有し、ポッド内のコンテナは、隔離された同じホストにあるかのように実行されます。これにより、各コンテナはポッドへのアクセスを可能にする 1 つの IP アドレスを共有し、コンテナはあたかも独自のローカルホスト上で実行しているかのように相互に通信することができます。

ポッドの仕様 (PodSpec) は、ポッドの望ましい状態を定義します。ワークロードリソースを使用してポッドテンプレートを管理することで、個別のポッドまたは複数のポッドをデプロイできます。ワークロードリソースには、Deployments (複数のポッドレプリカを管理する)、StatefulSets (データベースポッドなどの一意にする必要があるポッドをデプロイする)、DaemonSets (ポッドをすべてのノードで継続的に実行する必要がある場合) が含まれます。詳細は後ほど説明します。

ポッドはデプロイできる最小のユニットですが、コンテナは構築して管理できる最小のユニットです。

コンテナの構築

ポッドは、実際には 1 つ以上のコンテナを取り囲む構造に過ぎず、各コンテナ自体にファイルシステム、実行ファイル、設定ファイル、ライブラリ、その他アプリケーションを実際に実行するためのコンポーネントが格納されています。コンテナを普及させた会社の名前が Docker Inc. だったため、Docker コンテナと呼ばれることもあります。しかし、コンテナのランタイム、イメージ、ディストリビューション方法を業界向けに定義してきたのは Open Container Initiative です。また、コンテナは、Linux に既に存在していた多くの機能から作成されていることから、OCI コンテナ、Linux コンテナ、あるいはただ単にコンテナとも呼ばれます。

コンテナを構築するときは、通常は Dockerfile (会社名から命名) から始めます。Dockerfile 内では、以下を識別します。

• ベースイメージ - ベースのコンテナイメージは、通常は、オペレーティングシステムのファイルシステム (Red Hat Enterprise Linux や Ubuntu など) の最小バージョン、または特定の種類のアプリケーション (nodejs や python アプリケーションなど) を実行するソフトウェアを提供するように拡張された最小システムのいずれかから構築されるコンテナです。

• アプリケーションソフトウェア - Linux システムに追加するときとほぼ同じ方法で、アプリケーションソフトウェアをコンテナに追加できます。例えば、Dockerfile では、npm や yarn を実行して Java アプリケーションをインストールするか、yum や dnf を実行して RPM パッケージをインストールすることができます。つまり、Dockerfile で RUN コマンドを使用すると、ベースイメージのファイルシステムで使用可能な任意のコマンドを実行して、生成されたコンテナイメージの内部でソフトウェアをインストールしたり、設定したりできます。

• インストラクション - Dockerfile reference には、Dockerfile の設定時に追加できるインストラクションが記載されています。これには、コンテナ自体の中にあるもの (ローカルシステムの ADD または COPY ファイル) の構築、コンテナを実行するときに実行するコマンドの特定 (CMD または ENTRYPOINT)、コンテナを実行するシステムへのコンテナの接続 (実行する USER、マウントするローカル VOLUME、EXPOSE するポート) などに使用する指示が含まれています。

docker コマンドとサービスは、従来、コンテナ (docker build) の構築に使用されてきましたが、コンテナイメージの構築に使用できるその他ツールには podman や nerdctl などがあります。コンテナの構築方法については、「Building Better Container Images」または「Overview of Docker Build」参照してください。

コンテナの保存

コンテナイメージを作成したら、ワークステーションのコンテナディストリビューションレジストリ、またはパブリックコンテナレジストリに保存できます。ワークステーションでプライベートコンテナレジストリを実行すると、コンテナイメージをローカルに保存して、すぐに利用できるようにすることができます。

コンテナイメージを、よりパブリックな方法で保存するときは、イメージをパブリックコンテナレジストリーにプッシュします。パブリックコンテナレジストリは、コンテナイメージの保存と配布を一元的に行える場所です。代表的なパブリックコンテナレジストリには、Amazon Elastic Container Registry、Red Hat Quay レジストリ、Docker Hub レジストリなどがあります。

Amazon Elastic Kubernetes Service (Amazon EKS) でコンテナ化されたワークロードを実行するときは、Amazon Elastic Container Registry に保存されている Docker 公式イメージのコピーをプルすることをお勧めします。Amazon ECR は、2021 年からこれらのイメージを保存しています。人気の高いコンテナイメージは Amazon ECR Public Gallery で検索でき、特に、Docker Hub イメージは Amazon ECR Docker Gallery で検索できます。

コンテナの実行

コンテナは標準フォーマットで構築されているため、コンテナランタイムを実行でき (Docker など)、コンテンツがローカルマシンのアーキテクチャ (x86_64 や arm など) に一致するマシンであれば、どのマシンでもコンテナを実行できます。コンテナをテストしたり、ローカルのデスクトップで実行したりするには、docker run または podman run コマンドを使用して、ローカルホストでコンテナを起動します。ただし Kubernetes では、各ワーカーノードにコンテナランタイムがデプロイされており、そのノードにコンテナの実行をリクエストするかどうかは Kubernetes が決定します。

コンテナがノード上で実行されるように割り当てられると、そのノードは、リクエストされたバージョンのコンテナイメージがノード上にすでに存在するかどうかを確認します。存在しなければ、Kubernetes が、適切なコンテナレジストリからそのコンテナをプルしてローカルで実行するように、コンテナランタイムに指示します。コンテナイメージとは、ノートパソコン、コンテナレジストリー、Kubernetes ノード間を移動するソフトウェアパッケージのことを指します。コンテナとは、そのイメージの実行中のインスタンスを指します。

ポッド

コンテナの準備が整ったら、ポッドの操作として、ポッドの設定、デプロイ、ポッドをアクセス可能にするなどの作業を行います。

ポッドの設定

ポッドを定義するときは、一連の属性をポッドに割り当てます。これらの属性には、少なくともポッド名と実行するコンテナイメージが含まれている必要があります。ただし、ポッドの定義を使用して設定する必要のある項目は他にも多数あります (ポッドに追加できる内容の詳細については「PodSpec」のページを参照してください)。具体的には次のとおりです。

• ストレージ - 実行中のコンテナを停止して削除すると、より永続的なストレージを設定しない限り、そのコンテナ内のデータストレージは削除されます。Kubernetes はさまざまなストレージタイプをサポートしており、ボリューム内でこれらを抽象化します。ストレージタイプには、CephFS、NFS、iSCSI などがあります。ローカルのコンピュータからローカルブロックデバイスを使用することもできます。クラスターからこれらのストレージタイプのいずれかを使用すれば、ストレージボリュームをコンテナのファイルシステム内の選択したマウントポイントにマウントできます。永続ボリュームは、ポッドが削除された後も残り、エフェメラルボリュームはポッドが削除されると、削除されます。クラスター管理者がクラスター用に異なる StorageClasses を作成した場合、使用後にボリュームを削除するか、再利用するか、容量がさらに必要になった場合に拡張するか、また、特定のパフォーマンス要件を満たすようにするかなど、使用するストレージの属性を選択できることがあります。

• シークレット - ポッド仕様のコンテナでシークレットを使用できるようにすると、ファイルシステム、データベース、その他保護されているアセットにアクセスするために必要な許可をそれらのコンテナに付与できます。キー、パスワード、トークンは、シークレットとして保存できるアイテムです。シークレットを使用すると、この情報をコンテナイメージに保存する必要はなく、実行中のコンテナでシークレットを利用できるようにすることができます。シークレットに似ているのが ConfigMaps です。ConfigMap には一般に、サービスを設定するためのキーと値のペアなど、重要度が低い情報が格納されます。

• コンテナリソース - コンテナを詳細に設定するためのオブジェクトは、リソース設定の形式をとることができます。コンテナごとに、そのコンテナが使用できるメモリと CPU の量をリクエストできるほか、コンテナが使用できるリソースの合計量の上限を設定できます。例については、「Resource Management for Pods and Containers」を参照してください。

• 中断 - ポッドは、意図せずに (ノードがダウンしたとき)、または意図的に (アップグレードが必要なとき) 中断することがあります。ポッド中断の予算を設定することで、中断が起きた場合のアプリケーションの可用性をある程度制御することができます。アプリケーションの例については、「Specifying a Disruption Budget」を参照してください。

• 名前空間 - Kubernetes には、Kubernetes コンポーネントとワークロードを互いに分離するさまざまな方法が用意されています。特定のアプリケーションのすべてのポッドを、同じ名前空間で実行することは、それらのポッドをまとめて保護し管理する一般的な方法です。独自の名前空間を作成して使用することも、名前空間を指定しない (Kubernetes が default の名前空間を使用する) ように選択することもできます。Kubernetes コントロールプレーンのコンポーネントは、通常、kube-system 名前空間で実行されます。

これらの設定は、通常、YAML ファイルにまとめられ、Kubernetes クラスターに適用されます。パーソナルな Kubernetes クラスターの場合は、これらの YAML ファイルをローカルシステムに保存します。ただし、よりクリティカルなクラスターやワークロードの場合は、GitOps が、ストレージを自動化し、ワークロードと Kubernetes インフラストラクチャリソースの両方を更新する方法として一般的に使用されています。

ポッド情報の収集とデプロイに使用されるオブジェクトは、以下のデプロイ方法のいずれかによって定義されます。

ポッドのデプロイ

ポッドをデプロイする際に選択すべき方法は、そのポッドで実行する予定のアプリケーションのタイプに応じて異なります。この方法には、以下のようなものがあります。

• ステートレスアプリケーション - ステートレスアプリケーションは、クライアントのセッションデータを保存しないため、その次のセッションは、前のセッションで起きたことを参照する必要がありません。これにより、ポッドが異常な状態になった場合は新しいポッドと交換するか、状態を保存せずにポッドを移動させるだけで済みます。ステートレスアプリケーション (ウェブサーバーなど) を実行している場合は、Deployment を使用して Pods と ReplicaSets をデプロイできます。ReplicaSet は、同時に実行したいポッドのインスタンス数を定義します。ReplicaSet は直接実行することもできますが、1 回に実行するポッドのレプリカの数を定義するため、デプロイ内でレプリカを直接実行するのが一般的です。

• ステートフルアプリケーション - ステートフルアプリケーションとは、ポッドの ID とポッドの起動順序が重要であるアプリケーションのことです。これらのアプリケーションには、安定した永続的ストレージが必要であり、一貫した方法でデプロイしスケールインする必要があります。ステートフルアプリケーションを Kubernetes にデプロイするには、StatefulSets を使用します。通常、StatefulSet として実行されるアプリケーションの一例が、データベースです。StatefulSet 内では、レプリカ、ポッドとそのコンテナ、マウントするストレージボリューム、データを保存するコンテナ内の場所を定義できます。ReplicaSet としてデプロイされるデータベースの例については、「Run a Replicated Stateful Application」を参照してください。

• ノードあたりのアプリケーション - アプリケーションを、Kubernetes クラスター内のすべてのノードで実行する必要がある場合があります。例えば、データセンターで、すべてのコンピュータでモニタリングアプリケーションまたは特定のリモートアクセスサービスを実行する必要がある場合です。Kubernetes では、DaemonSet を使用することで、選択したアプリケーションがクラスター内のすべてのノードで実行されるようにすることができます。

• 完了まで実行するアプリケーション - 特定のタスクを完了するために、複数のアプリケーションを実行する必要がある場合があります。例えば、毎月のステータスレポートを実行したり、古いデータを消去したりする場合です。Job オブジェクトを使用すると、アプリケーションを起動して実行し、タスクが完了したら、終了するように設定することができます。CronJob オブジェクトを使用すると、Linux の crontab 形式で定義された構造を使用して、特定の時間、分、日、月、曜日に、アプリケーションを実行するように設定できます。

ネットワークからアプリケーションにアクセスできるようにする

アプリケーションはさまざまな場所を移動するマイクロサービスのセットとしてデプロイされることが多いため、Kubernetes には、それらのマイクロサービスが相互に検索できる方法が必要でした。また、Kubernetes クラスターの外にあるアプリケーションにアクセスするユーザーのために、Kubernetes には、そのアプリケーションを外部のアドレスとポートで公開する方法が必要でした。これらのネットワーク関連の機能は、それぞれ Service オブジェクトと Ingress オブジェクトを使って実行されます。

• サービス - ポッドは異なるノードやアドレスに移動できるため、最初のポッドと通信する必要のある別のポッドがそのポッドの場所を特定することが困難になる場合があります。この問題を解決するため、Kubernetes では、アプリケーションを Service として表すことができます。Service を使用すると、特定の名前を持つポッドまたはポッドのセットを識別し、そのアプリケーションのサービスをポッドから公開するポートと、他のアプリケーションがそのサービスにアクセスする際に使用できるポートを指定することができます。クラスター内の別のポッドは名前で Service をリクエストすることができ、Kubernetes は、そのリクエストをそのサービスを実行しているポッドのインスタンスの適切なポートに転送します。

• Ingress – Ingress は、Kubernetes Services によって示されたアプリケーションを、クラスター外のクライアントが利用できるようにします。Ingress の基本機能には、ロードバランサー (Ingress が管理)、Ingress コントローラー、コントローラーから Service にリクエストを送信するルールなどがあります。Kubernetes で選択できる Ingress Controllers は複数あります。

次のステップ

Kubernetes の基本的な概念と、それらが Amazon EKS とどのように関連するのかを理解することで、Amazon EKS ドキュメントと Kubernetes のドキュメントの両方を参照しながら、Amazon EKS クラスターを管理したりワークロードをクラスターにデプロイしたりする際に必要になる情報をすぐに見つけられるようになります。Amazon EKS の使用を開始するには、以下から選択してください。

• Amazon EKS – eksctl の使用開始シンプルなクラスターを作成する

• Amazon EKS クラスターを作成します。より複雑なクラスターを作成する

• Linux サンプルアプリケーションをデプロイするサンプルアプリケーションをデプロイする

• クラスターリソースを整理およびモニタリングするクラスターの管理方法を知る