一.Kubernetes介紹
1.1 什麼是K8S
作用：用于自動部署、擴充和管理“容器化（containerized）應用程式”的開源系統。
可以了解成 K8S 是負責自動化運維管理多個容器化程式（比如 Docker）的叢集，是一個生态極其豐富的容器編排架構工具。
由來：k8S由google的Borg系統(博格系統，google内部使用的大規模容器編排工具)作為原型，後經G0語言延用Borg的思路重寫并捐獻給CNCF基金會開源
含義：詞根源于希臘語的舵手、飛行員
官網: https://kubernetes.io
GitHub: https://github.com/kubernetes/kubernetes
1.2為什麼要用K8S
試想下傳統的後端部署辦法:把程式包(包括可執行二進制檔案、配置檔案等)放到伺服器上，接着運作啟動腳本把程式跑起來，同時啟動守護腳本定期檢查程式運作狀态、必要的話重新拉起程式
設想一下，如果服務的請求量上來，已部署的服務響應不過來怎麼辦?傳統的做法往往是，如果請求量、記憶體、CPU超過門檻值做了告警，運維人員馬上再加幾台伺服器，部署好服務之後，接入負載均衡來分擔已有服務的壓力
這樣問題就出現了:從監控告警到部署服務，中間需要人力介入! 那麼，有沒有辦法自動完成服務的部署、更新、解除安裝和擴容、縮容呢?
而這就是K8S要做的事情: 自動化運維管理容器(Docker) 程式。K8s的目标是讓部署容器化應用簡單高效
K8S解決了裸跑Docker的若幹痛點:
●單機使用，無法有效叢集
●随着容器數量的.上升，管理成本攀升
●沒有有效的容災、自愈機制
●沒有預設編排模闆，無法實作快速、大規模容器排程
●沒有統一 的配置管理中心工具
●沒有容器生命周期的管理工具
●沒有圖形化運維管理工具
k8s提供了容器編排，資源排程，彈性伸縮，部署管理，服務發現等一系列功能
1.3 K8S的特性
●彈性伸縮
使用指令、UI或者基于CPU使用情況自動快速擴容和縮容應用程式執行個體，保證應用業務高峰并發時的高可用性:業務低峰時回收資源，以最小成本運作服務
●自我修複
在節點故障時重新啟動失敗的容器，替換和重新部署，保證預期的副本數量:殺死健康檢查失敗的容器，并且在未準備好之前不會處理用戶端請求,確定線上服務不中斷
●服務發現和負載均衡
K8s為多個容器提供一-個統一通路入口(内部IP位址和一個DNS名稱)，并且負載均衡關聯的所有容器，使得使用者無需考慮容器IP問題
●自動釋出(預設滾動釋出模式)和復原
K8S采用滾動更新政策更新應用，一次更新一個Pod，而不是同時删除所有Pod，如果更新過程中出現問題，将復原更改，確定更新不受影響業務
●集中化配置管理和密鑰管理
管理機密資料和應用程式配置，而不需要把敏感資料暴露在鏡像裡，提高敏感資料安全性。并可以将一些常用的配置存儲在K8S中，友善應用程式使用
●存儲編排，支援外挂存儲并對外挂存儲資源進行編排
挂載外部存儲系統，無論是來自本地存儲，公有雲( 如AWS)，還是網絡存儲( 如NFS、Glusterfs、Ceph) 都作為叢集資源的一部分使用， 極大提高存儲使用靈活性
●任務批處理運作
提供一次性任務，定時任務:滿足批量資料處理和分析的場景
二.K8S叢集架構與元件
K8s是屬于主從裝置模型(Master-Slave 架構)，即有Master 節點負責叢集的排程、管理和運維，Slave 節點是叢集中的運算工作負載節點
在K8S中，主節點一般被稱為Master 節點，而從節點則被稱為Worker Node 節點，每個Node 都會被Master 配置設定一些工作負載
Master元件可以在群集中的任何計算機上運作，但建議Master節點占據一個獨立的伺服器
因為Master是整個叢集的大腦，如果Master所在節點當機或不可用，那麼所有的控制指令都将失效
除了Master， 在K8s叢集中的其他機器被稱為Worker Node節點，當某個Node當機時，其上的工作負載會被Master自動轉移到其他節點上去
2.1 Master元件
Master：叢集控制管理節點，所有的指令都經由master處理
●Kube-apiserver
用于暴露Kubernetes API，任何資源請求或調用操作都是通過kube-apiserver提供的接口進行。以HTTP Restful API
提供接口服務，所有對象資源的增删改查和監聽操作都交給API Server處理後再送出給Etcd存儲
可以了解成API Server 是K8S的請求入口服務。API Server 負責接收K8S所有請求(來自UI界面或者CLI指令行工具)，
然後根據使用者的具體請求，去通知其他元件幹活。可以說API Server 是K8S叢集架構的大腦
●Kube-controller-manager
運作管理控制器，是K8S 叢集中處理正常任務的背景線程，是K8S叢集裡所有資源對象的自動化控制中心。
在K8S叢集中，一個資源對應一個控制器，而Controller manager就是負責管理這些控制器的
由一系列控制器組成，通過APIServer監控整個叢集的狀态，并確定叢集處于預期的工作狀态，比如當某個Node意外當機時，Controller Manager會及時發現并執行自動化修複流程，確定叢集始終處于預期的工作狀态
這些控制器主要包括:
●Node Controller(節點控制器):負責在節點出現故障時發現和響應
●Replication Controller (副本控制器) :負責保證叢集中一個RC (資源對 象Replication Controller) 所關聯的Pod
副本數始終保持預設值。可以了解成確定叢集中有且僅有N個Pod執行個體，N是RC中定義的Pod副本數量
●Endpoints Controller (端點控制器) :填充端點對象 (即連接配接Services 和Pods) ，負責監聽 Service 和對應的Pod副本的變化
可以了解端點是一個服務暴露出來的通路點，如果需要通路一個服務，則必須知道它的endpoint
●Service Account & Token Controllers ( 服務帳戶和令牌控制器) :為新的命名空間建立預設帳戶和API通路令牌
●ResourceQuota Controller(資源配額控制器):確定指定的資源對象在任何時候都不會超量占用系統實體資源
●Namespace Controller ( 命名空間控制器) :管理namespace的生命周期
●Service Controller (服務控制器) :屬于K8S叢集與外部的雲平台之間的一個接口控制器
●Kube-scheduler
是負責資源排程的程序，根據排程算法為新建立的Pod選擇-一個合适的Node節點
可以了解成K8S所有Node節點的排程器。當使用者要部署服務時，Scheduler 會根據排程算法選擇最合适的Node 節點來部署Pod
●預算政策(predicate)
●優選政策( priorities)
2.2 配置存儲中心---etcd
K8S的存儲服務
etcd 是分布式鍵值存儲系統，存儲了K8S 的關鍵配置和使用者配置，K8S中僅API Server 才具備讀寫權限，其他元件必須通過 API Server的接口才能讀寫資料。
2.3 Worker Node元件
2.3.1 Node節點的工作流程：
Node節點可動态增加到kubernetes叢集中，前提是這個節點已經正确安裝、配置和啟動了上述的關鍵程序，預設情況下，kubelet會向Master注冊自己，這也kubernetes推薦的Node管理方式。
一旦Node被納入叢集管理範圍，kubelet會定時向Master彙報自身的情況，以及之前有哪些Pod在運作等，這樣Master可以獲知每個Node的資源使用情況，并實作高效均衡的資源排程政策。
如果Node沒有按時上報資訊，則會被Master判斷為失聯，Node狀态會被标記為Not Ready，随後Master會觸發工作負載轉移流程。
●Kubelet
Node節點的螢幕，以及與Master節點的通訊器。Kubelet 是Master節點安插在Node節點上的“眼線”，它會定時向API Server彙報自己
Node節點上運作的服務的狀态，并接受來自Master節點的訓示采取調整措施
從Master節點擷取自己節點上Pod的期望狀态(比如運作什麼容器、運作的副本數量、網絡或者存儲如何配置等)，
直接跟容器引擎互動實作容器的生命周期管理，如果自己節點上Pod的狀态與期望狀态不一緻，則調用對應的容器平台接口(即docker的接口)達到這個狀态
管理鏡像和容器的清理工作，保證節點上鏡像不會占滿磁盤空間，退出的容器不會占用太多資源
●Kube-Proxy
在每個Node節點上實作pod網絡代理，是Kubernetes Service 資源的載體，負責維護網絡規則和四層負載均衡工作。負責寫入規則至iptables、ipvs實作服務映射通路的
Kube-Proxy本身不是直接給Pod 提供網絡，Pod的網絡是由Kubelet 提供的，Kube-Proxy 實際上維護的是虛拟的Pod叢集網絡
Kube-apiserver通過監控Kube-Proxy 進行對Kubernetes Service 的更新和端點的維護
在K8S叢集中微服務的負載均衡是由Kube-proxy實作的。Kube-proxy是K8S叢集内部的負載均衡器。它是一個分布式代理伺服器，在K8S的每個節點上都會運作一個Kube-proxy 元件
●docker engine（docker或rocket）
容器引擎，運作容器，負責本機的容器建立和管理工作
三.K8S核心概念
Kubernetes包含多種類型的資源對象: Pod、 Label、 Service、 Replication Controller 等
所有的資源對象都可以通過Kubernetes 提供的 kubectl工具進行增、删、改、查等操作，并将其儲存在etcd中持久化存儲
Kubernets其實是一個高度自動化的資源控制系統，通過跟蹤對比etcd存儲裡儲存的資源期望狀态與目前環境中的實際資源狀态的差異，來實作自動控制和自動糾錯等進階功能
●Pod
Pod是Kubernetes 建立或部署的最小/最簡單的基本機關，一個Pod 代表叢集上正在運作的一個程序
可以把Pod了解成豌豆莢，而同一Pod内的每個容器是一顆顆豌豆
一個Pod由一個或多個容器組成，Pod中容器共享網絡、存儲和計算資源，在同一台Docker主機上運作
一個Pod裡可以運作多個容器，又叫邊車模式(sideCara) 模式。而在生産環境中一般都是單個容器或者具有強關聯互補的多個容器組成一個Pod
同一個Pod之間的容器可以通過localhost 互相通路，并且可以挂載Pod内所有的資料卷;但是不同的Pod之間的容器不能用localhost通路，也不能挂載其他Pod的資料卷
●Pod 控制器(五大控制器)
Pod控制器是Pod啟動的一種模版，用來保證在K8S裡啟動的Pod 應始終按照使用者的預期運作(副本數、生命周期、健康狀态檢查等)
K8S内提供了衆多的Pod 控制器，常用的有以下幾種:
●Deployment：無狀态應用部署。Deployment 的作用是管理和控制Pod和Replicaset， 管控它們運作在使用者期望的狀态中
●Replicaset: 確定預期的Pod副本數量。Replicaset 的作用就是管理和控制Pod，管控他們好好幹活。 但是，Replicaset 受控于Deployment
可以了解成Deployment 就是總包工頭，主要負責監督底下的勞工Pod幹活，確定每時每刻有使用者要求數量的Pod在工作。
如果一旦發現某個勞工Pod不行了，就趕緊新拉一個Pod過來替換它。而ReplicaSet 就是總包工頭手下的小包工頭
從K8S使用者角度來看，使用者會直接操作Deployment 部署服務，而當Deployment 被部署的時候，K8S 會自動生成要求的ReplicaSet 和Pod。
使用者隻需要關心Deployment 而不操心ReplicaSet
資源對象Replication Controller是ReplicaSet 的前身，官方推薦用Deployment 取代Replication Controller來部署服務
●Daemonset: 確定所有節點運作同一類Pod，保證每個節點上都有一個此類Pod運作，通常用于實作系統級背景任務
●Statefulset:有狀态應用部署
●Job: 一次性任務。根據使用者的設定，Job管理的Pod把任務成功完成就自動退出了
●Cronjob: 周期性計劃性任務
●Label
标簽，是K8S特色的管理方式，便于分類管理資源對象
Label可以附加到各種資源對象上，例如Node、Pod、Service、 RC等，用于關聯對象、查詢和篩選。
一個Label是一個key-value 的鍵值對，其中key 與value 由使用者自己指定
一個資源對象可以定義任意數量的Label，同一個Label也可以被添加到任意數量的資源對象中，也可以在對象建立後動态添加或者删除
可以通過給指定的資源對象捆綁一個或多個不同的Label，來實作多元度的資源分組管理功能
與Label 類似的，還有Annotation (注釋)
差別在于有效的标簽值必須為63個字元或更少，并且必須為空或以字母數字字元([a-z0-9A-Z]) 開頭和結尾，中間可以包含橫杠(-)、下劃線(_)、點(.)和字母或數字。注釋值則沒有字元長度限制
●Label選擇器(Label selector )
給某個資源對象定義一個Label， 就相當于給它打了一個标簽;随後可以通過标簽選擇器(Label selector) 查詢和篩選擁有某些Label的資源對象
标簽選擇器目前有兩種:基于等值關系(等于、不等于)和基于集合關系(屬于、不屬于、存在)
●Service
在K8S的叢集裡，雖然每個Pod會被配置設定一個單獨的IP位址，但由于Pod是有生命周期的(它們可以被建立，而且銷毀之後不會再啟動)，随時可能會因為業務的變更，導緻這個IP位址也會随着Pod 的銷毀而消失，Service就是用來解決這個問題的核心概念。
K8S中的Service 并不是我們常說的“服務”的含義，而更像是網關層，可以看作一組提供相同服務的Pod的對外通路接口、流量均衡器，Service作用于哪些Pod 是通過标簽選擇器來定義的。
在K8S叢集中，Service 可以看作一組提供相同服務的Pod 的對外通路接口。用戶端需要通路的服務就是Service 對象。
每個Service都有一個固定的虛拟ip (這個ip也被稱為Cluster IP) ，自動并且動态地綁定後端的Pod, 所有的網絡請求直接通路Service 的虛拟ip，Service會自動向後端做轉發
Service除了提供穩定的對外通路方式之外，還能起到負載均衡(Load Balance) 的功能，自動把請求流量分布到後端所有的服務上，service可以做到對客戶透明地進行水準擴充(scale)
而實作service 這一功能的關鍵， 就是kube-proxy。 kube -proxy運作在每個節點上，監聽API Server中服務對象的變化，
可通過以下三種流量排程模式: userspace (廢棄)、iptables (瀕臨廢棄)、ipvs (推薦，性能最好)來實作網絡的轉發。
Service是K8S服務的核心，屏蔽了服務細節，統一對外暴露服務接口， 真正做到了“微服務”。比如我們的一個服務A，部署了3
個副本，也就是3個Pod;對于使用者來說，隻需要關注一個Service 的入口就可以，而不需要操心究競應該請求哪一個Pod。
優勢非常明顯:一方面外部使用者不需要感覺因為Pod. 上服務的意外崩潰、 K8S 重新拉起Pod 而造成的IP變更，外部使用者也不需要感覺因更新、變更服務帶來的Pod替換而造成的IP變化。
●Ingress
Service主要負責K8S 叢集内部的網絡拓撲，那麼叢集外部怎麼通路叢集内部呢?這個時候就需要Ingress了。
Ingress是整個K8S叢集的接入層，負責叢集内外通訊
Ingress是K8S 叢集裡工作在OSI網絡參考模型下，第7層的應用，對外暴露的接口，典型的通路方式是http/https
Service隻能進行第四層的流量排程，表現形式是ip+port。Ingress則可以排程不同業務域、不同URL通路路徑的業務流量。
比如:用戶端請求http://www.ly.com:port ---> Ingress ---> Service ---> Pod
●Name
由于K8S内部，使用“資源”來定義每一種邏輯概念(功能)，是以每種“資源”，都應該有自己的“名稱”
“資源”有api版本(apiversion) 、類别(kind)、中繼資料(metadata) 、定義清單(spec)、狀态(status) 等配置資訊
“名稱”通常定義在“資源”的“中繼資料”資訊裡。在同一個namespace 空間中必須是唯一的
●Namespace
随着項目增多、人員增加、叢集規模的擴大，需要一種能夠邏輯上隔離K8S 内各種“資源"的方法，這就是Namespace
Namespace是為了把一個K8S叢集劃分為若千個資源不可共享的虛拟叢集組而誕生的
不同Namespace 内的“資源”名稱可以相同，相同Namespace 内的同種“資源”， “名稱”不能相同
合理的使用K8S的Namespace，可以使得叢集管理者能夠更好的對傳遞到K8S裡的服務進行分類管理和浏覽
K8S裡預設存在的Namespace 有: default、 kube-system、 kube-public 等
查詢K8S 裡特定“資源”要帶上相應的Namespace
k8s的架構以及工作流程
master節點：API server shceduler controller-manager
worker node 節點：kubelet kube-proxy docker engine
工作流程或者各個元件的功能：
1、使用者通過用戶端發送請求給API server,API Server 接收請求建立一批Pod，會存儲pod資料到etcd
2、Controller-manager 通過API Server 到etcd中讀取按照預設的模闆去建立Pod,Controller-manager 又會通過API Server讓Scheduler為新建立的Pod 根據預算政策以及優選政策，選擇最适合的Node 節點把pod排程過來
比如運作這個Pod需要2C 4G 的資源，Scheduler 會通過預算政策在所有Node’節點中挑選最優的。Node 節點中還剩多少資源是通過彙報給API Server 存儲在etcd 裡，API Server 會調用一個方法找到etcd裡所有node節點的剩餘資源，再對比pod所需要的資源，在所有node節點中查找哪些node節點符合要求
如果都符合，預算政策就交給優選政策處理，優選政策再通過CPU 的負載、記憶體的剩餘量等因素選擇最合适的Node節點，并把Pod排程到這個Node’節點上運作
3、scheduler通過Api server來讓Kubelet根據排程結果執行Pod建立操作，并且對node節點進行監視，會定時向api server彙報自己node節點運作的服務狀态,并且存儲到etcd中
在這期間，Controller Manager同時會根據K8S的mainfiles檔案執行RC Pod的數量來保證指定的Pod副本數
4、在每個node上都會有一個kube-proxy，來實作pod的網絡代理，它是Kubernetes Service 資源的載體。在任何一個節點上通路一個service的虛拟ip，都可以通路到pod，提供cluster ip的通路入口
所有Node上運作的Proxy程序通過APIServer查詢并監聽service對象與其對應的Endponts資訊，建立一個軟體方式的負載均衡器來實作Service通路到後端Pod的流量轉發功能