在第一章節我們熟悉了Docker的技術知識，那麼需要考慮的是如何管理這些Docker容器呢？在衆多容器編排管理平臺中kubernetes無疑是最主流的。Kubernetes起源於谷歌的borg系統。Borg是谷歌內部的容器管理系統，它主要的目的是實現資源管理的自動化以及有效的利用平臺資源。kubernetes的設計理念多源於borg系統，並且將borg中精華的部分提取出來。我們先來看一下kubernetes的基礎架構，如下所示：
先從整體入手，具體的組件將在第三章節詳細講解。在kubernetes中服務器的角色可以分爲controller plane和nodes兩種。Controller plane也可以理解爲kubernetes的master節點，最核心的組件就是kube-apiserver，它是kubernetes集羣的大腦負責管理整個集羣。而node節點是kubernetes中運行容器實例的部分，它上面跑的是真正運行的Docker容器和鏡像。
首先需要提到的是kubernetes的設計理念，也是它的核心概念：聲明式的API.聲明式設計與命令式設計是不同的，命令式的設計強調的是怎麼做，比如server端會發生命令叫client端執行哪項工作，然後收集執行結果。而聲明式設計更強調的是一種“期望”，server發出一份“期望”，client端會根據這份“期望”自行進行執行任務工作。在理解聲明式和命令式的區別時，大家可以想象命令式是基層領導，他在安排下屬工作的時候都要清楚每個員工的工作內容，安排好每個員工的工作。而命令式更像高層領導，他關心是公司的發展方向，指定發展目標和期望。如果隨着管理人數的越來越多，命令式的模式就會顯得力不從心了，管理端的壓力會越來越大，這也是聲明式的優勢。
在kubernetes中使用聲明式的API去描述整個集羣的狀態，運行在集羣中的實體稱之爲對象。Kubernetes集羣的期望狀態是指整個集羣工作負載的狀態描述，包括哪些容器運行狀態、集羣的資源使用情況、重啓和回滾策略等。而這些狀態的維護都是通過操作kubernetes API來實現的，API會將數據信息存儲在etcd中做持久化。那麼我們該怎麼聲明來告訴kubernetes API完成工作呢？可以通過yaml格式來寫一段描述，如下：
這份yaml的主要字段有apiVersion是說明需要調用kubernetes API的版本、kind是說明這個資源類型是Deployment、replicas是指期望2個副本數、而spec字段中主要聲明容器的鏡像名稱和開放端口等。我們通過這個yaml文件告訴kubernetes來“期望”創建這個類型的資源，kubernetes會通過各個組件的調用來實現我們的聲明。
在kubernetes的API設計原則有以下幾點：
API是遵循RESTful接口規則的並且應該是聲明式的，對於大規模的集羣環境這種設計可以保證集羣的穩定性和減輕master節點的工作負載，同時隱藏技術細節將API對象以對應的名稱暴露給使用者來描述一個集羣期望的狀態。
API的對象是從真正的實際工作場景中提煉出來的，滿足集羣建設的現實需求。比如Service、Ingress、Volume等，它解決了容器在集羣中的服務發現、對外訪問、存儲掛載等，可以支撐各自複雜的業務場景，同時它們也是高內聚、松耦合的，符合雲原生設計規範。
API的數據會被保存在etcd存儲系統中，同時使用各種控制器來獲取kubernetes API中的對象並實現相關的容器管理工作，控制邏輯應該只依賴當前狀態，這是爲了整個集羣的穩定可靠，在設計控制邏輯時儘量避免複雜狀態機制和邏輯。
Kubernetes 的基礎組件介紹
在kubernetes中首先要說的是Pod，Pod是kubernetes中最小的單位，一個容器有時候並不能對應複雜的應用，所以kubernetes提出了Pod這個概念，它是把應用的容器、存儲資源和獨立的網絡地址等資源打包在一起，作爲集羣中的最小單位，可以看到kubernetes從設計之初就是站着業務應用的視角上的，它能夠在應用中的多個容器之間進行協調工作，構建一個高內聚的服務單元，方便集羣中業務應用的發佈和運行。
Pod在kubernetes集羣中是如何運行的，都會經歷那些基礎組件呢？我們回個頭來再來看kubernetes的基礎架構圖，如下所示：
kube-apiserver是整個kubernetes的控制入口，上一章節已經有比較詳細的說明API的設計原則和特性，這裏就不過多的贅述。
kubectl是客戶端的命令行工具，我們編寫的yaml聲明文件會經過kubectl格式化發送給kube-apiserver，api會解釋聲明並存儲到etcd中。
kube-controller-manager是負責kubernetes中的控制邏輯，維護集羣中運行組件的整個生命週期，包括節點的狀態、Pod的個數等。
kube-scheduler是負責節點的資源管理和分配，在kube-apiserver中創建的Pod，scheduler會根據集羣的資源使用情況分配到對應的節點上，並且更新pod的最新狀態。
以上三個組件是運行在kubernetes control plane上，也就是master節點上，它們是整個集羣的核心組件。
etcd是集羣中的API信息的持久化存儲，它只會和kube-apiserver通信，API將接受的信息存儲到etcd中，etcd在生產環境中建議使用多節點部署（N+1），它符合Raft一致性算法。
kube-porxy是運行在Node節點上的，它負責Pod的網絡代理和負載均衡，通過它創建的訪問規則可以允許集羣內部或外部與Pod通信。
kubelet也是運行在Node節點上的，它會真正和容器進行關聯，維護和操作容器同時接收容器的運行狀態，將信息反饋給kube-apiserver.它作爲每個Node節點的agent，接受節點上Pod任務和管理容器和維護整個生命週期。
整個Pod的創建流程大概如下：
1）我們先編寫對應的yaml文件，通過kubectl提交Pod的創建任務，kube-apiserver與kubectl交互相應請求，通過認證和授權（rbac授權在以後的文章中可以詳細講解）完成Deployment資源的初始化，並將創建的信息存儲在etcd中做持久化。
2）kube-controller-manager通過watch機制，檢測kube-apiserver的狀態變化，當發現有新的Deployment資源類型的時候，將任務加入到工作隊列裏，通過各個控制循環，發現新的Deployment資源沒有關聯表述的Pod和Replicaset，啓用對應的replicaset controller創建Pod，同時更新kube-apiserver信息狀態。
3）kube-scheduler也是通過watch監聽最新的集羣狀態，當發現有新的Pod信息時，它會到整個集羣的Node節點進行打分和過濾，通過binding的方式將Pod綁定到對應Node主機上，同時最新的狀態也會同步到kube-apiserver上。
4）kubelet組件通過與kube-apiserver通信獲取相關的信息，當發現有信息聲明綁定關係時，會通過cni進行主機上的容器創建操作，新建Pod後也會將信息發送到kube-apiserver上，kube-apiserver接受的信息都會存儲到etcd中。
5）kube-proxy也會和kubelet類似，在接收到kube-apiserver端有Service的創建任務會在Node節點上創建相關的網絡規則和負載均衡策略。
以上就是Pod創建的大概流程，希望大家能夠了解並能夠在kubernetes的使用中有所體會。
如何在 Kubernetes 發佈你的應用
最後的章節我們來完成在kubernetes集羣中發佈應用的工作，可以使用之前的創建nginx的yaml聲明文件來完成我們的發佈任務。
首先如何創建一個kubernetes集羣，我們可以通過kubernetes官網上的交互式教程來完成，官網已經爲我們創建好了一個集羣，鏈接地址如下：
https://kubernetes.io/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/
我們可以通過kubectl命令交互來操作kubernetes集羣，比如kubectl get node來查看Node節點的信息，如下：
我們編寫一份nignx的yaml聲明文件，如下：
然後我們通過kubectl apply -f nginx.yaml來創建這個Deployment資源類型，kubernetes API會根據我們的聲明完成相關的工作內容。
同時我們可以通過kubectl describe命令查看每個Pod的運行狀態和信息。
這樣一個應用已經在kubernetes中運行起來了，是不是很簡單啊？kubernetes in 5 mins先暫時到這裏，希望大家通過我的描述能瞭解Docker和kubernetes的全貌並對今後的kubernetes之旅有幫助。對於一個應用在kubernetes中是如何服務發現的、容器之前的網絡架構、容器的對外訪問、rbac授權等等內容如果大家也感興趣，希望留言給我，我會整理好相關的內容和資料在後續的文章中發佈出來，今天就到這裏，謝謝大家。