Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Kubernetes の概念

フォーカスモード

このページの内容

Kubernetes の概念 - アマゾン EKS

このページの改善にご協力ください

本ユーザーガイドの改善にご協力いただけませんか? すべてのページの右側のペインにある GitHub リンクで、このページの編集を選択してください。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。

このページの改善にご協力ください

本ユーザーガイドの改善にご協力いただけませんか? すべてのページの右側のペインにある GitHub リンクで、このページの編集を選択してください。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。

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

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

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

Kubernetes を利用する理由

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

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

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

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

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

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

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

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

Kubernetes の属性

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

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

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

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

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

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

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

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

Kubernetes の管理

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

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

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

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

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

実行中の Kubernetes

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

実行中の Kubernetes クラスター。

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

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

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

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

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

クラスター

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

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

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

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

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

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

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

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

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

コント役割プレーン

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

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

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

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

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

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

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

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

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

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

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

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

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

拡張クラスター

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

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

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

ワークロード

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

コンテナ

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

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

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

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

コンテナの構築

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

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

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

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

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

docker コマンドとサービスは従来、コンテナ (docker build) の構築に使用されてきましたが、コンテナイメージの構築に使用できるその他ツールには podmannerdctl などがあります。コンテナの構築方法については「より良いコンテナ・イメージの構築」または「Dockerビルドの概要」参照してください。

コンテナの保存

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

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

アマゾン エラスティックKubernetesサービス (アマゾン EKS) でコンテナ化されたワークロードを実行するときはアマゾン エラスティック・コンテナ・レジストリ に保存されている Docker 公式イメージのコピーをプルすることをお勧めします。アマゾン ECR は2021 年からこれらのイメージを保存しています。人気の高いコンテナイメージは アマゾン ECR Public Gallery で検索でき、特に、Docker Hub イメージは アマゾン ECR Docker Gallery で検索できます。

コンテナの実行

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

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

ポッド

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

ポッドの設定

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

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

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

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

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

  • 名前空間 - 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 としてデプロイされるデータベースの例については「レプリケートされたステートフル アプリ」を参照してください。

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

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

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

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

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

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

次のステップ

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

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.