Freigeben über

Bereitstellen von Infrastrukturknoten in einem Azure Red Hat OpenShift-Cluster

Mit Microsoft Azure Red Hat OpenShift können Sie Infrastrukturcomputersätze verwenden, um Computer zu erstellen, die nur Infrastrukturkomponenten hosten, z. B. den Standardrouter, die integrierte Containerregistrierung und die Komponenten für Clustermetriken und -überwachung. Diese Infrastrukturcomputer verursachen keine OpenShift-Kosten; sie verursachen nur Azure Compute-Kosten.

In einer Produktionsbereitstellung empfiehlt es sich, 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 Maschinensätze erforderlich; eine für jede Verfügbarkeitszone. Anleitungen zur Größenanpassung von Infrastrukturknoten finden Sie unter Empfohlene Infrastrukturpraktiken.

Qualifizierte Arbeitslasten

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 Ingress-Controller

  • Die Sammlung von Clustermetriken oder der Überwachungsdienst, einschließlich Komponenten für die Überwachung benutzerdefinierter Projekte

  • Cluster-aggregierte Protokollierung

Von Bedeutung

Das Ausführen anderer Workloads als der angegebenen Arten auf den Infrastrukturknoten kann sich auf den Service Level Agreement (SLA) und die Stabilität des Clusters auswirken.

Voraussetzungen

Damit virtuelle Azure-Computer, die einem Cluster hinzugefügt werden, als Infrastrukturknoten und nicht als Arbeitsknoten erkannt werden und keine OpenShift-Gebühr in Rechnung gestellt wird, müssen die folgenden Kriterien erfüllt sein:

  • Bei den Knoten muss es sich nur um einen der folgenden Instanztypen handeln:

    • Standard_E4s_v5
    • Standard_E8s_v5
    • Standard_E16s_v5
    • Standard_E4as_v5
    • Standard_E8as_v5
    • Standard_E16as_v5

  • Es können nicht mehr als drei Knoten vorhanden sein. Allen zusätzlichen Knoten wird eine OpenShift-Gebühr berechnet.

  • Die Knoten müssen ein Azure-Tag von node_role: infra haben.

  • Es sind nur Workloads zulässig, die für Infrastrukturknoten bestimmt sind. Alle anderen Arbeitslasten würden diese Arbeitsknoten berücksichtigen und der Gebühr unterliegen. Diese Bezeichnung kann auch die SLA ungültig machen und die Stabilität des Clusters gefährden.

Infrastruktur-Maschinensätze erstellen

  1. Verwenden Sie die Manifestdefinitionsvorlage , um die Manifestdefinition für den Infrastrukturcomputersatz zu erstellen.

  2. Ersetzen Sie alle Felder zwischen eckigen Klammern (<>) durch Ihre spezifischen Werte.

    Ersetzen Sie z. B. location: <REGION> durch location: westus2

  3. Informationen zum Abrufen der erforderlichen Werte für die Manifestdefinitionsvorlage finden Sie unter Befehle und Werte.

  4. Erstellen Sie den Maschinensatz mit dem folgenden Befehl: oc create -f <machine-set-filename.yaml>

  5. Führen Sie den folgenden Befehl aus, um die Erstellung des Computersatzes zu überprüfen: oc get machineset -n openshift-machine-api

    Die Ausgabe des Überprüfungsbefehls sollte ähnlich wie die folgenden Werte 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

Vorlage für die Definition des Manifests

Die folgende Vorlage wurde im vorherigen Verfahren verwendet, um die Manifestdefinition für den Infrastrukturcomputersatz 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

Im Folgenden finden Sie einige allgemeine Befehle und Werte, die zum Erstellen und Ausführen der Vorlage verwendet werden.

Alle Maschinensätze auflisten:

oc get machineset -n openshift-machine-api

Rufen Sie Details für einen bestimmten Maschinensatz ab:

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

Virtuelles Netzwerk:

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 folgenden Anweisungen, um Ihre Infrastrukturworkloads auf die zuvor erstellten Infrastrukturknoten zu verschieben.

Eingang

Verwenden Sie dieses Verfahren für alle anderen Eingangscontroller, die Sie möglicherweise im Cluster haben. Wenn Ihre Anwendung über einen hohen Eingangsressourcenbedarf verfügt, ist es möglicherweise besser, sie über Arbeitsknoten oder einen dedizierten Computersatz zu verteilen.

  1. Stellen Sie nodePlacement auf ingresscontroller und node-role.kubernetes.io/infra ein und erhöhen Sie replicas, um die Anzahl der Infrastrukturknoten anzugleichen.

    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. Vergewissern Sie sich, dass der Ingress Controller-Operator Pods auf den neuen Infrastrukturknoten startet:

    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>

Registratur

  1. Setzen Sie nodePlacement in der Registrierung auf 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. Überprüfen Sie, ob der Registrierungsoperator Pods auf den neuen Infrastrukturknoten startet:

    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>

Clusterüberwachung

  1. Konfigurieren Sie den Überwachungsstapel für Cluster, damit die Infrastrukturknoten genutzt werden.

    Dadurch werden alle anderen Anpassungen an den Clusterüberwachungsstapel außer Kraft gesetzt, daher sollten Sie ihre vorhandenen Anpassungen zusammenführen, 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

  2. Stellen Sie sicher, dass der OpenShift Monitoring Operator die Pods auf den neuen Infrastrukturknoten startet. Beachten Sie, dass einige Knoten, wie zum Beispiel prometheus-operator, auf den Masterknoten verbleiben.

    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>

Domain Name System (DNS)

  1. Zulassen, dass die DNS-Pods auf den Infrastrukturknoten ausgeführt werden.

    oc edit dns.operator/default

    apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
name: default
spec:
nodePlacement:
  tolerations:
  - operator: Exists

  2. Stellen Sie sicher, dass DNS-Pods auf allen infra Knoten bereitgestellt 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

Verwandte Inhalte

Informationen zum Upgrade Ihres Clusters finden Sie unter Upgrade eines Azure Red Hat OpenShift-Clusters.

  • Last updated on