Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Red Hat OpenShift en Microsoft Azure permite usar conjuntos de máquinas de infraestructura para crear máquinas que solo hospede 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 Proceso de Azure.
En una implementación de producción, la recomendación es implementar tres conjuntos de máquinas para contener 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 de ajuste de tamaño de nodo 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 del plano de control de Kubernetes y Red Hat OpenShift de Azure que se ejecutan en nodos maestros
El enrutador predeterminado
Registro de imágenes de contenedor integrado
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 de 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 la estabilidad del clúster.
Prerrequisitos
Para que las máquinas virtuales de Azure agregadas a un clúster se reconozcan como nodos de infraestructura, en lugar de nodos de trabajo, y no se les cobrará una tarifa de OpenShift, se deben cumplir los siguientes criterios:
Los nodos deben ser solo 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. Se aplica una tarifa de OpenShift a cualquier nodo adicional.
Los nodos deben tener una etiqueta de Azure.
node_role: infraSolo se permiten cargas de trabajo designadas para los nodos de infraestructura. Todas las demás cargas de trabajo considerarían estos nodos de trabajo y estarían sujetos a la tarifa. Esta designación también podría 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
Utilice la plantilla de definición del manifiesto para crear la definición del manifiesto para su conjunto de máquinas de infraestructura.
Reemplace todos los campos entre corchetes angulares (
<>) por sus valores específicos.Por ejemplo, reemplace
location: <REGION>porlocation: westus2Para obtener los valores necesarios para la plantilla de definición de manifiesto, 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 los siguientes 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
Plantilla de definición de manifiesto
La plantilla siguiente se usó en el procedimiento anterior para crear la definición del 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 y valores comunes que se usan para crear y ejecutar la plantilla.
Enumerar todos los conjuntos de máquinas:
oc get machineset -n openshift-machine-api
Obtenga 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 mover las cargas de trabajo de infraestructura a los nodos de infraestructura creados anteriormente.
Entrada
Use este procedimiento para cualquier otro controlador de entrada que pueda tener en el clúster. Si la aplicación tiene requisitos elevados de recursos de entrada, es posible que sea mejor distribuirlos entre nodos de trabajo o un conjunto de máquinas dedicado.
Configure el
nodePlacementen elingresscontrolleranode-role.kubernetes.io/infray aumente elreplicaspara 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 Ingress Controller Operator está iniciando 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 el
nodePlacementen el 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"}]}}'Verifique que el gestor del registro está iniciando 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.
Esto anula cualquier otra personalización en la pila de supervisión del clúster, por lo que podría querer 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 está iniciando pods en los nuevos nodos de infraestructura. Tenga en cuenta que algunos nodos, como
prometheus-operator, permanecen en 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 (Sistema de Nombres de Dominio)
Permitir 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
infranodos.oc get ds/dns-default -n openshift-dnsNAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE dns-default 7 7 7 7 7 kubernetes.io/os=linux 35d
Contenido relacionado
Para actualizar el clúster, consulte Actualización de un clúster de Red Hat OpenShift en Azure.