go語言
k8s的源碼托管在GitHub上
Pass 雲計算的平台級服務
紅帽內部平台級服務產品叫openshift，而openshitf的核心就是k8s
K8s可以:
1、自動裝箱
2、自我修復
3、水平擴展
4、服務發現和負載均衡
5、自動發布和回滾
6、密鑰和配置管理
7、存儲編排
8、批量處理執行
當一個容器出現問題的時候，直接kill掉，重新創建，這樣實現修復
======================================
K8s從運維角度來講其實就是一個集群，組合多台主機的資源整合成一個大的資源池，並統一對外提供計算、存儲等能力的集群
這個就是把多個主機當一個主機來使用，前提是分別在多個主機上安裝k8s的相關的應用程序，讓大家在這個級別上完成通信從而完成彼此之間的協調
但是在k8s中主機是分角色的，大家知道集群有常用的兩種模型:
1、p2p 沒有中心節點，每一個節點本身都可以接受服務請求，能路由請求的那種模型
2、有中心節點的集群，像mysql的主從復制，有一個是主節點，其它都跟着同步
k8s就是一個有中心節點架構的集群
K8s架構的特點:
Master:
一般兩三個就可以了，因為他們彼此之間需要做高可用，Master是整個集群的唯一路口
各nodes:
每個都是來貢獻一部分計算能力，說白了他們就是用來運行容器的節點
用戶怎么在這個集群中運行容器呢？
客戶端請求要先發給Master，把創建、啟動容器的請求交給Master，Master當中有一個調度器，去分析現有的各nodes的資源狀態，找一個最佳適配運行用戶請求的容器的節點，並把它調度上去，由這個node本地的或其他容器引擎負責把這個容器啟動起來
要啟動容器是不是需要用到鏡像？鏡像在何處？DockerHub或者私有倉庫當中，如果用戶請求在本地中找不到鏡像就會從DockerHub和私有倉庫中拖下來並創建運行
鏡像本身可以是在容器中,所以我們完全可以吧倉庫托管在k8s自身上了
接收請求的剛才講到是k8s Cluster，大家知道，提供服務能讓客戶端遠程訪問到，需要一個套接字向外提供，而套接字對外提供服務一般都是API接口，所以我們客戶端要么通過編程訪問要么通過專門編好的客戶端程序
k8s的的確確就把Master上的組件稱為叫做API Server
Master負責接收、解析、處理請求
K8s中的調度器叫做scheduler，他負責去觀測每一個node之上總共可用的資源量，cpu、mem、
===============
K8S通過兩級的方式調度:
第一步:先做預選 看看節點中有多少個容器是符合需求的，比如共有十個，篩選后發現只有三個符合要求
第二步:優選 取決於優先的算法來決定
在node上裝有keepalived應用程序,負責檢查容器的健康運行狀態的，問題來了，萬一我們在某個node上運行起來了，萬一此容器掛了，那么托管在本容器的其他容器就沒了，但是K8S有自愈能力，它會在其他節點上創建出一模一樣的容器，那么問題是如何確保該容器是健康的，怎么才能知道它是故障的，是不是需要持續監控着它們，所以K8S上實現了一大堆叫控制器的應用程序，讓你負責去監控它所管理的每一個容器是否是健康的，一旦發現不健康，控制器就負責想MasterAPI Server發送請求，說我的容器掛了一個，然后調度重新啟動一個，因此Master有個組件叫控制器，這個控制器要在本地不停地loop(循環)，周期性探測
如果負責健康檢查的控制器出問題了那么怎么辦？答:在master上做第三個組件，非常重要的組件叫 負責檢查每個控制器是否健康，那么有人想到了，如果控制器管理器也掛了呢？答:在控制器管理級別做冗余？怎么做？別忘了Master可以有很多個節點，它們之間是冗余關系，每個Master節點上都有控制器管理器，萬一哪個Master掛了其它Master節點可以頂替上來的
總結:K8S有三個重要的組件:
1、API Server 負責響應客戶端(接收和處理請求)
2、Scheduler 調度容器容器創建的請求
3、控制器管理器，確保控制器是否健康，而控制器確保創建的容器處於健康運行狀態
補充:K8S支持眾多的控制器，控制容器健康的只是其中一種，它還有很多其它的控制器
另外:我們以后在K8S之上就不能再這么稱呼容器了，因為在K8S上最小運行的單元是不是容器，而是pod，K8S調度的目標是pod，可以把它理解為容器的外殼，給容器作為一種抽象的封裝，pod便成了K8S系統之上最小的調度的邏輯單元，pod內部主要是用來存放容器的，但是pod有個工作特點:
大家記不記得:可以將多個容器聯和起來，加入到同一個網絡名稱空間中去，所以這是pod的工作特點
一個pod可以包含多個容器，這些容器可以共享同一個底層的網絡名稱空間(NET、UTS、IPC) 而user MNT pad是相互隔離的
並且pod里面的容器還可以共享同一個存儲卷，並且，存儲卷不在容器內，它屬於pod，相當於是pod的虛擬磁盤
各node主要是運行pod的
各位要注意的是一般一個pod內只放一個容器，除非容器之間有特別緊密的關系需要放在同一pod當中
如果pod中有多個容器那么滿足:
假如我們這個容器中跑的是nginx，它會生成很多日志，我們要收集日志通常需要在目標服務器上部署一個日志收集的agent---，那么就部署在輔助容器上，非主容器叫做 編車(set car)主要是輔助主容器的某些功能而設置的
所以我們的調度器調度的也是pod，我們的node也是運行pod，pod是k8s的原子單元，也就是一個pod無論有一個容器還是多個容器，一旦我們把某個pod調度到某個node上運行后，這一個pod上的所有容器只能運行在同一個node上，這個要注意
node概念:
node是k8s集群的工作節點 ，負責運行Master指派的各種任務，最核心的任務是一pod的形式去運行容器，理論上node可以是任何形式上的設備，只要能夠有傳統意義上的cpu、內存、存儲空間，還能夠裝上k8s相關的套件，都可以當做集群的一份子來工作，k8s執行的效果可以是如下:
當用戶請求Master創建資源時，那么我們還有沒有那么多cpu、內存源啊等我們做一個統一資源調度評估，那么終端用戶就無需關心我們的資源到底是運行在哪個節點上，就實現了雲里霧里的計算了
那么這么多pod運行在一個集群當中，那么將來分類管理怎么辦？比如我們要刪除某一類的pod，那么怎么刪除呢？我只想讓某一部分控制器控制管理某一類pod，那么怎么管理？怎么能識別，能挑揀出這一類pod呢？
我們不可能用名稱來識別，畢竟隨時都會創建出一個來，名稱假如是一個獨有標識符的話，一個pod因為故障而被刪除以后重新建立一個新的pod，那么新pod跟原pod可能不一樣只不過他內容和應用程序是一樣的，我們不能靠名稱來識別，同時我們可能需要將一類pod歸組，如創建了四個nginx需要歸為一類pod，並同一管理，如果我們把控制器刪了，就把四個nginx容器同步刪了，控制器還需要確保這四個nginx還在的，缺一個，他需要補一個，多一個，它需要多殺一個，精確符合我們期望的四個才行，控制器要完成這個功能
所以為了能夠實現pod能夠被識別，我們需要在pod上附加一些元數據
用標簽來識別pod，也就是你創建玩pod的時候可以直接給pod打上標簽，讓控制器或人能夠基於標簽的這個值來識別標簽了，換句話來說來識別pod了
k8s標簽類的組件:標簽選擇器:Lable select