k8s_clearily_series② Pod
kubernetesついて明瞭に説明していく「k8s_clearily_series」の二回目になります。
第二回目はkubernetesの基本リソースとなる「Pod」の機能について7つの観点から詳細な説明をさせていただきます。
1.Podについて
2.Podに内包されるコンテナ数
3.Podにおけるコンテナの再生成
4.Podの短寿命
5.Podの共有ストレージ
6.Podのネットワーク
7.Podのリソースコントローラー
1.Podについて
Podはkubernetesにおいて、基本となるリソースであり中核を担う概念になるため、kubernetesを理解する上では必須になります。
ではkubernetesにおけるPodとはなにか?
Podが持っている意味はコンテナの管理単位を表す用語と言われております。その用語がもつ裏付けからひも解くとPod≠コンテナではありません。
その内容を踏まえた上でPodをわかりやすく表現するなら、「コンテナが内包されている箱」と認識していただくことが一番わかりやすいと思われます。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_01-3-1024x301.png)
では事項からはPodの詳細について、お話をさせていただきます。
2.Podに内包されるコンテナの数
Podは内包するコンテナの数によって2つの使用ケースに分類されます。
①最小のデプロイ単位としての使用
Podに1つのコンテナを内包し、アプリケーションコンテナの実行を行うケース
②コンテナ間の共有
Podに2つ以上のコンテナを内包し、アプリケーションコンテナとログ or プロキシコンテナの実行を行うケース
①はkubernetesを最も一般的な「1つのPodを1つのコンテナ」で利用する方法となり、単一で実行することができるアプリケーションコンテナを内包されるケースになります。
②は「アプリケーションコンテナ」と「ログor プロキシコンテナ」を連携して利用する場合に、Podに2つ以上のコンテナを内包して、1つの論理的なホストをPod上に構築するケースになります。
この利用方法は「サイドカーコンテナ」とも言われており、「アプリケーションコンテナ」と「ログ or プロキシコンテナ」はPod内で2つのコンテナ間の共有を行っているので、相互通信をPod内で行うことが可能となります。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_02-3-1024x267.png)
3.Podにおけるコンテナの再生成
kubernetesではPod内のコンテナが異常終了したかどうかを定期的に監視しております。そのためPod内のコンテナアプリケーションに異常終了が検出された場合、同じコンテナイメージを使用して作成を行います。このため再生成されたコンテナにはアプリケーションの状態が一貫されていることになります。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_03-1.png)
4.Podの短寿命
kubernetesのPodはアプリケーションのデプロイやスケーリング、障害対応を効率的に行うために短寿命という概念を持っております。
Podはその中に内包されるコンテナの容量が少ないため、新規のPod作成が素早く容易に行うことが可能となります。これはkubernetesがアプリケーションのコンポーネントを効果的に管理し、障害への対応やスケーリングを簡略化するためになります。こうした短寿命の設計概念を持っていることで下記のような特徴がございます。
- アプリケーションの可用性
Podの再作成が素早く容易であるため、障害が発生した際もアプリケーションコンテナのダウンタイムを最小限にすることが可能である。
- スケーリング
コンテナアプリケーションの負荷に合わせて、Podの素早い増減が可能である。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_04-12.png)
- リソースの最適化
Podの容量が少なく短命であることを前提に設計されているため、不要なリソースをNode内に占有することがなくなるので、kubernetesのリソースを効率的に利用することが可能である。 - コンテナの独立性
Podに内包されているコンテナは独立しての動作ができるため、Podにて構成されるコンテナアプリケーション群の一部を異なる速度で更新、再生成が可能である。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_04-34-1.png)
5.Podの共有ストレージ
kubernetesでは、Pod内にあるコンテナ間またはPod同士で共有ストレージを使用することが可能となります。共有ストレージを利用することで、異なるコンテナが同じPod内でデータをやり取りしたり、データを永続化することも可能となります。3つの共有ストレージについて説明をさせていただきます。
- EmptyDir
Pod内にあるコンテナのデータを一時的に共有するストレージになります。Podが削除されるとデータも削除され、Pod間でのデータ共有はできません。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_05-1-3-1024x763.png)
- HostPath
kubernetesのNodeにスケジューリングされたPod間でデータの共有を行うストレージになります。永続性がありますが、スケジューリングされたNode内でしかデータの共有はできません。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_05-2-3.png)
- PersistentVolume(PV)とPersistentVolmeClaim(PVC)
kubernetesクラスターのNode間にスケジューリングされたPod間でデータの共有を行うストレージになります。永続性があり、外部にあるストレージ(パブリッククラウドのストレージサービスなど)と連携することが可能となります。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_05-3-6-1024x481.png)
6.Podのネットワーク
kubernetesのPodにおけるネットワーキングは、kubernetes内におけるコンテナ間の通信および外部への通信を管理し、セキュリティに加え可用性、スケーリングなどの要件を満たすために必要なものになります。
Podのネットワークを構成する概念として下記一覧がございます。
- IPアドレス
kubernetesクラスター内でPodは重複のない固有のIPアドレスを割り当てられているため、クラスター内で他のPodとの通信が可能となります。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_06-1-1.png)
- Podネットワーク
kubernetesクラスター内では、Podが配置されるネットワークが存在します。Podネットワークはkubernetesクラスター全体で一様なCIDR(Classless Inter-Domain Routing)ブロックで構成されます。クラスター内にある各NodeはこのCIDRブロックからサブネットに割り当ててPodにIPアドレスを提供します。結果、Pod間で通信を行うことが可能となります。このCIDRブロックはデフォルトで決められておりますが、変更を行うことも可能です。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_06-2-2.png)
- 動的IPアドレスの割り当て
kubernetesではPodにIPアドレスを動的に割り当てるのが一般的になり、IPアドレスの管理はkubernetesによって自動化されます。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_06-3-1.png)
- 補足事項
IPアドレスの個所でPodとコンテナは同じIPアドレスであることを記載させていただきました。Podの中に複数のコンテナが入っているケースの場合はコンテナにport番号を割り当てて、Pod内にあるコンテナにアクセスできるように設定を行います。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_06-4-2.png)
7.Podのリソースコントローラー
Podはリソースコントローラーによって特定のPodの状態を維持し、必要に応じてPodの作成、スケールアップ、スケールダウン、再生成する役割を果たします。リソースコントローラーごとの役割を下記に記載いたします。
- ReplicaSet(レプリカセット)
ReplicaSetは指定されたレプリカ数のPodが実行されていることを保証するためのリソースコントローラーです。ReplicaSet単体で操作することは稀であり、Deploymentの基盤として機能するものになります。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_07-1.png)
- Deployment(デプロイメント)
kubernetesクラスター内で、アプリケーションのデプロイメントとスケーリングを定義された状態を維持するためのリソースコントローラーになります。ReplicaSetが基盤として機能しているので、定義されたレプリカ数のPodの維持や過負荷によるスケーリング、新しいバージョンによるアプリケーションのローリングアップデートもサポートされております。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_07-2-1-3-872x1024.png)
- DaemonSet(デーモンセット)
DaemonSetは、クラスタ内にあるすべてのNodeでPodを実行するためのリソースコントローラーになります。NodeにスケジューリングできるPodの数はNodeに対して1つのみとなります。
主な使用方法は、ログやセキュリティの情報を収集するためにエージェントを各Nodeにインストールする際に使用するリソースコントローラーになります。
![](https://i-study.jp/blog/wp-content/uploads/sites/2/2023/09/pod_07-3-1-1024x600.png)
まとめ
KubernetesのPodは単一の管理単位として扱う最小のものであることがお分かりいただけると思います。kubernetesはこのPodをリソースコントローラーでレプリカの数や負荷などのコントロールを行ったり、状況に応じた共有ストレージの使い分けたり、Podに複数のコンテナを内包してコンテナアプリケーションのログやプロキシに使用したりとPodを元に様々な使い分けを行うことが可能となります。
基本的なPodの概要がお分かりいただけたところで、次回はkubernetesのクラスターやNode、コントロールプレーンなどのコンポーネントについてお話をさせていただきます。