Clusters Públicos y Privados
En Compute Cloud@Customer, antes de crear un cluster, decida qué tipo de acceso de red necesita el cluster: si necesita un cluster público o privado. No puede crear clusters públicos y privados en una VCN.
La diferencia clave entre un cluster público y un cluster privado es si configura subredes públicas o privadas para el punto final de API de Kubernetes y el equilibrador de carga de trabajador.
Las subredes de los nodos de trabajador y los nodos de plano de control siempre son privadas.
Para los nodos de trabajador y los nodos de plano de control, puede configurar reglas de ruta que permitan el acceso solo dentro de la VCN o fuera de la VCN. Esta documentación asigna a esas tablas de rutas los nombres "vcn_private" y "nat_private". Puede seleccionar cualquiera de estas configuraciones de subred privada para los nodos de trabajador y los nodos de plano de control, tanto si el cluster es privado como si el cluster es público.
Clusters públicos
Un cluster público requiere los siguientes recursos de red:
-
Subred pública para el punto final de API del servicio Kubernetes. Consulte las instrucciones para crear una subred pública de "punto final de plano de control" en Creating an OKE Control Plane Subnet (Flannel Overlay) y Creating a Control Plane Subnet (VCN-Native Pod).
-
Subred pública para el equilibrador de carga de trabajador. Consulte las instrucciones para crear una subred pública "service-lb" en Creación de una subred de equilibrador de carga de trabajador (superposición de franela) y Creación de una subred de equilibrador de carga de trabajador (pod nativo de VCN)
-
Gateway de Internet para conectar recursos de una subred pública a Internet mediante direcciones IP públicas.
-
Un gateway de NAT. Utilice un gateway de NAT para el acceso a Internet saliente. Un gateway de NAT conecta los recursos de una subred privada a Internet sin exponer las direcciones IP privadas.
-
Al menos tres direcciones IP públicas gratuitas. Las direcciones IP públicas gratuitas son necesarias para el gateway de NAT, el equilibrador de carga del plano de control y el equilibrador de carga del trabajador.
El equilibrador de carga de trabajador necesita una dirección IP pública gratuita para exponer las aplicaciones. El equilibrador de carga de trabajador puede requerir más direcciones IP públicas libres en función de las aplicaciones que se ejecuten en los pods.
Clusters privados
Si crea varias redes virtuales en la nube de OKE, cada CIDR debe ser único. Los CIDR de diferentes redes virtuales en la nube para clusters privados no se pueden solapar con ningún otro CIDR de VCN ni ningún CIDR local. Las direcciones IP utilizadas deben ser exclusivas de cada VCN.
Un cluster privado tiene los siguientes recursos de red:
-
Subred privada para el punto final de API de de Kubernetes. Consulte las instrucciones para crear una subred privada "control-plane-endpoint" en Creating an OKE Control Plane Subnet (Flannel Overlay) y Creating a Control Plane Subnet (VCN-Native Pod).
-
Subred privada para el equilibrador de carga de trabajador. Consulte las instrucciones para crear una subred "service-lb" privada en Creación de una subred de equilibrador de carga de plano de control de OKE (superposición de franela) y Creación de una subred de equilibrador de carga de plano de control (pod nativo de VCN).
-
Una tabla de rutas sin reglas de rutas. Esta tabla de rutas solo permite el acceso dentro de la VCN.
-
(Opcional) Un gateway de intercambio de tráfico locales (LPG). Use un LPG para permitir el acceso desde otras VCN. Un LPG permite el acceso al cluster desde una instancia que se ejecuta en una VCN diferente. Cree un LPG en la VCN de OKE y cree un LPG en una segunda VCN en Compute Cloud@Customer. Utilice el comando de conexión de LPG para parar los dos LPG. Las redes virtuales en la nube con intercambio de tráfico pueden estar en distintos arrendamientos. Los CIDR de las redes virtuales en la nube con intercambio de tráfico no se pueden solapar. Consulte Conexión de redes virtuales en la nube a través de un gateway de intercambio de tráfico local.
Cree una regla de ruta para dirigir el tráfico de la subred de la VCN hacia y desde los LPG y reglas de seguridad para permitir o denegar determinados tipos de tráfico. Consulte Creación de una VCN (superposición de franela) o Creación de una VCN ( Pod nativo de VCN) para la tabla de rutas que se agregará a la VCN de OKE y a una tabla de rutas similar que se agregará a la segunda VCN. Agregue la misma regla de ruta en la segunda VCN y especifique el CIDR de la VCN de OKE como destino.
Instalar el SDK de OCI y
kubectlen la instancia de la segunda VCN y conectarse al cluster privado. Consulte Crear un archivo de configuración de Kubernetes. -
(Opcional) Gateway de direccionamiento dinámico (DRG). Utilice un DRG para activar el acceso desde la red local. Un DRG permite el tráfico entre la VCN de OKE y el espacio de dirección IP de la red local. Cree el DRG en el compartimento de la VCN de OKE y, a continuación, asocie la VCN de OKE a ese DRG. Consulte Conexión a la red local a través de un gateway de enrutamiento dinámico (DRG).
Cree una regla de ruta para dirigir el tráfico al espacio de dirección IP de la red del centro de datos local. Consulte Creación de una VCN (superposición de franela) o Creación de una VCN ( Pod nativo de VCN) para ver la tabla de rutas que se agregará a la VCN de OKE.