Kubernetes とは?

Kubernetes は、DevOps がクラスター全体でコンテナーのデプロイ、管理、スケーリングに使用するオープンソース ソフトウェアです。もう 1 つのオープンソース テクノロジである Docker は、Kubernetes と共に一般的に使用される既定のコンテナー ファイル形式です。

コンテナー

コンテナーは、アプリをその依存関係と構成とともにパッケージ化するため、さまざまな環境で一貫して動作できます。アプリケーションの進化に伴い、多数のサーバーで多数のコンテナーを実行する場合があり、そのすべてを手動で調整することは複雑になります。Kubernetes は、オープンソース API と、何をどこで実行する必要があるかを決定してその実行を維持するコントロール システムを使用して、その複雑さに対処します。

Kubernetes の機能

スケジュールとリソースの配置

Kubernetes は、仮想マシンのクラスターを調整し、利用可能なコンピューティング リソースと各コンテナーのリソースのニーズに基づいて、実行するコンテナーをスケジュールします。

サービス検出と負荷分散

Kubernetes は、サービスの検出と負荷分散を管理するため、ポッドが時間の経過と共に変化しても、トラフィックを適切なポッドにルーティングできます。

需要に合わせたスケーリング

Kubernetes は、コンピューティング使用率と設定した目的の状態に基づいてワークロードをスケーリングします。

失敗した場合の自己回復

Kubernetes は、リソースの正常性をチェックし、問題が発生したときにコンテナーを再起動またはレプリケートできます。障害が発生したコンテナーを再起動または置き換え、ワークロードの準備ができるまでトラフィックを保留します。

制御された変更のサポート

Kubernetes は、記述した目的の状態に基づく自動ロールアウトやロールバックを含め、稼働中のアプリケーションに対するデプロイ パターンをサポートします。

構成とシークレットの管理

Kubernetes は、パスワードやトークンなどの機密情報のシークレットと構成管理を提供します。

ストレージ オーケストレーション

Kubernetes では、Kubernetes のストレージ オーケストレーション モデルに基づいて、選択したストレージ システム (ローカル ストレージやパブリック クラウド オプションなど) をマウントできます。

オブジェクトの簡単な用語集

Kubernetes は、API オブジェクト (宣言および管理するリソース) を中心に構築されています。併せてご確認ください。

• ポッド: 1 つ以上のコンテナーを実行する基本単位。

• サービス: アプリを公開し、変化するポッドにトラフィックをルーティングするための安定した方法。

• デプロイ: 目的のアプリの状態を記述し、時間の経過と共に更新する方法 (多くの場合、ロールアウトとロールバックに関連付けられています)。

• ノード: ポッドが実行されているクラスター内のマシン。

• コントロール プレーン: クラスターの状態とスケーリングの決定を管理するコンポーネント。

全体の仕組み

1. アプリケーションの目的の状態 (実行する内容、コピーの数、リソースのニーズ) を宣言します。

2. コントロール プレーンは、Kubernetes API とバッキング ストアを介してその要求を記録して処理します。

3. スケジューラは、十分なリソースを持つノードにポッドを配置します。

4. ノード コンポーネントがワークロードを実行します。

5. コントローラーは継続的に調整を行い、実際の状態が必要な状態 (必要に応じたワークロードのスケーリング、置換、更新) と一致するようにします。

主要な構成要素

クラスター: コントロール プレーンとワーカー ノード

Kubernetes クラスターは通常、クラスターを管理するコントロール プレーンとワークロードを実行するワーカー ノードの 2 つの部分で記述されます。

コントロール プレーン コンポーネント

これらのコンポーネントは、クラスターの全体的な状態を管理します。

• kube-apiserver: Kubernetes HTTP API (要求のフロント ドア) を公開します。

• etcd: クラスター データ用の一貫性のある高可用性キー値ストア。

• kube-scheduler: 配置が必要なポッドを検索し、これらをノードに割り当てます。

• kube-controller-manager: 実際の状態を目的の状態に調整するコントローラーを実行します。

• cloud-controller-manager (省略可能): Kubernetes をクラウド プロバイダー固有のコントロール ロジックに接続します。

コード コンポーネント

各ワーカー ノードは、ポッドとネットワーク規則を管理するソフトウェアを実行します。

• kubelet: ポッドがノード (コンテナーを含む) で実行されていることを確認します。

• kube-proxy (省略可能): サービスをサポートするためのネットワーク規則を管理します。

• container runtime: ノードでコンテナーを実行します。

ポッド: 作業の基本単位

Kubernetes は、抽象内で個々のコンテナーを直接スケジュールすることはありません。1 つ以上のコンテナーをポッドにグループ化し、このポッドが基本的な運用単位になります。その後、ポッドは、定義した目的の状態に合わせてスケールアップまたはスケールダウンされます。

実際には、これは次のことを意味します。

1. ユーザーが、実行したいアプリについて記述します。

2. Kubernetes が、使用可能なコンピューティングを使用してポッドをマシンにスケジュールします。

3. コントローラーが、クラスターがユーザーが要求した状態に向かって移行させ続けます。

サービス ネットワーク

ポッドは出入りする可能性があるため、Kubernetes は、ワークロードに到達するための安定した方法を提供するプリミティブ (クラスター上でアプリケーションを記述および実行するために組み合わせる基本的な構成要素) を提供します。

ポッド ネットワークの基本

各ポッドは、独自のクラスター全体の IP アドレスを取得し、ポッドは、Kubernetes ネットワーク モデル内でネットワーク アドレス変換 (NAT) を使用せずにノード間で通信できます。

サービス

サービス API は、個々のポッドが時間の経過と共に変化したとしても、一連のバックエンド ポッドに対して安定した IP アドレスまたはホスト名を提供します。

EndpointSlice

Kubernetes は、現在どのポッドがサービスをバッキングしているかを追跡するために、エンドポイント スライス オブジェクトを管理します。

イングレス/ゲートウェイ API

クラスター外のクライアントにサービスを公開するために、Kubernetes は、ゲートウェイ API (およびその前身であるイングレス) をサポートしています。

LoadBalancer サービス

一部の環境では、LoadBalancer サービスの種類を使用してサービスを外部に公開できます。

クラスターで実行できるアドオン

Kubernetes クラスターには、多くの場合、コア コンポーネントを超えて機能を拡張するアドオンが含まれています。次のような例があります。

• クラスター全体の名前解決用の DNS。

• クラスター管理用の Web UI (ダッシュボード)。

• メトリック収集用のコンテナー リソース監視。

• ログを一元的に収集するためのクラスター レベルのログ。

Kubernetes は、コンテナー化されたアプリケーションをマシンのクラスター上で実行し、記述した状態に維持します。これを行うには、適切なマシンに作業を配置し、トラフィックを適切な場所にルーティングし、障害と変更を監視します。

基本的なフロー

1. ユーザーが実行したい内容を記述する

ほとんどの Kubernetes ワークロードは、宣言された "目的の状態" (実行する必要がある内容、コピーの数、公開方法) として開始されます。Kubernetes は、宣言型の構成と自動化を中心に構築されています。

2. Kubernetes が実行する場所を決定する

Kubernetes は、使用可能なコンピューティング リソースと各コンテナーのニーズに基づいて、クラスター内のマシンにコンテナーをスケジュールします。コンテナーはポッド内で実行されます。これは、Kubernetes がマシン上に配置するユニットです。

3. Kubernetes がユーザーの目的の状態と照らし合わせて現実を確認し続ける

コントローラーはクラスターを監視し、API サーバーを使用して変更を加えて、現在の状態を目的の状態に近づけます。

コンテナーのスケジューリングと日常的な管理

スケジューリングとは、「これをどこで実行するか」を 決定する作業です。

1. スケジュールされるのはポッドであり、個々のコンテナーではない

Kubernetes はコンテナーをポッドにグループ化してから、それらのポッドをマシンに配置します。

2. スケジューラーがポッドを適切なノードに割り当てる

kube-scheduler は、まだ割り当てられていないポッドを探し、それらのノードを選択します。

3. ノード エージェントがポッドの実行を維持する

各ノードでは、kubelet がポッドが実行されていることを確認します (コンテナーを含む)。

負荷分散とサービス検出

コンテナーやポッドは作成、移動、置換え可能なため、アプリケーションには、互いを見つける安定した方法が必要です。

サービス検出と負荷分散は組み込みの動作である

Kubernetes は、サービス検出を管理し、負荷分散を使用するため、ポッドが時間の経過と共に変化しても、トラフィックをルーティングできます。

サービスは、一連の変化するポッドに対して安定したアドレスを提供する

サービス API は、1 つ以上のポッドによってバッキングされているサービスに対して、安定した IP アドレスまたはホスト名を提供します。Kubernetes は、EndpointSlice オブジェクトを通じてバッキング ポッドを追跡します。

ポッドの変更に合わせてトラフィック ルーティングが更新される

サービスの背後にあるポッドが変更されると、トラフィックが現在のバックエンドに引き続き到達するようにサービス ルーティングが調整されます。

アプリケーションのスケーリング (および "目的の状態" が重要な理由)

Kubernetes は、ユーザーが設定した状態に向けてワークロードをスケーリングできます (コンピューティング使用率に基づくスケーリングを含む)。

一般的なスケーリングの考え方には次のようなものがあります:

• より多くのレプリカ (より多くのポッド) で需要の増加に対応します。

• 要求が減少すると、レプリカが少なくなります。

• リソースの追跡により、配置の判断に CPU とメモリのニーズが反映されるようにします。

これは"目的の状態" モデルに関連しています。ターゲットを指定すると、コントローラーはそれに向かって動作し続けます。

自己回復: 何かが壊れた場合の動作

Kubernetes には、ワークロードの正常性と可用性を維持することを目的とした自己回復動作が含まれています。これには次のものが含まれます。

• 失敗したコンテナーの再起動 (コンテナー レベルの再起動)。

• 要求されたレプリカ数を維持するための、失敗したポッドの置換 (レプリカの置換)。

• ノードが使用できなくなった場合のワークロードの再スケジュール。

• トラフィックを正常なポッドのみに送るための、失敗したポッドのサービス エンドポイントからの削除 (サービスの負荷分散)。

自己回復では、問題が発生したときに、コンテナーの正常性を確認し、コンテナーを再起動または複製します。

Kubernetes KPI の役割

主要業績評価指標 (KPI またはメトリック) を使用して、クラスターの正常性とワークロードの動作を理解します。

KPI の発生元

• Kubernetes システム コンポーネントは、ダッシュボードとアラートに役立つメトリック (Prometheus 形式) を出力します。

• メトリックは通常、コンポーネントの /metrics HTTP エンドポイントで使用できます (kube-apiserver、kube-scheduler、kubelet、kube-proxy、kube-controller-manager などのコンポーネントを含む)。

KPI が把握に役立つ内容の例

• クラスターの正常性シグナル (コンポーネント レベルのメトリックとエラー パターン)

• ワークロードの安定性 (頻繁な再起動や置換など)

• 容量の負荷 (スケーリングの決定に関連する、リソースの割り当てと需要の違い)

これが日常業務で重要な理由

監視により、チームは、クラスター リソース、Kubernetes API、コンテナー、ログをより包括的に把握できるため、問題の把握から修正までのフィードバック ループが短くなります。

Kubernetes は、多くの場合、チームが、トラフィック ルーティング、スケーリング、回復処理をプラットフォームに任せながら、多数のマシン上で多数のコンテナーを実行する一貫した方法を必要とするときに選択されます。

スケーラビリティ

Kubernetes はワークロードをスケーリングできます。つまり、需要の変化に応じてワークロードを目的の状態に向けて増減し、コンピューティング使用率に基づいてスケーリングできます。

一般的なユース ケース

• トラフィックが変動する Web アプリ (キャンペーン、季節的なピーク): 負荷の変化に応じてレプリカを調整します。

• バッチ処理またはイベント ドリブン処理: 突発的な需要に合わせて容量を追加し、その後はスケールバックします。

• マイクロサービス: アプリケーション全体をスケーリングせずに、特定のサービスをスケーリングします。

リソースの効率

Kubernetes は、自動ビン パッキングをサポートしています。これは、CPU とメモリのニーズに基づいてコンテナーをノードに配置し、使用可能なリソースをより有効に活用する方法です。また、ワークロードを管理しながら、リソース割り当ても追跡します。

一般的なユース ケース

• 複数のチームで共有するクラスター: リソースがある場所にワークロードを配置して、無駄な容量を削減します。

• 混在ワークロード クラスター (サービスとジョブ): 手動で配置せずにノードを有効に活用します。

サービス検出と負荷分散

Kubernetes は、DNS または IP アドレスを使用してワークロードを公開し、デプロイの安定性を保つためにネットワーク トラフィックを分散できます。また、サービス検出を管理し、ワークロードの変化に応じて負荷分散を組み込みます。

一般的なユース ケース

• マイクロサービス間の通信: ポッドが変化しても、サービスは安定した名前でお互いを見つけます。

• 安定したエンドポイントの背後にある内部 API: トラフィックを現在のバックエンドのみにルーティングします。

自己回復

Kubernetes は、障害が発生したコンテナーを置き換え、ノードが使用できなくなったときにワークロードを再スケジュールし、目的の状態を維持するように設計されています。たとえば、コンテナーを再起動する場合、レプリカを置き換える場合、正常でないポッドをサービス エンドポイントから削除してトラフィックを正常なポッドのみに送る場合があります。

一般的なユース ケース

• 常時稼働のサービス: 手動介入なしで、障害が発生したインスタンスを再起動または置換します。

• ノードの変動が頻繁に発生するクラスター: ノードが停止したときに、ワークロードを再スケジュールします。

• サービスの背後にあるサービス: 異常なポッドへのトラフィックのルーティングを停止します。

より安全なリリース

Kubernetes は、自動ロールアウトおよびロールバックをサポートします。ユーザーが目的の状態を記述すると、Kubernetes が実際の状態を制御された速度でその状態に向かって移行します。

一般的なユース ケース

• 頻繁なアプリケーションの更新: 変更を段階的にロールアウトしてから、必要に応じて元に戻します。

• 複数のサービスを提供するチーム: アプリ間でリリースの仕組みを一貫させます。

移植性

コンテナー化されたアプリはインフラストラクチャーとは別のものです。Kubernetes は、オンプレミス、サーバーレス、ハイブリッド クラウド、マルチクラウド環境全体でこれらのアプリをローカル マシンから本番環境に移行しながら、各環境間で一貫性を維持します。

一般的なユース ケース

• 開発/テスト/本番環境のパリティ: 環境全体で同じパッケージ化およびスケジューリング モデルを維持します。

• ハイブリッド デプロイ: システムの一部をオンプレミスで、残りをクラウドで、同じオーケストレーションのアプローチで実行します。

Kubernetes は、拡大を続ける大規模なツールとコミュニティ サポートによって支えられた、宣言型な構成と機械学習の自動化を使用してコンテナー化されたワークロードを実行する一般的な方法を提供します。

クラウドネイティブ アプリにとって引き続き重要な理由

チームが多くのサービス、短時間のワークロード、頻繁な更新で構成されるシステムを構築する場合、Kubernetes は、繰り返し可能な運用に重点を置いているため、実用的な基盤として機能し続けます。

• 環境全体での一貫した運用 (依存関係と共にパッケージ化されたコンテナーが、環境全体で同じ方法で実行されます)。

• 幅広く利用できるサービス、サポート、ツールを備えた広範でアクティブなエコシステム。

• コミュニティが構築したアドオン、プラグイン、バージョン間でコア API の一貫性を保つコンフォーマンス プログラムによる拡張性。

ワークロードを構築または実行している場合、Azure Kubernetes Service (AKS) は、Azure がコントロール プレーンを管理することで、コンテナー化されたアプリケーションのデプロイと管理に役立ちます。