Развертывание узлов инфраструктуры в кластере 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.

  • Разрешены только рабочие нагрузки, назначенные для узлов инфраструктуры. Все остальные рабочие нагрузки будут считаться этими рабочими узлами и, таким образом, подлежат оплате. Это также может привести к недопустимости обслуживания и компрометации стабильности кластера.

Создание наборов компьютеров инфраструктуры

  1. Используйте приведенный ниже шаблон, чтобы создать определение манифеста для набора компьютеров инфраструктуры.

  2. Замените все поля между<> "" определенными значениями.

    Например, измените location: <REGION> на location: westus2.

  3. Сведения о заполнении необходимых значений см. в разделе "Команды и значения".

  4. Создайте набор компьютера со следующей командой: oc create -f <machine-set-filename.yaml>

  5. Чтобы проверить создание набора компьютеров, выполните следующую команду: 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}'

Перемещение рабочих нагрузок на новые узлы инфраструктуры

Используйте приведенные ниже инструкции, чтобы переместить рабочие нагрузки инфраструктуры на ранее созданные узлы инфраструктуры.

Входящий трафик

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

Примечание.

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

  1. Задайте значение 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"}]}}}'
    
  2. Убедитесь, что оператор контроллера входящего трафика запускает pod на новых узлах инфраструктуры:

    oc -n openshift-ingress get pods -o wide
    
    NAME                              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>
    

Реестр

  1. Задайте для 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"}]}}'
    
  2. Убедитесь, что оператор реестра запускает модули pod на новых узлах инфраструктуры:

    oc -n openshift-image-registry get pods -l "docker-registry" -o wide
    
    NAME                              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>
    

Мониторинг платформы (кластера)

  1. Настройте стек мониторинга кластера для использования узлов инфраструктуры.

    Примечание.

    Это переопределит любые другие настройки в стек мониторинга кластера, поэтому вам может потребоваться объединить существующие настройки перед выполнением команды.

    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
    
  2. Убедитесь, что оператор мониторинга OpenShift запускает модули pod на новых узлах инфраструктуры. Обратите внимание, что некоторые узлы (например prometheus-operator) останутся на главных узлах.

    oc -n openshift-monitoring get pods -o wide
    
    NAME                                           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

  1. Разрешите dns-модулям pod выполняться на узлах инфраструктуры.

    oc edit dns.operator/default
    
    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
    name: default
    spec:
    nodePlacement:
      tolerations:
      - operator: Exists
    
  2. Убедитесь, что модули 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