前言：
公司算是很早一批使用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的簡單介紹，歡迎真正的大佬指正，共同學習。