kubernetes基礎學習（基於本身對公司k8s知識普及的ppt）

前言：

  公司算是很早一批使用k8s（kubernetes）的那一羣，印象中是17年下半年就開始使用，也算是kubernetes使用的先驅之一了，從剛開始認識k8s到如今使用接近2年，陸陸續續從入門學習，到如今玩的還算溜，也踩過N多坑，血淚史也是一篇接一篇的，雖然用了兩年多，公司不少人仍是不太瞭解這個東西究竟是啥，因而乎，在領導推進下，我寫了一篇基礎的關於kubernetes的介紹，事先說明，此文技術乾貨不多，大多數是理論介紹（雖然網上資料不少，我也算是收集了一下。），儘可能用簡單明瞭的方式去介紹這個大殺器，最後會有一點點的經常使用命令介紹，再重申一遍，這裏沒有具體的技術乾貨，部署什麼的，網上文檔不少，此處不會作細緻描寫。（固然，若是是大牛願意跟我討論k8s仍是很歡迎，畢竟我仍是菜鳥）

什麼是kubernetes：

   kubernetes，簡稱K8s，是用8代替8個字符「ubernete」而成的縮寫。是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單而且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制‘’經過部署容器方式實現，每一個容器之間互相隔離，每一個容器有本身的文件系統 ，容器之間進程不會相互影響，能區分計算資源。 Kubernetes最先是Google開源的一個容器編排引擎，它的前身是谷歌內部研發的Borg系統以及後來的Omega，它支持自動化部署、大規模可伸縮、應用容器化管理。在生產環境中部署一個應用程序時，一般要部署該應用的多個實例以便對應用請求進行負載均衡。 在Kubernetes中，咱們能夠建立多個容器，每一個容器裏面運行一個應用實例，而後經過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不須要運維人員去進行復雜的手工配置和處理。

 

   以上總結下，kubernetes是基於容器化而且集成了部署，規劃，更新，維護爲一體的生產級的編排應用架構。kubernetes的各類支持是很是好的，支持自動化部署，自動彈性伸縮，應用容器化管理。另外kubernetes對語言的親和性也很好，幾乎全部語言均可以跑在kubernetes的容器集羣裏，kubernetes更多的是讓人注重於應用層面的變化，而不是更多的關注於底層。

kubernetes內部組件簡單介紹以及服務發現機制：

  在介紹k8s內部組件以前，我但願看到我這篇文章的朋友，必定要拋棄一個概念，雖然k8s的節點概念是存在的，可是不要去想節點，底層全部節點實際上是給k8s集羣提供資源的，若是還用傳統運維的思想去看節點的話，是很難弄懂k8s的機制的。雖然這個理解是我我的的想法，可是我仍是但願能給看到文章的朋友必定的幫助。下面我會用我我的理解的方式來介紹一下k8s的組件，由於我的所學有限，若是有錯誤的地方歡迎指出。

kubectl--k8s命令的發佈者：咱們管理整個k8s集羣的時候，須要各類命令，在master節點或者管理節點上，kubectl就是這個命令的發佈者，觀察集羣，操控集羣，部署等等，都是依賴於這個命令來完成的。

APIServer--k8s集羣的通訊樞紐 ： API這個概念如今應該都不陌生，在k8s集羣裏，全部的命令下達，甚至是管理節點的信息傳達變動等等都須要這個組件進行信息的傳達，若是他掛了。集羣整個都會失聯。

etcd--k8s數據的存儲者： k8s核心組件之一，有國內大牛參與的項目，這個能夠單獨拎出來作個集羣，基於key-value模式進行數據存儲，整個集羣的信息，變動，規則，都是存儲在他這裏。

Controller Manager--k8s資源管理者、控制者： 整個節點的資源的管理，控制都是靠這個組件，它會對整個節點的資源進行一個觀察和反饋，甚至於pod的生存週期都受它的控制，生殺大權的掌控者。

Scheduler--k8s資源的調度者： 業務pod根據所寫編排的規則進行調度的組件，它會根據使用者編寫的規則或者默認規則，根據資源的狀況進行調度。

kubelete--k8s接受命令部署節點的大總管： 這個組件也是節點上必備核心之一，接受命令，傳輸調度，變動信息都須要它來作，若是一個節點的它掛了，整個節點全部業務也會掛掉。

kube-proxy--k8s服務發現者： kubernetes的服務發現是基於服務名，並不是傳統意義上的域名，想要發現自身的服務，就須要它在中間作架橋，相似網絡架橋的組件吧。

core-dns--k8s內部dns組件： 服務名的解析者，與上面的是一對，它負責對內，對外的解析，這個能夠理解爲超微型的dns服務器。

Pod--k8s對外服務的基礎容器組： k8s裏常常聽到的一個名詞。pod是個容器組，能夠單個、多個容器組合到一塊兒，對外服務的基本單位。

ingress--k8s對外服務組件:  想要外面的人訪問進來，須要這個組件，相似nginx的反代，它會按照編排好的規則進行服務發現以及對外服務。

下面插入幾張簡單示意圖，簡單說明下k8s的組件發現機制：

kubernetes的外部服務發現機制：

  如下爲k8s的外部發現服務的機制，是否經過ingress進入集羣內部服務的區分，（圖我找了很久，這兩張手畫的至關詳細了），圖（1）中標識了在未增長ingress的狀況下，直接經過負載或者節點端口而後service發現服務，這種狀況有點相似傳統的冗餘架構，各走各的，每一個模塊的壓力會比較大，節點端口冗餘，並且須要多個端口多個域名來區分，在服務模塊量比較大的狀況下維護起來會特別耗時。圖（2）中則是增長了ingress，經過ingress的反代機制，只有一個流量入口，反代到service上，而後進行服務的各類發現，在資源上節約了入口資源，流量不至於太分散，管理起來也比較方便。

（1）（2）

 

kubernetes的內部服務發現機制：

  如下爲內部服務發現機制，對於一個企業來講，並非須要全部的東西都暴露在公網之上，k8s集羣就很好的將一些服務發現內置在了集羣內部循環，以前介紹的組件，kube-proxy，core-dns起到相當重要的做用，在這裏還要介紹一個概念，（這個概念屬於我的理解）service，在k8s內部也好，外部也好，service至關於整個服務pod服務發現的大門，經過service來進行服務的外部，內部發現，同時也具備必定的負載做用，service的做用，連通着外部ingress---->service---->pod、pod---->service---->pod的重要角色，另外要記住，pod是隨時能夠銷燬的，可是由於service的存在，因此，銷燬pod以後，再生成一個新的它依舊會被發現的緣由，而在內部，這個依舊適用，它會經過kube-proxy和core-dns的組件進行內部服務名的發現，而後進行內部的通訊循環。下面的圖也很好的說明了這個。

 

 

 

kubernetes的一些簡單命令使用：

  k8s的命令其實網上不少，通常都會用命名空間和節點label對節點和資源進行控制，因此一些簡單的命令仍是有必要去記一下：

     kubectl get xxxxx  -n xxx  （在某個明明空間下獲取k8s資源信息，這裏能夠獲取節點，業務pod，系統pod等等信息，增長 -o 參數能夠指定輸出格式）

     kubectl logs xxxx -n xxxx  （通常用於觀察業務pod的日誌輸出，也能夠用於觀察節點信息，這個對平常找bug很好用）

     kubectl exec -it xxx -n xxxx  --/bin/bash  （這個命令很像docker，主要是用於進入pod，在日誌做用不明顯的狀況下，進入pod具體排查，在有多個容器組成的pod裏面須要指定容器的label）

 k8s的編排之類不會在這裏說，以上爲k8s的簡單介紹，歡迎真正的大佬指正，共同窗習。