Implementar nodos de infraestructura en un clúster de Red Hat OpenShift (ARO) en Azure
ARO permite usar conjuntos de máquinas de infraestructura para crear máquinas que solo hospedan componentes de infraestructura, como el enrutador predeterminado, el registro de contenedor integrado y los componentes para las métricas y la supervisión del clúster. Estas máquinas de infraestructura no incurren en costos de OpenShift; solo incurren en costos de Azure Compute.
En una implementación de producción, se recomienda implementar tres conjuntos de máquinas para que alberguen componentes de infraestructura. Cada uno de estos nodos se puede implementar en diferentes zonas de disponibilidad para aumentar la disponibilidad. Este tipo de configuración requiere tres conjuntos de máquinas diferentes; una para cada zona de disponibilidad. Para obtener instrucciones sobre el ajuste de tamaño de los nodos de infraestructura, consulte Procedimientos recomendados de infraestructura.
Cargas de trabajo calificadas
Las siguientes cargas de trabajo de infraestructura no incurren en suscripciones de trabajo de Red Hat OpenShift en Azure:
Servicios de plano de control de Kubernetes y de Red Hat OpenShift en Azure que se ejecutan en maestros
El enrutador predeterminado
El registro de imágenes de contenedor integrado
El controlador de entrada basado en HAProxy
La recopilación de métricas del clúster o el servicio de supervisión, incluidos los componentes para supervisar proyectos definidos por el usuario
Registro agregado por clúster
Importante
La ejecución de cargas de trabajo distintas de los tipos designados en los nodos de infraestructura puede afectar al Acuerdo de Nivel de Servicio (SLA) y a la estabilidad del clúster.
Antes de empezar
Para que las máquinas virtuales de Azure agregadas a un clúster de ARO se reconozcan como nodos de infraestructura (en lugar de más nodos de trabajo) y no se le cobre una tarifa de OpenShift, se deben cumplir los siguientes criterios:
Los nodos deben ser solo de uno de los siguientes tipos de instancia:
- Standard_E4s_v5
- Standard_E8s_v5
- Standard_E16s_v5
- Standard_E4as_v5
- Standard_E8as_v5
- Standard_E16as_v5
No puede haber más de tres nodos. Los nodos adicionales tienen un cargo de OpenShift.
Los nodos deben tener una etiqueta de Azure de node_role: infra
Solo se permiten cargas de trabajo designadas para los nodos de infraestructura. Las demás cargas de trabajo las considerarían nodos de trabajo y, por tanto, estarían sujetas a la tarifa. Esto también puede invalidar el Acuerdo de Nivel de Servicio y poner en peligro la estabilidad del clúster.
Creación de conjuntos de máquinas de infraestructura
Use la plantilla siguiente para crear la definición de manifiesto para el conjunto de máquinas de infraestructura.
Reemplace todos los campos entre "<>" por sus valores específicos.
Por ejemplo, reemplace
location: <REGION>porlocation: westus2.Para obtener ayuda para rellenar los valores necesarios, consulte Comandos y valores.
Cree el conjunto de máquinas con el siguiente comando:
oc create -f <machine-set-filename.yaml>Para comprobar la creación del conjunto de máquinas, ejecute el siguiente comando:
oc get machineset -n openshift-machine-apiLa salida del comando de comprobación debe ser similar a la siguiente:
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
Plantilla de definición de manifiesto
Use la plantilla siguiente en el procedimiento anterior para crear la definición de manifiesto para el conjunto de máquinas de infraestructura:
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 y valores
A continuación se muestran algunos comandos o valores comunes que se usan al crear y ejecutar la plantilla.
Enumerar todos los conjuntos de máquinas:
oc get machineset -n openshift-machine-api
Obtener los detalles de un conjunto de máquinas específico:
oc get machineset <machineset_name> -n openshift-machine-api -o yaml
Grupo de recursos de clúster:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'
Grupo de recursos de red:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.networkResourceGroupName}'
Identificador de infraestructura:
oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'
Región:
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}'
Subred:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}'
Versión:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.version}'
Red virtual:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}'
Traslado de cargas de trabajo a los nuevos nodos de infraestructura
Siga las instrucciones siguientes para trasladar las cargas de trabajo de infraestructura a los nodos de infraestructura creados anteriormente.
Entrada
Use este procedimiento para los controladores de entrada adicionales que pueda tener en el clúster.
Nota:
Si la aplicación tiene requisitos de recursos de entrada muy altos, puede ser mejor distribuirlos entre nodos de trabajo o a un conjunto de máquinas dedicado.
Establezca
nodePlacementdeingresscontrollerennode-role.kubernetes.io/infray aumentereplicaspara que coincida con el número de nodos de infraestructura: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"}]}}}'Compruebe que el operador del controlador de entrada inicie pods en los nuevos nodos de infraestructura:
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>
Registro
Establezca
nodePlacementdel Registro ennode-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"}]}}'Compruebe que el operador del Registro inicie pods en los nuevos nodos de infraestructura:
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>
Supervisión de clústeres
Configure la pila de supervisión del clúster para usar los nodos de infraestructura.
Nota:
Esto invalidará cualquier otra personalización en la pila de supervisión del clúster, por lo que es posible que quiera combinar las personalizaciones existentes antes de ejecutar el 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" EOFCompruebe que el operador de supervisión de OpenShift inicie pods en los nuevos nodos de infraestructura. Tenga en cuenta que algunos nodos (como
prometheus-operator) permanecerán en los nodos maestros.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>
DNS
Permita que los pods DNS se ejecuten en los nodos de infraestructura.
oc edit dns.operator/defaultapiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: nodePlacement: tolerations: - operator: ExistsCompruebe que los pods DNS están programados en todos los nodos de infraestructura.
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