Подготовка Linux для томов Edge

Статья
10/16/2024

В статье описывается, как подготовить Linux для томов Edge с помощью AKS, включенных Azure Arc, Edge Essentials или Ubuntu.

Примечание.

Минимальная поддерживаемая версия ядра Linux — 5.1. В настоящее время существуют известные проблемы с 6.4 и 6.2.

Предварительные требования

Примечание.

Хранилище контейнеров Azure, включенное Azure Arc, доступно только в следующих регионах: восточная часть США, восточная часть США 2, западная часть США 2, западная часть США 2, западная часть США 3, Северная Европа, Западная Европа.

Удаление предыдущего экземпляра хранилища контейнеров Azure, включенного расширением Azure Arc

Если вы ранее установили версию хранилища контейнеров Azure, включенную ранее 2.1.0-preview, необходимо удалить предыдущий экземпляр, чтобы установить более новую версию. Если вы установили выпуск 1.2.0-preview или более ранних версий , используйте эти инструкции. Версии после версии 2.1.0-preview доступны для обновления и не требуют этого удаления.

Чтобы удалить старую версию расширения, ресурсы Kubernetes, имеющие ссылки на старую версию расширения, необходимо очистить. Все ожидающие ресурсы могут отложить очистку расширения. Существует по крайней мере два способа очистки этих ресурсов: либо с помощью kubectl delete <resource_type> <resource_name>, либо путем отмены применения файлов YAML, используемых для создания ресурсов. Ресурсы, которые необходимо удалить, обычно являются модулями pod, ссылкой на ПВХ и субволюмой CRD (если был настроен том Ingest Edge Cloud). Кроме того, следующие четыре файла YAML можно передать kubectl delete -f с помощью следующих команд в указанном порядке. Эти переменные необходимо обновить с помощью ваших сведений:
- YOUR_DEPLOYMENT_FILE_NAME_HERE: добавьте имена файлов развертывания. В примере в этой статье использовалось deploymentExample.yamlимя файла. При создании нескольких развертываний каждый из них должен быть удален в отдельной строке.
- YOUR_PVC_FILE_NAME_HERE: добавьте имена файлов сохраняемого утверждения тома. В примере из этой статьи, если вы использовали том Cloud Ingest Edge, то использовалось cloudIngestPVC.yamlимя файла. Если вы использовали локальный общий пограничный том, то использовалось localSharedPVC.yamlимя файла. При создании нескольких PVC каждый из них должен быть удален в отдельной строке.
- YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE: добавьте имена файлов подволюмы Edge. В примере в этой статье использовалось edgeSubvolume.yamlимя файла. Если вы создали несколько подволок, каждый из них должен быть удален в отдельной строке.
- YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE: добавьте имя файла конфигурации хранилища Edge здесь. В примере в этой статье использовалось edgeConfig.yamlимя файла.
```
kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>"   
kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"
```
После удаления файлов для развертываний, PVCs, подволок Edge и конфигурации хранилища Edge на предыдущем шаге можно удалить расширение с помощью следующей команды. Замените YOUR_RESOURCE_GROUP_NAME_HERE, YOUR_CLUSTER_NAME_HEREа YOUR_EXTENSION_NAME_HERE также соответствующими сведениями:
```
az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
```

Кластер Kubernetes, подключенный к Arc

В этих инструкциях предполагается, что у вас уже есть кластер Kubernetes, подключенный к Arc. Чтобы подключить существующий кластер Kubernetes к Azure Arc, ознакомьтесь с этими инструкциями.

Если вы хотите использовать службу хранилища контейнеров Azure, включенную Azure Arc с операциями Интернета вещей Azure, следуйте инструкциям по созданию кластера для операций Интернета вещей Azure.

Кластеры с одним узлом и несколькими узлами

Кластер с одним узлом обычно используется для целей разработки или тестирования из-за простоты в настройке и минимальных требованиях к ресурсам. Эти кластеры предлагают упрощенную и простую среду для разработчиков, чтобы экспериментировать с Kubernetes без сложности установки с несколькими узлами. Кроме того, в ситуациях, когда такие ресурсы, как ЦП, память и хранилище, ограничены, кластер с одним узлом является более практическим. Его простота настройки и минимальные требования к ресурсам делают его подходящим выбором в средах с ограниченными ресурсами.

Однако кластеры с одним узлом имеют ограничения, в основном в виде отсутствующих функций, включая отсутствие высокой доступности, отказоустойчивость, масштабируемость и производительность.

Конфигурация Kubernetes с несколькими узлами обычно используется для рабочих, промежуточных или крупномасштабных сценариев из-за таких функций, как высокий уровень доступности, отказоустойчивость, масштабируемость и производительность. Кластер с несколькими узлами также представляет проблемы и компромиссы, включая сложность, издержки, затраты и рекомендации по эффективности. Например, для настройки и обслуживания кластера с несколькими узлами требуются дополнительные знания, навыки, средства и ресурсы (сеть, хранилище, вычисления). Кластер должен обрабатывать координацию и обмен данными между узлами, что приводит к потенциальной задержке и ошибкам. Кроме того, запуск кластера с несколькими узлами является более ресурсоемким и является дорогостоящим, чем кластер с одним узлом. Оптимизация использования ресурсов между узлами имеет решающее значение для поддержания эффективности кластера и приложений и производительности.

В итоге кластер Kubernetes с одним узлом может быть подходит для разработки, тестирования и ограниченных ресурсов сред. Кластер с несколькими узлами лучше подходит для рабочих развертываний, высокого уровня доступности, масштабируемости и сценариев, в которых распределенные приложения являются обязательными. Этот выбор в конечном счете зависит от конкретных потребностей и целей развертывания.

Минимальные требования к оборудованию

Кластер с одним узлом или 2-узлом

рекомендуемая виртуальная машина Standard_D8ds_v5
Эквивалентные спецификации на узел:
- 4 ЦП
- ОЗУ 16 ГБ

Кластер с несколькими узлами

рекомендуемая виртуальная машина Standard_D8as_v5
Эквивалентные спецификации на узел:
- 8 ЦП
- ОЗУ 32 ГБ

32 ГБ ОЗУ служит буфером; однако достаточно 16 ГБ ОЗУ. Для конфигураций Edge Essentials требуется 8 ЦП с 10 ГБ ОЗУ на узел, что делает 16 ГБ ОЗУ минимальным требованием.

Минимальные требования к хранилищу

Требования к пограничным томам

При использовании параметра отказоустойчивого хранилища тома Edge выделяет место на диске из отказоустойчивого пула носителей, который состоит из хранилища, экспортированного каждым узлом в кластере.

Пул носителей настроен на использование 3-сторонняя репликация для обеспечения отказоустойчивости. При подготовке тома Edge он выделяет место на диске из пула носителей и выделяет хранилище на 3 из реплик.

Например, в кластере с 3 узлами с 20 ГБ дискового пространства на узел кластер имеет пул носителей размером 60 ГБ. Однако из-за репликации он имеет действующий размер хранилища в 20 ГБ.

При подготовке пограничного тома с запрошенным размером 10 ГБ он выделяет зарезервированный системный том (статически размер 1 ГБ) и том данных (размер до запрошенного размера тома, например 10 ГБ). Зарезервированный том системы потребляет 3 ГБ (3 x 1 ГБ) дискового пространства в пуле носителей, а объем данных потребляет 30 ГБ (3 x 10 ГБ) дискового пространства в пуле носителей в общей сложности 33 ГБ.

Требования к томам кэша

Для томов кэша требуется не менее 4 ГБ на узел хранилища. Например, если у вас есть 3-узелный кластер, требуется не менее 12 ГБ хранилища.

Поделиться через