kubernetes簡介html
kubernetes是用於管理多個機器上容器化應用的開源系統平臺，它擁有一套容器應用部署、規劃、更新、維護機制，讓應用部署更簡單高效。核心的特色就是可以自主的管理容器來保證雲平臺中的容器按照用戶的指望狀態運行。node
kubernetes集羣基礎概念mysql
Clusternginx
Cluster是網絡、存儲、計算各類資源的集合，k8s利用這些資源運行容器應用。
redisMastersql
Master是集羣的管理中心，負責調度，決定將應用放置在哪裏運行，能夠同時運行多個master以保證高可用。
dockerNode後端
Node是集羣的工做節點，負責運行容器應用，node由master管理，node負責監控並彙報容器的狀態，同時根據master要求管理容器的生命週期。Node上運行着Kubelet、kube-proxy服務進程，這些服務進程負責Pod的建立、啓動、監控、重啓、銷燬、以及實現軟件模式的負載均衡。查看node，kubectl get node， kubectl describe nodeapi
Pod安全
pod是k8s的最小工做單元，每一個pod包含一個或者多個容器，一般狀況下運行單一容器，也便是one-container-per-Pod模式；對於多個容器有緊密聯繫且須要共享資源的則使用多容器模式。
一個pod中的應用容器共享資源：Pod中的不一樣應用程序能夠看到其餘應用程序的進程ID；Pod中的多個容器可以訪問同一個IP和端口範圍；Pod中的多個容器可以使用SystemV IPC或POSIX消息隊列進行通訊；Pod中的多個容器共享一個主機名；Pod中的各個容器能夠訪問在Pod級別定義的Volumes；
Pod的生命週期經過Replication Controller來管理；經過模板進行定義，而後分配到一個Node上運行，在Pod所包含容器運行結束後，Pod結束。
Controller
k8s一般不會直接建立pod，它是經過controller來管理pod，k8s提供了多種controller，有Deployment、ReplicaSet、DaemonSet、StatefuleSet、job等。Deployment管理pod及其副本，並保證pod按照指望的狀態運行；ReplicaSet管理多個副本，使用deployment會自動建立ReplicaSet，因此一般不須要直接用ReplicaSet；DaemonSet用於每一個node最多運行一個pod副本的場景；StatefuleSet保證pod的每個副本在整個生命週期中名稱是不變的。Job用於運行結束就刪除的應用，其餘controller的pod一般是長期運行。
Service
一個Service能夠看做一組提供相同服務的Pod的對外訪問接口，Service做用於哪些Pod是經過Label Selector來定義的，service有本身的ip和端口，爲pod提供負載均衡。
Namecpace
namespace是將物理的cluster邏輯上劃分紅多個虛擬的cluster，每個cluster就是一個namespace，不一樣的namespace裏的資源是徹底隔離的，kubectl get namespace命令查看，default是默認的命名空間，kebe-system是k8s本身建立的系統資源的命名空間。
Volume
volume是pod中可以被多個容器訪問的共享目錄
kubernetes架構
Kubernetes將集羣中的機器劃分爲一個Master節點和一羣工做節點（Node）。其中，Master節點上運行着集羣管理相關的一組進程etcd、API Server、Controller Manager、Scheduler，後三個組件構成了Kubernetes的總控中心，這些進程實現了整個集羣的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能，而且全都是自動完成。在每一個Node上運行Kubelet、Proxy、Docker daemon三個組件，負責對本節點上的Pod的生命週期進行管理，以及實現服務代理的功能。
Kubernetes主要由如下幾個核心組件組成：
etcd 保存了整個集羣的狀態； apiserver 提供了資源操做的惟一入口，並提供認證、受權、訪問控制、API註冊和發現等機制； controller manager 負責維護集羣的狀態，好比故障檢測、自動擴展、滾動更新等； scheduler 負責資源的調度，按照預約的調度策略將Pod調度到相應的機器上； kubelet 負責維護容器的生命週期，同時也負責Volume（CVI）和網絡（CNI）的管理； Container runtime 負責鏡像管理以及Pod和容器的真正運行（CRI）； kube-proxy 負責爲Service提供cluster內部的服務發現和負載均衡； kube-dns 負責爲整個集羣提供DNS服務 Ingress Controller 爲服務提供外網入口 Heapster 提供資源監控 Dashboard 提供GUI Federation 提供跨可用區的集羣 Fluentd-elasticsearch 提供集羣日誌採集、存儲與查詢
建立pod流程
經過Kubectl提交一個建立RC的請求，該請求經過API Server被寫入etcd中， 此時Controller Manager經過API Server的監聽資源變化的接口監聽到這個RC事件， 分析以後，發現當前集羣中尚未它所對應的Pod實例，因而根據RC裏的Pod模板定義生成一個Pod對象， 經過API Server寫入etcd，接下來，此事件被Scheduler發現，它當即執行一個複雜的調度流程，爲這個新Pod選定一個落戶的Node， 而後經過API Server將這一結果寫入到etcd中， 隨後，目標Node上運行的Kubelet進程經過API Server監測到這個「新生的」Pod， 並按照它的定義，啓動該Pod並不辭辛苦地負責它的下半生，直到Pod的生命結束。 最後 經過Kubectl提交一個新的映射到該Pod的Service的建立請求， Controller Manager會經過Label標籤查詢到相關聯的Pod實例， 而後生成Service的Endpoints信息，並經過API Server寫入到etcd中， 接下來，全部Node上運行的Proxy進程經過API Server查詢並監聽Service對象與其對應的Endpoints信息， 創建一個軟件方式的負載均衡器來實現經過Service訪問到後端Pod的流量轉發功能
k8s的分層架構
Kubernetes設計理念和功能其實就是一個相似Linux的分層架構
核心層：Kubernetes最核心的功能，對外提供API構建高層的應用，對內提供插件式應用執行環境 應用層：部署（無狀態應用、有狀態應用、批處理任務、集羣應用等）和路由（服務發現、DNS解析等） 管理層：系統度量（如基礎設施、容器和網絡的度量），自動化（如自動擴展、動態Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等） 接口層：kubectl命令行工具、客戶端SDK以及集羣 生態系統：在接口層之上的龐大容器集羣管理調度的生態系統，能夠劃分爲兩個範疇 Kubernetes外部：日誌、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等 Kubernetes內部：CRI、CNI、CVI、鏡像倉庫、Cloud Provider、集羣自身的配置和管理等
k8s 狀態服務
在K8S運行的服務，從簡單到複雜能夠分紅三類：無狀態服務、普通有狀態服務和有狀態集羣服務
無狀態服務
K8S使用RC（或更新的Replica Set）來保證一個服務的實例數量，若是說某個Pod實例因爲某種緣由Crash了，RC會馬上用這個Pod的模版新啓一個Pod來替代它，因爲是無狀態的服務，新啓的Pod與原來健康狀態下的Pod如出一轍。在Pod被重建後它的IP地址可能發生變化，爲了對外提供一個穩定的訪問接口，K8S引入了Service的概念重點內容。一個Service後面能夠掛多個Pod，實現服務的高可用。
普通有狀態服務
和無狀態服務相比，它多了狀態保存的需求。Kubernetes提供了以Volume和Persistent Volume爲基礎的存儲系統，能夠實現服務的狀態保存。
有狀態集羣服務
與普通有狀態服務相比，它多了集羣管理的需求。K8S爲此開發了一套以Pet Set爲核心的全新特性，方便了有狀態集羣服務在K8S上的部署和管理。具體來講是經過Init Container來作集羣的初始化工做，用 Headless Service 來維持集羣成員的穩定關係，用動態存儲供給來方便集羣擴容，最後用Pet Set來綜合管理整個集羣。
要運行有狀態集羣服務要解決的問題有兩個,一個是狀態保存，另外一個是集羣管理。 咱們先來看如何解決第一個問題：狀態保存。Kubernetes 有一套以Volume插件爲基礎的存儲系統，經過這套存儲系統能夠實現應用和服務的狀態保存。
在應用程序中，能夠分爲有狀態應用和無狀態應用。 無狀態的應用更關注於羣體，任何一個成員均可以被取代。 對有狀態的應用是關注個體。 像咱們前面用deployment控制器管理的nginx、myapp等都屬於無狀態應用。 像mysql、redis，zookeeper等都屬於有狀態應用，他們有的還有主從之分、前後順序之分。 statefulset控制器能實現有狀態應用的管理，但實現起來也是很是麻煩的。須要把咱們運維管理的過程寫入腳本並注入到statefulset中才能使用。雖然互聯網上有人作好了stateful的腳本，可是仍是建議你們不要輕易的把redis、mysql等這樣有狀態的應用遷移到k8s上。 在k8s中，statefulset主要管理一下特效的應用： a)、每個Pod穩定且有惟一的網絡標識符； b）、穩定且持久的存儲設備； c)、要求有序、平滑的部署和擴展； d）、要求有序、平滑的終止和刪除； e)、有序的滾動更新，應該先更新從節點，再更新主節點； statefulset由三個組件組成: a) headless service（無頭的服務，即沒名字）； b）statefulset控制器 c）volumeClaimTemplate（存儲卷申請模板，由於每一個pod要有專用存儲卷，而不能共用存儲卷）
K8S存儲系統
K8S的存儲系統從基礎到高級又大體分爲三個層次：普通Volume，Persistent Volume 和動態存儲供應(dynamic provisioning)。
普通Volume
單節點Volume是最簡單的普通Volume，它和Docker的存儲卷相似，使用的是Pod所在K8S節點的本地目錄。具體有兩種，一種是 emptyDir，是一個匿名的空目錄，由Kubernetes在建立Pod時建立，刪除Pod時刪除。另一種是 hostPath，與emptyDir的區別是，它在Pod以外獨立存在，由用戶指定路徑名。這類和節點綁定的存儲卷在Pod遷移到其它節點後數據就會丟失，因此只能用於存儲臨時數據或用於在同一個Pod裏的容器之間共享數據。
跨節點存儲卷
這種存儲卷不和某個具體的K8S節點綁定，而是獨立於K8S節點存在的，整個存儲集羣和K8S集羣是兩個集羣，相互獨立。跨節點的存儲卷在Kubernetes上用的比較多，若是已有的存儲不能知足要求，還能夠開發本身的Volume插件，只須要實現Volume.go 裏定義的接口。若是你是一個存儲廠商，想要本身的存儲支持Kubernetes 上運行的容器，就能夠去開發一個本身的Volume插件，目前支持不少種存儲方式，nfs，clusterfs，ceph，nas等等。
persistent volume和普通Volume的區別
普通Volume和使用它的Pod之間是一種靜態綁定關係，在定義Pod的文件裏，同時定義了它使用的Volume。Volume 是Pod的附屬品，咱們沒法單首創建一個Volume，由於它不是一個獨立的K8S資源對象。而Persistent Volume 簡稱PV是一個K8S資源對象，因此咱們能夠單首創建一個PV。它不和Pod直接發生關係，而是經過Persistent Volume Claim，簡稱PVC來實現動態綁定。Pod定義裏指定的是PVC，而後PVC會根據Pod的要求去自動綁定合適的PV給Pod使用。
PersistentVolumeClaim
用戶根據所需存儲空間大小和訪問模式建立（或在動態部署中已建立）一個 PersistentVolumeClaim。Kubernetes的Master節點循環監控新產生的PVC，找到與之匹配的PV（若是有的話），並把他們綁定在一塊兒。動態配置時，循環會一直將PV與這個PVC綁定，直到PV徹底匹配PVC。避免PVC請求和獲得的PV不一致。綁定一旦造成，PersistentVolumeClaim綁定就是獨有的，無論是使用何種模式綁定的。若是找不到匹配的volume，用戶請求會一直保持未綁定狀態。在匹配的volume可用以後，用戶請求將會被綁定。好比，一個配置了許多50Gi PV的集羣不會匹配到一個要求100Gi的PVC。 只有在100Gi PV被加到集羣以後，這個PVC才能夠被綁定。
PV的訪問模式
ReadWriteOnce：是最基本的方式，可讀可寫，但只支持被單個Pod掛載。
ReadOnlyMany：能夠以只讀的方式被多個Pod掛載。
ReadWriteMany：這種存儲能夠以讀寫的方式被多個Pod共享。不是每一種存儲都支持這三種方式，像共享方式，目前支持的還比較少，比較經常使用的是NFS。在PVC綁定PV時一般根據兩個條件來綁定，一個是存儲的大小，另外一個就是訪問模式。
靜態，是管理員手動建立一堆PV，組成一個PV池，供PVC來綁定。
動態，是指在現有PV不知足PVC的請求時，可使用存儲分類(StorageClass)，描述具體過程爲：PV先建立分類，PVC請求已建立的某個類（StorageClass）的資源，這樣就達到動態配置的效果。即經過一個叫 Storage Class的對象由存儲系統根據PVC的要求自動建立。
一個PV建立完後狀態會變成Available，等待被PVC綁定。一旦被PVC邦定，PV的狀態會變成Bound，就能夠被定義了相應PVC的Pod使用。Pod使用完後會釋放PV，PV的狀態變成Released。變成Released的PV會根據定義的回收策略作相應的回收工做。有三種回收策略，Retain、Delete 和 Recycle。Retain就是保留現場，K8S什麼也不作，等待用戶手動去處理PV裏的數據，處理完後，再手動刪除PV。Delete 策略，K8S會自動刪除該PV及裏面的數據。Recycle方式，K8S會將PV裏的數據刪除，而後把PV的狀態變成Available，又能夠被新的PVC綁定使用。在實際使用場景裏，PV的建立和使用一般不是同一我的。這裏有一個典型的應用場景：管理員建立一個PV池，開發人員建立Pod和PVC，PVC裏定義了Pod所需存儲的大小和訪問模式，而後PVC會到PV池裏自動匹配最合適的PV給Pod使用。
動態存儲供應（dynamic provisioning）
前面在介紹PV的生命週期時，提到PV的供給有兩種方式，靜態和動態。動態卷供給是一個 Kubernetes 獨有的功能，這一功能容許按需建立存儲卷。在沒有這種能力以前，集羣管理員須要打電話給他們的雲或者存儲提供者來建立新的存儲卷，成功之後再建立 PersistentVolume對象，纔可以在 Kubernetes 中使用。動態卷供給能力讓管理員沒必要進行預先建立存儲卷，而是隨用戶需求進行建立。這一特性在 1.2 版本中處於 α 階段，在版本 1.4 中提高爲 β。提升了動態卷的彈性和可用性。 其中動態方式是經過StorageClass來完成的，這是一種新的存儲供應方式。使用StorageClass有什麼好處呢？除了由存儲系統動態建立，節省了管理員的時間，還有一個好處是能夠封裝不一樣類型的存儲供PVC選用。在StorageClass出現之前，PVC綁定一個PV只能根據兩個條件，一個是存儲的大小，另外一個是訪問模式。在StorageClass出現後，等於增長了一個綁定維度。
k8s網絡方案
一、直接路由：
節點數量很少的狀況下，經過在每一個node上啓動docker的時候經過設置—bip並添加對應的路由能夠實現各個pod直接的網絡互聯互通，而且可與其餘物理機或者虛擬機進行直接通訊，由於沒有數據包的拆包解包工做。
直接路由網絡優點：性能較好，容易管理
直接路由網絡劣勢：網絡隔離性差，每次新增節點都須要手動設置路由規則。
二、Flannel容器網絡：
Flannel是CoreOS團隊針對Kubernetes設計的一個網絡規劃服務，簡單來講，它的功能是讓集羣中的不一樣節點主機建立的Docker容器都具備全集羣惟一的虛擬IP地址,在默認的Docker配置中，每一個節點上的Docker服務會分別負責所在節點容器的IP分配。這樣致使的一個問題是，不一樣節點上容器可能得到相同的內外IP地址。並使這些容器之間可以經過IP地址相互找到，也就是相互ping通。
Flannel的設計目的就是爲集羣中的全部節點從新規劃IP地址的使用規則，從而使得不一樣節點上的容器可以得到「同屬一個內網」且」不重複的」IP地址，並讓屬於不一樣節點上的容器可以直接經過內網IP通訊。
Flannel實質上是一種「覆蓋網絡(overlaynetwork)」，也就是將TCP數據包裝在另外一種網絡包裏面進行路由轉發和通訊，目前已經支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等數據轉發方式，默認的節點間數據通訊方式是UDP轉發。
Flannel之因此能夠搭建kubernets依賴的底層網絡，是由於它能夠實現如下兩點：
· 它給每一個node上的docker容器分配相互不想衝突的IP地址；
· 它能給這些IP地址之間創建一個覆蓋網絡，同過覆蓋網絡，將數據包原封不動的傳遞到目標容器內
Flannel網絡優點：部署簡單，性能還行
Flannel網絡劣勢：沒法隔離多子網，對上層設計依賴度高，沒有IPAM，IP地址浪費，對docker啓動方案有綁定。
三、Calico容器網絡：
Calico介紹
· Calico是一個純3層的數據中心網絡方案，並且無縫集成像OpenStack這種IaaS雲架構，可以提供可控的VM、容器、裸機之間的IP通訊。Calico不使用重疊網絡好比flannel和libnetwork重疊網絡驅動，它是一個純三層的方法，使用虛擬路由代替虛擬交換，每一臺虛擬路由經過BGP協議傳播可達信息（路由）到剩餘數據中心。
· Calico在每個計算節點利用Linux Kernel實現了一個高效的vRouter來負責數據轉發，而每一個vRouter經過BGP協議負責把本身上運行的workload的路由信息像整個Calico網絡內傳播——小規模部署能夠直接互聯，大規模下可經過指定的BGP route reflector來完成。
· Calico節點組網能夠直接利用數據中心的網絡結構（不管是L2或者L3），不須要額外的NAT，隧道或者Overlay Network。
· Calico基於iptables還提供了豐富而靈活的網絡Policy，保證經過各個節點上的ACLs來提供Workload的多租戶隔離、安全組以及其餘可達性限制等功能。
Calico網絡優點：性能較好，可控性高，隔離性好
Calico網絡劣勢：操做起來比較複雜，維護成本高，對iptables有依賴
calico https://www.kubernetes.org.cn/4960.html
各類應用方案知識點可參考官網
https://kubernetes.io/docs/home/