本文的試驗環境為CentOS 7.3，Kubernetes集群為1.11.2，安裝步驟參見kubeadm安裝kubernetes V1.11.1 集群
應用場景：鏡像往往是一個應用的基礎，還有很多需要自定義的參數或配置，例如資源的消耗、日誌的位置級別等等，這些配置可能會有很多，因此不能放入鏡像中，Kubernetes中提供了Configmap來實現向容器中提供配置文件或環境變量來實現不同配置，從而實現了鏡像配置與鏡像本身解耦，使容器應用做到不依賴於環境配置。
向容器傳遞參數
DockerKubernetes描述ENTRYPOINTcommand容器中的可執行文件CMDargs需要傳遞給可執行文件的參數
如果需要向容器傳遞參數，可以在Yaml文件中通過command和args或者環境變量的方式實現。
kind: Pod spec: 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（當然配置內容不相同，只是名字相同），就可以降低環境管理和部署的複雜度。
ConfigMap有三種用法：
- 生成為容器內的環境變量
- 設置容器啟動命令的參數
- 掛載為容器內部的文件或目錄
ConfigMap的缺點
- ConfigMap必須在Pod之前創建
- ConfigMap屬於某個NameSpace，只有處於相同NameSpace的Pod才可以應用它
- ConfigMap中的配額管理還未實現
- 如果是volume的形式掛載到容器內部，只能掛載到某個目錄下，該目錄下原有的文件會被覆蓋掉
- 靜態Pod不能用ConfigMap
ConfigMap的創建
$ kubectl create configmap --from-literal== $ kubectl create configmap --from-literal== --from-literal== --from-literal== $ kubectl create configmap --from-file= $ kubectl apply -f # 還可以從一個文件夾創建configmap $ kubectl create configmap --from-file=/path/to/dir
yaml 文件的方式
apiVersion: v1
data:
my-nginx-config.conf: |
server {
listen 80;
server_name www.kubia-example.com;
gzip on;
gzip_types text/plain application/xml;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
sleep-interval: |
25
kind: ConfigMap
ConfigMap的調用
環境變量的方式
apiVersion: v1 kind: Pod metadata: name: env-configmap spec: containers: - image: nginx env: - name: INTERVAL valueFrom: configMapKeyRef: name: key: sleep-interval
如果引用了一個不存在的ConfigMap，則創建Pod時會報錯，直到能夠正常讀取ConfigMap後，Pod會自動創建。
一次傳遞所有的環境變量
spec: containers: - image: nginx envFrom: - prefix: CONFIG_ configMapRef: name:
命令行參數的方式
apiVersion: v1
kind: Pod
metadata:
name: env-configmap
spec:
containers:
- image: nginx
env:
- name: INTERVAL
valueFrom:
configMapKeyRef:
name:
key: sleep-interval
args: ["$(INTERVAL)"]
以配置文件的方式
apiVersion: v1 kind: Pod metadata: name: nginx-test spec: containers: - image: nginx name: web-server volumeMounts: - name: config mountPath: /etc/nginx/conf.d readOnly: true volumes: - name: config configMap: name:
將Configmap掛載為一個文件夾後，原來在鏡像中的文件夾裡的內容就看不到，這是什麼原理？這是因為原來文件夾下的內容無法進入，所以顯示不出來。為了避免這種掛載方式影響應用的正常運行，可以將configmap掛載為一個配置文件。
spec: containers: - image: nginx volumeMounts: - name: config mountPath: /etc/someconfig.conf subPath: myconfig.conf
Configmap的更新
$ kubectl edit configmap
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
創建和調用的過程與configmap大同小異，這裡就不再贅述了。
