本篇內(nèi)容介紹了“Kubernetes ConfigMap怎么安裝啟用”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)提供高防服務(wù)器租用、云服務(wù)器、香港服務(wù)器、四川主機(jī)托管等

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

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

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

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

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

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

懷著好奇心，我創(chuàng)建了一個這個對象的golang channel安裝啟用，然后運(yùn)行一些基準(zhǔn)點(diǎn)。你可以點(diǎn)擊（https://github.com/thrawn01/configmap-microservice-demo/blob/master/manager.go）找到代碼和基準(zhǔn)點(diǎn)測試。

Mutex版本沒有死鎖的風(fēng)險(xiǎn)，很高效。

 而 FileWatcher的實(shí)施會較復(fù)雜一點(diǎn)。它的目標(biāo)是使任意額外的fsnotify events成為一個單獨(dú)更新的event，這樣我們只要執(zhí)行一次回調(diào)函數(shù)。查看完整代碼請點(diǎn)擊這里（https://github.com/thrawn01/configmap-microservice-demo/blob/master/watcher.go）

有意思的部分是 run()函數(shù)執(zhí)行在線程中，然后運(yùn)行回調(diào)函數(shù)。

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

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

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

我繼續(xù)使用fsnotify函數(shù)庫，因?yàn)閷τ谖襾碚f，用它在osx上開發(fā)，在容器上部署都比較方便。以Linux為中心的實(shí)施應(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ùn)行我們的應(yīng)用程序容器。

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

從我們的容器觀點(diǎn)角度看，我們的配置文件完整途徑將會是：/etc/config/configmap-microservice-demo.yaml

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

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

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

如果這個部分讓你很困惑，你可以點(diǎn)擊這篇博客（http://www.dasblinkenlichten.com/kubernetes-101-networking/），它對于Kubernetes網(wǎng)絡(luò)是如何運(yùn)行的有很深層次的指導(dǎo)意義。這個是官方文檔（http://kubernetes.io/docs/admin/networking/）。

更新ConfigMap

現(xiàn)在為了有趣的部分，讓我們來更新我們的配置，部署修改到ConfigMap。

讓我們打開原始的ConfigMap密鑰清單文件，然后修改我們的message: Hello World到message:Hello Grandma。

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

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

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

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

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

“Kubernetes ConfigMap怎么安裝啟用”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！