これらのKubernetes Podスキルを習得し、企業にとって必須のスキルになりましょう

Kubernetes Pod とは何ですか?

Kubernetes Pod は、Kubernetes アプリケーションの基本的な実行単位です。これは、1 つ以上のアプリケーション コンテナーと共有ストレージ/ネットワーク リソースをカプセル化し、アプリケーションが実行される独自の環境と考えることができます。 Kubernetes には、サービス、エンドポイント、その他のエンティティをカプセル化する多くの概念がありますが、最終的には Pod がコードが実行される場所です。

Kubernetes Podとコンテナの違い

概念的には、Pod は Docker Compose のコンテナに相当します。 Docker Compose と比較すると、Kubernetes における Pod は Docker Compose におけるコンテナと同じ役割を果たしますが、Pod は実際には、関連付けられたネットワークおよびストレージ構成を持つ 1 つ以上のコンテナの抽象化です。 Pod には複数のコンテナを含めることができますが、ベスト プラクティスとしては、アプリケーション コードを実行するメイン コンテナと、追加のアプリケーション機能 (ログ記録、監視、ネットワークなど) を提供する 0 個以上のサポート コンテナを用意することが推奨されます。このアプローチはサイドカーと呼ばれ、これらのサポート コンテナーはサイドカー コンテナーと呼ばれます。

Kubernetes ポッドとノードの違い

ノードは Kubernetes のワーカーであり、ポッドはノード上で実行されます。ノードは、AWS EC2 インスタンスなどの仮想ノード、または物理コンピュータ サーバーにすることができます。ポッドはノードに割り当てられ、それらのノード上で実行され、ノードがクラスターに提供する容量を消費します。ポッドはノードに明示的にバインドされません。これらは Kubernetes コントロール プレーンによって割り当てられ、必要に応じてノード間で移動できます。

Kubernetes ポッドとクラスターの違い

クラスターは基本的に、容量を提供するノードのセット、アプリケーションを実行するポッドのセット、およびその他の構成 (サービスやイングレス コントローラーなど) であり、すべて Kubernetes コントロール プレーンによって管理されます。概念的には、Pod は Kubernetes によるアプリケーションの実行方法と考えることができます。

Kubernetes ポッドの仕組み

Pod は、メイン コンテナ (コードを実行するコンテナ) と、0 個以上のサポート コンテナまたはサイドカー コンテナの上にある抽象化レイヤーです。コンテナに加えて、ポッドには Kubernetes クラスター内の ID といくつかの構成もあります。

ポッドのライフサイクル

Pod はライフサイクルにおいていくつかの段階を経ます。

• 保留中: システムはポッドを受け入れましたが、1 つ以上のコンテナーがまだセットアップされておらず、実行されていません。
• 実行中: ポッドはノードにバインドされ、そのコンテナはすべて作成されました。
• 成功: ポッド内のすべてのコンテナが正常に終了し、再起動されません。ポッドはノードにバインドされなくなり、リソースを消費します。
• 失敗: ポッド内の少なくとも 1 つのコンテナが失敗状態で終了しました。ポッドはノードにバインドされなくなり、リソースを消費します。
• 不明: Pod ホスト ノードとの通信の問題によりステータスが不明な場合。ノードが Kubernetes コントロール プレーンにステータスを報告できない場合、そのノードで実行されているポッドは不明状態になります。

ポッドが複数のコンテナを管理する方法

Pod は複数のコンテナをカプセル化して、同じストレージとネットワーク名前空間を共有するようにすることができます。これにより、アプリケーション ヘルパー プロセスとメイン アプリケーションを、それらの間のネットワーク構成を処理することなく結合できるようになります。同じポッド内で実行されているコンテナは、ローカル ネットワークとストレージを共有します。これは通常、ログ記録、監視、ネットワーク構成などのサイドカー コンテナーに使用されます。たとえば、複数のコンテナを持つ Pod を構成するには、次のようにします。

 apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: ['sh', '-c', 'echo The app is running! && sleep 3600'] - name: log-container image: busybox command: ['sh', '-c', 'tail -f /dev/null']

これにより、Pod 内で 2 つのコンテナが実行されます。1 つはアプリケーションを実行し、もう 1 つはログ記録用です。ネットワークとファイルシステムを共有します。これがポッドの力です。

Kubernetes でのポッドの使用

Kubernetes は複雑なプラットフォームであり、本番環境のワークロードを実行するには、コンテナを含む Pod を定義する以上の知識が必要です。 Pod を効果的に管理するために理解する必要がある追加のポイントをいくつか示します。

ポッドの更新と交換

実行中の Pod を直接更新することは、Pod の不変性の仮定 (基本的にはコンテナの不変性と同じ) に違反するため、良い方法ではありません。実際、Kubernetes は Pod レベルでこの不変性を強制し、Pod への更新を拒否します。代わりに、新しいバージョンの Pod をデプロイし、トラフィックを新しいバージョンにスムーズにリダイレクトする必要があります。このデプロイメントが段階的に実行され、一度に 1 つの Pod が置き換えられる場合 (同じアプリケーションに対して複数の Pod を実行する場合に該当)、これはローリング アップデートと呼ばれます。まったく新しい Pod セットをデプロイし、トラフィックをそれらにリダイレクトし、それらが正しく動作していることを確認してから、古い Pod を終了する場合、これはブルーグリーン デプロイと呼ばれます。

一連の Pod を含む Deployment を作成するときに、更新戦略を定義できます。たとえば、ローリング アップデート戦略を定義する方法は次のとおりです。

 apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deployment spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: ...

これにより、利用可能なポッドの数を少なくとも 2 に保ちながら、ポッドが 1 つずつ段階的に更新されます。

ポッドリソース制限

ポッドがノード リソースを過剰に消費するのを防ぐために、ポッドに対して CPU とメモリの要求と制限を定義することができます。例えば：

 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

これにより、64 MB のメモリと 0.25 個の CPU コアが要求され、128 MB のメモリと 0.5 個の CPU コアに制限されます。これらの概念を理解することで、本番環境で Pod を安全かつ確実に実行できるようになります。

Kubernetes のポッドストレージ

ポッドには、作業メモリを通じて実装される一時的なストレージのみがあります。永続ボリュームを使用して永続ストレージを作成し、永続ボリューム要求を通じてそれをポッドに関連付けることができます。概念的には、永続ボリュームはノードに似ています。永続ボリュームは、基盤となるリソース (この場合はコンピューティングではなくストレージ) を Kubernetes クラスターで利用できるようにします。永続ボリューム要求は、これらの利用可能なリソースをポッド用に予約し、ポッドに関連付けます。これらの永続ボリューム要求は、ポッド内のコンテナにボリュームとして接続し、コンテナのローカル ファイル システムの一部としてアクセスできます。

重要なのは、これらを Pod 内のすべてのコンテナで共有できるため、同じ Pod 内のコンテナ間でファイルベースの通信が可能になることです。ログサイドカーコンテナは通常、このアプローチを使用してメインコンテナからログを読み取り、AWS CloudWatch Logs などの外部ログアグリゲータにエクスポートします。

永続ボリューム要求を定義し、それをボリュームとしてポッド内のコンテナに関連付ける方法は次のとおりです。

 apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: busybox command: ['sh', '-c', 'echo Hello Kubernetes! > /mnt/vol1/hello-file'] volumeMounts: - mountPath: /mnt/vol1 name: vol1 volumes: - name: vol1 persistentVolumeClaim: claimName: my-pvc

これにより、PVC my-pvc が /mnt/vol1 にマウントされ、コンテナーはファイルを読み書きできるようになります。永続ボリュームを使用すると、ポッドを再起動してもデータが失われないことが保証されます。

ポッドネットワーク

各ポッドにはクラスター全体で一意の IP アドレスが割り当てられ、クラスター内からアクセスできます。また、サービスも定義できます。これにより、同種の Pod (通常はデプロイメント) のグループを単一の IP アドレスまたはプライベート DNS 名でアドレス指定し、それらの Pod 間でトラフィックを負荷分散できるようになります。 Ingress を定義して、Ingress Controller を介してクラスター外部にサービスを公開することもできます。ポッドは、追加のネットワーク構成を必要とせずに、デフォルトで相互に通信できます。ただし、場合によっては、Pod ネットワークをさらに分離する必要があることもあります。これは、ラベルセレクターに基づいてポッド間のトラフィックを制御できる Kubernetes ネットワークポリシーを使用して実現できます。

たとえば、次のネットワーク ポリシーでは、role=frontend の Pod のみが role=backend の Pod にアクセスできます。

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: backend-policy spec: podSelector: matchLabels: role: backend ingress: - from: - podSelector: matchLabels: role: frontend

Kubernetes でネットワークベースのアプリケーションを実行するには、Pod ネットワークを理解することが重要です。主流のネットワーク モデルには、Flannel、Calico、Cilium などがあります。

要約する

Kubernetes は非常に強力なプラットフォームですが、その強力さには膨大な複雑さが伴います。ポッドは単なる出発点に過ぎませんが、Kubernetes がポッド上で本番環境レベルのワークロードを展開するために使用する抽象化と構成を習得するには、ポッドの動作を理解することが不可欠です。

ポッドのライフサイクル、複数のコンテナの管理方法、ストレージ、リソース制限など、ポッドの基本を理解することは、Kubernetes の使用を開始するための重要な第一歩です。基本を理解すれば、Kubernetes が提供するサービス検出、負荷分散、ローリング アップデートなどの高度な機能を活用して、より複雑なアプリケーション デプロイメントを構築できます。