アプリケーション構成の管理

このレッスンポイント

作成とConfigMapsシークレットとリソースを使用して、
ポッド認証の実装と原則。
コンテナリソース、セキュリティ、およびその他の事前チェックconfigureと使用。

以下の8つの領域に細分化：

アバター

需要元

背景の質問

まず、需要の源で一緒に見て。私たちは、それがコンテナを起動するために、コンテナのミラーを使用することで、この経験を持っている必要があります。コンテナを起動するには、支援のためのニーズを対処すべき多くの問題があります。

まず、例えば、いくつかの変数の設定。我々は内部に書かれたいくつかの変数の設定ミラーを置くことができないので、設定は変更を必要とするとき、私たちは鏡を再コンパイルする必要があり、これは確かに受け入れられません。
第二は、機密情報の保管及び使用です。例えば、アプリケーションは、いくつかのパスワードを使用する、またはいくつかのトークンを使用する必要があります。
第三の容器は、私たちがクラスタ自体にアクセスしたいものです。例えば、私がアクセスKUBE-apiserverにしたい、そして、認証自体は問題です。
第四は、ノード上で実行した後、そのリソース要件容器です。
第五は、カーネルを共有しているノード上のコンテナである、それはどのように行うには、安全制御ですか？
我々は試験容器の開始前に、前提条件について話最後の事。例えば、コンテナの開始前に、私は、DNSサービスが使いやすいではありません確認する必要がありますか？または確認Unicom社のネットワークではないでしょうか？そして、事実確認の前にいくつかのこと。

ポッド構成管理

これらの設定は、それを管理しない方法Kubernetesの内部には、それを何ですか？下図のように：

アバター

変数を使用するように構成さConfigMap。
機密情報は秘密です。
認証は、達成するためにこれらの独立したリソースServiceAccountです。
リソースの割り当てはリソースです。
セキュリティ制御がSecurityContextがあります。
達成するために、InitContainersでこれらのフィールドを追加したこれらのスペック構成管理を事前に確認してください。

ConfigMap

ConfigMapはじめに

レッツ・レビュー最初の部分は、ConfigMapです。レッツそれを行うために使用されているConfigMapを開始し、それがもたらす利点の一つ。実際には、いくつかの環境変数、またはいくつかのコマンドライン引数内で主に当社のアプリケーション構成ファイルの一部として、いくつかの変数の構成情報を管理し、またはそれています。

その利点は、容器の移植性を保証する可変形状ミラーと容器デカップリングの数を、可能にすることです。下の図の右側にあるファイルレイアウトのスクリーンショットを見てください。

必要なコンフィギュレーションファイル、環境変数、コマンドラインパラメータ変数構成管理の主要なコンテナ・ランタイム。ワークロードの移植（POD）のを保護するために、容器及び可変設定するためのミラーを切り離します。

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-system
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "type": "flannel",
      "delegate":{
        "isDefaultGateway": true
      }
    }
  net-conf.json: |
  {
    "Network": "172.27.0.0/16".
    "Backend": {
      "Type": "vxlan"
    }
  }

メタ情報は、我々は、名前と名前空間情報の両方を懸念している、ConfigMapです：これは2つの部分から構成定義ConfigMap自体、です。次に、データの内部には、あなたはそれが2つのプロファイルを管理する見ることができます。実際には、その構造はこれです：値、キー値は、ファイルの内容で、ファイル名です：ConfigMapを参照するには名前から地図、地図は、実際のキーである言葉が含まれています。

ConfigMapを作成します

導入を読んだ後、それが作成された方法で、より具体的な外観。1は、指定された名前であり、第二は、DATAです：我々は2つがあることを引数で、作成するkubectlこのコマンドを使用することをお勧めします。DATAはだけでなく、直接、キーと値のペアを指定すると、あなたは以下の例を見ることができ、指定されたファイルまたはディレクトリを指定することができます。

コマンドを作成します。kubectl create configmap [NAME] [DATA]

どのデータ：

指定されたファイルまたはディレクトリ

サンプルを作成するファイルを指定します。

kubectl create configmap kube-flannel-cfg --from-file=configure-pod-container/configmap/cni-conf.json -n kube-system

kubectl get configmap kube-flannel-cfg -o yaml
apiVersion：v1
kind: ConfigMap
metadata:
  labels:
    app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-system
data: 
  cni-conf.json: |  # 文件名字作为key
    {  # 文件内容作为value
      "name": "cbr0",
      "type": "flannel",
      "delegate": {
        "isDefaultGateway": true
      }
    }

作成されたキーと値のペアを指定します。

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

kubectl get configmap special-config -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:  # 输入的键值对
  special.how: very
  special.type: charm

指定されたファイルは、ファイル名がマップのキーである場合は、ファイルの内容は、値の地図です。キー：マップキーに直接マッピングされた値の形式、：値そして、キーと値のペアが指定されたデータ、すなわちへの鍵である指定。

ConfigMapの使用

あなたが完了し作成したら、それを使用する方法をすべきですか？

主に使用ポッドConfigMapは、一般的に、環境変数、コマンドラインパラメータをポッド・コンフィギュレーション・ファイルをマウントするために使用されます。

ConfigMap構成環境変数によって実施例1]）

apiVersion:
kind: Pod
metadata:
  namp: cm-env-test
spec:
  containers:
    - name: test-container
      iamge: k8s.gcr.io/busybox
      command: ["/bin/sh","-c","env"]
      env:
        # 用apecial-config中的specila.how定义环境变量
        - name: SPECILA_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
  restartPolicy: Never

実施例2 :(ライン設定パラメータconfigMap制御コマンド）

apiVersion: v1
kind: Pod
metadata:
  name: cm-cmd-test
spec:
  containers:
    - name: test-container
      iamge: k8s.gcr.io/busybox
      command: ["/bin/sh","-c","echo ${SPECILA_LEVEL_KEY}"]
      env:
        - name: SPECILA_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_LEVEL
  restartPolicy: Never

例3：ConfigMapとマウントのプロフィール

apiVersion: v1
kind: Pod
metadata:
  name: cm-value-test
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: ["/bin/sh","-c","ls /etc/config"]
      valumeMonuts:
        - name: config-value
          mountPath: /etc/config
  valumes:
    - name: config-valume
      configMap:
        name: special-config
  restartPolicy: Never

これは主に、上記図ConfigMapに使用ポッドに、示されています。

最初は、環境変数です。その後、ConfigMapKeyRefこのフィールドvalueFromおよび、によって、次の名前がConfigMap名を指定された環境変数は、その後、キーは、キーの内側にConfigMap.dataです。この場合、後にスタートbusyboxのコンテナ船は、ENVは、SPECIALが表示されます行っLEVELの KEY環境変数。
第二は、コマンドラインパラメータです。コマンドラインパラメータを実際に直接使用するには、このフィールドの中に入るCMDの環境変数の最初の行です。
最後のものは、直接の容器への道にリンクされているボリュームの負荷の下のディレクトリです。上記の例では、容器内の/ etc / configディレクトリ内のコンテンツにリンクされた特殊設定ConfigMapは、これも使用する方法であることです。

ノートにConfigMapポイント

今ConfigMapの使用は、ポイントに記載されている次の5つのポイントの合計に注意を払うの概要ならびにその関心のいくつかの操作を行います。

ConfigMapファイルサイズ。ConfigMapファイルが、サイズ制限なし、しかしETCDの内部には、書き込みデータのサイズが制限され、現在は1MB未満に制限されています。
第二の点が導入されたときConfigMapポッドはConfigMap名前空間で同じである必要があり、実際にはフロント缶が見られることに留意されたい、ConfigMap.metadata名前空間フィールドです。
第三は、ポッドConfigMapが挙げられます。このConfigMapが存在しない場合は、その後、ポッドは実際には、成功を作成することができません、これはまた、ポッドを作成する前に、最初のConfigMapを作成し、参照しなければならないことを意味します。
第四点は、envFromの方法を使用することです。ConfigMapは、いくつかの重要で、このような内部の番号のキー名として、有効でない場合は、環境変数にすべてのインポート情報ConfigMapの内部には、この環境変数は、実際の容器に注入されていない場合、それは無視されます。しかし、ポッド自身が作成することができます。そして第三の点は、同様に、ファイルに基づいて、ないConfigMap存在し、全体のフォーム環境変数に導入します。
最後のポイントは以下のとおりです。どのようなポッドのConfigMapを使用しますか？そこだけ作成するコマンドラインkubectlポッドを使用することにより、例えば、K8S ConfigMapを使用して作成されたAPIにポッドされて、あなたは確かにConfigMapを使用することができますが、作成された静的ポッドマニフェストkubeletすることにより、たとえば、他の方法で作成されたポッドは、それがありますあなたはConfigMapを使用することはできません。

秘密

シークレットはじめに

今、私たちは、秘密、秘密の話をトークンなどのリソースの機密情報保存されたパスワードの主要な標的です。機密情報がbase-64でエンコードを使用して保存されている、我々は秘密データ図の定義を見て。

apiVersion: v1
kind: Secret # Secret元数据
metadata: 
  name: mysecret
  namespace: kube-system
type: Opaque
data:
  username: YYUYYYLKSD
  password: sjdfksdklflkll=

メタデータ、そして、主に、名前空間の2つのフィールド名である。タイプが続き、それはそれは秘密のタイプを指し、非常に重要な分野です。秘密のタイプより多くの種は、次の4つの一般的な種類が記載されています：

まず、それは共通の秘密文書で、不透明です。
第二は、サービス・アカウント・トークンで、サービスアカウント認証のための秘密の使用;
第三は、倉庫ミラーを引っ張ることによって、個人秘密でdockerconfigjson、です。
第四はbootstrap.tokenされ、秘密はチェックして、クラスタのアクセスノードです。

データはまた、キーと値のストアの形態で、秘密データを格納され、続きます。

シークレットを作成します。

次に、我々は秘密の創造を見てください。

作成するには、2つの方法があります。

システムが作成されます。デフォルトのユーザー（デフォルトServiceAccount）シークレットを作成し、各名前空間の例K8Sため。
ユーザーが手動で作成：コマンドを手動で作成するには、kubectlこのコマンドラインツールをお勧めします、それはConfigMapは、1つの以上の型パラメータになります比較的です。データが同じである場合、ファイルやキーと値のペアを指定することも可能です。指定しない場合、その後、入力し、デフォルトでは不透明タイプです。

秘密は自動的にシークレットを作成するためのシステムがあり、ユーザーが作成し作成することができます

たとえば：シークレット作成した各ユーザー（デフォルトServiceAccount）のデフォルトの名前空間をK8S

コマンドを手動で作成します。secrtジェネリック[NAME]を作成kubectl [DATA] [TYPE]

前記データ：ファイル/値のペアを指定することができます

不透明デフォルト：ほかのタイプ

ファイルの作成を指定します。

kubectl create secret generic myregistrykey --from-file=.dockerconfigjson=/root/.docker/config.json –type=kubernetes.io/dockerconfigjson

apiVersion: V1
kind: Secret
metadata:
  name: myregistrykey
  namespace: default
data: 
  .dockerconfigjson: jflsdkjfklsdjflksdjflksjdfkjsdklfjalkqqqqqqqqqqqqqqqqqqqqqqqkljdflksjdfdsf
type: kubernetes.io/dockerconfigjson

キーと値のペアを指定します。

kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11

apiVersion: v1
data: 
  password: tttttslejkljlk
  username: ChjsldfiwenkHH
kind: Secret
meatdata:
  name: prod-db-secret
  namespace: default
type: Opaque

二つの例上記の図。最初のファイルを指定することで、プル秘密のプライベート倉庫ミラーリングを作成され、指定されたファイルが/root/.docker/config.jsonです。指定されたタイプがdockerconfigjsonであれば、我々は我々の種類が指定されていない場合、デフォルトは不透明である、他のキーと値のペアを指定します。キーと値のペアは、キーです：コンテンツbase64で暗号化の値値の形で。秘密は、このような状況を作成することです。

秘密の使用

シークレットを作成したら、それを使用する方法を見て。これは主にポッドで使用され、通常は、コンテナのビジネスプロセスと、その後、使用する秘密のカタログを読み取るために、コンテナ指定されたディレクトリを形成するために、ボリュームによって取り付けられています。また、民間の倉庫にミラーが必要へのアクセスではなく、参照の秘密によって実現しています。

実施例1：（Sectetは、ユーザ指定されたディレクトリにマウント）

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts: # secret以文件形式挂载在/etc/foo下
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo  
    secret:  # 指定要挂载的secret
      secrteName: mysecret

例2：（SeviceAccountが自動的に固定秘密のディレクトリ（ca.crt生成トークンと2つのファイルを）使用してマウント）

apiVersion: v1
kind: Pod
metadata: 
  name: nginx-sjdlrkj325-mdfp5
  namespace: default
spec:
  containers:
  - iamge: nginx: 1-alpine
    name: nginx
    - volumeMounts: # 固定挂载到容器中的/var/run/secret/kubernetes.io/serviceaccount目录下 /var/run/secret/kubernetes.io/serviceaccount
      name: default-token-666i8
      readonly: true
  serviceAccount: default
  serviceAccountName: default # 使用namespace默认的serviceaccount
  volumes:
  - name: default-token-6lsdkjf
    secret:
      defaultMode: 420  # 挂载namespace默认的secret
      secretName: default-token-6fjsi

道をマウントするユーザーが指定したディレクトリで見てみましょう：

第一実施形態：図に示すように、容器mysecretの/ etc / fooのディレクトリをマウントするため、ユーザが直接指定し、左;
第二の実施形態：、右図に示すシステムは、自動的に生成されるように、serviceaccount秘密が自動的に下部容器/var/run/secrets/kubernetes.io/serviceaccountディレクトリに取り付けられ、これは2つのファイル、あるCAを生成します.CRT、それはトークンです。これらは、2つの証明書ファイルの認証情報を保存します。

プライベートイメージライブラリを使用します

秘密はミラーを見て、次の民間倉庫で使用されます。まず、個人情報は（作成は、特に秘密のセクションを参照）、及び2つの方法で構成することができ、画像の下に、ミラープライベートリポジトリを引くイメージリポジトリ秘密の内部に格納されています。

第一実施形態：直接ポッド内部、左側に示されるように、imagePullSecretsフィールドによって構成される。
第二の方法は、自動的に注入されます。予めユーザ設定imagePullSecretsポッドがimagePullSecrets注入システムを自動的に作成し、serviceaccountポッドに使用されます。

指定imagePullSecret

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container
    image: <你的镜像>
  imagePullSecret：
  - name: regcred

アバター

ノートへのポイントの秘密使用

最後に、次の3つのポイントを秘密が使用の注意点をいくつか見てみましょう：

最初は、秘密のファイルサイズの上限です。このConfigMapのように、それは1MBです。
第二には、秘密は、ベース64符号化を使用しているが、それは平文との大きな違いはありません。機密情報の秘密ストアの一部の使用があるのであれば、それは非常に慎重に検討する必要があります。それはあなたとこの秘密のだろう、このクラスタを訪問しようとしている人であることは、クラスタにアクセスすることができれば、あなたは秘密を得ることができますので、まだ、慎重に考慮しなければなりません。

機密情報は、秘密が要求されている場合は、この暗号化のための強い需要が推奨されるとKubernetesがアドレス著作権管理や機密情報の暗号化にボールトオープンソースソリューションを行うに使用することができますがあります。

すべてをプルダウンします名前空間の下にリスト/時計操作は、すべての秘密は、これは実際により多くの情報にさらされている場合は第三のベストプラクティスは、秘密を読み取ることで、リスト/ウォッチをお勧めしません。あなただけの秘密自身のニーズを得るので、推奨メソッドをGET。

ServiceAccount

はじめにServiceAccount

次に、我々はServiceAccountについて話しています。ServiceAccountザは第一ポッド内部クラスタ内認証の問題を解決するために使用され、認証情報が秘密の内部に存在します。

アバター

上のスクリーンショットの左側を見て、あなたが赤いボックスの一番下を見ることができ、これはK8Sが自動的ServiceAccountを追加している秘密と指定ServiceAccountという秘密のフィールドがあります。そして、テーマ上図の右側を見て、それに対応するデータの秘密のデータは、2つあり、一つはトークンで、ca.crtです。サービスの終了を確認するためのca.crtは、認証のためのポッドトークンは、それらがBASE64でエンコードされています。そして、あなたはメタ情報であるメタデータを参照することができ、実際には、リンクServiceAccount情報（秘密はどのServiceAccountによって使用されている）があります。最後に、我々は、これがこの種のサービス・アカウント・トークンで、タイプに注意してください。

たとえば、次のようにそれが属するアプリケーションアクセスK8Sクラスタ内のポッド

それに対応するServiceAccountと秘密を紹介した後、我々は見て、ポッドはそれをServiceAccountまたは使用の秘密を使用する方法であるあなたのK8Sクラスタにアクセスする方法です。

ポッドが作成されたときに実際には、それは最初にすべての秘密のにK8S関数に実装されているディレクトリコンテナを、マウントに固定します。これは、このca.crtを入れて、これらの2つのファイルのトークンマウント固定ディレクトリに移動します。

ポッドは、それがこのファイルにそれを使用する方法であるとき、クラスタにアクセスするには？私たちは、スクリーンショット、以下のコードを見て：

アバター

私たちは、ポッドアクセスK8Sクラスタ囲碁の内側を実現する場合、一般的には、サービスのクライアントにアクセスするには、この情報の一部を生成するInClusterConfigの道に直接転送されます。その後、二つの情報があり、この最後のコンフィグレーションを見ることができます：

tlsClientConfigが、これは主に使用ca.crt検証サーバです。
二つ目は、これはポッド認証で、ベアラトークンです。ポッドのサーバー側で使用認証トークンになります。

再び左側にあります。身元認証情報の完了後のポッドは2つの部分があります。一つは、グループでのユーザーです。アイデンティティ認証は、情報の2枚です。その後、ポッド権限管理を行うためにRBAC機能を使用することができます。

RBACが設定されていない場合、ポッドのデフォルトのアクセス権は、リソースのGETを持っているK8Sがクラスタに属しているから、あなたがデータを得ることができるということです。それはより多くの権限を必要とする場合、あなたは自分のRBACを設定する必要があります。私たちは、後のレッスンで詳しく、私たちが見ることができます知識を、RBACは関連します。

資源

とコンテナのリソース管理

リソース構成管理コンテナ：ここではいくつかのリソース、すなわちです。

CPU、メモリ、および一時記憶：現在、内部サポートの3つのタイプがあります。あなたは、これらの3つを考えるときには十分ではありません、そのようなGPU、またはその他のリソースなど、独自のリソースのいくつかがあり、また、あなた自身を定義することができますが、設定時に指定した数は整数でなければなりません。現在のリソースの割り当てと制限要求は二つのタイプに分割され、一つは必要な量のリソースが限界です。CPU、メモリおよびストレージは、コンテナ内の下の文のリソースフィールドに一時的に行われています。

リソースの種類をサポートしています：

CPU：単位：millicore（1コア= 1000millicore）
メモリ：単位：バイト
はかないストレージ（一時保存）：単位：バイト
カスタムリソース：あなたは整数でなければなりません設定します

構成：

二つのタイプの要求/限界へのリソースの割り当て

CPU
- spec.containers []。resources.limits.cpu
- spec.containers []。resources.request.cpu
メモリ
- spec.containers []。resources.limits.memory
- spec.containers []。resources.request.memory
はかないストレージ（一時保存）
- spec.containers []。resources.limit.epherneralストレージ
- spec.containers []。resources.request.epherneralストレージ

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: wp
    iamge: wordpress
    resources:  # 申明需要的资源
      request：
        memory: "64Mi"
        cpu: "250m"
        ephemeral-storage: "2Gi"
      limits:
        memory: "128Mi"
        cpu: "500m"
        ephemeral-storage: "4Gi"

例えば、リソース要件ワードプレスコンテナ、1つの要求、声明を行うために必要なリソースとリソースのための重要な1つの制限、。

サービスのポッド品質（QoS）の設定

CPU・メモリは、コンテナ資源の需要に応じて、我々はサービスポッド、保証され、バースト可能とにBestEffortの質の分類を行いました。

保証：これが保証され、各コンテナ内のポッドは、メモリとCPUの要求や制限の文を持っている必要があり、その要求と制限が同じでなければなりません。
破断可能な：少なくともCPUとメモリ要求を有する容器の破断可能な存在。
BestEffort：限りにBestEffortで保証されており、バースト可能な、など。

まあ、これはどのようなサービスの品質のことですか？アウト追放POD：リソースの割り当てが良いです後、このようなノードの割当てリソース上のメモリ不足など、このノードポッドコンテナ、上で実行している場合、kubeletは、いくつかの低優先順位をつけ、以下の（にBestEffort、バースト可能なような）サービスの品質を要求します。彼らは、最初の除去にBestEffortに基づいて、その後、ポッドを追放するバースト可能な順序を削除します。

SecurityContextが

はじめにSecurityContextが

SecurityContextが挙動は主にコンテナを制限するために使用され、それは、セキュリティ、およびその他のコンテナを確保することができます。この機能は、ユーザーがKubernetesまたはコンテナのランタイム機能ピースそのものではなく、Kubernetesと実行時設定ではなく、最終的にはカーネルの下に達し、その後、カーネルのメカニズムを介したSecurityContextを有効にするように。そこでここで話していた、それは、よりシンプルまたはもう少し抽象的になります。

SecurityContextが3つのレベルに分かれて：

最初のレベルは、容器は、容器のみ有効になります。
第2のレベルは力にすべてのコンテナ内のポッドのために、ポッドです。
第三は、クラスタ・レベルで、PSP、すべてのポッドクラスター効果があります。

権限とアクセス制御設定は、今（フォローアップの数は変更になる場合があります）7の合計を示しています。

第任意アクセス制御は、ユーザIDとグループIDを介してファイルへのアクセスを制御することです。
第二は、ポリシーの設定を介してファイルやプロセスへのユーザーアクセス制御を制御するもので、SELinuxのです。
第三の特権容器の特権です。
第四は、それはまた、特定のプロセスにある設定への特権の能力で、Linuxの機能です。
第五は、AppArmorのですが、それはまた、そのようなポートの一部を読み取り、書き込みなど、いくつかの構成ファイルを介して、実行可能ファイルのアクセス制御権を制御します。
第Seccompは、システムコールのうちの一つの制御です。
第七AllowPrivilegeEscalationは、子プロセスが父の許可よりも制限を取得することができます。

実際には、昨年秋には、その権限の一部を制御するコアです。

アバター

図は、コンテンツのためのより多くの需要を持っている場合、あなたはより詳細な情報を検索するには、この情報を知ることができ、ポッドたSecurityContextレベルおよびコンテナレベルの構成の一例です。

InitContainer

InitContainerはじめに

その後InitContainer、最初に導入区別InitContainerと通常のコンテナ、次の3点を見てみましょう。

InitContainerは、最初に通常のコンテナの前に開始され、正常に実行された後に、すべてのInitContainerまで、通常のコンテナが有効になります。
InitContainerは、通常のコンテナが同時に開始されている間、第二の実装を成功した後に再度行う実行を開始するために定義されている間には、
通常のコンテナが実行されている可能性がありながらInitContainerは、終了の成功裡の妥結後に実行しました。これは、長年のであってもよいし、それが失敗し再起動しますが、これは通常のコンテナInitContainerの場所と異なっています。

上記の3つのポイントによると、私たちはInitContainerの使用を見てください。実際には、それは主に通常のコンテナサービスは、例えば、それは普通のコンテナを開始する前に初期化し、またはそれはいくつかの設定ファイルを準備するために、設定ファイルがいくつか変更することも行うことができますです。別の例は、ユニコムのネットワークかどうかなどの検証のいくつかの前提条件を実行することです。

アバター

上記のスクリーンショットは、それがKUBE-フランネル通常コンテナが開始する前に、このためInitContainerネットワークプロファイルの一部を製造するために主に、フランネル成分の構成InitContainerあります。

結論

ConfigMapと秘密：秘密はConfigMapと作成と使用のシナリオの方法を紹介した後、共通点のConfigMapの注意を使用して、秘密と仕上げを分類しました。最後に、使用してミラーリング構成民間倉庫。
ポッド認証：最初に導入され、秘密ServiceAccount関係、次いでポッド認証プロセスとリードポッド権管理（すなわち、RBAC構成管理）しながら、ソースの観点から実装の詳細を分析します。
コンテナリソースとセキュリティは：第1の共通のコンテナリソースタイプ（CPU /メモリ）の設定を導入し、その後、ポッドの分類内容に対するサービスの品質。一方SecurityContextが効果的な階層的な権限と設定項目の簡単な説明。
InitContainer：最初はInitContainer通常の容器とのInitContainer差の使用を導入しました。次に、本実施形態の実際の使用に基づいてInitContainer使用を説明してきました。

第8章：アプリケーション構成の管理

アプリケーション構成の管理

需要元

背景の質問

ポッド構成管理

ConfigMap

ConfigMapはじめに

ConfigMapを作成します

サンプルを作成するファイルを指定します。

作成されたキーと値のペアを指定します。

ConfigMapの使用

ノートにConfigMapポイント

秘密

シークレットはじめに

シークレットを作成します。

秘密の使用

プライベートイメージライブラリを使用します

ノートへのポイントの秘密使用

ServiceAccount

はじめにServiceAccount

たとえば、次のようにそれが属するアプリケーションアクセスK8Sクラスタ内のポッド

資源

とコンテナのリソース管理

サービスのポッド品質（QoS）の設定

SecurityContextが

はじめにSecurityContextが

InitContainer

InitContainerはじめに

結論

おすすめ