Configuración de recursos de red para despliegue y creación de clusters
Descubra cómo configurar recursos de red para utilizar Container Engine for Kubernetes (OKE).
Antes de poder utilizar Container Engine for Kubernetes para crear y desplegar clusters en las regiones de un arrendamiento:
- Dentro del arrendamiento, ya debe haber un compartimento que contenga los recursos de red necesarios (como VCN, subredes, gateway de Internet, tabla de rutas, grupos de seguridad de red y/o listas de seguridad). Si ese compartimento no existe, tendrá que crearlo. Tenga en cuenta que los recursos de red pueden residir en el compartimento raíz. Sin embargo, si espera que varios equipos creen clusters, se recomienda crear un compartimento independiente para cada equipo.
- Dentro del compartimento, los recursos de red (como VCN, subredes, gateway de Internet, tabla de rutas, grupos de seguridad de red y/o listas de seguridad) se deben configurar correctamente en cada región en la que desee crear y desplegar clusters. Al crear un nuevo cluster, puede hacer que Container Engine for Kubernetes cree y configure automáticamente nuevos recursos de red en el flujo de trabajo "Creación rápida". También puede especificar explícitamente los recursos de red existentes que se utilizarán en el flujo de trabajo "Creación personalizada". Si especifica recursos de red existentes, usted o alguna otra persona debe tener ya configurados esos recursos de la forma adecuada, como se describe en este tema.
En este tema se describe la configuración necesaria para cada recurso de red. Para ver detalles de una configuración típica, consulte Configuraciones de recurso de red de ejemplo.
Para obtener un tutorial introductorio, consulte Creación de un cluster con Oracle Cloud Infrastructure Container Engine for Kubernetes. También hay disponibles varios tutoriales de desarrolladores relacionados.
Configuración de VCN
La VCN en la que desea crear y desplegar clusters debe estar configurada de la siguiente manera:
- La VCN debe tener un bloque CIDR definido que sea lo suficientemente grande para todos los recursos que necesita un cluster (punto final de API de Kubernetes, nodos de trabajador, pods, equilibradores de carga). Un bloque CIDR/16 sería lo suficientemente grande para casi todos los casos de uso (10.0.0.0/16, por ejemplo). El bloque CIDR especificado para la VCN no se debe superponer con el bloque CIDR especificado para pods al utilizar el plugin CNI de canal (consulte Uso del plugin CNI de canal para redes de pod) y para los servicios Kubernetes (consulte Bloques CIDR y Container Engine for Kubernetes).
- La VCN debe tener un número adecuado de subredes definidas para los nodos de trabajador, para los equilibradores de carga, para el punto final de API de Kubernetes y para los pods al utilizar el plugin de CNI de red de pod nativos de VCN de OCI (consulte Uso del plugin de CNI de red de pod nativos de VCN de OCI). La mejor práctica es utilizar subredes regionales para facilitar la implantación de failover entre dominios de disponibilidad. Consulte Configuración de subred.
- La VCN debe tener reglas de seguridad definidas (en uno o ambos grupos de seguridad de red y/o listas de seguridad para cada subred). Consulte Configuración de reglas de seguridad en grupos de seguridad de red y/o listas de seguridad.
- Oracle recomienda que se seleccione la resolución de DNS para la VCN.
- Si utiliza subredes públicas, la VCN debe tener un gateway de Internet. Consulte Configuración de gateway de Internet.
- Si utiliza subredes privadas, la VCN debe tener un gateway de NAT y un gateway de servicio. Consulte Configuración de gateway de NAT y Configuración de gateway de servicio.
- Si la VCN tiene un gateway de NAT, un gateway de servicio o un gateway de Internet, debe tener una tabla de rutas con las reglas adecuadas definidas. Consulte Configuración de tabla de rutas.
Consulte VCN y subredes y Configuraciones de recursos de red de ejemplo.
Configuración de gateway de Internet
Si desea utilizar subredes públicas (para nodos de trabajador, equilibradores de carga y/o el punto final de API de Kubernetes) y las subrees necesitan acceso a Internet y desde Internet, la VCN debe tener un gateway de Internet. El gateway de Internet se debe especificar como el destino para el bloque de CIDR de destino 0.0.0.0/0 como una regla de ruta en una tabla de rutas.
Consulte VCN y subredes y Configuraciones de recursos de red de ejemplo.
Configuración de gateway de NAT
Si desea utilizar subredes privadas (para nodos de trabajador, punto final de API de Kubernetes o pods al utilizar el plugin CNI de red de pod nativo de VCN de OCI) y las subredes necesitan acceso a Internet, la VCN debe tener un gateway de NAT. Por ejemplo, si espera que las aplicaciones desplegadas descarguen software o accedan a servicios de terceros.
El gateway de NAT se debe especificar como el destino para el bloque de CIDR de destino 0.0.0.0/0 como una regla de ruta en una tabla de rutas.
Consulte Gateway de NAT y Configuraciones de recursos de red de ejemplo.
Configuración de gateway de servicio
Si desea utilizar subredes privadas para nodos de trabajador, el punto final de API de Kubernetes o los pods al utilizar el plugin CNI de red de pod nativo de VCN de OCI, la VCN debe tener un gateway de servicio.
Cree el gateway de servicio en la misma VCN y el mismo compartimento que la subred de nodos de trabajador, la subred de punto final de API de Kubernetes o la subred de pods, y seleccione la opción Todos los servicios de <region> en Oracle Services Network.
El gateway de servicio se debe especificar como el destino para Todos los servicios de <region> en Oracle Services Network como regla de ruta en una tabla de rutas.
Consulte Acceso a Oracle Services: gateway de servicio y Configuraciones de recursos de red de ejemplo.
Configuración de tabla de rutas
Tabla de rutas para subredes de nodos de trabajador
Si desea desplegar nodos de trabajador en una subred pública, la tabla de rutas de subred debe tener una regla de ruta que especifique el gateway de Internet como el destino para el bloque de CIDR de destino 0.0.0.0/0.
Si desea desplegar nodos de trabajador en una subred privada, la tabla de rutas de subred debe tener:
- regla de ruta que especifica el gateway de servicio como el destino para Todos los servicios de <region> en Oracle Services Network
- regla de ruta que especifica el gateway de NAT como destino para el bloque de CIDR de destino 0.0.0.0/0
Tabla de rutas para subredes de punto final de API de Kubernetes
Si desea desplegar el punto final de API de Kubernetes en una subred pública, la tabla de rutas de subred debe tener una regla de ruta que especifique el gateway de Internet como destino para el bloque de CIDR de destino 0.0.0.0/0.
Si desea desplegar el punto final de API de Kubernetes en una subred privada, la tabla de rutas de subred debe tener:
- regla de ruta que especifica el gateway de servicio como el destino para Todos los servicios de <region> en Oracle Services Network
- regla de ruta que especifica el gateway de NAT como destino para el bloque de CIDR de destino 0.0.0.0/0
Tabla de rutas para subredes de equilibrador de carga
Si desea desplegar equilibradores de carga en subredes públicas, la tabla de rutas de subred debe tener una regla de ruta que especifique el gateway de Internet como destino para el bloque de CIDR de destino 0.0.0.0/0.
Si desea desplegar equilibradores de carga en subredes privadas, la tabla de rutas de subred puede estar vacía.
Tabla de rutas de la subred de pods
Si desea utilizar el plugin CNI de redes de pod nativo de VCN de OCI para redes de pod, despliegue los pods en una subred privada. La tabla de rutas de subred debe tener:
- regla de ruta que especifica el gateway de servicio como el destino para Todos los servicios de <region> en Oracle Services Network
- regla de ruta que especifica el gateway de NAT como destino para el bloque de CIDR de destino 0.0.0.0/0
Si desea utilizar el plugin CNI de canal para redes de pod, no se necesita una subred de pod.
Notas sobre la configuración de tabla de rutas
-
Para evitar la posibilidad de un enrutamiento asimétrico, una tabla de rutas para una subred pública no puede contener una regla de ruta que apunte a un gateway de Internet y una regla de ruta que apunte a un gateway de servicio (consulte Problemas de acceso a sus instancias públicas desde servicios de Oracle a través de un gateway de servicio).
-
Para obtener más información sobre la configuración de tablas de rutas, consulte:
Configuración de opciones de DHCP
La VCN en la que desea crear y desplegar clusters debe tener opciones de DHCP configuradas. El valor por defecto para el tipo de DNS de solucionador de VCN e Internet es aceptable.
Consulte Opciones de DHCP y Configuraciones de recursos de red de ejemplo.
Configuración de subred
Las características del cluster que desea crear determinarán el número de subredes que se van a configurar. La mejor práctica es utilizar subredes regionales para facilitar la implantación de failover entre dominios de disponibilidad.
La VCN en la que desea crear y desplegar clusters debe tener al menos dos subredes diferentes (opcionalmente, más):
- una subred de punto final de API de Kubernetes
- una subred de nodos de trabajador
- una subred de equilibrador de carga regional o específica de AD (opcional)
- una subred de pods (cuando se utilizan redes de pods nativas de VCN)
- una subred bastión (opcional)
Puede combinar las subredes y también combinar reglas de seguridad. Sin embargo, este enfoque dificulta la gestión de la seguridad y, por lo tanto, no se recomienda a menos que utilice grupos de seguridad de red para controlar el acceso a los clusters.
Los bloques de CIDR de subred no se deben solapar con los bloques de CIDR que especifique para los pods que se ejecutan en el cluster (consulte Bloques de CIDR y Container Engine for Kubernetes).
Los nodos virtuales y los nodos gestionados tienen requisitos diferentes, por lo que debe configurar subredes de nodos de trabajador y subredes de pod de forma ligeramente diferente al utilizar nodos virtuales en lugar de nodos gestionados.
Las subredes deben configurarse con las siguientes propiedades:
- Tabla de rutas: consulte Configuración de tabla de rutas
- Opciones de DHCP: consulte Configuración de opciones de DHCP
- Grupos de seguridad de red y/o lista de seguridad: consulte Configuración de reglas de seguridad en grupos de seguridad de red y/o listas de seguridad
Consulte VCN y subredes y Configuraciones de recursos de red de ejemplo.
Configuración de subred de punto final de API de Kubernetes
La subred de punto final de API de Kubernetes aloja un punto final que proporciona acceso a la API de Kubernetes en el plano de control de cluster.
La subred de punto final de API de Kubernetes debe ser una subred regional, y puede ser una subred privada o pública:
- Si especifica una subred pública para el punto final de API de Kubernetes, puede exponer opcionalmente el punto final a Internet asignando una dirección IP pública al punto final. La dirección IP pública permite que los servicios en la nube de terceros (como los servicios CI/CD de SaaS) accedan al punto final de API de Kubernetes. Tenga en cuenta lo siguiente:
- Si el punto final de API de Kubernetes tiene una dirección IP pública, deben existir reglas de ruta y reglas de seguridad para permitir el acceso al punto final mediante un gateway de Internet (consulte Ejemplo 1: Cluster con CNI de franela) Plugin, punto final de API de Kubernetes público, nodos de trabajador privados y equilibradores de carga públicos y Ejemplo 3: cluster con plugin de OCI CNI, punto final de API de Kubernetes público, nodos de trabajador privados y equilibradores de carga públicos.
- Si el punto final de API de Kubernetes no tiene una dirección IP pública, deben existir reglas de ruta y reglas de seguridad para permitir el acceso al punto final mediante un gateway de servicio y un gateway de NAT (consulte Ejemplo 2: cluster) con el plugin CNI de franela, el punto final de la API de Kubernetes privado, los nodos de trabajador privados y los equilibradores de carga públicos y el Ejemplo 4: cluster con el plugin de OCI CNI, el punto final de la API de Kubernetes privado, los nodos de trabajador privados y los equilibradores de carga públicos).
- Después de crear un cluster, puede cambiar posteriormente si se asigna una dirección IP pública al punto final de API de Kubernetes. Si cambia si se asigna una dirección IP pública al punto final, tenga en cuenta que también debe actualizar las reglas de ruta y las reglas de seguridad correctamente.
- Si especifica una subred privada para el punto final de API de Kubernetes, el tráfico puede acceder a la subred del punto final de API de Kubernetes desde otra subred de VCN, desde otra VCN o desde la red local (con intercambio de tráfico mediante FastConnect). También puede configurar un host bastión en una subred pública para llegar al punto final de API de Kubernetes (consulte Configuración de un bastión para el acceso al cluster).
Configuración de subred de nodo de trabajador
Una subred de nodo de trabajador aloja los nodos de trabajador. Todos los nodos gestionados de un pool de nodos pertenecen a la misma subred de nodo de trabajador.
La subred de nodo de trabajador puede ser una única subred regional o varias subredes específicas de dominio de disponibilidad (una en cada uno de los dominios de disponibilidad).
Nodos gestionados/autogestionados: la subred de nodo de trabajador puede ser una subred pública o una subred privada. Sin embargo, recomendamos que la subred de nodo de trabajador sea una subred privada para garantizar la máxima seguridad.
Nodos virtuales: la subred de nodo de trabajador puede ser una subred pública o una subred privada. Sin embargo, recomendamos que la subred de nodo de trabajador sea una subred privada para garantizar la máxima seguridad. También recomendamos que la subred de nodo de trabajador y la subred de pod sean la misma subred (en cuyo caso, la subred de nodo de trabajador debe ser una subred privada porque los nodos virtuales necesitan que la subred de pod sea una subred privada).
Configuración de subred de pod
Una subred de pod aloja los pods en los nodos de trabajador de un pool de nodos al utilizar redes de pod nativas de VCN (consulte Uso del plugin CNI de redes de pod nativas de VCN de OCI para redes de pod).
La subred de pod debe ser una única subred regional.
Nodos gestionados: la subred de pod puede ser una subred pública o una subred privada. Sin embargo, recomendamos que la subred de pod sea una subred privada para garantizar la máxima seguridad.
Nodos virtuales: la subred de pod debe ser una subred privada. Recomendamos que la subred de pod y la subred de nodo de trabajador sean la misma subred (en cuyo caso, la subred de nodo de trabajador también debe ser una subred privada).
Configuración de subred de equilibrador de carga
Las subredes de equilibrador de carga conectan equilibradores de carga de Oracle Cloud Infrastructure creados por los servicios de Kubernetes del tipo LoadBalancer.
Las subredes de equilibrador de carga pueden ser subredes regionales únicas o subredes específicas de dominio de disponibilidad (una en cada uno de los dominios de disponibilidad). Sin embargo, recomendamos subredes regionales.
Las subredes de equilibrador de carga pueden ser subredes públicas o privadas, en función de cómo se acceda a las aplicaciones desplegadas en el cluster. Si se accede a las aplicaciones internamente desde la VCN, utilice subredes privadas para las subredes de equilibrador de carga. Si se accede a las aplicaciones desde Internet, utilice subredes públicas para las subredes de equilibrador de carga.
Configuración de subred de bastión (opcional)
Un bastión opcional en una subred bastión puede proporcionar acceso seguro al punto final de API de Kubernetes y acceso SSH a los nodos de trabajador. Consulte Configuración de un bastión para el acceso a los clusters.
Configuración de reglas de seguridad en grupos de seguridad de red y/o listas de seguridad
La VCN en la que desea crear y desplegar clusters debe tener reglas de seguridad definidas. Puede definir las reglas de seguridad de una de las siguientes formas o de ambas:
- En los grupos de seguridad de red (recomendado) que seleccione para los pools de nodos, para el punto final de API de Kubernetes, para los pods (cuando se utilizan redes de pods nativas de VCN) y para los equilibradores de carga (si se especifica) al crear un cluster.
- En las listas de seguridad que ya están asociadas a las subredes que seleccione para los nodos de trabajador, para el punto final de API de Kubernetes, para los pods (cuando se utilizan redes de pods nativas de VCN) y para los equilibradores de carga (si se especifica) al crear un cluster.
Los nodos de trabajador, el punto final de API de Kubernetes, los pods (cuando se utilizan redes de pods nativas de VCN) y el equilibrador de carga tienen diferentes requisitos de reglas de seguridad, como se describe en este tema. Puede agregar reglas adicionales para satisfacer sus necesidades específicas.
Si especifica reglas de seguridad tanto en grupos de seguridad de red como en listas de seguridad, se aplican todas las reglas de seguridad (es decir, la unión de las reglas de seguridad).
Para obtener más información, consulte:
- Configuraciones de recursos de red de ejemplo
- Listas de seguridad
- Grupos de seguridad de red
- Reglas de seguridad
Reglas de seguridad para el punto final de API de Kubernetes
Se deben definir las siguientes reglas de entrada para el punto final de API de Kubernetes, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Origen | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | CIDR de nodos de trabajador | TCP/6443 | Comunicación del nodo de trabajador de Kubernetes al punto final de API de Kubernetes. |
| Con estado | CIDR de nodos de trabajador | TCP/12250 | Comunicación del nodo de trabajador de Kubernetes al punto final de API de Kubernetes. |
| Con estado | CIDR de pods | TCP/6443 | Comunicación de punto final de API de Pod a Kubernetes (cuando se utiliza la red de pod nativa de VCN). |
| Con estado | CIDR de pods | TCP/12250 | Comunicación de punto final de API de Pod a Kubernetes (cuando se utiliza la red de pod nativa de VCN). |
| Con estado | CIDR de nodos de trabajador | ICMP 3,4 | Detección de ruta. |
Se pueden definir las siguientes reglas de entrada opcionales para el punto final de API de Kubernetes, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Origen | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | 0.0.0.0/0 o subredes específicas | TCP/6443 | Acceso del cliente al punto final de API de Kubernetes |
Se deben definir las siguientes reglas de salida para el punto final de API de Kubernetes, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Destino | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | Todos los servicios de <region> en Oracle Services Network | TCP/443 | Permitir que el punto final de API de Kubernetes se comunique con OKE. |
| Con estado | CIDR de nodos de trabajador | TCP/TODOS | Todo el tráfico a los nodos de trabajador (cuando se utiliza flannel para redes de pod). |
| Con estado | CIDR de pods | TODOS/TODOS |
Comunicación de punto final de API de Kubernetes a pod (cuando se utiliza una red de pod nativa de VCN). |
| Con estado | CIDR de nodos de trabajador | ICMP 3,4 | Detección de ruta. |
| Con estado | CIDR de nodos de trabajador | TCP 10250, SELLO | Comunicación de punto final de API de Kubernetes a nodo de trabajador (cuando se utiliza una red de pod nativa de VCN). |
Reglas de seguridad para nodos de trabajador
Los nodos de trabajador se crean con direcciones IP públicas o privadas, en función de si se especifican subredes públicas o privadas al definir los pools de nodos en un cluster. Container Engine for Kubernetes debe poder acceder a los nodos de trabajador.
Se deben definir las siguientes reglas de entrada para los nodos de trabajador, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Origen | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | CIDR de nodos de trabajador | TODOS/TODOS | Permite la comunicación desde (o hacia) nodos de trabajador. |
| Con estado | CIDR de pods | TODOS/TODOS | Permitir que los pods en un nodo de trabajador se comuniquen con los pods en otros nodos de trabajador (cuando se utilizan redes de pods nativas de VCN). |
| Con estado | CIDR de punto final de API de Kubernetes | TCP/TODOS | Permitir que el punto final de API de Kubernetes se comunique con los nodos de trabajador. |
| Con estado | 0.0.0.0/0 | ICMP 3,4 | Detección de ruta. |
| Con estado | CIDR de punto final de API de Kubernetes | TCP 10250, SELLO | Comunicación de punto final de API de Kubernetes a nodo de trabajador (cuando se utiliza una red de pod nativa de VCN). |
Las siguientes reglas de entrada opcionales se pueden definir para nodos de trabajador (solo nodos gestionados), en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Origen | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | 0.0.0.0/0 o CIDR de subred | TCP/22 | (Opcional) Permitir tráfico SSH entrante a nodos de trabajador. |
Se deben definir las siguientes reglas de salida para los nodos de trabajador, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Destino | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | CIDR de nodos de trabajador | TODOS/TODOS | Permite la comunicación desde (o hacia) nodos de trabajador. |
| Con estado | CIDR de pods | TODOS/TODOS | Permitir que los nodos de trabajador se comuniquen con pods en otros nodos de trabajador (cuando se utilizan redes de pods nativas de VCN). |
| Con estado | 0.0.0.0/0 | ICMP 3,4 | Detección de ruta. |
| Con estado | Todos los servicios de <region> en Oracle Services Network | TCP/TODOS | Permitir que los nodos se comuniquen con OKE. |
| Con estado | CIDR de punto final de API de Kubernetes | TCP/6443 | Comunicación del nodo de trabajador de Kubernetes al punto final de API de Kubernetes. |
| Con estado | CIDR de punto final de API de Kubernetes | TCP/12250 | Comunicación del nodo de trabajador de Kubernetes al punto final de API de Kubernetes. |
Las siguientes reglas de salida opcionales se pueden definir para nodos de trabajador, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Destino | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | 0.0.0.0/0 | TCP/TODOS | (Opcional) Permitir que los nodos de trabajador se comuniquen con Internet. |
Reglas de seguridad para subredes de pod
Al utilizar el plugin CNI de red de pod nativo de VCN de OCI para redes de pod:
-
las reglas de seguridad definidas para la subred del nodo de trabajador, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad, deben incluir:
- Reglas de entrada y salida con estado que permiten todo el tráfico entre nodos de trabajador
- Reglas de entrada y salida con estado que permiten todo el tráfico entre los nodos de trabajador y el equilibrador de carga
- Reglas de salida con estado que permitan el tráfico entre nodos de trabajador y Container Engine for Kubernetes
- las reglas de seguridad definidas para la subred de pod, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad, deben incluir reglas de entrada y salida con estado que permitan todo el tráfico entre pods
Las siguientes reglas de entrada se deben definir para subredes de pod, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Origen | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | CIDR de punto final de API de Kubernetes | TODOS/TODOS | Comunicación de punto final de API de Kubernetes a pod (cuando se utiliza una red de pod nativa de VCN). |
| Con estado | CIDR de nodos de trabajador | TODOS/TODOS | Permitir que los pods en un nodo de trabajador se comuniquen con los pods en otros nodos de trabajador. |
| Con estado | CIDR de pods | TODOS/TODOS | Permitir que los pods se comuniquen entre sí. |
Se deben definir las siguientes reglas de salida para las subredes de pod, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Destino | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | CIDR de pods | TODOS/TODOS | Permitir que los pods se comuniquen entre sí. |
| Con estado | Todos los servicios de <region> en Oracle Services Network | ICMP 3,4 | Detección de ruta. |
| Con estado | Todos los servicios de <region> en Oracle Services Network | TCP/TODOS | Permitir que los nodos de trabajador se comuniquen con los servicios de OCI. |
| Con estado | CIDR de punto final de API de Kubernetes | TCP/6443 | Comunicación de punto final de API de Pod a Kubernetes (cuando se utiliza la red de pod nativa de VCN). |
| Con estado | CIDR de punto final de API de Kubernetes | TCP/12250 | Comunicación de punto final de API de Pod a Kubernetes (cuando se utiliza la red de pod nativa de VCN). |
Las siguientes reglas de salida opcionales se pueden definir para una subred de pod, en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad:
| Estado | Destino | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | 0.0.0.0/0 | TCP/443 | (Opcional) Permitir que los pods se comuniquen con Internet. |
Reglas de seguridad para equilibrador de carga y equilibrador de carga de red
Cuando Container Engine for Kubernetes aprovisiona un equilibrador de carga de OCI o un equilibrador de carga de red para un servicio de Kubernetes de tipo LoadBalancer, deben existir reglas de seguridad adecuadas para permitir el tráfico entrante y saliente hacia y desde la subred del equilibrador de carga o del equilibrador de carga de red. En el caso de los nodos gestionados (no los nodos virtuales), estas reglas de seguridad se crean automáticamente por defecto para los equilibradores de carga, pero no se crean automáticamente por defecto para los equilibradores de carga de red. Para obtener más información sobre el aprovisionamiento de un equilibrador de carga de OCI o un equilibrador de carga de red para un servicio de Kubernetes de tipo LoadBalancer, consulte Definición de servicios de Kubernetes de tipo LoadBalancer.
Puede definir reglas de seguridad de entrada y salida para la subred en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad. Para obtener más información, consulte:
- Especificación de grupos de seguridad de red (recomendado)
- Especificación de opciones de gestión de lista de seguridad al aprovisionar un equilibrador de carga de OCI
- Especificación de opciones de gestión de lista de seguridad al aprovisionar un equilibrador de carga de red de OCI
Defina la siguiente regla de seguridad de entrada en uno o en ambos:
- grupo de seguridad de red (recomendado) al que se ha agregado el equilibrador de carga o el recurso del equilibrador de carga de red
- una lista de seguridad asociada a la subred del equilibrador de carga o del equilibrador de carga de red
| Estado | Origen | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | 0.0.0.0/0 o CIDR específico | TCP/443 | Permita el tráfico entrante al equilibrador de carga. |
Defina el protocolo y el puerto de destino de la regla de entrada según los requisitos específicos de la aplicación. Por ejemplo, especifique UDP como protocolo para una aplicación que maneja el tráfico UDP.
Defina la siguiente regla de seguridad de salida en uno o en ambos:
- grupo de seguridad de red (recomendado) al que se ha agregado el equilibrador de carga o el recurso del equilibrador de carga de red
- una lista de seguridad asociada a la subred del equilibrador de carga o del equilibrador de carga de red
| Estado | Destino | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | CIDR de nodos de trabajador | TODO/30000-32767 | Permitir tráfico a nodos de trabajador. |
Por defecto, los equilibradores de carga de OCI o los equilibradores de carga de red aprovisionados por el proxy de Container Engine for Kubernetes solicitan todos los nodos de trabajador del cluster. Cuando las solicitudes se conectan mediante proxy a nodos de trabajador en el cluster, deben existir las siguientes reglas de seguridad de entrada y salida (en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad) para que el equilibrador de carga o el equilibrador de carga de red se comuniquen con los nodos de trabajador en el puerto 10256 (el puerto de estado de kube-proxy):
- Regla de seguridad de entrada para la lista de seguridad de subred de nodo de trabajador (o grupo de seguridad de red) para permitir que el equilibrador de carga o el equilibrador de carga de red se comuniquen con kube-proxy en nodos de trabajador:
Estado Origen Protocolo/puerto de destino Descripción Con estado Equilibrador de carga o CIDR de subred de equilibrador de carga de red TODO/10256 Permitir que el equilibrador de carga de OCI o el equilibrador de carga de red se comuniquen con kube-proxy en nodos de trabajador. - Regla de seguridad de salida para la lista de seguridad de subred (o grupo de seguridad de red) del equilibrador de carga o equilibrador de carga de red para permitir que el equilibrador de carga o el equilibrador de carga de red se comuniquen con kube-proxy en nodos de trabajador:
Estado Destino Protocolo/puerto de destino Descripción Con estado CIDR de subred de nodo de trabajo TODO/10256 Permitir que el equilibrador de carga de OCI o el equilibrador de carga de red se comuniquen con kube-proxy en nodos de trabajador.
Al aprovisionar un equilibrador de carga de red para un servicio de Kubernetes de tipo LoadBalancer:
- Puede especificar que las solicitudes terminen en la dirección IP del cliente especificada en las cabeceras de los paquetes IP, en lugar de conectarse mediante proxy a otros nodos de trabajador del cluster (configurando
externalTrafficPolicy: Local). Consulte Terminación de solicitudes en el nodo de recepción. - Si especifica que las solicitudes terminen en la dirección IP del cliente, también puede especificar si desea conservar la dirección IP del cliente en las cabeceras de los paquetes IP (mediante la anotación
oci-network-load-balancer.oraclecloud.com/is-preserve-source). Consulte Preserving The Client IP Address.
Tenga en cuenta que, en ambos casos, debe haber configurado una regla de seguridad (en un grupo de seguridad de red (recomendado) y/o en una lista de seguridad) para que los nodos de trabajador del cluster permitan el tráfico de entrada desde el bloque CIDR donde se realizan las conexiones de cliente, a todos los puertos de nodo (30000 a 32767). Si la aplicación está expuesta a Internet, defina el bloque de CIDR de origen de la regla de seguridad en 0.0.0.0/0. También puede definir el bloque de CIDR de origen de la regla de seguridad en un bloque de CIDR específico (por ejemplo, si las conexiones de cliente provienen de una subred específica).
| Estado | Origen | Protocolo/puerto de destino | Descripción |
|---|---|---|---|
| Con estado | 0.0.0.0/0 o CIDR de subred | TODO/30000-32767 | Permitir que los nodos de trabajador reciban conexiones a través del equilibrador de carga de red de OCI. |
Reglas de seguridad para subredes de bastión
Un bastión opcional en una subred bastión puede proporcionar acceso seguro al punto final de API de Kubernetes y acceso SSH a los nodos de trabajador. Para obtener información sobre las reglas de seguridad de entrada y salida que se deben definir, consulte Configuración de un bastión para el acceso al cluster.