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 Docker Compose File to Kubernetes Resources」を参照してください。

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

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

ハードウェア - 要件に応じて 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 Anywhere には、多くの一般的なオープンソースプロジェクトのビルドを含む、キュレーションパッケージがあります。そのため、ユーザーは、ソフトウェアを自分で構築したり、重要なセキュリティパッチ、バグ修正、アップグレードを管理したりする必要はありません。同様に、デフォルトの設定がニーズを満たしていれば、通常それらのアドオンの設定はほとんど必要ありません。アドオンを使用してクラスターを拡張する方法については、「クラスターの拡張」を参照してください。

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

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

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

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

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

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

ノードへのポッドのスケジュール (スケジューラー) - 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 と同期させるためのもの) があります。

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

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

コンテナ間のネットワークの管理 (kube-proxy) - サービスを使用してポッド間の通信をサポートする場合、Kubernetes に、ポッドネットワークを設定して、それらのポッドに関連づけられた IP アドレスとポートを追跡する方法が必要でした。kube-proxy サービスは、各ノードで実行し、ポッド間でその通信を可能にします。

ベースイメージ - ベースコンテナイメージは、通常は、オペレーティングシステムのファイルシステム (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 するポート) などに使用する指示が含まれています。

ストレージ - 実行中のコンテナを停止して削除すると、より永続的なストレージを設定しない限り、そのコンテナ内のデータストレージは削除されます。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 名前空間で実行されます。

ステートレスアプリケーション - ステートレスアプリケーションは、クライアントのセッションデータを保存しないため、以降のセッションは前のセッションで起きたことを参照する必要がありません。これにより、ポッドが異常な状態になった場合は新しいポッドと交換するか、状態を保存せずにポッドを移動させるだけで済みます。ステートレスアプリケーション (ウェブサーバーなど) を実行している場合は、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 では、アプリケーションを Service として表すことができます。Service を使用すると、特定の名前を持つポッドまたはポッドのセットを識別し、そのアプリケーションのサービスをポッドから公開するポートと、他のアプリケーションがそのサービスにアクセスする際に使用できるポートを指定することができます。クラスター内の別のポッドは名前で Service をリクエストすることができ、Kubernetes は、そのリクエストをそのサービスを実行しているポッドのインスタンスの適切なポートに転送します。

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

シンプルなクラスターを作成する

より複雑なクラスターを作成する

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

クラスターの管理方法を知る