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

Microsoft Azure Red Hat OpenShift vous permet d’utiliser des ensembles d’ordinateurs 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 les métriques de cluster et la surveillance. Ces machines d’infrastructure n’entraînent pas de coûts OpenShift ; ils entraînent uniquement des coûts de calcul Azure.

Dans un déploiement de production, il est recommandé de déployer trois ensembles d’ordinateurs 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 worker 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’images conteneur intégré
Contrôleur d’entrée basé sur HAProxy
Collecte des métriques de cluster ou service de supervision, y compris les composants de surveillance 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.

Conditions préalables

Pour que les machines virtuelles Azure ajoutées à un cluster soient reconnues en tant que nœuds d’infrastructure, au lieu de nœuds Worker et qu’elles ne soient pas facturées, les critères suivants doivent être remplis :

Les nœuds doivent être 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 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 considéreraient ces nœuds de travail et seraient soumises aux frais. Cette désignation peut également invalider le contrat SLA et compromettre la stabilité du cluster.

Créer des ensembles de machines d’infrastructure

Utilisez le modèle de définition de manifeste pour créer la définition de manifeste pour votre jeu d’ordinateurs d’infrastructure.
Remplacez tous les champs entre crochets (<>) par vos valeurs spécifiques.

Par exemple, remplacez location: <REGION> par location: westus2
Pour obtenir les valeurs requises pour le modèle de définition de manifeste, consultez Commandes et valeurs.
Créez l’ensemble de machines avec la commande suivante : oc create -f <machine-set-filename.yaml>

Pour vérifier la création de l'ensemble de machines, exécutez la commande suivante : oc get machineset -n openshift-machine-api

La sortie de la commande de vérification doit ressembler aux valeurs suivantes :

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

Le modèle suivant a été utilisé dans la procédure précédente pour créer la définition de manifeste pour votre jeu 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: <VNET_NAME>
          zone: <ZONE>
      taints:
      - key: node-role.kubernetes.io/infra
        effect: NoSchedule

Commandes et valeurs

Voici quelques commandes et valeurs courantes utilisées pour créer et exécuter le modèle.

Répertorier tous les ensembles d’ordinateurs :

oc get machineset -n openshift-machine-api

Obtenez des détails pour 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}'

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

Réseau virtuel :

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

Utilisez les instructions suivantes 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 autres contrôleurs d’entrée que vous pouvez avoir dans le cluster. Si votre application a des besoins élevés en ressources d’entrée, il peut être préférable de les répartir entre les nœuds Worker ou un ensemble d’ordinateurs dédiés.

Définissez la nodePlacement sur le ingresscontroller à node-role.kubernetes.io/infra et augmentez le replicas pour correspondre 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"}]}}}'

Vérifiez que l'Opérateur de Contrôleur Ingress 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

Définissez dans le nodePlacement 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"}]}}'

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

Configurez la pile de surveillance du cluster pour utiliser les nœuds d’infrastructure.

Cela remplace toutes les autres personnalisations de la pile de surveillance 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

Vérifiez que l’opérateur de supervision OpenShift démarre des pods sur les nouveaux nœuds d’infrastructure. Notez que certains nœuds, tels que prometheus-operator, restent sur les nœuds principaux.

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>

Système de noms de domaine (DNS)

Autoriser 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

Vérifiez que les pods DNS sont déployés sur tous les infra nœuds.

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

Pour mettre à niveau votre cluster, consultez Mettre à niveau un cluster Azure Red Hat OpenShift.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-07-10