kubernetes 基礎概念學習

一 Kubernetes概述
Kubernetes是一個全新的基於容器技術的分佈式架構領先方案。Kubernetes(k8s)是Google開源的容器集羣管理系統（谷歌內部:Borg）。在Docker技術的基礎上，爲容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提升了大規模容器集羣管理的便捷性。
　　Kubernetes是一個完備的分佈式系統支撐平臺，具備完備的集羣管理能力，多擴多層次的安全防禦和准入機制、多租戶應用支撐能力、透明的服務註冊和發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制以及多粒度的資源配額管理能力。
同時Kubernetes提供完善的管理工具，涵蓋了包括開發、部署測試、運維監控在內的各個環節。
Kubernetes中，Service是分佈式集羣架構的核心，一個Service對象擁有以下關鍵特徵：
擁有一個惟一指定的名字
擁有一個虛擬IP（Cluster IP、Service IP、或VIP）和端口號
可以提供某種遠程服務能力
被映射到了提供這種服務能力的一組容器應用上
　　Service的服務進程目前都是基於Socket通訊方式對外提供服務，好比Redis、Memcache、MySQL、Web Server，或者是實現了某個具體業務的一個特定的TCP Server進程，雖然一個Service一般由多個相關的服務進程來提供服務，每一個服務進程都有一個獨立的Endpoint（IP+Port）訪問點，但Kubernetes可以讓咱們經過服務鏈接到指定的Service上。有了Kubernetes內建的透明負載均衡和故障恢復機制，無論後端有多少服務進程，也無論某個服務進程是否會因爲發生故障而從新部署到其餘機器，都不會影響咱們對服務的正常調用，更重要的是這個Service自己一旦建立就不會發生變化，意味着在Kubernetes集羣中，咱們不用爲了服務的IP地址的變化問題而進行修復。
　　容器提供了強大的隔離功能，因此有必要把爲Service提供服務的這組進程放入容器中進行隔離。爲此，Kubernetes設計了Pod對象，將每一個服務進程包裝到相對應的Pod中，使其成爲Pod中運行的一個容器。爲了創建Service與Pod間的關聯管理，Kubernetes給每一個Pod貼上一個標籤Label，好比運行MySQL的Pod貼上name=mysql標籤，給運行PHP的Pod貼上name=php標籤，而後給相應的Service定義標籤選擇器Label Selector，這樣就能巧妙的解決了Service於Pod的關聯問題。
Pod運行在一個稱之爲節點（Node）的環境中，節點能夠是物理機，也能夠是虛擬機，經過一個節點運行幾百個Pod；其次每一個Pod裏運行着一個特殊的稱之爲Pause的容器，其餘容器則爲業務容器，全部業務容器共享Pause容器的網絡棧和Volume掛載卷，所以他們之間的通訊和交互更爲高效，所以在設計之初能夠將一組密切相關聯的服務進程放入同一個Pod中。
　　在集羣管理方面，Kubernetes將集羣中的機器劃分爲一個Master節點和一羣工做節點Node，其中，在Master節點運行着集羣管理相關的一組進程kube-apiserver、kube-controller-manager和kube-scheduler，這些進程實現了整個集羣的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理能力，而且都是全自動完成的。Node做爲集羣中的工做節點，運行真正的應用程序，在Node上Kubernetes管理的最小運行單元是Pod。Node上運行着Kubernetes的kubelet、kube-proxy服務進程，這些服務進程負責Pod的建立、啓動、監控、重啓、銷燬以及實現軟件模式的負載均衡器。
　　在Kubernetes集羣中，它解決了傳統IT系統中服務擴容和升級的兩大難題。你只需爲須要擴容的Service關聯的Pod建立一個Replication Controller簡稱（RC），則該Service的擴容及後續的升級等問題將迎刃而解。在一個RC定義文件中包括如下3個關鍵信息。
目標Pod的定義
目標Pod須要運行的副本數量（Replicas）
要監控的目標Pod標籤（Label）
　　在建立好RC後，Kubernetes會經過RC中定義的的Label篩選出對應Pod實例並實時監控其狀態和數量，若是實例數量少於定義的副本數量，則會根據RC中定義的Pod模板來建立一個新的Pod，而後將新Pod調度到合適的Node上啓動運行，直到Pod實例的數量達到預約目標，這個過程徹底是自動化。

二 Kubernetes優點、場景、特色
Kubernetes主要優點:
容器編排
輕量級
開源
彈性伸縮
負載均衡
Kubernetes常見場景：
快速部署應用
快速擴展應用
無縫對接新的應用功能
節省資源，優化硬件資源的使用
Kubernetes相關特色：
可移植: 支持公有云，私有云，混合雲，多重雲（multi-cloud）
可擴展: 模塊化, 插件化, 可掛載, 可組合
自動化: 自動部署，自動重啓，自動複製，自動伸縮/擴展

三 Kubetcl的核心概念
3.1 Master
　　k8s集羣的管理節點，負責管理集羣，提供集羣的資源數據訪問入口。擁有Etcd存儲服務（可選），運行Api Server進程，Controller Manager服務進程及Scheduler服務進程，關聯工做節點Node。
Kubernetes API server提供HTTP Rest接口的關鍵服務進程，是Kubernetes裏全部資源的增、刪、改、查等操做的惟一入口。也是集羣控制的入口進程；
Kubernetes Controller Manager是Kubernetes全部資源對象的自動化控制中心；
Kubernetes Schedule是負責資源調度（Pod調度）的進程。
3.2 Node
　　Node是Kubernetes集羣架構中運行Pod的服務節點（亦叫agent或minion）。Node是Kubernetes集羣操做的單元，用來承載被分配Pod的運行，是Pod運行的宿主機。關聯Master管理節點，擁有名稱和IP、系統資源信息。運行docker eninge服務，守護進程kunelet及負載均衡器kube-proxy.
每一個Node節點都運行着如下一組關鍵進程
kubelet：負責對Pod對於的容器的建立、啓停等任務，同時與Master節點協做，實現集羣管理的基本功能；
kube-proxy：實現Kubernetes Service的通訊與負載均衡機制的重要組件；
Docker Engine（Docker）：Docker引擎，負責本機容器的建立和管理工做。
　　Node節點能夠在運行期間動態增長到Kubernetes集羣中，默認狀況下，kubelet會想master註冊本身，這也是Kubernetes推薦的Node管理方式，kubelet進程會定時向Master彙報自身情報，如操做系統、Docker版本、CPU和內存，以及有哪些Pod在運行等等，這樣Master能夠獲知每一個Node節點的資源使用狀況，並實現高效均衡的資源調度策略。
3.3 Pod
　　運行於Node節點上，若干相關容器的組合。Pod內包含的容器運行在同一宿主機上，使用相同的網絡命名空間、IP地址和端口，可以經過localhost進行通訊。Pod是Kurbernetes進行建立、調度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod能夠包含一個容器或者多個相關容器。
　　Pod有兩種類型：普通Pod和靜態Pod。後者比較特殊，它並不存在Kubernetes的etcd存儲中，而是存放在某個具體的Node上的一個具體文件中，而且只在此Node上啓動。普通Pod一旦被建立，就會被放入etcd存儲中，隨後會被Kubernetes Master調度到摸個具體的Node上進行綁定，隨後該Pod被對應的Node上的kubelet進程實例化成一組相關的Docker容器並啓動起來，在默認狀況下，當Pod裏的某個容器中止時，Kubernetes會自動檢測到這個問題而且重啓這個Pod（重啓Pod裏的全部容器），若是Pod所在的Node宕機，則會將這個Node上的全部Pod從新調度到其餘節點上。

Pod的IP與ContainerPort（容器端口）共同構成了Endpoint，表示此Pod中的一個服務進程對外的通訊地址。
每一個Pod也能夠對其能使用的資源設置相應配額，CPU和內存的數值都爲絕對值，CPU一般定義爲千分之一單位，如100-300m，表示佔用0.1——0.3個CPU，內存一般以字節數表示，如64Mi。

3.4 Label（標籤）
Kubernetes中的任意API對象都是經過Label進行標識，Label的實質是一系列的Key/Value鍵值對，其中key與value可自定義。Label能夠附加到各類資源對象上，如Node、Pod、Service、RC等，一個資源對象能夠定義任意數量的Label，同一個Label也能夠被添加到任意數量的資源對象上去。Label是Replication Controller和Service運行的基礎，兩者經過Label來進行關聯Node上運行的Pod,能夠經過Label Selector（標籤選擇器）查詢和篩選資源對象。
一些經常使用的Label以下：
版本標籤："release":"stable","release":"canary"......
環境標籤："environment":"dev","environment":"qa","environment":"production"
架構標籤："tier":"frontend","tier":"backend","tier":"middleware"
分區標籤："partition":"customerA","partition":"customerB"
質量管控標籤："track":"daily","track":"weekly"
　　Label至關於咱們熟悉的標籤，給某個資源對象定義一個Label就至關於給它大了一個標籤，隨後能夠經過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源對象，Kubernetes經過這種方式實現了相似SQL的簡單又通用的對象查詢機制。
Label和Label Selector共同構成了Kubernetes系統中最核心的應用模型，是的被管理對象可以被精細的分組管理，同時實現了整個集羣的高可用性。
Label場景：
kube-Controller進程經過資源對象RC上定義Label Selector來篩選要監控的Pod副本的數量，從而實現副本數量始終符合預期設定的全自動控制流程
kube-proxy進程經過Service的Label Selector來選擇對應的Pod，自動創建起每一個Service島對應Pod的請求轉發路由表，從而實現Service的智能負載均衡
經過對某些Node定義特定的Label，而且在Pod定義文件中使用Nodeselector這種標籤調度策略，kuber-scheduler進程能夠實現Pod」定向調度「的特性。

3.5 Replication Controller
　　Replication Controller用來管理Pod的副本，保證集羣中存在指定數量的Pod副本。集羣中副本的數量大於指定數量，則會中止指定數量以外的多餘容器數量，反之，則會啓動少於指定數量個數的容器，保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。
定義RC包括以下幾個部分：
Pod期待的副本數（replicas）；
用於篩選目標Pod的Label Selector；
當Pod的副本數小於預期數量時，用於建立Pod的Pod模板（template）。
RC機制：
當定義了RC並提交至Kubernetes集羣中以後，Master節點上的Controller Manager組件獲悉，並同時巡檢系統中當前存活的目標Pod，並確保目標Pod實例的數量恰好等於此RC的指望值，若存在過多的Pod副本在運行，系統會中止一些Pod，反之則自動建立一些Pod。
注意：刪除RC並不會影響經過該RC已經建立的Pod。
提示：下一代RC，即Replica Sets與RC惟一的區別是RS支持基於集合的Label selector。
RC特性及場景：
經過定義RC實現Pod的建立過程及副本數量自動控制；
RC裏包括完整的Pod定義模板；
RC經過Label Selector機制實現副本的自動控制；
經過改變RC裏的Pod副本數量，能夠實現Pod的擴容或縮容功能；
經過改變RC的Pod模板的鏡像版本，能夠實現Pod的滾動升級功能。
3.6 Deployment
Deployment在內部使用了RS來實現目的，Deployment至關於RC的一次升級，其最大的特點爲能夠隨時獲知當前Pod的部署進度。
Deployment場景：
建立一個Deployment對象來生成對應的RS並完成Pod副本的建立過程；
檢查Deployment的狀態來看部署動做是否完成（即副本數量是否達到預期值）；
更新Deployment以建立新的Pod（好比鏡像升級）；
若是當前Deployment不穩定，則回滾到一個早先Deployment版本；
掛起或恢復一個Deployment。
3.7 HPA（Horizontal Pod Autoscaler）
Pod的橫向自動擴容，也是Kubernetes的一種資源，經過追蹤分析RC控制的全部Pod目標的負載變化狀況，來肯定是否須要針對性的調整Pod副本數量。
HPA針對Pod負載的兩種度量方式：
CPUUtilizationPercentage；
應用程序自定義的度量指標。
3.8 Service
　　Service定義了Pod的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，用戶不須要了解後臺Pod是如何運行。
外部系統訪問Service的機制：
Kubernetes的三種IP：
Node IP：Node節點的IP地址
Pod IP： Pod的IP地址
Cluster IP：Service的IP地址
　　首先,Node IP是Kubernetes集羣中節點的物理網卡IP地址，全部屬於這個網絡的服務器之間都能經過這個網絡直接通訊。這也代表Kubernetes集羣以外的節點訪問Kubernetes集羣以內的某個節點或者TCP/IP服務的時候，必須經過Node IP進行通訊；
　　其次，Pod IP是每一個Pod的IP地址，他是Docker Engine根據docker0網橋的IP地址段進行分配的，一般是一個虛擬的二層網絡；
　　最後Cluster IP是一個虛擬的IP，但更像是一個僞造的IP網絡，Cluster IP特色：
Cluster IP僅僅做用於Kubernetes Service這個對象，並由Kubernetes管理和分配P地址；
Cluster IP沒法被ping，他沒有一個「實體網絡對象」來響應；
Cluster IP只能結合Service Port組成一個具體的通訊端口，單獨的Cluster IP不具有通訊的基礎，而且他們屬於Kubernetes集羣這樣一個封閉的空間。
Kubernetes集羣以內，Node IP網、Pod IP網與Cluster IP網之間的通訊，採用的是Kubernetes本身設計的一種區別於常規的IP路由的編程方式的特殊路由規則。
3.9 Volume（存儲卷）
Volume是Pod中可以被多個容器訪問的共享目錄，Kubernetes中的Volume是定義在Pod上，能夠被一個或多個Pod中的容器掛載到某個目錄下。Kubernetes中的Volume與Pod的生命週期相同，與容器的生命週期並沒有直接關係。Kubernetes的Volume支持多種類型的後端驅動，如glusterfs、ceph。
Volume常見類型：
emptyDir：爲Pod分配到Node的時候建立。無需指定宿主機的目錄文件，爲Kubernetes自動分配的目錄。
場景：
臨時空間，用於某些應用程序運行時所需的臨時目錄，且無須永久保存；
長時間任務的中間過程CheckPoint的臨時保存目錄；
一個容器須要從另外一個容器中獲取數據的目錄（多容器共享目錄）。
hostPath：爲在Pod上掛載宿主機上的文件或目錄。
場景：
容器應用程序生產的日誌文件須要永久保存，可使用宿主機的高速文件系統進行存儲；
須要訪問宿主機的Docker內部數據結構的容器。可指定hostPath爲/var/lib/docker，使容器內部應用直接訪問Docker的文件系統；
提示：若不一樣Node上具備相同配置的Pod可能由於宿主機的目錄結構不一致從而致使訪問結構不一致。
NFS：NFS網絡文件系統；
iSCSI：iSCSI存儲設備；
flocker；
rbd：
glusterfs。
3.10 Namespace（命名空間）
Namespace用於實現多租戶的資源隔離，可將集羣內部的資源對象分配到不一樣的Namespace中，造成邏輯上的不一樣項目、小組或用戶組，便於不一樣的Namespace在共享使用整個集羣的資源的同時還能被分別管理。
提示：Kubernetes集羣在啓動後，會建立一個名爲「default」的Namespace，且默認狀況下Kubernetes的相關資源，如Pod、RC、Service都將被系統建立到此默認名爲default的Namespace中。
3.11 Annotation（註釋）
Annotation相似Label，也使用key/value形式進行定義。Annotation是用戶任意定義的「附加信息」，如電話號碼、負責人、網站等等。

四 Kubernetes 組件簡述
Kubernetes Master控制組件，調度管理整個系統（集羣），包含以下組件:
Kubernetes API Server
做爲Kubernetes系統的入口，其封裝了核心對象的增刪改查操做，以RESTful API接口方式提供給外部客戶和內部組件調用。維護的REST對象持久化到Etcd中存儲。
Kubernetes Scheduler
爲新創建的Pod進行節點(node)選擇(即分配機器)，負責集羣的資源調度。組件抽離，能夠方便替換成其餘調度器。
Kubernetes Controller
負責執行各類控制器，目前已經提供了不少控制器來保證Kubernetes的正常運行。
Replication Controller
管理維護Replication Controller，關聯Replication Controller和Pod，保證Replication Controller定義的副本數量與實際運行Pod數量一致。
Node Controller
管理維護Node，按期檢查Node的健康狀態，標識出(失效|未失效)的Node節點。
Namespace Controller
管理維護Namespace，按期清理無效的Namespace，包括Namesapce下的API對象，好比Pod、Service等。
Service Controller
管理維護Service，提供負載以及服務代理。
EndPoints Controller
管理維護Endpoints，關聯Service和Pod，建立Endpoints爲Service的後端，當Pod發生變化時，實時更新Endpoints。
Service Account Controller
管理維護Service Account，爲每一個Namespace建立默認的Service Account，同時爲Service Account建立Service Account Secret。
Persistent Volume Controller
管理維護Persistent Volume和Persistent Volume Claim，爲新的Persistent Volume Claim分配Persistent Volume進行綁定，爲釋放的Persistent Volume執行清理回收。
Daemon Set Controller
管理維護Daemon Set，負責建立Daemon Pod，保證指定的Node上正常的運行Daemon Pod。
Deployment Controller
管理維護Deployment，關聯Deployment和Replication Controller，保證運行指定數量的Pod。當Deployment更新時，控制實現Replication Controller和　Pod的更新。
Job Controller
管理維護Job，爲Jod建立一次性任務Pod，保證完成Job指定完成的任務數目
Pod Autoscaler Controller
實現Pod的自動伸縮，定時獲取監控數據，進行策略匹配，當知足條件時執行Pod的伸縮動做。