Kubernetes （一）K8S入門
Kubernetes是什麼
Kubernetes的初識
1. K8S是一個全新的基於容器技術的分散式架構領先方案，用於管理雲平臺中多個主機上的容器化的應用。Kubernetes的目標是讓部署容器化的應用簡單並且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制，能夠自主管理容器來保證雲平臺中的容器按照使用者期望的狀態執行。
例如：比如使用者想讓apache一直執行，使用者不需要關心怎麼去做，Kubernetes會自動去監控，然後去重啟，新建，總之，讓apache一直提供服務.
2. K8S是一個開放的開發平臺，它不侷限於任何一種語言，沒有限定任何程式設計介面，所以無論是JAVA,Go,Python還是C++編寫的服務，都可以毫無困難地對映為Kubernetes的Service,並通過標準的TCP通訊協議進行互動.
3. K8S是一個完備的分散式系統支撐平臺，具有完備的叢集管理能力，包括多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和服務發現機制、內建智慧負載均衡，強大的故障發現和自我修復能力、以及多粒度的資源配額管理能力。
Kubernetes的特點
1、故障遷移：當某一個node節點關機或掛掉後，node節點上的服務會自動轉移到另一個node節點上，這個過程所有服務不中斷。這是docker或普通雲主機是不能做到的
2、資源排程：當node節點上的cpu、記憶體不夠用的時候，可以擴充node節點，新建的pod就會被kube-schedule排程到新擴充的node節點上
3、資源隔離：建立開發、運維、測試三個名稱空間，切換上下文後，開發人員就只能看到開發名稱空間的所有pod，看不到運維名稱空間的pod，這樣就不會造成影響，互不干擾
傳統的主機或只有docker環境中，登入進去就會看到所有的服務或者容器
4、因為採用docker容器，程序之間互不影響，
5、安全：不同角色有不同的許可權，檢視pod、刪除pod等操作；RBAC認證增加了k8s的安全
6、快速精準地部署應用程式
7、限制硬體用量僅為所需資源
為什麼要用Kubernetes
轉載至：https://www.jianshu.com/p/0d1dbd24d635
1.k8s可以更快的更新新版本：打包應用，更新的時候可以做到不用中斷服務，伺服器故障不用停機，從開發環境到測試環境到生產環境的遷移極其方便，一個配置檔案搞定，一次生成image，到處執行。。。
2. 一個平臺搞定所有
3. 雲環境無縫遷移： 如果你有換雲的需求，例如從GCP到AWS，使用K8SD的話，你就不用有任何擔心，K8S完全相容各種雲服務提供商，例如 Google Cloud、Amazon、Microsoft Azure，還可以工作在 CloudStack, OpenStack, OVirt, Photon, VSphere。
4. 高效的利用資源：Kubernetes 如果發現有節點工作不飽和，便會重新分配 pod，幫助我們節省開銷，高效的利用記憶體、處理器等資源。如果一個節點宕機了，Kubernetes 會自動重新建立之前執行在此節點上的 pod，在其他節點上執行。如下圖：
左邊，是4個虛擬機器，黃色和藍色部分是執行的應用，白色部分是未使用的記憶體和處理器資源。
右邊，同樣的應用打包執行在容器中。
5. 開箱即用的自動縮放能力：網路、負載均衡、複製等特性，對於 Kubernetes 都是開箱即用的。pod 是無狀態執行的，任何時候有 pod 宕了，立馬會有其他 pod 接替它的工作，使用者完全感覺不到。如果使用者量突然暴增，現有的 pod 規模不足了，那麼會自動創建出一批新的 pod，以適應當前的需求。反之亦然，當負載降下來的時候，Kubernetes 也會自動縮減 pod 的數量。
6. 使用CI/CD更加簡單：你不必精通於 Chef 和 Ansible 這類工具，只需要對 CI 服務寫個簡單的指令碼然後執行它，就會使用你的程式碼建立一個新的 pod，並部署到 Kubernetes 叢集裡面。應用打包在容器中使其可以安全的執行在任何地方，例如你的 PC、一個雲伺服器，使得測試極其簡單。
7. 可靠性：Kubernetes 如此流行的一個重要原因是：應用會一直順利執行，不會被 pod 或 節點的故障所中斷。如果出現故障，Kubernetes 會建立必要數量的應用映象，並分配到健康的 pod 或節點中，直到系統恢復。而且使用者不會感到任何不適。一個容器化的基礎設施是有自愈能力的，可以提供應用程式的不間斷操作，即使一部分基礎設施出現故障。
總之：Kubernetes 使得應用的啟動、遷移、部署變得即簡單又安全。不必擔心應用遷移後工作出現問題，也不用擔心一臺伺服器無法應付突發的使用者量。需要注意的是，你的應用最好使用微服務架構進行開發，因為微服務應用比單體應用更適合做容器化。
Kubernetes的基本概念和術語
Kubernetes使用共享網路將多個物理機或虛擬機器彙集到一個叢集中，在各伺服器之間進行通訊，該叢集是配置Kubernetes的所有元件、功能和工作負載的物理平臺。叢集中一臺伺服器（或高可用部署中的一組伺服器）用作Master，負責管理整個叢集，餘下的其他機器用作Worker Node,它們是使用本地和外部資源接收和執行工作負載的伺服器。叢集中的這些主機可以是物理伺服器，也可以是虛擬機器（包括IaaS雲端的VPS）
Master
Master指的是叢集的控制節點，是叢集的閘道器和中樞，負責諸如為使用者和客戶端暴露API、跟蹤其它伺服器的健康狀態、以最優方式排程工作負載，以及編排其他元件之間的通訊等任務，它是使用者或客戶端與叢集之間的核心聯絡點，基本上K8S所有的控制命令都是發給它，它來複制具體的執行過程，並負責Kubernetes系統的大多數集中式管控邏輯。單個Master節點即可完成其所有的功能，但出於冗餘及負載均衡等目的，生產環境中通常需要協同部署多個此類主機。Master節點類似於蜂群中的蜂王。如下圖：
Kubernetes的叢集控制平面由多個元件組成，這些元件可統一運行於單一Master節點，也可以以多副本的方式同時運行於多個節點，以為Master提供高可用功能，甚至還可以運行於Kubernetes叢集自身之上。Master主要包括以下幾個元件。
API Server
Api Server負責輸出RESTful風格的Kubernetes API，它是發往叢集的所有REST操作命令的接入點，並負責接收、校驗並響應所有的REST請求，結果狀態被持久儲存於etcd中。因此，API Server是整個叢集的閘道器。
ETCD
Kubernetes叢集的所有狀態資訊都需要持久儲存於儲存系統etcd中，不過，etcd是由CoreOS基於Raft協議開發的分散式鍵值儲存，可用於服務發現、共享配置以及一致性保障（例如資料庫主節點選擇、分散式鎖等）。因此，etcd是獨立的服務元件，並不隸屬於Kubernetes叢集自身。生產環境中應該以etcd叢集的方式執行以確保其服務可用性。
Controller Manager
Kubernetes中，叢集級別的大多數功能都是由幾個被稱為控制器的程序執行實現的，這幾個程序被整合與kube-controller-manager守護程序中。由控制器完成的功能主要包括生命週期功能和API業務邏輯，具體如下
-
生命週期功能：包括Namespace建立和生命週期、Event垃圾回收、Pod終止相關的垃圾回收、級聯垃圾回收及Node垃圾回收等。
-
API業務邏輯：例如，由ReplicaSet執行的Pod擴充套件等。
Scheduler
Kubernetes是用於部署和管理大規模容器應用的平臺，根據叢集規模的不同，其託管執行的容器很可能會數以千計甚至更多。API Server確認Pod物件的建立請求之後，便需要由Scheduler根據叢集內各節點的可用資源狀態，以及要執行的容器的資源需求做出排程決策，如下圖所示。另外，Kubernetes還支援使用者自定義排程器。
Node
Node是Kubernetes叢集的工作節點，負責接收來自Master的工作指令並根據指令相應的建立或刪除Pod物件，以及調整網路規則以合理地路由和轉發流量等。理論上講，Node可以是任何形式的計算裝置無論是物理機還是虛擬機器，在K8S中Master會統一將其抽象為Node物件進行管理。Node類似於蜂群中的工蜂，生產環境中，它們通常數量眾多。
Kubernetes將所有Node的資源集結於一處形成一臺更強大的“伺服器”，如下圖，在使用者將應用部署於其上時，Master會使用排程演算法將其自動指派某個特定的Node執行，在Node加入叢集或從叢集中移除時，又或者當某個Node宕機時，Master也會按需重行編排影響到的Pod（容器）至新的Node裡面。於是，使用者無需關心其應用究竟運行於何處，不用擔心某個Node宕機了，影響應用的執行，除非你只有一個Node節點，在生產環境這是不現實的。
從抽象的角度來講，Kubernetes還有著眾多的元件來支撐其內部的業務邏輯，包括執行應用、應用編排、服務暴露、應用恢復等，它們在Kubernetes中被抽象為Pod、Service、Controller等資源型別。
Node負責提供執行容器的各種依賴環境，並接收Master的管理。每個Node主要由以下幾個元件構成。
kubelet
kubelet是運行於工作節點之上的守護程序，它從API Server接收關於Pod物件的配置資訊並確保它們處於期望的狀態（desired state，也可以說目標狀態）kubelet會在API Server上註冊當前工作節點，定期向Master彙報節點資源使用情況，並通過cAdvisor監控容器和節點的資源佔用情況。
kube-proxy
每個工作節點都需要執行一個kube-proxy守護程序，它能夠按需為Service資源物件生成iptables或ipvs規則，從而捕獲訪問當前Service的ClusterIP的流量並將其轉發至正確的後端Pod物件。
docker
docker用於執行容器
Pod
Kubernetes並不直接執行容器，而是使用一個抽象的資源物件來封裝一個或者多個容器，這個抽象即為Pod，它是Kubernetes的最小排程單元。同一Pod中的容器共享網路名稱空間和儲存資源，這些容器可經由本地迴環介面lo直接通訊，但彼此之間又在Mount、User及PID等名稱空間上保持了隔離。儘管Pod中可以包含多個容器，但是作為最小排程單元，它應該儘可能地保持“小”，即通常只應該包含一個主容器，以及必要的輔助型容器（Pause）。通常情況下一個Node可以有一個或多個Pod，這取決於業務的架構。
Label
標籤（Label）是將資源進行分類的識別符號, Label以key/value鍵值對的形式附加到任何物件上，如Pod，Service，Node，RC（ReplicationController）/RS（ReplicaSet）等。Label可以在建立物件時就附加到物件上，也可以在物件建立後通過API進行額外新增或修改。標籤旨在指定物件（如Pod等）辨識性的屬性，這些屬性僅對使用者存在特定的意義，對Kubernetes叢集來說並不直接表達核心系統語意.一個物件可以有多個標籤,一個標籤也可以附加到多個物件上.Selector
Selector即標籤選擇器,全名"Label Selector",他是一種根據Label來過濾複合條件的資源物件的機制,類似與CSS的標籤選擇器.例如,將附有標籤”role：backend“的所有Pod物件挑選出來歸為一組就是標籤選擇器的一種應用，如下圖所示，通常使用標籤對資源物件進行分類，而後使用標籤選擇器挑選出它們，例如將其建立未某Service的端點。
Pod控制器
儘管Pod是kubernetes的最小排程單元.生產中,很少會跑一個自主式pod,一般由控制器去建立pod,其配置檔案中內嵌了pod的建立方式.——控制器（Controller）對其進行管理。用於工作負載的控制器是一種管理Pod生命週期的資源抽象，它們是kubernetes上的一類物件，而非單個資源物件，包括ReplicationController，ReplicaSet、Deployment、StatefulSet、Job等。已下圖所示的Deployment控制器為例，它負責確保指定的Pod物件的副本數量精確符合定義，否則“多退少補”。使用控制器之後就不再需要手動管理Pod物件了，只需要宣告應用的期望狀態，控制器就會自動對其進行程序管理。
ReplicaSet
代使用者建立指定數量的pod副本數量,確保pod副本數量符合預期狀態,並且支援滾動式自動擴容和縮容功能.
組成:
a.使用者期望的pod副本數量;
b.標籤選擇器,判斷哪個pod歸自己管理;
c.pod資源模板,當現存的pod數量不足,會根據pod資源模板進行新建.
注意: 幫助使用者管理無狀態的pod資源,精確反應使用者定義的目標數量,但RelicaSet不是直接使用的控制器,而是使用Deployment;
Deployment
工作在ReplicaSet之上,用於管理無狀態應用,目前來說最好的控制器.支援滾動更新和回滾功能,還提供宣告式配置;
DaemonSet
用於確保叢集中的每一個節點只執行特定的pod副本,通常用於實現系統級後臺任務,比如ELK中負責收集日誌filebeat,特性:服務是無狀態的,服務必須是守護程序;
Job
只要完成就立即退出,不需要重啟或重建;
Cronjob
週期性任務控制,不需要持續後臺執行;
StatefulSet
管理有狀態應用.
Serveice(服務)
Service是建立在一組Pod物件之上的資源抽象，它通過標籤選擇器選定一組Pod物件，併為這組Pod物件定義一個統一的固定訪問入口（通常是一個IP地址），若Kubernetes叢集存在DNS附件，它就會在Service建立時為其自動配置一個DNS名稱以便客戶端進行服務發現。到達Service IP的請求將被負載均衡至其後的端點——各個Pod物件之上，因此Service從本質上來講是一個四層代理服務。另外，service還可以將叢集外部流量引入到叢集中來。
Volume(儲存卷)
儲存卷（Volume）是獨立於容器檔案系統之外的儲存空間，常用於擴充套件容器的儲存空間併為它提供持久儲存能力。Kubernetes叢集上的儲存卷大體可以分為臨時卷、本地卷和網路卷。臨時卷和本地卷都位於Node本地，一旦Pod被排程至其他Node，此種類型的儲存卷將無法訪問到，因此臨時卷和本地卷通常用於資料快取，持久化的資料則需要放置於持久卷（persistent volume）之上。
Name和Namespace
名稱（Name）是Kubernetes叢集中資源物件的識別符號，它們的作用域通常是名稱空間（Namespace），因此名稱空間是名稱的額外的限定機制。在同一名稱空間中，同一型別資源物件的名稱必須具有唯一性。名稱空間通常用於實現租戶或專案的資源隔離，從而形成邏輯分組，如下圖所示，建立的Pod和Service等資源物件都屬於名稱空間級別，未指定時，他們都屬於預設的名稱空間“default”。
Annotation
Annotation（註釋）是另一種附加在物件之上的鍵值型別的資料，但它擁有更大的資料容量。Annotation常用於將各種非標識型元資料（metadata）附加到物件上，但它不能用於標識和選擇物件，通常也不會被Kubernetes直接使用，其主要目的是方便工具或使用者的閱讀和查詢等。
Ingress
Kubernetes將Pod物件和外部網路環境進行了隔離，Pod和Service等物件間的通訊都使用其內部專用地址進行，如若需要開放某些Pod物件提供給外部使用者訪問，則需要為其請求流量開啟一個通往Kubernetes叢集內部的通道，除了Service之外，Ingress也是這類通道的實現方式之一。
Horizontal Pod Autoscaler(HPA)
是kubernetes（以下簡稱k8s）的一種資源物件，能夠根據某些指標對在statefulSet、replicaController、replicaSet等集合中的pod數量進行動態伸縮，使執行在上面的服務對指標的變化有一定的自適應能力。
HPA目前支援四種類型的指標，分別是Resource、Object、External、Pods。其中在穩定版本autoscaling/v1中只支援對CPU指標的動態伸縮，在測試版本autoscaling/v2beta2中支援memory和自定義指標的動態伸縮，並以annotation的方式工作在autoscaling/v1版本中。
K8S核心附件
Kubernetes叢集還依賴於一組稱為"附件"(add-ons)的元件以提供完整的功能，它們通常是由第三方提供的特定應用程式，且託管運行於Kubernetes叢集之上，如上圖所示。
KubeDNS
在Kubernetes叢集中排程執行提供DNS服務的Pod，同一叢集中的其他pod可使用此DNS服務解決主機名。Kubernetes從1.11版本開始預設使用CoreDNS專案為叢集提供服務註冊和服務發現的動態名稱解析服務，之前的版本中用到的是kube-dns專案，而SKyDNS則是更早一代的專案。
Kubernetes Dashboard
Kubernetes叢集的全部功能都要基於Web的UI，來管理叢集中應用甚至是叢集自身。
Heapster
容器和節點的效能監控與分析系統，它收集並解析多種指標資料，如資源利用率、生命週期事件等。新版本的Kubernetes中，其功能會逐漸由Prometheus結合其他元件所取代。
Ingress Controller
Service是一種工作於傳輸層的負載均衡器，而Ingress是在應用層實現的HTTP(s)負載均衡機制。不過，Ingress資源自身不能進行“流量穿透”，它僅是一組路由規則的集合，這些規則需要通過Ingress控制器（Ingress Controller）發揮作用。目前，此類的可用專案有Nginx、Traefik、Envoy及HAProxy等。