Diseño de los Componentes de la Topología
Revise las opciones arquitectónicas para diseñar la red para su topología de Kubernetes, decida si necesita los hosts bastion y admin y diseñe las agrupaciones de nodos.
Diseñar la red
Decida los requisitos de acceso aleatorio de las aplicaciones contenedorizadas y determine los recursos de red que necesite.
Tenga en cuenta los requisitos de escala de la carga de trabajo al decidir el tamaño de la red; es decir, los rangos CIDR para VCN y las subredes.
Conecte los nodos de trabajador a una subred distinta dentro de VCN. Utilice subredes independientes para los demás recursos, como los nodos de equilibrio de carga, el host de base y el host de administración.
El enfoque recomendado es anexar los nodos del trabajador de Kubernetes a una subred privada. Cada nodo de trabajador tiene solo una dirección IP privada. Utilice un equilibrador de carga (interno o público) para distribuir el tráfico entre los nodos del trabajador. Para permitir que los nodos de trabajador inicien el acceso a los hosts en Internet público, utilice un gateway NAT.
Si desea crear servicios del tipo NodePort
, conecte los nodos del trabajador de Kubernetes a una subred pública. El tráfico hacia los nodos y desde ellos se direcciona a través del gateway de Internet. Cada nodo de trabajador tiene una dirección IP pública y una dirección privada. Debe configurar explícitamente las reglas de seguridad para permitir el acceso a los nodos de trabajador desde Internet público.
Puede utilizar un gateway de servicio para direccionar todo el tráfico de los nodos de trabajador a otros servicios de Oracle Cloud (como Oracle Cloud Infrastructure Object Storage ) dentro de la región.
Restringir el acceso administrativo
Considere el uso de un host bastion y un host admin para acceder a la topología y gestionarla en la nube.
Para proteger los nodos de trabajador de Kubernetes frente al acceso no autorizado desde fuera de la nube, aíselos en una subred que no tenga una ruta a Internet pública ni desde ella.
Despliegue un host de base y utilícelo como el único punto de entrada para las conexiones SSH a las demás instancias informáticas de la topología, incluidos los nodos de trabajador. Para una mayor seguridad, considere permitir el acceso SSH al host de base solo a un juego conocido de direcciones IP fuera de la nube.
Para operaciones administrativas en la topología de Kubernetes en la nube, considere la posibilidad de crear un host de administración en la nube, con las herramientas necesarias como kubectl
y la CLI de Oracle Cloud Infrastructure instalada en ella. Utilice el host de base como servidor de salto para conexiones SSH al host de administración.
Diseñar los pools de nodos
Un pool de nodos es un grupo de instancias informáticas que se han configurado de forma idéntica dentro de un cluster de Kubernetes. Los pools de nodos permiten desplegar y gestionar aplicaciones con diferentes requisitos de recursos de forma eficaz. Por ejemplo, puede crear una agrupación de nodos independiente para cada aplicación o servicio en contenedor.
Decida el número de agrupaciones de nodos que se crearán y el número de nodos del trabajador en cada agrupación en función del número y el tamaño de las cargas de trabajo contenedorizadas. Se crea un mínimo de tres nodos de trabajador en cada grupo. Todos los nodos de trabajador dentro de un grupo determinado se crean con la misma forma, que usted especifica.
Garantice la alta disponibilidad
Asegúrese de que las cargas de trabajo contenedorizadas en la nube no se vean afectadas por las interrupciones del centro de datos.
Las regiones de Oracle Cloud Infrastructure contienen uno o varios dominios de disponibilidad tolerantes a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía, refrigeración y red interna. Es poco probable que un fallo en un dominio de disponibilidad afecte a los demás dentro de la misma región. En una región que contiene varios dominios de disponibilidad, los nodos de trabajador se distribuyen entre los dominios de disponibilidad. Puede adjuntar los nodos a las subredes regionales, lo que abarca todos los dominios de disponibilidad.
Cada dominio de disponibilidad contiene tres dominios de errores, cada una de las agrupaciones aisladas de hardware e infraestructura. Un evento de mantenimiento o error de hardware que afecta a un dominio de error no afecta los recursos de los otros dominios de errores. En las regiones que tienen un único dominio de disponibilidad, los nodos de trabajador se distribuyen entre los dominios de errores del centro de datos.