個人ホームページ:バグの克服 - CSDN ブログ

kubernetes コラム: kubernetes_Conquering バグブログ - CSDN ブログ

ポッドは、 Kubernetes で作成および管理できるデプロイ可能なコンピューティングの最小単位です。ポッド(Whale Pods や Pea Pods など) は、(1 つ以上の) コンテナーのグループであり、これらのコンテナーは、ストレージ、ネットワーク、およびそれらのコンテナーの実行方法の宣言を共有します。ポッド内のコンテンツは常に同じ場所に配置され、一緒にスケジュールされ、共有コンテキストで実行されます。つまり、Docker 用語で説明すると、Pod は名前空間を共有し、ファイルシステムボリュームを共有するコンテナのグループに似ています。

定义: Pod 就是用来管理一组(一个|多个)容器的集合特点: 共享网络共享存储共享上下文环境

1.2 ポッドは複数のコンテナをどのように管理しますか?

ポッド内のコンテナは、クラスター内の同じ物理マシンまたは仮想マシン上に自動的にスケジュールされ、一緒にスケジュールすることができます。コンテナーは、リソースと依存関係を共有し、相互に通信し、コンテナー自体を終了するタイミングと方法を調整できます。たとえば、次の図に示すように、共有ボリューム内のファイルに対する Web サーバーのサポートを提供する 1 つのコンテナーと、それらのファイルをリモートで更新する別の「サイドカー」コンテナーがあるとします。

1.3 ポッドの使用方法は?

通常、単一インスタンスの Pod であっても、Pod を直接作成する必要はありません。代わりに、デプロイメントやジョブなどのワークロードリソースを使用してポッドを作成します。ポッドが状態を追跡する必要がある場合は、StatefulSet リソースを検討してください。

Kubernetes クラスター内のポッドの主な使用法は 2 つあります。

単一のコンテナを実行するポッド。「ポッドごとに 1 つのコンテナ」モデルは、Kubernetes の最も一般的な使用例です。この場合、ポッドは単一のコンテナのラッパーとして考えることができ、Kubernetes はコンテナではなくポッドを直接管理します。
複数のコンテナを連携して実行するポッド。ポッドは、緊密に結合されリソースを共有する必要がある、同じ場所に配置された複数のコンテナで構成されるアプリケーションをカプセル化する場合があります。これらの同じ場所に配置されたコンテナは、単一のまとまったサービス単位を形成する場合があります。つまり、1 つのコンテナが共有ボリュームからパブリックにファイルを提供し、別の「サイドカー」コンテナがそれらのファイルを更新または更新します。ポッドは、これらのコンテナーとストレージリソースを管理可能なエンティティにパッケージ化します。

例証します:

併置され、共同管理される複数のコンテナをポッドに編成することは、比較的高度なユースケースです。このパターンは、コンテナーが密接に関連しているシナリオでのみ使用してください。
各ポッドは、特定のアプリケーションの単一インスタンスを実行するように設計されています。アプリケーションを水平方向にスケーリングする場合 (たとえば、複数のインスタンスを実行してより多くのリソースを提供する場合)、インスタンスごとに 1 つずつ複数の Pod を使用する必要があります。Kubernetes では、これをコピー (レプリケーション)と呼ぶことがよくあります。通常、ワークロードリソースとそのコントローラーは、一連のポッドレプリカの作成と管理に使用されます。

2 ポッドの基本操作

2.1 ポッドの表示

# 查看默认命名空间的 pod
$ kubectl get pods|pod|po

# 查看所有命名空间的 pod
$ kubectl get pods|pod -A
$ kubectl get pods|pod|po -n 命名空间名称

# 查看默认命名空间下 pod 的详细信息
$ kubectl get pods -o wide 

# 查看所有命名空间下 pod 的详细信息
$ kubectl get pods -o wide -A

# 实时监控 pod 的状态
$ kubectl get pod -w

2.2 ポッドの作成

pod : kubectl run nginx(pod名称) --image=nginx:1.19

コンテナ: docker run --name nginx nginx:1.19

公式サイト参考アドレス：Pod | Kubernetes

# nginx-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.19
      ports:
            - containerPort: 80
# 使用 kubectl apply/create -f 创建 pod
$ kubectl create -f nginx-pod.yml
$ kubectl apply -f nginx-pod.yml

注意: create 仅仅是不存在时创建,如果已经存在则报错！apply 不存在创建，存在更新配置。推荐使用 apply！

2.3 ポッドの削除

$ kubectl delete pod  pod名称
$ kubectl delete -f pod.yml

2.4 コンテナをポッドに入れる

# 注意: 这种方式进入容器默认只会进入 pod 中第一个容器
$ kubectl exec -it nginx(pod名称) --(固定写死) bash(执行命令)
# 注意: 进入指定 pod 中指定容器
$ kubectl exec -it pod名称 -c 容器名称 --(固定写死) bash(执行命令)

2.5 ポッドログの表示

# 注意: 查看 pod 中第一个容器日志
$ kubectl logs -f(可选,实时) nginx(pod 名称)
# 注意: 查看 pod 中指定容器的日志
$ kubect logs -f pod名称 -c 容器名称

2.6 ポッドの説明情報の表示

$ kubectl describe pod nginx(pod名称)

複数のコンテナを実行する 3 ポッド

3.1 ポッドの作成

# myapp-pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
    - name: nginx
      image: nginx:1.19
      ports:
            - containerPort: 80
      imagePullPolicy: IfNotPresent

    - name: redis
      image: redis:5.0.10
      ports:
            - containerPort: 6379
      imagePullPolicy: IfNotPresent

実行を作成する

$ kubectl apply -f myapp-pod.yml

3.2 指定したコンテナのログを表示する

# 查看日志 (默认只查看第一个容器日志，这里是展示 nginx 日志)
$ kubectl logs -f myapp

# 查看 pod 中指定容器的日志
$ kubectl logs -f myapp -c nginx(容器名称)
$ kubectl logs -f myapp -c redis(容器名称)

3.3 コンテナへのアクセス

# 进入 pod 的容器 (默认进入第一个容器内部，这里会进入 nginx 容器内部)
$ kubectl exec -it myapp -- sh

# 进入 pod 中指定容器内部
$ kubectl exec -it myapp -c nginx -- sh
$ kubectl exec -it myapp -c redis -- sh

4 ポッドラベル (ラベル)

标签（Labels）ポッドなどの Kubernetes オブジェクトにアタッチされるキーと値のペアです。ラベルは、ユーザーにとって意味があり関連性のあるオブジェクトの識別プロパティを指定するために使用することを目的としています。ラベルは作成時にオブジェクトに添付でき、その後いつでも追加および変更できます。各オブジェクトはキー/値ラベルのセットを定義できますが、各キーは特定のオブジェクトに対して一意である必要があります。

ラベル機能: k8s 内のオブジェクトにエイリアスを付けるために使用され、エイリアスを使用してフィルタリングすることができます

4.1 文法

标签由键值对组成、有効なタグ値は次のとおりです。

63 文字以下である必要があります (空でも構いません)
タグ値が空でない限り、英数字 ( ) で[a-z0-9A-Z]始まり、終わる必要があります。
ダッシュ ( -)、アンダースコア ( _)、ドット ( .)、および文字または数字が含まれます

4.2 例

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp #创建时添加
spec:
  containers:
    - name: nginx
      image: nginx:1.21
      imagePullPolicy: IfNotPresent

    - name: redis
      image: redis:5.0.10
      imagePullPolicy: IfNotPresent
  restartPolicy: Always

4.3 ラベルの基本操作

# 查看标签
$ kubectl get pods --show-labels

# kubectl label pod pod名称 标签键值对
$ kubectl label pod myapp env=prod

# 覆盖标签 --overwrite
$ kubectl label --overwrite pod myapp env=test

# 删除标签 -号代表删除标签
$ kubectl label pod myapp env-

# 根据标签筛选 env=test/env  > = < 
$ kubectl get po -l env=test
$ kubectl get po -l env
$ kubectl get po -l '!env' # 不包含的 pod
$ kubectl get po -l 'env in (test,prod)' #选择含有指定值的 pod
$ kubectl get po -l 'env notin (test,prod)' #选择含有指定值的 pod

5 ポッドのライフサイクル

公式 Web サイトからの抜粋:ポッドのライフサイクル | Kubernetes

ポッドは事前定義されたライフサイクルに従い、Pendingstage から開始し、ポッド内の少なくとも 1 つのプライマリコンテナが正常に開始された場合に開始し、Runningポッド内のコンテナが失敗状態で終了したかどうかに応じてSucceededまたはFailedstage に入ります。同時に、ポッドはその存続期間中に 1 回だけスケジュールされます。ポッドがノードにスケジュール (割り当て) されると、ポッドが停止または終了されるまで、そのノード上でポッドが実行されます。

5.1 ライフサイクル

個々のアプリケーションコンテナーと同様に、ポッドは比較的一時的な (長命ではなく) エンティティとみなされます。ポッドが作成され、一意の ID (UID) が指定されてノードにスケジュールされ、(再起動ポリシーに従って) 終了されるか削除されるまで実行されます。ノードが停止した場合、そのノードにスケジュールされた Pod も、指定されたタイムアウト期間が経過した後に削除されるようにスケジュールされます。

ポッド自体には自己修復機能がありません。ポッドがノードにスケジュールされ、その後そのノードに障害が発生した場合、そのポッドは削除されます。同様に、ノードのリソースの枯渇またはノードのメンテナンスが原因でポッドが削除されると、ポッドは存続できなくなります。Kubernetes は、これらの比較的使い捨て可能な Pod インスタンスを管理するために、コントローラーと呼ばれる高レベルの抽象化を使用します。

特定の Pod (UID によって定義される) は、別のノードに「再スケジュール」されることはなく、その代わりに、その Pod を新しいほぼ同一の Pod に置き換えることができます。必要に応じて、新しいポッドに同じ名前を付けることができますが、その UID は異なります。

ストレージボリュームなど、ポッドと同じ存続期間を持つものがある場合、そのオブジェクトはポッド (同じ UID を持つ) が存在する限り存続することを意味します。何らかの理由で Pod が削除された場合、同一の代替 Pod が作成された場合でも、関連するオブジェクト (ここではボリュームなど) も削除され、再作成されます。

5.2 ポッドステージ

ポッドステージの数と意味は厳密に定義されています。ポッドには、このドキュメントに記載されている値以外の値があると想定しないでくださいphase。

価値	説明
`Pending`（保留中）	ポッドは Kubernetes システムによって受け入れられましたが、1 つ以上のコンテナがまだ作成されておらず、実行されていません。このフェーズには、ポッドがスケジュールされるまでの待機時間と、ネットワーク経由でイメージをダウンロードするのにかかる時間が含まれます。
`Running`（ランニング）	ポッドはノードにバインドされており、ポッド内のすべてのコンテナが作成されています。少なくとも 1 つのコンテナがまだ実行中か、起動または再起動の処理中です。
`Succeeded`（成功）	ポッド内のすべてのコンテナは正常に終了されたため、再起動されません。
`Failed`（失敗）	ポッド内のすべてのコンテナが終了し、少なくとも 1 つのコンテナが障害により終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。
`Unknown`（知らない）	何らかの理由でポッドのステータスを取得できません。これは通常、ポッドが存在するホストとの通信が失敗したために発生します。

例証します:

ポッドが削除されると、一部の kubectl コマンドを実行すると、ポッドのステータスがTerminating(終了) と表示されます。このTerminating状態はポッドのステージの 1 つではありません。ポッドには正常に終了するための期限が与えられており、デフォルトは 30 秒です。このパラメータを使用して、--forcePod を強制的に終了できます。

phaseノードが停止した場合、またはクラスター内の他のノードとの接続が失われた場合、Kubernetes は、失われたノード上で実行されているすべてのポッドのをに設定するポリシーを適用しますFailed。

[クラウドネイティブ] k8s のポッドとライフサイクルについての深い理解

目次

1 ポッドとは

1.1はじめに