Partilhar via

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

O Microsoft Azure Red Hat OpenShift permite que você use conjuntos de máquinas de infraestrutura para criar máquinas 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. Essas máquinas de infraestrutura não incorrem em custos OpenShift; eles incorrem apenas em custos de computação do Azure.

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

Cargas de trabalho qualificadas

As seguintes tarefas de infraestrutura não incorrem em subscrições de trabalhadores do Azure Red Hat OpenShift:

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

  • O roteador padrão

  • O registro de imagem de contêiner integrado

  • O controlador de ingresso baseado em HAProxy

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

  • Registo de logs agregados por clusters

Importante

A execução de cargas de trabalho diferentes dos tipos designados nos nós de infraestrutura pode afetar o SLA (Service Level Agreement, 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 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. Aplicam-se taxas de OpenShift a quaisquer nós extras.

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

  • Apenas as cargas de trabalho designadas para nodos 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 máquinas de infraestrutura

  1. Use o modelo de definição de manifesto para criar a definição de manifesto para seu conjunto de máquinas de infraestrutura.

  2. Substitua todos os campos entre colchetes angulares (<>) pelos 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 verification 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 modelo a seguir foi usado no procedimento anterior para criar a definição de manifesto para seu 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

A seguir estão 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 de um conjunto de máquinas específico:

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

Grupo de recursos de 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}'

Referência:

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 seu aplicativo tiver altos requisitos de recursos de ingresso, talvez seja melhor distribuí-los entre nós de trabalho ou um conjunto de máquinas dedicadas.

  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 Ingress está iniciando pods nos nós de infraestrutura nova:

    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>

Registo

  1. Defina o nodePlacement no registro como 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 de 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>

Monitorização de cluster

  1. Configurar a pilha de monitorização do cluster para usar os nós de infraestrutura.

    Isso substitui quaisquer outras personalizações para as stacks de monitorização do cluster, por isso, talvez queira integrar as personalizações existentes antes de proceder com a execução do 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 monitorização do OpenShift está iniciando 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. Permita que os pods DNS sejam executados nos nós da 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 agendados 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 Azure Red Hat OpenShift.

  • Last updated on