KubernetesはPodPresetを用いてPodsに情報を注入する

文書ディレクトリ

1、PodPreset紹介

2、環境、ソフトウェア準備

3、K 8 s PodPreset構成を有効にする

4、PodPreset注入情報例

4.1、マッチング指定Podロード構成

4.2、あるNamespaceの下のすべてのPodロード構成に一致する

1、PodPreset紹介
PodPresetは、secrets、volume mounts、environment variablesなど、Podの作成時に他の実行時に必要な情報を注入するK 8 s APIリソースであり、ラベルセレクタを使用してPodを指定してPodPresetプリセット情報を適用することができます.PodPresetを使用する利点は、いくつかの一般的なPodプリセット情報をテンプレートとして構成できることです.これにより、各Podにすべての情報を明示的に提供する必要がなく、Pod初期化構成を簡素化し、構成を統一する効果もあります.
2、環境、ソフトウェアの準備
今回のプレゼンテーション環境では、本機のMAC OSで操作しています.以下はインストールされたソフトウェアとバージョンです.

Docker: 18.06.3-ce

Oracle VirtualBox: 6.0.8 r130520 (Qt5.6.3)

Linux: 7.6.1810

Minikube: v0.30.0

Kubernetes: 1.12.1

注意:ここでKubernetesクラスタ構築はMinikubeを使用して完了します.Minikubeが起動したシングルノードk 8 s Nodeの例は、ネイティブのVM仮想マシンで実行する必要があるので、VMを事前にインストールする必要があります.ここでOracle VirtualBoxを選択します.k 8 sは下部にDockerコンテナを使用するため、本機はDocker環境を設置する必要がある.ここではDocker、VirtualBox、Minikube、Kubectlの設置過程を無視し、PodPresetの構成と使用に重点を置いて説明する.
3、K 8 s PodPreset構成を有効にする
K 8 sはデフォルトでPodPresetサポートをオンにしない.APIタイプはsettings.k8s.io/v1alpha1である.クラスタがPodPresetサポートをオンにしているかどうかを確認しない場合は、kubectl api-versionsコマンドでタイプが存在するかどうかを確認するか、またはkubectl get podpresetコマンドで表示し、オンにしていない場合はerror: the server doesn't have a resource type "podpreset"エラーを提示する.
PodPresetを有効にすると、K 8 s ApiServerで--runtime-config=settings.k8s.io/v1alpha1=trueの構成を追加できます.Minikube方式でクラスタを起動し、起動時に次のコマンドを追加できます.

minikube start --extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset`

以上のコマンドが複雑すぎる場合は、Yaml方式の構成を変更することもできます.MinikubeはStatic Pod方式でKubeletで各コンポーネントサービスを起動するので、対応するコンポーネントのYamlを変更してPodPresetをアクティブにすることができ、/etc/kubernetes/manifests/kube-apiserver.yamlファイルを変更することで以下の構成を追加し、変更が完了するとKubeletはkube-apiserver各コンポーネントを自動的に再起動します.

$ vim /etc/kubernetes/manifests/kube-apiserver.yaml
- --runtime-config=settings.k8s.io/v1alpha1=true  #     
- --enable-admission-plugins=NamespaceLifecycle...,PodPreset  #      ,PodPreset   

切り取り修正後のkube-apiserver.yamlファイルは以下の通りです.

spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
    - --runtime-config=settings.k8s.io/v1alpha1=true
    - --advertise-address=172.30.12.98
    - --allow-privileged=true
    - --client-ca-file=/var/lib/minikube/certs/ca.crt
    - --enable-bootstrap-token-auth=true

コンポーネントの再起動が完了したら、PodPresetがサポートされているかどうかを再度確認できます.

$ kubectl api-versions | grep settings.k8s.io
settings.k8s.io/v1alpha1

4.PodPreset注入情報例
ここでは、PodPresetを使用してPodに情報を注入する方法を示します.ここでは、指定したPodロード構成と、NamespaceのすべてのPodロード構成を一致させる2つの例を示します.
4.1、指定Podロード構成に一致する
上記の Pod， PodPreset について説明したが、ここでは、指定したPodロード構成と一致する方法を説明する.まず、PodPreset Yamlリソースファイルを新規作成します.

$ vim podpreset-busybox-hwy.yaml
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: busybox-hwy
  namespace: wanyang3
spec:
  selector:
    matchLabels:
      role: busybox-hwy
  env:
    - name: PODPRESET_MESSAGE
      value: "This is podpreset message."
  volumeMounts:
    - mountPath: /opt/logs
      name: logs-volume
  volumes:
    - name: logs-volume
      emptyDir: {}

次のような重要な情報が表示されます.

PodPresetリソースApiVersionはsettings.k8s.io/v1alpha1

ここでselector. matchLabelsは、Labelsマッチングラベルを介してrole: busybox-whyを含むPod

を含む.

は、envの環境変数PODPRESET_MESSAGE=This is podpreset message.を、一致するPodの

に注入する.

は、volumesボリュームのマウントディレクトリを、一致するPodの/opt/logsディレクトリ

に注入する.
このPodPresetリソースを作成してください.

$ kubectl create ns wanyang3
namespace/wanyang3 created
$ kubectl apply -f podpreset-busybox-hwy.yaml
podpreset.settings.k8s.io/busybox-hwy created
$ kubectl get podpreset -n wanyang3
NAME          CREATED AT
busybox-hwy   2019-07-07T02:10:31Z

次に、Pod Yamlリソースファイルを作成します.

$ vim pod-busybox-hwy.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: busybox-hwy
  namespace: wanyang3
  labels:
    app: busybox-hwy
    role: busybox-hwy
spec:
  containers:
    - name: busybox-hwy
      image: busybox:latest
      command: ["sleep", "60000"]

注意:ここではbusybox容器でテストします.ここでlabels role: busybox-hwyは上のPodPreset selector. matchLabelsと一致しなければなりません.そうしないと、情報を注入できません.では、Podリソースを作成します.

$ kubectl apply -f pod-busybox-hwy.yaml
pod/busybox-hwy created
$ kubectl get pod -n wanyang3
NAME          READY   STATUS    RESTARTS   AGE
busybox-hwy   1/1     Running   0          15s

作成に成功し、容器内に入ってPodPreset情報が正しく注入されているかどうかを確認しましょう.

$ kubectl exec -it busybox-hwy -n wanyang3 /bin/sh
/ # printenv |grep PODPRESET
PODPRESET_MESSAGE=This is podpreset message.
/ # df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                  36.0G      9.3G     26.7G  26% /
tmpfs                    64.0M         0     64.0M   0% /dev
tmpfs                     1.8G         0      1.8G   0% /sys/fs/cgroup
/dev/mapper/centos-root
                         36.0G      9.3G     26.7G  26% /opt/logs
/dev/mapper/centos-root
                         36.0G      9.3G     26.7G  26% /dev/termination-log
/dev/mapper/centos-root
                         36.0G      9.3G     26.7G  26% /etc/resolv.conf
/dev/mapper/centos-root
                         36.0G      9.3G     26.7G  26% /etc/hostname
/dev/mapper/centos-root
                         36.0G      9.3G     26.7G  26% /etc/hosts
......                         

検証に問題はありません.PodPreset情報はPodに注入されましたが、私たちのPod yamlファイルは非常に簡潔で、ある構成の変更を回避しました.すべての関連するPodはYaml構成を更新する必要があります.便利ではありませんか.PodPresetの実装方法をより深く理解し、PodのYamlファイルを取得してみましょう.

# kubectl get pod busybox-hwy -n wanyang3 -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    podpreset.admission.kubernetes.io/podpreset-busybox-hwy: "24187"
  creationTimestamp: 2019-07-07T02:22:27Z
  labels:
    app: busybox-hwy
    role: busybox-hwy
  name: busybox-hwy
  namespace: wanyang3
  resourceVersion: "24302"
  selfLink: /api/v1/namespaces/wanyang3/pods/busybox-hwy
  uid: 1066b217-a05e-11e9-aab0-080027a076a9
spec:
  containers:
  - command:
    - sleep
    - "60000"
    env:
    - name: PODPRESET_MESSAGE
      value: This is podpreset message.
    image: busybox:latest
    imagePullPolicy: Always
    name: busybox-hwy
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /opt/logs
      name: logs-volume
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-nnbrm
      readOnly: true
  dnsPolicy: ClusterFirst
  nodeName: minikube
  ......

k 8 s admission controllerを通過した後のYamlファイルは、テンプレートのInclude機能と同様に、PodPresetとPodリソースMergeを統合すると同時に、podpreset.admission.kubernetes.io/podpreset-busybox-hwy: "24187"という注釈を追加したものであり、この24187リソース番号は、上のpodpreset-busybox-hwyの作成が完了した後のresourceVersion: "24187"リソースバージョン番号である.
4.2、NamespaceのすべてのPodロード構成に一致する
1つ以上の指定されたPod注入情報を一致させるには、NamespaceのすべてのPod注入情報についてどのように構成すればいいですか?方法は、selector.matchLabelsを構成するときにすべてをマッチングすればよい.

$ vim podpreset-ns-test.yaml 
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: podpreset-ns-test
  namespace: podpreset-test
spec:
  selector:
    matchLabels:  #     ，    
  env:
    - name: DB_PORT
      value: "6379"
    - name: TZ
      value: Asia/Shanghai

説明:ここではmatchLabels:が空に設定されており、Namespacesの下にあるすべてのPodに一致し、podpreset-testとDB_PORT= 6379の2つの共通環境変数構成が注入されていることを示しています.注意:ここでのTZ=Asia/Shanghai環境変数構成は、Podが属するタイムゾーンを変更するために使用できます.前にCentosコンテナの内部時間方式を変更しました.Docker/K 8 sを参照して、コンテナ内のタイムゾーンの不一致を解決する方法の文章を参照してください.ここでは、新しい簡便な方法でタイムゾーンを構成することができます.これにより、名前空間のすべてのPodがタイムゾーンを統一的に変更できます(Centosのデフォルト時間はTZ=Asia/Shanghaiです).次に、このPodPresetリソースを作成します.

$ kubectl create ns podpreset-test
namespace/podpreset-test created
$ kubectl apply -f podpreset-ns-test.yaml
podpreset.settings.k8s.io/podpreset-ns-test created
$ kubectl get podpreset -n podpreset-test
NAME                CREATED AT
podpreset-ns-test   2019-07-07T03:52:42Z

次に、複数のPodをそれぞれ作成して、そのPodPreset情報を注入する.

$ vim pod-nginx-test-1.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-test-1
  namespace: podpreset-test
  labels:
    app: nginx-test-1
spec:
  containers:
    - name: nginx-test-1
      image: nginx:latest

$ vim pod-nginx-test-2.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-test-2
  namespace: podpreset-test
  labels:
    app: nginx-test-2
spec:
  containers:
    - name: nginx-test-2
      image: nginx:latest    

以上のPodリソースを作成し、情報の注入に成功したかどうかを個別に確認します.

$ kubectl apply -f pod-nginx-test-1.yaml
pod/nginx-test-1 created
$ kubectl apply -f pod-nginx-test-2.yaml
pod/nginx-test-2 created
$ kubectl get pod -n podpreset-test
NAME           READY   STATUS    RESTARTS   AGE
nginx-test-1   1/1     Running   0          26s
nginx-test-2   1/1     Running   0          20s

#                
$ kubectl exec -it nginx-test-1 -n podpreset-test /bin/sh
# printenv
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=nginx-test-1
DB_PORT=6379
HOME=/root
PKG_RELEASE=1~stretch
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.17.1
......
PWD=/
TZ=Asia/Shanghai
# date
Sun Jul  7 12:16:53 CST 2019

$ kubectl exec -it nginx-test-2 -n podpreset-test /bin/sh
# printenv
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
HOSTNAME=nginx-test-2
DB_PORT=6379
HOME=/root
PKG_RELEASE=1~stretch
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.17.1
......
PWD=/
TZ=Asia/Shanghai
# date
Sun Jul  7 12:17:26 CST 2019

このNamespaceの下の2つのPodが構成情報を注入することに成功し、タイムゾーンも変更されたことがわかりますが、便利ではないでしょうか.しかし、Namespaceの次のPodを指定してPodPresetを使用しない場合は、どのように構成すればいいのでしょうか.結局、一部のパーソナライズされたPodは汎用構成を使用しません.UTC注釈を構成して、PodがPodPresetに注入されないことを示すことができ、次に説明する.

$ vim pod-nginx-test-3.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-test-3
  namespace: podpreset-test
  annotations:
    podpreset.admission.kubernetes.io/exclude: "true"
  labels:
    app: nginx-test-3
spec:
  containers:
    - name: nginx-test-3
      image: nginx:latest

Podリソースを作成し、コンテナに情報が注入されているかどうかを確認します.

$ kubectl apply -f pod-nginx-test-3.yaml
$ kubectl exec -it nginx-test-3 -n podpreset-test /bin/sh
$ printenv | grep TZ
$ printenv | grep DB_PORT
$ date
Sun Jul  7 04:18:54 UTC 2019

無視PodPreset注入annotationsが追加された後、情報は注入されず、時間はデフォルトのpodpreset.admission.kubernetes.io/exclude: "true"時間であることがわかります.
PodPresetは、上記の2つの使い方に加えて、同じPodにマルチPodPresetを適用したり、複数のリソースタイプ(ReplicaSetなど)をサポートしたり、ConfigMapから値を取ることをサポートしたりします.また、PodPresetがPod構成と競合している場合、例えばPod Yamlコンテナマウント構成とPodPresetコンテナマウント構成が同じパスである場合、エラーメッセージが競合します.
最後に注意すべきことは、

現在PodPresetのプリセット機能は進化中ですが、関連する管理作業を大幅に簡素化し、これらの共通構成を開発者から分離し、システム管理構成にすることができます.

PodPresetはNamespaceレベルのオブジェクトで、同じネーミングスペースの下のコンテナでのみ機能します.

は現在UTCバージョンで、まだ成熟していません.例えば、作成したPodPresetに対して非常に少量の修正を実行した場合、applyまたはreplaceを再試行すると、サービス側は更新されません(親測に問題があり、再構築を削除するしかありません)、自分で試してみることができます.

参考資料

PodPreset Doc

Enable PodPreset