ポイント: Kubernetesポッドは、リソースを共有する1つ以上のコンテナをカプセル化した最小のデプロイ可能ユニットです。このガイドでは、ポッドのタイプ、ライフサイクルのフェーズ、単一およびマルチコンテナポッドのYAMLマニフェスト例を使用したデプロイ方法をカバーします。
- Kubernetesポッドは、コンテナ化されたアプリケーションを効果的に管理します。
- ポッドは、ネットワークおよびストレージリソースを共有する複数の密結合されたコンテナを含むことができます。
この記事では、Kubernetesのポッド、ユースケース、ライフサイクル、およびアプリケーションをデプロイするためのポッドの使用方法について説明します。
この投稿は、Kubernetesの目的を理解し、minikubeおよびkubectlがインストールされていることを前提としています。
K8sポッドとは？
Kubernetesのオブジェクトモデルの中で、ポッドは最小のビルディングブロックです。クラスター内では、ポッドは実行中のプロセスを表します。ポッド内には1つ以上のコンテナが含まれることがあります。同じポッド内のものは以下を共有します：
- ユニークなネットワークIP
- ネットワーク
- ストレージ
- ポッドに適用した追加の仕様
ポッドを考える別の方法は、アプリケーションに特化した「論理ホスト」であり、1つ以上の密結合されたコンテナを保持しています。たとえば、ポッドにapp-containerとlogging-containerがあるとします。logging-containerの唯一の仕事は、app-containerからログを取得することです。ポッド内にコンテナを配置することで、余分な通信設定が不要になり、すべてがローカルでリソースを共有します。これは、コンテナなしの世界で同じ物理サーバー上で実行するのと同じことです。
もちろん、ポッドに関して他にも行うことがあります。たとえば、第二のコンテナを初期化するinit containerを持つことがあります。二番目のコンテナが起動してサービスを提供すると、最初のコンテナは停止します。その仕事は完了です。
ポッドモデルのタイプ
作成できるポッドのモデルタイプは2つあります：
- 1ポッドあたり1コンテナ。 このモデルが最も一般的です。ポッドは単一のコンテナの「ラッパー」です。ポッドはK8Sが認識する最小のオブジェクトであるため、コンテナを直接管理するのではなく、ポッドを管理します。
- マルチコンテナポッド。 このモデルでは、ポッドはリソースを共有するために密結合された複数のコンテナを保持できます。これらのコンテナは、サービスの単一の一貫したユニットとして機能します。ポッドはこれらの複数のコンテナをストレージリソースと共に単一のユニットにラップします。例としては、サイドカー、プロキシ、ロギングがあります。
各ポッドはアプリケーションの単一のインスタンスを実行します。アプリを水平にスケールする必要がある場合（たとえば、複数のレプリカを実行するなど）、インスタンスごとにポッドを使用できます。これは、単一のポッド内で同じアプリの複数のコンテナを実行することとは異なります。
ポッドは耐久性のあるエンティティとして意図されていないことを言及する価値があります。ノードが失敗した場合やノードを維持している場合、ポッドは生き残りません。この問題を解決するために、K8Sはコントローラーを持っています。通常、ポッドはコントローラーのタイプで作成できます。
ポッドライフサイクルのフェーズ
ポッドのステータスは、ライフサイクルのどの段階にあるかを教えてくれます。これは、確実なものではないため、ポッドが正常に立ち上がらない場合はデバッグするのが良いプラクティスです。ポッドライフサイクルの5つのフェーズは次のとおりです：
- 保留中。 ポッドは受け入れられましたが、少なくとも1つのコンテナイメージが作成されていません。
- 実行中。 ポッドはノードにバインドされており、すべてのコンテナが作成されています。1つのコンテナが実行中または起動中または再起動中です。
- 成功。 ポッド内のすべてのコンテナが正常に終了し、再起動しません。
- 失敗。 すべてのコンテナが終了し、少なくとも1つのコンテナが失敗しました。失敗したコンテナは非ゼロステータスで終了しました。
- 不明。 ポッドの状態を取得できませんでした。
実践におけるポッド
ポッドが理論上何であるかについて話しましたが、次に実践でのポッドの姿を見てみましょう。まずシンプルなポッドマニフェストを確認し、その後、どのように作業するかを示す例アプリをデプロイします。
マニフェスト（YAML）
マニフェストを4つの部分に分解します：
- ApiVersion – 使用しているKubernetes APIのバージョン
- Kind – 作成したいオブジェクトの種類
- Metadata – 名前や名前空間など、オブジェクトを一意に識別する情報。
- Spec – たとえば、イメージ名、コンテナ名、ボリュームなど、ポッドの指定された構成。
ApiVersion、kind、metadataは、ポッドだけでなくすべてのKubernetesオブジェクトに適用される必須フィールドです。specのレイアウトも必須であり、オブジェクトによって異なります。上記の例のマニフェストは、単一コンテナポッドのspecがどのようになるかを示しています。
単一コンテナポッド
apiVersion: "api version" (1)
kind: "object to create" (2)
Metadata: (3)
Name: "Pod name"
labels:
App: "label value"
Spec: (4)
containers:
- name: "container name"
image: "image to use for container"
さて、マニフェストがどのように見えるかを理解したので、ポッドを作成するための両方のモデルを示します。
私たちのpod-1.yamlは、単一コンテナポッドのマニフェストです。これは、何かをエコーするnginxポッドを実行します。
apiVersion: v1
kind: Pod
metadata:
name: firstpod
labels:
app: myapp
spec:
containers:
- name: my-first-pod
image: nginx
次に、Kubectl create -f pod-1.yamlを実行して、このマニフェストをローカルKubernetesクラスターにデプロイします。その後、kubectl get podsを実行して、ポッドが期待通りに実行されていることを確認します。
kubectl get pod
NAME READY STATUS RESTARTS AGE
firstpod 1/1 Running 0 45s
現在、実行中です！実行されていることを確認するために、kubectl exec firstpod—kubeconfig=kubeconfig — service nginx statusを実行します。これは、— service nginx statusを渡すことで、ポッド内でコマンドを実行します。（注：これはdocker execを実行するのに似ています。）
kubectl exec firstpod — service nginx status
nginx is running.
さて、kubectl delete pod firstpodを実行してクリーンアップします。
kubectl delete pod firstpod
pod "firstpod" deleted
マルチコンテナマニフェスト
この例では、より有用なものをデプロイします：単一のエンティティとして機能する複数のコンテナを持つポッドです。1つのコンテナが10秒ごとに現在の日付をファイルに書き込み、もう1つのコンテナがログを提供します。
pod-2.yamlマニフェストをkubectl create -f pod-2.yamlでデプロイしてください。
apiVersion: v1
kind: Pod
metadata:
name: multi-container-pod # Name of our pod
spec:
volumes:
- name: shared-date-logs # Creating a shared volume for my containers
emptyDir: {}
containers:
- name: container-writing-dates # Name of first container
image: alpine # Image to use for first container
command: ["/bin/sh"]
args: ["-c", "while true; do date >> /var/log/output.txt; sleep 10;done"] # writing date every 10secs
volumeMounts:
- name: shared-date-logs
mountPath: /var/log # Mounting log dir so app can write to it.
- name: container-serving-dates # Name of second container
image: nginx:1.7.9 # Image for second container
ports:
- containerPort: 80 # Defining what port to use.
volumeMounts:
- name: shared-date-logs
mountPath: /usr/share/nginx/html # Where nginx will serve the written file
ポッド内のボリュームについて少し触れる価値があります。上記の例では、ボリュームはポッドのライフサイクル中にコンテナが通信する方法を提供します。ポッドが削除され再作成されると、共有ボリュームに保存されたデータは失われます。この問題を解決するために、永続ボリュームオブジェクトが存在し、データがポッドの損失を超えて存在するようにします。このマルチコンテナの例は、2つのコンテナポッドを作成する方法を示すだけでなく、両方のコンテナがリソースを共有する方法を示しています。
kubectl create -f pod-2.yaml
pod "multi-container-pod" created
それから、本当にデプロイされたことを確認します。
kubectl get pod --kubeconfig=kubeconfig
NAME READY STATUS RESTARTS AGE
multi-container-pod 2/2 Running 0 1m
素晴らしい！実行中です。今、期待通りに動作していることを確認しましょう。2つのコンテナがポッドにあることを確認するためにkubectl describe pod “pod name”を実行します。このコマンドは、作成されたオブジェクトの様子を示します。
Containers:
container-writing-dates:
Container ID: docker://e5274fb901cf276ed5d94b625b36f240e3ca7f1a89cbe74b3c492347e98c7a5b
Image: alpine
Image ID: docker-pullable://alpine@sha256:621c2f39f8133acb8e64023a94dbdf0d5ca81896102b9e57c0dc184cadaf5528
Port:
Host Port:
Command:
/bin/sh
Args:
-c
while true; do date >> /var/log/output.txt; sleep 10;done
State: Running
Started: Fri, 16 Nov 2018 11:31:44 -0700
Ready: True
Restart Count: 0
Environment:
Mounts:
/var/log from shared-date-logs (rw)
/var/run/secrets/Kubernetes.io/serviceaccount from default-token-8dl5j (ro)
container-serving-dates:
Container ID: docker://f9c85f3fe398c3197644fb117dc1681635268903b3bba43aa0a1d151fab6ad22
Image: nginx:1.7.9
Image ID: docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Fri, 16 Nov 2018 11:31:44 -0700
Ready: True
Restart Count: 0
Environment:
Mounts:
/usr/share/nginx/html from shared-date-logs (rw)
/var/run/secrets/Kubernetes.io/serviceaccount from default-token-8dl5j (ro)
両方のコンテナが実行中であるため、両方が割り当てられた仕事をしていることを確認しましょう。
コンテナに接続するには、kubectl exec -ti multi-container-pod -c container-serving-dates —kubeconfig=kubeconfig bashを実行します。これで、コンテナ内にいます。
最後に、コンテナ内でcurl ‘http://localhost:80/output.txt’を実行し、ファイルを提供するはずです。（コンテナにcurlがインストールされていない場合は、最初にapt-get update && apt-get install curlを実行し、その後curl ‘http://localhost:80/output.txtを再実行してください。）
curl 'http://localhost:80/app.txt'
Fri Nov 16 18:31:44 UTC 2018
Fri Nov 16 18:31:54 UTC 2018
Fri Nov 16 18:32:04 UTC 2018
Fri Nov 16 18:32:14 UTC 2018
Fri Nov 16 18:32:24 UTC 2018
Fri Nov 16 18:32:34 UTC 2018
Fri Nov 16 18:32:44 UTC 2018
Fri Nov 16 18:32:54 UTC 2018
Kubernetesガイド
- Kubernetes (K8s) とは？ Kubernetesの基本チュートリアル
- Kubernetesのベストプラクティスによるクラスタ効率の向上
- ベストプラクティス：Kubernetes用のアプリケーション設計
- Kubernetes Pods: はじめに
- Kubernetes ReplicaSets: 簡単な紹介
- Kubernetes Deployments 完全解説
- Kubernetes DaemonSets の使用と管理
- Kubernetesサービスの仕組み
- Kubernetesのポート、ターゲットポート、ノードポートの使用
- KubernetesにおけるConfigMapsの作成と使用
- Kubernetes Secretsの紹介
- Kubernetesネットワーキングの基本
- Kubernetes Ingress解説
- Kubernetes Helmチャートの紹介
- Kubernetesオペレーターのパターンとは？
- KubernetesにおけるStatefulSetとしてのPostgreSQLのデプロイ
- Kubernetesカスタムリソース定義（CRD）の解説
- クラウドネイティブアプリケーションのための3つのKubernetesパターン
- Kubernetesコンピュートリソースの解説
- DevOpsパイプラインのためのKubernetesセキュリティ
- Kubernetesを用いた継続的デリバリーのためのSpinnakerの使用
- Kubernetesマルチクラスタ：使用方法と理由
- Kubernetesモニタリング：包括的ガイド
- Kubernetes vs Docker: 簡単な比較
- Kubernetes vs Docker Swarm: コンテナオーケストレーションツールの比較
- Kubernetes vs OpenShift: 何が違うのか？
- Kubernetesの認定：認定を取得する方法と理由
この投稿は私自身の見解であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。