Más información sobre la configuración de un cluster de Kubernetes en la nube
Una topología basada en Kubernetes en la nube contiene numerosos componentes, incluidos los recursos de red, las instancias informáticas y los nodos de Kubernetes. Para desplegar y gestionar una topología compleja de forma eficaz, defina la infraestructura en la nube como código (IaC) en los archivos de configuración de Terraform.
Para cambiar la topología, versione los módulos de Terraform adecuados, actualice las definiciones de recursos y aplique la configuración revisada. Si es necesario, puede revertir a una versión anterior de la infraestructura fácilmente.
Utilice los bloques de construcción de Terraform proporcionados en esta solución para desplegar la infraestructura necesaria para un entorno de Kubernetes basado en nube.
Antes de Empezar
Arquitectura
La topología de ejemplo que esta solución proporciona código Terraform para contiene una única red virtual en la nube (VCN) con las redes y los recursos de Kubernetes necesarios, todo en una sola región de Oracle Cloud Infrastructure.

Nota:
El código Terraform incluye variables de entrada, que puede utilizar para ajustar la arquitectura para que se adapte a los requisitos de red de las cargas de trabajo contenedorizadas, el tamaño y el número de pools de nodos necesarios, las restricciones de tolerancia a fallos, etc.- Red virtual en la nube (VCN)
Todos los recursos de la topología están en una única red. El prefijo CIDR se define para la red (valor predeterminado: 10.0.0.0/16).
- SubredesVCN en la topología de ejemplo contiene cuatro subredes. Defina los tamaños de las subredes.
Subred Prefijo de CIDR predeterminado Descripción Subred de la base 10.0.1.0/29 Una subred pública para el host de base opcional. Subred del equilibrador de carga 10.0.2.32/27 si es público (10.0.2.0/27 si es privado) Subred para los nodos de equilibrador de carga. Decida si la subred es pública o privada. Subred de administrador 10.0.1.8/29 Una subred privada del host de administración opcional, que contiene las herramientas necesarias para gestionar el cluster de Kubernetes, como kubectl
,helm
y la CLI de Oracle Cloud Infrastructure.Subred de los nodos del personal 10.0.64.0/18 Subred para los nodos de trabajador de Kubernetes. Decida si la subred es pública o privada. 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 una subred regional 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.
- Gateway de servicio (opcional)
- 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 (no incluidos en el código de ejemplo)
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 no muestra ningún nodo de equilibrador de carga.
- 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. El host admin en la topología de ejemplo se encuentra 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. En la topología de ejemplo, todos los nodos de trabajador están en un solo grupo de nodos y se conectan a una subred privada. Puede personalizar el número de agrupaciones de nodos, el tamaño de cada agrupación y si desea utilizar una subred pública según sus requisitos.
Si los nodos de trabajador están conectados a una subred privada, no se puede acceder a ellos directamente desde Internet público. Los usuarios pueden acceder a las aplicaciones contenedorizadas a través del equilibrador de carga.
Si activa el acceso SSH a los nodos del trabajador, los administradores pueden crear conexiones SSH a los nodos del trabajador mediante el host bastion.
La arquitectura muestra tres nodos de trabajador, cada uno en un dominio de disponibilidad distinto dentro de la región: AD1, AD2 y AD3.Nota:
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.
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. |