Kubernetes 1.2 新功能解析：ConfigMap (下)

Blackjun 發(fā)布于2019-07-01 16:22 / 3529人閱讀

摘要：的工作就是為作出的修改查看我們的配置文件，并且運行讀取配置文件的新版本回調(diào)函數(shù)，使用設(shè)置新的。它的目標(biāo)是使任意額外的成為一個多帶帶更新的，這樣我們只要執(zhí)行一次回調(diào)函數(shù)。

Kubernetes 1.2版本添加了一個叫ConfigMap的新功能。這個功能提供給容器注入應(yīng)用程序數(shù)據(jù)的方式。注入配置文件對于大部分應(yīng)用程序來說很強大，但是新的ConfigMap功能不僅可以在容器開啟時提供初始配置功能，還有在容器運行時更新自身配置的功能。在這篇帖子里，我將會給大家展示如何編寫微服務(wù)來利用更新好的配置，并且在fly上面重構(gòu)你的service。

讓我們來看看監(jiān)控配置文件變化的簡單網(wǎng)頁app是怎么樣的。

這個app有趣部分是ConfigManager 和 WatchFile.

ConfigManager的工作就是提供訪問我們的 Config{}的路徑結(jié)構(gòu)，這樣的話當(dāng)Kubernetes ConfigMap給我們一個新的配置文件版本或者我們更新 Config{} 對象時候，競爭沖突不存在。

WatchFile的工作就是為作出的修改查看我們的配置文件，并且運行讀取配置文件的新版本回調(diào)函數(shù)，使用ConfigManager設(shè)置新的 Config{} 。

讓我們看一下ConfigManager的安裝啟用。

這里是我們使用一個簡單的Mutex用來避免競爭沖突的例子。通常你想要避免使用Mutex，然后使用建立在channel里面的golang。但是既然管理員的工作是保護配置對象的實例，那么使用Mutex也還是可以接受的。

懷著好奇心，我創(chuàng)建了一個這個對象的golang channel安裝啟用，然后運行一些基準(zhǔn)點。你可以點擊（點我）找到代碼和基準(zhǔn)點測試。

Mutex版本沒有死鎖的風(fēng)險，很高效。而 FileWatcher的實施會較復(fù)雜一點。它的目標(biāo)是使任意額外的fsnotify events成為一個多帶帶更新的event，這樣我們只要執(zhí)行一次回調(diào)函數(shù)。查看完整代碼請點擊這里（點我）
有意思的部分是 run()函數(shù)執(zhí)行在線程中，然后運行回調(diào)函數(shù)。

你可能會覺得代碼應(yīng)該尋找 fsnotify.Writeevents而不是fsnotify.Remove，然而……ConfigMap所呈現(xiàn)給應(yīng)用程序的配置文件事實上是一個連接到我們配置文件的符號鏈接，而不是一個文件。當(dāng)ConfigMap更新時，Kubernetes AtomicWriter()就可以實現(xiàn)強大的ConfigMap更新。

為了做到這樣，AtomicWriter()創(chuàng)建了一個新的目錄；編寫更新好的ConfigMap內(nèi)容到新的目錄。一旦編寫完成，那么它就會移動原始配置文件符號鏈接，然后用新的指向最新創(chuàng)建目錄符號鏈接替換它。

我們的代碼處理方式理論上應(yīng)該是監(jiān)控我們的配置文件符號鏈接，而不是為events的真實文件。然而，fsnotify.v1并不允許我們提交IN_DONT_FOLLOW標(biāo)志到inotify，inotify允許我們?yōu)樾薷谋O(jiān)控符號鏈接。但是fsnotify取消引用符號鏈接，然后為events監(jiān)控真實文件。這不太可能作出修改，因為fsnotify是為跨平臺設(shè)計的，而且不是所有的平臺都支持符號鏈接。

我繼續(xù)使用fsnotify函數(shù)庫，因為對于我來說，用它在osx上開發(fā)，在容器上部署都比較方便。以Linux為中心的實施應(yīng)該直接使用"golang.org/x/exp/inotify"數(shù)據(jù)庫。
現(xiàn)在我們有了我們的代碼，我們可以創(chuàng)建一個Docker鏡像然后更新到Docker hub，為部署在我們Kubernetes集群做好準(zhǔn)備。

假設(shè)你已經(jīng)建立起了一個Kubernetes集群；讓我們來創(chuàng)建一個ConfigMap配置，然后用我們的容器來使用它。

創(chuàng)建ConfigMap

首先，我們創(chuàng)建一個密鑰清單文件

這個定義了一個新的叫做configmap-microservice-demo的ConfigMap，它包括了 data:配置文件名字叫做configmap-microservice-demo.yaml
它的內(nèi)容是message: Hello World。
使用 kubectl來創(chuàng)建ConfigMap。

你可以檢測到最新的創(chuàng)建好的ConfigMap

接下來我們來定義一個Replication Controller密鑰清單來運行我們的應(yīng)用程序容器。

有趣的地方就是volumes:和volumeMounts:，這兩者告訴運行在節(jié)點上的kubelet哪里可以安裝我們的配置文件。當(dāng)我們的容器運行的時候；數(shù)據(jù)卷插件會在我們的容器中安裝一個叫做/etc/config的目錄，然后在這里面替換我們的配置文件configmap-microservice-demo.yaml。
從我們的容器觀點角度看，我們的配置文件完整途徑將會是：/etc/config/configmap-microservice-demo.yaml

現(xiàn)在讓我們來創(chuàng)建Replication Controller。

我們現(xiàn)在可以檢查我們正在運行的pods來尋找我們新pod的IP地址。

現(xiàn)在如果你登錄到我們集群中的一個節(jié)點，我們在集群里可以用pod的IP地址從任何地方來訪問應(yīng)用程序。

如果這個部分讓你很困惑，你可以點擊這篇博客（點我），它對于Kubernetes網(wǎng)絡(luò)是如何運行的有很深層次的指導(dǎo)意義。這個是官方文檔（點我）。

更新ConfigMap

現(xiàn)在為了有趣的部分，讓我們來更新我們的配置，部署修改到ConfigMap。
讓我們打開原始的ConfigMap密鑰清單文件，然后修改我們的message: Hello World到message:Hello Grandma。

用我們更新的版本替代目前的ConfigMap

我們可以驗證到，通過在configmap資源上執(zhí)行g(shù)et，更新很成功。

我們的應(yīng)用程序很快得到了更新后的配置，我們可以通過看日志就來驗證。

現(xiàn)在我們可以在集群里面curl我們的應(yīng)用程序，我們應(yīng)該看到更新的配置反應(yīng)在我們的應(yīng)用程序里。

你可以登錄到我們的容器正在運行的節(jié)點，然后檢查直接檢查配置文件。Kubernetes將目錄安裝在/var/lib/kubelet/pods//volumes/kubernetes.io~configmap/config-volume。

查看完整代碼點擊這里：點我