IBM Cloud Docs
Planificación de despliegues de apps

Planificación de despliegues de apps

Antes de desplegar una aplicación en su clúster Red Hat OpenShift on IBM Cloud, decida cómo desea configurar su aplicación para que se pueda acceder a ella correctamente y se integre con otros servicios en IBM Cloud.

Traslado de cargas de trabajo a Red Hat OpenShift on IBM Cloud

Vea los tipos de cargas de trabajo que se pueden ejecutar en Red Hat OpenShift on IBM Cloud y la mejor manera de configurar estas cargas de trabajo.

¿Qué tipo de apps puedo ejecutar en Red Hat OpenShift on IBM Cloud?

Apps sin estado
Para los entornos de nube nativa como Kubernetes se prefieren las apps sin estado. Son fáciles de migrar y escalar porque declaran dependencias y almacenan las configuraciones de forma separada del código, y tratan los servicios de respaldo como por ejemplo las bases de datos como recursos adjuntos en lugar de emparejados a la app. Los pods de la aplicación no requieren almacenamiento de datos persistente ni una dirección IP de red estable y, por ello, se pueden terminar, replanificar y escalar como respuesta a las demandas de carga de trabajo. La app utiliza Database-as-a-Service para los datos persistentes y NodePort, un equilibrador de carga, o los servicios de Ingress para exponer la carga de trabajo en una dirección IP estable.
Apps con estado
Las apps con estado son más complicadas de configurar, gestionar y escalar que las apps sin estado porque los pods requieren datos persistentes y una identidad de red estable. Las apps con estado son a menudo bases de datos u otras cargas de trabajo distribuidas, intensivas en datos, en las que el procesamiento es más eficiente más cerca de los datos propiamente dichos. Si desea desplegar una app con estado, tiene que configurar el almacenamiento persistente y montar un volumen persistente en el pod controlado por un objeto StatefulSet. Puede elegir añadir almacenamiento de archivos, bloques u objetos como almacenamiento persistente para el conjunto con estado. También puede instalar Portworx en sus nodos de trabajo de metal desnudo y utilizar Portworx como solución de almacenamiento definido por software de alta disponibilidad para gestionar el almacenamiento persistente de sus aplicaciones con estado. Para más información sobre el funcionamiento de los conjuntos con estado, consulte la documentación de Kubernetes.

Algunas directrices para desarrollar apps sin estado, nativas de la nube

Eche un vistazo a la App de los Doce Factores, una metodología neutral desde el punto de vista lingüístico para considerar cómo desarrollar su aplicación a través de 12 factores, que se resumen a continuación.

  1. Base de código: utilice una base de código única en un sistema de control de versiones para los despliegues. Al extraer una imagen para el despliegue del contenedor, especifique una etiqueta de imagen probada en lugar de utilizar latest.
  2. Dependencias: Declare explícitamente y aísle las dependencias externas.
  3. Configuración: Almacene la configuración específica del despliegue en variables de entorno, no en el código.
  4. Servicios de copia de seguridad: Trate los servicios de copia de seguridad, tales como almacenes de datos o colas de mensajes, como recursos adjuntos o sustituibles.
  5. Etapas de una app: Cree las apps en etapas diferenciadas, como por ejemplo build, release, run, con una separación estricta entre ellas.
  6. Procesos: Ejecute la app como uno o más procesos sin estado que no compartan nada y utilice almacenamiento persistente para guardar los datos.
  7. Enlace de puertos: Los enlaces de puertos deben ser independientes y proporcionar un punto final de servicio en un host y un puerto bien definidos.
  8. Concurrencia: Gestione y escale la app a través de instancias de proceso tales como réplicas y escalado horizontal. Establezca solicitudes de recursos y límites para los despliegues. Observe que las políticas de red de Calico no pueden limitar el ancho de banda.
  9. Desechabilidad: Diseñe su app para que sea fácil de desechar, con un inicio rápido, una conclusión ordenada y buena tolerancia a terminaciones abruptas de procesos. Recuerde, los contenedores, los pods, e incluso los nodos trabajadores deben ser desechables, por lo que debe planificar su app en consecuencia.
  10. Paridad entre desarrollo y producción: Configure un canal de integración continua y entrega continua para su aplicación, con una diferencia mínima entre la aplicación en desarrollo y la aplicación en producción.
  11. Registros: Trate los archivos de registro como secuencias de sucesos: el entorno externo o de alojamiento es quien procesa y direcciona los archivos de registro. Importante: En Red Hat OpenShift on IBM Cloud, los archivos de registro no están activados de forma predeterminada. Para habilitarlos, consulte Configuración del reenvío de archivos de registro.
  12. Procesos de administración: Mantenga cualquier script de administración único con su aplicación y ejecútelo como un objeto de trabajo Kubernetes para garantizar que los scripts de administración se ejecutan con el mismo entorno que la propia aplicación. Para la orquestación de paquetes más grandes que desee ejecutar en sus clústeres de Kubernetes, considere el uso de un gestor de paquetes como Helm.

¿Qué ocurre con las aplicaciones sin servidor?

Puede ejecutar aplicaciones y trabajos sin servidor a través del servicio IBM Cloud Code Engine. Code Engine también puede crear sus imágenes automáticamente.

Ya tengo una app. ¿Cómo puedo migrarla a Red Hat OpenShift on IBM Cloud?

Puede realizar algunos pasos generales para contenerizar la app como se indica a continuación.

  1. Utilice la aplicación de doce factores como guía para aislar dependencias, separar procesos en servicios independientes y reducir al máximo el estado de su aplicación.
  2. Busque una imagen base encontrar para utilizar. Puede utilizar imágenes públicas disponibles en Docker Hub, imágenes públicas de IBM, o crear y gestionar las suyas propias en su IBM Cloud Container Registry privado.
  3. Añada a su imagen de Docker sólo aquello que sea necesario para ejecutar la app.
  4. Revise los casos prácticos comunes de modificación de apps.
  5. En lugar de utilizar un almacenamiento local, planifique utilizar soluciones de almacenamiento persistente o de base de datos como servicio en la nube para realizar copias de seguridad de los datos de su app.
  6. Con el tiempo, refactorice los procesos de la app en microservicios.

Casos prácticos comunes de modificación de apps

Red Hat OpenShift tiene valores predeterminados distintos a los de Kubernetes de comunidad, como por ejemplo restricciones de contexto de seguridad más estrictas. Revise los siguientes casos prácticos en los que es posible que tenga que modificar las apps para poderlas desplegar en clústeres de Red Hat OpenShift.

Casos prácticos comunes que requieren modificaciones de una app
Escenario Pasos que puede realizar
La app se ejecuta como root. Es posible que vea que los pods fallan con el estado CrashLoopBackOff El pod necesita acceso con privilegios. Consulte Pasos de ejemplo para otorgar a un despliegue acceso con privilegios. Para obtener más información, consulte la documentación de Red Hat OpenShift sobre la gestión de las restricciones de contexto de seguridad(SCC).
Las apps están diseñadas para que se ejecuten en Docker. Estas apps suelen ser herramientas de registro y de supervisión que se basan en el motor de tiempo de ejecución del contenedor, ejecutan la API de tiempo de ejecución del contenedor directamente y acceden a directorios de registro del contenedor. En Red Hat OpenShift, la imagen deben ser compatible con el tiempo de ejecución del contenedor CRI-O. Para más información, consulte Uso del motor de contenedores CRI-O.
La aplicación utiliza el almacenamiento de archivos persistente con un ID de usuario no root que no puede escribir en el dispositivo de almacenamiento montado. Ajuste el contexto de seguridad para el despliegue de la app de modo que runAsUser tenga el valor 0.
El servicio está expuesto en el puerto 80 o en otro puerto menor que 1024. Es posible que un error de tipo Permission denied.

Los puertos menores que 1024 son puertos con privilegios que están reservados para los procesos de arranque. Podrías elegir una de las siguientes soluciones:

  • Cambie el puerto a 8080 o un puerto similar mayor que 1024 y actualice sus contenedores para escuchar en este puerto.
  • Agregue su implementación de contenedor a una cuenta de servicio privilegiada, como en el ejemplo para otorgar acceso privilegiado a una implementación.
  • Configure su contenedor para escuchar en cualquier puerto de red, luego actualice el tiempo de ejecución del contenedor para asignar ese puerto al puerto 80 en el host mediante el reenvío de puertos.
Otros casos de uso y casos prácticos Revise la documentación de Red Hat OpenShift para migrar bases de datos, aplicaciones de infraestructura web, CI/CD.

Pasos de ejemplo para otorgar a un despliegue acceso con privilegios

Si tiene una app que se ejecuta con permisos de root, debe modificar el despliegue para que funcione con las restricciones de contexto de seguridad definidas para el clúster de Red Hat OpenShift. Por ejemplo, puede configurar el proyecto con una cuenta de servicio para controlar el acceso con privilegios y luego modificar el despliegue para que utilice esta cuenta de servicio.

Antes de empezar: acceda al clúster de Red Hat OpenShift.

  1. Como administrador del clúster, cree un proyecto.

    oc adm new-project <project_name>
    
  2. Elija como destino el proyecto de modo que los recursos siguientes que cree estén en el espacio de nombres del proyecto.

    oc project <project_name>
    
  3. Cree una cuenta de servicio para el proyecto.

    oc create serviceaccount <sa_name>
    
  4. Añada una restricción de contexto de seguridad con privilegios a la cuenta de servicio para el proyecto. Si desea comprobar qué políticas hay en la SCC de privileged, ejecute oc describe scc privileged. Para obtener más información sobre las SCC, consulte la documentación deRed Hat OpenShift.

    oc adm policy add-scc-to-user privileged -n <project_name> -z <sa_name>
    
  5. En el archivo de configuración del despliegue, haga referencia a la cuenta de servicio con privilegios y establezca el contexto de seguridad como privilegiado.

    • En spec.template.spec, añada serviceAccount: <sa_name>.
    • En spec.template.spec.containers, añada securityContext: privileged: true.

    Ejemplo

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp_deployment
      labels:
        app: myapp
    spec:
      ...
      template:
        ...
        spec:
          serviceAccount: <sa_name>
          containers:
          - securityContext:
              privileged: true
          ...
    
  6. Despliegue el archivo de configuración de la app.

    oc apply -f <filepath/deployment.yaml>
    
  7. Verifique que el pod está en el estado Running. Si el pod muestra un estado de error o se queda atascado en un estado durante mucho tiempo, describa el pod y revise la sección Events para comenzar el solucionar el problema del despliegue.

    oc get pods
    

Visión general de los objetos de Kubernetes para apps

Con Kubernetes, debe declarar muchos tipos de objetos en archivos de configuración YAML, como por ejemplo pods, despliegues y trabajos. Estos objetos describen cosas tales como las apps en contenedores que se están ejecutando, los recursos que utilizan y las políticas que gestionan su comportamiento a la hora de reiniciar, actualizar, replicar, etc. Para más información, consulte la documentación de Kubernetes para conocer las mejores prácticas de configuración.

Creía que tenía que poner mi app en un contenedor. ¿Qué es todo esto de los pods?

Un pod es la unidad desplegable más pequeña que puede gestionar Kubernetes. El usuario pone su contenedor (o un grupo de contenedores) en un pod y usa el archivo de configuración del pod para indicar al pod cómo ejecutar el contenedor y compartir recursos con otros pods. Todos los contenedores que se colocan en un pod se ejecutan en un contexto compartido, lo que significa que comparten la máquina virtual o física.

Qué incluir en un contenedor
Cuando piense en los componentes de la aplicación, considere si sus requisitos de recursos, como CPU o memoria, difieren significativamente. ¿Algunos componentes podrían ejecutarse mejor reduciendo un poco para desviar recursos hacia otras áreas? ¿Hay otro componente que es de cara al cliente, por lo que es de gran importancia que se mantenga activo? Divídalos en contenedores separados. Siempre puede desplegarlos en el mismo pod de modo que se ejecuten de forma sincronizada.
Qué colocar en un pod
Los contenedores de una aplicación no tienen que estar siempre en el mismo pod. De hecho, si tiene un componente con estado y difícil de escalar, como por ejemplo un servicio de base de datos, póngalo en un pod distinto que pueda planificar en un nodo trabajador con más recursos para manejar la carga de trabajo. Si los contenedores funcionan correctamente si se ejecutan en nodos trabajadores diferentes, utilice varios pods. Si tienen que estar en la misma máquina y escalarse juntos, agrupe los contenedores en el mismo pod.

Si puedo utilizar una cápsula, ¿para qué necesito todos estos tipos de objetos?

Crear un archivo YAML de pod es fácil. Puede escribir una con sólo unas pocas líneas como se indica a continuación.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Pero con esto no es suficiente. Si el nodo con el que se ejecuta el pod queda inactivo, el pod queda inactivo también y no se vuelve a programar. En su lugar, utilice un despliegue que admita la reprogramación de pods, conjuntos de réplicas y actualizaciones continuas. Un despliegue básico es casi tan fácil de hace como un pod. En lugar de definir sólo el contenedor en la spec, debe especificar replicas y una template en la spec del despliegue. La plantilla tiene su propia spec para los contenedores dentro de la misma, como por ejemplo el código siguiente.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Puede seguir añadiendo características como, por ejemplo, antiafinidad o límites de recursos, todos en el mismo archivo YAML.

Para obtener una explicación más detallada de las diferentes características que puede añadir a su despliegue, consulte Creación del archivo YAML de despliegue de su aplicación.

¿Qué tipo de objetos Kubernetes puedo crear para mi app?

Cuando prepare el archivo YAML de la app, tiene muchas opciones para aumentar la disponibilidad, el rendimiento y la seguridad de la app. Por ejemplo, en lugar de un solo pod, puede utilizar un objeto controlador de Kubernetes para gestionar la carga de trabajo, como un conjunto de réplicas, un trabajo o un conjunto de daemons. Para más información sobre pods y controladores, consulte la documentación de Kubernetes. Un despliegue que gestiona un conjunto de réplicas de pods es un caso de uso común para una app.

Por ejemplo, un objeto kind: Deployment constituye una buena opción para desplegar un pod de app porque con este objeto puede especificar un conjunto de réplicas para aumentar la disponibilidad de los pods.

En la tabla siguiente se describe por qué puede crear distintos tipos de objetos de carga de trabajo de Kubernetes.

Tipos de objetos de carga de trabajo de Kubernetes que se pueden crear.
Objecto Descripción
Pod Un pod es la unidad desplegable más pequeña para las cargas de trabajo, y puede contener un solo contenedor o varios. Al igual que los contenedores, los pods son desechables y se suelen utilizar para realizar pruebas unitarias de las funciones de las aplicaciones. Para evitar el tiempo de inactividad de la app, considere la posibilidad de desplegar pods con un controlador de Kubernetes, como un despliegue. Un despliegue le ayuda a gestionar varios pods, réplicas, escalado de pods, despliegues y más.
ReplicaSet Un conjunto de réplicas garantiza que se ejecutan varias réplicas del pod y que se vuelve a planificar el pod en el caso de que se desactive. Puede crear un conjunto de réplicas para probar cómo funciona la planificación del pod, pero, para gestionar actualizaciones de app, despliegues y escalado, cree en su lugar un despliegue.
Deployment Un despliegue es un controlador que gestiona un pod o un conjunto de réplicas de plantillas de pod. Puede crear pods o conjuntos de réplicas sin un despliegue para probar las características de la app. En el caso de una configuración de nivel de producción, utilice despliegues para gestionar actualizaciones, despliegues y escalado de apps.
StatefulSet De forma similar a los despliegues, un conjunto con estado es un controlador que gestiona un conjunto de réplicas de pods. A diferencia de los despliegues, un conjunto con estado garantiza que su pod tiene una identidad de red exclusiva que mantiene su estado entre replanificaciones. Cuando desee ejecutar cargas de trabajo en la nube, intente diseñar la app de modo que sea sin estado para que las instancias de servicio sean independientes entre sí y, si fallan, no se interrumpa el servicio. Sin embargo, algunas apps, como las bases de datos, deben ser con estado. En estos casos, considere la posibilidad de crear un conjunto con estado y utilizar el almacenamiento de archivos, en bloque o de objeto como almacenamiento persistente para el conjunto con estado. También puede instalar Portworx en sus nodos de trabajo de metal desnudo y utilizar Portworx como solución de almacenamiento definido por software de alta disponibilidad para gestionar el almacenamiento persistente de su conjunto de estados.
DaemonSet Utilice un conjunto de daemons cuando tenga que ejecutar el mismo pod en cada nodo trabajador del clúster. Los pods gestionados por un conjunto de daemons se planifican automáticamente cuando se añade un nodo trabajador a un clúster. Los casos de uso típicos incluyen recopiladores de registros, como logstash o prometheus, que recopilan registros de cada nodo trabajador para proporcionar detalles sobre el estado de un clúster o de una app.
Job Un trabajo garantiza que uno o varios pods se ejecutan correctamente hasta su finalización. Puede utilizar un trabajo para colas o trabajos por lotes para admitir el procesamiento paralelo de elementos de trabajo independientes pero relacionados, como fotogramas específicos que renderizar, correos electrónicos que enviar y archivos que convertir. Para programar un trabajo para que se ejecute a determinadas horas, utilice un comando CronJob.

¿Qué sucede si quiero que la configuración de mi app utilice variables? ¿Cómo añado estas variables al YAML?

Para añadir información variable a sus despliegues en lugar de codificar los datos en el archivo YAML, puede utilizar Kubernetes ConfigMap o Secret objeto.

Para consumir un mapa de configuración o un secreto, debe montarlo en el pod. El objeto configmap o secret se combina con el pod justo antes de que se ejecute el pod. Puede reutilizar una especificación de despliegue y una imagen entre varias apps, pero luego debe intercambiar los mapas de configuración y los secretos personalizados. Los secretos en concreto consumen mucho almacenamiento en el nodo local, así que debe planificarlos en consecuencia.

Ambos recursos definen pares de clave-valor, pero se utilizan para situaciones diferentes.

Configmap
Proporcione información de configuración no confidencial para las cargas de trabajo que se especifican en un despliegue. Puede utilizar mapas de configuración de tres maneras principales.
  • Sistema de archivos: se puede montar un archivo entero o un conjunto de variables en un pod. Se crea un archivo para cada entrada, en función del contenido de nombre de clave del archivo que se establece en el valor.
  • Variable de entorno: configure de forma dinámica la variable de entorno de una especificación de contenedor.
  • Opción de línea de comandos: Establece la opción de línea de comandos que se utiliza en una especificación de contenedor.
Secreto
Proporcione información confidencial a las cargas de trabajo tal como se indica a continuación. Otros usuarios del clúster pueden tener acceso al secreto, de modo que asegúrese de que la información secreta se puede compartir con esos usuarios.
  • Información de identificación personal (PII): almacene en secretos la información confidencial, como, por ejemplo direcciones de correo electrónico u otra información que sea necesaria para la conformidad de la empresa o el cumplimiento con la normativa gubernamental.
  • Credenciales: coloque las credenciales, como por ejemplo contraseñas, claves y señales, en un secreto para reducir el riesgo de una exposición accidental. Por ejemplo, cuando enlaza un servicio al clúster, las credenciales se guardan en un secreto.

¿Desea proteger aún más sus secretos? Solicite al administrador del clúster que habilite un proveedor de servicios de gestión de claves en el clúster para cifrar los secretos nuevos y existentes.

¿Cómo puedo asegurarme de que mi aplicación tiene los recursos correctos?

Cuando especifique el archivo YAML de su aplicación, podrá añadir funciones Kubernetes a la configuración de su aplicación que le ayudarán a obtener los recursos correctos. En particular, establezca los límites de recursos y solicitudes para cada contenedor que esté definido en su archivo YAML.

Además, el administrador del clúster puede configurar controles de recursos que afecten al despliegue de la app, como los siguientes.

¿Cómo puedo añadir funciones a la configuración de mi app?

Consulte Especificación de los requisitos de la app en el archivo YAML para ver descripciones de lo que puede incluir en un despliegue. El ejemplo incluye las opciones siguientes.

¿Cómo puedo añadir servicios de IBM, como por ejemplo Watson, a mi app?

Consulte Adición de servicios a apps.

Planificación de despliegues de alta disponibilidad

Cuanto más ampliamente distribuya la configuración entre varios nodos trabajadores y clústeres, menor será la probabilidad de que los usuarios experimenten tiempo de inactividad con la app.

Revise las siguientes configuraciones potenciales de apps que están ordenadas por grados de disponibilidad en orden ascendente.

Etapas de alta disponibilidad para una
de alta disponibilidad para una

  1. Un despliegue con pods n+2 gestionados por un conjunto de réplicas en un único nodo.
  2. Un despliegue con n+2 pods gestionados por un conjunto de réplicas y distribuidos en varios nodos (antiafinidad) en un clúster de una sola zona.
  3. Un despliegue con n+2 pods gestionados por un conjunto de réplicas y distribuidos en varios nodos (antiafinidad) en varias zonas de un clúster multizona.

También puede conectar varios clústeres en distintas regiones con un equilibrador de carga global.

¿Cómo puedo aumentar la disponibilidad de mi app?

Tenga en cuenta las opciones siguientes para aumentar la disponibilidad de la app.

Utilice despliegues y conjuntos de réplicas para desplegar la app y sus dependencias
Un despliegue es un recurso de Kubernetes que puede utilizar para declarar todos los componentes de la aplicación y sus dependencias. Con despliegues, no tiene que anotar todos los pasos, y en su lugar puede centrarse en la app. Cuando despliega más de un pod, se crea automáticamente un conjunto de réplicas para los despliegues que supervisa los pods y comprueba que estén en funcionamiento el número especificado de pods. Cuando un pod pasa a estar inactivo, el conjunto de réplicas sustituye el pod que no responde por uno nuevo. Puede utilizar un despliegue para definir estrategias para la app que incluyan el número de pods que desea añadir durante una actualización continuada y el número de pods que pueden no estar disponibles al mismo tiempo. Cuando realiza una actualización escalonada, el despliegue comprueba si la revisión funciona y detiene el despliegue cuando se detectan anomalías. Con las implantaciones, puede implantar simultáneamente varias revisiones con diferentes opciones. Por ejemplo, puede probar un primer despliegue antes de decidir si se debe utilizar para producción. Mediante el uso de Despliegues, puede realizar el seguimiento de las revisiones desplegadas. Puede utilizar este historial para retrotraer a una versión anterior si detecta que las actualizaciones no funcionan como esperaba.
Incluya suficientes réplicas para la carga de trabajo de la app, más dos
Para que la app esté aún más disponible y resulte más resistente frente a errores, considere la posibilidad de incluir más réplicas que el mínimo para gestionar la carga de trabajo prevista. Las réplicas adicionales pueden gestionar la carga de trabajo en el caso de que un pod se cuelgue y el conjunto de réplicas aún no haya recuperado el pod inactivo. Para la protección frente a dos anomalías simultáneas, incluya dos réplicas adicionales. Esta configuración es un patrón de tipo N+2, donde N es el número de réplicas necesario para gestionar la carga de trabajo entrante y +2 significa dos réplicas adicionales. Mientras el clúster tenga suficiente espacio, puede tener tantos pods como desee.
Distribuya los pods entre varios nodos (antiafinidad)
Cuando se crea un despliegue, cada pod se puede desplegar en el mismo nodo trabajador. Esto se conoce como afinidad o colocación. Para proteger la app con relación a una anomalía del nodo trabajador, es posible configurar el despliegue para repartir los pods a través de varios nodos trabajadores utilizando la opción podAntiAffinity con los clústeres estándar. Puede definir dos tipos de antiafinidad de pod: preferida o necesaria. Para más información, consulte la documentación de Kubernetes sobre Asignación de Pods a Nodos.

Para ver un ejemplo de afinidad en un despliegue de app, consulte Cómo crear el archivo YAML de despliegue de la app.
Distribución de pods entre varias zonas o regiones
Para proteger la app frente a un error de zona, puede crear varios clústeres en distintas zonas o puede añadir zonas a una agrupación de nodos trabajadores en un clúster multizona. Los clústeres multizona solo están disponibles en determinadas multizonas clásicas o VPC, como Dallas. Si crea varios clústeres en distintas zonas, debe configurar un equilibrador de carga global. Cuando se utiliza un conjunto de réplicas y se especifica la antiafinidad de pod, Kubernetes distribuye los pods de la app entre los nodos. Si los nodos están en varias zonas, los pods se distribuyen entre las zonas, lo que aumenta la disponibilidad de la app. Si desea limitar las apps de modo que solo se ejecuten en una zona, puede configurar la afinidad de pod, o puede crear y etiquetar una agrupación de nodos trabajadores en una zona.
En un despliegue de clúster multizona, ¿se distribuyen mis pods de aplicaciones uniformemente entre los nodos?
Los pods se distribuyen uniformemente entre las zonas, pero no siempre entre los nodos. Por ejemplo, si tiene un clúster con un nodo en cada una de las tres zonas y despliega un conjunto de réplicas de seis pods, cada nodo obtiene dos pods. Sin embargo, si tiene un clúster con dos nodos en cada una de las tres zonas y despliega un conjunto de réplicas de seis pods, cada zona planifica dos pods, y puede que planifique un pod por nodo o puede que no. Para un mayor control de la programación, puede configurar la afinidad de los pods.
Si una zona se cae, ¿cómo se reprograman los pods en los nodos restantes de las otras zonas?
Depende de la política de planificación utilizada en el despliegue. Si ha incluido afinidad de pods específica de nodo, sus pods no se reprogramarán. Si no lo ha hecho, los pods se crean en los nodos trabajadores disponibles en otras zonas, pero es posible que no estén equilibrados. Por ejemplo, es posible que los dos pods se distribuyan entre los dos nodos disponibles, o puede que ambos se planifiquen en un nodo con capacidad disponible. De forma similar, cuando la zona no disponible vuelve a estar activa, los pods no se suprimen y se reequilibran automáticamente entre los nodos. Si desea que los pods se reequilibren entre zonas después de que la zona vuelva a estar operativa, configure el desprogramador Kubernetes. En clusters multizona, intenta mantener la capacidad de los nodos trabajadores al 50% por zona para que quede capacidad suficiente para proteger tu cluster contra un fallo zonal.
¿Y si quiero extender mi aplicación a varias regiones?
Para proteger su aplicación de un fallo regional, cree un segundo clúster en otra región, configure un equilibrador de carga global para conectar sus clústeres y utilice un YAML de despliegue para desplegar un conjunto de réplicas duplicado con pod antiafinidad para su aplicación.
¿Y si mis aplicaciones necesitan almacenamiento persistente?
Utilice un servicio de nube, como por ejemplo IBM Cloudant o IBM Cloud Object Storage.

¿Cómo puedo escalar mi app?

Si desea añadir y eliminar apps de forma dinámica en respuesta a la utilización de la carga de trabajo, consulte Escalado de apps para ver los pasos a seguir para habilitar el escalado automático horizontal de pods.

Creación de versiones y actualización de apps

Ha puesto un montón de esfuerzo para prepararse para la próxima versión de su app. Puede utilizar herramientas de actualización de IBM Cloud y de Kubernetes para implantar distintas versiones de su app.

¿Cómo puedo organizar mis despliegues para hacerlos más fáciles de actualizar y gestionar?

Ahora que tiene una idea de lo que desea incluir en el despliegue, quizás se pregunte cómo va a gestionar todos estos archivos YAML distintos. Por no mencionar los objetos que crean en el entorno de Kubernetes.

Las siguientes sugerencias le pueden ayudar a organizar los archivos YAML de despliegue.

  • Utilice un sistema de control de versiones, como por ejemplo Git.
  • Agrupe los objetos Kubernetes estrechamente relacionados dentro de un solo archivo YAML. Por ejemplo, si está creando un deployment, también puede añadir el archivo service al YAML. Separe los objetos con --- como en el ejemplo siguiente.
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    ...
    ---
    apiVersion: v1
    kind: Service
    metadata:
    ...
    
  • Puede utilizar el mandato oc apply -f para aplicar a un directorio entero, no sólo a un archivo.
  • Pruebe el kustomize kustomize que puede utilizar para ayudar a escribir, personalizar y reutilizar las configuraciones de YAML de recursos de Kubernetes.

Dentro del archivo YAML, puede utilizar etiquetas o anotaciones como metadatos para gestionar los despliegues.

Etiquetas
Las etiquetas son pares de key:value que pueden adjuntarse a objetos de Kubernetes como pods y despliegues. Pueden ser lo que desee y son útiles para seleccionar objetos basándose en la información de la etiqueta. Las etiquetas proporcionan la base para la agrupación de objetos. Los ejemplos siguientes ilustran algunas etiquetas.
  • app: nginx
  • version: v1
  • env: dev
Anotaciones
Las anotaciones se parecen a las etiquetas en que también son pares key:value. Son mejores para información que no es identificativa y que pueden aprovechar las herramientas o las bibliotecas como, por ejemplo, información adicional sobre la procedencia de un objeto, cómo utilizar el objeto, punteros a repositorios de seguimiento relacionados, o una política sobre el objeto. Los objetos no se seleccionan en base a las anotaciones.

¿Qué estrategias de actualización de apps puedo utilizar?

Para actualizar la app, puede elegir entre diversas estrategias como las siguientes. Puede empezar con un despliegue continuo o un conmutador instantáneo antes de avanzar hacia un despliegue de prueba más complicado.

Despliegue
Puede utilizar las funciones nativas de Kubernetes para crear un despliegue de la v2 y sustituir gradualmente el despliegue anterior de la v1. Este enfoque requiere que las aplicaciones sean compatibles con versiones anteriores, de modo que los usuarios que reciban la versión de la aplicación v2 no experimenten ningún cambio brusco. Para obtener más información, consulte Gestión de despliegues continuos para actualizar las apps.
Conmutación instantánea
También conocido como un despliegue de azul-verde, una conmutación instantánea requiere el doble de recursos informáticos para tener dos versiones de una app en ejecución a la vez. Con este enfoque, puede conmutar a los usuarios a la versión más reciente en tiempo real. Asegúrese de utilizar selectores de etiquetas de servicio (como version: green y version: blue) para asegurarse de que las solicitudes se envían a la versión correcta de la aplicación. Puede crear el nuevo despliegue version: green, esperar a que esté preparado y, a continuación, suprimir el despliegue version: blue. O bien, puede realizar una actualización continua, pero establecer el parámetro maxUnavailable en 0% y el parámetro maxSurge en 100%.
Despliegue de prueba o despliegue A/B
Una estrategia de actualización más compleja, un despliegue de prueba es cuando se elige un porcentaje de usuarios como, por ejemplo, el 5% y se les envía la nueva versión de la app. Se recopilan métricas en las herramientas de registro y supervisión sobre cómo se funciona la nueva versión de la app, se hacen pruebas A/B y, a continuación, se implanta la actualización a más usuarios. Al igual que con todos los despliegues, el etiquetado de la app (como por ejemplo version: stable y version: canary) es crítico.

¿Cómo puedo automatizar el despliegue de mi app?

Si desea ejecutar la app en varios clústeres, en entornos públicos y privados, o incluso en varios proveedores de nube, quizás se pregunte cómo puede hacer que su estrategia de despliegue funcione en estos entornos. Con IBM Cloud y otras herramientas de código abierto, puede empaquetar la aplicación para ayudar a automatizar los despliegues.

Configure un conducto de integración y entrega continuas (CI/CD)
Con los archivos de configuración de la app organizados en un sistema de gestión de control de origen como, por ejemplo, Git, puede crear el conducto para probar y desplegar código en distintos entornos, como test y prod. Trabaje con el administrador del clúster para configurar la integración y la entrega continua.
Empaquete los archivos de configuración de la app
Empaquete la app con herramientas como Kustomize o Helm.
  • Con el proyecto kustomize, puede escribir, personalizar y reutilizar sus configuraciones YAML de recursos de Kubernetes.
  • Con el Helm Kubernetes gestor de paquetes, puede especificar todos los recursos de Kubernetes que necesita su aplicación en un gráfico de Helm. A continuación, puede utilizar Helm para crear los archivos de configuración de YAML y desplegar estos archivos en el clúster. También puede integrar los gráficos Helm proporcionados por IBM Cloud para ampliar las capacidades de su clúster, como con un complemento de almacenamiento en bloque.

¿Quiere crear plantillas de archivo YAML? Algunas personas utilizan Helm para hacer precisamente eso, o puede probar otras herramientas comunitarias como ytt.

Configuración del descubrimiento de servicios

Cada uno de los pods de su clúster de Red Hat OpenShift tiene una dirección IP. Pero cuando despliega una app en el clúster, no desea depender de la dirección IP del pod para el descubrimiento de servicios y la red. Los pods se eliminan y se sustituyen con frecuencia y dinámicamente. En su lugar, utilice un servicio de Kubernetes, que representa un grupo de pods y proporciona un punto de entrada estable a través de la dirección IP virtual del servicio, denominado cluster IP. Para más información, consulte la documentación de Kubernetes sobre Servicios.

¿Cómo puedo asegurarme de que mis servicios están conectados a las implantaciones correctas y listos para funcionar?

Para la mayoría de los servicios, añada un selector al archivo de servicio .yaml de modo que se aplique a los pods que ejecutan las apps por esa etiqueta. Muchas veces, cuando tu aplicación arranca por primera vez, no quieres que procese las peticiones inmediatamente. Añada un sondeo de preparación a su despliegue de modo que el tráfico sólo se envíe a un pod que se considere que está preparado. Para ver un ejemplo de despliegue con un servicio que utiliza etiquetas y establece una sonda de preparación, echa un vistazo a este YAML de NGINX.

A veces, no desea que el servicio utilice una etiqueta. Por ejemplo, es posible que tenga una base de datos externa o que desee apuntar el servicio a otro servicio de un espacio de nombres diferente dentro del clúster. Cuando esto sucede, tiene que añadir manualmente un objeto de puntos finales y enlazarlo al servicio.

¿Cómo puedo exponer mis servicios en Internet?

Puede crear tres tipos de servicios para redes externas: NodePort, LoadBalancer e Ingress.

Tiene diversas opciones que dependen del tipo de clúster. Para obtener más información, consulte Planificación de servicios de red.

Al planificar cuántos objetos Service necesita en el clúster, tenga en cuenta que Kubernetes utiliza iptables para gestionar las reglas de red y de reenvío de puerto. Si ejecuta muchos servicios en el clúster, como por ejemplo 5000, el rendimiento puede verse afectado.

Protección de apps

Cuando planifique y desarrolle la app, tenga en cuenta las opciones siguientes para mantener una imagen segura, asegurarse de que la información confidencial está cifrada y controlar el tráfico entre los pods de la app y otros pods y servicios del clúster.

Seguridad de la imagen
Para proteger la app, debe proteger la imagen y establecer comprobaciones para garantizar la integridad de la imagen. Revise el tema sobre seguridad de registro y de imágenes para ver los pasos que puede seguir para asegurarse de proteger las imágenes del contenedor. Por ejemplo, podría usar Vulnerability Advisor para comprobar el estado de seguridad de las imágenes de contenedor. Cuando se añade una imagen al espacio de nombres de IBM Cloud Container Registry de la organización, Vulnerability Advisor escanea la imagen automáticamente para detectar problemas de seguridad y posibles vulnerabilidades. Si encuentra problemas de seguridad, se proporcionan instrucciones para poder arreglar el problema de vulnerabilidad notificado. Para empezar, consulte Gestión de la seguridad de imágenes con Vulnerability Advisor.
Secretos de Kubernetes
Cuando despliegue la app, no almacene información confidencial, como credenciales o claves, en el archivo de configuración de YAML, los mapas de configuración o los scripts. Utilice en su lugar secretos de Kubernetes, como por ejemplo un secreto de extracción de imágenes para las credenciales de registro. Luego puede hacer referencia a estos secretos en el archivo YAML de despliegue.
Cifrado de secretos
Puede cifrar los secretos de Kubernetes que cree en el clúster utilizando un proveedor de servicio de gestión de claves (KMS). Para empezar, consulte Cifrado de secretos mediante un proveedor de KMS y Verificación de que los secretos se han cifrado.
Gestión del tráfico de pods
Las Políticas de red de Kubernetes protegen los pods del tráfico de la red interna. Por ejemplo, si la mayoría de los pods, o todos ellos, no requieren acceso a pods o servicios específicos, y desea asegurarse de que los pods no puedan acceder a dichos pods o servicios de forma predeterminada, puede crear una política de red de Kubernetes para bloquear el tráfico de entrada a dichos pods o servicios. Las políticas de red de Kubernetes también pueden ayudarle a imponer el aislamiento de carga de trabajo entre espacios de nombres controlando la forma en que se pueden comunicar los pods y los servicios en distintos espacios de nombres. Para los clústeres que ejecutan Kubernetes 1.21 y posteriores, las señales de cuenta de servicio que utilizan los pods para comunicarse con el servidor de la API de Kubernetes tienen un límite de tiempo, se renuevan automáticamente, se circunscriben a un público concreto de usuarios (el pod) y se invalidan después de que se suprima el pod. Para continuar la comunicación con el servidor de API, debe diseñar sus apps para leer periódicamente, por ejemplo cada minuto. el valor de la señal renovada Para obtener más información, consulte Fichas de cuentas de servicio vinculadas.

Gestión del acceso y supervisión del estado de la app

Después de desplegar la app, puede controlar quién puede acceder a la app y supervisar el estado y el rendimiento de la app.

¿Cómo puedo controlar quién tiene acceso a mis implementaciones de apps?

Los administradores de cuentas y de clústeres pueden controlar el acceso a diferentes niveles: clúster, proyecto de Red Hat OpenShift, pod y contenedor.

Con IBM Cloud IAM, puede asignar permisos a usuarios individuales, grupos o cuentas de servicio a nivel de instancia de clúster. Puede limitar aún más el acceso al clúster restringiendo el acceso de los usuarios a determinados espacios de nombres del clúster. Para obtener más información, consulte Asignación de acceso a clúster.

Para controlar el acceso a nivel de pod, puede configurar restricciones de contexto de seguridad (SCC).

En el archivo YAML de despliegue de la app, puede definir el contexto de seguridad para un pod o un contenedor. Para más información, consulte la documentación de Kubernetes.

Después de desplegar mi app, ¿cómo puedo supervisar su estado?

Puede configurar el registro y la supervisión de su clúster en IBM Cloud.