Непрерывность бизнес-процессов и аварийное восстановление для службы Kubernetes Azure в масштабах предприятияEnterprise-scale business continuity and disaster recovery for Azure Kubernetes Service

Организация должна разрабатывать подходящие возможности уровня платформы Azure Kubernetes Service (AKS) для удовлетворения своих конкретных требований.Your organization needs to design suitable Azure Kubernetes Service (AKS) platform-level capabilities to meet its specific requirements. Эти службы приложений имеют требования, связанные с целевым временем восстановления (RTO) и целевой точкой восстановления (RPO).These application services have requirements related to recovery time objective (RTO) and recovery point objective (RPO). Существует несколько рекомендаций по устранению аварийного восстановления AKS.There are multiple considerations to address for AKS disaster recovery. Первым шагом является определение соглашения об уровне обслуживания (SLA) для инфраструктуры и приложения.Your first step is to define a service-level agreement (SLA) for your infrastructure and application. Узнайте о соглашении об уровне обслуживания для службы Azure Kubernetes (AKS).Learn about the SLA for Azure Kubernetes Service (AKS). Сведения о вычислении месячного времени работы см. в разделе сведения об уровне обслуживания .See the SLA details section for information about monthly uptime calculations.

Рекомендации по проектированиюDesign considerations

Примите во внимание следующие факторы.Consider the following factors:

  • Кластер AKS должен использовать несколько узлов в пуле узлов, чтобы обеспечить минимальный уровень доступности приложения.The AKS cluster should use multiple nodes in a node pool to provide the minimum level of availability for your application.

  • Установка запросов и ограничений Pod.Set pod requests and limits. Установка этих ограничений позволяет Kubernetes:Setting these limits lets Kubernetes:

    • Эффективное предоставление ресурсов ЦП и памяти для модулей Pod.Efficiently give CPU and memory resources to the pods.

    • Более высокая плотность контейнеров на узле.Have higher container density on a node.

    Ограничения также могут повысить надежность благодаря снижению затрат из-за более эффективного использования оборудования.Limits can also increase reliability with reduced costs because of better use of hardware.

  • Пригодность AKS для зоны доступности или групп доступности.AKS suitability for Availability Zones or availability sets.

    • Выберите регион с поддержкой зон доступности.Choose a region that supports Availability Zones.

    • Зоны доступности можно задать только при создании пула узлов и последующего изменения.Availability Zones can only be set when the node pool is created and can't be changed later. Поддержка многозоны применяется только к пулам узлов.Multizone support only applies to node pools.

    • Для полного преимущества зональные все зависимости службы также должны поддерживать зоны.For complete zonal benefit, all service dependencies must also support zones. Если зависимая служба не поддерживает зоны, возможно, сбой зоны приведет к сбою этой службы.If a dependent service doesn't support zones, it's possible that a zone failure could cause that service to fail.

    • Чтобы получить более высокий уровень доступности, чем Зоны доступности может достичь, запустите несколько кластеров AKS в разных парных регионах.For higher availability beyond what Availability Zones can achieve, run multiple AKS clusters in different paired regions. Если ресурс Azure поддерживает геоизбыточность, укажите расположение, в котором у избыточной службы будет свой дополнительный регион.If an Azure resource supports geo-redundancy, provide the location where the redundant service will have its secondary region.

  • Следует иметь в виду рекомендации по аварийному восстановлению в AKS.You should be aware of guidelines for disaster recovery in AKS. Затем определите, применяются ли они к кластерам AKS, которые используются для Azure Dev Spaces.Then consider whether they apply to the AKS clusters that you use for Azure Dev Spaces.

  • Согласованно создавайте резервные копии приложений и данных.Consistently create backups for applications and data.

    • Службу без отслеживания состояния можно эффективно реплицировать.A non-stateful service can be replicated efficiently.

    • Если необходимо сохранить состояние в кластере (не рекомендуется), убедитесь, что вы регулярно создаете резервные копии данных в парном регионе.If you need to store state in the cluster (not recommended), make sure you back up the data frequently in the paired region.

  • Обновление и обслуживание кластера.Cluster update and maintenance.

    • Всегда обновляйте кластер.Always keep your cluster up to date.

    • Помните о процессе выпуска и устаревания.Be aware of the release and deprecation process.

    • Планируйте обновления и обслуживание заранее.Plan your updates and maintenance in advance.

  • Сетевое подключение, если происходит отработка отказа.Network connectivity if a failover occurs.

    • Выберите маршрутизатор трафика, который может распределять трафик между зонами или регионами в зависимости от требований.Choose a traffic router that can distribute traffic across zones or regions, depending on your requirement. Эта архитектура развертывает Azure Load Balancer , так как она может распределять трафик между зонами без веб-сайта.This architecture deploys Azure Load Balancer because it can distribute non-web traffic across zones.

    • Если вам нужно распределить трафик между регионами, попробуйте использовать переднюю дверцу Azure.If you need to distribute traffic across regions, consider using Azure Front Door.

  • Запланированные и незапланированные отработки отказа.Planned and unplanned failovers.

    • При настройке каждой службы Azure выберите компоненты, поддерживающие аварийное восстановление.When setting up each Azure service, choose features that support disaster recovery. Например, в этой архитектуре включите Реестр контейнеров Azure для георепликации.For example, in this architecture, enable Azure Container Registry for geo-replication. Если регион выходит из строя, вы по-прежнему можете получать изображения из реплицированной области.If a region goes down, you can still pull images from the replicated region.
  • Настройте возможности инженерного DevOpsа для достижения целей уровня обслуживания.Maintain engineering DevOps capabilities to reach service level goals.

  • Определите, требуется ли соглашение об уровне обслуживания с финансовыми обязательствами для конечной точки сервера API Kubernetes.Determine whether you need a financially backed SLA for your Kubernetes API server endpoint.

Рекомендации по проектированиюDesign recommendations

Ниже приведены рекомендации по проектированию.The following are best practices for your design:

  • Используйте три узла для пула системных узлов.Use three nodes for the system node pool. Для пула узлов пользователей Начните с не менее двух узлов.For the user node pool, start with no less than two nodes. Если требуется более высокая доступность, настройте дополнительные узлы.If you need higher availability, set up more nodes.

  • Изолируйте приложение от системных служб, поместив его в отдельный пул узлов.Isolate your application from the system services by placing it in a separate node pool. Таким образом, службы Kubernetes работают на выделенных узлах и не конкурируют с другими службами.This way, Kubernetes services run on dedicated nodes and don't compete with other services. Используйте теги, метки и таинтс для обозначения пула узлов, чтобы запланировать рабочую нагрузку.Use tags, labels, and taints to identify the node pool to schedule your workload.

  • Регулярное отслеживание кластера, например обеспечение своевременных обновлений, является критически важным для надежности.Regular upkeep of your cluster like making timely updates is crucial for reliability. Учитывать поддерживаемое окно Kubernetes версий на AKS и планируйте обновления заранее.Be mindful of supported window of Kubernetes versions on AKS and plan your updates in advance. Кроме того, рекомендуется отслеживать работоспособность модулей Pod с помощью проб.Also, monitoring the health of the pods through probes is recommended.

  • По возможности удаляйте состояние службы из контейнеров внутри.Whenever possible, remove service state from inside containers. Вместо этого используйте платформу Azure как службу (PaaS), которая поддерживает репликацию по регионам.Instead, use an Azure platform as a service (PaaS) that supports multiregion replication.

  • Обеспечьте доступность ресурсов Pod.Ensure pod resources. Настоятельно рекомендуется, чтобы в развертываниях были указаны требования к ресурсам Pod.It's highly recommended that deployments specify pod resource requirements. Затем планировщик может соответствующим образом спланировать модуль.The scheduler can then appropriately schedule the pod. Надежность значительно снижается, если не планируется выполнение модулей Pod.Reliability depreciates significantly when pods aren't scheduled.

  • Настройте несколько реплик в развертывании, чтобы обрабатывались нарушения, такие как сбои оборудования.Set up multiple replicas in the deployment to handle disruptions like hardware failures. Для запланированных событий, таких как обновления и обновления, бюджет на прерывание может обеспечить наличие необходимого количества реплик Pod для выполнения ожидаемой загрузки приложения.For planned events like updates and upgrades, a disruption budget can ensure the required number of pod replicas exist to handle expected application load.

  • Приложения могут использовать службу хранилища Azure для своих данных.Your applications might use Azure Storage for their data. Так как приложения распределены между несколькими кластерами AKS в разных регионах, необходимо синхронизировать хранилище.Because your applications are spread across multiple AKS clusters in different regions, you need to keep the storage synced. Ниже приведены два распространенных способа репликации хранилища.Here are two common ways to replicate storage:

    • Асинхронная репликация на основе инфраструктурыInfrastructure-based asynchronous replication

    • асинхронная репликация на основе приложений;Application-based asynchronous replication

  • Оценка ограничений Pod.Estimate pod limits. Тестирование и создание базовых показателей.Test and establish a baseline. Начните с одинаковых значений для запросов и ограничений.Start with equal values for requests and limits. Затем постепенно Настраивайте эти значения до тех пор, пока не будет установлен порог, который может привести к нестабильной работе кластера.Then, gradually tune those values until you've established a threshold that can cause instability in the cluster. Ограничения Pod можно указать в манифестах развертывания.Pod limits can be specified in your deployment manifests.

    Встроенные функции предоставляют решение сложной задачи по обработке сбоев и нарушений в архитектуре службы.The built-in features provide a solution to the complex task of handling failures and disruptions in service architecture. Эти конфигурации помогают упростить разработку и автоматизацию развертывания.These configurations help to simplify both design and deployment automation. Если в организации определен стандарт для соглашений об уровне обслуживания, RTO и RPO, он может использовать встроенные службы для Kubernetes и Azure, чтобы достичь своих бизнес-целей.When an organization has defined a standard for the SLA, RTO, and RPO, it can use built-in services to Kubernetes and Azure to achieve its business goals.

  • Установка бюджетов прерываний Pod.Set pod disruption budgets. Этот параметр проверяет количество реплик в развертывании, которые можно выполнить во время обновления или обновления.This setting checks how many replicas in a deployment you can take down during an update or upgrade event.

  • Принудительное использование квот ресурсов для пространств имен службы.Enforce resource quotas on the service namespaces. Квота ресурсов в пространстве имен обеспечит правильную установку запросов и ограничений на ресурсы Pod в развертывании.The resource quota on a namespace will ensure pod requests and limits are properly set on a deployment.

    • Установка квот ресурсов на уровне кластера может вызвать проблемы при развертывании партнерских служб, у которых нет соответствующих запросов и ограничений.Setting resources quotas at the cluster level can cause problems when deploying partner services that don't have proper requests and limits.
  • Регулярно запускайте последнюю версию средства с kube-advisor открытым исходным кодом для обнаружения проблем в кластере.Regularly run the latest version of the kube-advisor open-source tool to detect issues in your cluster.

  • Храните образы контейнеров в реестре контейнеров Azure и Георепликация реестра в каждом регионе AKS.Store your container images in Azure Container Registry and geo-replicate the registry to each AKS region.

  • AKS можно использовать в качестве бесплатной службы, но этот уровень не предлагает соглашение об уровне обслуживания с финансовыми обязательствами.AKS can be used as a free service, but that tier doesn't offer a financially backed SLA. Чтобы получить это соглашение об уровне обслуживания, необходимо добавить соглашение об уровне обслуживания времени работы в то, что вы покупаете.To get that SLA, you have to add an uptime SLA to what you buy. Мы рекомендуем использовать этот параметр для всех рабочих кластеров.We recommend all production clusters use this option. Резервирование кластеров без этого параметра для подготовительных кластеров.Reserve clusters without this option for pre-production clusters. При объединении с Зоны доступности уровень соглашения об уровне обслуживания Kubernetes API увеличивается до 99,95%.When combined with Availability Zones, the Kubernetes API server SLA is increased to 99.95%. Пулы узлов и другие ресурсы попадают под свои соглашения об уровне обслуживания.Your node pools, and other resources are covered under their own SLA.

  • Используйте несколько регионов и расположений пиринга для подключения ExpressRoute .Use multiple regions and peering locations for ExpressRoute connectivity.

    При возникновении сбоя, влияющего на расположение региона Azure или поставщика пиринга, избыточная Гибридная архитектура сети поможет обеспечить непрерывное подключение между организациями.If an outage affecting an Azure region or peering provider location occurs, a redundant hybrid network architecture can help ensure uninterrupted cross-premises connectivity.

  • Области Interconnect с глобальным пирингом виртуальной сети.Interconnect regions with global virtual network peering. Если кластеры должны взаимодействовать друг с другом, подключение между виртуальными сетями может осуществляться через пиринг виртуальных сетей.If the clusters need to talk to each other, connecting both virtual networks to each other can be achieved through virtual network peering. Эта технология соединяет виртуальные сети друг с другом, обеспечивая высокую пропускную способность в магистральной сети Майкрософт, даже в разных географических регионах.This technology interconnects virtual networks to each other providing high bandwidth across Microsoft's backbone network, even across different geographic regions.

  • Использование протокола разбиения на части по протоколу TCP, передняя дверца Azure гарантирует, что конечные пользователи сразу же подключаются к ближайшей точке присутствия в передней дверце.Using split TCP-based anycast protocol, Azure Front Door ensures that your end users promptly connect to the nearest Front Door point of presence. К другим функциям передней дверцы Azure относятся:Other features of Azure Front Door include:

    • Терминирование TLSTLS termination

    • Личный доменCustom domain

    • Брандмауэр веб-приложенияWeb Application Firewall

    • Переопределение URL-адресаURL rewrite

    • Сходство сеансовSession affinity

    Изучите потребности вашего трафика приложения, чтобы узнать, какое решение является наиболее подходящим.Review the needs of your application traffic to learn which solution is the most suitable.