Conceptos de Container Engine y Kubernetes

Un cluster de Kubernetes es un grupo de nodos (máquinas que ejecutan aplicaciones). Cada nodo puede ser una máquina física o una máquina virtual. La capacidad del nodo (su número de CPU y la cantidad de memoria) se define al crear el nodo. Un cluster comprende:

• Nodos de plano de control (anteriormente conocidos como "nodos maestros"). Normalmente, habrá tres nodos de plano de control para una alta disponibilidad.
• Nodos de trabajador, organizados en pools de nodos.

Al crear un cluster mediante Container Engine for Kubernetes, puede crear el nuevo cluster como un cluster básico o como un cluster mejorado.

Al crear un nuevo cluster con Motor de contenedor para Kubernetes, especifique el tipo de cluster que desea crear. Puede especificar:

• Cluster mejorado: los clusters mejorados soportan todas las funciones disponibles, incluidas las funciones no soportadas por los clusters básicos (como nodos virtuales, gestión de complementos de cluster, identidad de carga de trabajo y nodos de trabajador adicionales por cluster). Los clusters mejorados vienen con un acuerdo de nivel de servicio (SLA) con respaldo financiero.
• Cluster básico: los clusters básicos soportan todas las funciones principales proporcionadas por Kubernetes y Container Engine for Kubernetes, pero ninguna de las funciones mejoradas que proporciona Container Engine for Kubernetes. Los clusters básicos incluyen un objetivo de nivel de servicio (SLO), pero no un acuerdo de nivel de servicio (SLA) con respaldo financiero.

Tenga en cuenta lo siguiente al crear clusters:

• Al utilizar la consola para crear un cluster, si no selecciona ninguna función mejorada durante la creación del cluster, tiene la opción de crear el nuevo cluster como un cluster básico. Por defecto, se crea un nuevo cluster como cluster mejorado, a menos que decida crear explícitamente un cluster básico.
• Al utilizar la CLI o la API para crear un cluster, puede especificar si desea crear un cluster básico o un cluster mejorado. Si no especifica explícitamente el tipo de cluster que se va a crear, se crea un nuevo cluster como cluster básico por defecto.

La creación de un nuevo cluster como un cluster mejorado permite agregar fácilmente funciones mejoradas más adelante, aunque no haya seleccionado inicialmente funciones mejoradas. Si decide crear un nuevo cluster como cluster básico, aún puede optar por actualizar el cluster básico a un cluster mejorado más adelante. Sin embargo, no puede volver a una versión anterior de un cluster mejorado a un cluster básico.

Consulte Comparación de clusters mejorados con clusters básicos.

Tenga en cuenta que todas las referencias a "clusters" en la documentación de Container Engine for Kubernetes hacen referencia tanto a clusters mejorados como a clusters básicos, a menos que se indique explícitamente lo contrario.

El plano de control de cluster de Kubernetes implanta la funcionalidad principal de Kubernetes. Se ejecuta en instancias informáticas (conocidas como "nodos de plano de control") en el arrendamiento del servicio Container Engine for Kubernetes. Oracle gestiona completamente el plano de control de cluster.

El plano de control de cluster ejecuta una serie de procesos, incluidos:

• kube-apiserver para soportar las operaciones de API de Kubernetes solicitadas desde la herramienta de línea de comandos de Kubernetes (kubectl) y otras herramientas de línea de comandos, así como desde llamadas directas de REST. kube-apiserver incluye los controladores de admisión necesarios para operaciones avanzadas de Kubernetes.
• kube-controller-manager para gestionar diferentes componentes de Kubernetes (por ejemplo, controlador de replicación, controlador de puntos finales, controlador de espacio de nombre y controlador de cuentas de servicio)
• kube-scheduler para controlar en qué lugar del cluster desea ejecutar tareas
• etcd para almacenar los datos de configuración del cluster
• cloud-controller-manager para actualizar y suprimir nodos de trabajador (mediante el controlador de nodos), para crear equilibradores de carga cuando se crean servicios de Kubernetes de type: LoadBalancer (mediante el controlador de servicios) y para configurar rutas de red (mediante el controlador de rutas). El oci-cloud-controller-manager también implementa una interfaz de almacenamiento de contenedores, un controlador de volúmenes flexibles y un provisionador de volúmenes flexibles (para obtener más información, consulte la documentación de OCI Cloud Controller Manager (CCM) en GitHub).

La API de Kubernetes permite a los usuarios finales consultar y manipular recursos de Kubernetes (como pods, espacios de nombre, mapas de configuración y eventos).

Puede acceder a la API de Kubernetes en el plano de control de cluster mediante un punto final alojado en una subred de la VCN. Esta subred de punto final de API de Kubernetes puede ser una subred privada o pública. Si especifica una subred pública para el punto final de API de Kubernetes, puede exponer opcionalmente el punto final a Internet mediante la asignación de una dirección IP pública al punto final (y también a la dirección IP privada). Puede controlar el acceso a la subred de punto final de API de Kubernetes mediante reglas de seguridad definidas para grupos de seguridad de red (recomendado) o listas de seguridad.

Los nodos de trabajador constituyen el plano de datos de cluster. En los nodos de trabajador es donde se ejecutan las aplicaciones que se despliegan en un cluster.

Cada nodo de trabajador ejecuta una serie de procesos, incluidos:

• kubelet para comunicarse con el plano de control de cluster
• kube-proxy para mantener reglas de red

Los procesos del plano de control de cluster supervisan y registran el estado de los nodos de trabajador y distribuyen las operaciones solicitadas entre ellos.

Un pool de nodos es un subjuego de nodos de trabajador dentro de un cluster que tienen la misma configuración. Los pools de nodos permiten crear pools de máquinas dentro de un cluster que tiene configuraciones diferentes. Por ejemplo, puede crear un pool de nodos en un cluster como máquinas virtuales y otro pool de nodos como máquinas con hardware dedicado. Un cluster debe tener como mínimo un pool de nodos, pero no es necesario que un pool de nodos contenga ningún nodo de trabajador.

Los nodos de trabajador en un pool de nodos están conectados a una subred de nodo de trabajador en la VCN.

Al crear un pool de nodos, especifique que todos los nodos de trabajador del pool de nodos se crean como nodos virtuales o todos se crean como nodos gestionados.

Al crear un pool de nodos con Motor de contenedor para Kubernetes, especifique que los nodos de trabajador del pool de nodos se deben crear como uno u otro de los siguientes:

• Nodos virtuales, totalmente gestionados por Oracle. Los nodos virtuales proporcionan una experiencia de Kubernetes "sin servidor", lo que le permite ejecutar aplicaciones en contenedores a escala sin la sobrecarga operativa de actualizar la infraestructura de plano de datos y gestionar la capacidad de los clusters. Solo puede crear nodos virtuales en clusters mejorados.
• Nodos gestionados que se ejecutan en instancias informáticas (tanto con hardware dedicado como máquina virtual) de su arrendamiento y, al menos, usted las gestiona en parte. Como es responsable de gestionar los nodos gestionados, tiene la flexibilidad de configurarlos para cumplir sus requisitos específicos. Es responsable de actualizar Kubernetes en nodos gestionados y de gestionar la capacidad del cluster. Puede crear nodos gestionados tanto en clusters básicos como en clusters mejorados.

Consulte Comparación de nodos virtuales con nodos gestionados.

Tenga en cuenta que todas las referencias a 'nodos' y 'nodos de trabajador' en la documentación de Container Engine for Kubernetes hacen referencia tanto a nodos virtuales como a nodos gestionados, a menos que se indique explícitamente lo contrario.

Para obtener más información, consulte Working with Self-Managed Nodes.

Tenga en cuenta que todas las referencias a 'nodos' y 'nodos de trabajador' en la documentación de Container Engine for Kubernetes cubren nodos autogestionados, a menos que se indique explícitamente lo contrario.

Cuando una aplicación que se ejecuta en un nodo de trabajador está compuesta por varios contenedores, Kubernetes agrupa los contenedores en una sola unidad lógica denominada pod para facilitar la gestión y detección. Los contenedores en el pod comparten el mismo espacio de nombre de red y el mismo espacio de almacenamiento, y se pueden gestionar como un único objeto mediante el plano de control de cluster. Un número de pods que proporcionen la misma funcionalidad se puede agrupar en un único juego lógico conocido como servicio.

Los clusters de Kubernetes utilizan los plugins de la interfaz de red de contenedor (CNI) para implantar la conectividad de red para los pods que se ejecutan en los nodos de trabajador. Los plugins CNI configuran interfaces de red, proporcionan direcciones IP y mantienen la conectividad.

Para obtener más información sobre los pods, consulte la documentación de Kubernetes.

En Kubernetes, un servicio es una abstracción que define un juego lógico de pods y una política mediante la cual acceder a ellos. El juego de pods a los que se dirige un servicio generalmente se determina mediante un selector.

Para algunas partes de una aplicación (por ejemplo, frontends), puede que desee exponer un servicio en una dirección IP externa fuera de un cluster.

ServiceTypes de Kubernetes permite especificar el tipo de servicio que desea exponer. Un LoadBalancer ServiceType crea un equilibrador de carga de Oracle Cloud Infrastructure en subredes de equilibrador de carga en la VCN.

Para obtener más información sobre los servicios en general, consulte la documentación de Kubernetes. Para obtener más información sobre la creación de servicios de equilibrador de carga con Container Engine for Kubernetes, consulte Definición de servicios de Kubernetes de tipo LoadBalancer.

Kubernetes ha adoptado la especificación de la interfaz de red de contenedor (CNI) para la gestión de recursos de red. El CNI consta de una especificación y bibliotecas para escribir plugins para configurar interfaces de red en contenedores Linux, junto con una serie de plugins soportados.

Los clusters de Kubernetes utilizan los plugins de la interfaz de red de contenedor (CNI) para implantar la conectividad de red para los pods que se ejecutan en los nodos de trabajador. Los plugins CNI configuran interfaces de red, proporcionan direcciones IP y mantienen la conectividad.

Para obtener más información, consulte la documentación de la CNI sobre GitHub.

Un archivo de manifiesto de Kubernetes incluye instrucciones en un archivo yaml o json que especifican cómo desplegar una aplicación al nodo o nodos en un cluster de Kubernetes. Las instrucciones incluyen información sobre el despliegue de Kubernetes, el servicio Kubernetes y otros objetos de Kubernetes que se crearán en el cluster. También se suele hacer referencia al manifiesto como especificación de pod o como archivo deployment.yaml (aunque se permiten otros nombres de archivo). Los parámetros que se deben incluir en un archivo de manifiesto de Kubernetes se describen en la documentación de Kubernetes.

Un controlador de admisión de Kubernetes intercepta las solicitudes autenticadas y autorizadas al servidor de la API de Kubernetes antes de admitir un objeto (por ejemplo, un pod) en el cluster. Un controlador de admisión puede validar un objeto o modificarlo, o ambos. Muchas funciones avanzadas de Kubernetes requieren un controlador de admisión activado. Para obtener más información, consulte la documentación de Kubernetes.

La versión de Kubernetes que seleccione al crear un cluster con Container Engine for Kubernetes determina los controladores de admisión soportados por ese cluster. Para obtener más información sobre los controladores de admisión soportados, el orden en que se ejecutan en el servidor de API de Kubernetes y las versiones de Kubernetes en las que están soportados, consulte Controladores de admisión soportados.

Un cluster de Kubernetes se puede organizar en espacios de nombre para dividir los recursos del cluster entre varios usuarios. Inicialmente, un cluster tiene los siguientes espacios de nombre:

• default, para recursos sin otro espacio de nombre
• kube-system, para los recursos creados por el sistema Kubernetes
• kube-node-lease, para un objeto de leasing por nodo para ayudar a determinar la disponibilidad del nodo
• kube-public, normalmente se utiliza para los recursos que tienen que estar accesibles en el cluster

Para obtener más información sobre los espacios de nombre de Kubernetes, consulte la documentación de Kubernetes.