Azure Kubernetes Services (AKS) 的 Kubernetes 核心概念

應用程式開發持續轉向以容器為基礎的方法,進而增加協調和管理資源的需求。 Kubernetes 是領先的平臺,可讓您可靠地排程容錯應用程式工作負載。 Azure Kubernetes Service (AKS) 的受控 Kubernetes 供應專案,可進一步簡化以容器為基礎的應用程式部署和管理。

本文將介紹:

  • 核心 Kubernetes 基礎結構元件:
    • 控制平面
    • 節點
    • 節點集區
  • 工作負載資源:
    • 豆莢
    • 部署
  • 如何將資源群組到 命名空間

什麼是 Kubernetes?

Kubernetes 是一個快速發展中的平台,可管理容器型應用程式及其相關聯的網路和儲存體元件。 Kubernetes 著重于應用程式工作負載,而不是基礎結構元件。 Kubernetes 提供宣告式部署方法,並以一組完善的 API 管理作業,作為此部署方法的後盾。

您可以建立及執行新式、可移植的微服務型應用程式,並使用 Kubernetes 來協調和管理應用程式元件的可用性。 隨著小組採用以微服務為基礎的應用程式而獲得進展,Kubernetes 對於無狀態與具狀態的應用程式均提供支援。

Kubernetes 屬於開放式平台,可讓您使用慣用的程式設計語言、作業系統、程式庫或訊息匯流排來建置您的應用程式。 現有的持續整合與持續傳遞 (CI/CD) 工具可與 Kubernetes 整合,以排程及部署發行。

AKS 提供受控 Kubernetes 服務,可降低部署和核心管理工作(例如升級協調)的複雜性。 Azure 平臺會管理 AKS 控制平面,而您只需針對執行應用程式的 AKS 節點付費。 AKS 建置於開放原始碼 Azure Kubernetes Service 引擎: AKS 引擎上。

Kubernetes 叢集架構

Kubernetes 叢集分成兩個元件:

  • 控制平面:提供應用程式工作負載的核心 Kubernetes 服務和協調流程。
  • 節點:執行您的應用程式工作負載。

Kubernetes 控制平面和節點元件

控制平面

當您建立 AKS 叢集時,系統會自動建立並設定控制平面。 由於受控 Azure 資源已從使用者抽象化,因此免費提供此控制平面。 您只需針對附加至 AKS 叢集的節點付費。 控制平面和其資源只會在您建立叢集所在的區域上。

控制平面包含下列核心 Kubernetes 元件:

元件 描述
kube-apiserver API 伺服器是基礎 Kubernetes Api 的公開方式。 此元件可提供管理工具的互動,例如 kubectl 或 Kubernetes 儀表板。
etcd 為了維持 Kubernetes 叢集和設定的狀態,高可用性 etcd 是 Kubernetes 內的索引鍵值存放區。
kube-scheduler 當您建立或調整應用程式時,排程器會判斷哪些節點可以執行工作負載,並加以啟動。
kube-controller-manager 控制器管理員會監看一些較小的控制器,這些控制器會執行一些動作,例如複寫 pod 和處理節點作業。

AKS 提供單一租使用者控制平面,具有專用的 API 伺服器、排程器等。您可以定義節點的數目和大小,而 Azure 平臺會設定控制平面和節點之間的安全通訊。 與控制平面的互動是透過 Kubernetes Api (例如 kubectl 或 Kubernetes 儀表板)進行。

雖然您不需要設定元件 (像是具有此受控控制平面的高可用性 etcd 存放區) ,您無法直接存取控制平面。 Kubernetes 控制平面和節點升級會透過 Azure CLI 或 Azure 入口網站進行協調。 若要針對可能的問題進行疑難排解,您可以透過 Azure 監視器記錄來檢查控制平面記錄檔。

若要設定或直接存取控制平面,請使用 aks 引擎來部署您自己的 Kubernetes 叢集。

如需相關的最佳作法,請參閱 AKS 中叢集安全性和升級的最佳做法

節點和節點集區

若要執行您的應用程式和支援服務,您需要一個 Kubernetes 節點。 AKS 叢集至少有一個節點,也就是執行 Kubernetes 節點元件和容器執行時間的 Azure 虛擬機器 (VM) 。

元件 描述
kubelet Kubernetes 代理程式,可處理來自控制平面的協調流程要求,以及排程執行要求的容器。
kube-proxy 處理每個節點上的虛擬網路。 Proxy 會路由網路流量,以及管理服務和 Pod 的 IP 定址。
容器執行時間 允許容器化應用程式與其他資源(例如虛擬網路和儲存體)執行及互動。 使用 Kubernetes version 1.19 + for Linux 節點集區的 AKS 叢集,會用來 containerd 作為其容器執行時間。 從 Kubernetes 1.20 版開始 Windows 節點集區, containerd 可用於容器執行時間的預覽中,但 Docker 仍是預設的容器執行時間。 針對節點集區使用舊版 Kubernetes 的 AKS 叢集,會使用 Docker 作為其容器執行時間。

Kubernetes 節點的 Azure 虛擬機器和支援的資源

節點的 Azure VM 大小會定義儲存體 Cpu、記憶體、大小和可用的類型 (例如高效能 SSD 或一般 HDD) 。 規劃節點大小,以確定您的應用程式可能需要大量的 CPU 和記憶體或高效能儲存體。 相應放大 AKS 叢集中的節點數目以符合需求。

在 AKS 中,叢集節點的 VM 映射是以 Ubuntu Linux 或 Windows Server 2019 為基礎。 當您建立 AKS 叢集或向外擴充節點數目時,Azure 平臺會自動建立並設定所要求的 Vm 數目。 代理程式節點會以標準 Vm 計費,因此會自動套用任何 VM 大小折扣 (包括 Azure 保留) 。

如果使用不同的主機 OS、容器執行時間或包含不同的自訂套件,請使用 aks 引擎 來部署您自己的 Kubernetes 叢集。 上游 aks-engine 發行的功能,並提供預先 AKS 叢集中支援的設定選項。 因此,如果您想要使用或 Docker 以外的容器執行時間 containerd ,您可以執行 aks-engine 來設定和部署符合您目前需求的 Kubernetes 叢集。

資源保留

AKS 會使用節點資源來協助節點功能成為叢集的一部分。 此使用方式可能會在您節點的總資源和 AKS 中的 allocatable 資源之間建立差異。 為使用者部署的 pod 設定要求和限制時,請記住此資訊。

若要尋找節點的 allocatable 資源,請執行:

kubectl describe node [NODE_NAME]

為了維持節點的效能和功能,AKS 會在每個節點上保留資源。 當節點成長到更大的資源時,資源保留會因為較高的使用者部署 pod 管理需求而增加。

注意

使用 AKS 附加元件(例如 Container Insights) (OMS) 將會耗用額外的節點資源。

保留兩種類型的資源:

  • CPU
    保留的 CPU 取決於節點類型和叢集設定,因為執行其他功能,可能會導致 allocatable 的 CPU 較少。

    主機上的 CPU 核心 1 2 4 8 16 32 64
    Kube-reserved (millicore) 60 100 140 180 260 420 740
  • 記憶體
    AKS 使用的記憶體包括兩個值的總和。

    1. kubelet 守護 進程
      kubelet 守護程式會安裝在所有 Kubernetes 代理程式節點上,以管理容器建立和終止。

      根據預設,AKS 上 kubelet 的 daemon 具有 記憶體。可用<750Mi 收回規則,確保節點隨時都必須至少有 750 Mi allocatable。 當主機低於可用的記憶體閾值時, kubelet 會觸發以終止其中一個正在執行的 pod,並釋出主機電腦上的記憶體。

    2. Kubelet daemon 的 記憶體保留回歸率,可正常運作 (kube 保留) 。

      • 前 4 GB 記憶體的25%
      • 20% 的 (下 4 GB 的記憶體,最多 8 GB)
      • 下 8 GB 記憶體的 10% (高達 16 GB)
      • 下 112 GB 記憶體的 6% (高達 128 GB)
      • 128 GB 以上記憶體的2%

記憶體和 CPU 配置規則:

  • 讓代理程式節點保持良好狀態,包括某些主機系統 pod 對叢集健全狀況很重要。
  • 使節點報告的 allocatable 記憶體和 CPU 比不是 Kubernetes 叢集的一部分更少。

無法變更上述資源保留。

例如,如果節點提供 7 GB,它會報告34% 的記憶體未 allocatable,包括750Mi 的硬性收回閾值。

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

除了 Kubernetes 本身的保留之外,基礎節點作業系統也會保留大量的 CPU 和記憶體資源,以維護作業系統功能。

如需相關的最佳作法,請參閱 AKS 中基本排程器功能的最佳做法

節點集區

相同設定的節點會一起分組到 節點集區 中。 Kubernetes 叢集至少包含一個節點集區。 當您建立 AKS 叢集時,會定義初始節點數目和大小,以建立 預設節點集 區。 AKS 中的這個預設節點集區包含用來執行代理程式節點的基礎 VM。

注意

為了確保您的叢集能可靠地運作,您應該在預設節點集區中至少執行兩個 (2) 節點。

您可以根據預設節點集區來調整或升級 AKS 叢集。 您可以選擇調整或升級特定節點集區。 進行升級作業時,執行中的容器會排程於節點集區中的其他節點上,直到所有節點皆成功升級。

如需有關如何在 AKS 中使用多個節點集區的詳細資訊,請參閱 在 AKS 中建立和管理叢集的多個節點集區。

節點選取器

在具有多個節點集區的 AKS 叢集中,您可能需要告知 Kubernetes 排程器要針對指定的資源使用哪個節點集區。 例如,輸入控制器不應該在 Windows 的伺服器節點上執行。

節點選取器可讓您定義各種參數,例如節點 OS,以控制 pod 應排程的位置。

下列基本範例會使用節點選取器 "kubernetes.io/os" 來排定 linux 節點上的 NGINX 實例: linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

如需如何控制 pod 排程位置的詳細資訊,請參閱 AKS 中先進排程器功能的最佳做法

Pod

Kubernetes 會 使用 pod 來執行應用程式的實例。 一個 Pod 代表應用程式的單一執行個體。

Pod 通常會有與容器的1:1 對應。 在 advanced 案例中,pod 可能包含多個容器。 多容器 pod 會在同一個節點上一起排程,並允許容器共用相關的資源。

當您建立 pod 時,可以定義 資源要求 來要求特定數量的 CPU 或記憶體資源。 Kubernetes 排程器會藉由將 pod 排程在具有可用資源的節點上執行,來嘗試符合要求。 您也可以指定資源限制上限,以防止 pod 從基礎節點耗用太多計算資源。 最佳做法是為所有 pod 加上資源限制,以協助 Kubernetes 排程器找出必要、允許的資源。

如需詳細資訊,請參閱 Kubernetes PodKubernetes Pod 生命週期

Pod 是邏輯資源,但應用程式工作負載會在容器上執行。 Pod 通常是暫時的可處置資源。 個別排程的 pod 遺漏一些高可用性和冗余 Kubernetes 功能。 取而代之的是,pod 是由 Kubernetes 控制器(例如部署控制器)所部署和管理。

部署和 YAML 資訊清單

部署 代表 Kubernetes 部署控制器所管理的相同 pod。 部署會定義要建立的 pod 複本 數目。 如果 pod 或節點發生問題,Kubernetes 排程器可確保在狀況良好的節點上排程其他 pod。

您可以更新部署以變更 Pod 的設定、使用的容器映像,或連結的儲存體。 部署控制器:

  • 清空和終止指定數目的複本。
  • 從新的部署定義建立複本。
  • 繼續處理,直到部署中的所有複本都更新為止。

AKS 中的多數無狀態應用程式均應使用部署模型,而不是排程個別的 Pod。 Kubernetes 可以監視部署健康情況和狀態,以確保在叢集中執行所需的複本數目。 個別排程時,如果 pod 遇到問題,就不會重新開機,而且如果其目前節點發生問題,則不會重新排程在狀況良好的節點上。

如果您的應用程式至少需要可用的實例數目,您就不會想要在更新程式中中斷管理決策。 Pod 中斷預算 定義在更新或節點升級期間,可以將部署中的複本數降到多少。 例如,如果您的部署中有 五個 (5 個) 的複本,您可以將 pod 中斷定義為 4 (四) ,以便一次只允許刪除或重新排程一個複本。 和 pod 資源限制一樣,最佳作法是在需要永遠存在複本數目下限的應用程式上定義 pod 中斷預算。

部署通常可透過 kubectl createkubectl apply 來建立和管理。 藉由定義 YAML 格式的資訊清單檔,以建立部署。

下列範例會建立 NGINX Web 伺服器的基本部署。 部署會指定要建立的 三個 (3) 複本,而且需要在容器上開啟埠 80 。 此外也會定義 CPU 和記憶體的資源要求和限制。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

您可以藉由在 YAML 資訊清單中包含服務 ((例如負載平衡器) )來建立更複雜的應用程式。

如需詳細資訊,請參閱 Kubernetes 部署

使用 Helm 管理套件

Helm 通常用來管理 Kubernetes 中的應用程式。 您可以藉由建立和使用現有的公用 Helm (其中包含封裝版的應用程式程式碼和 Kubernetes YAML 資訊清單)來部署資源。 您可以在本機或遠端儲存機制(例如 Azure Container Registry Helm 圖表存放庫)中儲存 Helm 圖表。

若要使用 Helm,請在您的電腦上安裝 Helm 用戶端,或使用 Azure Cloud Shell中的 Helm 用戶端。 搜尋或建立 Helm 圖,然後將它們安裝到您的 Kubernetes 叢集。 如需詳細資訊,請參閱 在 AKS 中使用 Helm 安裝現有的應用程式

StatefulSet 和 Daemonset

使用 Kubernetes 排程器,部署控制器會在具有可用資源的任何可用節點上執行複本。 雖然此方法對無狀態應用程式而言可能已足夠,但部署控制器不適合需要的應用程式:

  • 持續性命名慣例或儲存體。
  • 要存在於叢集中每個選取節點上的複本。

不過,有兩個 Kubernetes 資源可讓您管理這些類型的應用程式:

  • Statefulset 會將應用程式的狀態維持在個別 pod 生命週期以外,例如儲存體。
  • Daemonset 確保在 Kubernetes 啟動程式早期,于每個節點上執行實例。

StatefulSet

新式應用程式開發通常是無狀態應用程式的目標。 針對可設定狀態的應用程式(例如包含資料庫元件的應用程式),您可以使用 statefulset。 和部署一樣,StatefulSet 也會建立並管理至少一個相同的 pod。 StatefulSet 中的複本遵循正常、連續的方法來進行部署、調整、升級和終止。 命名慣例、網路名稱和儲存體會保存,因為複本會以 StatefulSet 重新排程。

使用 YAML 格式定義應用程式 kind: StatefulSet 。 從該處,StatefulSet 控制器會處理所需複本的部署與管理。 資料會寫入至 Azure 受控磁碟或 Azure 檔案所提供的永續性儲存體。 使用 Statefulset 時,即使刪除 StatefulSet,仍會保留基礎持續性儲存區。

如需詳細資訊,請參閱 Kubernetes StatefulSet

StatefulSet 中的複本可在 AKS 叢集中任何可用的節點上排程及執行。 若要確保您的集合中至少有一個 pod 在節點上執行,請改用 DaemonSet。

DaemonSet

針對特定的記錄檔收集或監視,您可能需要在所有或選取的節點上執行 pod。 您可以在一或多個相同的 pod 上使用 DaemonSet 部署,但 DaemonSet 控制器可確保指定的每個節點都執行 pod 的實例。

DaemonSet 控制器可及早在叢集啟動程序執行時,在預設 Kubernetes 排程器啟動之前將 Pod 排程於節點上。 這項功能可確保 DaemonSet 中的 Pod 會在部署或 StatefulSet 中的傳統 Pod 排程之前啟動。

和 StatefulSet 相同,DaemonSet 也可使用 kind: DaemonSet 定義為 YAML 定義的一部分。

如需詳細資訊,請參閱 Kubernetes DaemonSet

注意

如果使用 虛擬節點附加元件,daemonset 將不會在虛擬節點上建立 pod。

命名空間

Kubernetes 資源(例如 pod 和部署)會以邏輯方式分組到 命名空間 ,以分割 AKS 叢集,並限制建立、查看或管理資源的存取權。 例如,您可以建立命名空間來分隔商務群組。 使用者只能與其指派的命名空間內包含的資源互動。

依邏輯區隔資源和應用程式的 Kubernetes 命名空間

您在建立 AKS 叢集時,可以使用下列命名空間:

命名空間 描述
預設值 當未提供任何內容時,預設會建立 pod 和部署。 在較小的環境中,您可以直接將應用程式部署到預設命名空間中,而無須建立額外的邏輯分隔。 當您與 Kubernetes API 互動時 (例如 kubectl get pods),若未指定命名空間,將會使用預設值。
kube-system 存在核心資源的位置,例如 DNS 和 proxy 等網路功能,或 Kubernetes 儀表板。 您通常不會將自己的應用程式部署到此命名空間中。
kube-public 通常不會使用,但可用於在整個叢集中可見的資源,並可供任何使用者查看。

如需詳細資訊,請參閱 Kubernetes 命名空間

後續步驟

本文說明了部分核心 Kubernetes 元件,及其套用至 AKS 叢集的方式。 如需有關 Kubernetes 及 AKS 核心概念的詳細資訊,請參閱下列文章: