K8S學習記錄1——概念篇

Kubernetes簡述

Kubernetes是一個開源的,用於管理雲平臺中多個主機上的容器化的應用,Kubernetes的目標是讓部署容器化的應用簡單並且高效(powerful),Kubernetes提供了應用部署,規劃,更新,維護的一種機制。

Kubernetes一個核心的特點就是能夠自主的管理容器來保證雲平臺中的容器按照用戶的期望狀態運行着(比如用戶想讓apache一直運行,用戶不需要關心怎麼去做,Kubernetes會自動去監控,然後去重啓,新建,總之,讓apache一直提供服務),管理員可以加載一個微型服務,讓規劃器來找到合適的位置,同時,Kubernetes也系統提升工具以及人性化方面,讓用戶能夠方便的部署自己的應用(就像canary deployments)。

現在Kubernetes着重於不間斷的服務狀態(比如web服務器或者緩存服務器)和原生雲平臺應用(Nosql),在不久的將來會支持各種生產雲平臺中的各種服務,例如,分批,工作流,以及傳統數據庫。

在Kubenetes中,所有的容器均在Pod中運行,一個Pod可以承載一個或者多個相關的容器,在後邊的案例中,同一個Pod中的容器會部署在同一個物理機器上並且能夠共享資源。一個Pod也可以包含O個或者多個磁盤卷組(volumes),這些卷組將會以目錄的形式提供給一個容器,或者被所有Pod中的容器共享,對於用戶創建的每個Pod,系統會自動選擇那個健康並且有足夠容量的機器,然後創建類似容器的容器,當容器創建失敗的時候,容器會被node agent自動的重啓,這個node agent叫kubelet,但是,如果是Pod失敗或者機器,它不會自動的轉移並且啓動,除非用戶定義了 replication controller。

用戶可以自己創建並管理Pod,Kubernetes將這些操作簡化爲兩個操作:基於相同的Pod配置文件部署多個Pod複製品;創建可替代的Pod當一個Pod掛了或者機器掛了的時候。而Kubernetes API中負責來重新啓動,遷移等行爲的部分叫做“replication controller”,它根據一個模板生成了一個Pod,然後系統就根據用戶的需求創建了許多冗餘,這些冗餘的Pod組成了一個整個應用,或者服務,或者服務中的一層。一旦一個Pod被創建,系統就會不停的監控Pod的健康情況以及Pod所在主機的健康情況,如果這個Pod因爲軟件原因掛掉了或者所在的機器掛掉了,replication controller 會自動在一個健康的機器上創建一個一摸一樣的Pod,來維持原來的Pod冗餘狀態不變,一個應用的多個Pod可以共享一個機器。

我們經常需要選中一組Pod,例如,我們要限制一組Pod的某些操作,或者查詢某組Pod的狀態,作爲Kubernetes的基本機制,用戶可以給Kubernetes Api中的任何對象貼上一組 key:value的標籤,然後,我們就可以通過標籤來選擇一組相關的Kubernetes Api 對象,然後去執行一些特定的操作,每個資源額外擁有一組(很多) keys 和 values,然後外部的工具可以使用這些keys和vlues值進行對象的檢索,這些Map叫做annotations(註釋)。

Kubernetes支持一種特殊的網絡模型,Kubernetes創建了一個地址空間,並且不動態的分配端口,它可以允許用戶選擇任何想使用的端口,爲了實現這個功能,它爲每個Pod分配IP地址。

現代互聯網應用一般都會包含多層服務構成,比如web前臺空間與用來存儲鍵值對的內存服務器以及對應的存儲服務,爲了更好的服務於這樣的架構,Kubernetes提供了服務的抽象,並提供了固定的IP地址和DNS名稱,而這些與一系列Pod進行動態關聯,這些都通過之前提到的標籤進行關聯,所以我們可以關聯任何我們想關聯的Pod,當一個Pod中的容器訪問這個地址的時候,這個請求會被轉發到本地代理(kube proxy),每臺機器上均有一個本地代理,然後被轉發到相應的後端容器。Kubernetes通過一種輪訓機制選擇相應的後端容器,這些動態的Pod被替換的時候,Kube proxy時刻追蹤着,所以,服務的 IP地址(dns名稱),從來不變。

所有Kubernetes中的資源,比如Pod,都通過一個叫URI的東西來區分,這個URI有一個UID,URI的重要組成部分是:對象的類型(比如pod),對象的名字,對象的命名空間,對於特殊的對象類型,在同一個命名空間內,所有的名字都是不同的,在對象只提供名稱,不提供命名空間的情況下,這種情況是假定是默認的命名空間。UID是時間和空間上的唯一。

Kubernetes的核心概念

1.Master

  k8s集羣的管理節點,負責管理集羣,提供集羣的資源數據訪問入口。擁有Etcd存儲服務(可選),運行Api Server進程,Controller Manager服務進程及Scheduler服務進程,關聯工作節點Node。Kubernetes API server提供HTTP Rest接口的關鍵服務進程,是Kubernetes裏所有資源的增、刪、改、查等操作的唯一入口。也是集羣控制的入口進程;Kubernetes Controller Manager是Kubernetes所有資源對象的自動化控制中心;Kubernetes Schedule是負責資源調度(Pod調度)的進程

2.Node

  Node是Kubernetes集羣架構中運行Pod的服務節點(亦叫agent或minion)。Node是Kubernetes集羣操作的單元,用來承載被分配Pod的運行,是Pod運行的宿主機。關聯Master管理節點,擁有名稱和IP、系統資源信息。運行docker eninge服務,守護進程kunelet及負載均衡器kube-proxy.

  • 每個Node節點都運行着以下一組關鍵進程
  • kubelet:負責對Pod對於的容器的創建、啓停等任務
  • kube-proxy:實現Kubernetes Service的通信與負載均衡機制的重要組件
  • Docker Engine(Docker):Docker引擎,負責本機容器的創建和管理工作

  Node節點可以在運行期間動態增加到Kubernetes集羣中,默認情況下,kubelet會想master註冊自己,這也是Kubernetes推薦的Node管理方式,kubelet進程會定時向Master彙報自身情報,如操作系統、Docker版本、CPU和內存,以及有哪些Pod在運行等等,這樣Master可以獲知每個Node節點的資源使用情況,冰實現高效均衡的資源調度策略。

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重新調度到其他節點上。

4.Replication Controller

  Replication Controller用來管理Pod的副本,保證集羣中存在指定數量的Pod副本。集羣中副本的數量大於指定數量,則會停止指定數量之外的多餘容器數量,反之,則會啓動少於指定數量個數的容器,保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。

5.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僅僅作用於Kubernetes Service這個對象,並由Kubernetes管理和分配P地址
  • Cluster IP無法被ping,他沒有一個“實體網絡對象”來響應
  • Cluster IP只能結合Service Port組成一個具體的通信端口,單獨的Cluster IP不具備通信的基礎,並且他們屬於Kubernetes集羣這樣一個封閉的空間。

Kubernetes集羣之內,Node IP網、Pod IP網於Cluster IP網之間的通信,採用的是Kubernetes自己設計的一種編程方式的特殊路由規則。

6.Label

 Kubernetes中的任意API對象都是通過Label進行標識,Label的實質是一系列的Key/Value鍵值對,其中key於value由用戶自己指定。Label可以附加在各種資源對象上,如Node、Pod、Service、RC等,一個資源對象可以定義任意數量的Label,同一個Label也可以被添加到任意數量的資源對象上去。Label是Replication Controller和Service運行的基礎,二者通過Label來進行關聯Node上運行的Pod。

我們可以通過給指定的資源對象捆綁一個或者多個不同的Label來實現多維度的資源分組管理功能,以便於靈活、方便的進行資源分配、調度、配置等管理工作。

一些常用的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 Selector在Kubernetes中重要使用場景如下:

    •   kube-Controller進程通過資源對象RC上定義Label Selector來篩選要監控的Pod副本的數量,從而實現副本數量始終符合預期設定的全自動控制流程
    •   kube-proxy進程通過Service的Label Selector來選擇對應的Pod,自動建立起每個Service島對應Pod的請求轉發路由表,從而實現Service的智能負載均衡
    •   通過對某些Node定義特定的Label,並且在Pod定義文件中使用Nodeselector這種標籤調度策略,kuber-scheduler進程可以實現Pod”定向調度“的特性

 

Kubernetes架構和組件

Kubernetes 組件:

  Kubernetes Master控制組件,調度管理整個系統(集羣),包含如下組件:

  1.Kubernetes API Server

    作爲Kubernetes系統的入口,其封裝了核心對象的增刪改查操作,以RESTful API接口方式提供給外部客戶和內部組件調用。維護的REST對象持久化到Etcd中存儲。

  2.Kubernetes Scheduler

    爲新建立的Pod進行節點(node)選擇(即分配機器),負責集羣的資源調度。組件抽離,可以方便替換成其他調度器。

  3.Kubernetes Controller

    負責執行各種控制器,目前已經提供了很多控制器來保證Kubernetes的正常運行。

  4. Replication Controller

    管理維護Replication Controller,關聯Replication Controller和Pod,保證Replication Controller定義的副本數量與實際運行Pod數量一致。

  5. Node Controller

    管理維護Node,定期檢查Node的健康狀態,標識出(失效|未失效)的Node節點。

  6. Namespace Controller

    管理維護Namespace,定期清理無效的Namespace,包括Namesapce下的API對象,比如Pod、Service等。

  7. Service Controller

    管理維護Service,提供負載以及服務代理。

  8.EndPoints Controller

    管理維護Endpoints,關聯Service和Pod,創建Endpoints爲Service的後端,當Pod發生變化時,實時更新Endpoints。

  9. Service Account Controller

    管理維護Service Account,爲每個Namespace創建默認的Service Account,同時爲Service Account創建Service Account Secret。

  10. Persistent Volume Controller

    管理維護Persistent Volume和Persistent Volume Claim,爲新的Persistent Volume Claim分配Persistent Volume進行綁定,爲釋放的Persistent Volume執行清理回收。

  11. Daemon Set Controller

    管理維護Daemon Set,負責創建Daemon Pod,保證指定的Node上正常的運行Daemon Pod。

  12. Deployment Controller

    管理維護Deployment,關聯Deployment和Replication Controller,保證運行指定數量的Pod。當Deployment更新時,控制實現Replication Controller和 Pod的更新。

  13.Job Controller

    管理維護Job,爲Jod創建一次性任務Pod,保證完成Job指定完成的任務數目

  14. Pod Autoscaler Controller

    實現Pod的自動伸縮,定時獲取監控數據,進行策略匹配,當滿足條件時執行Pod的伸縮動作。

 

 Kubernetes Node運行節點,運行管理業務容器,包含如下組件:

  1.Kubelet

    負責管控容器,Kubelet會從Kubernetes API Server接收Pod的創建請求,啓動和停止容器,監控容器運行狀態並彙報給Kubernetes API Server。

  2.Kubernetes Proxy

    負責爲Pod創建代理服務,Kubernetes Proxy會從Kubernetes API Server獲取所有的Service信息,並根據Service的信息創建代理服務,實現Service到Pod的請求路由和轉發,從而實現Kubernetes層級的虛擬轉發網絡。

  3.Docker

    Node上需要運行容器服務

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章