Kubernetes init container
阿新 • • 發佈:2018-04-12
模板 簡介 等等 服務 後臺 內容 容器 特性 erp
[toc]
簡介
在很多應用場景中,應用在啟動之前都需要進行如下初始化操作:
- 等待其他關聯組件正確運行(例如數據庫或某個後臺服務)
- 基於環境變量或配置模板生成配置文件
- 從遠程數據庫獲取本地所需配置,或者將自身註冊到某個中央數據庫中
- 下載相關依賴包,或者對系統進行一些預配置操作
kubernetes v1.3引入了一些alpha版本的新特性init container(在v1.5版本時被更新為beta版本),用於在啟動應用容器之前 啟動一個或多個“初始化”容器,完成應用容器所需的預置條件。init container與應用容器本質上是一樣的,但它們是僅運行一次就結束的任務,並且必須在成功執行完成後,系統才能繼續執行下一個容器。根據pod的重啟策略,當init container執行失敗,在設置了RestartPolicy=Never時,pod將自動啟動失敗;而設置RestartPolicy=Always時,Pod將會被系統自動重啟。
配置
下面以一個nginx應用為例,在啟動nginx之前,通過初始化容器busybox為nginx創建一個index.html的主頁文件。這裏為init container和nginx設置了一個共享的volume,以供nginx訪問init container設置的index.html文件:
nginx-init-containers.yaml內容如下:
apiVersion: v1 kind: Pod metadata: name: nginx annotations: spec: initContainers: - name: install image: busybox command: - wget - "-O" - "/work-dir/index.html" - "http://kubernetes.io" volumeMounts: - name: workdir mountPath: "/work-dir" containers: - name: workdir image: nginx ports: - containerPort: 80 volumeMounts: - name: workdir mountPath: /usr/share/nginx/html dnsPolicy: Default volumes: - name: workdir emptyDir: {}
init container與應用容器的區別
簡單的說明一下兩者的區別:
- init container的運行方式與應用容器不同,它們必須先於應用容器執行完成,當設置了多個init container時,將按順序逐個運行,並且只有前一個init container運行成功後才能運行後一個init container。當所有init container都成功運行後,kubernetes才會初始化pod的各種信息,並開始創建和運行應用容器。
- 在init container的定義中也可以設置資源限制、volume的使用和安全策略等等。但資源限制的設置與應用容器不同:
- 如果多個init container都定義了資源請求/資源限制,則取最大的值作為所有init container的資源請求值/資源限制值。
- pod的有效資源請求值/資源限制值取以下二者中的較大值:
- 所有應用容器的資源請求值/限制值之和
- init container的有效資源請求值/限制值
- 調度算法將基於pod的有效資源請求值/限制值進行計算,也就是說init container可以為初始化操作預留系統資源,即使後續應用容器無須使用這些資源。
- pod的有效QoS等級適用於init container和應用容器。
- 資源配額和限制將根據pod的有效資源請求/限制,與調度機制一致。
- init container不能設置readinessProbe探針,因為必須在它們成功運行以後才能繼續運行pod中定義的普通容器。將pod重啟時,init container將會重新運行,常見的pod重啟場景如下:
- init container的鏡像被更新時,init container將重新運行,導致pod重啟,僅更新應用容器的鏡像只會使得應用容器被重啟。
- pod的infrastructure容器更新時,pod將會重啟。
- 或pod中的所有應用容器都終止了,並且RestartPolicy=Always時,則pod將會重啟。
Kubernetes init container