在系統介紹瞭如何實際部署一個K8S專案後，作為本系列文章的最後一篇，我們一起來看看Kubernetes叢集內容總覽，再對一些更深層次的功能進行總結。
Kubernetes總覽
下圖是一個k8s的總覽結構內容
可以看到圖中提到的這些功能模組中，還有一些是在本文中並沒有出現的：
l ConfigMap
用來儲存使用者配置檔案定義的，通過其內部的Volume投射技術實現，其實也是Volume掛載的一種方式。這種方式不僅可以實現應用程式被的複用，而且還可以通過不同的配置實現更靈活的功能。在建立容器時，使用者可以將應用程式打包為容器映象後，通過環境變數或者外接掛載檔案的方式進行配置注入。
l Secret
Secret 物件型別用來儲存敏感資訊，例如密碼、OAuth 令牌和 SSH 金鑰。 將這些資訊放在Secret中比放在 Pod 的定義、容器映象中、相對於ConfigMap說更加安全和靈活。 Secret是標準的k8s資源物件，使用方法和ConfigMap非常類似。同時我們可以對Secret進行訪問控制，防止機密資料被訪問
l PV
PVC是Kubernetes中持久化資料卷的實現方式，它是StatefulSet的核心功能，也是Pod持久化的必要手段，Kubernetes通過PV和PVC拆分，從而達到功能點的解耦。
除了文中提到的內容之外， Kubernetes叢集的內容也遠比我們目前看到的複雜的多，也還有很多內容等待著我們探索。
在這裡，我們對這些深層次的功能做一個總結，也是一個對深入學習Kubernetes的梳理。
Kubernetes元件
我們平時做開發的過程中所使用的伺服器（即宿主機），在Kubernetes叢集中被稱為Node節點。
同時在Kubernetes中存在一個或者多個Master節點控制多個宿主機實現叢集，整個Kubernetes的核心排程功能基本都在Master節點上。
Kubernetes的主要功能通過五個大元件組成：
- kubelet：安裝在Node節點上，用以控制Node節點中的容器完成Kubernetes的排程邏輯
- ControllerManager：是我們上述所講的控制器模式的核心管理元件，管理了所有Kubernetes叢集中的控制器邏輯
- API Server：服務處理叢集中的api請求，我們一直寫的kubectl，其實就是傳送給API Server的請求，請求會在其內部進行處理和轉發
- Scheduler：負責Kubernetes的服務排程，比如控制器只是控制Pod的編排，最後的排程邏輯是由Scheduler所完成並且傳送請求給kubelet執行的
- Etcd：這是一個分散式的資料庫儲存專案，由CoreOS開發，最終被RedHat收購成為Kubernetes的一部分，它裡面儲存了Kubernetes叢集中的所有配置資訊，比如所有叢集物件的name，IP，secret，configMap等所有資料，其依靠自己的一致性演算法可以保證在系統中快速穩定的返回各種配置資訊，因此這也是Kubernetes和心中的核心元件
定製化功能
除了各種強大的元件功能之外，Kubernetes也給使用者提供了極高的自由度。
為了實現這種高度的自由，Kubernetes給使用者提供了三個公開的介面，分別是：
l CNI（Container Networking Interface，容器網路介面）：其定義了Kubernetes叢集所有網路的連結方式，整個叢集的網路都通過這個介面實現。只要實現了這個介面內所有功能的網路外掛，就可以作為Kubernetes叢集的網路配置外掛，其內部包括宿主機路由表配置、7層網路發現、資料包轉發等等都有各式各樣的小外掛，這些小外掛還可以隨意配合使用，使用者可以按照自己的需求自由定製化這些功能
l CSI（Container Storage Interface，容器儲存介面）定義了叢集持久化的一些規範，只要是實現這個介面的儲存功能，就可以作為Kubernetes的持久化外掛
l CRI（Container Runtime Interface，容器執行時介面）：在Kubernetes的容器執行時，比如預設配置的Docker在這個叢集的容器執行時，使用者可以自由選擇實現了這個介面的其他任意容器專案，比如之前提到過的containerd和rkt
這裡講一個有趣的點：CRI。
Kubernetes的預設容器是Docker，但是由於專案初期的競爭關係，Docker其實並不滿足Kubernetes所定義的CRI規範，那怎麼辦呢？
為了解決這個問題，Kubernetes專門為Docker編寫了一個叫DockerShim的元件，即Docker墊片，用來把CRI請求規範，轉換成為Docker操作Linux的OCI規範（對，就是第二部分提到的那個OCI基金會的那個規範）。但是這個功能一直是由Kubernetes專案維護的，只要Docker釋出了新的功能Kubernetes就要維護這個DockerShim元件。
於是，這個近期的訊息——Kubernetes將在明年的版本v1.20中刪除刪除DockerShim元件，意味著從明年的新版本開始，Kubernetes將全面不支援Docker容器的更新了。
但其實這對我們普通開發者來說可能並沒有什麼影響，最壞的結果就是我們的映象需要從Docker換成其他Kubernetes支援的容器映象。
不過根據這這段時間各個雲平臺放出的訊息來看，這些平臺都會提供對應的轉換措施，比如我們還是提供Docker映象，平臺在釋出運維的時候會把這些映象轉換成其他映象；又或者這些平臺會自行維護一個DockerShim來支援Docker，都是有解決方案的。
架構總覽與總結
這一部分我們來看看Kubernetes的架構圖：
通過這一系列的學習，作為一個普通程式設計師，不得不讚嘆Google對編碼這件事得深厚與極致，框架中因為太多僅因為解耦而產生的元件，並且還提供了這麼大的自由度，不得不說是我們活字格開發團隊學習過程中遇到的一個很有技術深度的框架。
但這種過高的自由度也有負面作用。
在部署過程中，Kubernetes叢集的複雜度非常高，部署一個滿足生產環境需求的Kubernetes框架更是難上加難，網上還有專門賣Kubernetes生產環境叢集部署的指令碼程式，可見Kubernetes系統的龐大。
在學習的過程中可以使用kinD或者minikube在本地以Docker的形式模擬一個Kubernetes叢集，但是這種程度的學習距離生產環境還是有一定的差距。
總結
這個系列文章，詳細的描述了我們活字格開發團隊上天過程中碰到的幾個難啃的神仙。
從雲平臺的發展到k8s的具體使用，一步一步抽絲剝繭地向大家解釋了一個雲平臺，從最初的虛擬機器，到PaaS雛形，到Docker容器化，再到最終Kubernetes的形態的過度和演變。
人的記憶是需要依賴於前驅節點的，僅僅通過一篇文章就想把Kubernetes中涉及的那些技術點和各種難記的名詞一一解釋清楚顯然是不可能的，我們的想法是讓大家通過一步一步瞭解整個雲生態的演化過程，從而最終理解整個專案。
最後想送給大家一句話：
紙上得來終覺淺，絕知此事要躬行。
在我們開發組成員第一遍看完這些文件之後覺得自己已經完全掌握了，但是在實際的文件撰寫過程中，才發現自己兩眼一抹黑，不知道從何開始。
太多的知識點只停留在聽說過，僅僅知道是什麼的階段。在這裡還是建議大家動起手來，試試文中提到的例項，我們相信在自己動手寫過一遍之後，你會對這些內容不一樣的理解。
雖然本系列文章已經結束，但在後續的內容中我們也會繼續為大家講述更多葡萄城中新老葡萄在工作過程中遇到的各種技術揭祕、分享。
覺得內容不錯點個贊再走吧~
轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。