# Pod

> For AI agents: the complete glossary index is at [llms.txt](https://glossary.cncf.io/ja/llms.txt).
> Markdown versions of every glossary page are available by appending `index.md` to the page URL.

[Kubernetes](https://glossary.cncf.io/ja/kubernetes/)環境の中では、Podは最も基本的なデプロイ可能ユニットとして機能します。
これはコンテナ化されたアプリケーションをデプロイし、管理するための基本的な構成要素を表しています。
各Podには単一のアプリケーションインスタンスが含まれ、一つ以上の[コンテナ](https://glossary.cncf.io/ja/container/)を保持することができます。
Kubernetesは、より大規模なDeploymentの一部としてPodを管理し、必要に応じてPodを[垂直スケーリング](https://glossary.cncf.io/ja/vertical-scaling/)または[水平スケーリング](https://glossary.cncf.io/ja/horizontal-scaling/)することができます。

## 解決すべき問題はなんですか

コンテナは一般的に、特定のワークロードを実行し制御する独立した単位として機能しますが、コンテナが密接に相互作用し、適切に連携して制御される必要がある場合もあります。

これらの密接に関連するコンテナがそれぞれ個別に管理される場合、冗長な管理作業が発生します。
たとえば、オペレーターは関連するコンテナの配置を繰り返し判断し、それらが一緒に保たれるようにしなければなりません。
また、これらの関連するコンテナのライフサイクルは同期される必要がありますが、個別にしか管理できません。

## どのように役に立つのでしょうか

Podは密接に関連するコンテナを単一のユニットにまとめることで、コンテナ操作を大幅に簡素化します。
たとえば、補助的なコンテナは、追加機能を提供したり、グローバルな設定を行うために主コンテナと一緒に使用されることがよくあります。
これには、基本設定を主コンテナに注入して適用するコンテナ、 _sidecar_ (コンテナ)であり、主コンテナのためのネットワークトラフィックルーティングを処理する([サービスメッシュ](https://glossary.cncf.io/ja/service-mesh/)を参照)、あるいは各コンテナと連動してログを収集するコンテナなどが含まれます。

メモリとCPUの割り当ては、Podレベルで定義することも、コンテナごとに定義することもできます。
Podレベルで定義すると、内部のコンテナがリソースを柔軟に共有できます。

---

- Canonical URL: https://glossary.cncf.io/ja/pod/
- Status: Completed
- 最終更新日 April 12, 2024: ` [ja] Correct the notation of the word "infrastructure" (#3045) ` ([e8aa8c5](https://github.com/cncf/glossary/commit/e8aa8c59e07935c67d70451ea42b80f509f7b7ff))
- Source: https://github.com/cncf/glossary/blob/main/content/ja/pod.md
- License: [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)