ソリューションとテクノロジーで成功への道筋をつけることができます。Cloudお客様のビジネス全体に役立つ、わかりやすい料金体系です。安全でインテリジェントなプラットフォームを使って今すぐ始めましょう。プロダクトをお試しいただけます。ポッドの使用方法について説明します。デプロイできる最小かつ最も基本的なオブジェクトです。ポッドは、クラスタ内で実行されるプロセスの単一インスタンスを表します。ポッドで複数のコンテナが実行される場合、コンテナは単一のエンティティとして管理され、ポッドのリソースを共有します。一般に、単一のポッドで複数のコンテナを実行するのは、高度なユースケースです。ポッドには、ポッド内のコンテナが共有するネットワークとストレージのリソースも含まれています。アドレスが自動的に割り当てられます。ポートを含む同じネットワーク名前空間を共有します。使用して互いに通信します。ボリュームのセットを指定できます。ポッドは、ホストするアプリケーション向けのシステム上のニーズを組み込んだ自己完結型の独立した「論理ホスト」のようなものです。各ポッドは、クラスタ上でアプリケーションの単一インスタンスを実行するためのものです。個々のポッドを直接作成することは推奨されません。代わりに、通常は、「レプリカ」と呼ばれる同一のポッドからなるセットを作成して、アプリケーションを実行します。「コントローラ」によって作成され、管理されます。コントローラは、構成要素となるポッドのライフサイクルを管理するほか、「水平スケーリング」を実行して、必要に応じてポッドの数を変更することもできます。ポッドをデバッグ、トラブルシューティング、または検査するためにポッドを直接操作することもありますが、コントローラを使用してポッドを管理することを強くおすすめします。ポッドは、クラスタ内のノードで実行されます。作成されたポッドは、プロセスが完了するか、ポッドが削除されるか、リソース不足のためにポッドがノードから強制排除されるか、ノードに障害が発生するまで、ノードに存在し続けます。ノードに障害が発生すると、ノード上のポッドは自動的に削除するようにスケジュールされます。ポッドのライフサイクルポッドは一時的なものです。ポッドは永続的に動作するように設計されておらず、終了したポッドを元に戻すことはできません。一般に、ユーザーまたはコントローラによって削除されるまで、ポッドがなくなることはありません。ポッドは自身を修復しません。ポッドがスケジュールされたノードでその後障害が発生した場合、ポッドは削除されます。同様に、なんらかの理由でポッドがノードから強制排除された場合、ポッドは自身を置き換えません。フィールドでそれが表されます。フィールドに自身の「フェーズ」を公開します。ポッドのフェーズは、ポッドの現在の状態の概要です。実行すると、次のいずれかのフェーズが返されます。以上のコンテナがまだ実行されていません。このフェーズには、ノードでのスケジューリングとイメージのダウンロードにかかる時間が含まれます。ポッドがノードにバインドされ、すべてのコンテナが作成されました。つのコンテナが実行中、起動中、または再起動中です。ポッド内のすべてのコンテナが正常に終了しました。終了したポッドは再起動しません。つのコンテナが失敗状態で終了しました。コンテナは、ゼロ以外のステータスで終了した場合に「失敗」となります。ポッドの状態を特定できません。フィールドが含まれています。現在のステータスの原因となったポッド内の状況をより具体的に示します。含まれる可能性があります。含まれる可能性があります。フィールドを含むポッドのマニフェスト全体を表示できます。ポッドを作成するポッドは一時的なものですから、ポッドを直接作成する必要はありません。同様に、ポッドは自身を修理したり置き換えたりできないので、ポッドを直接作成することは推奨されません。コントローラを使用して自動的にポッドを作成し、管理できます。コントローラは、更新プロセス全体を自動的に管理するため、更新をロールアウトする場合(コンテナ内で実行されるアプリケーションのバージョンを変更する場合など)にも役立ちます。メモリがリクエストされます。適切なノードにポッドをスケジュールしてワークロードを実行できるようになります。ポッドは、ポッドのリクエストに対応できるリソースがないノードではスケジュールされません。リクエストはポッドの制限とは異なります。両者は連動して機能します。メモリのリクエストを構成できます。ポッド内で実行される個々のコンテナに対して、リクエストを指定することもできます。以下の点にご注意ください。数値よりもはるかに小さい値です。メモリに関しては、デフォルトのリクエストはありません。リクエストがないポッドは、ポッドのワークロードを実行できる十分なメモリがないノード上でもスケジュール可能です。リクエストの値が小さすぎると、多すぎるポッドや、不十分な組み合わせのポッドが特定のノード上でスケジュールされ、パフォーマンスが低下する可能性があります。リクエストの値が大きすぎると、ポッドがスケジューリング不能になり、クラスタのリソースのコストが増加する可能性があります。ポッドにリソースを設定せずに(もしくはポッドのリソース設定に加えて)、ポッド内で実行される個々のコンテナにリソースを指定することもできます。コンテナにのみリソースを指定する場合、ポッドのリクエストは、各コンテナに指定されたリクエストの合計になります。リクエストを超えないようにする必要があります。リクエストの構成を行うことを強くおすすめします。リクエストと制限をご覧ください。メモリの量に制限をかけることができます。メモリの最大量を意味します。ポッドの制限を設定せずに(もしくはポッドの制限に加えて)、ポッド内で実行される個々のコンテナに制限をかけることもできます。コンテナにのみ制限をかける場合、ポッドの制限は、各コンテナにかけられた制限の合計になります。各コンテナはその制限の最大値までしかリソースにアクセスできないので、コンテナだけに制限をかける場合は、各コンテナの制限を指定する必要があります。両方を指定した場合は、すべてのコンテナの制限の合計がポッド制限を超えないようにする必要があります。制限は、同じタイプのリソースに対するリクエストと同じまたはそれ以上でなければなりません。制限をリクエストよりも低い値に設定しようとすると、ポッドのコンテナは実行されず、エラーがログに記録されます。ポッドのスケジューリングの際には制限が考慮されませんが、制限をかけることで、同じノード上のポッド間でのリソース競合を防ぐことができます。システムをポッドが枯渇させてノードのシステムが不安定になることを防げます。リクエストとは異なります。両者は連動して機能します。実際のワークロードの要件に基づいて、ポッドの制限を構成することを強くおすすめします。リクエストと制限をご覧ください。フィールドが含まれています。テンプレートには、ポッド内でどのコンテナを実行するか、ポッドでどのボリュームをマウントするかなど、各ポッドの実行方法を決定するポッド仕様が含まれます。テンプレートを使用してポッドを作成し、クラスタ内の「目的の状態」を管理します。テンプレートが変更されると、新しいテンプレートはその後のすべてのポッドに反映されますが、既存のポッドには反映されません。ノードプール内のノードで実行されます。次のようにして、ポッドが選択するノードプールを明示的または暗黙的に構成できます。設定すると、そのポッドを特定のノードプールにデプロイするよう明示的に指定できます。することで、ポッドはそのノードプール内のノードでのみ実行されるようになります。リクエストを指定できます。リクエストを満たすノードでのみ実行されます。持つノード上で動作するポッドを選択しません。つの使用方法があります。単一コンテナを実行するポッド。つのコンテナがアプリケーション全体を表します。この場合は、ポッドをラッパーと考えることができます。連携して動作する必要がある複数のコンテナを実行するポッド。複数のコンテナを含むポッドの主な使用目的は、リソースを共有する必要があり、同じ場所に配置され、共同で管理されるプログラムをサポートすることです。つのまとまったサービス単位を形成できます。あるコンテナが共有ボリュームからファイルを提供し、別のコンテナがそれらのファイルを更新できます。つの管理可能なエンティティにまとめます。個々のポッドは、特定のアプリケーションの単一インスタンスを実行するためのものです。つのポッドを使用する必要があります。これを一般に「複製」と呼びます。つのグループとして作成され、管理されます。ポッドの終了ポッドは、自身のプロセスが完了すると正常に終了します。秒が指定されています。フラグで設定することで、この正常終了時間をオーバーライドできます。ネットワークの概要を読む。ドキュメントの「ポッドの概要」を読む。ポッドのライフサイクルを理解する。ポッドの詳細を確認する。コントローラの詳細を確認する。コントローラの詳細を確認する。