Mejores prácticas de redes

Mejores prácticas: cree compartimentos independientes para cada equipo

Le recomendamos que cree un compartimento independiente para cada equipo si espera que varios equipos creen clusters.

Por ejemplo, los recursos de red como la red virtual en la nube (VCN) y las subredes utilizadas para el motor de Kubernetes pueden residir en el compartimento raíz. Sin embargo, si espera que varios equipos creen clusters, recomendamos que cree un compartimento independiente para los recursos de cluster de cada equipo (por ejemplo, como compartimentos secundarios del compartimento raíz). La razón es que, dado que un cluster y sus recursos no tienen que estar en el mismo compartimento que la VCN y las subredes, tener compartimentos separados para cada equipo facilita y hace más limpio separar los clusters y mantenerlos seguros.

Consulte Configuración de recursos de red para despliegue y creación de clusters.

Mejores prácticas: ajuste del tamaño de la VCN según corresponda

Recomendamos permitir posibles futuros requisitos de ampliación de pools de nodos y clusters al cambiar el tamaño de la VCN en la que desea crear y desplegar clusters de Kubernetes.

La VCN debe tener un bloque CIDR lo suficientemente grande como para asignar direcciones de red a todos los recursos que necesita un cluster (subredes, punto final de API de Kubernetes, nodos de trabajador, pods, equilibradores de carga).

Consulte Configuración de VCN y Bloques IPv4 CIDR y Kubernetes Engine (OKE).

Mejores prácticas: Seleccione el plugin CNI de red de pod que mejor se adapte a sus necesidades

Le recomendamos que considere cuidadosamente los requisitos de red de pod y, a continuación, seleccione el plugin CNI de red de pod que mejor se adapte a sus necesidades.

Por ejemplo:

• Si las aplicaciones requieren el uso de requisitos de red base (y no el uso de direcciones IP de la VCN) o requieren una alta densidad de pods por nodo de trabajador, se recomienda utilizar el plugin CNI de franela.
• Si las aplicaciones necesitan que los pods tengan una dirección IP del CIDR de la VCN y/o que requieran el rendimiento de red consistente que ofrecen las máquinas virtuales (independientemente de los nodos en los que se estén ejecutando los pods) sin superposición adicional, recomendamos utilizar el plugin CNI de redes de pod nativo de VCN de OCI.

Consulte Redes de pod y Bloques de IPv4 CIDR y Kubernetes Engine (OKE).

Mejores prácticas: configure externalTrafficPolicy correctamente al exponer aplicaciones

Recomendamos que considere detenidamente el valor más adecuado para el valor externalTrafficPolicy al aprovisionar un equilibrador de carga de red para un servicio de Kubernetes de tipo LoadBalancer:

• externalTrafficPolicy: Cluster (modo de cluster)

  Especifique el modo de cluster si siempre desea enrutar el tráfico a todos los pods que ejecutan un servicio con la misma distribución y no desea conservar las direcciones IP de cliente. En el modo de cluster, Kubernetes reenvía cualquier tráfico enviado a cualquier nodo de trabajador en un puerto determinado a uno de los pods de ese servicio.

  El modo de cluster suele provocar una menor rotación de backends en el cluster porque el enrutamiento de solicitudes no depende del estado de los pods del cluster. Cualquier solicitud se puede enviar a cualquier nodo y Kubernetes gestiona la obtención de la solicitud en el lugar correcto. El modo de cluster hace que la carga se distribuya correctamente desde el equilibrador de carga de red en los nodos de trabajador. Cuando el tráfico llega a un nodo de trabajador, el nodo lo maneja de la misma manera. El equilibrador de carga no sabe qué nodos del cluster están ejecutando pods para su servicio. Si ha seleccionado una subred regional para los nodos de trabajador, la carga se distribuye en todos los nodos de todos los dominios de disponibilidad de la región de la subred. En el modo de cluster, el tráfico se equilibra con la carga en todos los nodos del cluster, incluso en los nodos que no ejecutan un pod relevante.

• externalTrafficPolicy: Local (modo local)

  Especifique el modo local si desea que las solicitudes terminen en las direcciones IP de cliente especificadas en los encabezados de paquetes IP. Solo tiene la opción de conservar las direcciones IP de cliente cuando las solicitudes se terminan en las direcciones IP de cliente especificadas en los encabezados de paquetes IP. Es decir, cuando el valor externalTrafficPolicy se define en Local.

  El modo local elimina el salto de red adicional necesario en el modo de cluster, pero el tráfico de red puede llegar a estar desequilibrado si la red no está configurada correctamente. En el modo local, el tráfico de entrada se debe enviar a los nodos que ejecutan los pods correspondientes para ese servicio. De lo contrario, se borrará el tráfico. Como resultado, algunos pods de aplicaciones pueden recibir más tráfico que otros pods.

Para obtener más información, consulte Terminating Requests at the Receiving Node y Preserving The Client IP Address.

Mejores prácticas: evitar la superposición de bloques CIDR de servicio y pod con un bloque CIDR local y al utilizar el plugin CNI de canal

Recomendamos que evite la situación en la que el bloque CIDR utilizado por la red de superposición de canal para aprovisionar pods y servicios con direcciones IP se solapa con un bloque CIDR utilizado para aprovisionar instancias informáticas externas con direcciones IP.

Los clusters de Kubernetes necesitan una dirección IP única para cada pod. Por lo tanto, es necesaria la planificación de direcciones IP porque las direcciones no se pueden superponer con el espacio de direcciones IP privadas utilizado localmente o en otras redes virtuales en la nube conectadas.

Al utilizar el plugin CNI de canal, la comunicación entre pods en un cluster se encapsula en la red de superposición de canal. La red de superposición de canal utiliza su propio bloque CIDR para aprovisionar pods y nodos de trabajador con direcciones IP. Solo se puede acceder a los pods de la red de superposición de canal desde otros pods del mismo cluster. Las instancias informáticas externas al cluster no pueden acceder a los pods directamente. Si un pod intenta acceder a una instancia informática externa que tiene la misma dirección IP que otro pod del cluster, la solicitud se enrutará de forma incorrecta y se producirán problemas.

Consulte Uso del plugin flannel CNI para redes de pod.

Mejores prácticas: uso de subredes regionales y distribución de cargas de trabajo para alta disponibilidad

Le recomendamos que seleccione subredes regionales para nodos de trabajador a fin de garantizar una alta disponibilidad y distribuir cargas de trabajo entre ellos.

La VCN debe tener un número adecuado de subredes definidas para nodos de trabajo, equilibradores de carga y punto final de API de Kubernetes. El uso de subredes regionales y la distribución de cargas de trabajo entre ellas garantizan una alta disponibilidad y simplifican la implantación del failover en los dominios de disponibilidad.

Consulte Configuración de subred.

Mejores prácticas: utilice restricciones de distribución de topología para controlar cómo se distribuyen los pods

Recomendamos utilizar restricciones de distribución de topología de pod para controlar cómo se distribuyen los pods entre los dominios de disponibilidad y los nodos de trabajador.

Por ejemplo, cuando hay muchos nodos de trabajador disponibles pero solo se necesitan dos o tres pods, normalmente no desea que todos los pods se ejecuten en el mismo nodo de trabajador para evitar el riesgo de un único punto de fallo si hay un problema.

Sin embargo, a medida que se necesitan más y más pods para los clientes en varios dominios de disponibilidad, lo habitual es que desee distribuir los pods de forma uniforme entre varios nodos de trabajador en esos distintos dominios de disponibilidad. En este escenario, distribuir los pods para reducir la latencia y los costos de red asociados al envío de tráfico de red entre dominios de disponibilidad es tan preocupante como evitar un único punto de fallo. Es posible que prefiera tener un número similar de pods en cada dominio de disponibilidad y que el cluster se cure automáticamente si hay algún problema.

El uso de restricciones de propagación de topología de pod permite configurar un cluster para cumplir los objetivos gemelos de alta disponibilidad y uso eficiente de los recursos.

Consulte Restricciones de propagación de topología de pod en la documentación de Kubernetes.

Mejores prácticas: Planificar el número de nodos

Le recomendamos que tenga un plan para el número de nodos de un cluster que tenga en cuenta el tamaño del nodo, el perfil de aplicación de los pods y el plugin CNI de red de pod seleccionado.

Al utilizar el plugin CNI de canal, los clusters creados por Kubernetes Engine reservan un rango de /25 para pods de la red de superposición de canal y permiten hasta 110 pods por nodo. Al utilizar el plugin CNI de red de pod nativo de VCN de OCI, el mismo nodo puede tener un rango diferente según la unidad seleccionada para los nodos de trabajador. Según el tamaño de los nodos y el perfil de aplicación de los pods, decida por adelantado el número de nodos que desea en el cluster.

Consulte Redes de pod.

Mejores prácticas: uso de subredes y reglas de seguridad independientes

Recomendamos que utilice subredes y reglas de seguridad independientes al configurar recursos de red.

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 utiliza el plugin CNI de red de pod nativo de VCN de OCI)
• 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.

Consulte Configuración de subred.

Mejores prácticas: uso de subredes independientes para equilibradores de carga

Le recomendamos que cree subredes independientes para que los equilibradores de carga expongan los servicios.

Si no crea una subred de equilibrador de carga independiente, los servicios se exponen mediante una dirección IP de la subred del nodo de trabajador. Como resultado, es posible que el espacio asignado en la subred del nodo de trabajador se agote por completo antes de lo previsto, lo que podría impedir que el cluster se escale al número de nodos especificado.

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.

Consulte Load Balancer Subnet Configuration.

Mejores prácticas: uso de una subred de nodo de trabajador privada para una máxima seguridad

Le recomendamos que especifique una subred privada como subred de nodo de trabajador para garantizar la máxima seguridad.

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). 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.

Consulte Configuración de subred de nodo de trabajador.

Mejores prácticas: migre clusters para que sean nativos de VCN a fin de integrar el punto final de API de Kubernetes en su VCN

Le recomendamos que migre clusters que aún no sean nativos de VCN para que sean nativos de VCN.

En un cluster nativo de VCN, los nodos de trabajador, los equilibradores de carga y el punto final de API de Kubernetes están totalmente integrados en su propia VCN, y puede configurarlos como públicos o privados. Puede controlar el acceso a la subred de punto final de API de Kubernetes mediante reglas de seguridad definidas para grupos de seguridad de red (recomendado) o listas de seguridad.

Para aprovechar el control de seguridad que ofrecen los clusters nativos de VCN, migre un cluster que aún no sea nativo de VCN para integrar su punto final de API de Kubernetes en su propia VCN.

Consulte Migración a clusters nativo de VCN.

Mejores prácticas: cree un valor ConfigMap para sustituir el comportamiento CoreDNS por defecto

Le recomendamos que, si desea personalizar el comportamiento por defecto de CoreDNS, cree y aplique su propio ConfigMap para sustituir la configuración del archivo principal CoreDNS.

Tenga en cuenta que si personaliza el comportamiento CoreDNS por defecto, las personalizaciones se suprimen periódicamente durante las actualizaciones internas del cluster.

Consulte Configurar servidores DNS para clusters de Kubernetes.

Mejores prácticas: utilice sondas de preparación y de vida para las comprobaciones del sistema

Recomendamos que utilice sondeos de disponibilidad y de actividad de Kubernetes para comprobar el estado de los contenedores de un cluster y que personalice los sondeos para que cumplan sus requisitos.

Gestionar sistemas grandes y distribuidos puede ser complicado, especialmente cuando algo sale mal. Las comprobaciones del sistema de Kubernetes son una forma sencilla de asegurarse de que las instancias de aplicación funcionan. La creación de comprobaciones del sistema personalizadas permite adaptar las comprobaciones del sistema a su entorno.

En particular, le recomendamos encarecidamente que considere utilizar sondas de preparación y de estado para confirmar que los contenedores se están ejecutando y funcionando correctamente antes de hacerlos candidatos para recibir tráfico de un servicio. Los parámetros de sondeo y sondeo específicos que se utilizarán dependerán de la carga de trabajo. Establezca un equilibrio entre hacer que la sonda sea demasiado agresiva y demasiado lenta, y ajustar los parámetros para satisfacer las necesidades de la aplicación.

Consulte Configuración de sondeos de actividad, preparación y puesta en marcha en la documentación de Kubernetes.

Mejores prácticas: uso de las métricas del equilibrador de carga y del equilibrador de carga de red para supervisar los backends

Recomendamos que utilice métricas para supervisar el estado del equilibrador de carga de OCI o del equilibrador de carga de red aprovisionado para un servicio de Kubernetes de tipo LoadBalancer.

También le recomendamos que configure alarmas para que le avisen si la disponibilidad del backend está por debajo de un umbral de su elección. Por ejemplo:

• Utilice la métrica UnhealthyBackendServers del equilibrador de carga para configurar una alarma para que le avise si el número de servidores backend en mal estado de un juego de backends supera cero.
• Utilice la métrica BackendTimeouts del equilibrador de carga para configurar una alarma para que le avise si el número de timeouts en todos los servidores backend supera cero.
• Utilice la métrica HealthyBackends del equilibrador de carga de red para configurar una alarma que le avise si el número de backends que Oracle considera correctos está por debajo de uno.
• Utilice la métrica UnhealthyBackends del equilibrador de carga de red para configurar una alarma que le avise si el número de backends que Oracle considera en mal estado aumenta por encima de cero.

Consulte Métricas del equilibrador de carga, Métricas del equilibrador de carga de red y Creación de una alarma.

Mejores prácticas: utilice etiquetas de nodo para incluir un subjuego de nodos de trabajador en un juego de backends

Recomendamos que utilice la anotación node-label-selector para incluir en el juego de backends de un determinado equilibrador de carga o equilibrador de carga de red solo ese subjuego de nodos de trabajador que tengan los pods de aplicación necesarios. La inclusión de subjuegos de nodos de trabajador de un cluster en los juegos de backends de diferentes equilibradores de carga y equilibradores de carga de red permite presentar un único cluster de Kubernetes como varios clusters lógicos (servicios).

Una vez asociada una etiqueta Kubenetes a los nodos de trabajador que desea incluir en el juego de backends de un equilibrador de carga o equilibrador de carga de red, especifique esa etiqueta en el manifiesto del servicio de tipo LoadBalancer:

• para un equilibrador de carga, utilice la anotación oci.oraclecloud.com/node-label-selector:
• para un equilibrador de carga de red, utilice la anotación oci-network-load-balancer.oraclecloud.com/node-label-selector:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/node-label-selector: lbset=ServiceA
spec:
  type: LoadBalancer
...

apiVersion: v1
kind: Pod
...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: lbset
            operator: In
            values:
            - ServiceA
...

Consulte Selección de nodos de trabajador para incluir en juegos de backends.

Mejores prácticas: Instale Calico antes de crear pools de nodos

Recomendamos que si desea utilizar Calico para mejorar la seguridad del cluster, instale Calico en un cluster antes de crear cualquier pool de nodos.

Puede mejorar la seguridad del cluster mediante la implantación de políticas de red de Kubernetes. Para implantar políticas de red de Kubernetes, debe instalar y configurar un proveedor de red que soporte los recursos NetworkPolicy. Uno de esos proveedores es Calico.

Si instala Calico en un cluster que tiene pools de nodos existentes en los que los pods ya se están ejecutando, tendrá que volver a crear los pods cuando finalice la instalación de Calico. Por ejemplo, ejecutando el comando kubectl rollout restart. Si instala Calico en un cluster antes de crear pools de nodos en el cluster (como se recomienda), se asegurará de que no tendrá que volver a crear ningún pod.

Consulte Ejemplo: instalación de Calico y configuración de políticas de red.