Init Container

當我們在運用一個服務之前，通常會做一些初始化的工作，而這些工作一般隻需要運作一次，成功後就不再運作。為此kubernetes 引入了Init Container,用于在啟動應用容器之前啟動一個或多個“初始化”容器，完成應用容器的所需的預制條件。

Init Containers與正常的容器非常類似，但是它一些獨有的特征：

他們僅運作一次，成功後就會退出。

每個容器必須在成功執行完成後，系統才能繼續執行下一個容器。

如果Init Container運作失敗，kubernetes 将會重複重新開機Pod,直到Init Container 成功運作，但是如果 Pod的重新開機政策（restartPolicy）設定為Never,則Pod不會重新開機。

Init Container支援普通應用Container的所有參數，包括資源限制，挂載卷，安全設定等。但是Init Container 在資源的申請和限制上略有不同，同時，由于Init Container必須在Pod ready之前完成并退出，是以它不支援 readiness 探針。

Init Container 通常有如下應用方式：

處于安全的考慮，可以将自定義的代碼和工具使用Init Container運作，而不必添加到 應用 容器的鏡像中。

應用程式映像的建構和部署者角色可以彼此獨立，無需共同建構單個應用程式映像

使用不同的Linux命名空間，可以使它們具有來自應用容器的不同檔案系統權限。 是以，Init Container可以獲得應用程式容器無法通路的Secrets。

Init Container在任何應用程式容器啟動之前運作完畢，而應用程式容器通常是并行運作的，是以初始容器提供了一種簡單的方法來阻止或延遲應用程式容器的啟動，直到滿足一些前提條件。

具體的應用場景示例：

如使用shell 指令，等待服務被建立：for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1

如使用downward API将自身Pod資訊注冊到遠端伺服器上：curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d ‘instance=$()&ip=$()’

在啟動應用之前，等待一段時間：sleep 60

從git倉庫拉取配置或代碼到指定的挂載卷中

使用模闆工具動态的生成配置，并給配置檔案添加合适的參數。如使用Jinja模闆将POD IP添加到應用容器的配置中。

這裡定義一個nginx，在nginx容器啟動前更改預設起始頁面内容：

建立容器後，可以看到，先執行初始化操作：

Pod中的每個應用程式和Init Container的名稱必須是唯一的; 任何Container與另一個Container共享一個名稱都會引發驗證錯誤。

在Pod重新啟動時， init Container 将會重新運作，那麼所執行的初始化操作也會再次執行，這就要求Init Container的操作是可以重複執行的。例如上面的示例中，在對挂載目錄中檔案的添加前，可以先判斷檔案是否已經存在的處理，來防止出錯。

常見的Pod重新開機場景如下：

init container的鏡像被更新時， init Container将會重新運作，導緻Pod重新開機。僅更新應用容器的鏡像，隻會使得應用容器被重新開機。

Pod的 pause鏡像更新時， Pod将會重新開機。

若Pod 中的所有應用容器都終止了，并且restartPolicy=always, 則Pod将會重新開機。