最初のコンテナをkubernetes（初期化コンテナー）

シリーズカタログ

最初のコンテナを理解します

あなたが複数のコンテナを実行することができポッドは、それが最初のコンテナの一つ以上を実行することができ、初期のアプリケーションコンテナを実行する前に、コンテナは、次の2点を除いて、最初のコンテナとコンテナの一般的には違いはありません。

彼らは常に、run to completion
容器の初期の成功は、別の実行に実行する必要があります

コンテナ内の最初の実行ポッドに障害が発生した場合、kubernetesが正常に最初の実行まで、ポッドコンテナを再起動しようとするポッド再起動ポリシーが設定されている場合、从不(never)それは再起動しません。

コンテナが作成されると、内podspecを添加しinitContainers、その復帰状態で配列として格納され、最初のコンテナ船が指定されるフィールド、.status.initContainerStatusesここで、（通常のコンテナ状態格納欄.status.containerStatuses類似）

異なる初期コンテナと通常のコンテナ：

最初の容器は、リソースクォータおよびセキュリティ設定を含むすべての一般的な容器、およびストレージ・ボリュームをサポートしていますが、リソースの要求と初期制限処理容器はわずかに異なっていると説明する。また、最初の容器は、プローブ（準備プローブ）の可用性をサポートしない、請求それがためにready前にでなければなりませんrun to completion

あなたは、彼らがしますポッドで複数の初期のコンテナを指定した場合依次（ポッド普通のコンテナが並行して開始）を起動し、唯一の次に成功したスタートに。最初のコンテナのすべてがすでに開始されている場合は、kubernetesを開始し始めました一般的なアプリケーションコンテナ。

最初のコンテナを何をします

最初のコンテナとコンテナは、ミラーの一般的なアプリケーションから分離されているので、彼はいくつかの初期化の大きな利点をやっているので：

彼らは含まれており、セキュリティ上の理由から、一部のガジェットを実行して、一枚の上での使用に適していないことができます。
彼らはいくつかの初期化作業を行うためのいくつかの小さなツールとカスタムコードであってもよいので、あなたは、一般的なアプリケーションコンテナを使用する必要はありませんsed、awk、pythonまたはdigの最初の仕事をします
アプリケーションビルダーと出版社が一緒にポッドに対処することなく、独立して動作することができます
彼らは、Linuxを使用してnamespaces、彼らと一般的なアプリケーションポッドは、ファイルシステムの別のビューを持っているので、彼らは一般的なアプリケーションに与えることができるが、コンテナ未満を取得しますので、secrets
彼らは、アプリケーションコンテナの前に実行を開始し、その条件を満たすために必要となるまで、彼らは一般的なアプリケーションコンテナの初期化を防止または遅延させることができます

例：

シェルコマンドを実行することで、以下のコマンドで作成したサービスを待機します：

for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1

downward API次のようにリモートサーバに登録された現在のポッド、コマンドは次のとおりです。

curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'

コンテナの開始前に一定の時間を待ちます。たとえば、sleep 60
ストアディレクトリにgitリポジトリのクローンを作成
動的ないくつかの値は、メインアプリケーションのテンプレートツールを使用して設定ファイルに書き込まれます。

より詳細な例では、アプリケーション環境ポッド参照してくださいに配置ガイド

コンテナの初期使用

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

2つの初期ポッド容器を含有する上記で定義され、第一の待機myserviceサービスが利用可能である、第二のを待っているmydbサービスが利用可能である、2つのポッド実行が完了すると、コンテナアプリケーションが実行を開始します。

以下はあるmyserviceとmydb2つのサービスYAMLファイル

kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

上記で定義すると、次の初期化を使用して、ポッドおよびデバッグすることができ

kubectl create -f myapp.yaml
pod/myapp-pod created

kubectl get -f myapp.yaml

NAME        READY     STATUS     RESTARTS   AGE
myapp-pod   0/1       Init:0/2   0          6m

Name:          myapp-pod
Namespace:     default
[...]
Labels:        app=myapp
Status:        Pending
[...]
Init Containers:
  init-myservice:
[...]
    State:         Running
[...]
  init-mydb:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Containers:
  myapp-container:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Events:
  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
  ---------    --------    -----    ----                      -------------                           --------      ------        -------
  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634

kubectl logs myapp-pod -c init-myservice # Inspect the first init container
kubectl logs myapp-pod -c init-mydb      # Inspect the second init container

ときに我々はスタートmydbし、myservice2つのサービスの後、我々は最初のコンテナの完成を見ることができるし、myapp-podポッドが作成されます。

kubectl create -f services.yaml

service/myservice created
service/mydb created

kubectl get -f myapp.yaml
NAME        READY     STATUS    RESTARTS   AGE
myapp-pod   1/1       Running   0          9m

これらの例は非常に単純ですが、あなたは自分だけのオリジナルのコンテナを作成するためにいくつかのインスピレーションを提供することができるはずです

行動の詳細

ランタイムエラーまたは他の異常終了のため、それが続く場合は作成するために元の容器、ストレージボリュームとネットワークの作成後、中に発射ポッドの間に。コンテナは、開始するには、次の成功を返さなければなりませんrestartPolicyが、再試行し、場合restartPolicyに設定されAlwaysた初期の容器、実際に使用しOnFailureた戦略を
ポッド再起動した場合、その後、すべての元の容器の再実行されるように
最初の容器spec変更は镜像(image)初期コンテナを変更に対応して、ポッド修飾フィールド画像フィールドを再起動します
ファイルの書き込みに、特に、電源コード等があるべきであるように初期の容器は、再試行を再起動し、再実行することができるのでEmptyDirs、ファイルが既に存在してもよいことに留意すべきコードを
すべての最初のコンテナ船と通常のコンテナ名は一意である必要があります。

リソース

最初の容器の実行順序に基づいて、以下のルールがリソースに関して適用されます。

特定のリソース、すべてのコンテナアプリケーションの力への最高の初期エントリのために
ポッドのために、高い次の2を取るために同じリソース要求：

1）すべての共通リソース・アプリケーション・コンテナ・アプリケーションの和
容器リソースアプリケーションの初期力（上記によると、容器に最大のコンテナのすべての初期アプリケーションを取る最初のリソース要求）の2）
最初のコンテナがリソースを予約するために適用することができることを意味し有効にする最初の要求に基づいて、スケジューリング、ポッド後のライフサイクル全体がより少ない場合でも、

ポッド再起動の理由

以下に示すポッド上の理由から、初期の容器を再実行して、再起動します：

コンテナの初期ユーザーの更新PodSpecミラーの変化に結果を。一般的なアプリケーションコンテナの変更は、アプリケーションコンテナを再起動します
以来restartPolicy設定されているAlways、すべてのコンテナは、レコードのごみ容器の初期の損失の初期状態から、力の再起動を一時停止している原因