このページの改善にご協力ください
本ユーザーガイドの改善にご協力いただけませんか? すべてのページの右側のペインにある GitHub リンクで、このページの編集を選択してください。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。
アマゾン エラスティックKubernetesサービス (アマゾン EKS) はオープンソースの 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 クラスター。](images/k8sinaction.png)
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 インストールツール
AWS クラウドではアマゾン EKS クラスターを、eksctl
-
マネージドコント役割プレーン - AWS はコント役割プレーンをユーザーに代わって管理し、AWS アベイラビリティーゾーン全体で利用可能にするため、アマゾン EKS クラスターが利用可能かつスケーラブルになります。
-
ノード管理 - ノードを手動で追加する代わりに、マネージドノードグループを使用してノードライフサイクルを簡素化するマネージドノードグループまたは Karpenter
を使用して、必要に応じて Amazon EKS でノードを自動的に作成できます。マネージドノードグループはKubernetes クラスター自動スケーリング と統合されています。ノード管理ツールを使用すると、スポットインスタンスやノード統合などによりコストを節約したり、ワークロードのデプロイ方法やノードの選択方法を設定するスケジューリング 機能を使って、可用性を活用することができます。 -
クラスターネットワーク -
eksctl
はクラウドフォーメーション テンプレートを使用して、Kubernetes クラスター内のコント役割プレーンとデータプレーン (ノード) コンポーネント間に、ネットワークを設定します。また、内部と外部の通信を行うためのエンドポイントも設定します。詳細については「ツールのインストールアマゾンEKSワーカーノードのクラスターネットワーキングの謎を解く」を参照してください。Amazon EKS 内のポッド間の通信はEKS Pod Identity がポッドに AWS サービスへのアクセス権を付与する方法を学ぶAmazon EKS ポッド・アイデンティティー を使用して行われます。これによりポッドは認証情報やアクセス許可を管理する AWS クラウドの方法を利用できるようになります。 -
アドオン - アマゾン EKS を使用すると、Kubernetes クラスターをサポートするために一般的に使用される、ソフトウェアコンポーネントを構築して追加する必要がなくなります。例えば、AWS マネジメントコンソールから Amazon EKS クラスターを作成すると、Amazon EKS アマゾン EKS クラスターで kube-proxy を管理するkube-proxyKubernetes、 用の アマゾン VPC CNI を使用してPodsに IP を割り当てるAmazon VPC CNI プラグイン、CoreDNS (アマゾン EKS クラスターで DNS の CoreDNS を管理する) アドオンが、自動的に追加されます。利用可能なアドオンも含む、これらのアドオンの詳細については「アマゾン EKS アドオン」を参照してください。
クラスターをオンプレミスのコンピュータとネットワーク上で実行できるように、アマゾン は アマゾン EKS Anywhere
アマゾン EKS Anywhere はアマゾン EKS で使用されているものと同じ アマゾン EKS Distroetcd
ュメントで後述する etcd を参照)。
クラスターコンポーネント
Kubernetes クラスターコンポーネントはコント役割プレーンとワーカーノードという 2 つの主要な領域に分かれています。コント役割プレーンコンポーネント
コント役割プレーン
コント役割プレーンはクラスターを管理する一連のサービスで構成されています。これらのサービスはすべて 1 台のコンピュータで実行される場合もあれば、複数のコンピュータに分散される場合もあります。内部的にはこれらはコント役割プレーンインスタンス (CPI) と呼ばれます。CPI の実行方法はクラスターの規模と、高可用性の要件に応じて異なります。クラスターの需要が増えると、コント役割プレーンサービスはスケールしてそのサービスのインスタンスを増やし、リクエストはインスタンス間で負荷分散されます。
Kubernetes コント役割プレーンのコンポーネントが実行するタスクには以下が含まれます。
-
クラスターコンポーネント (API サーバー) との通信 (API サーバー) - API サーバー (kube-apiserver
) はクラスターへのリクエストをクラスターの内部と外部の両方から行えるようにするために Kubernetes API を公開します。つまり、クラスターのオブジェクト (ポッド、サービス、ノードなど) を追加または変更するリクエストはポッドを実行する kubectl
のリクエストなどの外部コマンドから送信することができます。同様に、ポッドのステータスをkubelet
サービスにクエリするときのように、API サーバーからクラスター内のコンポーネントに対してリクエストを実行することができます。 -
クラスターに関するデータの保存 (
etcd
キーバリューストア)* - サービスはクラスターの現在の状態を追跡するという重要な役割を担っています。etcd
etcd
サービスにアクセスできなくなると、ワークロードはしばらく実行し続けますが、クラスターの状態を更新したりクエリしたりすることはできなくなります。そのため、重要なクラスターは通常、複数の負荷分散された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-controller
、endpoint-controller
、cronjob-controller
、node-controller
など、さまざまな Kubernetes オブジェクトを監視するいくつかのコントローラーがあります。 -
クラウドリソースの管理 (クラウド コントローラー マネージャー) - Kubernetes と、基盤となるデータセンターリソースのリクエストを実行するクラウドプロバイダーとのやり取りはクラウド コントローラー マネージャー
(cloud-controller-manager ) が処理します。クラウド コントローラー マネージャー が管理するコントローラーにはルートコントローラー (クラウドネットワークルートの設定用)、サービスコントローラー (クラウドのロードバランシングサービスを使用するためのもの)、ノードライフサイクルコントローラー (クラウド API を使用してライフサイクル全体でノードを Kubernetes と同期させるためのもの) があります。
ワーカーノード (データプレーン)
単一ノード Kubernetes クラスターの場合、ワークロードはコント役割プレーンと同じマシンで実行してください。ただし、より標準的な構成ではKubernetes ワークロードを実行するための専用の個別のコンピュータシステム (ノード
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 オープンテレメトリー用ディストロ
使用可能な アマゾン EKS アドオンの完全なリストについては「アマゾン EKS アドオン」を参照してください。
ワークロード
Kubernetes ではワークロード
コンテナ
Kubernetes にデプロイして管理するアプリケーションワークロードの最も基本的な要素がポッド
ポッドはデプロイ可能な最小のユニットであるため、通常は 1 つのコンテナしか格納できません。しかし、コンテナが密結合している場合は複数のコンテナを 1 つのポッドに含めることができます。例えばウェブサーバーコンテナはログ記録、モニタリング、またはウェブサーバーコンテナと密結合したその他のサービスを提供できるサイドカー
ポッドの仕様 (PodSpec
ポッドはデプロイできる最小のユニットですが、コンテナは構築して管理できる最小のユニットです。
コンテナの構築
ポッドは実際には 1 つ以上のコンテナを取り囲む構造に過ぎず、各コンテナ自体にファイルシステム、実行ファイル、設定ファイル、ライブラリ、その他アプリケーションを実際に実行するためのコンポーネントが格納されています。コンテナを普及させた会社の名前が Docker Inc. だったため、Docker コンテナと呼ばれることもあります。しかし、コンテナのランタイム、イメージ、ディストリビューション方法を業界向けに定義してきたのは オープン・コンテナ構想
コンテナを構築するときは通常は Dockerfile (会社名から命名) から始めます。Dockerfile 内では以下を識別します。
-
ベースイメージ - ベースのコンテナイメージは通常はオペレーティングシステムのファイルシステム (レッドハット・エンタープライズ リナックス
や Ubuntu など) の最小バージョン、または特定の種類のアプリケーション (nodejs や python アプリケーションなど) を実行するソフトウェアを提供するように拡張された最小システムのいずれかから構築されるコンテナです。 -
アプリケーションソフトウェア - リナックス システムに追加するときとほぼ同じ方法で、アプリケーションソフトウェアをコンテナに追加できます。例えば、Dockerfile では
npm
やyarn
を実行して Java アプリケーションをインストールするか、yum
やdnf
を実行して RPM パッケージをインストールすることができます。つまり、Dockerfile で RUN コマンドを使用すると、ベースイメージのファイルシステムで使用可能な任意のコマンドを実行して、生成されたコンテナイメージの内部でソフトウェアをインストールしたり、設定したりできます。 -
インストラクション - Dockerfile 参照
にはDockerfile の設定時に追加できるインストラクションが記載されています。これにはコンテナ自体の中にあるもの (ローカルシステムの ADD
またはCOPY
ファイル) の構築、コンテナを実行するときに実行するコマンドの特定 (CMD
またはENTRYPOINT
)、コンテナを実行するシステムへのコンテナの接続 (実行するUSER
、マウントするローカルVOLUME
、EXPOSE
するポート) などに使用する指示が含まれています。
docker
コマンドとサービスは従来、コンテナ (docker build
) の構築に使用されてきましたが、コンテナイメージの構築に使用できるその他ツールには podman
コンテナの保存
コンテナイメージを作成したら、ワークステーションのコンテナディストリビューションレジストリ
コンテナイメージを、よりパブリックな方法で保存するときはイメージをパブリックコンテナレジストリーにプッシュします。パブリックコンテナレジストリはコンテナイメージの保存と配布を一元的に行える場所です。代表的なパブリックコンテナレジストリにはアマゾン エラスティック・コンテナ・レジストリ
アマゾン エラスティックKubernetesサービス (アマゾン EKS) でコンテナ化されたワークロードを実行するときはアマゾン エラスティック・コンテナ・レジストリ に保存されている Docker 公式イメージのコピーをプルすることをお勧めします。アマゾン ECR は2021 年からこれらのイメージを保存しています。人気の高いコンテナイメージは アマゾン ECR Public 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
」を参照してください。 -
中断 - ポッドは意図せずに (ノードがダウンしたとき)、または意図的に (アップグレードが必要なとき) 中断することがあります。ポッド中断の予算
を設定することで、中断が起きた場合のアプリケーションの可用性をある程度制御することができます。アプリケーションの例については「中断予算の指定 」を参照してください。 -
名前空間 - Kubernetes にはKubernetes コンポーネントとワークロードを互いに分離するさまざまな方法が用意されています。特定のアプリケーションのすべてのポッドを、同じ名前空間
で実行することはそれらのポッドをまとめて保護し管理する一般的な方法です。独自の名前空間を作成して使用することも、名前空間を指定しない (Kubernetes が default
の名前空間を使用する) ように選択することもできます。Kubernetes コント役割プレーンのコンポーネントは通常、kube-system名前空間で実行されます。
これらの設定は通常、YAML ファイルにまとめられ、Kubernetes クラスターに適用されます。パーソナルな Kubernetes クラスターの場合はこれらの YAML ファイルをローカルシステムに保存します。ただし、よりクリティカルなクラスターやワークロードの場合はGitOps
ポッド情報の収集とデプロイに使用されるオブジェクトは以下のデプロイ方法のいずれかによって定義されます。
ポッドのデプロイ
ポッドをデプロイする際に選択すべき方法はそのポッドで実行する予定のアプリケーションのタイプに応じて異なります。この方法には以下のようなものがあります。
-
ステートレスアプリケーション - ステートレスアプリケーションはクライアントのセッションデータを保存しないため、その次のセッションは前のセッションで起きたことを参照する必要がありません。これにより、ポッドが異常な状態になった場合は新しいポッドと交換するか、状態を保存せずにポッドを移動させるだけで済みます。ステートレスアプリケーション (ウェブサーバーなど) を実行している場合は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 のドキュメント