前文速讀
第一章：Docker與k8s的恩怨情仇（一）—成為PaaS前浪的Cloud Foundry
第二章：Docker與k8s的恩怨情仇（二）—用最簡單的技術實現“容器”
第三章：Docker與k8s的恩怨情仇（三）—后浪Docker來勢洶洶
第四章：Docker與k8s的恩怨情仇（四）-雲原生時代的閉源落幕
第五章：Docker與k8s的恩怨情仇（五）——Kubernetes的創新
第六章：Docker與k8s的恩怨情仇（六）—— “容器編排”上演“終結者”大片
第七章：Docker與k8s的恩怨情仇（七）—— “服務發現”大法讓你的內外交互原地起飛
在系統介紹了如何實際部署一個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中涉及的那些技術點和各種難記的名詞一一解釋清楚顯然是不可能的，我們的想法是讓大家通過一步一步了解整個雲生態的演化過程，從而最終理解整個項目。
最后想送給大家一句話：
紙上得來終覺淺，絕知此事要躬行。
在我們開發組成員第一遍看完這些文檔之后覺得自己已經完全掌握了，但是在實際的文檔撰寫過程中，才發現自己兩眼一抹黑，不知道從何開始。
太多的知識點只停留在聽說過，僅僅知道是什么的階段。在這里還是建議大家動起手來，試試文中提到的實例，我們相信在自己動手寫過一遍之后，你會對這些內容不一樣的理解。
雖然本系列文章已經結束，但在后續的內容中我們也會繼續為大家講述更多葡萄城中新老葡萄在工作過程中遇到的各種技術揭秘、分享。
覺得內容不錯點個贊再走吧~