Mejores prácticas de OKE

Mejores prácticas de gestión de clusters

Cambio de versión de clusters

Mantenga los clusters actualizados para que siempre estén ejecutando versiones de Kubernetes que se muestran como soportadas actualmente por OKE. La visualización de un cluster indica si hay disponible una versión más reciente de Kubernetes para ese cluster. Consulte Versiones soportadas de Kubernetes y Actualización de un cluster de OKE.

Utilizar etiquetas de Kubernetes.

Utilice etiquetas de Kubernetes para organizar los distintos recursos de Kubernetes (como servicios, pods, contenedores y redes) que componen un cluster.

Las etiquetas de Kubernetes son pares clave-valor que ayudan a mantener estos recursos y a realizar un seguimiento de cómo interactúan entre sí en un cluster.

Utilice el etiquetado de recursos.

Utilice el etiquetado de recursos para organizar los distintos recursos (como nodos de trabajador, redes virtuales en la nube, equilibradores de carga y volúmenes en bloque) utilizados por los clusters de Kubernetes que cree con Kubernetes Engine.

Cuando un gran número de recursos se distribuye en varios compartimentos de un arrendamiento, puede resultar difícil realizar un seguimiento de los recursos que se utilizan para fines específicos. También puede ser difícil agregar los recursos, informar sobre ellos y realizar acciones masivas sobre ellos.

El etiquetado permite definir claves y valores, y asociar esas etiquetas a recursos. A continuación, puede utilizar las etiquetas para organizar y mostrar los recursos según las necesidades de su empresa.

Para obtener más información, consulte Etiquetado de recursos en Compute Cloud@Customer.

Defina límites y solicitudes de recursos.

• Defina solicitudes de recursos para especificar la cantidad mínima de recursos que puede utilizar un contenedor.

• Defina límites de recursos para especificar la cantidad máxima de recursos que puede utilizar un contenedor.

En ocasiones, una aplicación no se puede desplegar en un cluster de Kubernetes debido a la disponibilidad limitada de recursos en ese cluster. El fallo de despliegue de la aplicación se puede evitar definiendo correctamente las solicitudes de recursos y los límites de recursos.

Si no define las solicitudes y los límites de recursos, los pods de un cluster pueden empezar a utilizar más recursos de los necesarios. Si un pod empieza a consumir más CPU o memoria en un nodo, es posible que el programador de Kubernetes (kube-scheduler) no pueda colocar nuevos pods en el nodo e incluso que el nodo se bloquee.

Para obtener más información, consulte Resource Management for Pods and Containers en el sitio kubernetes.io.

Proporcione nodos dedicados mediante marcas y tolerancias.

Utilice tolerancias y marcas de Kubernetes para limitar las aplicaciones que utilizan muchos recursos a nodos de trabajador específicos.

El uso de marcas y tolerancias permite mantener los recursos de nodos disponibles para las cargas de trabajo que los necesitan y evita la programación de otras cargas de trabajo en los nodos.

Para obtener más información, consulte Taints and Tolerations en el sitio kubernetes.io.

Controle la programación de pod mediante selectores de nodos y afinidad.

Hay varios métodos diferentes disponibles para restringir la ejecución de un pod en nodos concretos o para especificar una preferencia para que un pod se ejecute en nodos concretos. Los enfoques recomendados utilizan selectores de etiquetas para especificar la selección de nodos.

A menudo, kube-scheduler realiza una colocación razonable cuando no se especifican restricciones y preferencias. Sin embargo, hay algunas circunstancias en las que puede que desee controlar el nodo en el que se ejecuta un pod. En estas situaciones, la mejor práctica es controlar la programación de pods en nodos mediante selectores de nodos de Kubernetes, afinidad de nodos y afinidad entre pods.

El uso de selectores de nodos, afinidad de nodos y afinidad entre pods permite que kube-scheduler aísle lógicamente las cargas de trabajo, como según el hardware del nodo.

Utilice herramientas de terceros para la copia de seguridad y la recuperación ante desastres.

Utilice herramientas de terceros como Velero con Kubernetes Engine para la copia de seguridad y la recuperación ante desastres.

Las capacidades combinadas de copia de seguridad y recuperación ante desastres de estas herramientas y Kubernetes Engine pueden proporcionar una plataforma de Kubernetes fiable, sólida y escalable lista para producción.

Mejores prácticas de redes

Cree compartimentos independientes para cada equipo.

Si espera que varios equipos creen clusters, cree un compartimento independiente para cada equipo.

Asigne el tamaño adecuado a la VCN.

Permite posibles requisitos futuros de escalado de clusters y pools de nodos al cambiar el tamaño de la VCN en la que desea crear y desplegar clusters de Kubernetes.

Asegúrese de que la VCN tenga 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.

Seleccione el plugin CNI de redes de pod que mejor se adapte a sus necesidades.

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.

• 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, la mejor práctica es utilizar el plugin CNI de superposición de franela. Consulte Creating Flannel Overlay Network Resources.

• Si las aplicaciones necesitan que los pods tengan una dirección IP del CIDR de la VCN, 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, la mejor práctica es utilizar el plugin CNI de red de pod nativo de la VCN de OCI. Consulte Creación de recursos de red de pod nativos de VCN.

Configure externalTrafficPolicy correctamente al exponer aplicaciones.

Considere cuidadosamente 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.

Evite la superposición de bloques CIDR de pod y servicio con un bloque CIDR local y al utilizar el plugin CNI de superposición de franela.

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

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

Planifique el número de nodos que necesitará.

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

Utilizar subredes y reglas de seguridad independientes.

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 y puede tener más:

• Una subred de punto final de API de Kubernetes

• Una subred de nodos de trabajador

• Una o dos subredes de equilibrador de carga regionales específicas de dominio de disponibilidad (opcional)

• Una subred de pods (cuando se utiliza el plugin de CNI de red de pods nativos de VCN de OCI)

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

Mejores prácticas de seguridad

Planificar el nivel de exposición.

Responda a las siguientes preguntas antes de implantar un plan de seguridad para los clusters que cree con Kubernetes Engine:

• ¿Cuánta exposición a Internet desea que tengan los clusters?

• ¿Cómo planea exponer cargas de trabajo internamente en su VCN y externamente a Internet?

• ¿Cómo planea escalar cargas de trabajo?

• ¿Qué tipos de servicios de Oracle consumirá el cluster?

Cree clusters privados.

Si el cluster no necesita acceso directo desde Internet, cree un cluster privado. En un cluster privado, al servidor de API de Kubernetes y a los nodos de trabajador se les asignan solo direcciones IP privadas.

Opcionalmente, utilice un gateway de NAT para el acceso a Internet saliente, un gateway de direccionamiento dinámico (DRG) para permitir el acceso desde la red local y un gateway de intercambio de tráfico local (LPG) para permitir el acceso desde otras redes virtuales en la nube.

Coloque todas las aplicaciones en subredes privadas.

Si las aplicaciones que se ejecutan en nodos de trabajador no necesitan acceso directo a Internet, tanto la subred de nodos de trabajador como la subred de equilibrador de carga de trabajador deben ser privadas.

Restrinja el tráfico del cluster mediante grupos de seguridad de red.

Defina reglas de seguridad en grupos de seguridad de red (NSG), en lugar de en listas de seguridad, para la VCN en la que desea crear y desplegar clusters. Consulte Controlling Traffic with Network Security Groups.

Mejores prácticas generales de seguridad.

• Aplique parches de seguridad con regularidad.

• Utilice una combinación de políticas de red de Kubernetes y NSG.

• Utilice los NSG junto con herramientas de infraestructura como código (como Terraform).

• Rotar secretos y certificados con regularidad.

• Ejecutar todas las aplicaciones como un usuario sin privilegios.

• Tratar los contenedores como inmutables.

Auditoría, registro y supervisión.

• Consulte los logs con regularidad.

• Activar log de auditoría.

• Utilice el registro basado en cluster de Kubernetes.

• Supervisar los componentes del cluster.

• Registre los metadatos del tráfico de red y analícelos con regularidad.

• Utilice imágenes de contenedor pequeñas y seguras.

• Limite la exposición de credenciales.

Mejores prácticas de almacenamiento

• Seleccione el tipo de almacenamiento adecuado.

• Cree y utilice clases de almacenamiento para definir las necesidades de la aplicación.

• Cree y utilice volúmenes para el almacenamiento persistente.

• Limite el consumo de recursos de almacenamiento.

• Proteja y realice una copia de seguridad de los datos.

Mejores prácticas de cambio de versión

• Utilice la última versión soportada de Kubernetes.

• Configurar entornos de prueba y producción.

• Cordón y nodos de drenaje en preparación para el mantenimiento.

• Tratar los nodos de trabajador como inmutables.