Definición de subredes personalizadas al crear la ubicación

Durante la creación de la ubicación

Al crear la ubicación en la CLI, puede definir los parámetros siguientes para personalizar la red en la ubicación. Para obtener más información, consulte la referencia de mandatos ibmcloud sat location create.

Puede especificar la opción --pod-subnet para especificar un CIDR de subred personalizado para proporcionar direcciones IP privadas para pods. Esta opción solo se puede utilizar si también se habilita Red Hat CoreOS con el indicador --coreos-enabled. La subred debe tener un tamaño mínimo de o /23 superior. El valor predeterminado es 172.16.0.0/16.

También puede especificar la opción --service-subnet para especificar un CIDR de subred personalizado para proporcionar direcciones IP privadas para los servicios. Esta opción solo se puede utilizar si también se habilita Red Hat CoreOS con el indicador --coreos-enabled. La subred debe tener un tamaño mínimo de o /24 superior. El valor predeterminado es 172.20.0.0/16.

Definición de la interfaz de red de pod al crear la ubicación

Durante la creación de la ubicación

Al crear la ubicación en la CLI, puede definir --pod-network-interface para establecer la interfaz de red de pod. Los métodos disponibles son can-reach y interface.

• Para proporcionar una dirección URL o IP directa, especifique can-reach=<url> o can-reach=<ip_address>. Si la interfaz de red puede alcanzar la dirección URL o IP proporcionada, se utiliza esta opción. Por ejemplo, utilice can-reach=www.exampleurl.com para especificar un URL y can-reach=172.19.0.0 para especificar una dirección IP.
• Para elegir una interfaz con una serie Regex, especifique interface=<regex_string>; por ejemplo, interface=eth.*.

Para obtener más información, consulte la referencia de mandatos ibmcloud sat location create.

Definición de la interfaz de red de pod al crear el clúster

Durante la creación del clúster

Cuando crea el clúster en la CLI, puede definir --pod-network-interface para establecer la interfaz de red de pod. Los métodos disponibles son can-reach y interface.

• Para proporcionar una dirección URL o IP directa, especifique can-reach=<url> o can-reach=<ip_address>. Si la interfaz de red puede alcanzar la dirección URL o IP proporcionada, se utiliza esta opción. Por ejemplo, utilice can-reach=www.exampleurl.com para especificar un URL y can-reach=172.19.0.0 para especificar una dirección IP.
• Para elegir una interfaz con una serie Regex, especifique interface=<regex_string>; por ejemplo, interface=eth.*.

Para obtener más información, consulte la referencia de mandatos ibmcloud oc cluster create satellite.

Limitación del acceso al clúster de Satellite

Tras la localización y la creación del clúster

Después de crear la ubicación y el clúster, puede utilizar el mandato ibmcloud ks cluster master satellite-service-endpoint allowlist add para añadir una subred a una lista de elementos permitidos de puntos finales de servicio del clúster Satellite. Las solicitudes autorizadas dirigidas al maestro del clúster que se originan en la subred se permiten a través del punto final del servicio Satellite. La lista de elementos permitidos debe estar habilitada para que se apliquen las restricciones.

Creación de políticas de red utilizando puntos finales de host de Calico

Tras la localización y la creación del clúster

Si crea un clúster de Satellite en la versión 4.12 y posteriores, hay instancias de Calico Hostendpoint que se despliegan en el clúster para cada interfaz de red del nodo trabajador.

Puede utilizar estas instancias de Hostendpoint para definir políticas de red globales con la ayuda de la etiqueta “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” que se añade a cada instancia de Hostendpoint.

Además de esta etiqueta, se añaden todas las etiquetas del nodo trabajador para opciones de personalización adicionales.

Estos Hostendpoints tienen el perfil “projectcalico-default-allow", lo que significa que estos Hostendpoints podrían cambiar el comportamiento esperado anteriormente cuando se actualice a 4.12.

Antes de actualizar a 4.12, asegúrese de que todas las reglas de red esperadas anteriormente, las políticas, Hostendpoints funcionan igual también después de la actualización.

Para obtener más información, consulte la documentación deCalico.

Restricción del acceso al servicio NodePort

Tras la localización y la creación del clúster

De forma predeterminada, los servicios NodePort son accesibles en todas las interfaces de red que están disponibles para el clúster, por ejemplo, 0.0.0.0.

Sin embargo, en las ubicaciones de Satellite donde hay varias redes disponibles para los hosts, puede limitar las interfaces de red disponibles para los servicios.

Para limitar el rango, restrinja las direcciones de escucha para los servicios NodePort a nivel de clúster. Esta restricción permite al administrador del clúster limitar el acceso a una interfaz de red específica utilizando la subred IP como rango de direcciones de escucha permitido. Realice los pasos siguientes para volver a configurar el componente kube-proxy para limitar el rango de direcciones de escucha para los servicios de NodePort.

La configuración incorrecta del node-port-addresses podría aislar los servicios de orígenes válidos. Asegúrese de planificar todas las subredes que necesita su servicio. IBM Cloud no requiere acceso a ninguna subred para gestionar sus clústeres.

1. Acceda al clúster de Red Hat OpenShift.

2. Prepare la lista de CIDR de subred de origen planificada que desea permitir para acceder a los servicios NodePort.

3. Ejecute el mandato siguiente para obtener la configuración de network.operator.openshift.io y guardar una copia en caso de que necesite revertir los cambios.

   kubectl get network.operator.openshift.io cluster -o yaml
   

4. Edite la configuración de network.operator.openshift.io y establezca la lista de subredes en la sección spec e incluya las subredes necesarias para el servicio NodePort.

   spec:
     kubeProxyConfig:
       proxyArguments:
         node-port-addresses:
         - 192.0.2.0/24
         - 198.51.100.0/24
   

5. Guarde los cambios y aplíquelos al clúster.

   oc apply -f updated-network-config.yaml
   

6. Para la versión de clúster 4.10.x y anteriores, establezca el estado de gestión del operador de red de clúster en Unmanaged.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Unmanaged"}}'
   

7. Reinicia el servicio DaemonSetkube-proxy para aplicar los cambios. Esta operación no causa interrupciones.

   oc rollout restart ds -n openshift-kube-proxy openshift-kube-proxy
   

8. Espere a que se reinicien todos los pods de kube-proxy. Comprueba el estado ejecutando el siguiente comando.

   oc get po -n openshift-kube-proxy --selector app=kube-proxy
   

9. Para la versión de clúster de 4.10.x y anteriores, restablezca el estado de gestión del operador de red de clúster a Managed. Tenga en cuenta que esta acción puede reiniciar los pods de proxy.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Managed"}}'
   

Una vez reiniciados todos los pods, el clúster se configura con las subredes restringidas. Puede repetir estos pasos para actualizar o eliminar la lista de subredes según sea necesario.

Puede restringir aún más el tráfico utilizando NetworkPolicies para cada servicio.