一 Projected Volume
作為 Kubernetes 比較核心的編排對象，Pod 攜帶的信息極其豐富灯萍。在 Kubernetes 中，有幾種特殊的 Volume，它們存在的意義不是為了存放容器里的數(shù)據(jù)映砖，也不是用來進(jìn)行容器和宿主機(jī)之間的數(shù)據(jù)交換。這些特殊 Volume 的作用灾挨，是為容器提供預(yù)先定義好的數(shù)據(jù)邑退。從容器的角度來看，這些 Volume 里的信息就是仿佛是被 Kubernetes“投射”劳澄。Kubernetes 支持的 Projected Volume 有如下四種：
Secret
ConfigMap
DownWarAPI
ServiceAccountToken
1.1 Secret
Kubernetes 把 Pod 想要訪問的東西存放在 etcd 中地技，然后通過在 Pod 的容器里掛載 volume 的方式來進(jìn)行訪問。存放數(shù)據(jù)庫的憑證信息就是 Secret 最典型的應(yīng)用場景之一秒拔。
apiVersion: v1
kind: Pod
metadata:
name: secret-gysl
spec:
containers:
- name: secret-gysl
image: busybox
args:
- sleep
- "3600"
volumeMounts:
- name: secret-mysql-gysl
mountPath: "/projected-volume-secret"
readOnly: true
volumes:
- name: secret-mysql-gysl
projected:
sources:
- secret:
name: user
- secret:
name: passwd
在這個例子中莫矗，聲明掛載的 Volume 的類型是 projected 類型。這個 Volume 的數(shù)據(jù)來源（sources）是名為 user 和 passwd 的 Secret 對象砂缩，分別對應(yīng)的是數(shù)據(jù)庫的用戶名和密碼作谚。
在編寫 yaml 文件的時候需要最后幾行，secret 下面依然是需要進(jìn)一步縮進(jìn)的庵芭。
在 apply 以上 yaml 文件之后妹懒，我們會發(fā)現(xiàn) Pod 的狀態(tài)一直是 ContainerCreating ，原因是我們還沒有創(chuàng)建相關(guān)的 secret 双吆。使用以下命令進(jìn)行創(chuàng)建：
kubectl create secret generic user --from-file=username.txt
kubectl create secret generic passwd --from-file=passwd.txt
username.txt 和 passwd.txt 兩個文件的內(nèi)容分別如下：
cat username.txt
gysl
cat passwd.txt
E#w23%dj2JK@
進(jìn)入該 Pod:
kubectl exec -it secret-gysl sh
正常情況下眨唬，可以看到如下內(nèi)容：
/ # ls -al /projected-volume-secret/
total 0
drwxrwxrwt 3 root root 120 Aug 1 07:25 .
drwxr-xr-x 1 root root 60 Aug 1 07:25 ..
drwxr-xr-x 2 root root 80 Aug 1 07:25 ..2019_08_01_07_25_08.650769588
lrwxrwxrwx 1 root root 31 Aug 1 07:25 ..data -> ..2019_08_01_07_25_08.650769588
lrwxrwxrwx 1 root root 17 Aug 1 07:25 passwd.txt -> ..data/passwd.txt
lrwxrwxrwx 1 root root 19 Aug 1 07:25 username.txt -> ..data/username.txt
/ # cat /projected-volume-secret/username.txt
gysl
/ # cat /projected-volume-secret/passwd.txt
E#w23%dj2JK@
也可以通過 yaml 文件的方式來進(jìn)行創(chuàng)建，以上命令轉(zhuǎn)化為 yaml 如下：
apiVersion: v1
kind: Secret
metadata:
name: user
type: Opaque
data:
username.txt: Z3lzbAo=
---
apiVersion: v1
kind: Secret
metadata:
name: passwd
type: Opaque
data:
passwd.txt: RSN3MjMlZGoySktACg==
該yaml 文件中的 data 部分的字段都是經(jīng)過 base64 轉(zhuǎn)碼的：
cat username.txt |base64
Z3lzbAo=
cat passwd.txt |base64
RSN3MjMlZGoySktACg==
使用上面的命令進(jìn)入該 Pod 我們就可以看到跟之前操作一樣的內(nèi)容伊诵。上面我們使用了2個 secret 對象來進(jìn)行本次實(shí)驗(yàn)单绑。我們能否使用一個 secret 來達(dá)到一樣的目標(biāo)呢？
請看以下 yaml ：
apiVersion: v1
kind: Pod
metadata:
name: secret-gysl
spec:
containers:
- name: secret-gysl
image: busybox
args:
- sleep
- "3600"
volumeMounts:
- name: secret-mysql-gysl
mountPath: "/projected-volume-secret"
readOnly: true
volumes:
- name: secret-mysql-gysl
projected:
sources:
# - secret:
# name: passwd
- secret:
name: secret-gysl
---
apiVersion: v1
kind: Secret
metadata:
name: secret-gysl
type: Opaque
data:
user: Z3lzbAo=
passwd: RSN3MjMlZGoySktACg==
進(jìn)入 Pod 觀察：
/projected-volume-secret # ls -al
total 0
drwxrwxrwt 3 root root 120 Aug 1 06:55 .
drwxr-xr-x 1 root root 60 Aug 1 06:55 ..
drwxr-xr-x 2 root root 80 Aug 1 06:55 ..2019_08_01_06_55_22.687706782
lrwxrwxrwx 1 root root 31 Aug 1 06:55 ..data -> ..2019_08_01_06_55_22.687706782
lrwxrwxrwx 1 root root 13 Aug 1 06:55 passwd -> ..data/passwd
lrwxrwxrwx 1 root root 11 Aug 1 06:55 user -> ..data/user
從目錄結(jié)構(gòu)和內(nèi)容來看曹宴，差異并不大搂橙，多層軟連接，一些隱藏文件。使用這樣的方法創(chuàng)建的 secret 僅僅進(jìn)行了轉(zhuǎn)碼区转，并未進(jìn)行加密苔巨，生產(chǎn)環(huán)境中使用一般情況下需要使用加密插件。
1.2 ConfigMap
ConfigMap 與 Secret 的區(qū)別在于废离，ConfigMap 保存的是不需要加密的侄泽、應(yīng)用所需的配置信息，用法幾乎與 Secret 完全相同：可以使用 kubectl create configmap 從文件或者目錄創(chuàng)建 ConfigMap蜻韭，也可以直接編寫 ConfigMap 對象的 YAML 文件悼尾。我們以 kube-controller-manager.conf 文件來演示一下。
創(chuàng)建 configMap:
kubectl create configmap kube-scheduler --from-file=/etc/kubernetes/conf.d/kube-controller-manager.conf
同樣肖方，我們也可以使用 yaml 來創(chuàng)建：
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-controller-manager-gysl
data:
kube-controller-manager.conf: |
KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=true --v=4 --master=127.0.0.1:8080 --leader-elect=true --address=127.0.0.1 --service-cluster-ip-range=10.0.0.0/24 --cluster-name=kubernetes --cluster-signing-cert-file=/etc/kubernetes/ca.d/ca.pem --cluster-signing-key-file=/etc/kubernetes/ca.d/ca-key.pem --root-ca-file=/etc/kubernetes/ca.d/ca.pem --service-account-private-key-file=/etc/kubernetes/ca.d/ca-key.pem"
就這樣闺魏，kube-controller-manager.conf 配置文件的內(nèi)容就被保存到了 kube-controller-manager-gysl 這個ConfigMap 中。
1.3 Downward API
Downward API 能讓 Pod 里的容器能夠直接獲取到這個 Pod API 對象本身的信息俯画。
apiVersion: v1
kind: Pod
metadata:
name: downward-api-gysl
labels:
zone: beijing
cluster: gysl-cluster1
rack: rack-gysl
spec:
containers:
- name: client-container
image: busybox
command: ["sh", "-c"]
args:
- while true; do
if [[ -e /etc/podinfo/labels ]]; then
echo -en '\n\n'; cat /etc/podinfo/labels; fi;
sleep 5;
done;
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
readOnly: false
volumes:
- name: podinfo
projected:
sources:
- downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
Pod 的 Labels 字段的值析桥，就會被 Kubernetes 自動掛載成為容器里的 /etc/podinfo/labels 文件。執(zhí)行命令：
kubectl logs downward-api-gysl
看到的結(jié)果：
cluster="gysl-cluster1"
rack="rack-gysl"
zone="beijing"
cluster="gysl-cluster1"
rack="rack-gysl"
zone="beijing"
cluster="gysl-cluster1"
rack="rack-gysl"
zone="beijing"
Downward API 支持的字段已經(jīng)非常豐富艰垂，比如：
1. 使用 fieldRef 可以聲明使用:
spec.nodeName - 宿主機(jī)名字
status.hostIP - 宿主機(jī) IP
metadata.name - Pod 的名字
metadata.namespace - Pod 的 Namespace
status.podIP - Pod 的 IP
spec.serviceAccountName - Pod 的 Service Account 的名字
metadata.uid - Pod 的 UID
metadata.labels['<KEY>'] - 指定 <KEY> 的 Label 值
metadata.annotations['<KEY>'] - 指定 <KEY> 的 Annotation 值
metadata.labels - Pod 的所有 Label
metadata.annotations - Pod 的所有 Annotation
2. 使用 resourceFieldRef 可以聲明使用:
容器的 CPU limit
容器的 CPU request
容器的 memory limit
容器的 memory request
Downward API 能夠獲取到的信息泡仗，一定是 Pod 里的容器進(jìn)程啟動之前就能夠確定下來的信息。而如果你想要獲取 Pod 容器運(yùn)行后才會出現(xiàn)的信息猜憎。比如娩怎，容器進(jìn)程的 PID，那就肯定不能使用 Downward API 了拉宗，而應(yīng)該考慮在 Pod 里定義一個 sidecar 容器峦树。
1.4 Service Account
Service Account 對象的作用，就是 Kubernetes 系統(tǒng)內(nèi)置的一種“服務(wù)賬戶”旦事，它是 Kubernetes 進(jìn)行權(quán)限分配的對象魁巩。比如，Service Account A姐浮，可以只被允許對 Kubernetes API 進(jìn)行 GET 操作谷遂，而 Service Account B，則可以有 Kubernetes API 的所有操作的權(quán)限卖鲤。
像這樣的 Service Account 的授權(quán)信息和文件肾扰，實(shí)際上保存在它所綁定的一個特殊的 Secret 對象里的。這個特殊的 Secret 對象蛋逾，就叫作ServiceAccountToken集晚。任何運(yùn)行在 Kubernetes 集群上的應(yīng)用，都必須使用這個 ServiceAccountToken 里保存的授權(quán)信息区匣，也就是 Token偷拔，才可以合法地訪問 API Server。
因此，Kubernetes 項(xiàng)目的 Projected Volume 其實(shí)只有三種莲绰，因?yàn)榈谒姆N ServiceAccountToken欺旧，只是一種特殊的 Secret 而已。
為了方便使用蛤签，Kubernetes 已經(jīng)為你提供了一個的默認(rèn)“服務(wù)賬戶”（default Service Account）辞友。并且，任何一個運(yùn)行在 Kubernetes 里的 Pod震肮，都可以直接使用這個默認(rèn)的 Service Account称龙，而無需顯示地聲明掛載它。Kubernetes 在每個 Pod 創(chuàng)建的時候钙蒙，自動在它的 spec.volumes 部分添加上了默認(rèn) ServiceAccountToken 的定義茵瀑，然后自動給每個容器加上了對應(yīng)的 volumeMounts 字段间驮。這個過程對于用戶來說是完全透明的躬厌。一旦 Pod 創(chuàng)建完成，容器里的應(yīng)用就可以直接從這個默認(rèn) ServiceAccountToken 的掛載目錄里訪問到授權(quán)信息和文件竞帽。這個容器內(nèi)的路徑在 Kubernetes 里是固定的扛施，即：/var/run/secrets/kubernetes.io/serviceaccount。
$ kubectl exec -it downward-api-gysl sh
/ # ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt namespace token
這種把 Kubernetes 客戶端以容器的方式運(yùn)行在集群里屹篓，然后使用 default Service Account 自動授權(quán)的方式疙渣，被稱作“InClusterConfig”，也是我最推薦的進(jìn)行 Kubernetes API 編程的授權(quán)方式堆巧。
考慮到自動掛載默認(rèn) ServiceAccountToken 的潛在風(fēng)險妄荔，Kubernetes 允許你設(shè)置默認(rèn)不為 Pod 里的容器自動掛載這個 Volume。
最新免費(fèi)java谍肤，架構(gòu)啦租，大數(shù)據(jù)AI編程資料獲取添加
薇信:18410263200
通過驗(yàn)證填寫“111”(備注必填)
