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
Utilisez le modèle ci-dessous pour créer la définition de manifeste de votre jeu d’ordinateurs d’infrastructure.
Remplacez tous les champs entre « <> » par vos valeurs spécifiques.
Par exemple, remplacez
location: <REGION>
parlocation: westus2
.Pour obtenir de l’aide sur le remplissage des valeurs requises, consultez Commandes et valeurs.
Créez l’ensemble d’ordinateurs avec la commande suivante :
oc create -f <machine-set-filename.yaml>
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é.
Définissez le
nodePlacement
sur leingresscontroller
surnode-role.kubernetes.io/infra
et augmentez lereplicas
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"}]}}}'
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
Définissez le
nodePlacement
du registre surnode-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 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
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
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
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