Distribuire i nodi dell'infrastruttura in un cluster Azure Red Hat OpenShift (ARO)
ARO consente di usare i set di computer di infrastruttura per creare computer che ospitano solo componenti dell'infrastruttura, ad esempio il router predefinito, il registro contenitori integrato e i componenti per le metriche e il monitoraggio del cluster. Questi computer dell'infrastruttura non comportano costi openshift; comportano solo costi di calcolo di Azure.
In una distribuzione di produzione è consigliabile distribuire tre set di computer per contenere i componenti dell'infrastruttura. Ognuno di questi nodi può essere distribuito in zone di disponibilità diverse per aumentare la disponibilità. Questo tipo di configurazione richiede tre set di computer diversi; uno per ogni zona di disponibilità. Per indicazioni sul dimensionamento dei nodi dell'infrastruttura, vedere Procedure consigliate per l'infrastruttura.
Carichi di lavoro qualificati
I carichi di lavoro dell'infrastruttura seguenti non comportano sottoscrizioni di lavoro di Azure Red Hat OpenShift:
Servizi del piano di controllo Kubernetes e Azure Red Hat OpenShift eseguiti nei master
Router predefinito
Registro immagini del contenitore integrato
Controller di ingresso basato su HAProxy
Raccolta di metriche del cluster o servizio di monitoraggio, inclusi i componenti per il monitoraggio dei progetti definiti dall'utente
Registrazione aggregata del cluster
Importante
L'esecuzione di carichi di lavoro diversi dai tipi designati nei nodi dell'infrastruttura può influire sul Contratto di servizio e sulla stabilità del cluster.
Operazioni preliminari
Affinché le macchine virtuali di Azure aggiunte a un cluster ARO vengano riconosciute come nodi dell'infrastruttura (anziché più nodi di lavoro) e non vengano addebitati costi di OpenShift, è necessario soddisfare i criteri seguenti:
I nodi devono essere solo uno dei tipi di istanza seguenti:
- Standard_E4s_v5
- Standard_E8s_v5
- Standard_E16s_v5
- Standard_E4as_v5
- Standard_E8as_v5
- Standard_E16as_v5
Non possono essere presenti più di tre nodi. Eventuali nodi aggiuntivi vengono addebitati costi per OpenShift.
I nodi devono avere un tag di Azure di node_role: infra
Sono consentiti solo i carichi di lavoro designati per i nodi dell'infrastruttura. Tutti gli altri carichi di lavoro considererebbero questi nodi di lavoro e quindi soggetti alla tariffa. Ciò può anche invalidare il contratto di servizio e compromettere la stabilità del cluster.
Creazione di set di computer dell'infrastruttura
Usare il modello seguente per creare la definizione del manifesto per il set di computer dell'infrastruttura.
Sostituire tutti i campi tra "<>" con i valori specifici.
Sostituire ad esempio
location: <REGION>conlocation: westus2Per informazioni sulla compilazione dei valori necessari, vedere Comandi e valori.
Creare il set di computer con il comando seguente:
oc create -f <machine-set-filename.yaml>Per verificare la creazione del set di computer, eseguire il comando seguente:
oc get machineset -n openshift-machine-apiL'output del comando di verifica dovrebbe essere simile al seguente:
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
Modello di definizione del manifesto
Usare il modello seguente nella procedura precedente per creare la definizione del manifesto per il set di computer dell'infrastruttura:
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
Comandi e valori
Di seguito sono riportati alcuni comandi/valori comuni usati durante la creazione e l'esecuzione del modello.
Elencare tutti i set di computer:
oc get machineset -n openshift-machine-api
Ottenere i dettagli per un set di computer specifico:
oc get machineset <machineset_name> -n openshift-machine-api -o yaml
Gruppo di risorse cluster:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'
Gruppo di risorse di rete:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.networkResourceGroupName}'
ID infrastruttura:
oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'
Area:
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}'
Subnet:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}'
Versione:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.version}'
Rete virtuale:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}'
Spostamento dei carichi di lavoro nei nuovi nodi dell'infrastruttura
Usare le istruzioni seguenti per spostare i carichi di lavoro dell'infrastruttura nei nodi dell'infrastruttura creati in precedenza.
Dati in ingresso
Usare questa procedura per eventuali controller di ingresso aggiuntivi presenti nel cluster.
Nota
Se l'applicazione ha requisiti di risorse in ingresso molto elevati, potrebbe essere preferibile distribuirli tra nodi di lavoro o un set di computer dedicato.
Impostare su
ingresscontrollernode-role.kubernetes.io/infrae aumentare l'oggettonodePlacementreplicasin modo che corrisponda al numero di nodi dell'infrastruttura: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"}]}}}'Verificare che l'operatore controller in ingresso avvii i pod nei nuovi nodi dell'infrastruttura:
oc -n openshift-ingress get pods -o wideNAME 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
Impostare nel
nodePlacementRegistro di sistema sunode-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"}]}}'Verificare che l'operatore del Registro di sistema avvii i pod nei nuovi nodi dell'infrastruttura:
oc -n openshift-image-registry get pods -l "docker-registry" -o wideNAME 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>
Monitoraggio del cluster
Configurare lo stack di monitoraggio del cluster per l'uso dei nodi dell'infrastruttura.
Nota
Questa operazione eseguirà l'override di tutte le altre personalizzazioni nello stack di monitoraggio del cluster, pertanto è consigliabile unire le personalizzazioni esistenti prima di eseguire il 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" EOFVerificare che l'operatore di monitoraggio OpenShift avvii i pod nei nuovi nodi dell'infrastruttura. Si noti che alcuni nodi (ad esempio
prometheus-operator) rimarranno nei nodi master.oc -n openshift-monitoring get pods -o wideNAME 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
Consentire l'esecuzione dei pod DNS nei nodi dell'infrastruttura.
oc edit dns.operator/defaultapiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: nodePlacement: tolerations: - operator: ExistsVerificare che i pod DNS siano pianificati in tutti i nodi 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