Azure Kubernetes 服务 (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 服务 (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 可使用首选的编程语言、OS、库或消息总线生成应用程序。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 服务 (AKS) 提供托管 Kubernetes 服务,可简化部署和核心管理任务,包括协调升级。Azure Kubernetes Service (AKS) provides a managed Kubernetes service that reduces the complexity for deployment and core management tasks, including coordinating upgrades. Azure 平台可托管 AKS 群集主机,你只需为运行应用程序的 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 服务引擎 (aks-engine) 的基础之上。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 - 可维护 Kubernetes 群集和配置的状态,高可用性 etcd 是 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. 通过 Azure CLI 或 Azure 门户安排 Kubernetes 升级,后者先升级群集主机,然后升级节点。Upgrades to Kubernetes are orchestrated through the Azure CLI or Azure portal, which upgrades the cluster master and then the nodes. 要解决可能出现的问题,可以通过 Azure Monitor 日志查看群集主服务器日志。To troubleshoot possible issues, you can review the cluster master logs through Azure Monitor logs.

如果需要以特定方式配置群集主机或直接对其进行访问,可以使用 aks-engine 部署自己的 Kubernetes 群集。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. 代理路由流量并管理服务和 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 中,Moby 用作容器运行时。In AKS, Moby is used as the container runtime.

Azure 虚拟机和 Kubernetes 节点的支持资源

节点的 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。In AKS, the VM image for the nodes in your cluster is currently based on Ubuntu Linux. 创建 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.

如果需要使用不同的主机 OS、容器运行时或包含自定义包,可以使用 aks-engine 部署自己的 Kubernetes 群集。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. 例如,如果要使用 Windows 容器或 Moby 之外的容器运行时,可以使用 aks-engine 来配置和部署满足当前需求的 Kubernetes 群集。For example, if you wish to use Windows containers or 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

AKS 利用节点资源,以使节点作为群集的一部分发挥作用。Node resources are utilized by AKS to make the node function as part of your cluster. 这可能会在节点的总资源数和在 AKS 中使用时可分配的资源数之间产生差异。This can create a discrepency between your node's total resources and the resources allocatable when used in AKS. 在为用户部署的 Pod 设置请求和限制时,必须注意这一点。This is important to note when setting requests and limits for user deployed pods.

若要查找节点的可分配资源,请运行:To find a node's allocatable resources run:

kubectl describe node [NODE_NAME]

为了保持节点性能和功能,AKS 在每个节点上预留资源。To maintain node performance and functionality, resources are reserved on each node by AKS. 随着节点资源的增加,由于需要管理的用户部署的 Pod 数量增加,资源预留也会增加。As a node grows larger in resources, the resource reservation grows due to a higher amount of user deployed pods needing management.

Note

使用 OMS 等附加产品将消耗更多节点资源。Using add-ons such as OMS will consume additional node resources.

  • CPU - 预留的 CPU 取决于节点类型和群集配置,这可能会由于运行其他功能而导致可分配的 CPU 较少CPU - reserved CPU is dependent on node type and cluster configuration which may cause less allocatable CPU due to running additional features
主机上的 CPU 核心数CPU cores on host 11 22 44 88 1616 3232 6464
Kube 预留 (millicore)Kube-reserved (millicores) 6060 100100 140140 180180 260260 420420 740740
  • 内存 - 内存预留遵循渐进式的进度Memory - reservation of memory follows a progressive rate
    • 前 4 GB 内存的 25%25% of the first 4 GB of memory
    • 下一个 4 GB 内存的 20%(最多 8 GB)20% of the next 4 GB of memory (up to 8 GB)
    • 下一个 8 GB 内存的 10%(最多 16 GB)10% of the next 8 GB of memory (up to 16 GB)
    • 下一个 112 GB 内存的 6%(最多 128 GB)6% of the next 112 GB of memory (up to 128 GB)
    • 128 GB 以上任何内存的 2%2% of any memory above 128 GB

这些预留意味着你的应用程序的可用 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.

基础节点 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 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.

Note

为确保群集可靠运行,应在默认节点池中至少运行 2(两)个节点。To ensure your cluster to operate reliably, you should run at least 2 (two) nodes in the default node pool.

缩放或升级 AKS 群集时,将对默认节点池执行操作。When you scale or upgrade an AKS cluster, the action is performed against the default node pool.

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 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 usually 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.

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 个副本,则可以定义 4 个 Pod 中断,以便一次只允许删除/重新计划一个副本 。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 个副本,并在容器上打开端口 80 。The 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: dockerhub.azk8s.cn/library/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. 可以生成和使用包含应用程序代码打包版本和 Kubernetes YAML 清单的现有公共 Helm chart 来部署资源 。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 chart 可以存储在本地,通常也可以存储在远程存储库中,例如 Azure 容器注册表 Helm chart 存储库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 管理群集中 chart 的安装。The Tiller manages the installation of charts within the cluster. Helm 客户端本身安装在本地计算机上,也可以在 Azure 本地 Shell 中使用。The Helm client itself is installed locally on your computer, or can be used within the Azure local Shell. 可以使用客户端搜索或创建 Helm chart,然后将其安装到 Kubernetes 群集。You can search for or create Helm charts with the client, and then install them to your Kubernetes cluster.

Helm 包括客户端组件和服务器端 Tiller 组件,用于在 Kubernetes 群集内创建资源

有关详细信息,请参阅在 Azure Kubernetes 服务 (AKS) 中使用 Helm 安装应用程序For more information, see Install applications with Helm in Azure Kubernetes Service (AKS).

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, 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 StatefulSetFor 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.

在默认的 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. 这些分组提供了一种以逻辑方式划分 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 和代理等网络功能或 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: