Partager via


Déployer des nœuds d’infrastructure dans un cluster Azure Red Hat OpenShift (ARO)

ARO vous permet d’utiliser des groupes de machines d’infrastructure pour créer des machines qui hébergent uniquement des composants d’infrastructure, tels que le routeur par défaut, le registre de conteneurs intégré et les composants pour le monitoring et les métriques de cluster. Ces machines d’infrastructure n’entraînent pas de coûts OpenShift ; ils entraînent uniquement des coûts Azure Compute.

Dans un déploiement de production, il est recommandé de déployer trois ensembles de machines pour contenir des composants d’infrastructure. Chacun de ces nœuds peut être déployé dans différentes zones de disponibilité pour augmenter la disponibilité. Ce type de configuration nécessite trois ensembles de machines différents ; un pour chaque zone de disponibilité. Pour obtenir des conseils sur le dimensionnement des nœuds d’infrastructure, consultez les Pratiques d’infrastructure recommandées.

Charges de travail qualifiées

Les charges de travail d’infrastructure suivantes n’entraînent pas d’abonnements de rôle de travail Azure Red Hat OpenShift :

  • Services de plan de contrôle Kubernetes et Azure Red Hat OpenShift qui s’exécutent sur des maîtres

  • Routeur par défaut

  • Registre d’image conteneur intégré

  • Contrôleur d’entrée basé sur HAProxy

  • La collection des métriques de cluster ou service de monitoring, y compris les composants de monitoring des projets définis par l’utilisateur

  • Journalisation agrégée de cluster

Important

L’exécution de charges de travail autres que les types désignés sur les nœuds d’infrastructure peut affecter le contrat de niveau de service (SLA) et la stabilité du cluster.

Avant de commencer

Pour que les machines virtuelles Azure ajoutées à un cluster ARO soient reconnues comme des nœuds d’infrastructure (par opposition à d’autres nœuds Worker) et qu’il ne leur soit pas facturé de frais OpenShift, les critères suivants doivent être remplis :

  • Les nœuds doivent être de l’un des types d’instances suivants uniquement :

    • Standard_E4s_v5
    • Standard_E8s_v5
    • Standard_E16s_v5
    • Standard_E4as_v5
    • Standard_E8as_v5
    • Standard_E16as_v5
  • Il ne peut y avoir plus de trois nœuds. Tous les nœuds supplémentaires sont facturés avec des frais OpenShift.

  • Les nœuds doivent avoir une balise Azure de node_role: infra

  • Seules les charges de travail désignées pour les nœuds d’infrastructure sont autorisées. Toutes les autres charges de travail les considéreraient comme des nœuds Worker et sont donc soumises aux frais. Cela peut également invalider le SLA et compromettre la stabilité du cluster.

Création de jeux d’ordinateurs d’infrastructure

  1. Utilisez le modèle ci-dessous pour créer la définition de manifeste de votre jeu d’ordinateurs d’infrastructure.

  2. Remplacez tous les champs entre « <> » par vos valeurs spécifiques.

    Par exemple, remplacez location: <REGION> par location: westus2.

  3. Pour obtenir de l’aide sur le remplissage des valeurs requises, consultez Commandes et valeurs.

  4. Créez l’ensemble d’ordinateurs avec la commande suivante : oc create -f <machine-set-filename.yaml>

  5. Pour vérifier la création de l’ensemble d’ordinateurs, exécutez la commande suivante : oc get machineset -n openshift-machine-api

    La sortie de la commande de vérification doit ressembler à ce qui suit :

    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
    

Modèle de définition de manifeste

Utilisez le modèle suivant dans la procédure ci-dessus pour créer la définition de manifeste pour votre ensemble d’ordinateurs d’infrastructure :

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

Commandes et valeurs

Voici quelques commandes/valeurs courantes utilisées lors de la création et de l’exécution du modèle.

Répertorier tous les ensembles d’ordinateurs :

oc get machineset -n openshift-machine-api

Obtenir des détails sur un ensemble d’ordinateurs spécifique :

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

Groupe de ressources de cluster :

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

Groupe de ressources réseau :

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

ID d’infrastructure :

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

Région :

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

Référence SKU :

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

Sous-réseau :

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

Version :

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

Déplacement de charges de travail vers les nouveaux nœuds d’infrastructure

Suivez les instructions ci-dessous pour déplacer vos charges de travail d’infrastructure vers les nœuds d’infrastructure créés précédemment.

Entrée

Utilisez cette procédure pour tous les contrôleurs d’entrée supplémentaires que vous pouvez avoir dans le cluster.

Remarque

Si votre application a des besoins en ressources d’entrée très élevés, il peut être préférable de les répartir entre les nœuds Worker ou un ensemble d’ordinateurs dédié.

  1. Définissez le nodePlacement sur le ingresscontroller sur node-role.kubernetes.io/infra et augmentez le replicas pour qu’il corresponde au nombre de nœuds d’infrastructure :

    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. Vérifiez que l’opérateur de contrôleur d’entrée démarre des pods sur les nouveaux nœuds d’infrastructure :

    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>
    

Registre

  1. Définissez le nodePlacement du registre sur 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. Vérifiez que l’opérateur de registre démarre des pods sur les nouveaux nœuds d’infrastructure :

    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>
    

Monitoring du cluster

  1. Configurez la pile de monitoring du cluster pour qu’elle utilise les nœuds d’infrastructure.

    Remarque

    Cela remplace toutes les autres personnalisations de la pile de monitoring du cluster. Vous pouvez donc fusionner vos personnalisations existantes avant d’exécuter la commande.

    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. Vérifiez que l’opérateur de monitoring OpenShift démarre des pods sur les nouveaux nœuds d’infrastructure. Notez que certains nœuds (par exemple prometheus-operator) restent sur les nœuds maîtres.

    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. Autorisez les pods DNS à s’exécuter sur les nœuds d’infrastructure.

    oc edit dns.operator/default
    
    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
    name: default
    spec:
    nodePlacement:
      tolerations:
      - operator: Exists
    
  2. Vérifiez que les pods DNS sont planifiés sur tous les nœuds infra.

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