kubernetes configMap詳解

Kubernetes的ConfigMap說明

　　這篇博文，咱們來講一說，關於在kubernetes的pod中自定義配置的問題。

　　咱們知道，在幾乎全部的應用開發中，都會涉及到配置文件的變動，好比說在web的程序中，須要鏈接數據庫，緩存甚至是隊列等等。而咱們的一個應用程序從寫第一行代碼開始，要經歷開發環境、測試環境、預發佈環境只到最終的線上環境。而每個環境都要定義其獨立的各類配置。若是咱們不能很好的管理這些配置文件，你的運維工做將頓時變的無比的繁瑣。爲此業內的一些大公司專門開發了本身的一套配置管理中心，如360的Qcon，百度的disconf等。kubernetes也提供了本身的一套方案，即ConfigMap。kubernetes經過ConfigMap來實現對容器中應用的配置管理。

 建立ConfigMap

建立ConfigMap的方式有4種：

• 經過直接在命令行中指定configmap參數建立，即--from-literal

• 經過指定文件建立，即將一個配置文件建立爲一個ConfigMap--from-file=<文件>

• 經過指定目錄建立，即將一個目錄下的全部配置文件建立爲一個ConfigMap，--from-file=<目錄> 
  經過yaml文件來建立，另外一種是經過kubectl直接在命令行下建立。

• 事先寫好標準的configmap的yaml文件，而後kubectl create -f 建立

使用ConfigMap

使用ConfigMap有三種方式，一種是經過環境變量的方式，直接傳遞pod，另外一種是經過在pod的命令行下運行的方式，第三種是使用volume的方式掛載入到pod內

更新 ConfigMap 後：

• 使用該 ConfigMap 掛載的 Env 不會同步更新

• 使用該 ConfigMap 掛載的 Volume 中的數據須要一段時間（實測大概10秒）才能同步更新

ENV 是在容器啓動的時候注入的，啓動以後 kubernetes 就不會再改變環境變量的值，且同一個 namespace 中的 pod 的環境變量是不斷累加的，參考 Kubernetes中的服務發現與docker容器間的環境變量傳遞源碼探究。爲了更新容器中使用 ConfigMap 掛載的配置，能夠經過滾動更新 pod 的方式來強制從新掛載 ConfigMap，也能夠在更新了 ConfigMap 後，先將副本數設置爲 0，而後再擴容。

使用ConfigMap的限制條件：

configmap 必須在pod以前建立

configmap受namespace限制(

在pod對configmap進行掛載操做時，容器內部只能掛載爲目錄，沒法掛載爲文件。在掛載到容器內部後，目錄中將包含configmap定義的每一個item，若是該目錄下原來還有文件，則容器內的該目錄將會被掛載的configmap覆蓋。若是應用程序須要保留原來的其餘文件，則須要進行額外的處理。能夠將configmap掛載到容器內部的臨時目錄，再經過啓動腳本將配置文件複製或者連接到(cp或link命令)應用所用的實際配置目錄下。

Kubernetes的ConfigMap說明

參考http://www.javashuo.com/article/p-mzvdomkb-ex.html

kubernetes configMap 熱更新測試

https://www.kubernetes.org.cn/3138.html

Kubernetes的ConfigMap詳解

參考https://blog.csdn.net/liukuan73/article/details/79492374