虛擬化技術淺析之初識Kubernetes

作者：京東云開發者 2023-02-28 08:24:49

Federation控制平面“封裝”了多個k8s集群的Master角色，提供了統一的Master，包括Federation API Server、Federation Controller Manafer，用戶可以向操作單個集群一樣操作Federation，還統一了全部k8s集群的DNS、ConfigMap，并將數據保存在集中的etcd數據庫中。

作者：京東物流楊建民

一、微服務架構起源

單體架構：可以理解為主要業務邏輯模塊（我們編寫的代碼模塊，不包括獨立的中間件）運行在一個進程中的應用，最典型的是運行在一個Tomcat容器中，位于一個進程里。單體架構好處是技術門檻低、編程工作量少、開發簡單快捷、調試方便、環境容易搭建、容易發布部署及升級，開發運維等總體成本很低、見效快。其缺點也明顯：

（1）單體應用系統比較膨脹與臃腫，耦合度高，導致進行可持續開發和運維很困難。

（2）單體應用難以承載迅速增長的用戶請求和需求。

基于Spring Framework的單體應用架構圖

分布式架構核心思想是把一個單一進程的系統拆分為功能上相互協作又能獨立部署在多個服務器上的一組進程，這樣一來，系統可以根據實際業務需要，通過以下兩種方式實現某些獨立組件的擴容，提升吞吐量。

水平擴展：通過增加服務器數量進行擴容
垂直擴展：給系統中的某些特殊業務分配更好的機器，提供更多資源，從而提升這些業務的系統負載和吞吐

分布式架構是將一個龐大的單體應用拆分成多個獨立運行的進程，這些進程能通過某種方式實現遠程調用，因此，分布式架構要解決的第一個核心技術問題就是獨立進程之間的遠程通信。該問題的最早答案就是RPC技術（Remote Procedure Call），一種典型的微服務架構平臺的結構示意圖如下：

大家比較熟知的微服務架構框架有Dubbo與Spring Cloud，之后比較成功的微服務架構基本都和容器技術掛鉤了，其中最成功的、影響最大的當屬Kubernetes平臺了，與之相似的還有Docker公司推出的Docker Swarm(在2017年底，Docker Swarm也支持Kubernetes了)。

關于微服務架構的優勢由于文章篇幅有限，不再展開，但任何技術都存在兩面性，微服務架構具有一定的復雜性，如開發者必須掌握某種RPC技術，并且必須通過寫代碼來處理RPC速度過慢或者調用失敗等復雜問題。為了解決微服務帶來的編程復雜性問題，一種新的架構設計思想出現了，這就是Service Mesh，Service Mesh定義是：一個用于處理服務于服務之間通信（調用）的復雜的基礎架構設施。從本質上看，Service Mesh是一組網絡代理程序組成的服務網絡，這些代理會與用戶程序部署在一起，充當服務代理，這種代理后來在Google的Istio產品架構中稱為“Sidecar”，其實就是采用了代理模式的思想去解決代碼入侵及重復編碼的問題，。下圖給出了Service Mesh最簡單的架構圖。Servie Mesh同樣不是本次的主角，感興趣的小伙伴可自行學習。

二、初識k8s

官方原文是：K8s is an abbreviation derived by replacing the 8 letters “ubernete” with 8.

k8s全稱kubernetes，名字來源于希臘語，意思為“舵手”或“領航員”，它是第一代容器技術的微服務架構（第二代是Servie Mesh）。

Kubernetes最初源于谷歌內部的Borg，提供了面向應用的容器集群部署和管理系統。Kubernetes 的目標旨在消除編排物理/虛擬計算，網絡和存儲基礎設施的負擔，并使應用程序運營商和開發人員完全將重點放在以容器為中心的原語上進行自助運營。Kubernetes 也提供穩定、兼容的基礎（平臺），用于構建定制化的workflows 和更高級的自動化任務。

Kubernetes 具備完善的集群管理能力，包括多層次的安全防護和準入機制、多租戶應用支撐能力、透明的服務注冊和服務發現機制、內建負載均衡器、故障發現和自我修復能力、服務滾動升級和在線擴容、可擴展的資源自動調度機制、多粒度的資源配額管理能力。

Kubernetes 還提供完善的管理工具，涵蓋開發、部署測試、運維監控等各個環節。

2.1 k8s架構與組件

Kubernetes主要由以下幾個核心組件組成：

etcd保存了整個集群的狀態；
apiserver提供了資源操作的唯一入口，并提供認證、授權、訪問控制、API注冊和發現等機制；
controller manager負責維護集群的狀態，比如故障檢測、自動擴展、滾動更新等；
scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；
kubelet負責維護容器的生命周期，同時也負責Volume（CVI）和網絡（CNI）的管理；
Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；
kube-proxy負責為Service提供cluster內部的服務發現和負載均衡；

2.2 k8s設計理念

API設計原則

API對象是k8s集群中的管理操作單元。k8s集群系統每支持一項新功能，引入一項新技術，一定會新引入對應的API對象，支持對該功能的管理操作。例如副本集Replica Set對應的API對象是RS。

k8s采用聲明式操作，由用戶定義yaml，k8s的API負責創建。每個對象都有3大類屬性：元數據metadata、規范spec和狀態status。元數據是用來標識API對象的，每個對象都至少有3個元數據：namespace，name和uid；除此以外還有各種各樣的標簽labels用來標識和匹配不同的對象，例如用戶可以用標簽env來標識區分不同的服務部署環境，分別用env=dev、env=testing、env=production來標識開發、測試、生產的不同服務。規范描述了用戶期望k8s集群中的分布式系統達到的理想狀態（Desired State），例如用戶可以通過復制控制器Replication Controller設置期望的Pod副本數為3；status描述了系統實際當前達到的狀態（Status），例如系統當前實際的Pod副本數為2；那么復制控制器當前的程序邏輯就是自動啟動新的Pod，爭取達到副本數為3。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

apiVersion - 創建對象的Kubernetes API 版本
kind - 要創建什么樣的對象？
metadata- 具有唯一標示對象的數據，包括 name（字符串）、UID和Namespace（可選項）

使用上述.yaml文件創建Deployment，是通過在kubectl中使用kubectl create命令來實現。將該.yaml文件作為參數傳遞。如下例子：

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record

k8s常見對象：Pod、復制控制器（Replication Controller,RC）、副本集（Replica Set,RS）、部署（Deployment）、服務（Service）、任務（Job）、存儲卷（Volume）、持久存儲卷和持久存儲卷聲明（Persistent Volume,PV、Persistent Volume Claim,PVC）、節點（Node）、ConfigMap、Endpoint等。

控制機制設計原則

每個模塊都可以在必要時優雅地降級服務控制邏輯應該只依賴于當前狀態。這是為了保證分布式系統的穩定可靠，對于經常出現局部錯誤的分布式系統，如果控制邏輯只依賴當前狀態，那么就非常容易將一個暫時出現故障的系統恢復到正常狀態，因為你只要將該系統重置到某個穩定狀態，就可以自信的知道系統的所有控制邏輯會開始按照正常方式運行。
假設任何錯誤的可能，并做容錯處理。在一個分布式系統中出現局部和臨時錯誤是大概率事件。錯誤可能來自于物理系統故障，外部系統故障也可能來自于系統自身的代碼錯誤，依靠自己實現的代碼不會出錯來保證系統穩定其實也是難以實現的，因此要設計對任何可能錯誤的容錯處理。
盡量避免復雜狀態機，控制邏輯不要依賴無法監控的內部狀態。因為分布式系統各個子系統都是不能嚴格通過程序內部保持同步的，所以如果兩個子系統的控制邏輯如果互相有影響，那么子系統就一定要能互相訪問到影響控制邏輯的狀態，否則，就等同于系統里存在不確定的控制邏輯。
假設任何操作都可能被任何操作對象拒絕，甚至被錯誤解析。由于分布式系統的復雜性以及各子系統的相對獨立性，不同子系統經常來自不同的開發團隊，所以不能奢望任何操作被另一個子系統以正確的方式處理，要保證出現錯誤的時候，操作級別的錯誤不會影響到系統穩定性。
每個模塊都可以在出錯后自動恢復。由于分布式系統中無法保證系統各個模塊是始終連接的，因此每個模塊要有自我修復的能力，保證不會因為連接不到其他模塊而自我崩潰。
每個模塊都可以在必要時優雅地降級服務。所謂優雅地降級服務，是對系統魯棒性的要求，即要求在設計實現模塊時劃分清楚基本功能和高級功能，保證基本功能不會依賴高級功能，這樣同時就保證了不會因為高級功能出現故障而導致整個模塊崩潰。根據這種理念實現的系統，也更容易快速地增加新的高級功能，以為不必擔心引入高級功能影響原有的基本功能。

三、資源管理

容器云平臺如何對租戶可用資源進行精細管理，對平臺的可用性、可維護性和易用性起著至關重要的作用，是容器云平臺能夠為用戶提供豐富的微服務管理的基石。在云計算領域，資源可被分為計算資源、網絡資源和存儲資源三大類，也可被分別稱作計算云、網絡云和存儲云。

3.1、計算資源管理

Namespace

在k8s集群中，提供計算資源的實體叫做Node，Node既可以是物理機服務器，也可以是虛擬機服務器，每個Node提供了CPU、內存、磁盤、網絡等資源。每個Node（節點）具有運行pod的一些必要服務，并由Master組件進行管理，Node節點上的服務包括Docker、kubelet和kube-proxy。

通過引入Namespace，k8s將集群近一步劃分為多個虛擬分組進行管理，Namespace所實現“分區”是邏輯上的，并不與實際資源綁定，它用于多租戶場景實現資源分區和資源最大化利用。

大多數Kubernetes資源（例如pod、services、replication controllers或其他）都在某些Namespace中，但Namespace資源本身并不在Namespace中。而低級別資源（如Node和persistentVolumes）不在任何Namespace中。Events是一個例外：它們可能有也可能沒有Namespace，具體取決于Events的對象。

Pod

Pod是Kubernetes創建或部署的最小/最簡單的基本單位，一個Pod代表集群上正在運行的一個進程。

一個Pod封裝一個應用容器（也可以有多個容器），存儲資源、一個獨立的網絡IP以及管理控制容器運行方式的策略選項。Pod代表部署的一個單位：Kubernetes中單個應用的實例，它可能由單個容器或多個容器共享組成的資源。

每個Pod都是運行應用的單個實例，如果需要水平擴展應用（例如，運行多個實例），則應該使用多個Pods，每個實例一個Pod。在Kubernetes中，這樣通常稱為Replication。Replication的Pod通常由Controller創建和管理。Controller可以創建和管理多個Pod，提供副本管理、滾動升級和集群級別的自愈能力。例如，如果一個Node故障，Controller就能自動將該節點上的Pod調度到其他健康的Node上。

Container

docker本身比較重，2015年OCI（Open Container Initiative）誕生，它定義了鏡像標準、運行時標準和分發標準，由于k8s 本身不具備創建容器的能力，是通過 kubelet 組件調用容器運行時 API 接口和命令來創建容器，Kubernete 與容器運行時的關系是歷史性的，也很復雜。但是隨著 Kubernete 棄用 Docker ，目前主流的運行時主要是 containerd 和 CRI-O

“one-container-per-Pod”模式是Kubernetes最常見的用法，一個Pod也可以有多個容器。

三個級別的計算資源管理

在k8s中，可以從Namespace、Pod和Container三個級別區管理資源的配置和限制。例如：

容器級別可以通過Resource Request、Resource Limits配置項

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
spec:
  containers:
  - name: memory-demo-3-ctr
    image: vish/stress
    resources:
      limits:
        memory: "1000Gi"
      requests:
        memory: "1000Gi"
    args:
    - -mem-total
    - 150Mi
    - -mem-alloc-size
    - 10Mi
    - -mem-alloc-sleep
    - 1s

Pod級別可以通過創建LimitRange對象完成設置，這樣可以對Pod所含容器進行統一配置

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "4"
      memory: 2Gi
    min:
      cpu: 200m
      memory: 6Mi
    maxLimitRequestRatio:
      cpu: 3
      memory: 2
    type: Pod
  - default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi
    max:
      cpu: "2"
      memory: 1Gi
    min:
      cpu: 100m
      memory: 3Mi
    maxLimitRequestRatio:
      cpu: 5
      memory: 4
    type: Container

Namespace級別可以通過對ReSourceQuota資源對象的配置，提供一個總體的資源使用量限制，這個限制可以是對所有Poid使用的計算資源總量上限，也可以是對所有Pod某種類型對象的總數量上限（包括可以創建的Pod、RC、Service、Secret、ConfigMap及PVC等對象的數量）

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
  request.cpu: "4"
  request.memory: 8GB
  limit.memory:16GB
  pods: "2"

3.2 網絡資源管理

k8s的ip模型

?node Ip ：node節點的ip，為物理ip.

pod Ip：pod的ip，即docker 容器的ip，為虛擬ip。

cluster Ip：service 的ip，為虛擬ip。提供一個集群內部的虛擬IP以供Pod訪問。實現原理是通過Linux防火墻規則，屬于NAT技術。當訪問ClusterIP時，請求將被轉發到后端的實例上，如果后端實例有多個，就順便實現了負載均衡，默認是輪訓方式。

跨主機容器網絡方案

在k8s體系中，k8s的網絡模型設計的一個基本原則：每個pos都擁有一個獨立的IP地址，而且假定所有的Pod都在一個可以直接聯通的、扁平的網絡空間中，不管它們是否運行在同一個Node（宿主機）中，都可以直接通過對方的IP進行訪問。但k8s本身并不提供跨主機的容器網絡解決方案。公有云環境（例如AWS、Azure、GCE）通常都提供了容器網絡方案，但是在私有云環境下，仍然需要容器云平臺位不同的租戶提供各種容器網絡方案。

目前，為容器設置Overlay網絡是最主流的跨主機容器網絡方案。Overlay網絡是指在不改變原有網絡配置的前提下，通過某種額外的網絡協議，將原IP報文封裝起來形成一個邏輯上的網絡。在k8s平臺上，建議通過CNI插件的方式部署容器網絡。

CNI（Container Network Interface）是CNCF基金會下的一個項目，由一組用于配置容器的網絡接口的規范和庫組成，它定義的是容器運行環境與網絡插件之間的接口規范，僅關心容器創建時的網絡配置和容器被銷毀是網絡資源的釋放，并且一個容器可以綁定多個CNI網絡插件加入網絡中，如下圖。

目前比較流程的CNI插件實現方式有Flannel、Calico、macvlan、Open vSwitch、直接路由。

Ingress

在k8s集群內，應用默認以Service的形式提供服務，有kube-proxy實現Service到容器的負載均衡器的功能，如下圖定義一個mysql service：

kind: Service
apiVersion: v1
metadata:
  name: mysql-master
spec:
  selector:
    app: mysql-master
  ports:
      port: 3306
      targetPort: 3306

此時，集群外是無法訪問這個Service的。對于需要k8s集群外的客戶端提供服務的Service，可以通過Ingress將服務暴露出去，并且如果該集群（網絡）擁有真實域名，則還能將Service直接與域名進行對接。

k8s將一個Ingress資源對象的定義和一個具體的Ingress Controller相結合來實現7層負載均衡器。Ingress Controller在轉發客戶請求到后端服務時，將跳過kube-proxy提供的4層負載均衡器的功能，直接轉發到Service的后端Pod（Endpoints），以提高網絡轉發效率。

如上圖展示了一個典型的HTTP層路由的Ingress例子，其中：

對http://mywebsite.com/api的訪問將被路由到后端名為“api”的Service；
對http://mywebsite.com/web的訪問將被路由到后端名為“web”的Service；
對http://mywebsite.com/doc的訪問將被路由到后端名為“doc”的Service。

如下是一個典型的Ingress策略定義，Ingress Controller將對目標地址http://mywebsite.com/demo的訪問請求轉發到集群內部服務的webapp(webapp:8080/demo)

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
   name: mywebsite-ingress
spec:
   rules:
   -host：mywebsite.com
    http:
       paths:
      - path: /demo
          backend:
           serviceName: webapp
           servicePort: 8080

常用的Ingress Controller有：Nginx、HAProxy、Traefik、apisix等。

3.3 存儲資源

k8s支持的Volume類型

臨時目錄（emptyDir）

使用emptyDir，當Pod分配到Node上時，將會創建emptyDir，并且只要Node上的Pod一直運行，Volume就會一直存。當Pod（不管任何原因）從Node上被刪除時，emptyDir也同時會刪除，存儲的數據也將永久刪除。注：刪除容器不影響emptyDir。

配置類

ConfigMap：將保存在ConfigMap資源對象中的配置文件信息掛載到容器的某個目錄下
Secret：將保存在Secret資源對象中的密碼密鑰等信息掛載到容器內的某個文件中
DownwardApI：將downward API的數據以環境變量或文件的形式注入容器中
gitRepo：將某Git代碼庫掛載到容器內的某個目錄下

本地存儲類

hostPath：將宿主機的目錄或文件掛載到容器內進行使用
local：從v1.9版本引入，將本地存儲以PV形式提供給容器使用，并能夠給實現存儲空間的管理

共享存儲類

PV（Persistne Volume）：將共享存儲定義為一種“持久存儲卷”，可以被多個容器共享使用
PVC（Persistne Volume Claim）：用戶對存儲資源的一次“申請”，PVC申請的對象是PV，一旦申請成功，應用就能夠想使用本地目錄一樣使用共享存儲卷。下圖是一個PV對象ymal定義：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
  annotations:
        "volume.alpha.kubernetes.io/node-affinity": '{
            "requiredDuringSchedulingIgnoredDuringExecution": {
                "nodeSelectorTerms": [
                    { "matchExpressions": [
                        { "key": "kubernetes.io/hostname",
                          "operator": "In",
                          "values": ["example-node"]
                        }
                    ]}
                 ]}
              }'
spec:
    capacity:
      storage: 100Gi
    accessModes:
    - ReadWriteOnce
    persistentVolumeReclaimPolicy: Delete
    storageClassName: local-storage
    local:
      path: /mnt/disks/ssd1

PV與PVC

PV和PVC相互關系生命周期如上圖所示，k8s的共享存儲供應模式包括靜態模式（Static）和動態模式（Dynamic），資源供應的結果就是創建好的PV。運維人員手動創建PV就是靜態，而動態模式的關鍵就是StorageClass，它的作用就是創建PV模板。

創建StorageClass里面需要定義PV屬性比如存儲類型、大小等；另外創建這種PV需要用到存儲插件。最終效果是，用戶提交PVC，里面指定存儲類型，如果符合我們定義的StorageClass，則會為其自動創建PV并進行綁定。

下圖通過ymal創建一個StorageClass對象

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs    // 存儲分配器
parameters:
  type: gp2
reclaimPolicy: Retain   // 回收策略
mountOptions:
  - debug

StorageClass和PV、PVC之間的運作關系如下圖所示：

CSI

CSI（Container Storage Interface）與k8s的關系與CNI有點類似，CSI旨在容器和共享存儲之間建議一套標準的存儲訪問接口。在它誕生前，經歷了“in-tree”方式、FlexVolume模式。

CSI規范用語將存儲供應商代碼與k8s代碼完全解耦，存儲插件的代碼由存儲供應商自行維護。

和kube-apiserver直接進行交互的是K8S官方直接提供的一些sidecar容器，這些sidecar直接部署即可。這些sidecar容器（主要是上圖的三個主要部件）監聽自己對應的CRD，觸發對應的操作，通過UDS接口直接調用CSI driver的接口（例如CreateVolume() 、NodePublishVolme()等）來實現對卷的操作。

要開發CSI Drivers一般來說實現以下幾個服務：

CSI Identity service

允許調用者(Kubernetes組件和CSI sidecar容器)識別驅動程序及其支持的可選功能。

CSI Node service

NodePublishVolume, NodeUnpublishVolume 和 NodeGetCapabilities 是必須的。

所需的方法使調用者能夠使卷在指定的路徑上可用，并發現驅動程序支持哪些可選功能。

CSI Controller Service

實現CreateVolume、DeleteVolume接口

3.4 多集群資源管理方案-集群聯邦（Federation）

Federation是Kubernetes的子項目，其設計目標是對多個Kubernetess集群進行統一管理，將用戶的應用部署到不同地域的數據中心。Federation引入了一個位于Kubernetes集群只上的控制平面，屏蔽了后端各k8s子集群，向客戶提供了統一的管理入口，如下圖:

責任編輯：武曉燕來源：今日頭條