Desplegar en Azure Kubernetes Service

Idioma: Español

Este artículo se ha traducido del inglés mediante IA y puede contener errores. Sus comentarios nos ayudarán a mejorar.

Esta guía le explica cómo desplegar el Servidor Autogestionado de ActivityInfo en Azure Kubernetes Service (AKS), respaldado por un disco gestionado Premium SSD v2. Está dirigida a profesionales de TI que estén familiarizados con Kubernetes y Microsoft Azure.

Utilice este despliegue cuando la latencia de red de un sistema de archivos compartido limite el rendimiento de la base de datos. Consulte Desplegar como una Web App de Azure para una opción más sencilla que utiliza Azure Files.

Antes de empezar

El Servidor Autogestionado de ActivityInfo almacena sus datos en una base de datos SQLite. Esto condiciona todo el despliegue:

Ejecutar una única réplica. El servidor está diseñado para escalar verticalmente, no horizontalmente: para soportar más usuarios concurrentes, dé al pod más núcleos de CPU y memoria en lugar de añadir réplicas.
Utilizar almacenamiento en bloque duradero. Un disco gestionado Premium SSD v2 ofrece una latencia cercana a la de un disco local con IOPS y rendimiento configurables. Al ser un disco gestionado conectado a la red, sus datos se replican en el backend de almacenamiento y sobreviven a la pérdida de un nodo: el disco se desvincula y se vuelve a vincular al nodo donde se reprograma el pod.

Este tutorial finaliza accediendo al servidor desde su propia máquina con reenvío de puertos. Poner el servidor a disposición de los usuarios a través de HTTPS se trata en los enlaces al final de esta guía.

Prerrequisitos

Instale la CLI de Azure y kubectl, y luego inicie sesión:

az login

Establecer variables

RESOURCE_GROUP=activityinfo-rg
LOCATION=westeurope
CLUSTER=activityinfo-aks

Crear un clúster

Cree un grupo de recursos y un clúster de AKS. El controlador CSI de Azure Disk, que aprovisiona los discos gestionados, se instala de forma predeterminada. Los discos Premium SSD v2 son zonales, por lo que el grupo de nodos debe ejecutarse en una zona de disponibilidad; --zones 1 lo sitúa en la zona 1. Un nodo es suficiente, ya que ActivityInfo se ejecuta como un único pod. Añada un segundo nodo en la misma zona si desea que el pod se reprograme antes durante un fallo o una actualización del nodo.

az group create --name $RESOURCE_GROUP --location $LOCATION

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER \
  --node-vm-size Standard_D4s_v5 \
  --node-count 1 \
  --zones 1 \
  --generate-ssh-keys

Conecte kubectl al nuevo clúster:

az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER

Crear una clase de almacenamiento

Las clases de almacenamiento incorporadas utilizan tipos de disco más antiguos. Defina una clase de almacenamiento para Premium SSD v2. Guarde lo siguiente en storageclass.yaml:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: activityinfo-premium-v2
provisioner: disk.csi.azure.com
parameters:
  skuName: PremiumV2_LRS
  cachingMode: None
  DiskIOPSReadWrite: "3000"
  DiskMBpsReadWrite: "125"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

WaitForFirstConsumer crea el disco en la misma zona que el pod que lo utiliza. reclaimPolicy: Retain conserva el disco si la reclamación se elimina alguna vez, para que la base de datos no se pierda por accidente. Aumente DiskIOPSReadWrite y DiskMBpsReadWrite por encima de la línea base gratuita de 3000 IOPS y 125 MB/s si su carga de trabajo necesita más. Aplíquelo:

kubectl apply -f storageclass.yaml

Desplegar ActivityInfo

Guarde lo siguiente en activityinfo.yaml. Define un StatefulSet de una sola réplica que solicita un disco Premium SSD v2 de la clase de almacenamiento y lo monta en /data. El fsGroup en el contexto de seguridad hace que el disco montado sea escribible por el contenedor, que se ejecuta como un usuario no root. Un Service expone el contenedor en el puerto 80 dentro del clúster.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: activityinfo
spec:
  serviceName: activityinfo
  replicas: 1
  selector:
    matchLabels:
      app: activityinfo
  template:
    metadata:
      labels:
        app: activityinfo
    spec:
      securityContext:
        fsGroup: 1000
      containers:
        - name: activityinfo
          image: activityinfo/activityinfo:5.0.0
          ports:
            - containerPort: 8081
          env:
            - name: ACTIVITYINFO_DATA_DATA_DIRECTORY
              value: /data
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: activityinfo-premium-v2
        resources:
          requests:
            storage: 100Gi
---
apiVersion: v1
kind: Service
metadata:
  name: activityinfo
spec:
  selector:
    app: activityinfo
  ports:
    - port: 80
      targetPort: 8081

Aplique el manifiesto:

kubectl apply -f activityinfo.yaml

Acceder al servidor

Espere a que el pod esté listo y, a continuación, reenvíe un puerto local al Service:

kubectl rollout status statefulset/activityinfo
kubectl port-forward service/activityinfo 8081:80

Mientras se ejecuta el comando, abra http://localhost:8081, donde se le pedirá que cree la primera cuenta de usuario administrador. Pulse Ctrl+C para detener el reenvío.

Exponer el servidor a Internet

El reenvío de puertos solo permite acceder al servidor desde su propia máquina. Para que ActivityInfo esté disponible para los usuarios, exponga el Service y sírvalo a través de HTTPS. ActivityInfo puede obtener y renovar su propio certificado a través de Let's Encrypt, o puede terminar TLS en un controlador de entrada (ingress). Los siguientes recursos describen las opciones:

Configuración SSL automatizada — Soporte Let's Encrypt integrado de ActivityInfo.
Modo proxy HTTPS — cuando TLS es terminado por un controlador de entrada (ingress) o un proxy inverso.
Usar un balanceador de carga público en AKS — exponer el servicio con una IP pública.
Ingress NGINX gestionado en AKS — el complemento de enrutamiento de aplicaciones.

Hacer copia de seguridad de la base de datos

El disco gestionado sobrevive a la pérdida de un nodo, pero no protege contra desastres, como un incendio en el centro de datos. Tome instantáneas de volumen del disco de forma regular, o copie el contenido de /data a un almacenamiento duradero como Azure Blob Storage de forma programada. Mantenga las copias de seguridad fuera del clúster para poder restaurarlas tras una pérdida total del clúster.

Próximos pasos

Siga la guía de Configuración para configurar la Entrega de correo electrónico y el Inicio de sesión único a través de la interfaz basada en la web.

Siguiente elemento

Otras plataformas