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

應用程式開發會繼續進入以容器為基礎的方法,增加協調和管理資源的需求。 Kubernetes 是領先的平台,可提供容錯應用程式工作負載的可靠排程。 Azure Kubernetes Service (AKS) 是受控 Kubernetes 供應項目,可進一步簡化容器型應用程式的部署和管理。

本文將介紹:

  • 核心 Kubernetes 基礎結構元件:
    • 控制平面
    • 節點
    • 節點集區
  • 工作負載資源:
    • Pod
    • deployments
    • 集合
  • 如何將資源分組為命名空間

什麼是 Kubernetes?

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

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

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

AKS 提供受控 Kubernetes 服務,可減少部署和核心管理工作的複雜度,例如升級協調。 Azure 平台管理 AKS 控制平面,您只需針對執行應用程式的 AKS 節點付費。

Kubernetes 叢集架構

Kubernetes 叢集分成兩個元件:

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

Kubernetes 控制平面與節點元件

控制平面

您建立 AKS 叢集時,就會自動建立並設定控制平面。 此控制平面會免費以受控 Azure 資源的形式提供,使用者無需加以管理。 您只需支付連結至 AKS 叢集的節點費用。 控制平面以及資源只位於您建立叢集的區域。

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

元件 描述
kube-apiserver API 伺服器是公開基礎 Kubernetes API 的方式。 此元件可提供管理工具的互動,例如 kubectl 或 Kubernetes 儀表板。
etcd 擁有高可用性的 etcd 是 Kubernetes 中的金鑰值存放區,用以維護 Kubernetes 叢集和設定的狀態。
kube-scheduler 您建立或調整應用程式時,排程器會判斷哪些節點可執行工作負載,並加以啟動。
kube-controller-manager 控制器管理員會監看數個小型控制器,這些控制器負責執行複寫 Pod 和處理節點作業之類的動作。

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

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

若要設定或直接存取控制平面,請使用叢集 API 提供者 Azure 部署自我管理 Kubernetes 叢集。

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

節點和節點集區

若要執行應用程式和支援的服務,您必須要有 Kubernetes 節點。 AKS 叢集中有至少一個節點,而此類節點是可執行 Kubernetes 節點元件和容器執行階段的 Azure 虛擬機器 (VM)。

元件 描述
kubelet Kubernetes 代理程式負責處理來自控制平面的協調流程要求,以及處理排程和執行要求的容器。
kube-proxy 處理每個節點上的虛擬網路。 Proxy 會路由網路流量,以及管理服務和 Pod 的 IP 定址。
容器執行階段 可讓容器化應用程式執行其他資源並與其互動,例如虛擬網路和儲存體。 針對 Linux 節點集區使用 Kubernetes 1.19 版以上版本的 AKS 叢集會使用 containerd 作為其容器執行時間。 從 Windows節點集區的 Kubernetes 1.20 版開始,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 保留)。

對於受控磁碟,系統會根據選取的 VM SKU 和 vCPU 計數來指派預設磁碟大小和效能。 如需詳細資訊,請參閱預設 OS 磁碟大小調整

如果您需要 Kubernetes 節點容器執行時間和作業系統上的進階設定和控制,您可以使用叢集 API 提供者 Azure 來部署自我管理叢集。

資源保留

AKS 會使用節點資源來協助節點作為叢集的一部分運作。 此使用量可能會讓節點的總資源與 AKS 中可配置的資源不一致。 設定使用者部署 Pod 的要求和限制時,請記住這項資訊。

若要尋找節點的可配置資源,請執行:

kubectl describe node [NODE_NAME]

為了維持節點的效能與功能,AKS 會在每個節點上保留資源: 節點在資源中成長較大時,資源保留會因為管理使用者部署 Pod 的需求較高而成長。

注意

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

保留兩種類型的資源:

  • CPU
    保留的 CPU 取決於節點類型和叢集設定,這可能會因為執行其他功能而造成較少可配置的 CPU。

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

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

      根據預設,kubelet 精靈在 AKS 上具有 memory.available<750Mi 收回規則,確保節點隨時都必須至少有 750 Mi 可配置。 主機低於該可用的記憶體閾值時,kubelet 會觸發而終止其中一個執行中的 Pod,並在主機電腦上釋放記憶體。

    2. kubelet 精靈可正常運作的記憶體保留迴歸速率 (kube 保留)。

      • 前 4 GB 記憶體的 25%
      • 後續 4 GB 記憶體 (最多 8 GB) 的 20%
      • 後續 8 GB 記憶體 (最多 16 GB) 的 10%
      • 後續 112 GB 記憶體 (最多 128 GB) 的 6%
      • 任何 128 GB 以上記憶體的 2%

注意

AKS 會在不屬於已計算記憶體的 Windows 節點中,為系統程序額外保留 2GB。

記憶體和 CPU 配置規則:

  • 讓代理程式節點保持狀況良好,包括對叢集健全狀態至關重要的一些裝載系統 Pod。
  • 使節點報告較少的可配置記憶體和 CPU (彷彿不是 Kubernetes 叢集的一部分)。

以上保留的資源無法變更。

例如,如果節點提供 7 GB,這會報告 34% 的記憶體,但不包括 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 伺服器節點上執行。

節點選取器可讓您定義各種參數,例如節點作業系統,以控制應該排程 Pod 的位置。

下列基本範例會使用節點選取器 "kubernetes.io/os": linux 在 Linux 節點上排程 NGINX 執行個體:

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 的對應。 在進階案例中,Pod 可能會包含多個容器。 多容器 Pod 會一起排程於相同的節點上,並允許容器共用相關資源。

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

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

Pod 是邏輯資源,但應用程式工作負載是在容器上執行。 Pod 通常是暫時的可處置資源。 個別排程的 Pod 會錯過一些高可用性和備援 Kubernetes 功能。 實際上,Pod 會由 Kubernetes「控制器」部署及管理,例如「部署控制器」。

部署和 YAML 資訊清單

「部署」代表由 Kubernetes 部署控制器管理的相同 Pod。 部署會定義要建立的 Pod「複本」數量。 Kubernetes 排程器則會確保若 Pod 或節點發生問題,仍然會在狀況良好的節點上排程其他 Pod。

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

  • 清空並終止指定的複本數目。
  • 從新的部署定義建立複本。
  • 繼續此流程,直到部署中的所有複本更新為止。

AKS 中的多數無狀態應用程式均應使用部署模型,而不是排程個別的 Pod。 Kubernetes 可監視部署健康情況和狀態,以確定有所需數量的複本於叢集內執行。 如果個別排程 Pod,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 資訊清單。 您可以將 Helm 圖表儲存在本機,或儲存在遠端存放庫中,例如 Azure Container RegistryHelm 圖表存放庫

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

StatefulSet 和 Daemonset

使用 Kubernetes 排程器,部署控制器會在任何有可用資源的可用節點上執行複本。 雖然此方法可能足以用於無狀態應用程式,但部署控制器不適合需要下列項目的應用程式:

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

不過,兩項 Kubernetes 資源可讓您管理以下類型的應用程式:

  • StatefulSet 跨個別 Pod 生命週期維護應用程式的狀態,例如儲存體。
  • DaemonSet 在 Kubernetes 早期啟動程序時確定每個節點都有執行中的執行個體。

StatefulSet

新式應用程式開發通常的目標是無狀態應用程式。 針對具狀態應用程式,例如包含資料庫元件的具狀態應用程式,您可以使用 StatefulSet。 如同部署,StatefulSet 會建立和管理至少一個相同的 Pod。 StatefulSet 中的複本會依照正常、循序的方法進行部署、調整、升級和終止。 透過 StatefulSet,命名慣例、網路名稱和儲存體在複本重新排程後仍可持續保存。

使用 kind: StatefulSet 以 YAML 格式定義應用程式。 從其中,StatefulSet 控制器會處理所需複本的部署和管理。 資料會寫入至 Azure 受控磁碟或 Azure 檔案所提供的永續性儲存體。 透過 StatefulSet,即使在 StatefulSet 刪除後,基礎的永續性儲存體仍將保存。

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

StatefulSet 中的複本可在 AKS 叢集中任何可用的節點上排程及執行。 若要確定每個節點都至少要執行您集合中的一個 Pod,您可以改用 DaemonSet。

DaemonSet

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

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

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

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

注意

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

命名空間

Kubernetes 資源,例如 Pod 和部署,會以邏輯方式分組為「命名空間」,以分割 AKS 叢集,並限制對資源的建立、檢視或管理存取。 例如,您可以建立命名空間以區隔商務群組。 使用者只能與其指派的命名空間內包含的資源互動。

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

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

命名空間 描述
預設值 在未提供任何 Pod 和部署時依預設用來建立這些項目的位置。 在較小的環境中,您可以直接將應用程式部署到預設命名空間中,而無須建立額外的邏輯分隔。 當您與 Kubernetes API 互動時 (例如 kubectl get pods),若未指定命名空間,將會使用預設值。
kube-system 核心資源的所在之處,例如 DNS 和 Proxy 之類的網路功能,或是 Kubernetes 儀表板。 您通常不會將自己的應用程式部署到此命名空間中。
kube-public 通常不會使用,但可用於要在整個叢集中顯示,並且可供任何使用者檢視的資源。

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

後續步驟

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