Kubernetes基本概念與架構


Kubernetes,面向雲原生應用的新“雲平台”

Kubernetes:以google Brog為原型

 

Kubernetes的成長歷程:

l  2014年,Kubernetes正式由google開源

l  2015年,谷歌將Kubernetes捐給Linux基金會下屬的雲原聲計算基金會-CNCF

l  2017年,Kubernetes戰勝Swarm和 Mesos,成為容器管理與調度編排領域的首選平台和事實標准

 Kubernetes作為容器管理平台提供:

l  以Pod(容器組)為基本的編排和調度單元以及聲明式的對象配置模型(控制器、configmap、secrect等)

l  資源配額與分配管理

l  健康檢查、自愈、伸縮與滾動升級

Kubernetes提供了對微服務的支撐

l  服務發現、服務編排與內部路由支持

l  服務快速部署和自動負載均衡

l  提供對“有狀態”服務的支持等

總結一下,Kubernetes提供:

l  新一代應用雲化的事實標准,成為雲原聲的新可移植層,即新“雲平台”

l  為用戶提供簡單且一致的容器化應用部署、伸縮和管理機制,形成新的、通用的應用雲化模型

l  雲廠商鎖定的問題得以解決,雲應用支持跨雲遷移

Why Kubernetes

從生態圈角度:

l  Google的業內最成熟的容器編排管理經驗的輸出

l  2017年Kubernetes戰勝Swarm和 Mesos,成為容器管理與調度編排領域的首選平台和事實標准

l  傳統雲平台提供商的全面支持:google k8s engine、 Red Hat的OpenShift、Microsoft的Azure container service,

從雲應用角度,Kubernetes帶來的好處 :

l  容器管理、調度和編排的事實標准:擺脫鎖定,支持跨雲

l  先進的Workload管理之經驗模型:Pod和Controllers

l  原生支持微服務抽象:服務注冊、服務發現和自動負載均衡

1.Kubernetes架構與組件

Kubernetes架構全圖:

Master組件:集群大腦

 

Master:Kubernetes集群大腦,控制平面:

l  所有集群的控制命令都傳遞給Master組件並在其上執行

l  每個Kubernetes集群至少有一套Mater組件

l  每套Master組件包括三個核心組件(apiserver,scheduler和controller-manager)以及集群數據配置中心etcd

組件API Server:

l  集群控制的唯一入口,是提供Kubernetes集群控制RESTful API的核心組件

l  集群內各個組件之間數據交互和通信的中樞

l  提供集群控制的安全機制(身份認證、授權以及admission control)

組件:Scheduler

l  通過API Server的Watch接口監聽新建Pod副本信息,並通過調度算法為該Pod選擇一個最為合適的Node

l  支持自定義調度算法provider

l  默認調度算法內置預選策略,決策考量資源需求、服務質量、軟硬件約束、親緣性、數據局部性等指標參數

組件:ControllerManager

l  集群內各種資源controller的核心管理者

l  針對每一種具體的資源,都有相應的Controller

l  保證其下管理的每個Controller

每個controller的邏輯:

       For{

              獲取資源期望狀態

              獲取資源當前狀態

              改變:當前狀態à期望狀態

  }

組件:Etcd

l  Kubernetes集群的主數據庫,存儲着所有資源對象以及狀態

l  默認與Master組件部署在一個Node上

l  Etcd的數據變更都是通過API Server進行

Node組件:

Node:工作負載節點

Node:Kubernetes急群眾真正的工作負載節點

l  Kubernetes集群由多個Node共同承擔工作負載,Pod被分配到某個具體的Node上執行

l  Kubernetes通過node controller對node資源進行管理。支持動態在集群中添加或刪除Node

l  每個集群Node上都會部署Kubelet和Kube-proxy兩個組件

組件Kubelet

l  位於集群中每個Node上的非容器形式的服務進程組件,Master和node之間的橋梁

l  處理Mater下發到本Node上的Pod創建、啟停等管理任務;向API Server注冊Node信息

l  監控本Node上容器和節點資源情況,並定期向Master匯報節點資源占用情況

組件:Kube-proxy(運行在每個Node上)

l  Service抽象概念的實現,將到Service的請求按策略(負載均衡)算法分發到后端Pod(Endpoint)上

l  默認使用iptables mode實現

l  支持nodeport模式,實現從外部訪問集群內的service

總結一下,Kubernetes架構和組件:

l  兩類節點:Master和Node

l  Master組件:apiserver,scheduler,controllerManager,etcd

l  節點組件:kubelet,kube-proxy

2.Kubernetes基礎概念

Kubernetes對象:是一種持久化的,用於表示集群狀態的實體

²  一種聲明式的意圖的記錄,一般使用yaml文件描述對象

²  Kubernetes集群使用Kubernetes對象來表示集群的狀態

²  通過API/kubectl管理Kubernetes對象

Name和UID:

²  Kubernetes集群中所有對象都通過name和UID明確標識

²  API中的對象訪問路徑:/api/{version}/namespaces/{namespace}/{object-kind}/name,比如:/api/v1/namespaces/default/podshello-kubernetes

²  在多媒體信息檢索集群的整個生命周期內創建的眉哥哥對象實例都具有不同的UID

 Namespace,不僅僅是一個屬性,本身也是一個object

²  Namespace:用於將物理集群划分為多個虛擬集群

²  Namespace間完全隔離,因此也常被用來隔離不同的用戶(及權限)

²  內置三個Namespace:default、kube-system和kube-public,Node和PersistenVolume不屬於任何namespace

 Label用於建立集群對象之間的靈活的、松耦合的多維關聯關系

²  一個label是一個鍵-值對,其中key、value均由用戶自己定義

²  Label可以附着在任何對象上,每個對象也可以由任意個標簽。標簽可在對象定義時附加上,也可以通過命令動態管理標簽

²  Label可以將有組織有目的的結構映射到集群對象上,從而形成一個與現實世界管理結構同步對應松耦合的,多維的對象管理結構

通過label selector查詢和篩選建立對象間的關系

Annotations:可以將任意非標識性元數據附加到對象上

²  Annotations也是可以鍵值對形式呈現的

²  工具和庫可以檢索到並使用這些Annotations元數據

²  將數據作為Annotation附着在對象上,有利於創建一些用於部署、管理和做內部檢查的共享工具或客戶端

 Kubernetes對象分類

工作負載:以pod為中心

Pod:一個有特定關系的容器集合

u  Pod是集群中可以創建和部署的最小且最簡的Kubernetes對象單元

u  Pod也是一種封裝,它封裝了應用容器,存儲資源,獨立的網絡IP以及決定容器如何運行的策略選項

u  每個Pod中預置一個Pause容器,其名字空間、IPC資源、網絡和存儲資源被Pod內其他容器共享。Pod中的所有容器緊密協作,並且作為一個整體被管理、調度和運行

Pod生命周期

 

Service:與雲原生應用中“微服務“概念一一對應

u  Kubernetes集群為每一個Service分配一個集群唯一的IP地址,在service的生命周期內,該IP地址不變;在內部DNS的支持下,輕松實現服務發現機制

u  Service通過label selector關聯到實際支撐業務運行的Pod上,並通過集群內置的服務負載均衡將服務請求分發到后端的Pod

u  通過nodeport或設置loadbanlance機制實現集群外部對service的訪問

Controller是Kubernetes核心對象之一

u  Controller用於保證集群內一組Pod能始終按照某種期望的狀態(desired state)正常運行

u  狀態包括:Pod副本數量、節點選擇、資源約束、持久化數據維持等

u  Kubernetes支持多種Controller,常用的Deployment、replicaset、statefulset、damonset等

ReplicaSet:確保健康Pod的副本數始終滿足用戶定義的數量

u  前身是ReplicationController(rc)

u  相比rc,增加集合式label selector的支持

u  支持單獨使用,但更多隱藏在Deployment控制器后面,由deployment自動管理

Deployment:為Pod和ReplicaSet提供了聲明式的定義(declarative)

u  用戶在deploy門頭文件中描述期望狀態,Deployment controller就會自動將Pod 和Replica Set 的實際狀態改變到期望狀態

u  Deployment支持Pod的RollingUpdate,並自動管理背后的ReplicaSet

u  Deployment支持將Pod Rollback 到之前的任意version(僅限於pod-template模板改動)

StatefulSet:提供對有狀態應用的部署和控制的支持,1.9版本GA

u  適用場景:穩定的持久化存儲、穩定的網絡標志、有序部署有序擴展、有序收縮有序刪除、有序自動滾動升級等

u  Pod的存儲必須由PersistentVolume Provisioner根據請求的Storge Class進行配置,或由管理員預先配置好

u  考慮數據安全性,伸縮或刪除StatefulSet不會刪除關聯的存儲;另外Stateful目前要求Headless Service負責Pod的網絡身份,用戶有責任創建此服務

DaemonSet:保證在每個Node上都運行一個Pod副本

u  適用場景:系統Daemon程序、監控跟蹤、日志收集等

u  Kubernetes1.6之后,可設置更新策略:支持滾動更新

u  可指定Node:nodeSelector、nodeAffinity、podAffinity

ConfigMap:常用來向Pod提供非敏感的配置信息

u  ConfigMap用於保存配置數據的鍵值對,可以用來保存單個屬性,也可以用來保存配置文件

u  ConfigMap可以使用命令行基於字面值、文件或目錄來創建或通過configmap對象定義文件創建

u  ConfigMap可以通過三種方式在Pod中使用:環境變量、容器命令行參數或以文件形式通過數據卷掛載到Pod中 

Secret解決的是集群內密碼、token、密鑰等敏感數據的配置問題

u  常用於與ServiceAccount關聯,存儲在tmpfs文件系統中,Pod刪除后Secret文件也會對應的刪除

u  支持Opaque,Kubernetes.io/Service Account, Kubernetes.io/dockerconfigjson三種類型

u  Secrect可以以volume或者環境變量的方式使用

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM