Azure Kubernetes Services (AKS) 的 Kubernetes 核心概念Kubernetes core concepts for Azure Kubernetes Service (AKS)

開發應用程式移到容器為基礎的方法,來協調和管理資源的需求很重要。As application development moves towards a container-based approach, the need to orchestrate and manage resources is important. Kubernetes 是領先的平台,可用來提供容錯應用程式工作負載的可靠排程。Kubernetes is the leading platform that provides the ability to provide reliable scheduling of fault-tolerant application workloads. Azure Kubernetes Service (AKS) 是受管理的 Kubernetes 供應項目,可進一步簡化容器型應用程式的部署和管理。Azure Kubernetes Service (AKS) is a managed Kubernetes offering that further simplifies container-based application deployment and management.

本文介紹核心 Kubernetes 基礎結構元件,例如叢集主機節點節點集區This article introduces the core Kubernetes infrastructure components such as the cluster master, nodes, and node pools. 此外也介紹 Pod部署集合等工作負載資源,並說明如何將資源分組到命名空間中。Workload resources such as pods, deployments, and sets are also introduced, along with how to group resources into namespaces.

什麼是 Kubernetes?What is Kubernetes?

Kubernetes 是一個快速發展中的平台,可管理容器型應用程式及其相關聯的網路和儲存體元件。Kubernetes is a rapidly evolving platform that manages container-based applications and their associated networking and storage components. 重點在於應用程式工作負載,而不是基礎結構元件。The focus is on the application workloads, not the underlying infrastructure components. Kubernetes 提供宣告式部署方法,並以一組完善的 API 管理作業,作為此部署方法的後盾。Kubernetes provides a declarative approach to deployments, backed by a robust set of APIs for management operations.

您可以建置並執行新型、可攜、以微服務為基礎的應用程式,藉由使用 Kubernetes 來協調和管理這些應用程式元件的可用性而獲益。You can build and run modern, portable, microservices-based applications that benefit from Kubernetes orchestrating and managing the availability of those application components. 隨著小組採用以微服務為基礎的應用程式而獲得進展,Kubernetes 對於無狀態與具狀態的應用程式均提供支援。Kubernetes supports both stateless and stateful applications as teams progress through the adoption of microservices-based applications.

Kubernetes 屬於開放式平台,可讓您使用慣用的程式設計語言、作業系統、程式庫或訊息匯流排來建置您的應用程式。As an open platform, Kubernetes allows you to build your applications with your preferred programming language, OS, libraries, or messaging bus. 現有的持續整合與持續傳遞 (CI/CD) 工具可與 Kubernetes 整合,以排程及部署發行。Existing continuous integration and continuous delivery (CI/CD) tools can integrate with Kubernetes to schedule and deploy releases.

Azure Kubernetes Service (AKS) 提供受控 Kubernetes 服務,可降低部署和核心管理工作的複雜度,包括協調升級。Azure Kubernetes Service (AKS) provides a managed Kubernetes service that reduces the complexity for deployment and core management tasks, including coordinating upgrades. AKS 叢集主機由 Azure 平台所管理,且您只需針對執行應用程式的 AKS 節點付費。The AKS cluster masters are managed by the Azure platform, and you only pay for the AKS nodes that run your applications. AKS 會以開放原始碼 Azure Kubernetes Service 引擎為基礎 (aks 引擎)。AKS is built on top of the open-source Azure Kubernetes Service Engine (aks-engine).

Kubernetes 叢集架構Kubernetes cluster architecture

Kubernetes 叢集分成兩個元件:A Kubernetes cluster is divided into two components:

  • 叢集主機節點提供核心 Kubernetes 服務和應用程式工作負載的協調流程。Cluster master nodes provide the core Kubernetes services and orchestration of application workloads.
  • 節點會執行您的應用程式工作負載。Nodes run your application workloads.

Kubernetes 叢集主機和節點元件

叢集主機Cluster master

當您建立 AKS 叢集時,就會自動建立並設定叢集主機。When you create an AKS cluster, a cluster master is automatically created and configured. 此叢集主機會以受控 Azure 資源的形式提供,使用者無需加以管理。This cluster master is provided as a managed Azure resource abstracted from the user. 沒有任何成本,讓叢集主機,只有屬於 AKS 叢集中的節點。There's no cost for the cluster master, only the nodes that are part of the AKS cluster.

叢集主機包含下列核心 Kubernetes 元件:The cluster master includes the following core Kubernetes components:

  • kube-apiserver - API 伺服器是基礎 Kubernetes API 得以公開的途徑。kube-apiserver - The API server is how the underlying Kubernetes APIs are exposed. 此元件可提供管理工具的互動,例如 kubectl 或 Kubernetes 儀表板。This component provides the interaction for management tools, such as kubectl or the Kubernetes dashboard.
  • etcd - 具有高可用性的 etcd 是 Kubernetes 中的金鑰值存放區,用以維護 Kubernetes 叢集和設定的狀態。etcd - To maintain the state of your Kubernetes cluster and configuration, the highly available etcd is a key value store within Kubernetes.
  • kube-scheduler - 當您建立或調整應用程式時,排程器會判斷哪些節點可執行工作負載,並加以啟動。kube-scheduler - When you create or scale applications, the Scheduler determines what nodes can run the workload and starts them.
  • kube-controller-manager - 控制器管理員會監看較小型的,這些控制器負責執行複寫 Pod 和處理節點作業之類的動作。kube-controller-manager - The Controller Manager oversees a number of smaller Controllers that perform actions such as replicating pods and handling node operations.

AKS 提供具有專用 API 伺服器、排程器等項目的單一租用戶叢集主機。您可以定義節點的數目和大小,而 Azure 平台會設定叢集主機與節點之間的安全通訊。AKS provides a single-tenant cluster master, with a dedicated API server, Scheduler, etc. You define the number and size of the nodes, and the Azure platform configures the secure communication between the cluster master and nodes. 與叢集主機之間的互動可透過 Kubernetes API 進行,例如 kubectl 或 Kubernetes 儀表板。Interaction with the cluster master occurs through Kubernetes APIs, such as kubectl or the Kubernetes dashboard.

此受管理的叢集主機可讓您表示您不需要設定元件,例如高可用性etcd存放區,但這也表示您無法直接存取叢集主機。This managed cluster master means that you don't need to configure components like a highly available etcd store, but it also means that you can't access the cluster master directly. Kubernetes 的升級可透過 Azure CLI 或 Azure 入口網站來協調,其程序會先升級叢集主機,再升級節點。Upgrades to Kubernetes are orchestrated through the Azure CLI or Azure portal, which upgrades the cluster master and then the nodes. 若要對可能的問題進行疑難排解,您可以透過 Azure 監視器記錄檢閱叢集主機記錄。To troubleshoot possible issues, you can review the cluster master logs through Azure Monitor logs.

如果您需要以特定方式設定叢集主機,或需要直接存取權,您可以部署您的 Kubernetes 叢集使用aks 引擎If you need to configure the cluster master in a particular way or need direct access to them, you can deploy your own Kubernetes cluster using aks-engine.

如需相關聯的最佳作法,請參閱的叢集安全性與 AKS 中的升級最佳作法For associated best practices, see Best practices for cluster security and upgrades in AKS.

節點和節點集區Nodes and node pools

若要執行應用程式和支援的服務,您必須要有 Kubernetes 節點To run your applications and supporting services, you need a Kubernetes node. AKS 叢集中有一或多個節點,而此類節點是可執行 Kubernetes 節點元件和容器執行階段的 Azure 虛擬機器 (VM):An AKS cluster has one or more nodes, which is an Azure virtual machine (VM) that runs the Kubernetes node components and container runtime:

  • kubelet 是 Kubernetes 代理程式,負責處理來自叢集主機的協調流程要求,和處理相關排程以執行要求的容器。The kubelet is the Kubernetes agent that processes the orchestration requests from the cluster master and scheduling of running the requested containers.
  • 虛擬網路由每個節點上的 kube-proxy 負責處理。Virtual networking is handled by the kube-proxy on each node. Proxy 會路由網路流量,以及管理服務和 Pod 的 IP 定址。The proxy routes network traffic and manages IP addressing for services and pods.
  • 容器執行階段這項元件可讓容器化應用程式執行其他資源並與其互動,例如虛擬網路和儲存體。The container runtime is the component that allows containerized applications to run and interact with additional resources such as the virtual network and storage. 在 AKS,白鯨做為容器執行階段。In AKS, Moby is used as the container runtime.

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

節點的 Azure VM 大小將定義可用的 CPU 數量、記憶體數量,以及儲存體的大小和類型 (例如高效能 SSD 或一般 HDD)。The Azure VM size for your nodes defines how many CPUs, how much memory, and the size and type of storage available (such as high-performance SSD or regular HDD). 如果您預期有應用程式需要大量的 CPU 和記憶體或高效能儲存體,請據以規劃節點大小。If you anticipate a need for applications that require large amounts of CPU and memory or high-performance storage, plan the node size accordingly. 您也可以在 AKS 叢集中相應增加節點數目,以符合需求。You can also scale up the number of nodes in your AKS cluster to meet demand.

在 AKS,叢集中節點的 VM 映像目前依據 Ubuntu Linux 或 Windows Server 2019。In AKS, the VM image for the nodes in your cluster is currently based on Ubuntu Linux or Windows Server 2019. 當您建立 AKS 叢集或相應增加節點數目時,Azure 平台即會依據您要求的數目建立 VM,並加以設定。When you create an AKS cluster or scale up the number of nodes, the Azure platform creates the requested number of VMs and configures them. 沒有為您執行任何手動組態。There's no manual configuration for you to perform. 代理程式節點計費作為標準的虛擬機器,因此您需要的 VM 大小的任何折扣您使用 (包括Azure 保留的項目) 會自動套用。Agent nodes are billed as standard virtual machines, so any discounts you have on the VM size you're using (including Azure reservations) are automatically applied.

如果您需要使用不同的主機 OS,容器執行階段,或包含自訂的套件,您可以部署您的 Kubernetes 叢集使用aks 引擎If you need to use a different host OS, container runtime, or include custom packages, you can deploy your own Kubernetes cluster using aks-engine. 上游 aks-engine 會在功能於 AKS 叢集中正式受到支援之前發行這些功能,並提供設定選項。The upstream aks-engine releases features and provides configuration options before they are officially supported in AKS clusters. 例如,如果您想要使用白鯨以外的容器執行階段,您可以使用aks-engine若要設定及部署 Kubernetes 叢集,以符合您當前的需求。For example, if you wish to use a container runtime other than Moby, you can use aks-engine to configure and deploy a Kubernetes cluster that meets your current needs.

資源保留Resource reservations

您不需要管理每個節點上的核心 Kubernetes 元件,例如 kubelet 、kube-proxy 和 kube-dns ,但它們的確會耗用一些可用的計算資源。You don't need to manage the core Kubernetes components on each node, such as the kubelet, kube-proxy, and kube-dns, but they do consume some of the available compute resources. 為了維持節點的效能與功能,每個節點上都會保留下列計算資源:To maintain node performance and functionality, the following compute resources are reserved on each node:

  • CPU - 60 毫秒CPU - 60 ms
  • 記憶體 - 20%,最多 4 GiBMemory - 20% up to 4 GiB

保留這些資源代表應用程式可用的 CPU 和記憶體數量,看起來可能會小於節點本身所含的資源數量。These reservations mean that the amount of available CPU and memory for your applications may appear less than the node itself contains. 如果由於所執行的應用程式數量導致資源受限,則所保留的這些資源可確保仍有 CPU 和記憶體可供核心 Kubernetes 元件使用。If there are resource constraints due to the number of applications that you run, these reservations ensure CPU and memory remains available for the core Kubernetes components. 無法變更的資源保留項目。The resource reservations can't be changed.

例如:For example:

  • 標準 DS2 v2 節點大小包含 2 個 vCPU 和 7 GiB 記憶體Standard DS2 v2 node size contains 2 vCPU and 7 GiB memory

    • 7 GiB 記憶體的 20% = 1.4 GiB20% of 7 GiB memory = 1.4 GiB
    • 共有 (7 - 1.4) = 5.6 GiB 記憶體可供節點使用A total of (7 - 1.4) = 5.6 GiB memory is available for the node
  • 標準 E4s v3 節點大小包含 4 個 vCPU 和 32 GiB 記憶體Standard E4s v3 node size contains 4 vCPU and 32 GiB memory

    • 32 GiB 記憶體的 20% = 6.4 GiB,但 AKS 最多只會保留 4 GiB20% of 32 GiB memory = 6.4 GiB, but AKS only reserves a maximum of 4 GiB
    • 共有 (32 - 4) = 28 GiB 可供節點使用A total of (32 - 4) = 28 GiB is available for the node

基礎節點 OS 也需要一定數量的 CPU 和記憶體資源,才能完成它自己的核心功能。The underlying node OS also requires some amount of CPU and memory resources to complete its own core functions.

如需相關聯的最佳作法,請參閱AKS 中的基本的排程器功能的最佳做法For associated best practices, see Best practices for basic scheduler features in AKS.

節點集區Node pools

相同設定的節點會一起分組到節點集區中。Nodes of the same configuration are grouped together into node pools. Kubernetes 叢集包含一或多個節點集區。A Kubernetes cluster contains one or more node pools. 您在建立 AKS 叢集時會定義初始的節點數目和大小,而建立預設節點集區The initial number of nodes and size are defined when you create an AKS cluster, which creates a default node pool. AKS 中的這個預設節點集區包含用來執行代理程式節點的基礎 VM。This default node pool in AKS contains the underlying VMs that run your agent nodes. 多個節點的集區支援目前為預覽狀態,AKS 中。Multiple node pool support is currently in preview in AKS.

當您調整或升級 AKS 叢集時,相關動作會對預設節點集區執行。When you scale or upgrade an AKS cluster, the action is performed against the default node pool. 您也可以選擇要調整或升級的特定節點的集區。You can also choose to scale or upgrade a specific node pool. 進行升級作業時,執行中的容器會排程於節點集區中的其他節點上,直到所有節點皆成功升級。For upgrade operations, running containers are scheduled on other nodes in the node pool until all the nodes are successfully upgraded.

如需如何使用 AKS 中的多個節點集區的詳細資訊,請參閱建立及管理在 AKS 叢集中多個節點的集區For more information about how to use multiple node pools in AKS, see Create and manage multiple node pools for a cluster in AKS.

節點選取器Node selectors

在 AKS 叢集中包含多個節點的集區,您可能需要告訴 Kubernetes 排程器的節點集區,使用指定的資源。In an AKS cluster that contains multiple node pools, you may need to tell the Kubernetes Scheduler which node pool to use for a given resource. 例如,輸入控制器不應該執行 Windows Server (目前在 AKS 中的預覽) 的節點上。For example, ingress controllers shouldn't run on Windows Server nodes (currently in preview in AKS). 節點選取器可讓您定義各種不同的參數,例如節點的作業系統、 排程 pod 的所在位置的控制項。Node selectors let you define various parameters, such as the node OS, to control where a pod should be scheduled.

下列基本範例排程 NGINX 執行個體使用的節點選取器在 Linux 節點上 "beta.kubernetes.io/os 」: linux:The following basic example schedules an NGINX instance on a Linux node using the node selector "beta.kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: nginx:1.15.12
  nodeSelector:
    "beta.kubernetes.io/os": linux

如需有關如何控制 pod 排程的所在位置的詳細資訊,請參閱AKS 中的進階排程器功能的最佳做法For more information on how to control where pods are scheduled, see Best practices for advanced scheduler features in AKS.

PodPods

Kubernetes 會使用 Pod 執行您的應用程式執行個體。Kubernetes uses pods to run an instance of your application. 一個 Pod 代表應用程式的單一執行個體。A pod represents a single instance of your application. Pod 與容器之間通常會有 1:1 的對應,不過在進階案例中,Pod 可能會包含多個容器。Pods typically have a 1:1 mapping with a container, although there are advanced scenarios where a pod may contain multiple containers. 這些多容器 Pod 會一起排程於相同的節點上,並允許容器共用相關資源。These multi-container pods are scheduled together on the same node, and allow containers to share related resources.

當您建立 Pod 時,您可以定義資源限制以要求特定數量的 CPU 或記憶體資源。When you create a pod, you can define resource limits to request a certain amount of CPU or memory resources. Kubernetes 排程器會嘗試將 Pod 排程在具有可用資源的節點上執行,以符合要求。The Kubernetes Scheduler tries to schedule the pods to run on a node with available resources to meet the request. 您也可以指定資源上限,以防止指定的 Pod 在基礎節點上耗用太多計算資源。You can also specify maximum resource limits that prevent a given pod from consuming too much compute resource from the underlying node. 最佳做法是為所有 Pod 加上資源限制,以協助 Kubernetes 排程器了解哪些是必要且可供使用的資源。A best practice is to include resource limits for all pods to help the Kubernetes Scheduler understand which resources are needed and permitted.

如需詳細資訊,請參閱 < Kubernetes pod and Kubernetes pod lifecycleFor more information, see Kubernetes pods and Kubernetes pod lifecycle.

Pod 是邏輯資源,但應用程式工作負載執行的所在之處是容器。A pod is a logical resource, but the container(s) are where the application workloads run. Pod 通常是暫時性、可處置的資源,且個別排程的 Pod 會無法獲益於 Kubernetes 所提供的一些高可用性和備援功能。Pods are typically ephemeral, disposable resources, and individually scheduled pods miss some of the high availability and redundancy features Kubernetes provides. 實際上,Pod 通常會由 Kubernetes 控制器部署及管理,例如「部署控制器」。Instead, pods are usually deployed and managed by Kubernetes Controllers, such as the Deployment Controller.

部署和 YAML 資訊清單Deployments and YAML manifests

一項部署可代表一或多個由 Kubernetes 部署控制器管理的相同 Pod。A deployment represents one or more identical pods, managed by the Kubernetes Deployment Controller. 部署會定義要建立的複本 (Pod) 數目,且 Kubernetes 排程器會確保在 Pod 或節點發生問題時可在狀況良好的節點上排程其他 Pod。A deployment defines the number of replicas (pods) to create, and the Kubernetes Scheduler ensures that if pods or nodes encounter problems, additional pods are scheduled on healthy nodes.

您可以更新部署以變更 Pod 的設定、使用的容器映像,或連結的儲存體。You can update deployments to change the configuration of pods, container image used, or attached storage. 部署控制器會清空並終止指定數目的複本、從新的部署定義建立複本,然後繼續進行處理,直到部署中的所有複本皆完成更新。The Deployment Controller drains and terminates a given number of replicas, creates replicas from the new deployment definition, and continues the process until all replicas in the deployment are updated.

AKS 中的多數無狀態應用程式均應使用部署模型,而不是排程個別的 Pod。Most stateless applications in AKS should use the deployment model rather than scheduling individual pods. Kubernetes 可監視部署的健康情況和狀態,以確定有所需數量的複本執行於叢集內。Kubernetes can monitor the health and status of deployments to ensure that the required number of replicas run within the cluster. 當您只會排程個別 pod 時,pod 不重新啟動,如果使用者遇到的問題,並不重新排定 「 狀況良好的節點上如果其目前的節點發生問題。When you only schedule individual pods, the pods aren't restarted if they encounter a problem, and aren't rescheduled on healthy nodes if their current node encounters a problem.

如果應用程式需要執行個體仲裁以便隨時可供管理決策擬定之用,您就不應讓更新程序中斷該項功能。If an application requires a quorum of instances to always be available for management decisions to be made, you don't want an update process to disrupt that ability. 您可以使用 Pod 中斷預算,定義在更新或節點升級期間可在部署中停止多少個複本。Pod Disruption Budgets can be used to define how many replicas in a deployment can be taken down during an update or node upgrade. 例如,如果您的部署中有 5 個複本,您可以將 Pod 中斷定義為 4,而每次僅允許一個複本不受刪除/重新排程。For example, if you have 5 replicas in your deployment, you can define a pod disruption of 4 to only permit one replica from being deleted/rescheduled at a time. 與 Pod 資源限制相同,最佳做法是為需要有最少量複本持續存在的應用程式定義 Pod 中斷預算。As with pod resource limits, a best practice is to define pod disruption budgets on applications that require a minimum number of replicas to always be present.

部署通常可透過 kubectl createkubectl apply 來建立和管理。Deployments are typically created and managed with kubectl create or kubectl apply. 若要建立部署,您可以定義 YAML (YAML 不是標記語言) 格式的資訊清單檔。To create a deployment, you define a manifest file in the YAML (YAML Ain't Markup Language) format. 下列範例會建立 NGINX Web 伺服器的基本部署。The following example creates a basic deployment of the NGINX web server. 此部署會指定要建立 3 個複本,並開啟容器上的連接埠 80The deployment specifies 3 replicas to be created, and that port 80 be open on the container. 此外也會定義 CPU 和記憶體的資源要求和限制。Resource requests and limits are also defined for CPU and memory.

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: nginx:1.15.2
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

您也可以在 YAML 資訊清單中納入負載平衡器之類的服務,以建立更複雜的應用程式。More complex applications can be created by also including services such as load balancers within the YAML manifest.

如需詳細資訊,請參閱 < Kubernetes 部署For more information, see Kubernetes deployments.

使用 Helm 管理套件Package management with Helm

管理應用程式在 Kubernetes 中的常見方法是使用HelmA common approach to managing applications in Kubernetes is with Helm. 您可以建置和使用現有的公用 Helm 圖表,其中包含封裝版的應用程式程式碼,和用來部署資源的 Kubernetes YAML 資訊清單。You can build and use existing public Helm charts that contain a packaged version of application code and Kubernetes YAML manifests to deploy resources. 這些 Helm 圖表可以儲存在本機,或通常在遠端儲存機制,例如Azure 容器登錄的 Helm 圖表存放庫These Helm charts can be stored locally, or often in a remote repository, such as an Azure Container Registry Helm chart repo.

若要使用 Helm,請在您的 Kubernetes 叢集中安裝名為 Tiller 的伺服器元件。To use Helm, a server component called Tiller is installed in your Kubernetes cluster. Tiller 會管理安裝在叢集內的圖表。The Tiller manages the installation of charts within the cluster. Helm 用戶端本身安裝在本機電腦上,或可用於Azure Cloud ShellThe Helm client itself is installed locally on your computer, or can be used within the Azure Cloud Shell. 您可以使用用戶端搜尋或建立 Helm 圖表,然後將其安裝至 Kubernetes 叢集。You can search for or create Helm charts with the client, and then install them to your Kubernetes cluster.

Helm 包含可在 Kubernetes 叢集內建立資源的用戶端元件和伺服器端 Tiller 元件

如需詳細資訊,請參閱 < 安裝 Helm Azure Kubernetes Service (AKS) 中具有應用程式For more information, see Install applications with Helm in Azure Kubernetes Service (AKS).

StatefulSet 和 DaemonsetStatefulSets and DaemonSets

部署控制器會使用 Kubernetes 排程器,在任何有可用資源的可用節點上執行指定數量的複本。The Deployment Controller uses the Kubernetes Scheduler to run a given number of replicas on any available node with available resources. 這種部署使用方法可能足以因應無狀態應用程式的需要,但不適用於需要持續性命名慣例或儲存體的應用程式。This approach of using deployments may be sufficient for stateless applications, but not for applications that require a persistent naming convention or storage. 對於需要有複本存在於叢集內各個節點 (或選取的節點) 上的應用程式,部署控制器並不會考量複本分散到各節點間的方式。For applications that require a replica to exist on each node, or selected nodes, within a cluster, the Deployment Controller doesn't look at how replicas are distributed across the nodes.

有兩項 Kubernetes 資源可讓您管理此類型的應用程式:There are two Kubernetes resources that let you manage these types of applications:

  • StatefulSet - 跨個別 Pod 生命週期維護應用程式的狀態,例如儲存體。StatefulSets - Maintain the state of applications beyond an individual pod lifecycle, such as storage.
  • Daemonset - 及早在 Kubernetes 啟動程序執行時確定每個節點都有執行中的執行個體。DaemonSets - Ensure a running instance on each node, early in the Kubernetes bootstrap process.

StatefulSetStatefulSets

現今的應用程式開發通常以無狀態應用程式為目標,但 StatefulSet 可用於具狀態的應用程式,例如包含資料庫元件的應用程式。Modern application development often aims for stateless applications, but StatefulSets can be used for stateful applications, such as applications that include database components. StatefulSet 類似於會建立和管理一或多個相同 Pod 的部署。A StatefulSet is similar to a deployment in that one or more identical pods are created and managed. StatefulSet 中的複本會依照正常、循序的方法進行部署、調整、升級和終止。Replicas in a StatefulSet follow a graceful, sequential approach to deployment, scale, upgrades, and terminations. 透過 StatefulSet,命名慣例、網路名稱和儲存體在複本重新排程後仍可持續保存。With a StatefulSet, the naming convention, network names, and storage persist as replicas are rescheduled.

您可以使用 kind: StatefulSet 定義 YAML 格式的應用程式,隨後再由 StatefulSet 控制器處理必要複本的部署和管理。You define the application in YAML format using kind: StatefulSet, and the StatefulSet Controller then handles the deployment and management of the required replicas. 資料會寫入至 Azure 受控磁碟或 Azure 檔案所提供的永續性儲存體。Data is written to persistent storage, provided by Azure Managed Disks or Azure Files. 透過 StatefulSet,即使在 StatefulSet 刪除後,基礎的永續性儲存體仍將保存。With StatefulSets, the underlying persistent storage remains even when the StatefulSet is deleted.

如需詳細資訊,請參閱 < Kubernetes StatefulSetsFor more information, see Kubernetes StatefulSets.

StatefulSet 中的複本可在 AKS 叢集中任何可用的節點上排程及執行。Replicas in a StatefulSet are scheduled and run across any available node in an AKS cluster. 如果您必須確定每個節點都至少要執行您集合中的一個 Pod,您可以改用 DaemonSet。If you need to ensure that at least one pod in your Set runs on a node, you can instead use a DaemonSet.

DaemonSetDaemonSets

針對特定的記錄收集或監視需求,您可能需要在所有或選取的節點上執行指定的 Pod。For specific log collection or monitoring needs, you may need to run a given pod on all, or selected, nodes. DaemonSet 同樣可用來部署一或多個相同的 Pod,但 DaemonSet 控制器可確保每個指定的節點都會執行一個 Pod 執行個體。A DaemonSet is again used to deploy one or more identical pods, but the DaemonSet Controller ensures that each node specified runs an instance of the pod.

DaemonSet 控制器可及早在叢集啟動程序執行時,在預設 Kubernetes 排程器啟動之前將 Pod 排程於節點上。The DaemonSet Controller can schedule pods on nodes early in the cluster boot process, before the default Kubernetes scheduler has started. 這項功能可確保 DaemonSet 中的 Pod 會在部署或 StatefulSet 中的傳統 Pod 排程之前啟動。This ability ensures that the pods in a DaemonSet are started before traditional pods in a Deployment or StatefulSet are scheduled.

和 StatefulSet 相同,DaemonSet 也可使用 kind: DaemonSet 定義為 YAML 定義的一部分。Like StatefulSets, a DaemonSet is defined as part of a YAML definition using kind: DaemonSet.

如需詳細資訊,請參閱 < Kubernetes DaemonsetFor more information, see Kubernetes DaemonSets.

注意

如果使用虛擬節點附加元件,Daemonset 不會建立在虛擬節點上的 pod。If using the Virtual Nodes add-on, DaemonSets will not create pods on the virtual node.

命名空間Namespaces

Kubernetes 資源 (例如 Pod 和部署) 會依邏輯分組到命名空間中。Kubernetes resources, such as pods and Deployments, are logically grouped into a namespace. 藉由這樣的分組,即可依邏輯區隔 AKS 叢集,並限制建立、檢視或管理資源的存取權。These groupings provide a way to logically divide an AKS cluster and restrict access to create, view, or manage resources. 例如,您可以建立命名空間以區隔商務群組。You can create namespaces to separate business groups, for example. 使用者只能與其指派的命名空間內包含的資源互動。Users can only interact with resources within their assigned namespaces.

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

您在建立 AKS 叢集時,可以使用下列命名空間:When you create an AKS cluster, the following namespaces are available:

  • default - 此命名空間是在未提供任何 Pod 和部署時依預設用來建立這些項目的位置。default - This namespace is where pods and deployments are created by default when none is provided. 在較小的環境中,您可以直接將應用程式部署到預設命名空間中,而無須建立額外的邏輯分隔。In smaller environments, you can deploy applications directly into the default namespace without creating additional logical separations. 當您與 Kubernetes API 互動時 (例如 kubectl get pods),若未指定命名空間,將會使用預設值。When you interact with the Kubernetes API, such as with kubectl get pods, the default namespace is used when none is specified.
  • kube-system - 此命名空間是核心資源的所在之處,例如 DNS 和 Proxy 之類的網路功能,或是 Kubernetes 儀表板。kube-system - This namespace is where core resources exist, such as network features like DNS and proxy, or the Kubernetes dashboard. 您通常不會將自己的應用程式部署到此命名空間中。You typically don't deploy your own applications into this namespace.
  • kube-public - 此命名空間通常不會使用,但可用於要在整個叢集中顯示,並且可供任何使用者檢視的資源。kube-public - This namespace is typically not used, but can be used for resources to be visible across the whole cluster, and can be viewed by any user.

如需詳細資訊,請參閱 < Kubernetes 命名空間For more information, see Kubernetes namespaces.

後續步驟Next steps

本文說明了部分核心 Kubernetes 元件,及其套用至 AKS 叢集的方式。This article covers some of the core Kubernetes components and how they apply to AKS clusters. 如需關於 Kubernetes 及 AKS 核心概念的詳細資訊,請參閱下列文章:For additional information on core Kubernetes and AKS concepts, see the following articles: