Componentes maestros de Red Hat OpenShift

Revise los siguientes componentes del nodo maestro gestionado por IBM del clúster de Red Hat OpenShift on IBM Cloud.

No puede modificar estos componentes. IBM gestiona los componentes y los actualiza automáticamente durante las actualizaciones de parche maestro.

En OpenShift Container Platform 4, el operador correspondiente configura muchos componentes para facilitar la gestión. En la tabla siguiente se describen estas operaciones y estos componentes, para mostrar la funcionalidad que proporciona el componente en el clúster.

Arrendamiento único

El nodo maestro y todos los componentes de nodo maestro están dedicados únicamente a usted, y no se comparten con otros clientes de IBM.

Réplicas

Los componentes de nodo maestro, incluido el servidor de API de Red Hat OpenShift y el almacén de datos etcd, tienen tres réplicas y, si se encuentran en un área metropolitana multizona, se distribuyen entre las zonas para ofrecer una mayor disponibilidad. Se hace copia de seguridad de los componentes de nodo maestro cada 8 horas.

cloud-controller-manager

El gestor de controlador de nube gestiona componentes específicos del proveedor de la nube, como por ejemplo el equilibrador de carga de IBM Cloud.

cluster-health

El componente de estado del clúster supervisa el estado del clúster y se integra con las métricas y con la supervisión de IBM Cloud para el servicio.

cluster-policy-controller

La página cluster-policy-controller mantiene los recursos de políticas necesarios para crear pods dentro del clúster.

cluster-version-operator

El operador de versión del clúster (CVO) instala y actualiza otros operadores que se ejecutan en el clúster. Para más información, consulte el proyecto GitHub.

control-plane-operator

El operador de plano de control gestiona la instalación y la actualización de los componentes de plano de control en el nodo maestro.

etcd, etcd-molecule, etcd-operator

etcd es un almacén de valores de claves de alta disponibilidad que almacena el estado de todos los recursos de Kubernetes de un clúster, como servicios, despliegues y pods. Se realiza una copia de seguridad de los datos de etcd cada 8 horas en una instancia de almacenamiento cifrada que gestiona IBM.

kube-controller-manager, openshift-controller-manager

El controlador Kubernetes vigila el estado de los objetos dentro del clúster, como el conjunto de réplicas de una carga de trabajo. Cuando cambia el estado de un objeto, por ejemplo cuando cae un pod de un conjunto de réplicas, el gestor del controlador inicia acciones de corrección para conseguir el estado necesario. El controlador de Red Hat OpenShift realiza la misma función para los objetos que son específicos de la API de Red Hat OpenShift, como por ejemplo proyectos.

kube-scheduler

El programador de Kubernetes vigila los pods recién creados y decide dónde desplegarlos en función de la capacidad, las necesidades de rendimiento, las restricciones de las políticas, las especificaciones antiafinidad y los requisitos de la carga de trabajo. Si no se encuentra ningún nodo trabajador que se ajuste a los requisitos, el pod no se despliega en el clúster.

manifests-bootstrapper

El trabajo manifests-boot-strapper configura el maestro con los certificados necesarios para unirse como nodo maestro del clúster.

oauth-openshift

El servidor de OAuth integrado se configura automáticamente de modo que se integre con IBM Cloud Identity and Access Management (IAM). No puede añadir otros proveedores de identidad soportados al clúster. Para obtener más información sobre cómo autenticarse con el clúster a través de IAM, consulte Acceso a clústeres de Red Hat OpenShift.

openshift-apiserver, openshift-apiserver-operator, kube-apiserver

El servidor de API constituye el punto de entrada principal para todas las solicitudes de gestión del clúster procedentes del nodo trabajador destinadas al nodo maestro. El servidor de API valida y procesa las solicitudes que cambian el estado de los objetos de Kubernetes, como por ejemplo los pods o servicios, y los objetos de Red Hat OpenShift, como proyectos o usuarios. A continuación, el servidor de API almacena este estado en el almacén de datos etcd.

konnectivity-server, konnectivity-operator

El servidor Konnectivity trabaja con el agente Konnectivity para conectar de forma segura el nodo maestro con el nodo trabajador. Esta conexión admite llamadas apiserver proxy a los pods y servicios, llamadas oc exec, attach y logs a kubelet y mutación y validación de webhooks.

Controladores de admisión

Los controladores de admisiones se implementan para características específicas en clústeres de Red Hat OpenShift on IBM Cloud. Con los controladores de admisiones puede configurar políticas en el clúster que determinen si se permite o no una acción concreta en el clúster. En la política, puede especificar condiciones cuando un usuario no puede realizar una acción, aunque esta acción forme parte de los permisos generales que ha asignado al usuario utilizando RBAC. Por lo tanto, los controladores de admisión pueden proporcionar una capa adicional de seguridad para el clúster antes de que el servidor de la API de Red Hat OpenShift procese una solicitud de API. Cuando se crea un clúster Red Hat OpenShift, los siguientes controladores de admisión Kubernetes se instalan automáticamente en el orden dado en el maestro Red Hat OpenShift, que no puede ser cambiado por el usuario:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• ResourceQuota
• StorageObjectInUseProtection
• PersistentVolumeClaimResize
• Priority
• BuildByStrategy
• OriginPodNodeEnvironment
• PodNodeSelector
• ExternalIPRanger
• NodeRestriction
• SecurityContextConstraint
• SCCExecRestrictions
• PersistentVolumeLabel
• OwnerReferencesPermissionEnforcement
• PodTolerationRestriction
• openshift.io/JenkinsBootstrapper
• openshift.io/BuildConfigSecretInjector
• openshift.io/ImageLimitRange
• openshift.io/RestrictedEndpointsAdmission
• openshift.io/ImagePolicy
• openshift.io/IngressAdmission
• openshift.io/ClusterResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

Puede instalar sus propios controladores de admisión en el clúster o elegir entre los controladores de admisión opcionales que proporciona Red Hat OpenShift on IBM Cloud. Aplicación de la seguridad de la imagen del contenedor: Instale Portieris para bloquear el despliegue de contenedores a partir de imágenes no firmadas.

Si ha instalado controladores de admisión manualmente y ya no desea utilizarlos, elimínelos por completo. Si los controladores de admisión no se eliminan del todo, es posible que bloqueen todas las acciones que desee realizar en el clúster.

Red Hat OpenShift componentes del nodo trabajador

Revise los siguientes componentes de los nodos trabajadores gestionados por el cliente del clúster de Red Hat OpenShift on IBM Cloud.

Estos componentes se ejecutan en los nodos trabajadores porque puede utilizarlos con las cargas de trabajo que despliega en el clúster. Por ejemplo, las aplicaciones pueden utilizar un operador del OperatorHub que ejecuta un contenedor desde una imagen del registro interno. Usted es el responsable del uso de estos componentes, pero IBM proporciona actualizaciones para los mismos en las actualizaciones de parche para nodos trabajadores que decida aplicar.

En OpenShift Container Platform, muchos componentes están configurados por el operador correspondiente para facilitar la gestión. En la tabla siguiente se describen estas operaciones y estos componentes, para mostrar la funcionalidad que proporciona el componente en el clúster.

Arrendamiento único

Los nodos trabajadores y todos los componentes de los nodos trabajadores están dedicados únicamente a usted, y no se comparten con otros clientes de IBM. Sin embargo, si utiliza máquinas virtuales de nodo trabajador, el hardware subyacente podría compartirse con otros clientes de IBM en función del nivel de aislamiento de hardware que elija.

Sistema operativo

Para obtener una lista de los sistemas operativos soportados por versión de clúster, consulte la Información de versión.

Tiempo de ejecución del contenedor CRI-O

Sus nodos trabajadores se instalan con CRI-O como interfaz de ejecución del contenedor. Para obtener más información, consulte Tiempo de ejecución del contenedor.

Proyectos

Red Hat OpenShift organiza los recursos en proyectos, que son espacios de nombres de Kubernetes con anotaciones, e incluye muchos más componentes que los clústeres de Kubernetes de comunidad para ejecutar características de Red Hat OpenShift como el catálogo. En las siguientes filas se describen determinados componentes de los proyectos. Para más información, consulte Trabajar con proyectos.

calico-system, tigera-operator

Calico gestiona las políticas de red para el clúster, e incluye algunos componentes para gestionar la conectividad de red de los contenedores, la asignación de direcciones IP y el control del tráfico de red. El operador de Tigera instala y gestiona el ciclo de vida de los componentes de Calico.

default

Este proyecto se utiliza si no se especifica un proyecto o se crea un proyecto para los recursos de Kubernetes.

ibm-system

Este proyecto incluye el despliegue ibm-cloud-provider-ip que funciona con keepalived para proporcionar comprobación de estado y equilibrio de carga de capa 4 para las solicitudes dirigidas a los pods de la app.

kube-system

Este proyecto incluye muchos componentes que se utilizan para ejecutar Kubernetes en el nodo trabajador.

• ibm-master-proxy: ibm-master-proxy es un conjunto de daemons que reenvía solicitudes del nodo de trabajador a las direcciones IP de las réplicas de nodo maestro de alta disponibilidad. En clústeres de una sola zona, el maestro tiene tres réplicas en distintos hosts. Para clústeres que se encuentran en una zona con capacidad multizona, el maestro tiene tres réplicas que se dispersan entre zonas. Un equilibrador de carga de alta disponibilidad reenvía las solicitudes dirigidas al nombre de dominio maestro a las réplicas maestras.
• kubelet: el kubelet es un agente de nodo de trabajador que se ejecuta en cada nodo de trabajador y es responsable de supervisar el estado de los pods que se ejecutan en el nodo de trabajador y de ver los sucesos que envía el servidor de API. Basándose en los sucesos, el kubelet crea o elimina pods, garantiza sondeos de actividad y de preparación e informa sobre el estado de los pods al servidor de API.
• vpn: El agente Konnectivity trabaja con el servidor Konnectivity para conectar de forma segura el nodo maestro con el nodo trabajador. Esta conexión admite llamadas apiserver proxy a los pods y servicios, y llamadas oc exec, attach y logs a kubelet.
• Otros componentes: el proyecto kube-system también incluye componentes para gestionar recursos proporcionados por IBM como, por ejemplo, los plugins de almacenamiento de archivos y bloques, el equilibrador de carga de aplicaciones (ALB) de Ingress y keepalived.

openshift-cloud-credential-operator

El operador de credenciales de nube gestiona un controlador para los componentes de Red Hat OpenShift que solicitan credenciales del proveedor de nube. El controlador garantiza que solo se utilicen las credenciales necesarias para la operación, y no permisos elevados, como admin. Para más información, consulte el proyecto GitHub.

openshift-cluster-node-tuning-operator

IBM gestiona el operador de ajuste de nodos, que ejecuta un conjunto de demonios en cada nodo trabajador del clúster para ajustar los nodos trabajadores.

openshift-cluster-samples-operator

El operador de muestras gestiona determinados flujos de imágenes y plantillas que vienen por defecto con el clúster Red Hat OpenShift. Puede desplegar estas plantillas desde la perspectiva de Desarrollador en la consola web de Red Hat OpenShift.

openshift-cluster-storage-operator

El operador de almacenamiento de clúster se asegura de que se haya establecido una clase de almacenamiento predeterminada.

openshift-console, openshift-console-operator

La consola web de Red Hat OpenShift es una interfaz basada en web fácil de usar que puede utilizar para gestionar los recursos de Red Hat OpenShift y Kubernetes que se ejecutan en el clúster. También puede utilizar la consola para visualizar una señal de oc login para autenticarse en el clúster desde una CLI. Para obtener más información, consulte Navegación por la consola de Red Hat OpenShift.

openshift-dns, openshift-dns-operator

El proyecto DNS incluye los componentes para validar el tráfico de red de entrada con las reglas de iptables configuradas en el nodo trabajador y envía por proxy las solicitudes que tienen permiso para entrar en el clúster o para salir del mismo.

openshift-image-registry

Red Hat OpenShift proporciona un registro de imágenes de contenedor interno que puede usar para administrar y ver imágenes localmente a través de la consola. De forma alternativa, puede configurar IBM Cloud Container Registry privado o importar imágenes desde IBM Cloud Container Registry en el registro interno. El registro interno viene con un volumen File Storage for Classic en su cuenta de infraestructura IBM Cloud para almacenar las imágenes del registro. El volumen de almacenamiento de archivos se suministra mediante la reclamación de volumen persistente (PVC) image-registry-storage.

openshift-ingress, openshift-ingress-operator

Red Hat OpenShift utiliza rutas para exponer directamente el servicio de una aplicación en un nombre de host para que los clientes externos puedan acceder al servicio. Para crear rutas, el clúster utiliza el operador de Ingress. También puede utilizar Ingress para exponer apps externamente y personalizar el direccionamiento. Ingress consta de tres componentes: el operador de Ingress, el controlador de Ingress y los recursos de ruta. El controlador de Ingress correlaciona el servicio con el nombre de host. De forma predeterminada, el controlador de Ingress incluye dos réplicas. Asegúrese de que el clúster tenga al menos dos nodos de trabajador para que el controlador de Ingress pueda ejecutarse en hosts de cálculo diferentes para garantizar una mayor disponibilidad.

openshift-marketplace

El mercado incluye el OperatorHub que viene por defecto con el clúster Red Hat OpenShift. El OperatorHub incluye operadores de Red Hat y de otros proveedores. Tenga en cuenta que estos operadores los proporciona la comunidad, es posible que no se integren con el clúster y no reciben soporte IBM. Puede habilitar operadores desde OperatorHub en la consola web de Red Hat OpenShift.

openshift-monitoring

OpenShift Container Platform incluye una pila de monitorización integrada para su clúster, que incluye métricas y capacidades de gestión de alertas. Para ver una comparación entre la pila de supervisión integrada y otras opciones, como por ejemplo IBM Cloud Monitoring, consulte Visión general de las opciones de registro y supervisión.

openshift-multus

OpenShift Container Platform utiliza el complemento de interfaz de red de contenedores (CNI) de Multus para permitir múltiples redes de pods. Sin embargo, no puede configurar el clúster para que utilice varias redes de pods. Los clústeres de Red Hat OpenShift on IBM Cloud solo dan soporte a Calico, que se configura para el clúster de forma predeterminada. Si está activado, Service Mesh utiliza el plug-in Multus.

openshift-network-operator

El operador de red del clúster(CNO) gestiona los componentes de red del clúster que se configuran por defecto, como el complemento de proveedor de red del pod CNI y el operador DNS.

openshift-operator-lifecycle-manager

El gestor del ciclo de vida de los operadores(OLM ) gestiona el ciclo de vida de todos los operadores y el catálogo que se ejecutan en el clúster, incluidos los operadores para los componentes predeterminados y cualquier operador personalizado que se añada.

openshift-service-ca, openshift-service-ca-operator

El operador de la entidad emisora de certificados (CA) ejecuta la firma de certificados e inyecta certificados en los recursos del servidor de API y en los mapas de configuración del clúster. Para más información, consulte el proyecto GitHub.

Clúster con puntos finales de servicio de nube pública y privada

En el diagrama siguiente se muestran los componentes del clúster y la forma en que interactúan cuando están habilitados los puntos finales de servicio en la nube público y privado. Como los dos puntos finales de servicio están habilitados, la VPC crea un equilibrador de carga público para cada servicio para el tráfico de entrada.

Clúster solo con punto final de servicio de nube privada

En el diagrama siguiente se muestran los componentes del clúster y la forma en que interactúan cuando solo está habilitado el punto final de servicio en la nube privado. Como solo está habilitado el punto final de servicio en la nube privado, la VPC crea un equilibrador de carga privado para cada servicio para el tráfico de entrada.

Componentes de los nodos maestro y trabajador de la VPC

Los nodos maestros y de trabajo incluyen los mismos componentes que se describen en la Arquitectura de clúster clásica para clústeres. Para más información sobre la arquitectura de OpenShift Container Platform, consulte la documentación de Red Hat OpenShift.

Maestro

Componentes maestros, que incluyen el servidor de API y etcd, que tienen tres réplicas y están distribuidos entre zonas para ofrecer una disponibilidad aún mayor. Los maestros incluyen los mismos componentes que se describen en la arquitectura de clúster clásica para clústeres. El nodo maestro y todos los componentes de nodo maestro están dedicados únicamente a usted, y no se comparten con otros clientes de IBM.

Nodo de trabajador

Con Red Hat OpenShift on IBM Cloud, las máquinas virtuales que gestiona el clúster son instancias que se denominan nodos trabajadores. Estas máquinas virtuales de los nodos trabajadores y todos los componentes de los nodos trabajadores están dedicados únicamente a usted, y no se comparten con otros clientes de IBM. Sin embargo, el hardware subyacente se comparte con otros clientes de IBM. Los nodos trabajadores se gestionan mediante las herramientas de automatización que suministra Red Hat OpenShift on IBM Cloud, como la API, la CLI o la consola. A diferencia de los clústeres clásicos, no ve nodos de trabajador de cálculo de VPC en el portal de infraestructura o una factura de infraestructura aparte, sino que gestiona toda la actividad de mantenimiento y facturación de los nodos de trabajador en Red Hat OpenShift on IBM Cloud.

Los nodos de trabajo incluyen los mismos componentes que se describen en la arquitectura de clúster clásica.

Cuando ejecute oc get nodes, es posible que observe que los ROLES de los nodos trabajadores están marcados como master,worker. Estos nodos son nodos de trabajador en IBM Cloud y no incluyen los componentes maestros gestionados por IBM. En su lugar, estos nodos están marcados como master porque ejecutan los componentes de OpenShift Container Platform necesarios para configurar y gestionar los recursos predeterminados dentro del clúster, como OperatorHub y el registro interno.

Redes en clúster

Los nodos trabajadores se crean en una subred de VPC en la zona que especifique. La comunicación entre los nodos maestro y trabajadores se establece a través de la red privada. Si crea un clúster con los puntos finales de servicio público y privado habilitados, los usuarios externos autenticados pueden comunicarse con el maestro a través de la red pública, por ejemplo para ejecutar mandatos oc. Si crea un clúster con solo los puntos finales de servicio en la nube privados habilitados, los usuarios externos autenticados sólo pueden comunicarse con el maestro a través de la red privada. Puede configurar el clúster para que se comunique con los recursos de las redes locales, con otras VPC o con la infraestructura clásica estableciendo una VPN de VPC, IBM Cloud Direct Link o IBM Cloud Transit Gateway en la red privada.

Redes de apps

Los balanceadores de carga de Virtual Private Cloud se crean automáticamente en su VPC fuera del clúster para cualquier servicio de red que usted cree en su clúster. Por ejemplo, un equilibrador de carga de VPC expone los servicios de direccionador en el clúster de forma predeterminada. O bien, puede crear un servicio LoadBalancer de Kubernetes para sus apps y se genera automáticamente un equilibrador de carga de VPC. Los equilibradores de carga de VPC son solicitudes de ruta y multizona para la aplicación a través de los puertos de nodo privado que se abren automáticamente en los nodos de trabajador. Si están habilitados los puntos finales de servicio en la nube público y privado, se crean de forma predeterminada los direccionadores y los equilibradores de carga de VPC. Si solo está habilitado el punto final de servicio en la nube privado, de forma predeterminada los direccionadores y equilibradores de carga de VPC se crean como privados. Para obtener más información, consulte el apartado sobre redes de app públicas o privadas para clústeres de VPC. Se utiliza Calico como entramado de políticas de red de clúster.

Almacenamiento

Solo puede configurar IBM Cloud Object Storage y Cloud Databases.