Примечания и ограничения

• После создания кластера следующие элементы изменить нельзя:
  • Number of master nodes: Например, кластер без HA (с одним master node) нельзя изменить на кластер HA (с тремя master nodes).
  • AZ, в котором развернут master node
  • Network configuration кластера, например VPC, subnet, pod CIDR block, Service CIDR block и настройки kube-proxy (forwarding)
  • Network model: Например, container tunnel network нельзя изменить на VPC network.
• Внутренние ресурсы CCE, такие как ECS nodes, ограничены квотой и их наличием. Возможно, что при создании кластера, масштабировании кластера или авто‑масштабировании будут созданы только некоторые nodes.
• ECS node specifications: CPU ≥ 2 cores, memory ≥ 4 GiB
• Для доступа к кластеру CCE через VPN убедитесь, что VPN CIDR block не конфликтует с VPC CIDR block, в котором находится кластер, и pod CIDR block.

• По умолчанию NodePort Service доступен внутри VPC. Чтобы получить доступ к NodePort Service через Интернет, заранее привяжите EIP к узлу в кластере.
• Ограничения для load balancers, связанных с Services:
  • Load balancer, автоматически созданный на основе конфигурации Service, нельзя связывать с другими ресурсами. Если вы связываете load balancer с другими ресурсами, он не будет автоматически удалён при удалении Service, что приведёт к оставшимся ресурсам.
  • Имена слушателей load balancer для кластеров v1.15 и более ранних нельзя изменять. Если вы измените имена, доступ к load balancer может стать аномальным.
• В таблице ниже показаны взаимосвязи между сетевыми политиками и типами кластеров.

  Тип кластера	CCE Standard Cluster	CCE Standard Cluster	CCE Turbo Cluster
  Сетевая модель	Туннельная сеть	VPC сеть	Cloud Native Network 2.0
  Сетевые политики	Включено по умолчанию	Отключено по умолчанию (Чтобы использовать сетевые политики, включите DataPlane V2 при создании кластера.)	Отключено по умолчанию (Чтобы использовать сетевые политики, включите DataPlane V2 при создании кластера.)
  Реализация Data plane	OpenvSwitch	eBPF	eBPF
  Версии Кластера для правил входящего трафика	Все версии	v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0, или позже	Кластеры v1.34.3-r10 или позже
  Версии Кластера для правил исходящего трафика	v1.23 и позже
  Селектор для правил входящего трафика	namespaceSelector podSelector	namespaceSelector podSelector ipBlock	namespaceSelector podSelector ipBlock
  Селектор для правил egress	namespaceSelector podSelector ipBlock
  Максимальное количество объектов NetworkPolicy, которые могут быть применены к pod	15	Не ограничено. Рекомендуется поддерживать количество ниже 100.	Не ограничено. Рекомендуется поддерживать количество ниже 100.
  Поддерживаемые ОС	EulerOS CentOS HCE OS 2.0	HCE OS 2.0 поддерживается. Кластеры v1.28.15-r70, v1.29.15-r30, v1.30.14-r30, v1.31.10-r30, v1.32.6-r30, v1.33.5-r20, v1.34.1-r0 и более поздние версии поддерживают Ubuntu 22.04.	HCE OS 2.0 поддерживается. Кластеры v1.28.15-r70, v1.29.15-r30, v1.30.14-r30, v1.31.10-r30, v1.32.6-r30, v1.33.5-r20, v1.34.1-r0 и более поздние версии поддерживают Ubuntu 22.04.
  Политики сети IPv6	Не поддерживается	Не поддерживается	Поддерживается
  Защищённые контейнеры	Не поддерживается	Не поддерживается	Не поддерживается
  Область IPBlock	Нет ограничений	Подсети внутри блока pod CIDR, блока Service CIDR и IP-адресов узлов	Подсети внутри блока pod CIDR, блока Service CIDR и IP-адресов узлов
  Ограничение доступа к ClusterIP с помощью меток рабочих нагрузок	Не поддерживается	Поддерживается	Поддерживается
  Ограничение внутреннего CIDR‑блока облачного сервера 100.125.0.0/16	Поддерживается	Поддерживается	Поддерживается
  SCTP	Не поддерживается	Поддерживается	Поддерживается
  Постоянное разрешение доступа к pod‑ам на узле с других узлов	Поддерживается	Поддерживается	Поддерживается
  Настройка EndPort в сетевых политиках	Не поддерживается	Поддерживается	Поддерживается

  Note

  • Если вы обновляете стандартный кластер CCE с туннельной сетью до версии, поддерживающей правила egress в режиме in-place, правила не будут работать, потому что node OS не обновлена. В этом случае выполните reset the node.
  • Когда сетевая политика включена для кластера с туннельной сетью, исходный IP-адрес pod встраивается в необязательное поле пакетов, которые он отправляет в любой блок Service CIDR. Это позволяет настраивать правила сетевой политики на целевом pod, учитывая исходный IP-адрес pod.

• Ограничения для томов EVS:
  • Диски EVS нельзя подключать между AZ и нельзя использовать несколькими рабочими нагрузками, несколькими pod одной и той же нагрузки или несколькими задачами. Data sharing общего диска не поддерживается между узлами в кластере CCE. Если диск EVS подключён к нескольким узлам, могут возникнуть конфликты ввода‑вывода и конфликты кэша данных. Поэтому при создании Deployment, использующего диски EVS, выбирайте только один pod.
  • Для кластеров версии ниже v1.19.10, если используется политика HPA для масштабирования нагрузки с подключёнными томами EVS, к существующим pod нельзя выполнять чтение или запись, когда новый pod планируется на другой узел.

    Для кластеров v1.19.10 и более новых, если используется политика HPA для масштабирования нагрузки с подключёнными томами EVS, новый pod не может быть запущен, потому что диски EVS нельзя подключать.

• Ограничения для томов SFS:
  • Несколько PV могут использовать одну и ту же файловую систему SFS или SFS Turbo при следующих ограничениях:
    • Если pod монтирует том SFS или SFS Turbo, используемый несколькими PVC/PV, и у PV одинаковые значения volumeHandle, pod может не запуститься. Чтобы избежать этой проблемы, не монтируйте одну и ту же файловую систему SFS или SFS Turbo в один pod.
    • Параметр persistentVolumeReclaimPolicy в PV должен быть установлен в Retain. Иначе, при удалении PV связанный базовый том может быть удалён. В этом случае другие PV, связанные с базовым томом, работают некорректно.
    • Если базовый том используется многократно, включите изоляцию и защиту для ReadWriteMany на уровне приложения, чтобы предотвратить перезапись и потерю данных.
• Ограничения для томов OBS:
  • Если используются тома OBS, группу владельца и разрешения точки монтирования изменить нельзя.
  • Каждый раз, когда том OBS монтируется к рабочей нагрузке через PVC, в бэкенде создаётся резидентный процесс. Когда рабочая нагрузка использует слишком много томов OBS или читает и записывает большое количество файлов объектного хранилища, резидентные процессы потребляют значительный объём памяти. Чтобы обеспечить стабильную работу нагрузки, убедитесь, что количество используемых томов OBS не превышает запрошенную память. Например, если нагрузка запрашивает 4 GiB памяти, количество томов OBS должно быть не более 4.
  • Secure containers не поддерживают тома OBS.
  • Жёсткие ссылки не поддерживаются при монтировании общих бакетов.
  • Режим только для чтения не поддерживается, когда PVC OBS монтируется к рабочей нагрузке.
• Ограничения для локальных PV:
  • Локальные PV поддерживаются только при версии кластера v1.21.2-r0 или новее и версии дополнения Everest v2.1.23 или новее.
  • Удаление, удаление, сброс или масштабирование узла приведут к потере данных PVC/PV локального PV, связанного с узлом, которые нельзя восстановить или использовать повторно. В этих сценариях pod, использующий локальный PV, будет вытеснен с узла. Будет создан новый pod, который останется в состоянии pending. Это происходит потому, что PVC, используемый pod, имеет метку узла, из‑за чего pod не может быть запланирован. После сброса узла pod может быть запланирован на сброшенный узел. В этом случае pod остаётся в состоянии creating, поскольку базовый логический том, соответствующий PVC, не существует.
  • Не удаляйте вручную соответствующий пул хранения и не отсоединяйте диски с данными от узла. Иначе могут возникнуть исключения, такие как потеря данных.
  • Локальный PV нельзя монтировать к нескольким рабочим нагрузкам или джобам одновременно.
• Ограничения для локальных EV:
  • Локальные EV поддерживаются только при версии кластера v1.21.2-r0 или новее и версии дополнения Everest v1.2.29 или новее.
  • Не удаляйте вручную соответствующий пул хранения и не отсоединяйте диски с данными от узла. В противном случае могут возникнуть исключения, такие как потеря данных.
  • Убедитесь, что каталог /var/lib/kubelet/pods/ не смонтирован в pod на узле. В противном случае pod, смонтированный с такими томами, может не удалиться.
• Ограничения на снимки и бэкапы:
  • Функция снимков доступна only for clusters v1.15 or later и требует дополнения Everest на основе CSI.
  • Подтип (common I/O, high I/O или ultra-high I/O), режим диска (VBD или SCSI), шифрование данных, статус совместного использования и ёмкость EVS‑диска, созданного из снимка, должны совпадать с соответствующими параметрами диска, связанным со снимком. Эти атрибуты нельзя изменить после проверки или настройки.
  • Снимки можно создавать только для EVS‑дисков, которые доступны или находятся в использовании, и для одного EVS‑диска можно создать максимум семь снимков.
  • Снимки можно создавать только для PVC, созданных с использованием класса хранилища (имя которого начинается с csi), предоставляемого дополнением Everest. Снимки нельзя создавать для PVC, созданных с использованием класса хранилища FlexVolume, имя которого ssd, sas или sata.
  • Данные снимков зашифрованных дисков хранятся зашифрованными, а данные снимков незашифрованных дисков — незашифрованными.
  • При создании PVC из снимка избегайте удаления снимка, пока PVC находится в состоянии ожидания. Это может привести к ошибке удаления снимка.
• Ограничения на LVM:

  Конфигурация Бэкапа по умолчанию, хранящаяся в пути /etc/lvm/lvm.conf для LVM узла, была изменена. После установки дополнения CCE Container Storage (Everest) (версия ≥ 2.4.98) архивные логи будут сохраняться только один день, чтобы избежать заполнения дискового пространства историческими метаданными многочисленных операций LVM.

CCE использует Helm charts для развертывания дополнений. Чтобы изменить или обновить дополнение, выполните операции на странице Add-ons или используйте открытые API управления дополнениями. Избегайте внесения изменений в ресурсы дополнений в бэкенде, так как это может привести к аномальному поведению дополнения или неожиданным проблемам. Например, параметры могут быть перезаписаны после обновления.

Для ваших кластеров CCE в каждом регионе существуют квоты ресурсов.

Ёмкость кластера состоит из различных типов ресурсов, включая группы контейнеров (Под), экземпляры облачного хранилища (persistent volumes) и Services. Кроме того, размер этих ресурсных объектов также может влиять на ёмкость кластера.

Например:

• Если количество Под слишком велико, максимальное количество Под уменьшится в определённом диапазоне производительности.
• По мере приближения количества Под к верхнему пределу, верхние пределы других типов ресурсов в кластере также будут соответственно уменьшаться.

Поскольку кластеры в реальных рабочих средах содержат несколько типов ресурсов, возможно, что количество ресурсов одного типа не достигнет своего верхнего предела. Важно регулярно отслеживать использование ресурсов кластера и эффективно планировать и управлять ресурсами, чтобы обеспечить наилучшую производительность всех ресурсов. Если текущие характеристики не соответствуют вашим требованиям, вы можете масштабировать кластер, чтобы обеспечить стабильность.