【クラウドネイティブ】ポッドの詳細

1. Podの基本概念

• ポッドは、kubernetes の最小のリソース管理コンポーネントであり、コンテナ化されたアプリケーションの実行を最小限に抑えるリソース オブジェクトでもあります。ポッドは、クラスター内で実行されているプロセスを表します。kubernetes の他のほとんどのコンポーネントは、ポッドの機能をサポートおよび拡張するためにポッドを中心に展開します。たとえば、StatefulSet や Deployment などのコントローラー オブジェクトはポッドの実行を管理するために使用され、Service および Ingress オブジェクトはポッド アプリケーションを公開し、ポッドにサービスを提供するために使用されます。 storage PersistentVolume はリソース オブジェクトなどを格納します。

1.1//Kubrenes クラスターでは、Pod は次の 2 つの方法で使用できます。

●コンテナはPod内で動作します。「各 Pod に 1 つのコンテナ」モデルが最も一般的な使用法です。この使用法では、Pod を 1 つのコンテナのカプセル化として考えることができ、kuberentes はコンテナを直接管理するのではなく、Pod を管理します。

●ポッド内で複数のコンテナを同時に実行します。ポッドは、互いに緊密に結合して連携する必要がある複数のコンテナをカプセル化し、コンテナ間でリソースを共有することもできます。同じポッド内のこれらのコンテナは、互いに連携してサービス ユニットを形成できます。たとえば、1 つのコンテナがファイルを共有し、別の「サイドカー」コンテナがこれらのファイルを更新します。Pod はこれらのコンテナのストレージ リソースをエンティティとして管理します。

ポッド内のコンテナは同じノード上で実行する必要があります。最新のコンテナ テクノロジでは、コンテナが 1 つのプロセスのみを実行することが推奨されています。コンテナの PID 名前空間のプロセス番号は 1 で、信号を直接受信して処理できます。プロセスが終了すると、コンテナのライフ サイクルが終了します。コンテナー内で複数のプロセスを実行する場合は、ツリー構造で複数のプロセスのライフサイクル管理を完了するために、Linux オペレーティング システムの init プロセスと同様の管理および制御プロセスが必要です。それぞれのコンテナで実行されているプロセスは、ネットワーク通信を直接完了できません。これは、コンテナ間の分離メカニズムが原因です。k8s の Pod リソース抽象化により、この問題が解決されます。Pod オブジェクトは、NET、MNT、UTS、および IPC 名前空間を共有するコンテナのコレクションですしたがって、同じドメイン名、ホスト名、ネットワーク インターフェイスを持ち、IPC を介して直接通信できます。

Pod リソースの基礎となる基本的なコンテナーの一時停止は、各コンテナーにネットワーク名前空間とその他の共有メカニズムを提供します。基本的なコンテナー (親コンテナーとも呼ばれます) の一時停止は、Pod コンテナー間の共有操作を管理することです。この親コンテナーは、その方法を正確に認識できる必要があります。実行環境を共有するコンテナを作成し、これらのコンテナのライフサイクルを管理します。この親コンテナの考え方を実現するために、kubernetesではポーズコンテナをPod内の全コンテナの親コンテナとして利用します。この一時停止コンテナには 2 つのコア機能があり、1 つはポッドの Linux 名前空間全体の基礎を提供することです。次に、PID 名前空間を有効にします。これは、各 Pod で PID 1 のプロセス (初期プロセス) として機能し、ゾンビ プロセスをリサイクルします。

1.2pause コンテナにより、Pod 内のすべてのコンテナが 2 つのリソース (ネットワークとストレージ) を共有できるようになります。

●ネットワーク：

各ポッドには一意の IP アドレスが割り当てられます。ポッド内のすべてのコンテナは、IP アドレスやポートを含むネットワーク スペースを共有します。ポッド内のコンテナは、localhost を使用して相互に通信できます。ポッド内のコンテナが外部と通信するときは、共有ネットワーク リソースを割り当てる必要があります (ホストのポート マッピングの使用など)。

●収納：

Pod は複数の共有ボリュームを指定できます。ポッド内のすべてのコンテナは共有ボリュームにアクセスできます。ボリュームは、コンテナーの再起動後のファイルの損失を防ぐために、ポッド内のストレージ リソースを永続化するために使用することもできます。

1.3 kubernetesの一時停止コンテナは主にコンテナごとに以下の機能を提供します。

●ポッド内で Linux 名前空間 (ネットワーク コマンド スペースなど) を共有するための基礎として機能します;
● PID 名前空間を有効にし、init プロセスを開始します。

1.4Kubernetes がこのような Pod コンセプトと特別な構成構造を設計する目的は何ですか? ? ? ? ?

●理由 1: コンテナのグループを単位として扱う場合、コンテナ全体を単純に判断して効果的に処理することは困難です。たとえば、コンテナーが停止した場合、コンテナー全体が停止したと見なされますか? そこでPodの基本コンテナとして業務に関係のないPauseコンテナを導入し、そのステータスがコンテナグループ全体のステータスを表すため、この問題は解決できます。

●理由 2: Pod 内の複数のアプリケーション コンテナは、Pause コンテナの IP と Pause コンテナによってマウントされた Volume を共有するため、アプリケーション コンテナ間の通信の問題が簡素化され、コンテナ間のファイル共有の問題も解決されます。

1.5 ポッドは通常、次のカテゴリに分類されます。

●自律ポッド

この種の Pod 自体は自己修復できません。Pod が作成されると (ユーザーが直接作成したのか、別のコントローラーによって作成されたのかに関係なく)、Kuberentes によってクラスターのノードにスケジュールされます。ポッドのプロセスが終了するか、削除されるか、リソース不足により排除されるか、ノードに障害が発生するまで、ポッドはそのノード上に残ります。ポッドは自分自身を修復しません。ポッドを実行しているノードに障害が発生した場合、またはスケジューラ自体に障害が発生した場合、ポッドは削除されます。同様に、ポッドが配置されているノードにリソースが不足している場合、またはポッドがメンテナンス状態にある場合、ポッドも削除されます。

●コントローラーで管理するPod

Kubernetes は、Controller と呼ばれる高レベルの抽象化レイヤーを使用して Pod インスタンスを管理します。コントローラーは複数のポッドを作成および管理でき、コピー管理、ローリング アップグレード、クラスター レベルの自己修復機能を提供します。たとえば、ノードに障害が発生した場合、コントローラーはそのノード上のポッドを他の正常なノードに自動的にスケジュールできます。ポッドを直接使用することもできますが、通常、Kubernetes でポッドを管理するためにコントローラーが使用されます。

●スタティックポッド

静的ポッドは、マスター ノードの apiserver 経由ではなく、特定のノードの kubelet プロセスによって直接管理されます。コントローラーの Deployment または DaemonSet に関連付けることはできません。kubelet プロセス自体によって監視されます。ポッドがクラッシュすると、ポッドは再起動され、kubelet はそれらに対してヘルス チェックを実行できません。静的ポッドは常に特定の kubelet にバインドされ、常に同じノード上で実行されます。Kubelet は、Kubernetes API サーバー上の静的ポッドごとにミラー ポッド (ミラー ポッド) を自動的に作成するため、API サーバー内のポッドにクエリを実行できますが、API サーバーを通じて制御することはできません (たとえば、削除することはできません)。

kubelet 構成ファイルを表示する

/var/lib/kubelet/config.yaml
cat /var/lib/kubelet/config.yaml | grep staticPodPath
staticPodPath: /etc/kubernetes/manifests

次のコマンドを使用して、kubelet に対応する起動構成ファイルを検索し、ノード node の kubelet 構成ファイルを変更し、静的 Pod --pod-manifest-path パラメーターの環境変数構成を追加することもできます。

systemctl status kubelet
/usr/lib/systemd/system/kubelet.service.d
     └─10-kubeadm.conf

vim /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allowprivileged=true"

systemctl daemon-reload
systemctl restart kubelet

静的Podファイルの管理ディレクトリにPodのJsonまたはYamlファイルを用意します

vim /etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    app: static
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80

• 実行中の kubelet は、設定されたディレクトリを定期的にスキャンしてファイルの変更を確認し、このディレクトリにファイルが出現または消失すると、ポッドを作成または削除します。
• MasterノードにもPodが表示されているので、kubectl delete pod static-web-node01コマンドを実行してPodを削除すると削除できないことがわかります。

1.6Pod コンテナの分類:

1. インフラストラクチャコンテナ

• Pod ネットワーク全体とストレージ スペースを維持する
• ノード内でのノード操作
• Pod を起動すると、k8s は基本コンテナを自動的に起動します。

cat /opt/kubernetes/cfg/kubelet
......
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"

• Pod が作成されるたびに作成され、実行中の各 Pod には、自動的に実行されるポーズ amd64 基本コンテナーがあり、ユーザーには透過的です。

docker ps -a
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"

2. コンテナの初期化(initcontainers)

• init コンテナはアプリケーション コンテナが開始する前に完了するまで実行する必要があり、アプリケーション コンテナは並行して実行されるため、init コンテナはアプリケーション コンテナの起動をブロックまたは遅延する簡単な方法を提供できます。
  Init コンテナは、次の 2 つの点を除いて、通常のコンテナと非常に似ています。

●Initコンテナは正常に完了するまで常に実行されます。

●各 Init コンテナは起動を正常に完了し、次の Init コンテナが起動する前に終了する必要があります。Pod
の Init コンテナが失敗した場合、k8s は Init コンテナが成功するまで Pod を再起動し続けます。ただし、Pod の対応する再起動ポリシー (restartPolicy) が Never の場合は再起動されません。

Initのコンテナの役割

• init コンテナにはアプリケーション コンテナとは別のイメージがあるため、その起動関連のコードには次の利点があります。

●Init コンテナには、インストール時にアプリケーション コンテナに存在しないいくつかのユーティリティまたはパーソナライゼーション コードを含めることができます。たとえば、インストール プロセス中に sed、awk、python、または dig などのツールを使用するためだけに、イメージを FROM して新しいイメージを生成する必要はありません。

●Init コンテナは、これらのツールを安全に実行して、これらのツールがアプリケーション イメージのセキュリティを低下させることを防ぎます。

●アプリケーション イメージの作成者とデプロイ担当者は、別のアプリケーション イメージを共同で構築することなく、独立して作業できます。

●Init コンテナは、Pod 内のアプリケーション コンテナとは異なるファイル システム ビューで実行できます。したがって、Init コンテナは Secret にアクセスできますが、アプリケーション コンテナはアクセスできません。

●Init コンテナはアプリケーション コンテナが起動する前に完了まで実行する必要があるため、Init コンテナは一連の前提条件が満たされるまでアプリケーション コンテナの起動をブロックまたは遅延するメカニズムを提供します。前提条件が満たされると、ポッド内のすべてのアプリケーション コンテナが並行して起動されます。

3. アプリケーションコンテナ（メインコンテナ）

• パラレルスタート

公式ウェブサイトの例:

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

ある

piVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

• この例では、2 つの Init コンテナを持つ単純な Pod を定義します。最初のものは myservice が開始するのを待ち、2 つ目は mydb が開始するのを待ちます。両方の Init コンテナが開始されると、Pod は仕様内のアプリケーション コンテナを開始します。

k

ubectl describe pod myapp-pod

kubectl logs myapp-pod -c init-myservice

vim myservice.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
	
kubectl create -f myservice.yaml

kubectl get svc

kubectl get pods -n kube-system

kubectl get pods

vim mydb.yaml
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
	
kubectl create -f mydb.yaml

kubectl get pods

特記事項

●Pod の起動処理では、ネットワークとデータボリュームが初期化された後、Init コンテナが順次起動されます。次のコンテナを開始するには、各コンテナが正常に終了する必要があります。
●ランタイムや異常終了によりコンテナの起動に失敗した場合、PodのrestartPolicyで指定されたポリシーに従って再試行されます。ただし、ポッドの restartPolicy が Always に設定されている場合、Init コンテナが失敗したときに RestartPolicy ポリシーが使用されます。
●すべての Init コンテナが成功するまで、Pod は Ready になりません。Init コンテナのポートは Service に集約されません。初期化中のポッドは保留状態ですが、初期化状態を true に設定する必要があります。
●Podを再起動した場合は、すべてのInitコンテナを再実行する必要があります。
●Initコンテナ仕様の変更はコンテナイメージフィールドに限定されており、他のフィールドの変更は有効になりません。Init コンテナの image フィールドを変更することは、Pod を再起動することと同じです。
●初期コンテナにはアプリケーションコンテナの全フィールドが含まれます。ReadinessProbe を除きます。Init コンテナは完了以外の準備完了以外の状態を定義できないためです。これは検証プロセス中に強制されます。
●Pod 内の各アプリと Init コンテナの名前は一意である必要があります。他のコンテナと同じ名前を共有すると、検証中にエラーがスローされます。

1.7 イメージプルポリシー (imagePullPolicy)

• Pod の核心はコンテナを実行することです. Docker などのコンテナ エンジンを指定する必要があります. コンテナを起動するときに, イメージをプルする必要があります. k8s のイメージ プル戦略はユーザーが指定できます:
  • 1. IfNotPresent: イメージが既に存在する場合、kubelet はイメージをプルしません。ローカルで欠落している場合にのみ、ウェアハウスからイメージをプルします。デフォルトのイメージプル戦略
  • 2. 常に: ポッドが作成されるたびに、イメージが再度プルされます。
  • 3. Never: ポッドはこのイメージをアクティブにプルせず、ローカル イメージのみを使用します。
    注: 「:latest」というラベルが付いた画像ファイルの場合、デフォルトの画像取得ポリシーは「Always」ですが、他のラベルが付いた画像の場合、デフォルトのポリシーは「IfNotPresent」です。

公式の例:

https://kubernetes.io/docs/concepts/containers/images

に

bectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: private-image-test-1
spec:
  containers:
    - name: uses-private-image
      image: $PRIVATE_IMAGE_NAME
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
EOF


//master01 上操作
kubectl edit deployment/nginx-deployment
......
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.4
        imagePullPolicy: IfNotPresent							#镜像拉取策略为 IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {
    
    }
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always										#Pod的重启策略为 Always，默认值
      schedulerName: default-scheduler
      securityContext: {
    
    }
      terminationGracePeriodSeconds: 30
......

//テストケースを作成する

mkdir /opt/demo
cd /opt/demo

vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]


kubectl create -f pod1.yaml

kubectl get pods -o wide
pod-test1                         0/1     CrashLoopBackOff   4          3m33s

//現時点でPodの状態が異常となっているのは、echoプロセスが実行後に終了し、コンテナのライフサイクルも終了しているためです。

kubectl describe pod pod-test1
......
Events:
  Type     Reason     Age                 From                    Message
  ----     ------     ----                ----                    -------
  Normal   Scheduled  2m10s               default-scheduler       Successfully assigned default/pod-test1 to 192.168.80.11
  Normal   Pulled     46s (x4 over 119s)  kubelet, 192.168.80.11  Successfully pulled image "nginx"
  Normal   Created    46s (x4 over 119s)  kubelet, 192.168.80.11  Created container
  Normal   Started    46s (x4 over 119s)  kubelet, 192.168.80.11  Started container
  Warning  BackOff    19s (x7 over 107s)  kubelet, 192.168.80.11  Back-off restarting failed container
  Normal   Pulling    5s (x5 over 2m8s)   kubelet, 192.168.80.11  pulling image "nginx"
//可以发现 Pod 中的容器在生命周期结束后，由于 Pod 的重启策略为 Always，容器再次重启了，并且又重新开始拉取镜像

//修改 pod1.yaml 文件
cd /opt/demo
vim pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test1
spec:
  containers:
    - name: nginx
      image: nginx:1.14							#修改 nginx 镜像版本
      imagePullPolicy: Always
      #command: [ "echo", "SUCCESS" ]			#删除

//删除原有的资源
kubectl delete -f pod1.yaml 

//更新资源
kubectl apply -f pod1.yaml 

//查看 Pod 状态
kubectl get pods -o wide
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE
pod-test1                         1/1     Running   0          33s   172.17.36.4   192.168.80.11   <none>

//在任意 node 节点上使用 curl 查看头部信息
curl -I http://172.17.36.4
HTTP/1.1 200 OK
Server: nginx/1.14.2
......

1.8 ハーバーをデプロイし、プライベート プロジェクトを作成する

//Docker ハーバー ノード (192.168.80.30) で動作します。

systemctl stop firewalld.service
systemctl disable firewalld.service
setenforce 0

yum install -y yum-utils device-mapper-persistent-data lvm2 
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo 
yum install -y docker-ce
systemctl start docker.service
systemctl enable docker.service
docker version
//上传 docker-compose 和 harbor-offline-installer-v1.2.2.tgz 到 /opt 目录中
cd /opt
chmod +x docker-compose
mv docker-compose /usr/local/bin/

//部署 Harbor 服务
tar zxvf harbor-offline-installer-v1.2.2.tgz -C /usr/local/
vim /usr/local/harbor/harbor.cfg
--5行--修改，设置为Harbor服务器的IP地址或者域名
hostname = 192.168.80.30

cd /usr/local/harbor/
./install.sh

Harbor で新しいプロジェクトを作成する

(1) ブラウザ アクセス: http://192.168.80.10 Harbor WEB UI インターフェイスにログインします。デフォルトの管理者ユーザー名とパスワードは admin/Harbor12345 です。
(2) ユーザー名とパスワードを入力してインターフェイスにログインすると、次のことができます。新しいプロジェクトを作成します。「+プロジェクト」ボタンをクリックします。
(3) プロジェクト名を「kgc-project」と入力し、「OK」ボタンをクリックして新しいプロジェクトを作成します

//各ノードのプライベート ウェアハウスへの接続を構成します (各行の後のカンマに注意してください)

cat > /etc/docker/daemon.json <<EOF
{
  "registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],
  "insecure-registries":["192.168.80.30"]
}
EOF

systemctl daemon-reload
systemctl restart docker

//在每个 node 节点登录 harbor 私有仓库
docker login -u admin -p harbor12345 http://192.168.80.30

//在一个 node 节点下载 Tomcat 镜像进行推送
docker pull tomcat:8.0.52
docker images

docker tag tomcat:8.0.52 192.168.80.30/kgc-project/tomcat:v1
docker images

docker push 192.168.80.30/kgc-project/tomcat:v1


//查看登陆凭据
cat /root/.docker/config.json | base64 -w 0			#base64 -w 0：进行 base64 加密并禁止自动换行
ewoJImF1dGhzIjogewoJCSIxOTIuMTY4LjE5NS44MCI6IHsKCQkJImF1dGgiOiAiWVdSdGFXNDZTR0Z5WW05eU1USXpORFU9IgoJCX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8xOS4wMy41IChsaW51eCkiCgl9Cn0=