雲計算與K8s的關係
- 其實在我們看到分類這一塊，不管是應用、環境、或者是硬件資源的限制，都面臨着一些問題，最典型的就是環境的不統一，如果開發人員，所使用的環境，跟我們最終上架部署時的環境不統一就容易出現各種問題，那麼這時候，docker就橫空出世了，他可以將我們所需要的環境進行封裝，封裝成一個鏡像，然後我們的開發人員在以這個鏡像爲基礎的容器裏發佈代碼，然後我們再將它製作成鏡像，就可以解決環境不統一的問題了。
- docker的出現，可以說是一個必然的產物，很顯然，docker公司抓住了這次機會，到後來，步入到容器世界這個新領域之後，慢慢的發現，我們對容器的要求越來越高，尤其企業級應用開發更是需要基於容器技術，實現支持多人協作的持續集成、持續交付等，這個時候kubernetes就又出現了。
kubernetes介紹
- 其實k8s出現的時間那，並不長，只有區區幾年的時間，就像是一個舵手，飛行員，是谷歌開發的，基於GO語言，大概是在2014年對外宣佈，所以到今年爲止也就5年時間，k8s的前身，其實是谷歌內部一個集羣管理編排系統，叫Borg（博格），它其實已經用了10幾年的時間了，可以說人們都知道谷歌有這種技術，但無奈人家是閉源的，自己用的，可以說是覬覦已久，可惜始終沒有辦法一窺究竟。後來那，隨着容器技術的發展，谷歌發現，這項技術的話語權可能要暴露的時候拿，谷歌索性用GO語言，從頭開始從寫了一個程序，就這短短几年的時間，k8s的發展非常迅速，尤其是k8s這種新興技術領域，我們的國人，傾入了大量的心血，非常不容易，不僅是我國，因爲大家都知道k8s是基於谷歌的borg系統而來的，可以說是吸引了的目光，不過它那也確實，沒有辜負了大家對它的這份期望。
- K8s的1.0版本，大概是在2015年7月份左右發佈，到現在也就4年時間，到現在那，它的版本已經到了 1.13，差不多1年3、4個版本的迭代。我們不妨去github上去看下一它的源碼, https://www.github.com/kubernetes。
- 在2017年，是容器發展歷程上具有里程碑意義的一年，因爲在這一年當中，AWS（亞馬遜雲）,微軟的雲（Azure）,還有我們的阿里雲等著名的雲計算公司，陸續宣佈，他們的雲環境那原生態支持K8S，也就是說，購買了雲服務的用戶，只要點擊一個按鈕，直接就可以快速生成K8S集羣環境供用戶使用，這些大公司的引用，說明了咱們k8s的已經收到了廣泛的認可。而且2017年10月份左右，docker公司宣佈那，在docker總網同時支持swarm和k8s兩種工具，swarm是docker拿來跟k8s競爭的，後來k8s太過受歡迎，到後來不得不在髮型的企業版本中原生支持k8s。
以上那，是我們k8s的一個發展的歷史，以及我們知道了k8s在未來是多麼的重要，那麼爲什麼他會這麼受歡迎那？都說它是一個容器編排工具，那麼它到底能夠實現哪方面那？特性有哪些？
- 自我修復：就是有自愈能力。就是說，一旦一個容器蹦了，出問題了，K8S它真的會去自動找到這個壞的容器，然後分析它到底哪裏出現了問題，再去修復它，重啓，是這樣麼？不是的，它的策略是，一個出現問題之後，直接幹掉，然後生成一個新的做一個替換，它是這樣一種修復方式。所以我們從這裏也應該發現一個趨勢，就是我們的關注點，已經像羣體，集羣的方式轉變，而不再是個體了。
- 自動實現水平擴展。一個容器不夠，再建一個，還不夠再建一個，只要你的物理資源允許的情況下，可以不斷的擴展。這個很好理解啊。
- 自動化的服務發現和負載均衡。當我們需要在k8s運行很多應用程序的時候，好比我們運行的是各種的微服務，如果一個微服務依賴於其他的一個微服務，它能夠通過這種自動找到他所依賴的服務，並且如果需要啓動多個容器的話，還能夠實現自動的負載均衡。後邊咱們會仔細將他們是怎麼實現的。
- 自動發佈和回滾，作爲以後的一名運維人員那，這是我們的一個日常運維任務。有了k8s之後，你就省事多了。
- 祕鑰和配置管理，假設說，我們現在分別運行了20個nginx，有一天那，需要對他們的配置文件進行改動，我們怎麼做那？一臺一臺配置麼？我們會利用ansible等一些工具，編寫腳本等方法來實現，可這最終還是需要我們人工操作，那麼k8s是怎麼實現的那？每個服務在啓動的時候，都會加載自己配置文件，一遍都是放在本地的，但K8s不是這樣做的，它設立了一個專門配置管理服務器，剛纔這20個nginx他們啓動的時候，不在是通過加載自己本地的配置文件啓動，而是先到配置服務器上加載信息，這樣做有什麼好處那？配置的集中化，也就是說，以後我們想要改配置文件，只需要改配置服務器，也就是我們配置中間這裏就可以了
- 存儲編排
- 任務的批量處理執行
kubernetes架構及原理
我們要知道，k8s集羣環境中，有master 和node之分，master作爲主節點，又有3個功能主鍵，APIserver，scheduler,controller-Manager.那麼node節點有3個，一個kuberlet，作爲集羣角色的核心主鍵，其實就是負責跟APIserver通信的一個核心主鍵。Docker是在pod裏面運行容器的。關於這個pod大家一定要有一個概念，作爲k8s邏輯上的最小單元，其實那，它也是一個容器，只不過因爲pod裏面可以運行單個或多個docker，所以說k8s在這點上做的比較嚴謹。一個集羣會有大量pod，爲了更好的管理這些pod，K8s又給Pod定義了元素類信息，label,一種KV，label:key=value格式的數據。而且在k和v上還有一定的限制，定義完以後那，我們還可以用Label selector（標籤選擇器）:通過過濾條件，來挑選出符合要求的pod資源。
接下來那，讓我們來更深入的來理解它的一些其他的概念。
比如說，在k8s之上，我們運行了容器之後，同一類容器，或者說同一類pod可能不止一個，是吧？那麼既然如此，有兩個問題，第一：當用戶的請求到達時，我們改如何接納用戶的請求，到底由後邊同一類pod裏面那個pod來負責和響應，第二：pod是要有控制器來管理，儘量不要人工手工參與操作，事實上在k8s上，pod有兩類，這個兩類的，官方上是並沒有給出定義的，是我們自己給它分的類，第一類叫：自助式pod：自我管理的，我們創建以後，仍然是需要提交給APIserver，由APIserver接受以後，藉助於調度器來調度node節點，由node啓動此pod，如果有容器出現故障，需要重啓容器，那麼就kubelet來完成，但是如果node節點故障，那麼pod就消失了，也就是說容器就消失了，不能工作了。所以它還有這樣一個弊端。所以我們推薦大家使用第二類Pod：是有控制器來參與管理的pod。也正式因爲有控制器這種機制的使用，來管理參與創建Pod,所以在k8s集羣中設計中，pod完全可以叫做有生命週期的對象。然後，由控制器來調度pod將其調度至集羣中的某節點，運行以後，任務終止，進程也就被刪除，也就沒有了。但是傳統意義上像我們啓動一個tomcat和一個nginx的話，他們完成啓動任務之後，會作爲守護進程來運行的，也就是說如果發現他有問題的話，有可能是要進程重啓之類的操作。如果這一切都要我們人工來進行監控，甚至一些監控軟件都很難來實現，畢竟作爲軟件開發而言，你軟件本身就應該有這樣的功能，所以咱們k8s的這個功能就叫pod控制器。這種pod控制器有很多種，最早的一種，ReplicationController:副本控制器，意思是，當我們啓動一個pod，比如是一個nginxpod，那麼如果這一個pod不夠了，那麼我們就需要再啓動一個，那麼這個pod就叫做副本，其實每一個都可以成爲副本，那麼控制器，就控制着同一類資源的各種pod對象和副本，一旦發現副本數量少了，那麼它會跟APIserver請求，APIserver再通過調度器scheduler添加一個，同理如果多了一個，也會刪除。這個處理方式那叫做多退少補。爲的是要精確符合我們用戶的定義。比方說我們現在運行着兩個，其中一個壞了，就會通過APIserver添加一個新的，這裏我麼暫且不說，他們的數據之間的遷移，只看這個副本的數量，它是保持着跟原來定義的是一樣的。
我們的replicationcontroller就是來實現這個功能的，它還能實現什麼功能的？比如滾動更新，比如我們公司現在運行的服務是1.0鏡像版本啓動的，現在我們需要做一次大的升級，要把它變成1.1版本。這個時候就需要我們把運行在pod容器裏的docker鏡像替換成1.1版本，我們怎麼做那？這個時候就用到我們的滾動更新了。需要怎麼做那?比如說運行的有2個副本，我們可以先關閉一個副本，當然也可以不關，那麼我們在更新的時候能先創建一個新的副本，原先不是定義說只運行兩個副本嗎？在更新的時候是可以臨時添加副本的，那麼我們的新副本創建完成之後，再刪除之前的老版本，以此類推，直到全部更新完成，這就叫滾動更新。這裏注意一點，我們不僅可以替換新的版本，而且還可以把舊版本在替換回來，那麼這叫回滾操作。這個那就是早期的pod控制器，到後面那，k8s推出了一個叫ReplicaSet（叫副本集控制器），但ReplicaSet不直接使用，他有一個聲明式控制器，叫Deployment來負責管理，但Deployment只能用來負責管理那麼無狀態的應用，什麼叫無狀態服務，什麼叫有狀態服務，在這裏那，先不跟你們深說，你們現在先可以這麼理解，無狀態的服務，它是沒有做數據持久化的操作的，有狀態的服務，是有一部分數據可以做持久化，具體的我們現在不說，以後，我們會有類似的實驗。另外我們的Deployment控制器還支持二級控制器進程叫HPA，叫水平pod自動伸縮控制器，這個跟我們上面所說說的那個多退少補，是差不多類似的，比如說我們後邊定義的是後邊運行服務對CPU利用率不成超過60%，但現在明顯2個POD無法滿足，那麼它就會自動增加POD數量，至於增加幾個，那就要經過計算機的計算了。但現在明顯2個剛纔說了無狀態，那麼有狀態的就是statefulset，另外，如果我們需要只每一個node幾點上，運行一個副本，而不是隨意運行那麼就需要DaemonSet,job,Ctonjob週期性作業，這些那就是常見的控制器，光pod控制器就這麼一大推，而我們剛纔提到的job和Ctonjob只是爲了完成某些特定任務來指定的，job完成一次性的作業，例如日誌備份，備份完成之後，job消失。那麼Ctonjob用於特定操作，而且時間不太固定，比如我們現在生成了一大堆的數據集，需要我們做一個清理，臨時的啓動一個pod來執行這個清理動作，那麼這個就叫做job，任務完成，job消失，所以這麼多pod管理器，是用來分別對應不同的服務來指定的，以便於更好的服務於用戶。
kubernetes這個名字起源於古希臘，是舵手的意思，所以它的logo既像一張漁網，又像一個羅盤。 Kubernetes是一個爲了自動化部署、擴展伸縮和管理容器應用的開源系統。 它將組成應用程序的容器組合成邏輯單元，便於管理和發現。Kubernetes是建立在15年穀歌的生產運行的工作經驗上的，並且從社區結合了佳的想法和做法。 同時支持兩種容器技術：Docker和Rocket（CoreOS）
他是一個全新的基於容器技術的分佈式架構領先方案。Kubernetes(k8s)是 Google開源的容器集羣管理系統（谷歌內部:Borg）。在Docker技術的基礎上，爲容器化 的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提高了大規模容 器集羣管理的便捷性
Master節點
Master節點上面主要由四個模塊組成：APIServer、scheduler、controller manager、etcd
Master是集羣的網關和中樞，負責諸如爲用戶和客戶端暴露API、跟蹤其他服務器的健康狀態、以最優方式調度工作負載，以及編排其他組件之間的核心聯絡點，並負責kubernetes系統的大多數集中式管控邏輯。單個master節點即可完成其所有的功能，但出於冗餘及負載均衡的目的，生產環境中通常需要協同部署多個此類主機。Master節點類似於蜂羣中的蜂王。
APIServer。
APIServer負責對外提供RESTful的Kubernetes API服務，它是系統管理指令的統一入口，任何對資源進行增刪改查的操作都要交給APIServer處理後再提交給etcd。kubectl（Kubernetes提供的客戶端工具，該工具內部就是對 Kubernetes API的調用）是直接和APIServer交互的
Scheduler
scheduler的職責很明確，就是負責調度pod到合適的Node上。如果把scheduler看成一個黑匣子，那麼它的輸入是pod和由多個Node組成的列表，輸出是 Pod和一個Node的綁定，即將這個pod部署到這個Node上。Kubernetes目前提供了調度算法，但是同樣也保留了接口，用戶可以根據自己的需求定義自己的調度算法
controller manager
如果說APIServer做的是“前臺”的工作的話，那 controller manager就是負責“後臺”的。每個資源一般都對應有一個控制器，而 controller manager就是負責管理這些控制器的。比如我們通過APIServer創建一個pod， 當這個pod創建成功後，APIServer的任務就算完成了。而後面保證Pod的狀態始終和我們 預期的一樣的重任就由controller manager去保證了
etcd
etcd是一個高可用的鍵值存儲系統，Kubernetes使用它來存儲各個資源的 狀態，其實不僅能夠提供鍵值數據存儲，而且還爲其提供了監聽機制。kubbernetes系統中，etcd中的鍵值發生變化時會通知到APIserver，並由其通過watchAPI向客戶端輸出。基於watch機制，kubernetes集羣的各組件實現了高效協同合作。
Node
Nodde負責提供運行容器的各種依賴環境，並接受Master的管理。
每個Node節點主要由三個模塊組成：kubelet、kube-proxy、runtime
runtime
runtime指的是容器運行環境，目前Kubernetes支持docker和rocket 兩種容器，它負責下載鏡像和運行容器。kubelet並未固定鏈接至某容器運行時環境，而時以插件的方式載入配置的容器環境。
kube-proxy
該模塊實現了Kubernetes中的服務發現和反向代理功能。反向代理方面：kube-proxy支持TCP和UDP連接轉發，默認基於Round Robin算法將客戶端流量 轉發到與service對應的一組後端pod。服務發現方面，kube-proxy使用etcd的watch機 制，監控集羣中service和endpoint對象數據的動態變化，並且維護一個service到 endpoint的映射關係，從而保證了後端pod的IP變化不會對訪問者造成影響。另外kubeproxy還支持session affinity。
kubelet
Kubelet是Master在每個Node節點上面的agent，是Node節點上面 重要的模塊，它負責維護和管理該Node上面的所有容器，負責Pod對應的容器的創建、啓 停等任務。但是如果容器不是通過Kubernetes創建的，它並不會管理。本質上，它負責使 Pod得運行狀態與期望的狀態一致
至此，Kubernetes的Master和Node就簡單介紹完了。下面我們來看Kubernetes中的各種資源/對象
Pod
Pod 是Kubernetes的基本操作單元，也是應用運行的載體。整個Kubernetes系統都是 圍繞着Pod展開的，比如如何部署運行Pod、如何保證Pod的數量、如何訪問Pod等。另 外，Pod是一個或多個相關容器的集合，這可以說是一大創新點，提供了一種容器的組合的 模型。
除了基礎的組件之外，通常一個完整的kubernetes集羣還會由一組“附件”，那麼這些附件，通常時第三方提供的特定應用程序。
KubeDNS
在kubernetes集羣中調度運提供DNS服務的Pod，同一集羣中的其他Pod可使用此DNS服務解決主機名，Kubernetes自1.11版本開始默認使用CoreDNS項目爲集羣提供服務註冊和服務發現的動態名稱解析服務，之前的版本中用到的是kube-dns項目，而SkyDNS則是更早一代的項目
Kuberenets Dashboard
Kubernets集羣的全部功能都要給予Web的UI來管理集羣中的應用甚至是集羣自身
Heapster
容器和節點的性能監控和分析系統，收集並解析多種指標數據，如資源利用率、生命週期時間等，新版本的Kubernetes中，其功能會逐漸有Prometheus結合其他組件所取代
Ingress Controller
Server是一種工作於傳統層的負載均衡器，而Ingress是在應用層實現的HTTP(s)負載均衡機制，不過Ingrress資源自身並不能進行“流量穿透”，它僅是一組路由規則的集合，這些規則需要通過Ingress控制器（ingress Controller）發揮作用，目前，此類的可用項目有Nginx、Traefik、Envoy及HAProxy
