Bereitstellen von Infrastrukturknoten in einem Azure Red Hat OpenShift (ARO)-Cluster
Mit ARO können Sie Infrastrukturcomputersätze erstellen, auf denen nur Infrastrukturkomponenten wie der Standard-Router, die integrierte Containerregistrierung und die Komponenten für Cluster-Metriken und -Überwachung laufen. Diese Infrastrukturcomputer verursachen keine OpenShift-Kosten; sie verursachen nur Azure Compute-Kosten.
In einer Produktionsbereitstellung wird empfohlen, drei Computersätze für Infrastrukturkomponenten bereitzustellen. Jeder dieser Knoten kann in verschiedenen Verfügbarkeitszonen bereitgestellt werden, um die Verfügbarkeit zu erhöhen. Für diese Art von Konfiguration sind drei unterschiedliche Computersätze erforderlich; einer für jede Verfügbarkeitszone. Anleitungen zur Größenanpassung von Infrastrukturknoten finden Sie unter Empfohlene Infrastrukturpraktiken.
Qualifizierte Workloads
Die folgenden Infrastrukturarbeitslasten enthalten keine Azure Red Hat OpenShift-Workerabonnements:
Kubernetes und Azure Red Hat OpenShift-Steuerungsebenendienste, die auf Masters ausgeführt werden
Der Standardrouter
Die integrierte Containerimageregistrierung
Der HAProxy-basierte Eingangsdatencontroller
Die Sammlung von Clustermetriken oder der Überwachungsdienst, einschließlich Komponenten für die Überwachung benutzerdefinierter Projekte
Cluster-aggregierte Protokollierung
Wichtig
Die Ausführung anderer als der vorgesehenen Workloads auf den Infrastrukturknoten kann sich auf die Vereinbarung zum Servicelevel (SLA) und die Stabilität des Clusters auswirken.
Voraussetzungen
Damit Azure-VMs, die einem ARO-Cluster hinzugefügt werden, als Infrastrukturknoten (im Gegensatz zu weiteren Workerknoten) anerkannt werden und keine OpenShift-Gebühr erhoben wird, müssen die folgenden Kriterien erfüllt sein:
Die Knoten dürfen nur einem der folgenden Instanztypen angehören:
- Standard_E4s_v5
- Standard_E8s_v5
- Standard_E16s_v5
- Standard_E4as_v5
- Standard_E8as_v5
- Standard_E16as_v5
Es dürfen nicht mehr als drei Knoten vorhanden sein. Für jeden weiteren Knoten wird eine OpenShift-Gebühr erhoben.
Die Knoten müssen über ein Azure-Tag mit node_role: infra verfügen
Es sind nur Workloads erlaubt, die für Infrastrukturknoten bestimmt sind. Alle anderen Workloads würden diese als Workerknoten betrachten und somit der Gebühr unterliegen. Dies kann auch die SLA ungültig machen und die Stabilität des Clusters gefährden.
Erstellen von Infrastrukturcomputersätzen
Verwenden Sie die Vorlage unten, um die Manifestdefinition für Ihren Infrastruktur-Computersatz zu erstellen.
Ersetzen Sie alle Felder zwischen „<>“ durch Ihre spezifischen Werte.
Ersetzen Sie beispielsweise
location: <REGION>durchlocation: westus2.Hilfe zum Ausfüllen der erforderlichen Werte finden Sie unter Befehle und Werte.
Erstellen Sie den Computersatz mit dem folgenden Befehl:
oc create -f <machine-set-filename.yaml>Führen Sie den folgenden Befehl aus, um die Erstellung des Computersatzes zu überprüfen:
oc get machineset -n openshift-machine-apiDie Ausgabe des Überprüfungsbefehls sollte in etwa wie unten aussehen:
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
Manifestdefinitionsvorlage
Verwenden Sie die folgende Vorlage im obigen Verfahren, um die Manifestdefinition für Ihren Infrastruktur-Computersatz zu erstellen:
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
Befehle und Werte
Nachfolgend finden Sie einige gängige Befehle/Werte, die beim Erstellen und Ausführen der Vorlage verwendet werden.
Alle Computersätze auflisten:
oc get machineset -n openshift-machine-api
Abrufen von Details für einen bestimmten Computersatz:
oc get machineset <machineset_name> -n openshift-machine-api -o yaml
Clusterressourcengruppe:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'
Netzwerkressourcengruppe:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.networkResourceGroupName}'
Infrastruktur-ID:
oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'
Region:
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}'
Subnetz:
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}'
Verschieben von Workloads auf die neuen Infrastrukturknoten
Verwenden Sie die nachstehenden Anweisungen, um Ihre Infrastrukturworkloads auf die zuvor erstellten Infrastrukturknoten zu verschieben.
Eingehende Daten
Verwenden Sie dieses Verfahren für alle zusätzlichen Eingangsdatencontroller, die Sie möglicherweise im Cluster haben.
Hinweis
Wenn Ihre Anwendung sehr hohe Eingangsressourcenanforderungen aufweist, ist es möglicherweise besser, diese über Arbeitsknoten oder einen dedizierten Computersatz zu verteilen.
Legen Sie
nodePlacementfüringresscontrolleraufnode-role.kubernetes.io/infrafest, und erhöhen Siereplicasso, dass es der Anzahl der Infrastrukturknoten entspricht: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"}]}}}'Überprüfen Sie, ob der Eingangsdatencontroller-Operator Pods auf den neuen Infrastrukturknoten startet:
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>
Registrierung
Legen Sie
nodePlacementfür die Registrierung aufnode-role.kubernetes.io/infrafest: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"}]}}'Überprüfen Sie, ob der Registrierungsoperator Pods auf den neuen Infrastrukturknoten startet:
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>
Clusterüberwachung
Konfigurieren Sie den Clusterüberwachungsstapel für die Verwendung der Infrastrukturknoten.
Hinweis
Dadurch werden alle anderen Anpassungen des Clusterüberwachungsstapels außer Kraft gesetzt, so dass Sie Ihre bestehenden Anpassungen zusammenführen sollten, bevor Sie den Befehl ausführen.
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Überprüfen Sie, ob der OpenShift Monitoring-Operator Pods auf den neuen Infrastrukturknoten startet. Beachten Sie, dass einige Knoten (z. B.
prometheus-operator) auf Masterknoten verbleiben.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>
Domain Name System
Erlauben Sie den DNS-Pods, auf den Infrastrukturknoten zu laufen.
oc edit dns.operator/defaultapiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: nodePlacement: tolerations: - operator: ExistsÜberprüfen Sie, ob DNS-Pods auf allen Infrastrukturknoten geplant sind.
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