Condividi tramite

Distribuire i nodi dell'infrastruttura in un cluster Azure Red Hat OpenShift (ARO)

  • Articolo

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

  1. Usare il modello seguente per creare la definizione del manifesto per il set di computer dell'infrastruttura.

  2. Sostituire tutti i campi tra "<>" con i valori specifici.

    Sostituire ad esempio location: <REGION> con location: westus2

  3. Per informazioni sulla compilazione dei valori necessari, vedere Comandi e valori.

  4. Creare il set di computer con il comando seguente: oc create -f <machine-set-filename.yaml>

  5. Per verificare la creazione del set di computer, eseguire il comando seguente: oc get machineset -n openshift-machine-api

    L'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: aro-vnet 
          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.

  1. Impostare su ingresscontroller node-role.kubernetes.io/infra e aumentare l'oggetto nodePlacement replicas in 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"}]}}}'

  2. Verificare che l'operatore controller in ingresso avvii i pod nei nuovi nodi dell'infrastruttura:

    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>

Registro

  1. Impostare nel nodePlacement Registro di sistema su 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. 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 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>

Monitoraggio del cluster

  1. 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"
EOF

  2. Verificare 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 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

  1. Consentire l'esecuzione dei pod DNS nei nodi dell'infrastruttura.

    oc edit dns.operator/default

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

  2. Verificare 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