Развертывание узлов инфраструктуры в кластере Azure Red Hat OpenShift (ARO)
ARO позволяет использовать наборы компьютеров инфраструктуры для создания компьютеров, которые размещают только компоненты инфраструктуры, такие как маршрутизатор по умолчанию, интегрированный реестр контейнеров и компоненты для метрик кластера и мониторинга. Эти компьютеры инфраструктуры не несут затрат на OpenShift; Они несут только затраты на вычисления Azure.
В рабочем развертывании рекомендуется развернуть три набора компьютеров для хранения компонентов инфраструктуры. Каждый из этих узлов можно развернуть в разных зонах доступности для повышения доступности. Для этого типа конфигурации требуется три различных набора компьютеров; по одному для каждой зоны доступности. Рекомендации по размеру узлов инфраструктуры см . в рекомендациях по использованию инфраструктуры.
Квалифицированные рабочие нагрузки
Следующие рабочие нагрузки инфраструктуры не влечет за собой подписки на рабочую роль Azure Red Hat OpenShift:
Службы уровня управления Kubernetes и Azure Red Hat OpenShift, которые выполняются на мастерах
Маршрутизатор по умолчанию
Интегрированный реестр образов контейнеров
Контроллер входящего трафика на основе HAProxy
Коллекция метрик кластера или служба мониторинга, включая компоненты для мониторинга определяемых пользователем проектов
Ведение журнала с агрегированным кластером
Внимание
Выполнение рабочих нагрузок, отличных от указанных типов на узлах инфраструктуры, может повлиять на соглашение об уровне обслуживания (SLA) и стабильность кластера.
Подготовка к работе
Чтобы виртуальные машины Azure, добавленные в кластер ARO, были распознаны как узлы инфраструктуры (в отличие от дополнительных рабочих узлов), а не взимается плата OpenShift, необходимо выполнить следующие условия:
Узлы должны быть одним из следующих типов экземпляров:
- Standard_E4s_v5
- Standard_E8s_v5
- Standard_E16s_v5
- Standard_E4as_v5
- Standard_E8as_v5
- Standard_E16as_v5
Не может быть более трех узлов. Плата за любые дополнительные узлы взимается с оплаты OpenShift.
Узлы должны иметь тег Azure node_role.
Разрешены только рабочие нагрузки, назначенные для узлов инфраструктуры. Все остальные рабочие нагрузки будут считаться этими рабочими узлами и, таким образом, подлежат оплате. Это также может привести к недопустимости обслуживания и компрометации стабильности кластера.
Создание наборов компьютеров инфраструктуры
Используйте приведенный ниже шаблон, чтобы создать определение манифеста для набора компьютеров инфраструктуры.
Замените все поля между<> "" определенными значениями.
Например, измените
location: <REGION>наlocation: westus2.Сведения о заполнении необходимых значений см. в разделе "Команды и значения".
Создайте набор компьютера со следующей командой:
oc create -f <machine-set-filename.yaml>Чтобы проверить создание набора компьютеров, выполните следующую команду:
oc get machineset -n openshift-machine-apiВыходные данные команды проверки должны выглядеть следующим образом:
NAME DESIRED CURRENT READY AVAILABLE AGE ok0608-vkxvw-infra-westus21 1 1 1 1 165M ok0608-vkxvw-worker-westus21 1 1 1 1 4H24M ok0608-vkxvw-worker-westus22 1 1 1 1 4H24M ok0608-vkxvw-worker-westus23 1 1 1 1 4H24M
Шаблон определения манифеста
Используйте следующий шаблон в приведенной выше процедуре, чтобы создать определение манифеста для набора компьютеров инфраструктуры:
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
labels:
machine.openshift.io/cluster-api-cluster: <INFRASTRUCTURE_ID>
machine.openshift.io/cluster-api-machine-role: infra
machine.openshift.io/cluster-api-machine-type: infra
name: <INFRASTRUCTURE_ID>-infra-<REGION><ZONE>
namespace: openshift-machine-api
spec:
replicas: 1
selector:
matchLabels:
machine.openshift.io/cluster-api-cluster: <INFRASTRUCTURE_ID>
machine.openshift.io/cluster-api-machineset: <INFRASTRUCTURE_ID>-infra-<REGION><ZONE>
template:
metadata:
creationTimestamp: null
labels:
machine.openshift.io/cluster-api-cluster: <INFRASTRUCTURE_ID>
machine.openshift.io/cluster-api-machine-role: infra
machine.openshift.io/cluster-api-machine-type: infra
machine.openshift.io/cluster-api-machineset: <INFRASTRUCTURE_ID>-infra-<REGION><ZONE>
spec:
metadata:
creationTimestamp: null
labels:
machine.openshift.io/cluster-api-machineset: <OPTIONAL: Specify the machine set name to enable the use of availability sets. This setting only applies to new compute machines.>
node-role.kubernetes.io/infra: ''
providerSpec:
value:
apiVersion: azureproviderconfig.openshift.io/v1beta1
credentialsSecret:
name: azure-cloud-credentials
namespace: openshift-machine-api
image:
offer: aro4
publisher: azureopenshift
sku: <SKU>
version: <VERSION>
kind: AzureMachineProviderSpec
location: <REGION>
metadata:
creationTimestamp: null
natRule: null
networkResourceGroup: <NETWORK_RESOURCE_GROUP>
osDisk:
diskSizeGB: 128
managedDisk:
storageAccountType: Premium_LRS
osType: Linux
publicIP: false
resourceGroup: <CLUSTER_RESOURCE_GROUP>
tags:
node_role: infra
subnet: <SUBNET_NAME>
userDataSecret:
name: worker-user-data
vmSize: <Standard_E4s_v5, Standard_E8s_v5, Standard_E16s_v5>
vnet: aro-vnet
zone: <ZONE>
taints:
- key: node-role.kubernetes.io/infra
effect: NoSchedule
Команды и значения
Ниже приведены некоторые распространенные команды и значения, используемые при создании и выполнении шаблона.
Список всех наборов компьютеров:
oc get machineset -n openshift-machine-api
Получение сведений для определенного набора компьютеров:
oc get machineset <machineset_name> -n openshift-machine-api -o yaml
Группа ресурсов кластера:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'
Группа сетевых ресурсов:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.networkResourceGroupName}'
Идентификатор инфраструктуры:
oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'
Регион:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.location}'
SKU:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.sku}'
Подсеть:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}'
Версия:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.version}'
Vnet:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}'
Перемещение рабочих нагрузок на новые узлы инфраструктуры
Используйте приведенные ниже инструкции, чтобы переместить рабочие нагрузки инфраструктуры на ранее созданные узлы инфраструктуры.
Входящий трафик
Используйте эту процедуру для любых дополнительных контроллеров входящего трафика, которые могут быть в кластере.
Примечание.
Если приложение имеет очень высокие требования к ресурсам входящего трафика, возможно, лучше распределить их по рабочим узлам или выделенному набору компьютеров.
Задайте значение
nodePlacementingresscontrollernode-role.kubernetes.io/infraи увеличьте количество узлов инфраструктуры и увеличьтеreplicasего.oc patch -n openshift-ingress-operator ingresscontroller default --type=merge \ -p='{"spec":{"replicas":3,"nodePlacement":{"nodeSelector":{"matchLabels":{"node-role.kubernetes.io/infra":""}},"tolerations":[{"effect":"NoSchedule","key":"node-role.kubernetes.io/infra","operator":"Exists"}]}}}'Убедитесь, что оператор контроллера входящего трафика запускает pod на новых узлах инфраструктуры:
oc -n openshift-ingress get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES router-default-69f58645b7-6xkvh 1/1 Running 0 66s 10.129.6.6 cz-cluster-hsmtw-infra-aro-machinesets-eastus-3-l6dqw <none> <none> router-default-69f58645b7-vttqz 1/1 Running 0 66s 10.131.4.6 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none> router-default-6cb5ccf9f5-xjgcp 1/1 Terminating 0 23h 10.131.0.11 cz-cluster-hsmtw-worker-eastus2-xj9qx <none> <none>
Реестр
Задайте для
nodePlacementреестраnode-role.kubernetes.io/infraзначение :oc patch configs.imageregistry.operator.openshift.io/cluster --type=merge \ -p='{"spec":{"affinity":{"podAntiAffinity":{"preferredDuringSchedulingIgnoredDuringExecution":[{"podAffinityTerm":{"namespaces":["openshift-image-registry"],"topologyKey":"kubernetes.io/hostname"},"weight":100}]}},"logLevel":"Normal","managementState":"Managed","nodeSelector":{"node-role.kubernetes.io/infra":""},"tolerations":[{"effect":"NoSchedule","key":"node-role.kubernetes.io/infra","operator":"Exists"}]}}'Убедитесь, что оператор реестра запускает модули pod на новых узлах инфраструктуры:
oc -n openshift-image-registry get pods -l "docker-registry" -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES image-registry-84cbd76d5d-cfsw7 1/1 Running 0 3h46m 10.128.6.7 cz-cluster-hsmtw-infra-aro-machinesets-eastus-2-kljml <none> <none> image-registry-84cbd76d5d-p2jf9 1/1 Running 0 3h46m 10.129.6.7 cz-cluster-hsmtw-infra-aro-machinesets-eastus-3-l6dqw <none> <none>
Мониторинг платформы (кластера)
Настройте стек мониторинга кластера для использования узлов инфраструктуры.
Примечание.
Это переопределит любые другие настройки в стек мониторинга кластера, поэтому вам может потребоваться объединить существующие настройки перед выполнением команды.
cat << EOF | oc apply -f - apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |+ alertmanagerMain: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" prometheusK8s: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" prometheusOperator: {} grafana: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" k8sPrometheusAdapter: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" kubeStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" telemeterClient: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" openshiftStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" thanosQuerier: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" EOFУбедитесь, что оператор мониторинга OpenShift запускает модули pod на новых узлах инфраструктуры. Обратите внимание, что некоторые узлы (например
prometheus-operator) останутся на главных узлах.oc -n openshift-monitoring get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES alertmanager-main-0 6/6 Running 0 2m14s 10.128.6.11 cz-cluster-hsmtw-infra-aro-machinesets-eastus-2-kljml <none> <none> alertmanager-main-1 6/6 Running 0 2m46s 10.131.4.11 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none> cluster-monitoring-operator-5bbfd998c6-m9w62 2/2 Running 0 28h 10.128.0.23 cz-cluster-hsmtw-master-1 <none> <none> grafana-599d4b948c-btlp2 3/3 Running 0 2m48s 10.131.4.10 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none> kube-state-metrics-574c5bfdd7-f7fjk 3/3 Running 0 2m49s 10.131.4.8 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none>
DNS
Разрешите dns-модулям pod выполняться на узлах инфраструктуры.
oc edit dns.operator/defaultapiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: nodePlacement: tolerations: - operator: ExistsУбедитесь, что модули pod DNS запланированы на все инфракрасные узлы.
oc get ds/dns-default -n openshift-dns
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
dns-default 7 7 7 7 7 kubernetes.io/os=linux 35d