Azure Stack HCI 上的 Azure Kubernetes 服务的 Kubernetes 核心概念Kubernetes core concepts for Azure Kubernetes Service on Azure Stack HCI

Azure Stack HCI 上的 Azure Kubernetes 服务是由 Azure Stack HCI 提供支持的企业级 Kubernetes 容器平台。Azure Kubernetes Service on Azure Stack HCI is an enterprise-grade Kubernetes container platform powered by Azure Stack HCI. 它包括 Microsoft 支持的核心 Kubernetes、附加产品、专门构建的 Windows 容器主机和 Microsoft 支持的 Linux 容器主机,其目标是提供简单的部署和生命周期管理体验 **** 。It includes Microsoft supported core Kubernetes, add-ons, a purpose-built Windows container host and a Microsoft-supported Linux container host with a goal to have a simple deployment and life cycle management experience.

本文介绍了 Kubernetes 核心基础结构组件,例如控制平面、节点和节点池 。This article introduces the core Kubernetes infrastructure components such as the control plane, 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 群集体系结构Kubernetes cluster architecture

Kubernetes 是 Azure Stack HCI 上的 Azure Kubernetes 服务的核心组件。Kubernetes is the core component of the Azure Kubernetes Service on Azure Stack HCI. Azure Stack HCI 上的 Azure Kubernetes 服务使用一组预定义配置有效地部署 Kubernetes 群集,并考虑可伸缩性。Azure Kubernetes Service on Azure Stack HCI uses a set of predefined configurations to deploy Kubernetes cluster(s) effectively and with scalability in mind.

部署操作会创建多个 Linux 或 Windows 虚拟机,并将这些虚拟机一起加入以创建 Kubernetes 群集。The deployment operation will create multiple Linux or Windows virtual machines and join these together to create Kubernetes cluster(s).

部署的系统已准备好接收标准 Kubernetes 工作负载、缩放这些工作负载,甚至是根据需要纵向扩展和缩减虚拟机数量和群集数量。The deployed system is ready to receive standard Kubernetes workloads, scale these workloads, or even scale the number of virtual machines as well as the number of clusters up and down as needed.

在 Azure Stack HCI 上,Azure Kubernetes 服务群集划分为两个主要组件:An Azure Kubernetes Service cluster is divided into two main components on Azure Stack HCI:

  • 管理群集提供用于部署和管理一个或多个目标群集的核心业务流程机制和接口。Management cluster provides the the core orchestration mechanism and interface for deploying and managing one or more target clusters.
  • 目标群集(也称为工作负载群集)是应用程序工作负载运行并由管理群集进行管理的位置。Target clusters (also known as workload clusters) are where application workloads run and are managed by a management cluster.

说明 Azure Stack HCI 上的 Azure Kubernetes 服务的技术体系结构

管理群集Management cluster

创建 Azure Stack HCI 上的 Azure Kubernetes 服务群集时,会自动创建和配置管理群集。When you create an Azure Kubernetes Service cluster on Azure Stack HCI, a management cluster is automatically created and configured. 此管理群集负责预配和管理工作负载在其中运行的目标群集。This management cluster is responsible for provisioning and managing target clusters where workloads run. 管理群集包括以下核心 Kubernetes 组件:A management cluster includes the following core Kubernetes components:

  • API 服务器 - API 服务器是公开基础 Kubernetes API 的方式。API Server - The API server is how the underlying Kubernetes APIs are exposed. 此组件为管理工具(如 Windows Admin Center、PowerShell 模块或 kubectl)提供交互。This component provides the interaction for management tools such as Windows Admin Center, PowerShell modules, or kubectl.
  • 负载均衡器 - 负载均衡器是单个专用 Linux VM,具有用于管理群集 API 服务器的负载均衡规则。Load Balancer - The load balancer is a single dedicated Linux VM with a load balancing rule for the API server of the management cluster.

Windows Admin CenterWindows Admin Center

Windows Admin Center 为 Kubernetes 操作员提供直观的 UI,以管理 Azure Stack HCI 上的 Azure Kubernetes 服务群集的生命周期。Windows Admin Center offers an intuitive UI for the Kubernetes operator to manage the lifecycle of Azure Kubernetes Service clusters on Azure Stack HCI.

PowerShell 模块PowerShell module

PowerShell 模块是下载、配置和部署 Azure Stack HCI 上的 Azure Kubernetes 服务的一种简单方法。The PowerShell module is an easy way to download, configure and deploy Azure Kubernetes Service on Azure Stack HCI. PowerShell 模块还支持部署和配置其他目标群集,以及重新配置现有目标群集。The PowerShell module also supports deploying and configuring additional target clusters as well as reconfiguring existing ones.

目标群集Target cluster

目标(工作负载)群集是 Kubernetes 的高度可用部署,使用 Linux VM 运行 Kubernetes 控制平面组件以及 Linux 工作器节点。The target (workload) cluster is a highly available deployment of Kubernetes using Linux VMs for running Kubernetes control plane components as well as Linux worker nodes. 基于 Windows Server Core 的 VM 用于建立 Windows 工作器节点。Windows Server Core based VMs are used for establishing Windows worker nodes. 一个管理群集可以管理一个或多个目标群集。There can be one or more target cluster(s) managed by one management cluster.

辅助角色节点Worker nodes

要运行应用程序和支持服务,需要 Kubernetes 节点。To run your applications and supporting services, you need a Kubernetes node. Azure Stack HCI 上的 Azure Kubernetes 服务目标群集具有一个或多个工作器节点,这是运行 Kubernetes 节点组件的虚拟机 (VM),并托管组成应用程序工作负载的 Pod 和服务。An Azure Kubernetes Service target cluster on Azure Stack HCI has one or more worker nodes, which is a virtual machine (VM) that runs the Kubernetes node components, as well as hosting the pods and services that make up the application workload.

负载均衡器Load balancer

负载均衡器是运行 Linux 和 HAProxy + KeepAlive 的虚拟机,用于为管理群集部署的目标群集提供负载均衡服务。The load balancer is a virtual machine running Linux and HAProxy + KeepAlive to provide load balanced services for the target clusters deployed by the management cluster.

对于每个目标群集,Azure Stack HCI 上的 Azure Kubernetes 服务都会至少添加一个负载均衡器虚拟机 (LB VM)。For each target cluster, Azure Kubernetes Service on Azure Stack HCI will add at least one load balancer virtual machines (LB VM). 除此之外,还可以在目标群集上创建其他负载均衡器以实现 API 服务器的高可用性。In addition to this, another load balancer can be created for high availability of the API server on the target cluster. 在目标群集上创建的 LoadBalancer 类型的任何 Kubernetes 服务都会最终在 LB VM 中创建负载均衡规则。Any Kubernetes service of type LoadBalancer that is created on the target cluster will end up creating a load balancing rule in the LB VM.

附加组件Add-On components

可以在任何给定群集中部署多个可选的附加组件,最值得注意的是以下这些:Prometheus、Grafana 或 Kubernetes 仪表板。There are several optional add-on components that can be deployed in any given cluster, most notably: Prometheus, Grafana, or the Kubernetes Dashboard.

Kubernetes 组件Kubernetes components

此部分介绍可在 Azure Stack HCI 上的 Azure Kubernetes 服务目标群集上部署的核心 Kubernetes 工作负载组件(如 Pod、部署和集),以及如何将资源分组为命名空间。This section introduces the core Kubernetes workload components that can be deployed on Azure Kubernetes Service on Azure Stack HCI target clusters such as pods, deployments, and sets, along with how to group resources into namespaces.

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 requests 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 PodKubernetes Pod 生命周期For 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 控制器(例如 Deployment 控制器)进行部署和管理。Instead, pods are deployed and managed by Kubernetes Controllers, such as the Deployment Controller.

部署和 YAML 清单Deployments and YAML manifests

部署表示由 Kubernetes Deployment 控制器管理的一个或多个相同 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. Deployment 控制器耗尽并终止给定数量的副本,从新部署定义创建副本,并继续该过程,直至部署中的所有副本都已更新。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.

大多数无状态应用程序应使用部署模型,而不是计划单个 Pod。Most stateless applications 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) 个副本,则可以定义 4 个 Pod 中断,以便一次只允许删除/重新计划一个副本 。For example, if you have five (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) 个副本,并要求在容器上打开端口 80 。The deployment specifies three (3) replicas to be created, and requires port 80 to 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 also be created by also including services such as load balancers within the YAML manifest.

有关详细信息,请参阅 Kubernetes 部署For more information, see Kubernetes deployments

混合 OS 部署Mixed-OS deployments

如果 Azure Stack HCI 上的 Azure Kubernetes 服务给定目标群集由 Linux 和 Windows 工作器节点组成,则需要将工作负载安排到可支持预配工作负载的 OS 上。If a given Azure Kubernetes Service on Azure Stack HCI target cluster consists of both Linux and Windows worker nodes, workloads need to be scheduled onto an OS that can support provisioning the workload. Kubernetes 提供了两种机制来确保工作负载进入具有目标操作系统的节点:Kubernetes offers two mechanisms to ensure workloads land on nodes with a target operating system:

  • 节点选择器是 Pod 规范中的一个简单字段,可将 Pod 约束为仅安排到与操作系统匹配的正常节点。Node Selector is a simple field in the pod spec that constraints pods to only be scheduled onto healthy nodes matching the operating system.
  • 排斥和容许一起工作,以确保不会无意中将 Pod 安排到节点。Taints and tolerations work together to ensure that pods are not scheduled onto nodes unintentionally. 节点可以“进行排斥”,以便不接受不通过 Pod 规范中的“容许”显式容许其排斥的 Pod。A node can be "tainted" so as to not accept pods that do not explicitly tolerate its taint through a "toleration" in the pod spec.

有关详细信息,请参阅节点选择器以及排斥和容许For more information, see node selectors and taints and tolerations.

StatefulSet 和 DaemonSetStatefulSets and DaemonSets

Deployment 控制器使用 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. 对于群集内需要在每个节点或选定节点上存在副本的应用程序,Deployment 控制器不会查看副本在节点间的分布情况。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 (as replicas are rescheduled) the naming convention, network names, and storage persist.

使用 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. 数据会写入持久存储,即使在删除 StatefulSet 之后,基础存储仍保持不变。Data is written to persistent storage, with the underlying storage persisting even after the StatefulSet is deleted.

有关详细信息,请参阅 Kubernetes StatefulSetFor more information, see Kubernetes StatefulSets.

计划 StatefulSet 中的副本,并在 Azure Stack HCI 上的 Azure Kubernetes 服务群集中的任何可用节点上运行这些副本。Replicas in a StatefulSet are scheduled and run across any available node in an Azure Kubernetes Service on Azure Stack HCI 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.

在默认的 Kubernetes 计划程序启动之前,DaemonSet 控制器可以在群集启动进程的早期计划节点上的 Pod。The DaemonSet Controller can schedule pods on nodes early in the cluster boot process, before the default Kubernetes scheduler has started. 此功能可确保在计划 Deployment 或 StatefulSet 中的传统 Pod 之前启动 DaemonSet 中的 Pod。This ability ensures that the pods in a DaemonSet are started before traditional pods in a Deployment or StatefulSet are scheduled.

与 StatefulSet 一样,系统使用 kind: DaemonSet 将 DaemonSet 定义为 YAML 定义的一部分。Like StatefulSets, a DaemonSet is defined as part of a YAML definition using kind: DaemonSet.

有关详细信息,请参阅 Kubernetes DaemonSetFor more information, see Kubernetes DaemonSets.

命名空间Namespaces

Kubernetes 资源(如 Pod 和部署)以逻辑方式分组到命名空间中。Kubernetes resources, such as pods and Deployments, are logically grouped into a namespace. 这些分组提供了一种以逻辑方式划分 Azure Stack HCI 上的 Azure Kubernetes 服务目标群集并限制创建、查看或管理资源访问权限的方法。These groupings provide a way to logically divide an Azure Kubernetes Service on Azure Stack HCI target 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.

创建 Azure Stack HCI 上的 Azure Kubernetes 服务群集时,可以使用以下命名空间:When you create an Azure Kubernetes Service cluster on Azure Stack HCI, 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 和代理等网络功能或 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.