Compartilhar via

Implantar nós de infraestrutura em um cluster do Red Hat OpenShift no Azure

O Microsoft Azure Red Hat OpenShift permite que você use conjuntos de máquinas de infraestrutura para criar computadores que hospedam apenas componentes de infraestrutura, como o roteador padrão, o registro de contêiner integrado e os componentes para métricas e monitoramento de cluster. Esses computadores de infraestrutura não incorrem em custos do OpenShift; eles só incorrem em custos de Computação do Azure.

Em uma implantação de produção, a recomendação é que você implante três conjuntos de máquinas para manter componentes de infraestrutura. Cada um desses nós pode ser implantado em zonas de disponibilidade diferentes para aumentar a disponibilidade. Esse tipo de configuração requer três conjuntos de computadores diferentes; uma para cada zona de disponibilidade. Para obter diretrizes de dimensionamento de nós de infraestrutura, consulte as práticas de infraestrutura recomendadas.

Cargas de trabalho qualificadas

As seguintes cargas de trabalho de infraestrutura não incorrem em assinaturas de trabalho do Red Hat OpenShift no Azure:

  • Serviços de plano de controle do Kubernetes e do Red Hat OpenShift do Azure executados em mestres

  • O roteador padrão

  • O registro de imagem de contêiner integrado

  • O controlador de entrada baseado em HAProxy

  • A coleção de métricas de cluster ou o serviço de monitoramento, incluindo componentes para monitorar projetos definidos pelo usuário

  • Log agregado por cluster

Importante

A execução de cargas de trabalho diferentes dos tipos designados nos nós de infraestrutura pode afetar o SLA (Contrato de Nível de Serviço) e a estabilidade do cluster.

Pré-requisitos

Para que as máquinas virtuais do Azure adicionadas a um cluster sejam reconhecidas como nós de infraestrutura, em vez de nós de trabalho, e não sejam cobradas uma taxa do OpenShift, os seguintes critérios devem ser atendidos:

  • Os nós devem ser apenas um dos seguintes tipos de instância:

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

  • Não pode haver mais do que três nós. Todos os nós extras são cobrados por uma taxa do OpenShift.

  • Os nós devem ter uma tag do Azure de node_role: infra

  • Somente cargas de trabalho designadas para nós de infraestrutura são permitidas. Todas as outras cargas de trabalho considerariam esses nós de trabalho e estariam sujeitas à taxa. Essa designação também pode invalidar o SLA e comprometer a estabilidade do cluster.

Criar conjuntos de infraestrutura de máquinas

  1. Use o modelo de definição de manifesto para criar a definição de manifesto para o conjunto de computadores de infraestrutura.

  2. Substitua todos os campos entre colchetes angulares (<>) por seus valores específicos.

    Por exemplo, substitua location: <REGION> por location: westus2

  3. Para obter os valores necessários para o modelo de definição de manifesto, consulte Comandos e valores.

  4. Crie o conjunto de máquinas com o seguinte comando: oc create -f <machine-set-filename.yaml>

  5. Para verificar a criação do conjunto de máquinas, execute o seguinte comando: oc get machineset -n openshift-machine-api

    A saída do comando de verificação deve ser semelhante aos seguintes valores:

    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

Modelo de definição de manifesto

O template a seguir foi usado no procedimento anterior para criar a definição de manifesto para o conjunto de máquinas de infraestrutura.

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

Comandos e valores

Veja a seguir alguns comandos e valores comuns que são usados para criar e executar o modelo.

Listar todos os conjuntos de máquinas:

oc get machineset -n openshift-machine-api

Obtenha detalhes para um conjunto de máquinas específico:

oc get machineset <machineset_name> -n openshift-machine-api -o yaml

Grupo de recursos do cluster:

oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'

Grupo de recursos de rede:

oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.networkResourceGroupName}'

ID da infraestrutura:

oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'

Região:

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

Sub-rede:

oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}'

Versão:

oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.version}'

Rede virtual:

oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}'

Movendo cargas de trabalho para os novos nós de infraestrutura

Use as instruções a seguir para mover suas cargas de trabalho de infraestrutura para os nós de infraestrutura criados anteriormente.

Entrada

Use este procedimento para quaisquer outros controladores de entrada que você possa ter no cluster. Se o aplicativo tiver altos requisitos de recursos de ingresso, talvez seja melhor distribuí-los entre nós de processamento ou um conjunto de máquinas dedicado.

  1. Defina o nodePlacement no ingresscontroller para node-role.kubernetes.io/infra e aumente o replicas para corresponder ao número de nós de infraestrutura.

    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. Verifique se o Operador do Controlador de Entrada está iniciando pods nos novos nós de infraestrutura:

    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. Defina o nodePlacement no registro para 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. Verifique se o Operador do Registro está iniciando pods nos novos nós de infraestrutura:

    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>

Monitoramento do cluster

  1. Configure sua pilha de monitoramento de cluster de modo a utilizar os nós de infraestrutura.

    Isso substitui todas as outras personalizações na pilha de monitoramento do cluster, portanto, talvez você queira mesclar suas personalizações existentes antes de executar o 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. Verifique se o Operador de Monitoramento do OpenShift está iniciando os pods nos novos nós de infraestrutura. Observe que alguns nós, como prometheus-operator, permanecem em nós mestres.

    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. Permitir que os pods DNS sejam executados nos nós de infraestrutura.

    oc edit dns.operator/default

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

  2. Verifique se os pods DNS estão alocados em todos os infra nós.

    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

Conteúdo relacionado

Para atualizar seu cluster, consulte Atualizar um cluster do Red Hat OpenShift do Azure.

  • Last updated on