Compartir a través de


Implementación de nodos de infraestructura en un clúster de Red Hat OpenShift en Azure

Red Hat OpenShift en Microsoft Azure permite usar conjuntos de máquinas de infraestructura para crear máquinas que solo hospede componentes de infraestructura, como el enrutador predeterminado, el registro de contenedor integrado y los componentes para las métricas y la supervisión del clúster. Estas máquinas de infraestructura no incurren en costos de OpenShift; solo incurren en costos de Proceso de Azure.

En una implementación de producción, la recomendación es implementar tres conjuntos de máquinas para contener componentes de infraestructura. Cada uno de estos nodos se puede implementar en diferentes zonas de disponibilidad para aumentar la disponibilidad. Este tipo de configuración requiere tres conjuntos de máquinas diferentes; una para cada zona de disponibilidad. Para obtener instrucciones de ajuste de tamaño de nodo de infraestructura, consulte Procedimientos recomendados de infraestructura.

Cargas de trabajo calificadas

Las siguientes cargas de trabajo de infraestructura no incurren en suscripciones de trabajo de Red Hat OpenShift en Azure:

  • Servicios del plano de control de Kubernetes y Red Hat OpenShift de Azure que se ejecutan en nodos maestros

  • El enrutador predeterminado

  • Registro de imágenes de contenedor integrado

  • Controlador de entrada basado en HAProxy

  • La recopilación de métricas del clúster o el servicio de supervisión, incluidos los componentes para supervisar proyectos definidos por el usuario

  • Registro agregado de clúster

Importante

La ejecución de cargas de trabajo distintas de los tipos designados en los nodos de infraestructura puede afectar al Acuerdo de Nivel de Servicio (SLA) y la estabilidad del clúster.

Prerrequisitos

Para que las máquinas virtuales de Azure agregadas a un clúster se reconozcan como nodos de infraestructura, en lugar de nodos de trabajo, y no se les cobrará una tarifa de OpenShift, se deben cumplir los siguientes criterios:

  • Los nodos deben ser solo uno de los siguientes tipos de instancia:

    • Standard_E4s_v5
    • Standard_E8s_v5
    • Standard_E16s_v5
    • Standard_E4as_v5
    • Standard_E8as_v5
    • Standard_E16as_v5
  • No puede haber más de tres nodos. Se aplica una tarifa de OpenShift a cualquier nodo adicional.

  • Los nodos deben tener una etiqueta de Azure. node_role: infra

  • Solo se permiten cargas de trabajo designadas para los nodos de infraestructura. Todas las demás cargas de trabajo considerarían estos nodos de trabajo y estarían sujetos a la tarifa. Esta designación también podría invalidar el Acuerdo de Nivel de Servicio y poner en peligro la estabilidad del clúster.

Creación de conjuntos de máquinas de infraestructura

  1. Utilice la plantilla de definición del manifiesto para crear la definición del manifiesto para su conjunto de máquinas de infraestructura.

  2. Reemplace todos los campos entre corchetes angulares (<>) por sus valores específicos.

    Por ejemplo, reemplace location: <REGION> por location: westus2

  3. Para obtener los valores necesarios para la plantilla de definición de manifiesto, consulte Comandos y valores.

  4. Cree el conjunto de máquinas con el siguiente comando: oc create -f <machine-set-filename.yaml>

  5. Para comprobar la creación del conjunto de máquinas, ejecute el siguiente comando: oc get machineset -n openshift-machine-api

    La salida del comando de comprobación debe ser similar a los siguientes valores:

    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
    

Plantilla de definición de manifiesto

La plantilla siguiente se usó en el procedimiento anterior para crear la definición del manifiesto para el conjunto de máquinas de infraestructura.

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: <VNET_NAME>
          zone: <ZONE>
      taints:
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

Comandos y valores

A continuación se muestran algunos comandos y valores comunes que se usan para crear y ejecutar la plantilla.

Enumerar todos los conjuntos de máquinas:

oc get machineset -n openshift-machine-api

Obtenga los detalles de un conjunto de máquinas específico:

oc get machineset <machineset_name> -n openshift-machine-api -o yaml

Grupo de recursos de clúster:

oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'

Grupo de recursos de red:

oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.networkResourceGroupName}'

Identificador de infraestructura:

oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'

Región:

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}'

Subred:

oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}'

Versión:

oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.version}'

Red virtual:

oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}'

Traslado de cargas de trabajo a los nuevos nodos de infraestructura

Siga las instrucciones siguientes para mover las cargas de trabajo de infraestructura a los nodos de infraestructura creados anteriormente.

Entrada

Use este procedimiento para cualquier otro controlador de entrada que pueda tener en el clúster. Si la aplicación tiene requisitos elevados de recursos de entrada, es posible que sea mejor distribuirlos entre nodos de trabajo o un conjunto de máquinas dedicado.

  1. Configure el nodePlacement en el ingresscontroller a node-role.kubernetes.io/infra y aumente el replicas para que coincida con el número de nodos de infraestructura:

    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. Compruebe que el Ingress Controller Operator está iniciando pods en los nuevos nodos de infraestructura.

    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>
    

Registro

  1. Establezca el nodePlacement en el registro en 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. Verifique que el gestor del registro está iniciando pods en los nuevos nodos de infraestructura.

    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>
    

Supervisión de clústeres

  1. Configure la pila de supervisión del clúster para usar los nodos de infraestructura.

    Esto anula cualquier otra personalización en la pila de supervisión del clúster, por lo que podría querer combinar las personalizaciones existentes antes de ejecutar el comando.

    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. Compruebe que el operador de supervisión de OpenShift está iniciando pods en los nuevos nodos de infraestructura. Tenga en cuenta que algunos nodos, como prometheus-operator, permanecen en nodos maestros.

    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 (Sistema de Nombres de Dominio)

  1. Permitir que los pods DNS se ejecuten en los nodos de infraestructura.

    oc edit dns.operator/default
    
    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
    name: default
    spec:
    nodePlacement:
      tolerations:
      - operator: Exists
    
  2. Compruebe que los pods DNS están programados en todos los infra nodos.

    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
    

Para actualizar el clúster, consulte Actualización de un clúster de Red Hat OpenShift en Azure.