Configuración de subredes de VPC
Nube privada virtual
Cambie la agrupación de las direcciones IP públicas o privadas portátiles disponibles añadiendo subredes a su clúster VPC de IBM Cloud® Kubernetes Service.
El contenido de esta página es específico de los clústeres de VPC. Para obtener información sobre los clústeres clásicos, consulte Configuración de subredes y direcciones IP para clústeres clásicos.
Visión general de la red de VPC en IBM Cloud Kubernetes Service
Comprenda los conceptos básicos de la red de VPC en los clústeres de IBM Cloud Kubernetes Service.
Subredes
Antes de crear un clúster VPC por primera vez, debe crear una subred VPC en cada zona en la que desee desplegar nodos de trabajador. Una subred de VPC es un rango específico de direcciones IP privadas (bloque de CIDR) y configura un grupo de nodos trabajadores y pods como si estuvieran conectados a la misma conexión física.
Cuando se crea un clúster, solo se puede especificar una subred de VPC existente para cada zona. Cada nodo trabajador que añada en un clúster se despliega con una dirección IP privada de la subred de VPC en dicha zona. Una vez suministrado
el nodo trabajador, la dirección IP del nodo trabajador persiste tras una operación reboot
, pero la dirección IP del nodo trabajador cambia después de las operaciones replace
y update
.
No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.
¿Cuántas direcciones IP necesito para mi subred VPC?
Cuando cree su subred VPC, asegúrese de crear una subred con suficientes direcciones IP para su clúster, como 256. Después, ya no puede cambiar el número de direcciones IP que tiene una subred de VPC.
Tenga en cuenta las siguientes restricciones en cuanto a las direcciones IP.
- De forma predeterminada, 5 direcciones IP de cada subred están reservadas por VPC.
- se requiere 1 dirección IP de una subred en cada zona en la que su clúster tenga nodos trabajadores para la puerta de enlace de los puntos finales privados virtuales(VPE).
- Se requiere una dirección IP por cada nodo trabajador de su clúster.
- Se requiere una dirección IP cada vez que se actualiza o se reemplaza un nodo trabajador. Estas direcciones IP son eventualmente reclamadas y disponibles para su reutilización.
- Se utilizan 2 direcciones IP cada vez que se crea un equilibrador de carga público o privado. Si tiene un clúster multizona, estas 2 direcciones IP se distribuyen por zonas, por lo que es posible que la subred no tenga una dirección IP reservada.
- Otros recursos de red que configure para el clúster, como por ejemplo un escalado automático de VPNaaS o LBaaS, pueden necesitar direcciones IP adicionales o tener otras limitaciones de servicio. Por ejemplo, el escalado automático de LBaaS podría escalar hasta 16 direcciones IP por equilibrador de carga.
¿Qué rangos de IP puedo utilizar para mis subredes VPC?
El rango predeterminado de direcciones IP para subredes de VPC es 10.0.0.0 – 10.255.255.255. Para ver una lista de rangos de direcciones IP por zona de VPC, consulte los prefijos de dirección predeterminados de VPC.
Si tiene que crear el clúster utilizando subredes de rango personalizado, consulte la guía de prefijos de direcciones personalizados. Sin embargo, si se usan subredes de rango personalizado para los nodos de trabajador, hay que asegurarse de que el rango de IP de las subredes de nodos de trabajador no se solapen con la subred de pods del clúster. La subred de pod varía en función de las opciones de subred durante la creación del clúster y el tipo de infraestructura del clúster:
- Si especificó su propia subred de pods en la opción
--pod-subnet
durante la creación del cluster, a sus pods se les asignarán direcciones IP de este rango. - Si no ha especificado una subred de pod personalizada durante la creación del clúster, el clúster utiliza la subred de pod predeterminada. En el primer clúster que cree en una VPC, la subred de pod predeterminada es
172.17.0.0/18
. En el segundo clúster que cree en dicha VPC, la subred de pod predeterminada es172.17.64.0/18
. En cada clúster posterior, el rango de subred de pod es la siguiente subred/18
disponible que no se solape.
¿Cómo crear subredes para el acceso a la infraestructura clásica?
Si habilita el acceso clásico al crear la VPC, los prefijos de dirección predeterminados de acceso clásico determinan automáticamente los rangos de IP de las subredes que cree. Sin embargo, los rangos de IP predeterminados para las subredes de VPC de acceso clásico entran en conflicto con las subredes para el plano de control de IBM Cloud Kubernetes Service. En su lugar, debe crear la VPC sin los prefijos de direcciones predeterminados automáticos y, a continuación, crear sus propios prefijos de direcciones y subredes dentro de esos rangos para su clúster.
¿Puedo especificar subredes para pods y servicios en mi clúster?
Si tiene previsto conectar el clúster a redes locales mediante IBM Cloud Direct Link o un servicio VPN, puede evitar conflictos de subred si especifica un CIDR de subred personalizada que proporcione las direcciones IP privadas de los pods y un CIDR de subred personalizado para proporcionar las direcciones IP privadas de los servicios.
Para especificar subredes de pods y servicios personalizadas durante la creación del clúster, utilice las opciones --pod-subnet
y --service-subnet
en el comando CLI ibmcloud ks cluster create
.
Para ver los pods y subredes de servicio que utiliza el clúster, busque los campos Pod Subnet
y Service Subnet
en la salida de ibmcloud ks cluster get
.
Pods
- Rango predeterminado
-
En el primer clúster que cree en una VPC, la subred de pod predeterminada es
172.17.0.0/18
. En el segundo clúster que cree en dicha VPC, la subred de pod predeterminada es172.17.64.0/18
. En cada clúster posterior, el rango de subred de pod es la siguiente subred/18
disponible que no se solape. - Requisitos de tamaño
-
Al especificar una subred personalizada, tenga en cuenta el tamaño del clúster que tenga previsto crear y el número de nodos de trabajador que podría añadir en el futuro. La subred debe tener un CIDR de al menos
/23
, que proporciona suficientes IP de pod para un máximo de cuatro nodos trabajadores en un clúster. Para clústeres más grandes, utilice/22
para tener suficientes direcciones IP de pod para ocho nodos trabajadores,/21
para tener suficientes direcciones IP de pod para 16 nodos trabajadores, etc. -
Para los clústeres de VPC, puede especificar el tamaño de subred incluyéndolo en la opción
--pod-subnet
. Por ejemplo:--pod-subnet 0.0.0.0/X
dondeX
es el tamaño de subred de pod necesario. A continuación, se selecciona automáticamente la subred de pod. Al asignar la subred de pod automáticamente, la asignación se iniciará desde172.17.0.0
, la subred más grande se limita a13
y el tamaño de subred más pequeño se limita a23
. -
Existe un límite global para los nodos trabajadores. No puede superar los 500 nodos de trabajador en todos los clústeres de una región.
- Requisitos de rango
-
Las subredes de pod y servicio no se pueden solapar entre sí, y la subred de pod no se puede solapar con las subredes de VPC para los nodos de trabajador. La subred elegida tiene que pertenecer a uno de los siguientes rangos.
-
172.17.0.0 - 172.17.255.255
-
172.21.0.0 - 172.31.255.255
-
192.168.0.0 - 192.168.255.255
-
198.18.0.0 - 198.19.255.255
-
Servicios
- Rango predeterminado
- De forma predeterminada, todos los servicios que se despliegan en el clúster tienen asignada una dirección IP privada en el rango
172.21.0.0/16
. - Requisitos de tamaño
- Cuando se especifica una subred personalizada, la subred debe especificarse en formato CIDR con un tamaño de al menos
/24
, lo que permite un máximo de 255 servicios en el clúster, o con un tamaño mayor. - Requisitos de rango
- Las subredes de pod y servicio no se pueden solapar entre sí. La subred elegida tiene que pertenecer a uno de los siguientes rangos.
-
172.17.0.0 - 172.17.255.255
-
172.21.0.0 - 172.31.255.255
-
192.168.0.0 - 192.168.255.255
-
198.18.0.0 - 198.19.255.255
-
Pasarelas públicas
Una pasarela pública permite que una subred y todos los nodos trabajadores conectados a la subred establezcan conexiones de salida a internet. Si los nodos trabajadores deben acceder a un punto final público fuera del clúster, puede habilitar una pasarela pública en las subredes de VPC en las que se despliegan los nodos trabajadores.
Si un servicio de IBM Cloud no da soporte a puntos finales de servicio en la nube privados, los nodos trabajadores deben estar conectados a una subred que tenga una pasarela pública conectada. Los pods de dichos nodos trabajadores se pueden
comunicar de forma segura con los servicios a través de la red pública a través de la pasarela pública de la subred. Tenga en cuenta que no se necesita una pasarela pública en las subredes para permitir el tráfico de red de entrada de Internet
a los servicios LoadBalancer
o ALB.
Dentro de una VPC, solo puede crear una pasarela pública por zona, pero dicha pasarela pública se puede conectar a varias subredes dentro de la zona. Para obtener más información sobre las pasarelas públicas, consulte la documentación sobre redes para VPC.
Puntos finales privados virtuales (VPE)
Los nodos trabajadores se pueden comunicar con el nodo maestro de Kubernetes a través del punto final privado virtual(VPE) del clúster.
Un VPE es una dirección IP virtual enlazada a una pasarela de punto final. Se crea un recurso de pasarela de VPE por clúster en la VPC. Una dirección IP de una subred en cada zona en la que el clúster tiene nodos trabajadores se utiliza automáticamente
para la pasarela de VPE, y los nodos trabajadores de esta zona utilizan esta dirección IP para comunicarse con el maestro de Kubernetes. Para ver los detalles de la puerta de enlace VPE de su clúster, abra el panel Virtual private endpoint gateways for VPC y busque la puerta de enlace VPE en el formato iks-<cluster_ID>
.
Tenga en cuenta que los nodos trabajadores utilizan automáticamente el VPE que se crea de forma predeterminada en la VPC. Sin embargo, si ha habilitado el punto final de servicio en la nube público para el clúster, el tráfico de trabajador a maestro se establece la mitad sobre el punto final público y la mitad sobre el VPE para la protección frente a posibles interrupciones de la red pública o privada.
No suprima ninguna dirección IP en las subredes que se utilizan para los VPE.
Segmentación de red
La segmentación de red describe el enfoque para dividir una red en varias subredes. Las aplicaciones que se ejecutan en una subred no pueden ver las aplicaciones de otra subred ni acceder a ellas. Para obtener más información sobre las opciones de segmentación de red y para subredes de VPC, consulte este tema sobre la seguridad del clúster.
Las subredes proporcionan un canal para la conectividad entre los nodos trabajadores dentro del clúster. Además, cualquier sistema que esté conectado a cualquiera de las subredes privadas en la misma VPC puede comunicarse con los nodos trabajadores. Por ejemplo, todas las subredes de una VPC se pueden comunicar a través del direccionamiento de capa 3 privado con un direccionador de VPC incorporado.
Si tiene varios clústeres que deben comunicarse entre sí, puede crear los clústeres en la misma VPC. Sin embargo, si los clústeres no necesitan comunicarse, puede lograr una mejor segmentación de la red creando los clústeres en VPC independientes. También puede crear listas de control de accesos (ACL) para las subredes de VPC para que medien en el tráfico en la red privada. Las ACL constan de reglas de entrada y de salida que definen las entradas y salidas permitidas para cada subred de VPC.
Limitaciones de las redes de VPC
Cuando cree subredes de VPC para los clústeres, tenga en cuenta las siguientes características y limitaciones.
- El tamaño de CIDR predeterminado de cada subred de VPC es
/24
, que puede dar soporte a un máximo de 253 nodos trabajadores. Si tiene intención de desplegar más de 250 nodos trabajadores por zona en un clúster, tenga en cuenta la posibilidad de crear una subred de mayor tamaño. - Después de crear una subred de VPC, no puede cambiarse el tamaño ni su rango de IP.
- Varios clústeres de la misma VPC pueden compartir subredes de VPC. Sin embargo, las subredes de servicio y pod personalizadas no se pueden compartir entre varios clústeres.
- Las subredes de la VPC están vinculadas a una región multizona de un único campus y no pueden abarcar varias zonas o regiones.
- Después de crear una subred, no puede moverla a otra zona, región o VPC.
- Si tiene nodos de trabajador conectados a una subred existente en una zona, no puede cambiar la subred de esa zona en el clúster.
- Los rangos
172.16.0.0/16
,172.18.0.0/16
,172.19.0.0/16
y172.20.0.0/16
están prohibidos. - Dentro de una VPC, solo puede crear una pasarela pública por zona, pero dicha pasarela pública se puede conectar a varias subredes dentro de la zona.
- Los prefijos de direcciones predeterminadas de acceso clásico entran en conflicto con las subredes para el plano de control de IBM Cloud Kubernetes Service. Debe crear la VPC sin los prefijos de direcciones predeterminados automáticos y, a continuación, crear sus propios prefijos de direcciones y subredes dentro de esos rangos para su clúster.
Creación de una subred de VPC y conexión de una pasarela pública
Cree una subred de VPC para su clúster y, si lo desea, conecte una pasarela pública a la subred.
Creación de una subred de VPC en la consola
Utilice la consola de IBM Cloud para crear una subred de VPC para su clúster y, si lo desea, conecte una pasarela pública a la subred.
- En el panel de control de la subred de VPC, pulse Crear.
- Especifique un nombre para la subred y seleccione el nombre de la VPC que ha creado.
- Seleccione la ubicación y la zona en las que desea crear la subred.
- Especifique el número de direcciones IP que se deben crear.
- Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
- Si especifica un rango de IP específico, no utilice los siguientes rangos reservados:
172.16.0.0/16
,172.18.0.0/16
,172.19.0.0/16
y172.20.0.0/16
.
- Elija si desea conectar una pasarela de red pública a la subred. Se necesita una pasarela de red pública cuando se desea que el clúster acceda a puntos finales públicos, como un URL público de otra app o un servicio de IBM Cloud que solo de soporte a los puntos finales de servicio en la nube público.
- Pulse Crear subred.
- Utilice la subred para crear un clúster, crear una nueva agrupación de trabajadores o añadir la subred a una agrupación de trabajadores existente.> No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.
Creación de una subred de VPC en la CLI
Utilice la CLI de IBM Cloud para crear una subred de VPC para su clúster y, si lo desea, conecte una pasarela pública a la subred.
Antes de empezar
- En la línea de mandatos, inicie una sesión en su cuenta de IBM Cloud y elija como destino la región y grupo de recursos de IBM Cloud donde desea crear el clúster de VPC. Para ver las regiones soportadas, consulte Creación de una VPC en otra región.
El grupo de recursos del clúster puede diferir del grupo de recursos de VPC. Escriba sus credenciales de IBM Cloud cuando se le solicite. Si dispone de un ID federado, utilice la opción
--sso
para conectarse.ibmcloud login -r <region> [-g <resource_group>] [--sso]
- Create a VPC in the same region where you want to create the cluster.
Para crear una subred de VPC, siga estos pasos.
-
Obtenga el ID de la VPC donde desea crear la subred.
ibmcloud ks vpcs
-
Cree la subred. Para obtener más información sobre las opciones de este mandato, revise la referencia de CLI.
ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address>
- Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
- No utilice los siguientes rangos reservados:
172.16.0.0/16
,172.18.0.0/16
,172.19.0.0/16
, y172.20.0.0/16
.
-
Compruebe si tiene una pasarela pública en las zonas en las que desea crear un clúster. Dentro de una VPC, solo puede crear una pasarela pública por zona, pero dicha pasarela pública se puede conectar a varias subredes dentro de la zona.
ibmcloud is public-gateways
Salida de ejemplo
ID Name VPC Zone Floating IP Created Status Resource group 26426426-6065-4716-a90b-ac7ed7917c63 test-pgw testvpc(36c8f522-.) us-south-1 169.xx.xxx.xxx(26466378-.) 2019-09-20T16:27:32-05:00 available - 2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374 team3(ff537d43-.) us-south-2 169.xx.xxx.xxx(2ba9a280-.) 2019-08-02T10:30:29-05:00 available -
- Si ya tiene una pasarela pública en cada zona, anote los ID de las pasarelas públicas.
- Si no tiene una pasarela pública en cada zona, cree una pasarela pública. Recuerde nombrar la pasarela pública con en el formato
<cluster>-<zone>-gateway
. En la salida, anote el ID de la pasarela pública.
ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
Salida de ejemplo
ID 26466378-6065-4716-a90b-ac7ed7917c63 Name mycluster-us-south-1-gateway Floating IP 169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63) Status pending Created 2019-09-20T16:27:32-05:00 Zone us-south-1 VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf) Resource group -
-
Utilizando los ID de la pasarela pública y de la subred, conecte la pasarela pública a la subred.
ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
Salida de ejemplo
ID 91e946b4-7094-46d0-9223-5c2dea2e5023 Name mysubnet1 IPv4 CIDR 10.240.xx.xx/24 Address available 250 Address total 256 ACL allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906) Gateway mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63) Created 2019-08-21T09:43:11-05:00 Status available Zone us-south-1 VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
-
Utilice la subred para crear un clúster, crear una nueva agrupación de nodos trabajadores o añadir la subred a una agrupación de nodos trabajadores existente. No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.
Creación de subredes de VPC para el acceso clásico
Si habilita el acceso clásico al crear la VPC, los prefijos de dirección predeterminados de acceso clásico determinan automáticamente los rangos de IP de las subredes que cree. Sin embargo, los rangos de IP predeterminados para las subredes de VPC de acceso clásico entran en conflicto con las subredes para el plano de control de IBM Cloud Kubernetes Service. En su lugar, debe crear la VPC sin los prefijos de dirección predeterminados automáticos y luego crear sus propios prefijos de dirección. A continuación, siempre que cree subredes para el clúster, cree las subredes dentro de los rangos de prefijos de dirección que ha creado.
Creación de subredes de VPC para el acceso clásico en la consola
- Cree una VPC de acceso clásico sin prefijos de dirección predeterminados.
- En el panel de control Nubes privadas virtuales, pulse Crear.
- Especifique detalles para el nombre, el grupo de recursos y las etiquetas.
- Marque el recuadro de selección para Habilitar acceso a recursos clásicos y desmarque el recuadro de selección Crear un prefijo predeterminado para cada zona.
- Seleccione la región para la VPC.
- Pulse Crear nube privada virtual.
- Cree prefijos de dirección en cada zona.
- Pulse el nombre de su VPC para ver sus detalles.
- Pulse el separador Prefijos de dirección y pulse Crear.
- Para cada zona en la que tiene previsto crear subredes, cree uno o varios prefijos de direcciones. Los prefijos de dirección deben estar dentro de uno de los siguientes rangos:
10.0.0.0 - 10.255.255.255
,172.17.0.0 - 172.17.255.255
,172.21.0.0 - 172.31.255.255
,192.168.0.0 - 192.168.255.255
.
- Cree subredes que utilicen los prefijos de dirección.
- En el panel de control de la subred de VPC, pulse Crear.
- Especifique un nombre para la subred y seleccione el nombre de la VPC de acceso clásico.
- Seleccione la ubicación y la zona en las que desea crear la subred.
- Seleccione el prefijo de dirección que ha creado para esta zona.
- Especifique el número de direcciones IP que se deben crear. Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
- Elija si desea conectar una pasarela de red pública a la subred. Se necesita una pasarela de red pública cuando se desea que el clúster acceda a puntos finales públicos, como un URL público de otra app o un servicio de IBM Cloud que solo de soporte a los puntos finales de servicio en la nube público.
- Pulse Crear subred.
- Utilice las subredes para crear un clúster. No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.
Creación de subredes de VPC para el acceso clásico desde la CLI
- En la línea de mandatos, inicie una sesión en su cuenta de IBM Cloud y elija como destino la región y grupo de recursos de IBM Cloud donde desea crear el clúster de VPC. Para ver las regiones soportadas, consulte Creación de una VPC en otra región.
El grupo de recursos del clúster puede diferir del grupo de recursos de VPC. Escriba sus credenciales de IBM Cloud cuando se le solicite. Si dispone de un ID federado, utilice la opción
--sso
para conectarse.ibmcloud login -r <region> [-g <resource_group>] [--sso]
- Cree una VPC de acceso clásico sin prefijos de dirección predeterminados. En la salida, copie el ID de VPC.
ibmcloud is vpc-create <name> --classic-access --address-prefix-management manual
- Para cada zona en la que tiene previsto crear subredes, cree uno o varios prefijos de direcciones. Los prefijos de dirección deben estar dentro de uno de los siguientes rangos:
10.0.0.0 - 10.255.255.255
,172.17.0.0 - 172.17.255.255
,172.21.0.0 - 172.31.255.255
,192.168.0.0 - 192.168.255.255
.ibmcloud is vpc-address-prefix-create <prefix_name> <vpc_id> <zone> <prefix_range>
- Cree subredes en cada zona que utilicen los prefijos de dirección. Para obtener más información sobre las opciones de este mandato, revise la referencia de CLI.
Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP,
como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address> --ipv4-cidr-block <prefix_range>
- Opcional: conecte una pasarela de red pública a la subred. Se necesita una pasarela de red pública cuando se desea que el clúster acceda a puntos finales públicos, como un URL público de otra app o un servicio de IBM Cloud que solo de soporte
a los puntos finales de servicio en la nube público.
- Cree una pasarela pública en cada zona. Recuerde nombrar la pasarela pública con en el formato
<cluster>-<zone>-gateway
. En la salida, anote el ID de la pasarela pública.
Salida de ejemploibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
ID 26466378-6065-4716-a90b-ac7ed7917c63 Name mycluster-us-south-1-gateway Floating IP 169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63) Status pending Created 2019-09-20T16:27:32-05:00 Zone us-south-1 VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf) Resource group -
- Mediante los ID de la pasarela pública y la subred, conecte la pasarela pública a la subred.
Salida de ejemploibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
ID 91e946b4-7094-46d0-9223-5c2dea2e5023 Name mysubnet1 IPv4 CIDR 10.240.xx.xx/24 Address available 250 Address total 256 ACL allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906) Gateway mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63) Created 2019-08-21T09:43:11-05:00 Status available Zone us-south-1 VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
- Cree una pasarela pública en cada zona. Recuerde nombrar la pasarela pública con en el formato
- Utilice las subredes para crear un clúster. No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.
Restricción del tráfico de red pública a una subred con una pasarela pública
Mejore la seguridad de su clúster de IBM Cloud® Kubernetes Service permitiendo que menos nodos trabajadores tengan acceso externo a través de una pasarela pública de subred de VPC.
Si los pods de los nodos trabajadores tienen que conectarse a un punto final externo público, puede conectar una pasarela pública a la subred en la que están esos nodos trabajadores. Por ejemplo, el clúster de VPC se puede conectar automáticamente a otros servicios de IBM Cloud que den soporte a puntos finales de servicio en la nube privado, como por ejemplo IBM Cloud Container Registry. Sin embargo, si necesita acceder a los servicios de IBM Cloud que solo dan soporte a puntos finales de servicio en la nube público, puede conectar una pasarela pública a la subred para que sus pods puedan enviar solicitudes a través de la red pública.
Puede aislar este tráfico de red en el clúster conectando una pasarela pública a una sola subred en el clúster. Luego puede utilizar la afinidad de app para desplegar pods de app que requieren acceso a puntos finales externos solo en la subred con una pasarela pública conectada.
En los clústeres VPC, una subred se limita a una zona. Cuando se conecta una pasarela pública solo a una subred y se planifican los pods de app que requieren acceso público solo a los nodos trabajadores de dicha subred, estos pods están aislados en una sola zona del clúster.
-
Especifique como destino la región de la VPC en la que se ha desplegado el clúster.
ibmcloud target -r <region>
-
Compruebe si tiene una pasarela pública en una zona en la que tiene nodos trabajadores. Dentro de una VPC, solo puede crear una pasarela pública por zona, pero dicha pasarela pública se puede conectar a varias subredes dentro de la zona.
ibmcloud is public-gateways
Salida de ejemplo
ID Name VPC Zone Floating IP Created Status Resource group 26426426-6065-4716-a90b-ac7ed7917c63 test-pgw testvpc(36c8f522-.) us-south-1 169.xx.xxx.xxx(26466378-.) 2019-09-20T16:27:32-05:00 available - 2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374 team3(ff537d43-.) us-south-2 169.xx.xxx.xxx(2ba9a280-.) 2019-08-02T10:30:29-05:00 available -
-
Si ya tiene una pasarela pública en una zona en la que tiene nodos trabajadores y en la VPC en la que se encuentra el clúster, anote el ID de la pasarela.
-
Si no tiene una pasarela pública en una zona en la que tenga trabajadores y en la VPC en la que está el clúster, cree una pasarela pública. Recuerde nombrar la pasarela pública con en el formato
<cluster>-<zone>-gateway
. En la salida, anote el ID de la pasarela pública.ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
Salida de ejemplo
ID 26466378-6065-4716-a90b-ac7ed7917c63 Name mycluster-us-south-1-gateway Floating IP 169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63) Status pending Created 2019-09-20T16:27:32-05:00 Zone us-south-1 VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf) Resource group -
-
-
Obtenga una lista de los nodos trabajadores del clúster. Para la zona en la que ha habilitado la pasarela pública, anote la IP principal (Primary IP) de un nodo trabajador.
ibmcloud ks worker ls -c <cluster_name_or_ID>
Salida de ejemplo
ID Primary IP Flavor State Status Zone Version kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac 10.240.02.00 c2.2x4 normal Ready us-south-2 1.32.5 kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623 10.240.01.00 c2.2x4 normal Ready us-south-1 1.32.5
-
Describa el nodo trabajador. En la información de salida de Labels, anote el ID de subred de la etiqueta
ibm-cloud.kubernetes.io/subnet-id
,5f5787a4-f560-471b-b6ce-20067ac93439
en el siguiente ejemplo.kubectl describe node <worker_primary_ip>
Salida de ejemplo
NAME: 10.240.01.00 Roles: <none> Labels: arch=amd64 beta.kubernetes.io/arch=amd64 beta.kubernetes.io/instance-type=c2.2x4 beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=us-south failure-domain.beta.kubernetes.io/zone=us-south-1 ibm-cloud.kubernetes.io/ha-worker=true ibm-cloud.kubernetes.io/iaas-provider=gc ibm-cloud.kubernetes.io/internal-ip=10.240.0.77 ibm-cloud.kubernetes.io/machine-type=c2.2x4 ibm-cloud.kubernetes.io/os=UBUNTU_20_64 ibm-cloud.kubernetes.io/region=us-south ibm-cloud.kubernetes.io/sgx-enabled=false ibm-cloud.kubernetes.io/subnet-id=5f5787a4-f560-471b-b6ce-20067ac93439 ibm-cloud.kubernetes.io/worker-id=kube-bl25g33d0if1cmfn0p8g-vpcprod-default-00001093 ibm-cloud.kubernetes.io/worker-pool-id=bl25g33d0if1cmfn0p8g-5aa474f ibm-cloud.kubernetes.io/worker-pool-name=default ibm-cloud.kubernetes.io/worker-version=1.15.3_1517 ibm-cloud.kubernetes.io/zone=us-south-1 kubernetes.io/arch=amd64 kubernetes.io/hostname=10.240.0.77 kubernetes.io/os=linux Annotations: node.alpha.kubernetes.io/ttl: 0 ...
-
Mediante los ID de la pasarela pública y la subred, conecte la pasarela pública a la subred. Los nodos trabajadores que se despliegan en esta subred en esta zona ahora tienen acceso a puntos finales externos.
ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
Salida de ejemplo
ID 91e946b4-7094-46d0-9223-5c2dea2e5023 Name mysubnet1 IPv4 CIDR 10.240.xx.xx/24 Address available 250 Address total 256 ACL allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906) Gateway mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63) Created 2019-08-21T09:43:11-05:00 Status available Zone us-south-1 VPC myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
-
En el archivo de despliegue de su aplicación, añada una regla de afinidad para la etiqueta de ID de subred que encontró en el paso 4.
En la sección affinity de este YAML de ejemplo,
ibm-cloud.kubernetes.io/subnet-id
es el valor dekey
y<subnet_ID>
es el valor devalue
.apiVersion: apps/v1 kind: Deployment metadata: name: with-node-affinity spec: template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: ibm-cloud.kubernetes.io/subnet-id operator: In values: - <subnet_ID> ...
-
Aplique el archivo de configuración de despliegue actualizado.
kubectl apply -f with-node-affinity.yaml
-
Verifique que los pods de la app se han desplegado en los nodos trabajadores correctos.
-
Obtenga una lista de pods en el clúster. En la salida, identifique un pod para su app. Anote la dirección IP privada de NODE del nodo trabajador en el que está el pod.
kubectl get pods -o wide
En esta salida de ejemplo, el pod de app
cf-py-d7b7d94db-vp8pq
se encuentra en un nodo trabajador con la dirección IP10.240.01.00
.NAME READY STATUS RESTARTS AGE IP NODE cf-py-d7b7d94db-vp8pq 1/1 Running 0 15d 172.30.xxx.xxx 10.240.01.00
-
Obtenga una lista de los nodos trabajadores del clúster. En la salida, busque los nodos trabajadores en la zona en la que ha conectado la pasarela pública. Verifique que el nodo trabajadores con la dirección IP privada que ha identificado en el paso anterior se ha desplegado en esta zona.
ibmcloud ks worker ls --cluster <cluster_name_or_ID>
Salida de ejemplo
ID Primary IP Flavor State Status Zone Version kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac 10.240.02.00 c2.2x4 normal Ready us-south-2 1.32.5 kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623 10.240.01.00 c2.2x4 normal Ready us-south-1 1.32.5
-
-
Opcional: si utiliza listas de control de accesos (ACL) para controlar el tráfico de red del clúster, cree reglas de entrada y de salida en la ACL de esta subred para permitir la entrada y salida de los puntos finales públicos externos a los que deben acceder sus pods.