Editar

Compartir vía


Creación de proyectos de CNCF mediante Azure Kubernetes Service

Azure Kubernetes Service (AKS)

En este artículo se muestra cómo conceptualizar, diseñar, crear e implementar una aplicación que usa proyectos de Cloud Native Computing Foundation (CNCF) después de implementar Azure Kubernetes Service (AKS). La arquitectura describe la aplicación de proyectos de CNCF en GitHub. Las instrucciones de instalación del repositorio proporcionan los pasos para implementar la arquitectura.

Arquitectura

Diagrama de arquitectura en el que se muestra la arquitectura de referencia para crear un proyecto de CNCF.

Descargue un archivo de Visio de esta arquitectura.

La carga de trabajo es una aplicación web sencilla que los empleados pueden usar para enviar y ver los informes de gastos. Cuando un empleado envía un informe de gastos, el administrador del empleado recibe un correo electrónico.

Flujo de trabajo

Flujo de la aplicación

1. El empleado accede a una aplicación web a través de la entrada NGINX para enviar los gastos.

2. La aplicación web llama a una aplicación de API para recuperar al administrador del empleado.

3. La aplicación web inserta un mensaje que se genera para la creación del informe de gastos en un agente Knative.

4. El informe de gastos se guarda en MySQL.

5. Knative desencadena la función de distribución de correo electrónico con el mensaje de gastos como carga útil.

6. El distribuidor del correo electrónico crea un mensaje SendGrid.

7. SendGrid envía un correo electrónico al administrador recuperado para su revisión.

Flujo de DevOps

a. Los desarrolladores escriben o actualizan el código en Visual Studio Code.

b. Los desarrolladores insertan el código en GitHub desde su área de trabajo local en Visual Studio Code.

c. GitHub Webhook desencadena canalizaciones de Tekton que clonan el código de GitHub.

d. Las canalizaciones compilan e insertan imágenes de contenedores en un registro de Harbor.

e. Tekton implementa la aplicación web, la aplicación de API y las aplicaciones de distribución del correo electrónico.

f. Prometheus captura las métricas de la aplicación.

g. Los ingenieros supervisan las métricas en un panel de Grafana.

h. Los ingenieros de DevOps supervisan el panel de Grafana.

Infraestructura

i. Clúster de AKS basado en la infraestructura presentada en la línea base de AKS.

ii. Rook Ceph usado para el almacenamiento del clúster.

iii. Malla de servicio de Linkerd.

iv. Jaeger para el seguimiento general de aplicaciones en el clúster de Kubernetes.

Operaciones del clúster

Puede que sea ventajoso administrar los clústeres y su arranque mediante la administración de GitOps. Flux es un operador de GitOps conocido. A menudo se empareja con Acciones de GitHub para permitir la validación en manifiestos actualizados y gráficos de Helm.

Componentes

Azure

Software de código abierto

  • Kubernetes. CNCF. Automatiza la implementación, el escalado y la administración de aplicaciones contenedorizadas.
  • Flux. CNCF. Proveedor de GitOps para la entrega de infraestructura.
  • Rook. CNCF. Proporciona administración de almacenamiento para los clústeres.
  • Harbor. CNCF. Registro de contenedor para las imágenes.
  • Linkerd. CNCF. Malla de servicio que se integra con OpenFaaS, NGINX, Prometheus y Jaeger.
  • Prometheus. CNCF. Captura las métricas de la aplicación.
  • Jaeger. CNCF. Proporciona seguimiento general de aplicaciones en el clúster de Kubernetes.
  • Knative. CNCF. Se usa para compilar aplicaciones sin servidor y controladas por eventos. Implementa la función de distribución del correo electrónico.
  • MySQL. Base de datos que almacena los informes de gastos.
  • NGINX. Controlador de entrada de Kubernetes que los empleados usan para acceder a la aplicación web para enviar informes de gastos.
  • Tekton. Proyecto de Continuous Delivery Foundation que se usa para la integración continua o la implementación continua (CI/CD). Implementa la aplicación web, la aplicación de API y las aplicaciones de distribución del correo electrónico.
  • Grafana. Panel de métricas de aplicación.
  • SendGrid. Servicio de correo electrónico externo que envía correo al administrador para la revisión del informe de gastos.
  • GitHub. Repositorio de código. Las canalizaciones de Tekton usan código de GitHub.
  • .NET Core. Se usa para el front-end web y la API web.
  • Flux. Proporciona administración de GitOps.

Alternativas

Este proyecto utiliza proyectos graduados e incubados del CNCF. Podría haber varias alternativas para los servicios usados. Para conocerlas, consulte el sitio web de CNCF. Estos son algunos recursos que describen algunas de ellas:

Puede considerar varios servicios de Azure como alternativas. Por ejemplo, Enrutamiento de aplicaciones web, Registro de contenedor de Azure, Azure Container Storage, Azure Monitor, servicio administrado de Azure Monitor para Prometheus, Azure Managed Grafana.

Microsoft también admite proyectos de software de código abierto como complementos administrados o proyectos derivados en AKS, incluidos NGINX, Istio, Prometheus, Grafana y OpenEBS.

Detalles del escenario

Puede implementar esta arquitectura en cualquier clúster de Kubernetes, no solo en AKS. Proporciona un ejemplo de la flexibilidad de la plataforma AKS. AKS simplifica la implementación en Azure de clústeres de Kubernetes administrado.

Después de revisar este artículo, tendrá una buena comprensión de cómo implementar una aplicación típica que conste principalmente de proyectos de CNCF.

Posibles casos de uso

Estos otros casos de usos tienen patrones de diseño similares:

  • Creación de una canalización de CI/CD para cargas de trabajo basadas en contenedores
  • Uso de GitOps para AKS

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

  • Para el clúster de Kubernetes, necesita al menos un grupo de nodos de usuario de 3 nodos con una SKU de máquina virtual (VM) DS2_v2 o mayor.
  • Los volúmenes que usan discos administrados de Azure no se pueden conectar entre zonas. Deben estar ubicados en la misma zona.
  • La instalación de Rook puede tardar entre 20 y 25 minutos. Asegúrese de que el clúster de Ceph esté completamente aprovisionado antes de pasar al paso siguiente.
  • La configuración de Jaeger tarda aproximadamente 5 minutos.
  • Linkerd tarda aproximadamente 12 minutos en aparecer en el panel.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Puede usar la calculadora de precios de Azure para calcular los costos. A continuación se proporcionan algunas consideraciones de precios para ejecutar este proyecto en Azure. Se aplica un costo de ancho de banda insignificante.

Virtual Machine Scale Sets

Las máquinas virtuales que se usan en los conjuntos de escalado de máquinas virtuales de Azure para el clúster de AKS tienen un costo. Para más información, consulte Precios de conjuntos de escalado de máquinas virtuales Linux.

Storage

Los costos de almacenamiento se aplican a cada disco de datos que se necesita para la instalación de Rook. En este clúster de AKS de 3 nodos, la configuración de Rook usa dos discos de datos por nodo: un disco de 1 GB y un disco de 200 GB. Para más información, consulte Precios de Managed Disks.

Equilibrador de carga

El equilibrador de carga asociado a este clúster de AKS tiene un costo. Para más información, consulte los precios de Azure Load Balancer.

Virtual network

La red virtual que usa el clúster de AKS tiene un costo. Para más información, consulte Precios de redes virtuales.

Implementación de este escenario

Implemente este escenario desde el repositorio Azure/cloud-native-app de GitHub. Siga las instrucciones de configuración de la secuencia proporcionada para implementar la aplicación de proyectos de CNCF en su entorno.

Este repositorio es un proyecto de la comunidad. Acepta y aprueba solicitudes de incorporación de cambios (PR) de mejoras y modificaciones de la comunidad.

Pasos siguientes