1. configMap的原理及作用
就是為了讓鏡像 和 配置文件解耦，以便實(shí)現(xiàn)鏡像的可移植性和可復(fù)用性，因?yàn)橐粋€configMap其實(shí)就是一系列配置信息的集合，將來可直接注入到Pod中的容器使用，而注入方式有兩種，一種將configMap做為存儲卷，一種是將configMap通過env中configMapKeyRef注入到容器中。它通過兩種方式實(shí)現(xiàn)給Pod傳遞配置參數(shù):
A. 將環(huán)境變量直接定義在configMap中，當(dāng)Pod啟動時,通過env來引用configMap中定義的環(huán)境變量。
B. 將一個完整配置文件封裝到configMap中,然后通過共享卷的方式掛載到Pod中,實(shí)現(xiàn)給應(yīng)用傳參。
secret: 它是一種相對安全的configMap，因?yàn)樗鼘onfigMap通過base64做了編碼, 讓數(shù)據(jù)不是明文直接存儲在configMap中，起到了一定的保護(hù)作用，但對Base64進(jìn)行反編碼，對專業(yè)人士來說，沒有任何難度，因此它只是相對安全

2. requests未設(shè)置時，默認(rèn)與limits相同。limits未設(shè)置時，默認(rèn)值與集群配置相關(guān)。

• 使用requests來設(shè)置各容器需要的最小資源
• limits用于限制運(yùn)行時容器占用的資源，用來限制容器的最大CPU、內(nèi)存的使用率。當(dāng)容器申請內(nèi)存超過limits時會被終止，并根據(jù)重啟策略進(jìn)行重啟

3. k8s控制器和Pod Template的關(guān)系
Pod 本身并不能自愈（self-healing）。如果一個 Pod 所在的 Node （節(jié)點(diǎn)）出現(xiàn)故障，或者調(diào)度程序自身出現(xiàn)故障，Pod 將被刪除；同理，當(dāng)因?yàn)楣?jié)點(diǎn)資源不夠或節(jié)點(diǎn)維護(hù)而驅(qū)逐 Pod 時，Pod 也將被刪除。Kubernetes 通過引入 Controller（控制器）的概念來管理 Pod 實(shí)例。在 Kubernetes 中，更為推薦的做法是使用 Controller 來管理 Pod，而不是直接創(chuàng)建 Pod。
當(dāng)一個節(jié)點(diǎn)出現(xiàn)故障，控制器可以自動地在另一個節(jié)點(diǎn)調(diào)度一個配置完全一樣的 Pod，以替換故障節(jié)點(diǎn)上的 Pod。
控制器通過其中配置的 Pod Template 信息來創(chuàng)建 Pod
在 Kubernetes 中，廣泛使用的控制器有：Deployment、StatefulSet、DaemonSet。

4.k8s的設(shè)計(jì)思想
Kubernetes 項(xiàng)目最主要的設(shè)計(jì)思想是，從更宏觀的角度，以統(tǒng)一的方式來定義任務(wù)之間的各種關(guān)系，并且為將來支持更多種類的關(guān)系留有余地

5. pod和service
Pod 里的容器共享同一個 Network Namespace、同一組數(shù)據(jù)卷，從而達(dá)到高效率交換信息的目的
而對于另外一種更為常見的需求，比如 Web 應(yīng)用與數(shù)據(jù)庫之間的訪問關(guān)系，Kubernetes 項(xiàng)目則提供了一種叫作“Service”的服務(wù)。像這樣的兩個應(yīng)用，往往故意不部署在同一臺機(jī)器上，這樣即使 Web 應(yīng)用所在的機(jī)器宕機(jī)了，數(shù)據(jù)庫也完全不受影響?？墒?，我們知道，對于一個容器來說，它的 IP 地址等信息不是固定的，那么 Web 應(yīng)用又怎么找到數(shù)據(jù)庫容器的 Pod 呢？
Kubernetes 項(xiàng)目的做法是給 Pod 綁定一個 Service 服務(wù)，而 Service 服務(wù)聲明的 IP 地址等信息是“終生不變”的。這個Service 服務(wù)的主要作用，就是作為 Pod 的代理入口（Portal），從而代替 Pod 對外暴露一個固定的網(wǎng)絡(luò)地址。
這樣，對于 Web 應(yīng)用的 Pod 來說，它需要關(guān)心的就是數(shù)據(jù)庫 Pod 的 Service 信息。不難想象，Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自動更新、維護(hù)，則是 Kubernetes 項(xiàng)目的職責(zé)。

image.png

按照這幅圖的線索，我們從容器這個最基礎(chǔ)的概念出發(fā)，首先遇到了容器間“緊密協(xié)作”關(guān)系的難題，于是就擴(kuò)展到了 Pod；有了 Pod 之后，我們希望能一次啟動多個應(yīng)用的實(shí)例，這樣就需要 Deployment 這個 Pod 的多實(shí)例管理器；而有了這樣一組相同的 Pod 后，我們又需要通過一個固定的 IP 地址和端口以負(fù)載均衡的方式訪問它，于是就有了 Service。
可是，如果現(xiàn)在兩個不同 Pod 之間不僅有“訪問關(guān)系”，還要求在發(fā)起時加上授權(quán)信息。最典型的例子就是 Web 應(yīng)用對數(shù)據(jù)庫訪問時需要 Credential（數(shù)據(jù)庫的用戶名和密碼）信息。那么，在 Kubernetes 中這樣的關(guān)系又如何處理呢？
Kubernetes 項(xiàng)目提供了一種叫作 Secret 的對象，它其實(shí)是一個保存在 Etcd 里的鍵值對數(shù)據(jù)。這樣，你把 Credential 信息以 Secret 的方式存在 Etcd 里，Kubernetes 就會在你指定的 Pod（比如，Web 應(yīng)用的 Pod）啟動時，自動把 Secret 里的數(shù)據(jù)以 Volume 的方式掛載到容器里。這樣，這個 Web 應(yīng)用就可以訪問數(shù)據(jù)庫了

PV和PVC
PV 描述的，是持久化存儲數(shù)據(jù)卷。這個 API 對象主要定義的是一個持久化存儲在宿主機(jī)上的目錄，比如一個 NFS 的掛載目錄。
通常情況下，PV 對象是由運(yùn)維人員事先創(chuàng)建在 Kubernetes 集群里待用的。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.244.1.4
    path: "/"

而PVC 描述的，則是 Pod 所希望使用的持久化存儲的屬性。比如，Volume 存儲的大小、可讀寫權(quán)限等等。pvc 一般由開發(fā)人員創(chuàng)建

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  resources:
    requests:
      storage: 1Gi

而用戶創(chuàng)建的 PVC 要真正被容器使用起來，就必須先和某個符合條件的 PV 進(jìn)行綁定。這里要檢查的條件，包括兩部分：
第一個條件，當(dāng)然是 PV 和 PVC 的 spec 字段。比如，PV 的存儲（storage）大小，就必須滿足 PVC 的要求。
而第二個條件，則是 PV 和 PVC 的 storageClassName 字段必須一樣。這個機(jī)制我會在本篇文章的最后一部分專門介紹。
Pod 需要做的，就是在 volumes 字段里聲明自己要使用的 PVC 名字。接下來，等這個 Pod 創(chuàng)建之后，kubelet 就會把這個 PVC 所對應(yīng)的 PV，也就是一個 NFS 類型的 Volume，掛載在這個 Pod 容器內(nèi)的目錄上。
PVC 和 PV 的設(shè)計(jì)，其實(shí)跟“面向?qū)ο蟆钡乃枷胪耆恢?/strong>
PVC 可以理解為持久化存儲的“接口”，它提供了對某種持久化存儲的描述，但不提供具體的實(shí)現(xiàn)；而這個持久化存儲的實(shí)現(xiàn)部分則由 PV 負(fù)責(zé)完成。
這樣做的好處是，作為應(yīng)用開發(fā)者，我們只需要跟 PVC 這個“接口”打交道，而不必關(guān)心具體的實(shí)現(xiàn)是 NFS 還是 Ceph。畢竟這些存儲相關(guān)的知識太專業(yè)了，應(yīng)該交給專業(yè)的人去做。
在 Kubernetes 中，實(shí)際上存在著一個專門處理持久化存儲的控制器，叫作 Volume Controller。這個 Volume Controller 維護(hù)著多個控制循環(huán)，其中有一個循環(huán)，扮演的就是撮合 PV 和 PVC 的“紅娘”的角色。它的名字叫PersistentVolumeControlle
所謂容器的 Volume，其實(shí)就是將一個宿主機(jī)上的目錄，跟一個容器里的目錄綁定掛載在了一起 而所謂的“持久化 Volume”，指的就是這個宿主機(jī)上的目錄，具備“持久性”。。即：這個目錄里面的內(nèi)容，既不會因?yàn)槿萜鞯膭h除而被清理掉，也不會跟當(dāng)前的宿主機(jī)綁定。這樣，當(dāng)容器被重啟或者在其他節(jié)點(diǎn)上重建出來之后，它仍然能夠通過掛載這個 Volume，訪問到這些內(nèi)容。大多數(shù)情況下，持久化 Volume 的實(shí)現(xiàn)，往往依賴于一個遠(yuǎn)程存儲服務(wù)，比如：遠(yuǎn)程文件存儲（比如，NFS、GlusterFS）、遠(yuǎn)程塊存儲（比如，公有云提供的遠(yuǎn)程磁盤）等等。hostPath 和 emptyDir 類型的 Volume 并不具備這個特征：它們既有可能被 kubelet 清理掉，也不能被“遷移”到其他節(jié)點(diǎn)上。
這個準(zhǔn)備“持久化”宿主機(jī)目錄的過程，我們可以形象地稱為“兩階段處理”