Volver

Despliega Microcks en OVHcloud Managed Kubernetes Service (MKS)

Aurélie Vache8 minutos de lectura
,
Despliega Microcks en OVHcloud Managed Kubernetes Service (MKS)

Tu servicio ya está disponible para pruebas, pero la API de la que depende no estará lista hasta dentro de tres semanas. ¿Te suena? Cuando desarrollas o pruebas una aplicación, es habitual que algunas de las API en las que se apoya todavía no existan, y eso puede ser frustrante.

Aquí es donde entra en juego la simulación de API (API mocking): te permite probar tus integraciones sin depender de que el backend esté terminado. Microcks responde a esta necesidad, y lo hace directamente desde tu clúster de Kubernetes.

En este post te enseñamos a desplegar Microcks en un clúster de OVHcloud Managed Kubernetes Service (MKS) y a exponerlo con Kubernetes Gateway API, Envoy Gateway y un Public Cloud Load Balancer de OVHcloud.

Como proyecto de la CNCF, Microcks encaja perfectamente entorno cloud native. Y dado que OVHcloud es miembro Platinum de la CNCF, ejecutar Microcks en MKS es una muy buena forma de integrar la simulación y las pruebas de API en tu plataforma de Kubernetes.

¿Qué es Microcks?

Logotipo de Microcks, la herramienta de código abierto para simulación y pruebas de API

Microcks es una herramienta de código abierto para la simulación y las pruebas de API.

Crea simulaciones de API a partir de especificaciones de API, para que puedas probar aplicaciones e integraciones sin necesidad de que el backend real esté disponible.

Esto es especialmente útil en entornos distribuidos, donde los equipos y los servicios evolucionan de forma independiente. Como Microcks se ejecuta en Kubernetes, se adapta sin problemas a cualquier entorno cloud native.

Requisitos

Antes de empezar, necesitarás:

  • una cuenta de OVHcloud;
  • un proyecto de OVHcloud Public Cloud
  • una credencial de API con los permisos necesarios para gestionar un clúster MKS;
  • la CLI de OVHcloud;
  • kubectl;
  • Helm;
  • un dominio (que apunte al Load Balancer, si quieres un dominio personalizado).

¡Empezamos!

Paso 1: crea el clúster MKS

Primero creas un clúster Managed Kubernetes Service de OVHcloud y un pool de nodos.

Para este ejemplo, utiliza un pool de tres nodos basado en el flavor b3-8.

Ten en cuenta que para un uso en producción, deberías considerar utilizar un plan standard en lugar del plan gratuito.

Crear el cluster

Define los parámetros de tu clúster:

bash
export CLUSTER_NAME="microcks"
export REGION="GRA9"
export PLAN="free"

Crea el clúster Kubernetes:

bash
CLUSTER_ID=$(ovhcloud cloud mks create --name $CLUSTER_NAME --region $REGION --plan $PLAN | grep -oE '[0-9a-f-]{36}')

Espera entre 2 y 3 minutos a que el clúster se aprovisione.

Comprueba el estado del clúster Kubernetes:

bash
ovhcloud cloud mks get $CLUSTER_ID

Crea el pool de nodos y conéctate al clúster

Microcks se compone de varias cargas de trabajo de Kubernetes, incluyendo la aplicación Microcks, Keycloak y su instancia de PostgreSQL, MongoDB y el runtime de Postman.

Para una instalación pequeña, un pool de nodos con tres nodos de propósito general es un buen punto de partida.

Una vez que el clúster se haya creado, puedes crear el pool de nodos. Define la configuración del pool de nodos:

bash
export NODEPOOL_NAME="microcks-np"
export NODE_FLAVOR="b3-8"

Crea el pool de nodos:

bash
NP_ID=$(ovhcloud cloud mks nodepool create $CLUSTER_ID --flavor-name $NODE_FLAVOR --name $NODEPOOL_NAME --desired-nodes 3 --min-nodes 2 --max-nodes 3 | grep -oE '[0-9a-f-]{36}')

Espera 3-4 minutos a que el grupo de nodos se aprovisione.

Comprueba el estado del grupo de nodos:

bash
ovhcloud cloud mks nodepool get $CLUSTER_ID $NP_ID

Una vez que el clúster y el grupo de nodos estén listos, genera la configuración de Kubernetes:

bash
ovhcloud cloud mks kubeconfig generate $CLUSTER_ID > microcks.yaml

Configura la CLI de kubectl con el kubeconfig generado:

bash
export KUBECONFIG=$(pwd)/microcks.yaml

Comprueba que los nodos estén listos:

bash
kubectl get np
kubectl get nodes

Tu clúster Kubernetes ya está listo. Ya puedes pasar a exponer Microcks.

Paso 2: expón el clúster con Gateway API

Gateway API, diseñado como el sucesor de Ingress, es el estándar de Kubernetes para enrutar tráfico hacia un clúster. Su función es describir qué quieres exponer; después, un controlador traduce esa descripción en un proxy en ejecución y, en MKS, en un OVHcloud Public Cloud Load Balancer.

Deberás utilizar tres componentes: Envoy Gateway, una implementación de Gateway API construida sobre el proxy Envoy; cert-manager, que automatiza los certificados TLS; y un recurso Gateway que los une.

Instala Envoy Gateway

Instala el chart de Helm de Envoy Gateway:

bash
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm -n envoy-gateway-system --create-namespace

Luego crea una GatewayClass que indique a Kubernetes que Envoy Gateway es responsable de tus recursos Gateway:

bash
cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
EOF

Gestiona certificados TLS con cert-manager

Para gestionar automáticamente tus certificados TLS, utilizarás cert-manager junto con Let's Encrypt.

Instala cert-manager:

bash
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set crds.enabled=true --set config.gatewayAPI.enabled=true

Luego crea un ClusterIssuer para Let's Encrypt:

bash
cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-microcks
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your-email@example.com>   # Update with your email address
    privateKeySecretRef:
      name: letsencrypt-prod-microcks
    solvers:
      - http01:
          gatewayHTTPRoute:
            parentRefs:
              - name: microcks-gateway
                namespace: microcks
                group: gateway.networking.k8s.io
                kind: Gateway
EOF

Este emisor permite a cert-manager solicitar certificados a Let's Encrypt utilizando el solver HTTP-01 de Gateway API.

Crea el Gateway

Ya puedes crear el Gateway que expondrá Microcks.

Crea el namespace:

bash
kubectl create namespace microcks

Luego crea el Gateway con sus cinco listeners: HTTP y HTTPS para Microcks, TLS passthrough para gRPC, y HTTP y HTTPS para Keycloak.

bash
cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: microcks-gateway
  namespace: microcks
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod-microcks
spec:
  gatewayClassName: envoy
  listeners:
    - name: microcks-http
      hostname: microcks.<YOUR_DOMAIN>.com
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
    - name: microcks-https
      hostname: microcks.<YOUR_DOMAIN>.com
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: microcks-tls
      allowedRoutes:
        namespaces:
          from: Same
    - name: microcks-grpc
      hostname: microcks-grpc.<YOUR_DOMAIN>.com
      protocol: TLS
      port: 443
      tls:
        mode: Passthrough
      allowedRoutes:
        namespaces:
          from: Same
    - name: keycloak-http
      hostname: keycloak.<YOUR_DOMAIN>.com
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
    - name: keycloak-https
      hostname: keycloak.<YOUR_DOMAIN>.com
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: keycloak-tls
      allowedRoutes:
        namespaces:
          from: Same
EOF

Comprueba el estado del Gateway:

bash
kubectl get gateway -n microcks
--- OUTPUT ---
NAME               CLASS   ADDRESS        PROGRAMMED   AGE
microcks-gateway   envoy   xx.xx.xx.xx    True         3m49s

En esta etapa, el Gateway debería aparecer como: Accepted=True y Programmed=True. Si aún no es el caso, espera unos minutos a que el Gateway se programe y a que el Load Balancer de OVHcloud Public Cloud se aprovisione.

Configura DNS

Obtén la dirección externa asignada al Gateway:

bash
export GATEWAY_IP=$(kubectl get gateway microcks-gateway \
  -n microcks \
  -o jsonpath='{.status.addresses[0].value}')
 
echo $GATEWAY_IP
--- OUTPUT ---
xx.xx.xx.xx

Si usas un dominio personalizado, crea los siguientes registros DNS:

bash
microcks.<YOUR_DOMAIN>.com       A    <GATEWAY_IP>
microcks-grpc.<YOUR_DOMAIN>.com  A    <GATEWAY_IP>
keycloak.<YOUR_DOMAIN>.com       A    <GATEWAY_IP>

Puedes configurar estos registros a través de la interfaz de gestión de DNS de OVHcloud:

Despliega Microcks

Una vez configurado el DNS, verifica los registros:

bash
dig keycloak.<YOUR_DOMAIN>.com +noall +answer
dig microcks.<YOUR_DOMAIN>.com +noall +answer
dig microcks-grpc.<YOUR_DOMAIN>.com +noall +answer

Paso 3: despliega y verifica Microcks

La infraestructura ya está lista. ¡Vamos a desplegar Microcks!

Despliega Microcks con Helm

Para ello, utiliza el chart de Helm oficial de Microcks, configurado para generar recursos HTTPRoute de Gateway API en vez de recursos Ingress de Kubernetes.

Añade el repositorio de Helm de Microcks:

bash
helm repo add microcks https://microcks.io/helm/
helm repo update

Crea un archivo microcks_values.yaml:

bash
cat > microcks_values.yaml <<EOF
appName: microcks
 
ingresses: false
gatewayRoutes: true
 
gatewayRefName: microcks-gateway
gatewayRefNamespace: microcks
gatewayRefSectionName: microcks-https
grpcGatewayRefSectionName: microcks-grpc
 
microcks:
  url: microcks.<YOUR_DOMAIN>.com
  ingressSecretRef: microcks-tls
  generateCert: false
  grpcEnableTLS: true
 
keycloak:
  url: keycloak.<YOUR_DOMAIN>.com
  privateUrl: http://microcks-keycloak.microcks.svc.cluster.local:8080
  ingressSecretRef: keycloak-tls
  generateCert: false
  gatewayRefName: microcks-gateway
  gatewayRefNamespace: microcks
  gatewayRefSectionName: keycloak-https
EOF

Instala Microcks:

bash
helm install microcks microcks/microcks -n microcks -f microcks_values.yaml

Verifica el despliegue

Comprueba los pods:

bash
kubectl get pods -n microcks
--- OUTPUT ---
NAME                                           READY   STATUS    RESTARTS       AGE
microcks-7f9f994fbc-jd7pb                      1/1     Running   0              19m
microcks-keycloak-5cf68c6b65-xjr6n             1/1     Running   3 (3m1s ago)   19m
microcks-keycloak-postgresql-6665b755f-zjdrl   1/1     Running   0              19m
microcks-mongodb-7ddff9f544-8rdcx              1/1     Running   0              19m
microcks-postman-runtime-5699859b86-58mr7      1/1     Running   0              19m

Espera hasta que todos los pods estén en estado Running y los contenedores estén listos.

También puedes comprobar las rutas de la Gateway API:

bash
kubectl get httproute -n microcks
--- OUTPUT ---
NAME                HOSTNAMES                          AGE
microcks            ["microcks.<YOUR_DOMAIN>.com"]     3m34s
microcks-keycloak   ["keycloak.<YOUR_DOMAIN>.com"]     3m34s

Las rutas deberían hacer referencia a los nombres de host de Microcks y Keycloak configurados anteriormente.

En este punto, Microcks debería ser accesible a través de:

bash
https://microcks.<YOUR_DOMAIN>.com
https://microcks-grpc.<YOUR_DOMAIN>.com
https://keycloak.<YOUR_DOMAIN>.com

Ahora Microcks está en marcha en tu clúster de OVHcloud Managed Kubernetes Service, expuesto a través de Gateway API y protegido con certificados TLS que gestiona cert-manager.

Conclusión y próximos pasos

En este artículo has visto cómo desplegar Microcks en un clúster de OVHcloud Managed Kubernetes Service y cómo exponerlo con Envoy Gateway (como implementación de Kubernetes Gateway API) y un OVHcloud Public Cloud Load Balancer, con certificados TLS gestionados mediante cert-manager y Let's Encrypt.

Ya lo tienes todo listo para crear mocks de tus API y probarlas desde tu propio clúster de MKS.

En un entorno de producción, otra opción sería utilizar OVHcloud Managed Databases para PostgreSQL y MongoDB, en lugar de ejecutar estos componentes de base de datos directamente en el clúster de Kubernetes. Así, separas la plataforma de aplicaciones de la infraestructura de bases de datos y aprovechas las ventajas de los servicios de bases de datos gestionadas.

¿Te animas a probarlo? Crea tu primer clúster de Managed Kubernetes y despliega Microcks en menos de 30 minutos. Para seguir las últimas novedades de los productos de OVHcloud Public Cloud, echa un vistazo a la Cloud Roadmap & Changelog.

Compartir en: