【クラウドネイティブkubernetes】k8sでのpod活用について詳しく解説

I.はじめに

前回のk8sコンポーネントの記事でpodコンポーネントについてお話ししましたが、podはk8sにおけるリソース管理の最小単位であり、k8s全体で外部サービスを提供するための最も基本的な個体と言えます。ポッドの詳細な調査を行い、探索する必要があります。

次に、k8s アーキテクチャ図を見てください

k8s のポッドの理解を深めるために、k8s の完全なアーキテクチャを確認しましょう

3. ポッドの機能

上の写真と組み合わせると、ポッドは次のように要約できます。

• Pod はコンテナのグループで、K8S の最小単位です。Pod には複数のコンテナを含めることができますが、通常、各 Pod で実行されるコンテナは 1 つだけです。Pod はエンドウ豆のポッドとして理解でき、Pod 内の各コンテナはエンドウ豆のようなものです。 ;
• Pod のコアはコンテナーを実行することであり、コンテナー エンジンを指定する必要があります。たとえば、Docker はテクノロジの 1 つです。

4、ポッドの分類

ポッドが独立して作成されるかどうかによって、2 つのタイプに分けることができます。

• 自己作成: 直接作成された Pod は削除後に消え、自動的に再構築されません。
• コントローラーの作成: コントローラーによって作成されたポッドは、削除後に自動的に再構築されます。

5.ポッド内のコンテナ

上記の図から、コンテナはポッド内で実行されていることがわかります.これは、ポッドがコンテナが実行する外部コンテナであることも単純に理解できるため、ポッドは理論的に多くの docker コンテナを実行できます.この点について、2つの説明作られています：

• Pod ごとに 1 つのコンテナーが最も一般的な使用方法です. Pod はコンテナーの単純なパッケージです. K8S は、コンテナーを直接管理するのではなく、Pod を管理します。
• Pod は、相互に連携する必要がある複数のコンテナーを同時に実行し、リソースを共有します. 同じ Pod 内のコンテナーをサービス ユニットとして使用できます。

6.ポッド内ネットワーク

k8s クラスター内のノードの場合、複数のポッドが展開される場合があります.これらの異なるポッドが相互に通信する必要がある場合はどうなりますか? これには、ポッド内のネットワークについて話す必要があります。

• Pod には一連のコンテナーが含まれ、Pod は複数のワーカー ノードにまたがりません。
• 各 Pod には一意の IP アドレスが割り当てられ、Pod 内のすべてのコンテナは IP アドレスとポートを含むネットワーク スペースを共有します。
• Pod 内のコンテナーは、localhost を使用して相互に通信できます。

補足: k8s におけるネットワーク通信モデル

K8S クラスターには 4 種類のネットワークがあります。

        詳細は、同一ポッド内のコンテナ間の通信、ポッド間の通信、ポッドとサービス間の通信、クラスタ外のトラフィックとサービス間の通信です。

7. Podへの収納

• ボリュームを使用して Pod 内のストレージ リソースを保持し、コンテナーの再起動後のファイルの損失を防ぐこともできます。
• Pod 内のすべてのコンテナは共有ボリュームにアクセスできます。

八、Pod共通操作コマンド

1. k8s クラスター内のシステムで実行されているポッドを表示します

kubectl get pod -n kube-system

2. 自分で作成した Pod を表示する

kubectl get pod
或
kubectl get pod,svc,deploy

3. ポッドを削除する

ポッドを直接削除します。

kubectl delete pod ポッド名 -n 名前空間

コントローラー経由で作成されたポッドを削除します。

kubectl 削除ポッド コントローラー名 -n 名前空間

補足:

• Pod がデプロイ コントローラーを介して作成された場合、それを直接削除すると、自動的に新しい Pod が作成されます。
• -n は必須ではなく、特定の名前空間を示します。

4. Pod を起動する [コマンドモード起動]

kubectl run ポッド名 --image=mirror --port=80 --namespace 名前空間名

たとえば、前回の記事では、次のように記述できる nginx ポッドを作成しました。

kubectl run test-nignx-pod --image=nginx:1.23.0 --port=80 --namespace テスト

5. ポッドを開始する [yaml モードで開始]

現在のディレクトリに yaml ファイルを作成する

設定内容は以下の通りです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy  
  labels:
    chapter: first-app
spec:
  selector:
     matchLabels:  
       app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name : nginx
        image: nginx:1.23.0
        ports:
        - containerPort: 80

次に、apply メソッドを使用して開始します

kubectl apply -f ./test-nginx.yaml

気をつけて：

-f を適用して作成した Pod を削除する場合は、-f を適用して削除する必要があります。

6. デプロイメント コントローラーを介して yaml ファイルをエクスポートします。

現在のクラスターの下には、次のポッドがあります

 次のコマンドを使用して、このポッドに対応する yaml をエクスポートします

kubectl create deployment test-nginx3 --image=nginx:1.23.0 --namespace test -o yaml --dry-run=client > ./nginx.yaml

実行後、現在のディレクトリにyamlファイルが作成されていることがわかります

 ファイルの内容は、以前に作成した yaml と似ていますか? より完全なようです. このファイルの一部のパラメーターは、手動で変更できることに注意してください。

次に、apply コマンドを使用してポッドを作成できます。

kubectl apply -f nginx.yaml

7.名前空間内のポッドの詳細を表示する

kubectl get pod -n ns name -o wide

たとえば、デフォルトの名前空間でポッド情報を表示すると、yaml ファイルを通じて上記で作成されたポッドを確認できます。

kubectl get pod -n default -o wide

k8s を介して作成されたポッドには、curl を介して直接アクセスできる現在のポッドに IP アドレスが割り当てられます [同じクラスター内の他のノードにアクセスできます]

ナイン、ポッドエクステンションの補足説明

1. Pod イメージのプル戦略 

Pod イメージのプル ポリシーは、次のように imagePullPolicy フィールドで構成できます。

spec:
  containers:
    - name: nginx
      image: nginx:1.23.0
      imagePullPolicy: Always	#可取 Always（默认值）、IfNotPresent、Never

imagePullPolicy は、次の 3 つのポリシー値を使用できます。

Always: デフォルト値で、ポッドが作成されるたびにイメージが再プルされます;
IfNotPresent: イメージがホストに存在しない場合にのみプルされます;
Never: イメージは、ローカルを使用してアクティブにプルされることはありません画像を手動でプルダウンする必要があります。

2. Pod はリソース制限構成を使用します

クラスター内のノードには、CPU、メモリ、その他の情報などの特定の構成があり、作成されたポッドのためにノードのリソースをいっぱいにすることができないことがわかっているため、構成ファイルで適用を使用するように構成できます。 f で Pod を作成する場合、構成ファイルの主な構成は次のとおりです。

resources：
	requests：
		memory："内存大小"
		cpu："cpu占用大小"
	limits:	
		memory："内存占用大小"
		cpu："cpu占用大小"

以下は、完全なタグ構成と説明です。

spec:  
  containers: 
  - name: string   #必选，容器名称
    image: string  #必选，容器的镜像名称
  
    resources: #资源限制和请求的设置
      limits:  #资源限制的设置
        cpu: string     #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string  #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests: #资源请求的设置
        cpu: string    #Cpu请求，容器启动的初始可用数量
        memory: string #内存请求,容器启动的初始可用数量

以下は実際に使用する構成です

その他の構成については、ドキュメントを参照してください: k8s ドキュメント

3.ポッドの作成プロセスについて

kubectl apply -f xxx.yaml によって作成されたポッドは、この記事の冒頭にある k8s アーキテクチャ図と組み合わせて説明に使用されています。

• kubectl は、ポッドを作成するために apiserver にリクエストを送信します。
• apiserver は、ポッドの作成情報を保存用に etcd に保存します。
• スケジューラーは、ノードにバインドされていないポッド リソースをリッスンし、バインドするスケジューリング アルゴリズムを介してポッド リソースに適したノードを選択し、apiserver に応答して、ポッドのステータスを更新し、etcd に保存します。
• バインドされたノードでは、Controller-Manager が kubelet に自身のノードに割り当てられたポッドを受け取るように通知し、コンテナ エンジン API を呼び出してコンテナを作成し、API サーバーにコンテナのステータスで応答します。

4.ポッドのスケジューリング戦略

デフォルトでは、Pod が実行される Node ノードは、対応するアルゴリズムを使用して Scheduler コンポーネントによって計算され、このプロセスは手動制御の対象ではありません。しかし、実際の使用では、これはニーズを満たしていません。多くの場合、特定の Pod が特定のノードに到達するように制御したいため、どのようにすればよいのでしょうか? これには、ポッドの k8s スケジューリング ルールを理解する必要があります。

ポッドのスケジューリングに影響を与えるいくつかの要因を次に示します。

ポッドのリソース制限

スケジューラは、リクエストに従ってスケジューリングに十分なサイズのノードを見つけます。

ノード セレクター タグ (nodeSelector) の使用

ノード セレクターはノードを分離できます. たとえば、k8s クラスターには複数のノードがあります. 運用環境、開発環境、およびテスト環境を区別するために、ノード セレクター ラベルを使用してそれらを分割できます。

たとえば、Pod を開発環境にスケジュールする必要がある場合、スケジューラーを介して、ラベル セレクターが env_role:dev であるノードに Pod をスケジュールできます。対応する yaml コア構成は次のとおりです。

nodeSelector: 
  env_role:dev/prod

ノードセレクターについては、その使い方については別の記事で詳しく説明します。