Despliegue Kubernetes sin servidor con los nodos virtuales de OCI Kubernetes Engine
Ambos modos de operaciones pueden soportar aplicaciones básicas hasta las más críticas. Con los nodos virtuales, las operaciones de Kubernetes se simplifican y ofrecen la mejor relación precio-rendimiento. La compensación entre los nodos gestionados y los nodos virtuales se produce con los nodos gestionados; tiene un mayor control sobre la infraestructura de nodos. Puede configurar los recursos de Kubernetes para que utilicen HostPort y HostNetwork, o bien ejecutar DaemonSets y otras opciones que puedan ser necesarias para sus aplicaciones o herramientas. En la mayoría de los casos de uso, estas opciones no son necesarias.
Los nodos virtuales tienen más sentido cuando no necesita ajustar el control sobre la ejecución y la gestión de los contenedores. Si las aplicaciones requieren la configuración de la infraestructura de nodos que no está disponible con los nodos virtuales, utilice los nodos gestionados.
Arquitectura
Para integrar el cluster de OKE con OCI Vault, el operador de secretos externos se despliega en el cluster de OKE. Esto permite definir un recurso SecretStore que se asigne a OCI Vault para que contenga la contraseña de la base de datos. Una vez asignado el recurso SecretStore, el cluster de OKE puede acceder a la contraseña como secreto de Kubernetes. Un rol de OCI Identity and Access Management con permiso para leer desde OCI Vault permite al pod acceder al secreto. El rol está asociado a la cuenta de servicio de Kubernetes utilizada en la definición del pod para otorgarle acceso para leer desde OCI Vault.
El siguiente diagrama ilustra esta arquitectura de referencia.
Descripción de la ilustración k8n-virtual-nodes.png
La arquitectura tiene los siguientes componentes:
- Tenancy
Un arrendamiento es una partición segura y aislada que Oracle configura en Oracle Cloud al registrarse en Oracle Cloud Infrastructure. Puede crear, organizar y administrar sus recursos en Oracle Cloud dentro de su arrendamiento. Un arrendamiento es sinónimo de una compañía u organización. Normalmente, una compañía tendrá un único arrendamiento y reflejará su estructura organizativa dentro de ese arrendamiento. Un único arrendamiento suele estar asociado a una única suscripción, y una única suscripción normalmente solo tiene un arrendamiento.
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes entre sí y puede haber grandes distancias que las separen (entre países e incluso continentes).
- Compartimento
Los compartimentos son particiones lógicas entre regiones dentro de un arrendamiento de Oracle Cloud Infrastructure. Utilice compartimentos para organizar los recursos en Oracle Cloud, controlar el acceso a los recursos y definir cuotas de uso. Para controlar el acceso a los recursos de un compartimento determinado, debe definir políticas que especifiquen quién puede acceder a los recursos y qué acciones pueden realizar.
- Dominios de disponibilidad
Los dominios de disponibilidad son centros de datos independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como la alimentación o la refrigeración, ni la red interna del dominio de disponibilidad. Por lo tanto, un fallo en un dominio de disponibilidad no debería afectar a los otros dominios de disponibilidad de la región.
- Dominios de errores
Un dominio de errores es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad cuenta con tres dominios de errores con energía y hardware independientes. Al distribuir los recursos entre varios dominios de errores, las aplicaciones pueden tolerar fallos físicos del servidor, mantenimiento del sistema y fallos de energía en un dominio de errores.
- Red y subredes virtuales en la nube (VCN)
Una VCN es una red personalizable y definida por software que puede configurar en una región de Oracle Cloud Infrastructure. Al igual que las redes de los centros de datos tradicionales, las redes virtuales le proporcionan el control de su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- Equilibrador de carga
El servicio Oracle Cloud Infrastructure Load Balancing proporciona una distribución automatizada del tráfico desde un único punto de entrada a varios servidores en el backend.
- Gateway de Internet
El gateway de Internet permite el tráfico entre las subredes públicas de una VCN y la red pública de Internet.
- Gateway de traducción de direcciones de red (NAT)
Un gateway de NAT permite que los recursos privados de una VCN accedan a hosts en Internet, sin exponer dichos recursos a conexiones de Internet entrantes.
- Gateway de servicio
El gateway de servicios proporciona acceso desde una VCN a otros servicios, como Oracle Cloud Infrastructure Object Storage. El tráfico de la VCN al servicio Oracle viaja por el tejido de red de Oracle y no atraviesa Internet.
- Vault
Oracle Cloud Infrastructure Vault permite gestionar de forma central las claves de cifrado que protegen los datos y las credenciales secretas que utiliza para proteger el acceso a los recursos en la nube. Puede utilizar el servicio Vault para crear y gestionar almacenes, claves y secretos.
- Registro
Oracle Cloud Infrastructure Registry es un registro gestionado por Oracle que permite simplificar el desarrollo y el flujo de trabajo de producción. El registro facilita el almacenamiento, el uso compartido y la gestión de artefactos de desarrollo, como imágenes de Docker. La arquitectura altamente disponible y escalable de Oracle Cloud Infrastructure garantiza que pueda desplegar y gestionar sus aplicaciones de forma fiable.
- Lista de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, el destino y el tipo de tráfico que se debe permitir dentro y fuera de la subred.
- Tabla de rutas
Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de subredes a destinos fuera de una VCN, normalmente a través de gateways.
- OCI Kubernetes Engine
Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine u OKE) es un servicio totalmente gestionado, escalable y disponible que puede utilizar para desplegar las aplicaciones en contenedores en la nube. Especifique los recursos informáticos que necesitan sus aplicaciones y Kubernetes Engine los provisionará en Oracle Cloud Infrastructure en un arrendamiento existente. OKE utiliza Kubernetes para automatizar el despliegue, la ampliación y la gestión de aplicaciones en contenedores en clusters de hosts.
- Oracle MySQL Database Service
Oracle MySQL Database Service es un servicio de base de datos de Oracle Cloud Infrastructure (OCI) totalmente gestionado que permite a los desarrolladores desarrollar e implementar rápidamente aplicaciones nativas seguras en la nube. Optimizado y disponible exclusivamente en OCI, Oracle MySQL Database Service está 100 % creado, gestionado y soportado por los equipos de ingeniería de OCI y MySQL.
Oracle MySQL Database Service cuenta con un motor de análisis integrado y de alto rendimiento (HeatWave) para ejecutar análisis sofisticados en tiempo real directamente en una base de datos MySQL operativa.
- Ingress Controller
Un controlador de entrada (ing) es un componente que se ejecuta en un cluster de Kubernetes y gestiona los recursos de entrada. Recibe tráfico de la red externa, lo enruta al servicio correcto y realiza el equilibrio de carga y la terminación SSL. El controlador de entrada normalmente se ejecuta como un pod independiente en el cluster y se puede escalar independientemente de los servicios que gestiona.
- Secretos de Kubernetes
Los secretos de Kubernetes pueden incluir datos de configuración confidenciales, como tokens de autenticación, contraseñas y claves SSH. Los secretos le permiten controlar los datos confidenciales y reducen el riesgo de exponer los datos a usuarios no autorizados. Oracle Container Engine for Kubernetes soporta el cifrado de secretos de Kubernetes estáticos.
- Operador de secretos externos
El operador de secretos externos de Kubernetes integra Oracle Container Engine for Kubernetes con Oracle Cloud Infrastructure Vault. El operador lee información de API externas e inyecta automáticamente los valores en un secreto de Kubernetes.
- SecretStore
El plano de control de cluster de Kubernetes almacena datos de configuración sensibles (como tokens de autenticación, certificados y credenciales) como objetos secretos de Kubernetes en
etcd.Etcdes un almacén de clave-valor distribuido con código abierto que Kubernetes utiliza para la coordinación de clusters y la gestión de estado. En los clusters de Kubernetes creados por Container Engine for Kubernetes,etcdescribe y lee datos hacia y desde volúmenes de almacenamiento en bloque del servicio de Oracle Cloud Infrastructure Block Volumes. Por defecto, Oracle cifra los datos en volúmenes en bloque estáticos, incluidos los secretos deetcdy Kubernetes. Oracle gestiona este cifrado por defecto mediante una clave de cifrado maestra, sin que sea necesario realizar ninguna acción por su parte. Para obtener un control adicional sobre el ciclo de vida de la clave de cifrado maestra y cómo se utiliza, puede optar por gestionar la clave de cifrado maestra usted mismo, en lugar de que Oracle la gestione por usted.Al crear un nuevo cluster, puede especificar que los secretos de Kubernetes en
etcdse cifren mediante Oracle Key Management Cloud Service. - Pod
Un pod es un grupo de uno o más contenedores y su almacenamiento compartido, así como cualquier opción específica sobre cómo se deben ejecutar juntos. Normalmente, los contenedores de un pod comparten la misma red y espacio de memoria y pueden acceder a volúmenes compartidos para almacenamiento. Estos recursos compartidos permiten que los contenedores de un pod se comuniquen internamente de forma fluida como si estuvieran instalados en un único host lógico.
- Nodo virtual
Un nodo virtual es una abstracción de software de un nodo real. Los nodos virtuales se despliegan en el arrendamiento de OCI y OCI los supervisa y gestiona por completo.
Recomendaciones
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que planea asociar a las subredes de la VCN. Utilice bloques CIDR que estén dentro del espacio de direcciones IP privadas estándar.
Seleccione bloques de CIDR que no se solapen con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) a la que desee configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Al diseñar las subredes, tenga en cuenta el flujo de tráfico y los requisitos de seguridad. Asocie todos los recursos de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
Utilizar subredes regionales.
- Grupos de seguridad de red (NSG)
Puede utilizar NSG para definir un juego de reglas de entrada y salida que se aplican a VNIC específicas. Recomendamos utilizar NSG en lugar de listas de seguridad, ya que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de la aplicación.
Puede utilizar NSG para definir un juego de reglas de entrada y salida que se aplican a VNIC específicas. Recomendamos utilizar NSG en lugar de listas de seguridad, ya que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de la aplicación.
- Ancho de banda de equilibrador de carga
Al crear el equilibrador de carga, puede seleccionar una unidad predefinida que proporcione un ancho de banda fijo o especificar una unidad personalizada (flexible) en la que defina un rango de ancho de banda y permita que el servicio amplíe el ancho de banda automáticamente en función de los patrones de tráfico. Con cualquiera de los enfoques, puede cambiar la unidad en cualquier momento después de crear el equilibrador de carga.
Consideraciones
Tenga en cuenta lo siguiente al trabajar con nodos virtuales.
Para empezar con nodos virtuales, primero debe crear un cluster de OCI Kubernetes Engine con un pool de nodos virtuales o agregar un pool de nodos virtuales a un cluster de Kubernetes Engine (OKE) existente.
- Seleccione la unidad y la ubicación de los nodos virtuales.
-
La unidad determina el tipo de procesadores junto con la cantidad de recursos de CPU y memoria que se pueden asignar a cada pod. Cada pod puede asignar hasta los límites de memoria y CPU de la unidad seleccionada.
-
Los nodos virtuales escalarán pods con la configuración de la escala automática de pod horizontal (HPA). No es necesario configurar la escala automática del nodo.
-
Puede colocar los nodos virtuales en dominios de disponibilidad y dominios de errores específicos que sean los más óptimos para satisfacer sus necesidades de alta disponibilidad (HA). Para obtener el máximo nivel de redundancia, coloque un nodo virtual en cada dominio de errores dentro del dominio de disponibilidad del cluster de OKE.
-
Utilice etiquetas de nodo de Kubernetes para especificar la ubicación de los pods en nodos virtuales. Para obtener una distribución uniforme de pods entre nodos, utilice la restricción
PodTopologySpread.
-
-
Los nodos virtuales utilizan una red de pod nativos de VCN. El número de pods disponibles en el cluster está limitado por el número de direcciones IP disponibles en la subred.
- Las redes de pod nativo proporcionan a cada pod una dirección IP nativa de las subredes de la VCN, lo que permite a cada pod beneficiarse de las funciones de seguridad de red de OCI incorporadas, como logs de flujo de VCN, políticas de enrutamiento, VTAP y grupos de seguridad.
- Considere el uso de un rango de subred que permita el número de pods y nodos que espera utilizar y proporcione espacio para el crecimiento.
- Defina los grupos de seguridad de red (NSG) para limitar el tipo de tráfico que puede entrar y salir de los pods.
- Utilice los logs de flujo de VCN para inspeccionar todo el tráfico de red entre pods o utilice VTAP para capturar el tráfico de red.
- Los pods de los nodos virtuales tienen acceso a otros servicios de OCI con identidad de carga de trabajo.
Hay casos en los que un pod puede necesitar acceso a otros servicios de OCI.
- Utilice Workload Identity para otorgar privilegios a pods en nodos virtuales. Workload Identity asocia roles de OCI Identity and Access Management a cuentas de servicio de Kubernetes asignadas a pods.
- Los nodos virtuales proporcionan aislamiento a nivel de hipervisor para el pod.
Las vulnerabilidades de seguridad podrían potencialmente permitir que los procesos maliciosos dentro de un contenedor "escaparan" y afectaran al núcleo del nodo, lo que podría provocar el cierre del nodo. El código malicioso también puede acceder a los datos en memoria o almacenamiento y exfiltrar los datos. Los datos exfiltrados pueden pertenecer potencialmente a otro inquilino en un entorno de varios inquilinos.
- El nodo virtual proporciona aislamiento a nivel de hipervisor para los pods. Un pod no comparte recursos informáticos, memoria y red con otros pods del cluster, lo que mitiga la posibilidad de que un nodo caído o datos exfiltrados pertenezcan a otro inquilino causados por código malicioso.