課程資源c新技術研討kubernetes

Kubernetes容器編排引擎云原生概述低耦合+高內聚開發(fā)和運維不再分離不影響用戶使用服務的前提下迭代每個服務都被無差別地封裝在容器里Docker、Kubernetes什么是Kubernetes？簡單說：是生產級別的容器編排引擎可以自動化的容器部署、擴展和管理從2000年以來，谷歌基于容器研發(fā)三個容器管理系統(tǒng)，分別是Borg、Omega和Kubernetes。Borg是谷歌嚴守十幾年的秘密武器，利用其管理數(shù)量龐大的應用集群Borg和Omega是谷歌內部工具，至今未開源，Kubernetes是開源的谷歌從Borg到Kubernetes逐步吸取經(jīng)驗進行改進，于2015年將Kubernetes開源什么是Kubernetes？首先，它是一個全新的基于容器技術的分布式架構領先方案。其次，Kubernetes提供強大的自動化機制，可以大大降低運維成本。然后，Kubernetes是一個開放的開發(fā)平臺，不限于任何一種語言，沒有接口限定，無論是 Java、C++、Go都可以映射為Kubernetes的Service。最后，Kubernetes是一個完備的分布式系統(tǒng)支撐平臺，具備完備的集群管理能力，包括服務注冊服務發(fā)現(xiàn)、負載均衡、故障修復、在線擴容等。Kubernetes主要優(yōu)點（1）隱藏資源管理和故障處理的細節(jié)，使其用戶可以專注于應用程序開發(fā)；(2）以非常高的可靠性和可用性運行，并支持應用程序做同樣的事情；（3）讓我們有效地在數(shù)萬臺機器上運行工作負載。博格不是第一個解決這些問題的系統(tǒng)，但它是少數(shù)幾個運行系統(tǒng)之一他的規(guī)模，有這種程度的彈性和完整性。（4）同時支持Docker和Rocket容器概述（Docker）在一個實際的大型系統(tǒng)中，微服務架構可能由成千上萬個服務組成，如果將每個服務都打包上傳并運行，工作量和系統(tǒng)資源占用無疑是巨大的。而且進行服務器伸縮的時候，都需要進行重復的部署或刪除操作。

容器技術的出現(xiàn)解決了這一問題，我們可以將服務打包成鏡像，放到容器中，通過容器來運行服務，這樣便于進行分布式管理，也方便進行水平擴展。

Docker是容器技術的佼佼者，是一個開源容器，而Kubernetes是一個分布式容器編排引擎，二者是天生的一對。基于Linux64bit網(wǎng)絡隔離：namespace資源隔離：cgroup虛擬化：輕量、containerizationDockerfileKubernetes基本概念和術語 Kubernetes大部分的概念如Node、Pod、ReplicationController、Service都可以看做一種“資源對象”。幾乎所有對象都可以通過Kubernetes提供的kubectl工具執(zhí)行增刪改查等操作并將其保存在etcd中持久化存儲。程調用)執(zhí)行增、刪、改、查等操作并將其保存在eted中持久化存儲。從這個角度來看,Kubermetes其實是一個高度自動化的資源控制系統(tǒng)，它通過跟蹤對比etcd庫里保存的“資源期望狀態(tài)”與當前環(huán)境中的“實際資源狀態(tài)”的差異來實現(xiàn)自動控制和自動糾錯的高級功能。Pod：最重要也是最基本的概念，一個Pod包含一個或多個緊密相關的用戶業(yè)務容器Label：標簽，資源分組管理ReplicationController：Pod的伸縮擴展（副本數(shù)量控制）Service：一項“微服務”Kubernetes基本概念和術語

Master：集群控制節(jié)點Node：除Master外的其他機器節(jié)點Deployment：部署動作Volume：存儲卷Namespace：命名空間Pod的生命周期和重啟策略Pod在整個生命周期過程中被系統(tǒng)定義為各種狀態(tài)，熟悉Pod的各種狀態(tài)對于我們理解如何設置Pod的調度策略、重啟策略是很有必要的。Pod的重啟策略包括Always、OnFailure和Never，默認值為Always。Always:當容器失效時，由kubelet自動重啟該容器。OnFailure:當容器終止運行且退出碼不為0時，由kubelet自動重啟該容器。Never:不論容器運行狀態(tài)如何,kubelet都不會重啟該容器。Pod的健康檢查（Kubelet）LivenessProbe探針

用于判斷容器是否存活(running狀態(tài))，如果LivenessProbe探針探測到容器不健康，則kubelet將殺掉該容器，并根據(jù)容器的重啟策略做相應的處理。如果一個容器不包含LivenessProbe探針，那么kubelet認為該容器的LivenessProbe探針返回的值永遠是“Success“。LivenessProbe探針的三種實現(xiàn)方式（1）ExecAction:在容器內部執(zhí)行一個命令，如果該命令的返回碼為0，則表明容器健康。（2）TCPSocketAction:通過容器的IP地址和端口號執(zhí)行TCP檢查，如果能夠建立TCP連接，則表明容器健康。（3）HTTPGetAction:通過容器的IP地址、端口號及路徑調用HTTPGet方法，如果響應的狀態(tài)碼大于等于200且小于等于400，則認為容器狀態(tài)健康。Pod的調度ReplicationController、Deployment：全自動調度 RC的主要功能之一就是自動部署一個容器應用的多份副本,以及持續(xù)監(jiān)控副本的數(shù)量,在集群內始終維持用戶指定的副本數(shù)量。Pod擴容縮容kubectlscalercXXX--replicas=3Pod滾動升級

滾動升級通過執(zhí)行kubectlrolling-update命令--鍵完成，該命令創(chuàng)建了一-個新的RC，然后自動控制舊的RC中的Pod副本的數(shù)量逐漸減少到0，同時新的RC中的Pod副本的數(shù)量從0逐步增加到目標值，最終實現(xiàn)了Pod的升級。Service Service是Kubernetes的核心概念，通過創(chuàng)建Service，可以為一組具有相同功能的容器應用提供一個統(tǒng)一的入口地址，并且將請求進行負載分發(fā)到后端的各個容器應用上。Kubernetes主要組件及原理分析Kubernetes主要組件概述APIServer：對Pod、RC等資源對象進行增、刪、改、查的RestAPI服務器ControllerManager：負責集群中資源對象管理同步的組件Scheduler：集群中資源對象的調度控制器Kubelet：負責維護Pod容器的生命周期Kube-proxy：負載均衡和代理服務Etcd：分布式鍵值對(k,v)存儲服務，存儲整個集群的狀態(tài)信息Kubernetes主要組件有APIServer、ControllerManager、Scheduler、kubelet、kube-proxy，其中前三者運行于集群的Master節(jié)點，后兩者運行于集群的Slave節(jié)點。還有一個用于存儲Kubernetes集群信息的Etcd，它是一個高可用、強一致性的服務發(fā)現(xiàn)存儲倉庫，基于raft協(xié)議。APIServer：增刪改查RestAPI服務器 APIServer是對以上Pod、Service、RC等資源對象進行增、刪、改、查的RestAPI服務器。通過kube-apiserver進程提供服務，該進程運行于Master節(jié)點上。APIServer是Kubernetes的核心組件，是各個組件通信的渠道，有如下特性：(1)是集群管理的API入口。(2)是資源配額控制的入口。(3)提供了完備的集群安全機制。集群管理的API入口

我們如果要創(chuàng)建一個資源對象如Pod、Service、RC、Deployment等，都是要通過APIServer的。當然，我們可能是通過命令行的kubectl命令將一個yaml/json格式的文件create進行創(chuàng)建，還可能是通過寫代碼的方式使用如client-go這樣的操作Kubernetes的第三方包來操作集群。總之，最終，都是通過APIServer對集群進行操作的。通過APIServer，我們就可以往Etcd中寫入數(shù)據(jù)。Etcd中存儲著集群的各種數(shù)據(jù)。APIServer保證集群功能模塊間的通信 APIserver作為集群的核心，負責各個功能模塊之間的通信。集群中各個模塊通過APIserver將信息存入etcd，當需要獲取和操作這些數(shù)據(jù)時，則通過APIserver提供的REST接口來實現(xiàn)，從而實現(xiàn)各模塊之間的信息交互。Kubelet與APIServer交互

每個Node節(jié)點上的kubelet定期就會調用APIServer的REST接口報告自身狀態(tài)，APIServer接收這些信息后，將節(jié)點狀態(tài)信息更新到etcd中。kubelet也通過APIServer的Watch接口監(jiān)聽Pod信息，從而對Node機器上的POD進行管理。ControllerManager與APIServer交互 NodeController模塊通過APIServer提供的Watch接口，實時監(jiān)控Node的信息，并做相應處理。Scheduler與APIServer交互

當前者通過server的watch接口監(jiān)聽到新建pod副本的信息后，它會檢索所有符合該pod要求的Node列表，開始執(zhí)行pod調度邏輯，調度成功后將pod綁定到目標節(jié)點上。ControllerManager：負責集群中資源對象管理同步ControllerManager作為集群內部的管理控制中心，負責集群內的Node、Pod副本、服務端點(Endpoint)、命名空間(Namespace)、服務賬號(ServiceAccount)、資源定額(ResourceQuota)等的管理，當某個Node意外宕機時，ControllerManager會及時發(fā)現(xiàn)此故障并執(zhí)行自動化修復流程，確保集群始終處于預期的工作狀態(tài)。如圖所示，ControllerManager內部包含ReplicationController、NodeController、ResourceQuotaController、NamespaceController、ServiceAccountController、TokenController、ServiceCotoller及EndpointController等多個Contoller，每種Contoller都負責一種具體的控制流程，而ControllerManager正是這些Controller的核心管理者。ControllerManager：負責集群中資源對象管理同步ReplicationController（副本控制器）

核心作用是確保在任何時候集群中一個RC所關聯(lián)的Pod副本數(shù)量保持預設值。如果發(fā)現(xiàn)Pod副本數(shù)量超過預期值,則ReplicationController會銷毀一些Pod副本；反之，ReplicationController會自動創(chuàng)建新的Pod副本，直到符合條件的Pod副本數(shù)量達到預設值。

使用場景：重新調度（即時發(fā)生意外也會保證特定數(shù)量）、彈性伸縮（動態(tài)的擴容縮容）、滾動更新（逐個替換輔助滾動更新）NodeController（節(jié)點控制器） kubelet進程在啟動時通過APIServer注冊自身的節(jié)點信息，并定時向APIServer匯報狀態(tài)信息，APIServer接收到這些信息后，將這些信息更新到etcd中，etcd中存儲的節(jié)點信息包括節(jié)點健康狀況、節(jié)點資源、節(jié)點名稱、節(jié)點地址信息、操作系統(tǒng)版本、Docker版本、kubelet版本等。節(jié)點健康狀況包含“就緒”(True)“未就緒”(False)和“未知”(Unknown)三種。 NodeController通過APIServer實時獲取Node的相關信息，實現(xiàn)管理和監(jiān)控集群中的各個Node節(jié)點的相關控制功能，NodeController的核心工作流程如圖所示。ControllerManager：負責集群中資源對象管理同步Scheduler：集群中資源對象的調度控制器 KubernetesScheduler在整個系統(tǒng)中承擔了“承上啟下”的重要功能，“承上”是指它負責接收ContollerManager創(chuàng)建的新Pod，為其安排-一個落腳的“家”一目標Node；“啟下”是指安置工作完成后，目標Node上的kubelet服務進程接管后繼工作，負責Pod生命周期中的“下半生”。在整個調度過程中涉及三個對象，分別是：待調度Pod列表、可用Node列表，以及調度算法和策略。簡單地說，就是通過調度算法調度為待調度Pod列表的每個Pod從Node列表中選擇一個最適合的Node。流程：0.通過apiserver來進行主節(jié)點選舉，成功者進行調度業(yè)務流程處理1.通過apiserver感知集群的資源數(shù)據(jù)和pod數(shù)據(jù)，更新本地schedulerCache2.通過apiserver感知用戶或者controller的pod調度請求，加入本地調度隊列SchedulingQueue3.通過調度算法來進行pod請求的調度，分配合適的node節(jié)點，此過程可能會發(fā)生搶占調度4.將調度結果返回給apiserver,然后由kubelet組件進行后續(xù)pod的請求處理Scheduler之預選算法和優(yōu)選算法KubernetesScheduler當前提供的默認調度流程分為以下兩步。(1)預選調度過程，即遍歷所有目標Node,篩選出符合要求的候選節(jié)點。為此，Kubernetes內置了多種預選策略(xxxPredicates)供用戶選擇。(2)確定最優(yōu)節(jié)點，在第1步的基礎上，采用優(yōu)選策略(xxxPriority)計算出每個候選節(jié)點的積分，積分最高者勝出。預選調度NoDiskConflict：判斷備選Pod的GCEPersistentDisk和備選節(jié)點已存在的Pod是否沖突PodFitsResources：判斷備選節(jié)點的資源是否滿足備選Pod的需求,PodSelectorMatches：判斷備選節(jié)點是否包含備選Pod的標簽選擇器指定的標簽。PodFitsHost：判斷備選Pod的spec.nodeName域指定的節(jié)點名稱和備選節(jié)點名稱是否一致,PodFitsPorts：判斷備選Pod所用的端口列表中的端口是否在備選節(jié)點中已被占用優(yōu)選調度LeastRequestedPriority：該優(yōu)選策略用于從備選節(jié)點列表中選出資源消耗最小的節(jié)點CalculateNodeLabelPriority：判斷策略列出的標簽在備選節(jié)點中是否存在，存在+10分BalancedResourceAllocation：該優(yōu)選策略用于從備選節(jié)點列表中選出各項資源使用率最均衡的節(jié)點。Kubelet運行機制分析

在Kubernetes集群中，在每個Node節(jié)點(又稱Minion)上都會啟動一個kubelet服務進程。該進程用于處理Master節(jié)點下發(fā)到本節(jié)點的任務，管理Pod及Pod中的容器。每個kubelet進程會在APIServer.上注冊節(jié)點自身信息，定期向Master節(jié)點匯報節(jié)點資源的使用情況，并通過cAdvisor監(jiān)控容器和節(jié)點資源。節(jié)點管理kubelet在啟動時通過APIServer注冊節(jié)點信息，并定時向APIServer發(fā)送節(jié)點的新消息，APIServer在接收到這些信息后，將這些信息寫入etcd。Pod管理kubelet監(jiān)聽etcd所有針對Pod的操作將會被kubelet監(jiān)聽到。如果發(fā)現(xiàn)有新的綁定到本節(jié)點的Pod，則按照Pod清單的要求創(chuàng)建該Pod。如果發(fā)現(xiàn)本地的Pod被修改，則kubelet會做出相應的修改，比如刪除Pod中的某個容器時，則通過DockerClient刪除該容器。容器健康檢查cAdvisor資源監(jiān)控

監(jiān)控的對象包括容器、Pod、Service和整個集群。通過暴露RESTAPI暴露這些資源的使用情況的。cAdvisor被集成到Kubernetes代碼中，可以自動查找所有在其所在節(jié)點上的容器，自動采集CPU、內存、文件系統(tǒng)和網(wǎng)絡使用的統(tǒng)計信息，并全面分析該節(jié)點機的使用情況。Pod的健康檢查（Kubelet）LivenessProbe探針

用于判斷容器是否存活(running狀態(tài))，如果LivenessProbe探針探測到容器不健康，則kubelet將殺掉該容器，并根據(jù)容器的重啟策略做相應的處理。如果一個容器不包含LivenessProbe探針，那么kubelet認為該容器的LivenessProbe探針返回的值永遠是“Success“。LivenessProbe探針的三種實現(xiàn)方式（1）ExecAction:在容器內部執(zhí)行一個命令，如果該命令的返回碼為0，則表明容器健康。（2）TCPSocketAction:通過容器的IP地址和端口號執(zhí)行TCP檢查，如果能夠建立TCP連接，則表明容器健康。（3）HTTPGetAction:通過容器的IP地址、端口號及路徑調用HTTPGet方法，如果響應的狀態(tài)碼大于等于200且小于等于400，則認為容器狀態(tài)健康。Kube-proxy運行機制分析前面提到，Service是對一組Pod的抽象，它會根據(jù)訪問策略（如負載均衡策略）來訪問這組Pod。Kubernetes在創(chuàng)建服務時會為服務分配一個虛擬的IP地址，客戶端通過訪問這個虛擬的IP地址來訪問服務，而服務則負責將請求轉發(fā)到后端的Pod上。這就類似于一個反向代理。

而Kubelet-proxy正是這樣一個透明代理兼負載均衡器。Kube-proxy運行機制分析Kube-proxy通過查詢和監(jiān)聽APIServer中Service與Endpoints的變化，為每個Service都建立了一個“服務代理對象”，并自動同步。服務代理對象是kube-proxy程序內部的一種數(shù)據(jù)結構，它包括一個用于監(jiān)聽此服務請求的SocketServer,，SocketServer的端口是隨機選擇的一個本地空閑端口。此外，kubeproxy內部也創(chuàng)建了一個負載均衡器——LoadBalancer，LoadBalancer上保存Service到對應的后端Endpoint列表的動態(tài)轉發(fā)路由表，而具體的路由選擇則取決于RoundRobin負載均衡算法及Service的Session會話保持(SessionAffinity)這兩個特性。透明代理訪問Service的請求，不論是用ClusterIP+TargetPort的方式，還是用節(jié)點機IP+NodePort的方式，都被節(jié)點機的Iptables規(guī)則重定向到kube-proxy監(jiān)聽Service服務代理端口。負載均衡——LoadBalancer

Kube-proxy接收到service的請求后，如何選擇后端的Pod呢？

目前kubeproxy的負載均衡器只支持RoundRobin算法。RoundRobin算法按照成員列表逐個選取成員，如果一輪循環(huán)完，便從頭開始下一輪，如此循環(huán)往復。Kubernetes網(wǎng)絡原理Kubernetes網(wǎng)絡模型設計基礎原則：每個Pod都擁有一個獨立的IP地址，而且假定所有Pod都在一個可以直接連通的、扁平的網(wǎng)絡空間中。所以不管它們是否運行在同一個Node(宿主機)中，都要求它們可以直接通過對方的IP進行訪問。設計這個原則的原因是，用戶不需要額外考慮如何建立Pod之間的連接，也不需要考慮將容器端口映射到主機端口等問題。容器到容器的通信在同一個Pod內的容器(Pod內的容器是不會跨宿主機的)共享同一個網(wǎng)絡命名空間，共享同一個Linux協(xié)議棧。所以對于網(wǎng)絡的各類操作，就和它們在同一臺機器上一樣，它們甚至可以localhost地址訪問彼此的端口。Kubernetes網(wǎng)絡原理同一Node上Pod間的通信通過網(wǎng)橋把veth0和veth1組成為一個以太網(wǎng)，它們直接是可以直接通信的，另外這里通過veth對讓Pod1的eth0和veth0、Pod2的eth0和veth1關聯(lián)起來，從而讓Pod1和Pod2相互通信；Pod1通過自己默認的以太網(wǎng)設備eth0發(fā)送一個數(shù)據(jù)包，eth0把數(shù)據(jù)傳遞給veth0，數(shù)據(jù)包到達網(wǎng)橋后，網(wǎng)橋通過轉發(fā)表把數(shù)據(jù)傳遞給veth1，然后虛擬設備veth1直接把包傳遞給Pod2網(wǎng)絡命名空間中的虛擬設備eth0。Kubernetes網(wǎng)絡原理不同Node上Pod間的通信首先Po