Creación de una estrategia de clúster de alta disponibilidad

Diseñe su clúster estándar de modo que obtenga la máxima disponibilidad y capacidad de su app con IBM Cloud® Kubernetes Service. Utiliza las funciones integradas para aumentar la alta disponibilidad de tu clúster y proteger tu aplicación frente a tiempos de inactividad cuando falle un componente del clúster. Pero averiguar cuál debe ser la configuración de su clúster para soportar su carga de trabajo no es una ciencia exacta. Es posible que tenga que probar diferentes configuraciones y adaptarlas.

La alta disponibilidad (HA) es una disciplina fundamental en una infraestructura de TI para mantener las apps en funcionamiento, incluso cuando se produce un error de sitio parcial o completo. El objetivo principal de la alta disponibilidad es eliminar posibles puntos de anomalía en una infraestructura de TI. Por ejemplo, puede prepararse por si falla un sistema añadiendo redundancia y estableciendo mecanismos de migración tras error. Consulte Cómo IBM Cloud garantiza la alta disponibilidad y recuperación tras desastre.

Para empezar a planificar y dimensionar su clúster, revise estos puntos de decisión antes de crear un clúster.

Decidir cuántos clusters crear

Si distribuye sus apps entre varios nodos trabajadores, zonas y clústeres, es menos probable que los usuarios experimenten un tiempo de inactividad del sistema. Características incorporadas como, por ejemplo, el aislamiento y el equilibrio de carga, incrementan la resiliencia con relación a posibles anomalías con hosts, redes o apps.

Alta disponibilidad para
disponibilidad para

El número de clústeres que cree dependerá de su carga de trabajo, de las políticas y normativas de la empresa, de los requisitos empresariales, de los acuerdos de nivel de servicio que tenga con sus clientes, de los recursos que desee gastar y de lo que quiera hacer con los recursos informáticos.

  • Clústeres múltiples: por lo general, los clústeres múltiples son más complejos de gestionar, pero pueden ayudarte a alcanzar objetivos importantes como los siguientes.

    • Cumplir con las políticas de seguridad que requieren aislar las cargas de trabajo.
    • Probar cómo se ejecuta la app en una versión distinta de Kubernetes u otro software de clúster como por ejemplo Calico.
    • Consiga un mayor rendimiento para usuarios de distintas zonas geográficas.
    • Simplifique el acceso de los usuarios para controlar el acceso dentro de un clúster configurando el acceso a nivel de instancia de clúster en lugar de personalizar y gestionar múltiples políticas RBAC a nivel de espacio de nombres.
    • Reducir el número de nodos trabajadores. El ancho de banda de red en máquinas virtuales escalables es de unos 1000 Mbps. Si necesitas cientos de nodos de trabajo en un clúster, puedes dividir la configuración en varios clústeres con menos nodos, o bien solicitar nodos bare metal.
    • Permitir un mayor número de integraciones de servicios, como más de 5.000 servicios.
    • Proporcionar mayor disponibilidad a una aplicación. Al igual que al utilizar tres zonas en clústeres multizona, puede proporcionar mayor disponibilidad a su aplicación configurando tres clústeres repartidos entre distintas zonas.
    • Reduce los costes adquiriendo máquinas más pequeñas para gestionar tu carga de trabajo.
  • Un clúster con más nodos trabajadores: Un menor número de clústeres puede ayudarte a reducir el esfuerzo operativo y los costes por clúster de los recursos fijos. En lugar de crear más clústeres, puede añadir grupos de trabajadores a un clúster para disponer de diferentes tipos de recursos informáticos para sus componentes de aplicaciones y servicios. Cuando desarrolla la app, los recursos que utiliza están en la misma zona, o bien estrechamente conectados en una multizona, de forma que puede hacer presunciones sobre latencia, ancho de banda o errores correlacionados. Sin embargo, resulta aún más importante que organices tu clúster utilizando espacios de nombres, cuotas de recursos y etiquetas cuando solo dispones de un clúster.

Determinar cuántas ubicaciones se necesitan

Un clúster puede distribuir réplicas entre nodos trabajadores en una única ubicación o en varias ubicaciones. Esta elección puede influir en los tipos de clúster disponibles en la siguiente sección.

La distribución de la carga de trabajo entre tres zonas garantiza una alta disponibilidad para la app en el caso de que una de las zonas deje de estar disponible. Debe tener los nodos trabajadores distribuidos uniformemente entre las tres zonas de disponibilidad para cumplir el acuerdo de nivel de servicio (SLA) de IBM Cloud para la configuración de alta disponibilidad.

Los errores de zona afectan a todos los hosts de cálculo físico y al almacenamiento NFS. Los errores pueden ser interrupciones de alimentación, refrigeración, red o almacenamiento, y desastres naturales, como inundaciones, terremotos y huracanes. Para protegerse contra un fallo de zona, debe tener clústeres en dos zonas diferentes cuya carga esté equilibrada por un equilibrador de carga externo, crear un clúster en una ubicación multizona, que distribuya el maestro por las zonas, o plantearse la posibilidad de crear un segundo clúster en otra zona.

Clústeres multizona

Clásico VPC

Los clústeres multizona distribuyen las cargas de trabajo entre varios nodos de trabajo y zonas, creando una protección adicional contra los fallos de zona. Los nodos de trabajo se despliegan automáticamente con tres réplicas repartidas por varias zonas. Si una zona entera experimenta una interrupción, su carga de trabajo se programa en nodos de trabajo de las otras zonas, protegiendo su aplicación de la interrupción.

Cada región está configurada con un equilibrador de carga de alta disponibilidad al que se puede acceder desde el punto final de la API específico de la región. El equilibrador de carga direcciona solicitudes de entrada y salida a los clústeres en las zonas regionales. La probabilidad de que se produzca un error global de región es baja. Sin embargo, para estar preparado ante este error, puede configurar varios clústeres en diferentes regiones y conectarlos mediante un equilibrador de carga externo. Si una región entera deja de funcionar, el clúster de la otra región puede hacerse cargo de la carga de trabajo.

Por ejemplo, despliega su clúster multizona en una región metropolitana, como sydney, y tres réplicas se reparten automáticamente por las tres zonas de la metropolitana, como au-syd-1, au-syd-2 y au-syd-3. Si caen los recursos de una zona, las cargas de trabajo del clúster siguen ejecutándose en las otras zonas.

Un clúster de varias regiones requiere varios recursos de nube y, en función de la app, puede ser complejo y costoso. Compruebe si necesita una configuración de varias regiones o si podría tolerar una interrupción potencial del servicio. Si desea configurar un clúster de varias regiones, asegúrese de que la app y los datos se pueden alojar en otra región, y que la app admite la réplica de datos globales.

Varios clústeres conectados con equilibradores de carga

Clásico VPC

Para proteger su aplicación de un fallo maestro, puede crear varios clústeres en diferentes zonas dentro de una región y conectarlos con un equilibrador de carga global. Esta opción es útil si debe aprovisionar un clúster en un centro de datos clásico con una sola zona, pero desea seguir disfrutando de las ventajas de la disponibilidad multizona.

Para conectar varios clústeres con un equilibrador de carga global, los clústeres deben estar configurados con conectividad de red pública y tus apps deben estar expuestas a través de Ingress, routes, o con un Kubernetes.

Para equilibrar la carga de trabajo en varios clústeres, debe configurar un equilibrador de carga global a través de Cloud Internet Services (CIS) y añadir las direcciones IP públicas de sus ALB o servicios de equilibrador de carga a su dominio. Al añadir estas direcciones IP, puede direccionar el tráfico de entrada entre los clústeres.

Para que el equilibrador de carga global detecte si uno de los clústeres deja de estar disponible, tenga en cuenta la posibilidad de añadir una comprobación de estado basada en ping a cada dirección IP. Cuando se configura esta comprobación, el proveedor de DNS ejecuta ping de forma regular sobre las direcciones IP que ha añadido a su dominio. Si una dirección IP deja de estar disponible, el tráfico ya no se envía a esta dirección IP. Sin embargo, Kubernetes no reinicia automáticamente los pods del clúster no disponible en los nodos trabajadores de los clústeres disponibles. Si desea que Kubernetes reinicie automáticamente los pods en los clústeres disponibles, considere la posibilidad de configurar un clúster multizona.

Clústeres de una sola zona

Clásico

Los nodos de trabajo se distribuyen en distintos hosts físicos dentro de una misma zona. Esta opción protege contra ciertas interrupciones, como durante una actualización maestra, y es más sencilla de gestionar. Sin embargo, no protege tus aplicaciones si toda una zona sufre un corte. Si más adelante considera que la disponibilidad es un problema, los clústeres de zona única desplegados en determinadas ubicaciones pueden convertirse posteriormente en clústeres multizona.

Si su clúster se ha creado con todos los nodos de trabajo en una única zona, el maestro Kubernetes de su clúster clásico cuenta con alta disponibilidad e incluye hosts físicos independientes para su servidor API maestro, el etcd, el programador y el gestor de controladores, con el fin de protegerlo frente a posibles interrupciones del servicio, como las que pueden producirse durante una actualización del maestro. Puede añadir nodos trabajadores adicionales a su clúster de zona única para mejorar la disponibilidad y añadir protección en caso de que falle un nodo trabajador.

Si un nodo trabajador queda inactivo, las instancias de la app de los nodos trabajadores disponibles continúan ejecutándose. Kubernetes vuelve a planificar automáticamente los pods de los nodos trabajadores no disponibles para garantizar el rendimiento y la capacidad de la app. Para garantizar que tus pods se distribuyan de manera uniforme entre los nodos de trabajo, implementa la afinidad de pods.

Seleccione un tipo de clúster

Los tipos de nodo trabajador y los niveles de aislamiento disponibles dependen de la plataforma del contenedor, del tipo de clúster, del proveedor de la infraestructura que desea utilizar y de la ubicación de IBM Cloud Kubernetes Service en la que desea crear el clúster. Puede elegir entre clústeres Classic, VPC o Satellite. El tipo de clúster que necesitas viene determinado por las decisiones que hayas tomado respecto al número de clústeres y sus ubicaciones.

Opciones de hardware para nodos trabajadores en un clúster estándar*Opciones de
para nodos trabajadores en un
estándar*

Clústeres de VPC
Los nodos de trabajo se aprovisionan como instancias de servidor virtual en la infraestructura VPC. VPC es el tipo de infraestructura recomendado para los nuevos clústeres. Ofrece aislamiento de red de forma predeterminada y es compatible con las últimas funciones de « IBM Cloud Kubernetes Service », entre las que se incluyen los hosts dedicados y la seguridad predeterminada.
Clústeres de Satellite
Los nodos de trabajo se implementan en su propia infraestructura, ya sea en hardware local o en máquinas virtuales de otros proveedores de servicios en la nube, como AWS, Azure y GCP. Utiliza Satellite cuando necesites ejecutar clústeres gestionados por IBM Cloud fuera de los centros de datos de IBM Cloud.
Clústeres clásicos
Los nodos de trabajo se aprovisionan en máquinas virtuales o físicas en una infraestructura clásica de « IBM Cloud ». Utiliza Classic si necesitas nodos de trabajo «bare metal», opciones de almacenamiento definido por software (SDS) o conexiones a recursos de infraestructura clásica ya existentes.

Seleccione un sistema operativo para el clúster

Los sistemas operativos disponibles dependen del tipo de clúster elegido.

Ubuntu 24
Para más información, consulte las notas de la versión Ubuntu 24.04. Tenga en cuenta que con Ubuntu 24, NTP utiliza timesyncd y los comandos relacionados podrían actualizarse.

¿Vas a migrar a un nuevo sistema operativo? Consulte Migración a una nueva versión de Ubuntu.

Definir una estrategia de nomenclatura de clústeres

Considere la posibilidad de asignar nombres exclusivos a los clústeres de los grupos de recursos y a las regiones de la cuenta para evitar conflictos de nombres de métricas. No se puede cambiar el nombre de un clúster una vez creado.

Decidir cuántos nodos trabajadores para cada clúster

El nivel de disponibilidad que configure para el clúster afecta a la cobertura bajo los términos del acuerdo de nivel de servicio de alta disponibilidad de IBM Cloud. Por ejemplo, para recibir una cobertura completa de alta disponibilidad según los términos del SLA, debe configurar un clúster multizona con un total de 6 nodos de trabajador como mínimo, dos nodos de trabajador por zona que se distribuyen uniformemente en tres zonas.

El número total de nodos trabajadores de un clúster determina la capacidad de cálculo que está disponible para las apps del clúster. Puede proteger su configuración en caso de fallo de un nodo de trabajo configurando varios nodos de trabajo en su clúster. Los fallos en los nodos de trabajo pueden incluir interrupciones de hardware, como problemas de alimentación, refrigeración o red, así como problemas en el propio VM.

  • Clústeres multizona Classic VPC: Prevé contar con al menos dos nodos de trabajo por zona, es decir, seis nodos en total repartidos en tres zonas. Además, planifique que la capacidad total del clúster sea al menos el 150 % de la capacidad requerida de la carga de trabajo, de forma que si una zona deja de funcionar, tenga recursos disponibles para mantener la carga de trabajo.

  • Clústeres de una sola zona: planifica contar con al menos tres nodos de trabajo en tu clúster. Además, quiere tener disponible capacidad adicional de CPU y memoria equivalente al valor de un nodo en el clúster. Si tus aplicaciones requieren menos recursos de los que hay disponibles en el nodo de trabajo, es posible que puedas limitar el número de pods que despliegas en un nodo de trabajo.

Tenga en cuenta que:

Seleccionar sabores de nodo trabajador

Un nodo de trabajo es un VM que se ejecuta en hardware físico. Un tipo de nodo trabajador describe los recursos de cálculo, como CPU, memoria y capacidad de disco, que obtiene al solicitar el nodo trabajador.  Los nodos trabajadores del mismo tipo se agrupan en agrupaciones de nodos trabajadores.

A la hora de elegir un tipo de clúster, ya ha pensado en cómo influyen en su decisión la ubicación del sabor del nodo del trabajador y el tipo de máquina. A la hora de elegir entre los distintos tipos de nodos trabajadores, tenga en cuenta lo siguiente.

  • Tenencia: En función del nivel de aislamiento de hardware que necesite, los nodos de trabajador virtual pueden configurarse como compartidos por varios IBM clientes (tenencia múltiple) o dedicados únicamente a usted (tenencia única). Las máquinas "bare metal" siempre se configuran como dedicadas. A la hora de decidir entre nodos compartidos y dedicados, quizá le convenga consultar con su departamento jurídico para analizar el nivel de aislamiento de la infraestructura y de cumplimiento normativo que requiere el entorno de su aplicación.

    • Compartidos: Los recursos físicos, como la CPU y la memoria, se comparten entre todas las máquinas virtuales desplegadas en el mismo hardware físico. Para asegurarse de que cada máquina virtual se pueda ejecutar de forma independiente, un supervisor de máquina virtual, también conocido como hipervisor, segmenta los recursos físicos en entidades aisladas y los asigna como recursos dedicados a una máquina virtual (aislamiento de hipervisor). Los nodos compartidos suelen resultar más económicos que los nodos dedicados porque los costes del hardware subyacente se comparten entre varios clientes.
    • Dedicado: Todos los recursos físicos están dedicados únicamente a ti. Puede desplegar varios nodos trabajadores como máquinas virtuales en el mismo host físico. De forma similar a la configuración de tenencia múltiple, el hipervisor asegura que cada nodo trabajador recibe su parte compartida de los recursos físicos disponibles.
  • Tipo de máquina: Tienes una mezcla de tipos de máquina entre los que puedes elegir.

    • Máquinas virtuales: Para una mayor flexibilidad, tiempos de aprovisionamiento más rápidos, funciones de escalabilidad más automáticas y un precio más rentable, utilice máquinas virtuales. Puede utilizar máquinas virtuales en la mayoría de los casos prácticos de finalidad general como, por ejemplo, en entornos de desarrollo y pruebas, entornos de transferencia y producción, microservicios y apps empresariales. Sin embargo, esto supone una merma en el rendimiento.

    • Máquinas «bare metal» (físicas): si necesitas computación de alto rendimiento para cargas de trabajo que requieren un uso intensivo de datos o de memoria RAM, plantéate crear clústeres con nodos de trabajo «bare metal». Puesto que tiene el control completo sobre el aislamiento y el consumo de recursos para las cargas de trabajo, puede utilizar máquinas nativas para lograr la conformidad con HIPAA y PCI para su entorno. Los servidores nativos ofrecen acceso directo a los recursos físicos en la máquina, como la memoria o la CPU. Esta configuración elimina el hipervisor de máquina virtual que asigna recursos físicos a máquinas virtuales que se ejecutan en el host. En su lugar, todos los recursos de una máquina nativa están dedicados exclusivamente al trabajador, de modo que no es necesario preocuparse de que haya "vecinos ruidosos" que compartan recursos o ralenticen el rendimiento. Los tipos físicos tienen más almacenamiento local que virtual, y algunos tienen RAID para aumentar la disponibilidad de los datos. El almacenamiento local en el nodo de trabajo está destinado exclusivamente al procesamiento a corto plazo, y los discos principal y auxiliar se borran al actualizar o recargar el nodo de trabajo. Hay trabajadores de «bare metal» disponibles tanto para clústeres clásicos como para configuraciones de «bare metal» de VPC.

      La facturación de los nodos de trabajo «bare metal» varía según el tipo de infraestructura. Los servidores bare metal clásicos se facturan mensualmente. Si cancelas un servidor bare metal clásico antes de que termine el mes, se te cobrará hasta el final de ese mes. Una vez que hayas solicitado o cancelado un servidor clásico «bare metal», el proceso se completa manualmente en tu cuenta de infraestructura de IBM Cloud, por lo que puede tardar más de un día laborable en completarse. Los servidores «bare metal» de VPC se facturan por horas, sin un periodo mínimo de compromiso.

    • Máquinas SDS: Los sabores de almacenamiento definido por software (SDS) tienen discos brutos adicionales para el almacenamiento físico local. A diferencia del disco local principal y del auxiliar, estos discos sin formatear no se borran durante la actualización o la recarga de un nodo de trabajo. Debido a que los datos se coubican con el nodo de cálculo, las máquinas SDS son adecuadas para cargas de trabajo de alto rendimiento. El tipo de almacenamiento definido por software está disponible únicamente para clústeres clásicos y no se admite en clústeres de VPC.

      Puesto que tiene el control completo sobre el aislamiento y el consumo de recursos para las cargas de trabajo, puede utilizar máquinas SDS para lograr la conformidad con HIPAA y PCI para su entorno.

      Normalmente, se utilizan máquinas SDS en los casos siguientes: * Si utilizas un complemento de SDS, como Portworx, utiliza una máquina SDS. * Si tu aplicación es un StatefulSet que requiere almacenamiento local, puedes utilizar máquinas SDS y aprovisionar volúmenes persistentes locales Kubernetes. * Si tiene apps personalizadas que requieran almacenamiento local adicional en bruto.

  • Coste: en general, las cargas de trabajo intensivas se adaptan mejor a máquinas físicas bare metal, mientras que para tareas de pruebas y desarrollo con una buena relación calidad-precio, es posible que prefieras máquinas virtuales en hardware compartido o dedicado.

  • Localización: Decide en qué ubicaciones quieres tener un clúster. El lugar en el que se desea también puede informar sobre el número o el tipo de agrupaciones que se necesitan. Por ejemplo, si sabe que necesita que el lugar esté en Montreal, eso le ayudará a reducir sus opciones. Consulta las localizaciones disponibles.

  • Tamaño: los nodos más grandes pueden resultar más rentables que los más pequeños, especialmente en el caso de cargas de trabajo diseñadas para ganar en eficiencia cuando se procesan en una máquina de alto rendimiento. Sin embargo, si un nodo de trabajo de gran tamaño deja de funcionar, debes asegurarte de que tu clúster tenga capacidad suficiente para reprogramar de forma segura todos los pods de la carga de trabajo en otros nodos de trabajo del clúster. Los nodos de trabajadores más pequeños pueden ayudarle a escalar con seguridad. Más información sobre la capacidad.

  • GPU: Puede utilizar una máquina GPU para acelerar el tiempo de procesamiento necesario para cargas de trabajo de cálculo intensivo como IA, aprendizaje automático, inferencias y mucho más.

  • Almacenamiento: Cada VM incluye un disco adjunto para almacenar la información que necesita el VM para funcionar, como el sistema de archivos del sistema operativo, el entorno de ejecución de contenedores y el kubelet. El almacenamiento local en el nodo trabajador solo es para el proceso a corto plazo y los discos se limpian cuando se suprime, se vuelve a cargar, se sustituye o se actualiza el nodo trabajador. Además, la infraestructura clásica y de VPC difieren en la configuración del disco.

    • VM clásicas: las VM clásicas tienen dos discos conectados. El disco de almacenamiento principal dispone de 25 GB para el sistema de archivos del sistema operativo, y el disco de almacenamiento auxiliar dispone de 100 GB para datos como el entorno de ejecución de contenedores y el kubelet. Para garantizar la fiabilidad, los volúmenes de almacenamiento principal y auxiliar son discos locales en lugar de una red de área de almacenamiento (SAN). Entre las ventajas de fiabilidad se incluyen un mejor rendimiento al serializar bytes en el disco local y una reducción de la degradación del sistema de archivos debido a anomalías de la red. El disco auxiliar está cifrado de forma predeterminada.
    • Máquinas virtuales de cálculo de VPC: las máquinas virtuales de VPC tienen un disco principal que es un volumen de almacenamiento en bloques conectado a través de la red. La capa de almacenamiento no está separada de las otras capas de la red, y tanto el tráfico de la red como el de almacenamiento se direccionan en la misma red. El disco de almacenamiento primario se utiliza para almacenar datos como el sistema de archivos del SO, el entorno de tiempo de ejecución del contenedor y kubelet y está cifrado de forma predeterminada. Para clusters VPC, también puede aprovisionar un disco secundario en sus nodos trabajadores. Este disco opcional se ha habilitado en tu cuenta y puedes verlo en la consola de VPC. Los gastos de estos discos son independientes del coste de cada trabajador y aparecen como una partida diferente en su factura. Estos volúmenes secundarios también se tienen en cuenta a la hora de calcular el uso de la cuota de tu cuenta. Para evitar la expulsión automática de pods, se reserva el 10 % del disco de datos de Kubernetes (disco auxiliar en Classic, disco de arranque principal en VPC) para los componentes del sistema.

    En una app con estado, los datos desempeñan un papel importante para mantener la app en funcionamiento. Asegúrese de que los datos son de alta disponibilidad, de forma que pueda recuperarse de un error potencial. En IBM Cloud Kubernetes Service, puede elegir entre varias opciones para conservar los datos. Por ejemplo, puede suministrar almacenamiento NFS utilizando volúmenes persistentes nativos de Kubernetes, o almacenar los datos utilizando un servicio de base de datos de IBM Cloud. Para obtener más información, consulta Planificación de datos de alta disponibilidad.

    Elige una variante, o tipo de máquina, con la configuración de almacenamiento adecuada para tu carga de trabajo. Algunos tipos tienen una combinación de las siguientes configuraciones de disco y almacenamiento. Por ejemplo, algunos tipos tener un disco primario SATA con un disco secundario SSD sin formato.

Para obtener una lista de las variantes disponibles, consulte Variantes VPC o Variantes clásicas.

Determinar la capacidad del nodo trabajador para los recursos

Para aprovechar al máximo el rendimiento de tu nodo trabajador, ten en cuenta lo siguiente a la hora de configurar tus recursos:

  • Considera lo que hace tu aplicación: Empieza alineando el tamaño de la aplicación con la capacidad de uno de los tipos de nodo trabajador disponibles. Ten en cuenta también aspectos como si tu aplicación descarga imágenes grandes o en gran cantidad, ya que pueden ocupar espacio en el almacenamiento local del nodo de trabajo.

  • Mantenga la fuerza del núcleo: Cada máquina tiene un determinado número de núcleos. Según la carga de trabajo de su app, establezca un número límite de pods por núcleo, como por ejemplo 10.

  • Evita la sobrecarga de nodos: mantén tu nodo de trabajo al 75 % de su capacidad aproximadamente para dejar espacio a otros pods que puedan necesitar ser programados. Si las apps requieren más recursos de los que hay disponibles en el nodo trabajador, utilice un tipo de nodo trabajador distinto que pueda cumplir estos requisitos. Según la carga de trabajo de su app, establezca un límite de pods por nodo, como por ejemplo 40.

  • Elige los servicios: ¿Cuántas integraciones de servicios decidiste incluir cuando pensabas en cuántos clústeres crear? Estos servicios integrados y complementos pueden crear pods que consumen recursos del clúster y afectan a estos.

  • Réplicas de la app: Para determinar el número de nodos trabajadores que desea, también puede considerar cuántas réplicas de la app desea ejecutar. Por ejemplo, si sabe que la carga de trabajo requiere 32 núcleos de CPU, y tiene previsto ejecutar 16 réplicas de la app, cada pod de réplica necesita 2 núcleos de CPU. Si desea ejecutar solo un pod de app por nodo trabajador, puede solicitar un número apropiado de nodos trabajadores para su tipo de clúster para dar soporte a esta configuración.

  • Deje espacio para los requisitos de tiempo de ejecución: Los nodos de trabajo deben reservar ciertas cantidades de recursos de CPU y memoria para ejecutar los componentes necesarios, como el sistema operativo o el tiempo de ejecución del contenedor.

No se admiten la capacidad reservada ni las instancias reservadas.

Elija cuántos espacios de nombres crear dentro del clúster

Configure varios espacios de nombres cuando tenga varios equipos y proyectos que compartan el clúster. Los espacios de nombres son una forma de dividir los recursos del clúster mediante cuotas de recursos y límites por defecto. Cuando cree nuevos espacios de nombres, asegúrese de configurar políticas de RBAC adecuadas para controlar el acceso. Para obtener más información, consulta Compartir un clúster con espacios de nombres en la documentación de Kubernetes.

Si tiene un pequeño clúster, un par de docenas de usuarios y recursos que son similares (por ejemplo, diferentes versiones del mismo software), probablemente no necesite varios espacios de nombres. En su lugar, puede utilizar etiquetas.

Revise la información de seguridad sobre esta decisión en Aislamiento y seguridad de contenedores.

Establecer solicitudes y límites de recursos para los espacios de nombres

Para garantizar que todos los equipos dispongan de los recursos necesarios para implementar servicios y ejecutar aplicaciones en el clúster, debes configurar cuotas de recursos para cada espacio de nombres. Las cuotas de recursos determinan las restricciones de implementación, como el número de recursos de Kubernetes que se pueden implementar y la cantidad de CPU y memoria que pueden consumir dichos recursos. Después de establecer una cuota, los usuarios deben incluir los límites y las solicitudes de recursos en sus despliegues.

Cuando crees una implementación, limítala también para que el pod de tu aplicación solo se implemente en máquinas con la mejor combinación de recursos. Por ejemplo, puede que desee limitar una aplicación de base de datos a una máquina nativa con un volumen importante de almacenamiento en disco local como por ejemplo md1c.28x512.4x4tb.

Aumente la disponibilidad de sus aplicaciones

Los contenedores y pods son, por diseño, efímeros y pueden fallar inesperadamente. Por ejemplo, un contenedor o pod puede colgarse si se produce un error en la app. Para que tu aplicación tenga una alta disponibilidad, debes asegurarte de disponer de suficientes instancias para gestionar la carga de trabajo, además de instancias adicionales en caso de fallo. Puedes asegurarte de que hay suficientes instancias configurando escalado automático.

Buenas prácticas en curso

Una vez que el clúster esté en funcionamiento, sigue estas recomendaciones para mantenerlo seguro y en buen estado.

Mantén actualizado tu entorno de clúster

Comprobar mensualmente la disponibilidad de parches de seguridad y del sistema operativo para actualizar los nodos trabajadores. Asegúrate de actualizar tu clúster periódicamente para mantenerte en una versión compatible de Kubernetes Service.

Mantén actualizadas tus herramientas de línea comando

En la línea de comandos, se le notificará cuando haya actualizaciones disponibles de la CLI de ibmcloud y de conectores. Asegúrese de mantener actualizada la CLI para que pueda utilizar todos los mandatos y opciones disponibles.

Asegúrese de que el cliente de CLI de kubectl coincida con la misma versión de Kubernetes que el servidor del clúster. Kubernetes No es compatible con versiones de cliente kubectl que tengan una diferencia de 2 o más versiones con respecto a la versión del servidor (n ± 2).

Renueva periódicamente tus certificados CA

Por motivos de seguridad, se recomienda la renovación periódica de los certificados de la autoridad de certificación (CA). Los pasos para la rotación de certificados de autoridad de certificación (CA) incluyen la recarga o sustitución de los nodos de trabajo, por lo que conviene rotar los certificados de CA cada vez que actualices tus nodos de trabajo. Para obtener más información, consulta Rotación de certificados de CA en tu clúster.

Documenta la arquitectura de tu entorno

Mantener la documentación y los diagramas actualizados puede resultar de ayuda a la hora de solucionar problemas. Para obtener más información, consulta Documentación de la arquitectura de tu entorno.

Suscríbete para recibir las actualizaciones de las notas de la versión

Puedes recibir las notas de la versión de la documentación de IBM Cloud Kubernetes Service a través de RSS. Para obtener más información, consulta las Notas de la versión.

Próximos pasos

Para continuar con el proceso de planificación, elija entre VPC cluster networking y Classic cluster networking. Si estás listo para empezar a crear un clúster, primero empieza por Preparar tu cuenta para crear clústeres.