Cuenta no VRF o habilitada para VRF con solo un punto final de servicio en la nube público

En la imagen siguiente se muestran los componentes de un clúster y cómo interactúan en una cuenta no VRF o habilitada para VRF cuando solo está habilitado el punto final de servicio en la nube público.

Cuenta habilitada para VRF con puntos finales de servicio en la nube privado y público

En la imagen siguiente se muestran los componentes del clúster y la forma en que interactúan en una cuenta habilitada para VRF cuando están habilitados los puntos finales de servicio en la nube público y privado.

Componentes del nodo maestro de Kubernetes

El maestro de Kubernetes está relacionado con la gestión de todos los recursos de cálculo, red y almacenamiento del clúster y se asegura de que las apps y los servicios se desplieguen de igual forma en los nodos trabajadores del clúster. En función de cómo configurar la app y los servicios, el maestro determina el nodo trabajador que tiene los recursos suficientes para cumplir los requisitos de la app.

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

En la tabla siguiente se describen los componentes del nodo maestro de Kubernetes.

kube-apiserver

El servidor de API de Kubernetes sirve como punto de entrada principal para todas las solicitudes de gestión del clúster procedentes del nodo trabajador destinadas al nodo maestro de Kubernetes. El servidor de API de Kubernetes valida y procesa las solicitudes que cambian el estado de los recursos de Kubernetes, como pods o servicios, y almacena este estado en etcd.

konnectivity-server

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

etcd

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 en una instancia de almacenamiento cifrada que gestiona IBM.

kube-scheduler

El planificador de Kubernetes observa los pods recién creados y decide dónde se desplegarán en función de la capacidad, las necesidades de rendimiento, las restricciones de políticas, las especificaciones de 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.

kube-controller-manager

El gestor de controlador de Kubernetes es un daemon que observa el estado de los recursos del clúster, como por ejemplo los conjuntos de réplicas. Cuando cambia el estado de un recurso, por ejemplo si cae un pod de un conjunto de réplicas, el gestor del controlador inicia acciones de corrección para conseguir el estado necesario.

Componentes de nodo trabajador

Cada nodo trabajador es una máquina física (nativa) o una máquina virtual que se ejecuta en hardware físico en el entorno de nube. Al suministrar un nodo trabajador, puede determinar los recursos que están disponibles para los contenedores alojados en dicho nodo trabajador. De forma predeterminada, los nodos trabajadores se configuran con un entorno de ejecución de contenedor gestionado por IBM, distintos recursos de cálculo, sistema de red y un servicio de volúmenes. Las características integradas de seguridad proporcionan aislamiento, funciones de gestión de recursos y conformidad con la seguridad de los nodos trabajadores.

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 una máquina virtual de nodo trabajador, es posible que el hardware subyacente se comparta con otros clientes, en función del nivel de aislamiento de hardware que elija.

No se da soporte a la modificación de componentes de nodo trabajador predeterminado, kubelet, y puede provocar resultados inesperados.

En las tablas siguientes, se describen los componentes de un nodo de trabajador.

Espacio de nombres kube-system

ibm-master-proxy

El ibm-master-proxy reenvía solicitudes desde el nodo trabajador a las direcciones IP de las réplicas de maestro de alta disponibilidad. En clústeres de una sola zona, el maestro tiene tres réplicas en hosts independientes con un nombre de dominio y una dirección IP de maestro. Para clústeres que se encuentran en una zona con capacidad multizona, el maestro tiene tres réplicas que se dispersan entre zonas. Como tal, cada maestro tiene su propia dirección IP que se registra con DNS, con un nombre de dominio para el maestro de clúster completo.

konnectivity-agent

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

kubelet

El kubelet es un pod que se ejecuta en cada nodo trabajador y que es el responsable de supervisar el estado de los pods que se ejecutan en el nodo trabajador y de ver los sucesos que envía el servidor de API de Kubernetes. 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 de Kubernetes.

coredns

De forma predeterminada, Kubernetes planifica un pod CoreDNS (o un pod de KubeDNS en la versión 1.12 y anteriores) y el servicio en el clúster. Los contenedores utilizan automáticamente la IP del servicio DNS para resolver nombres DNS en sus búsquedas de otros pods y servicios.

calico

Calico gestiona las políticas de red del clúster y consta de varios componentes, indicados a continuación.

calico-cni: la interfaz de red de contenedor (CNI) de Calico gestiona la conectividad de red de los contenedores y elimina los recursos asignados cuando se suprime un contenedor.

calico-ipam: Calico IPAM gestiona la asignación de direcciones IP para contenedores.

calico-node: el nodo de Calico es un contenedor que empaqueta los distintos componentes necesarios para los contenedores de red con Calico.

calico-policy-controller: El controlador de política de Calico observa el tráfico de red de entrada y salida para cumplir las políticas de red establecidas. Si el tráfico no está permitido en el clúster, se bloquea el acceso al clúster. El controlador de políticas de Calico también se utiliza para crear y establecer políticas de red para un clúster.

kube-proxy

El proxy de red de Kubernetes es un daemon que se ejecuta en cada nodo trabajador y que reenvía o equilibra la carga del tráfico de red TCP y UDP para los servicios que se ejecutan en el clúster.

kube-dashboard

El panel de control de Kubernetes es una GUI basada en web que permite a los usuarios gestionar y resolver problemas en el clúster y en las aplicaciones que se ejecutan en el clúster.

heapster

Heapster es un agregador a nivel de clúster de datos de supervisión y de sucesos. El pod Heapster descubre todos los nodos del clúster y consulta información de uso del kubelet de cada nodo. En el panel de control de Kubernetes encontrará gráficos de utilización.

ALB de Ingress

Ingress es un servicio de Kubernetes que puede utilizar para equilibrar las cargas de trabajo de tráfico de red en el clúster reenviando solicitudes públicas o privadas a varias apps del clúster. Para exponer sus apps a través de la red pública o privada, debe crear un recurso de Ingress para registrar sus apps con el equilibrador de carga de aplicación de Ingress (ALB). Un solo URL o dirección IP puede acceder a varias apps.

Proveedor de almacenamiento

Cada clúster se configura con un plugin para suministrar almacenamiento de archivos. Si lo desea puede instalar otros complementos, como almacenamiento en bloque.

Espacio de nombres ibm-system

Registro y métricas

Puede utilizar los servicios IBM Cloud Logs y IBM Cloud® Monitoring para ampliar las funciones de recopilación y retención cuando trabaje con registros y con métricas. Equilibrador de carga

Un equilibrador de carga es un servicio de Kubernetes que se puede utilizar para equilibrar las cargas de trabajo de tráfico de red en el clúster reenviando solicitudes públicas o privadas a una app.

Espacio de nombres default

Servicios y pods de app

En el espacio de nombres default o en los espacios de nombres que cree, puede desplegar aplicaciones en pods y servicios para comunicarse con esos pods.