Kubernetes & Annotation & ConfigMap

Annotation

Annotation（註解）與Label類似，也使用key/value鍵值對的形式進行定義。不同的是Label具有嚴格的命名規則，它定義的是Kubernetes物件的元資料（Metadata），並且用於Label Selector。Annotation則是使用者任意定義的附加資訊，以便於外部工具查詢。在很多時候，Kubernetes的模組自身會通過Annotation標記資源物件的一些特殊資訊。

通常來說，用Annotation來記錄的資訊如下。

• ◎　build資訊、release資訊、Docker映象資訊等，例如時間戳、release id號、PR號、映象Hash值、Docker Registry地址等。
• ◎　日誌庫、監控庫、分析庫等資源庫的地址資訊。
• ◎　程式除錯工具資訊，例如工具名稱、版本號等。
• ◎　團隊的聯絡資訊，例如電話號碼、負責人名稱、網址等。

ConfigMap

為了能夠準確和深刻理解Kubernetes ConfigMap的功能和價值，我們需要從Docker說起。我們知道，Docker通過將程式、依賴庫、資料及配置檔案“打包固化”到一個不變的映象檔案中的做法，解決了應用的部署的難題，但這同時帶來了棘手的問題，即配置檔案中的引數在執行期如何修改的問題。

我們不可能在啟動Docker容器後再修改容器裡的配置檔案，然後用新的配置檔案重啟容器裡的使用者主程序。為了解決這個問題，Docker提供了兩種方式：

• ◎　在執行時通過容器的環境變數來傳遞引數；

• ◎　通過Docker Volume將容器外的配置檔案對映到容器內。

這兩種方式都有其優勢和缺點，在大多數情況下，後一種方式更合適我們的系統，因為大多數應用通常從一個或多個配置檔案中讀取引數。但這種方式也有明顯的缺陷：我們必須在目標主機上先建立好對應配置檔案，然後才能對映到容器裡。

上述缺陷在分散式情況下變得更為嚴重，因為無論採用哪種方式，寫入（修改）多臺伺服器上的某個指定檔案，並確保這些檔案保持一致，都是一個很難完成的目標。此外，在大多數情況下，我們都希望能集中管理系統的配置引數，而不是管理一堆配置檔案。針對上述問題，Kubernetes給出了一個很巧妙的設計實現，如下所述。

首先，把所有的配置項都當作key-value字串，當然value可以來自某個文字檔案，比如配置項password=123456、user=root、host=192.168.8.4用於表示連線FTP伺服器的配置引數。這些配置項可以作為Map表中的一個項，整個Map的資料可以被持久化儲存在Kubernetes的Etcd資料庫中，然後提供API以方便Kubernetes相關元件或客戶應用CRUD操作這些資料，上述專門用來儲存配置引數的Map就是Kubernetes ConfigMap資源物件。

接下來，Kubernetes提供了一種內建機制，將儲存在etcd中的ConfigMap通過Volume對映的方式變成目標Pod內的配置檔案，不管目標Pod被排程到哪臺伺服器上，都會完成自動對映。進一步地，如果ConfigMap中的key-value資料被修改，則對映到Pod中的“配置檔案”也會隨之自動更新。於是，Kubernetes ConfigMap就成了分散式系統中最為簡單（使用方法簡單，但背後實現比較複雜）且對應用無侵入的配置中心。