Kubernetes中的Configmap和Secret

本文的試驗環境為CentOS 7.3，Kubernetes叢集為1.11.2，安裝步驟參見

應用場景：映象往往是一個應用的基礎，還有很多需要自定義的引數或配置，例如資源的消耗、日誌的位置級別等等，這些配置可能會有很多，因此不能放入映象中，Kubernetes中提供了Configmap來實現向容器中提供配置檔案或環境變數來實現不同配置，從而實現了映象配置與映象本身解耦，使容器應用做到不依賴於環境配置。

向容器傳遞引數

如果需要向容器傳遞引數，可以在Yaml檔案中透過command和args或者環境變數的方式實現。

kind: Podspec:  containers:  - image: docker.io/nginx    command: ["/bin/command"]    args: ["arg1", "arg2", "arg3"]    env:    - name: INTERVAL      value: "30"    - name: FIRST_VAR      value: "foo"    - name: SECOND_VAR      value: "$(FIRST_VAR)bar"

可以看到，我們可以利用env標籤向容器中傳遞環境變數，環境變數還可以相互引用。這種方式的問題在於配置檔案和部署是繫結的，那麼對於同樣的應用，測試環境的引數和生產環境是不一樣的，這樣就要求寫兩個部署檔案，管理起來不是很方便。

什麼是ConfigMap

上面提到的例子，利用ConfigMap可以解耦部署與配置的關係，對於同一個應用部署檔案，可以利用valueFrom欄位引用一個在測試環境和生產環境都有的ConfigMap（當然配置內容不相同，只是名字相同），就可以降低環境管理和部署的複雜度。

image

ConfigMap有三種用法：

• 生成為容器內的環境變數

• 設定容器啟動命令的引數

• 掛載為容器內部的檔案或目錄

ConfigMap的缺點

• ConfigMap必須在Pod之前建立

• ConfigMap屬於某個NameSpace，只有處於相同NameSpace的Pod才可以應用它

• ConfigMap中的配額管理還未實現

• 如果是volume的形式掛載到容器內部，只能掛載到某個目錄下，該目錄下原有的檔案會被覆蓋掉

• 靜態Pod不能用ConfigMap

ConfigMap的建立

$ kubectl create configmap <map-name> --from-literal=<parameter-name>=<parameter-value>$ kubectl create configmap <map-name> --from-literal=<parameter1>=<parameter1-value> --from-literal=<parameter2>=<parameter2-value> --from-literal=<parameter3>=<parameter3-value>$ kubectl create configmap <map-name> --from-file=<file-path>$ kubectl apply -f <configmap-file.yaml># 還可以從一個資料夾建立configmap
$ kubectl create configmap <map-name> --from-file=/path/to/dir

Yaml 的宣告方式

apiVersion: v1data:
  my-nginx-config.conf: |
    server {
      listen              80;
      server_name         

      gzip on;
      gzip_types text/plain application/xml;

      location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
      }
    }  sleep-interval: |
    25kind: ConfigMap

ConfigMap的呼叫

環境變數的方式

apiVersion: v1kind: Podmetadata:  name: env-configmapspec:  containers:  - image: nginx    env:    - name: INTERVAL      valueFrom:        configMapKeyRef:          name: <map-name>          key: sleep-interval

如果引用了一個不存在的ConfigMap，則建立Pod時會報錯，直到能夠正常讀取ConfigMap後，Pod會自動建立。

一次傳遞所有的環境變數

spec:  containers:  - image: nginx    envFrom:    - prefix: CONFIG_      configMapRef:        name: <map-name>

命令列引數的方式

apiVersion: v1kind: Podmetadata:  name: env-configmapspec:  containers:  - image: nginx    env:    - name: INTERVAL      valueFrom:        configMapKeyRef:          name: <map-name>          key: sleep-interval    args: ["$(INTERVAL)"]

以配置檔案的方式

apiVersion: v1kind: Podmetadata:  name: nginx-testspec:  containers:  - image: nginx    name: web-server    volumeMounts:    - name: config      mountPath: /etc/nginx/conf.d      readOnly: true  volumes:  - name: config    configMap:      name: <map-name>

將Configmap掛載為一個資料夾後，原來在映象中的資料夾裡的內容就看不到，這是什麼原理？這是因為原來資料夾下的內容無法進入，所以顯示不出來。為了避免這種掛載方式影響應用的正常執行，可以將configmap掛載為一個配置檔案。

spec:  containers:  - image: nginx    volumeMounts:    - name: config      mountPath: /etc/someconfig.conf      subPath: myconfig.conf

image

Configmap的更新

$ kubectl edit configmap <map-name>

confgimap更新後，如果是以資料夾方式掛載的，會自動將掛載的Volume更新。如果是以檔案形式掛載的，則不會自動更新。
但是對多數情況的應用來說，配置檔案更新後，最簡單的辦法就是重啟Pod（殺掉再重新拉起）。如果是以資料夾形式掛載的，可以透過在容器內重啟應用的方式實現配置檔案更新生效。即便是重啟容器內的應用，也要注意configmap的更新和容器內掛載檔案的更新不是同步的，可能會有延時，因此一定要確保容器內的配置也已經更新為最新版本後再重新載入應用。

什麼是Secret

Secret與ConfigMap類似，但是用來儲存敏感資訊。在Master節點上，secret以非加密的形式儲存（意味著我們要對master嚴加管理）。從Kubernetes1.7之後，etcd以加密的形式儲存secret。secret的大小被限制為1MB。當Secret掛載到Pod上時，是以tmpfs的形式掛載，即這些內容都是儲存在節點的記憶體中，而不是寫入磁碟，透過這種方式來確保資訊的安全性。

Kubernetes helps keep your Secrets safe by making sure each Secret is only distributed to the nodes that run the pods that need access to the Secret. Also, on the nodes themselves, Secrets are always stored in memory and never written to physical storage, which would require wiping the disks after deleting the Secrets from them.

每個Kubernetes叢集都有一個預設的secrets

image

建立和呼叫的過程與configmap大同小異，這裡就不再贅述了。

作者：GreenWang
連結：