【ITニュース解説】🚀 Pods no Kubernetes (com 2 containers no mesmo Pod):

現代のシステム開発において、アプリケーションの安定稼働と効率的な管理は非常に重要であり、その中心的な役割を担う技術の一つがKubernetesである。Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための強力なプラットフォームとして広く利用されている。本記事では、Kubernetesの最も基本的な構成要素であるPodと、その周辺の重要な概念について解説する。

まず、Podとは何か。PodはKubernetesにおける最小のデプロイ可能な単位である。これは、私たちが実際にコンテナを配置し、実行する「箱」のようなものだと考えると良い。一つのPodは、一つまたは複数のコンテナを含むことができる。コンテナは、アプリケーションの実行に必要なコード、ライブラリ、依存関係などをすべてパッケージ化した軽量な独立した実行環境である。

同じPod内に複数のコンテナが配置される場合、これらのコンテナはいくつかの重要なリソースを共有する。最も重要なのが「ネットワーク名前空間」の共有だ。これは、同じPod内のすべてのコンテナが同じIPアドレスを共有することを意味する。つまり、Podがネットワーク上で持つIPアドレスは一つであり、Pod内のコンテナはそのIPアドレスを共有して通信する。また、localhostを通じてお互いに通信することも可能になる。ただし、IPアドレスが同じであるため、外部からそれぞれのコンテナにアクセスさせる場合は、異なるポート番号を使用する必要がある。加えて、Pod内のコンテナは、設定に応じて永続的なストレージである「ボリューム」も共有できる。

実際の運用環境では、Podを直接作成することはほとんどない。代わりに「Deployment」というリソースを通じてPodを管理する。Deploymentは、指定された数のPodを常に稼働させ、自動的なスケーリングや自己修復機能を提供する。Deploymentを作成すると、それが「ReplicaSet」を作成し、ReplicaSetが最終的にPodを作成し、管理する流れとなる。これにより、アプリケーションの可用性が高まり、管理の手間が大幅に削減される。

クライアントからのリクエストが、Kubernetes上で稼働するアプリケーションのPodに届くまでの流れを見てみよう。まず、クライアントからのリクエストは、DNS解決やホスト名解決を経て、公開されているIPアドレス、例えばロードバランサ（Ingress-nginxのロードバランサなど）に到達する。このロードバランサが、Ingress-nginxのPod（Nginxサーバー）にトラフィックを転送する。Ingressは、リクエストのホスト名やパスといった情報に基づいて、どのサービスにトラフィックをルーティングするかを決定する役割を担う。

Ingressがルーティング先を決定した後、その情報に基づいて「Service」にトラフィックを渡す。Serviceは、Kubernetesクラスター内のPodに対して、一貫したアクセスポイントを提供する。これは、まるでアプリケーションへの「固定電話番号」のようなものだ。Serviceは、設定されたラベル（Podに付与された目印）を使って、どのPodがそのサービスを提供するべきかを識別し、トラフィックを適切なPodのIPアドレスとポート（PodIP:targetPort）に転送する。Serviceはロードバランサーとしての機能も持ち、複数のPod間でトラフィックを均等に分散する。こうして、最終的にリクエストは目的のPod内のコンテナへと到達するのである。

Kubernetesには「Namespace」という概念もあり、これはリソースを論理的に分離する機能を提供する。例えば、開発環境と本番環境で同じ名前のAPIをデプロイしたい場合、それぞれ異なるNamespaceに配置することで、名前の衝突を避けることができる。Namespaceは、リソースの分離だけでなく、アクセス制御（RBAC）、リソースの割り当て制限（クォータ）、ネットワークポリシーの適用など、セキュリティと管理の面で非常に重要な役割を果たす。また、Namespaceを削除すると、そのNamespace内に存在するすべてのリソースが同時に削除されるため、環境の一括削除なども容易になる。

ここで、実際に一つのPod内に二つのAPIコンテナを配置する例を見てみよう。ここではapi3aとapi3bという二つのAPIを同じPodで動かすことを想定する。Deploymentの定義では、spec.containersセクション内に、それぞれのAPIに対応するコンテナ設定を記述する。

Copy
1 apiVersion: apps/v1
2 kind: Deployment
3 metadata:
4 name: api3
5 namespace: prod
6 spec:
7 replicas: 1
8 selector:
9 matchLabels: { app: api3 }
10 template:
11 metadata:
12 labels:
13 app: api3
14 svc-api3a: "true"
15 svc-api3b: "true"
16 spec:
17 containers:
18 # api3aコンテナの設定
19 name: api3a
20 image: https://suaiamgem # あなたのコンテナイメージ
21 ports: [{ name: http-api3a, containerPort: 8080 }] # ポート8080で公開
22 env: [{ name: ASPNETCORE_URLS, value: http://+:8080 }] # 環境変数でAPIのURLを設定
23 readinessProbe: { httpGet: { path: "/", port: 8080 }, initialDelaySeconds: 5, periodSeconds: 10 } # コンテナの準備完了状態をチェック
24 livenessProbe: { httpGet: { path: "/", port: 8080 }, initialDelaySeconds: 10, periodSeconds: 20 } # コンテナの生存状態をチェック
25 # api3bコンテナの設定
26 name: api3b
27 image: https://suaimagem # あなたのコンテナイメージ
28 ports: [{ name: http-api3b, containerPort: 8081 }] # ポート8081で公開
29 env: [{ name: ASPNETCORE_URLS, value: http://+:8081 }] # 環境変数でAPIのURLを設定
30 readinessProbe: { httpGet: { path: "/", port: 8081 }, initialDelaySeconds: 5, periodSeconds: 10 } # コンテナの準備完了状態をチェック
31 livenessProbe: { httpGet: { path: "/", port: 8081 }, initialDelaySeconds: 10, periodSeconds: 20 } # コンテナの生存状態をチェック

この例では、api3aはポート8080を、api3bはポート8081を使用している。先述の通り、同じPod内のコンテナは同じIPアドレスを共有するため、外部からのアクセスを受ける際は、それぞれのコンテナが異なるポート番号を持つ必要がある。readinessProbeとlivenessProbeは、それぞれコンテナがリクエストを受け入れられる状態にあるか（準備完了状態）、そしてコンテナ自体が正常に動作しているか（生存状態）をKubernetesが定期的にチェックするための設定である。これにより、不健全なコンテナへのトラフィック転送を防ぎ、問題のあるコンテナを自動的に再起動させることが可能になる。また、template.metadata.labelsにsvc-api3a: "true"やsvc-api3b: "true"といったラベルが付与されているが、これはServiceがこれらのラベルを使って特定のPodを見つけ出し、ルーティングを行うための目印となる。

このように、KubernetesのPodはコンテナ化されたアプリケーションの実行基盤であり、Deployment、Service、Ingress、Namespaceといった多様なリソースと連携することで、複雑なシステムを効率的かつ堅牢に運用することを可能にする。これらの概念を理解することは、現代のクラウドネイティブなシステム開発において、システムエンジニアを目指す上で不可欠な第一歩となるだろう。