Más información sobre el diseño de una topología de Kubernetes en la nube

Las empresas están implantando cada vez cargas de trabajo en la nube en contenedores sencillos. En un entorno de producción, necesita gestionar los contenedores y asegurarse de que no hay tiempo de inactividad. Kubernetes es un motor de orquestación de código abierto para gestionar aplicaciones y servicios en contenedor.

Oracle Cloud Infrastructure Container Engine for Kubernetes es un servicio gestionado, escalable y altamente disponible que puede utilizar para desplegar las aplicaciones contenedorizadas en clusters de Kubernetes en la nube.

Arquitectura

La arquitectura de una topología basada en Kubernetes en la nube depende de factores tales como si las cargas de trabajo contenedorizadas deben ser accesibles desde la red pública de Internet, el tamaño y el número de agrupaciones de nodos y los requisitos de tolerancia a fallos de las cargas de trabajo.

El siguiente diagrama muestra una arquitectura de referencia de un cluster de Kubernetes en una región de Oracle Cloud Infrastructure que contiene varios dominios de disponibilidad.

La arquitectura contiene los siguientes componentes:

• Red virtual en la nube (VCN): todos los recursos de la topología están en un único VCN.
• Subredes:

  El VCN de esta arquitectura contiene cuatro subredes, dos públicas y dos privadas. Una de las subredes públicas es para el host de base; la otra es para el equilibrador de carga orientado a Internet. De las dos subredes privadas, una es para un host admin que contiene las herramientas necesarias para gestionar el cluster de Kubernetes. La otra subred privada es para los nodos del cluster de Kubernetes.

  Todas las subredes son regionales, es decir, abarcan todos los dominios de disponibilidad en la región, abreviados como AD1, AD2 y AD3 en el diagrama de arquitectura. Por lo tanto, están protegidos frente a un fallo de dominio de disponibilidad. Puede utilizar las subredes para los recursos que despliegue en cualquier dominio de disponibilidad de la región.

• Gateways de red
  • Gateway de servicio (opcional)

    El gateway de servicios permite que los recursos de VCN accedan a servicios de Oracle como Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure File Storage y Oracle Cloud Infrastructure Database de forma privada; es decir, sin exponer el tráfico a Internet público. Las conexiones a través del gateway de servicios se pueden iniciar desde los recursos de VCN, no desde los servicios con los que se comunican los recursos.

  • Gateway de NAT (opcional)

    El gateway NAT permite a las instancias informáticas que están asociadas a subredes privadas de VCN acceder a Internet. Las conexiones a través del gateway de NAT se pueden iniciar desde los recursos de VCN, pero no desde la red pública de Internet.

  • Gateway de Internet

    El gateway de Internet permite la conectividad entre la red pública de Internet y cualquier recurso de las subredes públicas de VCN.

• Host de Basación (opcional)

  El host de base es una instancia informática que sirve como punto de entrada a la topología desde fuera de la nube.

  El host de base se provisiona normalmente en DMZ. Le permite proteger recursos confidenciales al colocarlos en redes privadas a las que no se puede acceder directamente desde fuera de la nube. Se expone un punto de entrada conocido único que se puede auditar de forma regular. Por lo tanto, evita exponer los componentes más sensibles de la topología sin comprometer el acceso a ellos.

  El host de base en la topología de ejemplo está conectado a una subred pública y tiene una dirección IP pública. Una regla de seguridad de entrada se configura para permitir conexiones SSH con el host de base desde Internet público. Para proporcionar un nivel de seguridad adicional, puede limitar el acceso SSH al host de base sólo desde un bloque específico de direcciones IP.

  Puede acceder a las instancias de Oracle Cloud Infrastructure en subredes privadas a través del host base. Para ello, active el reenvío de ssh-agent, que le permite conectarse al host de base y, a continuación, acceder al siguiente servidor reenviando las credenciales desde su equipo. También puede acceder a las instancias de la subred privada mediante el canal SSH dinámico. El túnel dinámico proporciona un proxy SOCKS en el puerto local, pero las conexiones se originan en el host remoto.

• Nodos de equilibrador de carga:

  Los nodos del equilibrador de carga interceptan y distribuyen el tráfico entre los nodos disponibles de Kubernetes que ejecutan las aplicaciones contenedorizadas. Si las aplicaciones deben ser accesibles desde Internet, utilice equilibrios de carga públicos; de lo contrario, utilice equilibrios de carga privados, que no tienen una dirección IP pública. La arquitectura muestra dos nodos de equilibrio de carga, cada uno en un dominio de disponibilidad distinto.

• Host de Administración (opcional):

  Mediante un host de administración, puede evitar la instalación y la ejecución de herramientas de gestión de infraestructura como, por ejemplo, kubectl, helm y la CLI de Oracle Cloud Infrastructure fuera de la nube. En la arquitectura de referencia, el host admin está en una subred privada y se puede acceder a él mediante el host bastion. Para poder ejecutar la CLI de Oracle Cloud Infrastructure en el host admin, debe designarla como principal de instancia.

• Nodos de trabajador de Kubernetes:

  Los nodos de trabajador de Kubernetes son las instancias informáticas en las que puede desplegar sus aplicaciones contenedorizadas. Todos los nodos de trabajador en esta arquitectura de referencia se encuentran en un único grupo de nodos y se conectan a una subred privada. Si es necesario, puede crear varios pools de nodos.

  No se puede acceder directamente a los nodos de trabajador en la arquitectura de referencia desde Internet pública. Los usuarios de las aplicaciones contenedorizadas pueden acceder a ellas a través del equilibrador de carga. Los administradores pueden acceder a los nodos de trabajadores mediante el host de base.

  La arquitectura muestra tres nodos de trabajador, cada uno en un dominio de disponibilidad distinto dentro de la región: AD1, AD2 y AD3. Los nodos maestros de Kubernetes se ejecutan en el arrendamiento de Oracle y no se muestran.

Si la región en la que desea desplegar las aplicaciones contenedorizadas contiene un único dominio de disponibilidad, los nodos de trabajador se distribuyen entre los dominios de fallos (FD) dentro del dominio de disponibilidad, como se muestra en la siguiente arquitectura.

Acerca de los servicios y permisos necesarios

Esta solución requiere los siguientes servicios y permisos:

Servicio	Permisos necesarios
Oracle Cloud Infrastructure Identity and Access Management	Gestionar políticas y grupos dinámicos.
Oracle Cloud Infrastructure Networking	Gestionar VCN, subredes, gateways de Internet, gateways de NAT, gateways de servicio, tablas de rutas y listas de seguridad.
Oracle Cloud Infrastructure Compute	Gestionar instancias informáticas.
Oracle Cloud Infrastructure Container Engine for Kubernetes	Gestione los clusters y las agrupaciones de nodos. Consulte Configuración de Políticas para Creación y Despliegue de Clusters.