Kubernetes k8s configmap 容器技術解析

1、什麼是 ConfigMap？

ConfigMap 是用來存儲配置文件的 Kubernetes 資源對象，配置對象存儲在 Etcd 中，配置的形式可以是完整的配置文件、key/value 等形式。

2、ConfigMap 能帶來什麼好處？

傳統的應用服務，每個服務都有自己的配置文件，各自配置文件存儲在服務所在節點，對於單體應用，這種存儲沒有任何問題，但是隨著用戶數量的激增，一個節點不能滿足線上用戶使用，故服務可能從一個節點擴展到十個節點，這就導致，如果有一個配置出現變更，就需要對應修改十次配置文件。

這種人肉處理，顯然不能滿足線上部署要求，故引入瞭各種類似於 ZooKeeper 中間件實現的配置中心，但配置中心屬於 “侵入式” 設計，需要修改引入第三方類庫，它要求每個業務都調用特定的配置接口，破壞瞭系統本身的完整性，而Kubernetes 利用瞭 Volume 功能，完整設計瞭一套配置中心，其核心對象就是ConfigMap，使用過程不用修改任何原有設計，即可無縫對 ConfigMap；為什麼呢？

如圖（1）所示，

• ConfigMap 相當於放入原生應用的配置文件，可以是一個或者多個；
• 容器啟動之後，到宿主機中拉取 ConfigMap 的內容，生成本地文件，通過 volume 形式映射到容器內部指定目錄上；
• 容器中應用程序按照原有方式讀取容器特定目錄上的配置文件。

在容器看來，配置文件就像是打包在容器內部特定目錄，整個過程對應用沒有任何侵入。

3、ConfigMap 三種創建方式

• 指定字面量進行創建，創建命令如下所示：

kubectl create configmap configmaptest --from-literal=foo=bar --from-literal=one=two

創建完成後通過如下方式查看：

[root@k8s-master k8s]# kubectl get configmap configmaptest -o yaml
apiVersion: v1
data:
  foo: bar
  one: two
kind: ConfigMap
metadata:
  creationTimestamp: "2020-04-14T13:53:42Z"
  name: configmaptest
  namespace: default
  resourceVersion: "613402"
  selfLink: /api/v1/namespaces/default/configmaps/configmaptest
  uid: 59b91eb4-7e57-11ea-83c7-509a4c36e19d

• 指定特定文件進行創建

kubectl create configmap config-files --from-file=/home/conf/db.properties

可以通過如下方式進行查看，（內容過長，影響閱讀，省略 ConfigMap 元信息。）

[root@k8s-master k8s]# kubectl get configmap test-config -o yaml
apiVersion: v1
data:
  db.properties: |
    driverClassName=com.mysql.jdbc.Driver
    ......

• 指定特定文件夾進行創建

kubectl create configmap config-dir --from-file=/home/conf/config-test

通過如下方式進行查看

[root@k8s-master k8s]# kubectl get configmap config-test -o yaml
apiVersion: v1
data:
  db.properties: |
    # 數據源配置
    driverClassName=com.mysql.jdbc.Driver
   ......
  logback.xml: "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<configuration debug=\"true\"
   ......
  svc.properties: |
    #server
    protocol=tcp
    .......
  system.properties: |
    time=100
    .......

如上描述三種基本的 ConfigMap創建方式，當然也可以使用合並不同選項進行創建配置文件，具體如下所示：

kubectl create configmap config-mix --from-file=/home/conf/biz/ --from-file=/home/conf/db.xml  --from-literal=one=two

看到這麼多，你可能會想到，–from-file最後一級如果是文件夾會怎樣呢？如你所想，文件夾其實不會被包含，隻會查找最後一級目錄下的文件。

4、ConfigMap 作為環境變量三種使用方式

單個引用

1、首先創建 ConfigMap

kubectl create configmap configmaptest --from-literal=code=25 --from-literal=foo=bar --from-literal=one=two

2、Deployment yaml中引用 ConfigMap 設置環境變量，如圖（2）所示

3、通過如下方式進行查看，環境變量是否生效，可以發現，容器環境中已經存在引用ConfigMap中的環境變量

[root@k8s-master k8s]# kubectl exec nginx-7c958f6448-z5q56 -it /bin/bash
[root@nginx-7c958f6448-z5q56 /]# env|grep CODE
CODE-TIME=25

多個引用

1、一次性傳遞所有ConfigMap條目作為環境變量，如圖（3）所示

可以通過如下方式進行查看環境變量是否生效，如下所示每個環境變量都按照預設，添加瞭配置的前綴，有人可能要說，我的配置文件中原來是什麼配置現在還保留什麼配置，不需要添加預設前綴，那麼請查看如圖（4）通過把前綴設置為空串，即可保持原有配置方式。

[root@k8s-master k8s]# kubectl exec nginx-84ccdff98d-vgzcw -it /bin/bash
[root@nginx-84ccdff98d-vgzcw /]# env|grep CODE
CODE_foo=bar
CODE_code=25
CODE_one=two

args 方式傳遞環境變量

容器啟動時，傳遞該變量到服務，運行 shell 腳本，可能會用到，具體設置方式如圖（5）所示：

以上解釋瞭通過在 yaml 設置 env 引用 ConfigMap 中配置作為環境變量的使用，在使用過程中，我參考瞭 《Kubernetes In Action》這本書，發現此書中有一段是這樣描述的，如圖（6）所示：

其大概意思是，配置鍵中不能包含破折號，如果包含則不能設置到環境變量中，此書這部分是基於 Kubernetes 1.6 進行編撰，而我使用的是 kubernetes 1.14，不清楚是不是因為 Kubernetes 已經改進的原因，還是其他原因，我有兩點不解的地方。

破折號（——）大多都是指特別長的符號，在編碼過程中很少有人使用這個，即使使用瞭，Kubernetes 根本無法保存成功。

又何談環境變量一說呢？會提示如圖(7)，圖（8）所示錯誤：

如果破折號換成英文半角字符 – 中劃線呢？如圖（9）所示，是可以保存成功的。當然也可以用於環境變量中。

當然通過如上方式設置完成之後，就可以直接在容器內部使用環境變量讀取已經設置的配置，但是使用環境變量的方式有一個致命的缺點是，當外部 ConfigMap 更新配置完成之後，容器內部環境變量並不會隨之改變，這是因為 ENV 是容器啟動時候註入的，啟動之後 Kubernetes 就不會改變 ENV 的值，即配置不能同步更新，隻能通過重啟容器方式，配置才能生效。

5、掛載 volume

這種方式則是通過 volume 形式映射到容器內部指定目錄上，容器內部進程直接讀取該目錄下特定文件，這種方式是我們常用的一種方式，具體使用時如下所示：

   ......
        - containerPort: 80
        volumeMounts:
          - mountPath: /usr/local/nginx/conf/vhost/
            name: http
          - mountPath: /usr/local/nginx/html/foo
            subPath: foo
            name: nginx-html
      volumes:
      - name: http
        configMap:
          name: nginx-conf
      - name: nginx-html
        configMap:
          name: configmaptest
          items: 
          - key: foo
            path: foo
   ......

volumeMounts 是容器內部指定掛載目錄，volumes 是引用目錄，即宿主機設置 ConfigMap 文件地址。

• 可以直接掛載一個目錄到容器內部，當宿主機通過如下方式修改 configmap 那麼容器內部配置將隨之改變，一次性修改所有文件。但是使用這種方式有一個問題需要註意，如果掛載到容器內部的文件夾下存在其它文件，這種掛載方式將直接覆蓋原有文件夾下的文件。

[root@k8s-master ~]# kubectl edit configmap configmaptest

• 如果有特定需求，需要掛載某個特定文件，而不允許覆蓋原有文件，可以掛載到指定文件，通過 subPath 配合指定文件。但是單個文件掛載這種方式不能實現熱更新，即宿主機 ConfigMap 文件發生變化，容器內部不會自動重載。
• 至於 items 使用就比較簡單瞭，如果一個 ConfigMap 中包含多個配置文件，但是隻想暴露出來其中一部分，那麼可以通過 items 方式進行指定。當然你也可以對文件設置讀寫權限。

6、Secret 使用

Secret 使用類似於 ConfigMap，支持兩種形式的使用：

• 將 Secret 作為環境變量暴露給容器進程使用。
• 將 Secret 通過volume 數據卷提供給容器進程使用。

看到這裡你可能要說瞭，什麼都一樣，為啥還要 Secret，一個 ConfigMap 解決問題不就完事瞭，其實不然，Secret 顧名思義，是用於存儲加密數據的，老版本 Kubernetes 隻支持 base64 加密，學過計算機的都知道 base64 那就不是什麼加密，隻是對字符串進行瞭 encode 編碼，通過 decode 直接可以解出明文。

但後來新版本的 Kubernetes 已經實現瞭真正意義上的加解密，所以 Secret 存在是有一定意義的，使用方式跟 ConfigMap 類似，但是命令確不一樣。

1、創建 Secret 輸入如下：

kubectl create secret generic nginx-ssl --from-file=ca.key --from-file=ca.cert

2、查看 Secret 輸入如下所示：

[root@k8s-master ~]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-7h5z9   kubernetes.io/service-account-token   3      6d13h
nginx-ssl         Opaque                                2      21h
[root@k8s-master ~]# kubectl get secret nginx-ssl -o yaml
apiVersion: v1
data:
  ca.crt: QmFnIEF0dHJpYnV0ZXMKICAgIGZy.......................
  ca.key: QmFnIEF0dHJpYnV0ZXMKICAgIGZy......................
kind: Secret
.....................

3、Pod 引用方式：

.....................
- containerPort: 80
        volumeMounts:
          - mountPath: /home/nginx/nginx/conf/cert/
            name: nginx-ssl
      volumes:
      - name: nginx-ssl
        secret:
          secretName: nginx-ssl
.....................

7、應用程序怎麼做到不重啟情況下讀取最新配置

上面已經提及使用環境變量和單文件掛載形式，無法實現熱更新，但是通過 數據卷形式可以實現宿主機和 Pod 內部讀取配置的實時更新，但是有一點需要註意的是 ConfigMap 更新，數據卷也更新瞭，如果你的應用進程不進行配置重載，即實時讀取配置數據，同樣還是使用的老配置。

這個問題可以通過把 Pod 的副本數減少到 0 進行重建 Pod 解決。這種方式雖然能夠解決服務重新加載問題，但是也會帶來問題。

因為可能會導致同一套服務，配置不一致的問題，因此，如果業務對實時性要求高，建議改成服務實時加載配置。總結一下，Kubernetes 隻是把配置實時同步到數據卷配置文件中，至於加載時機，還要看自己的應用程序。

舉個例子，nginx 配置存儲在 Kubernetes ConfigMap 裡面，公鑰信息存儲在 Secret 中，nginx 充當服務裡面的反向代理，因為端口資源規劃問題，需要修改 nginx 配置文件中端口，修改完成後，Pod 中的數據卷配置信息發生變化，但 nginx 並不會重載已經修改的配置信息。

通過如下命令行修改，修改完成後，發現 Pod 中 nginx 配置生效。

kubectl exec nginx -c nginx -- /usr/local/nginx/sbin/nginx -s reload

總結

ConfigMap 本身是一個很接地氣的設計，它借助於 volume ，原有服務不用修改任何代碼，即可無縫對接。如果你已經使用瞭其它分佈式配置管理服務，如：DisConf，Apollo等，你也可以保持原有方式，繼續使用。

以上就是Kubernetes k8s configmap 容器技術解析的詳細內容，更多關於k8s configmap 容器技術的資料請關註WalkonNet其它相關文章！

推薦閱讀：

• 詳解k8s ConfigMap 中 subPath 字段和 items 字段
• kubernetes之statefulset搭建MySQL集群
• kubernetes Volume存儲卷configMap學習筆記
• k8s中pod使用詳解(雲原生kubernetes)
• K8S 中 kubectl 命令詳解