【Azure容器】选择Kubernetes边缘计算选项

本文档讨论了可用于扩展边缘计算的各种选项的权衡。每个Kubernetes选项都涵盖了以下注意事项：

• 运营成本。维护和操作Kubernetes集群所需的预期劳动力。
• 易于配置。配置和部署Kubernetes集群的难度。
• 灵活性。衡量Kubernetes选项在将定制配置与边缘现有基础设施集成方面的适应性。
• 混合节点。能够使用Linux和Windows节点运行Kubernetes集群。

假设

• 您是一名集群运营商，希望了解在边缘运行Kubernetes和在Azure中管理集群的不同选项。
• 您对现有基础架构和任何其他基础架构要求（包括存储和网络要求）都有很好的了解。

阅读本文档后，您将能够更好地确定哪个选项最适合您的场景和所需的环境。

Kubernetes选择一览

*Other managed edge platforms (OpenShift, Tanzu, and so on) aren't in scope for this document.

**These values are based on using kubeadm, for the sake of simplicity. Different options for running bare-metal Kubernetes at the edge would alter the rating in these categories.

Ground-up configuration of Kubernetes using tools like kubeadm on any underlying infrastructure.

The biggest constraints for bare-metal Kubernetes are around the specific needs and requirements of the organization. The opportunity to use any distribution, networking interface, and plugin means higher complexity and operational cost. But this offers the most flexible option for customizing your cluster.

Often, edge locations have specific requirements for running Kubernetes clusters that aren't met with the other Azure solutions described in this document. Meaning this option is typically best for those unable to use managed services due to unsupported existing infrastructure, or those who seek to have maximum control of their clusters.

• This option can be especially difficult for those who are new to Kubernetes. This isn't uncommon for organizations looking to run edge clusters. Options like MicroK8s or k3s aim to flatten that learning curve.

• It's important to understand any underlying infrastructure and any integration that is expected to take place up front. This will help to narrow down viable options and to identify any gaps with the open-source tooling and/or plugins.

• Enabling clusters with Azure Arc presents a simple way to manage your cluster from Azure alongside other resources. This also brings other Azure capabilities to your cluster, including Azure Policy, Azure Monitor, Microsoft Defender for Cloud, and other services.

• Because cluster configuration isn't trivial, it's especially important to be mindful of CI/CD. Tracking and acting on upstream changes of various plugins, and making sure those changes don't affect the health of your cluster, becomes a direct responsibility. It's important for you to have a strong CI/CD solution, strong testing, and monitoring in place.

Cluster bootstrap:

• kubeadm: Kubernetes tool for creating ground-up Kubernetes clusters. Good for standard compute resources (Linux/Windows).

• MicroK8s: Simplified administration and configuration ("LowOps"), conformant Kubernetes by Canonical.

• k3s: Certified Kubernetes distribution built for Internet of Things (IoT) and edge computing.

Storage:

• Explore available CSI drivers: Many options are available to fit your requirements from cloud to local file shares.

Networking:

• A full list of available add-ons can be found here: Networking add-ons. Some popular options include Flannel, a simple overlay network, and Calico, which provides a full networking stack.

Operational cost:

• Without the support that comes with managed services, it's up to the organization to maintain and operate the cluster as a whole (storage, networking, upgrades, observability, application management). The operational cost is considered high.

Ease of configuration:

• Evaluating the many open-source options at every stage of configuration whether its networking, storage, or monitoring options is inevitable and can become complex. Requires more consideration for configuring a CI/CD for cluster configuration. Because of these concerns, the ease of configuration is considered difficult.

Flexibility:

• With the ability to use any open-source tool or plugin without any provider restrictions, bare-metal Kubernetes is highly flexible.

Kubernetes cluster (a master VM and a worker VM) configured and deployed for you on your Azure Stack Edge Pro device.

Azure Stack Edge Pro devices deliver Azure capabilities like compute, storage, networking, and hardware-accelerated machine learning (ML) to any edge location. Kubernetes clusters can be created once the compute role is enabled on any of the Pro-GPU, Pro-R, and Mini-R devices. Managing upgrades of the Kubernetes cluster can be done using standard updates available for the device.

Ideal for those with existing (Linux) IoT workloads or upgrading their compute for ML at the edge. This is a good option when it isn't necessary to have more granular control over the clusters.

• Admin permissions aren't granted by default. Although you can work with the product group to make certain exceptions, this makes it difficult to have finer control of your cluster.

• There is an extra cost if there isn't already an Azure Stack Edge device. Explore Azure Stack Edge devices and see if any fit your compute requirements.

• Calico, MetalLB, and CoreDNS are installed for Kubernetes networking on the device.

• Only Linux workloads are supported at this time.

• In addition to Kubernetes, Azure Stack Edge also comes with the IoT runtime, which means that workloads may also be deployed to your Azure Stack Edge clusters via IoT Edge.

• Support for two node clusters isn't currently available. This effectively means that this option is not a highly available (HA) solution.

Operational cost:

• With the support that comes with the device, operational cost is minimal and is scoped to workload management.

Ease of configuration:

• Pre-configured and well-documented Kubernetes cluster deployment simplifies the configuration required compared to bare-metal Kubernetes.

Flexibility:

• Configuration is already set, and Admin permissions aren't granted by default. Product group involvement may be required beyond basic configuration, and the underlying infrastructure must be an Azure Stack Edge Pro device, making this a less flexible option.

AKS hybrid is a set of predefined settings and configurations that is used to deploy one or more Kubernetes clusters (with Windows Admin Center or PowerShell modules) on a multi-node cluster running either Windows Server or Azure Stack HCI 20H2 or later.

Ideal for those who want a simplified and streamlined way to get a Microsoft-supported cluster on compatible devices (Azure Stack HCI or Windows Server). Operations and configuration complexity are reduced at the expense of the flexibility when compared to the bare-metal Kubernetes option.

Operational cost:

• Microsoft-supported cluster minimizes operational costs.

Ease of configuration:

• Pre-configured and well-documented Kubernetes cluster deployment simplifies the configuration required compared to bare-metal Kubernetes.

Flexibility:

• Cluster configuration itself is set, but Admin permissions are granted. The underlying infrastructure must either be Azure Stack HCI or Windows Server. 2019. This option is more flexible than Kubernetes on Azure Stack Edge and less flexible than bare-metal Kubernetes.

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal author:

• Prabhjot Kaur | Principal Cloud Solution Architect

To see non-public LinkedIn profiles, sign in to LinkedIn.

For more information, see the following articles:

• What is Azure IoT Edge

• Kubernetes on your Azure Stack Edge Pro GPU device

• Use IoT Edge module to run a Kubernetes stateless application on your Azure Stack Edge Pro GPU device

• Deploy a Kubernetes stateless application via kubectl on your Azure Stack Edge Pro GPU device

• Use Kubernetes dashboard to monitor your Azure Stack Edge Pro GPU device

• Building a CI/CD pipeline for microservices on Kubernetes