Revisión del estado (valores health, status y states) del nodo maestro

Estados de clúster y maestro

Visión general del impacto de una interrupción en el nodo maestro

El nodo maestro de Red Hat OpenShift es el componente principal que mantiene el clúster en funcionamiento. El nodo maestro almacena los recursos de clúster y sus configuraciones en la base de datos etcd, que sirve como único punto fiable para el clúster. El servidor de API de Red Hat OpenShift es el punto de entrada principal para todas las solicitudes de gestión del clúster procedentes de los nodos trabajadores destinadas al nodo maestro, o cuando desea interactuar con los recursos de clúster.

Si se produce una anomalía maestra, las cargas de trabajo continúan ejecutándose en los nodos de trabajador, pero no puede utilizar los mandatos de oc para trabajar con los recursos de clúster o ver el estado del clúster hasta que el servidor de la API de Red Hat OpenShift en el nodo maestro vuelva a estar activo. Si un pod se desactiva durante la caída del nodo maestro, el pod no se puede volver a planificar hasta que el nodo del trabajador vuelva a acceder al servidor de la API de Red Hat OpenShift.

Durante una interrupción del nodo maestro, todavía puede ejecutar mandatos ibmcloud oc en la API de IBM Cloud Kubernetes Service para trabajar con los recursos de la infraestructura, como nodos trabajadores o VLAN. Si cambia la configuración del clúster actual añadiendo o eliminando nodos de trabajador en el clúster, los cambios no se realizan hasta que se haga una copia de seguridad del nodo maestro.

No reinicie o rearranque un nodo trabajador durante una interrupción del nodo maestro. Esta acción elimina los pods del nodo trabajador. Como el servidor de la API de Kubernetes no está disponible, los pods no se pueden volver a planificar en otros nodos de trabajador del clúster.