Compartir a través de


Tutorial: Migración de Oracle WebLogic Server a Azure Kubernetes Service (AKS) con el escalador KEDA basado en métricas de Prometheus

En este tutorial se muestra cómo migrar Oracle WebLogic Server (WLS) a Azure Kubernetes Service (AKS) y a configurar el escalado horizontal automático basado en métricas de Prometheus.

En este tutorial, realizará las siguientes tareas:

  • Obtener información sobre las métricas de la aplicación WebLogic que puede exportar mediante WebLogic Monitoring Exporter.
  • Implementar y ejecutar una aplicación WebLogic en AKS mediante una oferta de Azure Marketplace.
  • Habilitar el servicio administrado de Azure Monitor para Prometheus mediante una oferta de Azure Marketplace.
  • Proporcionar métricas de WLS a un área de trabajo de Azure Monitor mediante una oferta de Azure Marketplace.
  • Integrar el escalado automático controlado por eventos (KEDA) de Kubernetes con un clúster de AKS mediante una oferta de Azure Marketplace.
  • Crear un escalador de KEDA basado en métricas de Prometheus.
  • Validar la configuración del escalador.

En el diagrama siguiente se muestra la arquitectura que ha creado:

Diagrama de la arquitectura de la solución de WLS en AKS con el escalador KEDA basado en métricas de Prometheus.

La oferta de Oracle WebLogic Server en AKS ejecuta un operador WLS y un dominio de WLS en AKS. El operador WLS administra un dominio de WLS implementado mediante un tipo de origen de dominio de modelo en imagen. Para obtener más información sobre el operador WLS, consulte Operador de Kubernetes de Oracle WebLogic.

WebLogic Monitoring Exporter extrae las métricas de WebLogic Server y las alimenta en Prometheus. El exportador usa la interfaz de administración RESTful de WebLogic Server 12.2.1.x para acceder al estado y las métricas del entorno de ejecución.

El servicio administrado de Azure Monitor para Prometheus recopila y guarda métricas de WLS a escala mediante una solución de supervisión compatible con Prometheus, basada en el proyecto Prometheus de Cloud Native Compute Foundation. Para más información, vea el servicio administrado de Azure Monitor para Prometheus.

En este artículo se integra KEDA con el clúster de AKS para escalar el clúster de WLS en función de las métricas de Prometheus del área de trabajo de Azure Monitor. KEDA supervisa el servicio administrado de Azure Monitor para Prometheus y alimenta los datos a AKS y al Horizontal Pod Autoscaler (HPA) para impulsar el escalado rápido de la carga de trabajo de WLS.

El siguiente estado y métricas de WLS se exportan de forma predeterminada. Puede configurar el exportador para exportar otras métricas a petición. Para obtener una descripción detallada de la configuración y el uso de WebLogic Monitoring Exporter, consulte WebLogic Monitoring Exporter.

Métricas de WebLogic.

Requisitos previos

  • Suscripción a Azure. Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
  • Asegúrese de que se le ha asignado el rol Owner o los roles Contributor y User Access Administrator en la suscripción. Para comprobar la asignación, siga los pasos descritos en Enumeración de asignaciones de roles de Azure mediante Azure Portal.
  • Prepare una máquina local con Windows con WSL, GNU/Linux o macOS instalados.
  • Instale la versión 2.54.0 o posterior de la CLI de Azure para ejecutar comandos de la CLI de Azure.
  • Instale y configure kubectl.
  • Instale cURL.
  • Tenga las credenciales de una cuenta de inicio de sesión único (SSO) de Oracle. Para crear una, consulte Crear una cuenta de Oracle.
  • Siga estos pasos para aceptar los términos de licencia de WLS:
    1. Visite Oracle Container Registry e inicie sesión.
    2. Si tiene un derecho de soporte técnico, seleccione Middleware y, a continuación, busque y seleccione weblogic_cpu.
    3. Si no tiene un derecho de soporte técnico para Oracle, seleccione Middleware y, a continuación, busque y seleccione weblogic.
    4. Acepta el acuerdo de licencia.

Preparación de la aplicación de ejemplo

En este artículo se usa testwebapp del repositorio weblogic-kubernetes-operator como una aplicación de ejemplo.

Use los comandos siguientes para descargar la aplicación de ejemplo precompilada y expandirla en un directorio. Dado que en este artículo se escriben varios archivos, estos comandos crean un directorio de nivel superior para contener todo.

export BASE_DIR=$PWD/wlsaks
mkdir $BASE_DIR && cd $BASE_DIR
curl -L -o testwebapp.war https://aka.ms/wls-aks-testwebapp
unzip -d testwebapp testwebapp.war

Modificación de la aplicación de ejemplo

En este artículo se usa la métrica openSessionsCurrentCount para escalar y reducir verticalmente el clúster de WLS. De forma predeterminada, el tiempo de espera de sesión en WebLogic Server es de 60 minutos. Para observar rápidamente la funcionalidad de reducción vertical, siga estos pasos para establecer un breve tiempo de espera:

  1. Use el comando siguiente para especificar un tiempo de espera de sesión de 150 segundos mediante wls:timeout-secs. El formato HEREDOC se usa para sobrescribir el archivo en testwebapp/WEB-INF/weblogic.xml con el contenido deseado.

    cat <<EOF > testwebapp/WEB-INF/weblogic.xml
    <?xml version="1.0" encoding="UTF-8"?>
    
    <wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
        <wls:weblogic-version>12.2.1</wls:weblogic-version>
        <wls:jsp-descriptor>
        <wls:keepgenerated>false</wls:keepgenerated>
        <wls:debug>false</wls:debug>
      </wls:jsp-descriptor>
      <wls:context-root>testwebapp</wls:context-root>
      <wls:session-descriptor>
        <wls:timeout-secs>150</wls:timeout-secs>
     </wls:session-descriptor>
    </wls:weblogic-web-app>
    EOF
    
  2. Use el siguiente comando para volver a comprimir la aplicación:

    cd testwebapp && zip -r ../testwebapp.war * && cd ..
    

Creación de una cuenta de Azure Storage y carga de la aplicación

Siga estos pasos para crear una cuenta de almacenamiento y un contenedor. Algunos de estos pasos le dirigen a otras guías. Después de completar los pasos, puede cargar una aplicación de ejemplo para implementarla en WLS.

  1. Inicie sesión en Azure Portal.
  2. Cree una cuenta de almacenamiento siguiendo los pasos descritos en Crear una cuenta de almacenamiento. Use las especializaciones siguientes para los valores del artículo:
    • Cree un nuevo grupo de recursos para la cuenta de almacenamiento.
    • En Región, seleccione Este de EE. UU. .
    • En Nombre de cuenta de almacenamiento, use el mismo valor que el nombre del grupo de recursos.
    • En Rendimiento, seleccione Estándar.
    • Las pestañas restantes no necesitan especializaciones.
  3. Continúe con la validación y creación de la cuenta, y vuelva a este artículo.
  4. Cree un contenedor de almacenamiento dentro de la cuenta siguiendo los pasos descritos en la sección Creación de un contenedor de Inicio rápido: Carga, descarga y enumeración de blobs con Azure Portal.
  5. En el mismo artículo, siga los pasos descritos en la sección Carga de un blob en bloques para cargar el archivo testwebapp.war. Después, regrese a este artículo.

Implementación de WLS en AKS mediante la oferta de Azure Marketplace

En esta sección, creará un clúster de WLS en AKS mediante la oferta Oracle WebLogic Server en AKS. La oferta proporciona un conjunto de características completo para implementar fácilmente WebLogic Server en AKS. Este artículo se centra en las funcionalidades avanzadas de escalado dinámico de la oferta. Para obtener más información sobre la oferta, consulte Implementación de una aplicación Java con WebLogic Server en un clúster de Azure Kubernetes Service (AKS). Para obtener la documentación de referencia completa de la oferta, consulte la documentación de Oracle.

Esta oferta implementa las siguientes opciones para el escalado automático horizontal:

  • Servidor de métricas de Kubernetes. Esta opción configura todos los ajustes necesarios en el momento de la implementación. Un escalador automático de pods horizontal (HPA) se implementa con una selección de métricas. Puede personalizar aún más HPA después de la implementación.

  • WebLogic Monitoring Exporter. Esta opción aprovisiona automáticamente WebLogic Monitoring Exporter, el servicio administrado de Azure Monitor para Prometheus y KEDA. Una vez completada la implementación de la oferta, las métricas de WLS se exportan y guardan en el área de trabajo de Azure Monitor. KEDA se instala con la capacidad de recuperar métricas del área de trabajo de Azure Monitor.

    Con esta opción, debe realizar más pasos después de la implementación para completar la configuración.

En este artículo se describe la segunda opción. Siga estos pasos para completar la configuración.

  1. Abra la oferta Oracle WebLogic Server en AKS en el explorador y seleccione Crear. Debería ver el panel Aspectos básicos de la oferta.

  2. Siga estos pasos para rellenar el panel Aspectos básicos:

    1. Asegúrese de que el valor que se muestra para Suscripción es el mismo que tiene los roles enumerados en la sección de requisitos previos.
    2. Debe implementar la oferta en un grupo de recursos vacío. En el campo Grupo de recursos, seleccione Crear nuevo y rellene un valor único diferente para el grupo de recursos, por ejemplo, wlsaks-eastus-20240109.
    3. En Detalles de la instancia, en Región, seleccione Este de EE. UU.
    4. En Credenciales WebLogic, indique una contraseña para el administrador de WebLogic y el cifrado del modelo de WebLogic, respectivamente. Guarde el nombre de usuario y la contraseña del administrador de WebLogic.
    5. Junto a Configuración básica opcional, seleccione No.
    6. En Configuración básica opcional, establezca Tamaño máximo de clúster dinámico en 10. Este valor le permite observar el comportamiento de escalado automático.

    Captura de pantalla de Azure Portal que muestra el panel Aspectos básicos de Oracle WebLogic Server en AKS.

  3. Seleccione Siguiente y vaya a la pestaña AKS.

  4. En Selección de imágenes, siga estos pasos:

    1. En Nombre de usuario para la autenticación de inicio de sesión único de Oracle, rellene el nombre de usuario de SSO de Oracle a partir de los requisitos previos.
    2. En Contraseña para la autenticación de inicio de sesión único de Oracle, rellene las credenciales de SSO de Oracle a partir de los requisitos previos.

    Captura de pantalla de Azure Portal que muestra el panel Oracle WebLogic Server en AKS - Selección de imagen.

  5. En Aplicación, siga estos pasos:

    1. En la sección Aplicación, junto a ¿Implementar una aplicación?, seleccione Sí.

    2. Junto a Paquete de aplicación (.war, .ear, .jar), seleccione Examinar.

    3. Empiece a escribir el nombre de la cuenta de almacenamiento de la sección anterior. Cuando aparezca la cuenta de almacenamiento deseada, selecciónela.

    4. Seleccione el contenedor de almacenamiento de la sección anterior.

    5. Active la casilla situada junto a testwebapp.war, que cargó en la sección anterior. Elija Seleccionar.

    6. Seleccione Siguiente.

      Captura de pantalla de Azure Portal que muestra el panel Oracle WebLogic Server en AKS - Selección de aplicación.

  6. Deje los valores predeterminados en el panel Configuración de TLS/SSL. Seleccione Siguiente para ir al panel Equilibrio de carga y, a continuación, siga estos pasos:

    1. Deje los valores predeterminados para todas las opciones, excepto Crear entrada para la consola de administración. Asegúrese de que ninguna aplicación con la ruta de acceso /console* provocará un conflicto con la ruta de acceso de la consola de administración. Para esta opción, seleccione .
    2. En los campos restantes, deje los valores predeterminados.
    3. Seleccione Siguiente.

    Captura de pantalla de Azure Portal que muestra el clúster de Oracle WebLogic Server en AKS, panel Equilibrio de carga.

  7. Deje los valores predeterminados en el panel DNS y seleccione Siguiente para ir al panel Base de datos.

  8. Deje los valores predeterminados en el panel Base de datos, seleccione Siguiente para ir al panel Escalado automático y, a continuación, siga estos pasos:

    1. Junto a ¿Aprovisionar recursos para el escalado automático horizontal? seleccione .
    2. En Configuración de escalado automático horizontal, junto a Seleccione una opción de escalado automático., seleccione WebLogic Monitor Exporter (escalado automático avanzado).
    3. Seleccione Revisar + crear.

    Captura de pantalla de Azure Portal que muestra el clúster de Oracle WebLogic Server en el panel Escalado automático horizontal de AKS.

  9. Espere hasta que se complete correctamente el proceso Ejecutando validación final... y, a continuación, seleccione Crear. Después de un tiempo, debería ver la página Implementación donde se muestra Implementación en curso.

Si ve algún problema durante el proceso Ejecutando validación final..., corríjalo e inténtelo de nuevo.

Conexión al clúster de AKS

Las secciones siguientes requieren un terminal con kubectl instalado para administrar el clúster de WLS. Para instalar kubectl localmente, use el comando az aks install-cli.

Siga los pasos que se indican a continuación para conectarse al clúster de AKS:

  1. Abra Azure Portal y vaya al grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.
  2. Seleccione el recurso de tipo Kubernetes Service en la lista de recursos.
  3. Seleccione Conectar. Aparece una guía para conectarse al clúster de AKS.
  4. Seleccione la CLI de Azure y siga los pasos para conectarse al clúster de AKS en el terminal local.

Recuperación de métricas del área de trabajo de Azure Monitor

Siga estos pasos para ver las métricas en el área de trabajo de Azure Monitor mediante consultas del lenguaje de consulta Prometheus (PromQL):

  1. En Azure Portal, consulte el grupo de recursos que usó en la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.

  2. Seleccione el recurso de tipo área de trabajo de Azure Monitor.

  3. En Prometheus administrado, seleccione Explorador de Prometheus.

  4. Introduzca webapp_config_open_sessions_current_count para consultar la cuenta actual de sesiones abiertas, como se muestra en la captura de pantalla siguiente:

    Captura de pantalla de Azure Portal, donde se muestra el Explorador de Prometheus.

Nota:

Puede usar el siguiente comando para acceder a las métricas mediante la exposición de WebLogic Monitoring Exporter:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: sample-domain1-cluster-1-exporter
  namespace: sample-domain1-ns
spec:
  ports:
  - name: default
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    weblogic.domainUID: sample-domain1
    weblogic.clusterName: cluster-1
  sessionAffinity: None
  type: LoadBalancer
EOF

kubectl get svc -n sample-domain1-ns -w

Espere a que la columna EXTERNAL-IP de la fila de sample-domain1-cluster-1-exporter cambie de <pending> a una dirección IP. A continuación, abra la dirección URL http://<exporter-public-ip>:8080/metrics en un explorador e inicie sesión con las credenciales que especificó al implementar la oferta. Aquí puede encontrar todas las métricas disponibles. Puede escribir cualquiera de estos elementos en la ventana PromQL para mostrarlos en Azure Monitor. Por ejemplo, heap_free_percent muestra un gráfico interesante. Para ver la presión de memoria a medida que se aplica la carga a la aplicación, establezca Actualización automática e Intervalo de tiempo con el intervalo más pequeño posible y deje abierta la pestaña.

Creación del escalador KEDA

Los escaladores definen cómo y cuándo KEDA debe escalar una implementación. En este artículo se usa el escalador de Prometheus para recuperar las métricas de Prometheus del área de trabajo de Azure Monitor.

En este artículo se usa openSessionsCurrentCount como desencadenador. La regla de esta métrica se describe de la manera siguiente. Cuando el recuento medio de sesiones abiertas es superior a 10, escale verticalmente el clúster de WLS hasta que alcance el tamaño máximo de réplica. De lo contrario, reduzca verticalmente el clúster de WLS hasta que alcance su tamaño mínimo de réplica. En la tabla siguiente se enumeran los parámetros importantes:

Nombre del parámetro Valor
serverAddress Punto de conexión de consulta del área de trabajo de Azure Monitor.
metricName webapp_config_open_sessions_current_count
query sum(webapp_config_open_sessions_current_count{app="app1"})
threshold 10
minReplicaCount 1
maxReplicaCount El valor predeterminado es 5. Si modificó el tamaño máximo del clúster durante la implementación de la oferta, reemplácelo por el tamaño máximo del clúster.

Dado que seleccionó WebLogic Monitoring Exporter en el momento de la implementación, un escalador KEDA está listo para implementarse. En los pasos siguientes se muestra cómo configurar el escalador KEDA para su uso con el clúster de AKS:

  1. Abra Azure Portal y vaya al grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.

  2. En el panel de navegación, en la sección Configuración, seleccione Implementaciones. Verá una lista ordenada de las implementaciones en este grupo de recursos, con la más reciente primero.

  3. Desplácese hasta la entrada más antigua de esta lista. Esta entrada corresponde a la implementación que inició en la sección anterior. Seleccione la implementación más antigua, cuyo nombre comienza con algo similar a oracle.20210620-wls-on-aks.

  4. Seleccione Salidas. Esta opción muestra la lista de salidas de la implementación.

  5. El valor kedaScalerServerAddress es la dirección del servidor que guarda las métricas de WLS. KEDA puede acceder a las métricas de la dirección y recuperarlas.

  6. El valor shellCmdtoOutputKedaScalerSample es la cadena base64 de un ejemplo de escalador. Copie el valor y ejecútelo en el terminal. El comando debería tener un aspecto similar al ejemplo siguiente:

    echo -e YXBpVm...XV0aAo= | base64 -d > scaler.yaml
    

    Este comando genera un archivo scaler.yaml en el directorio actual.

  7. Modifique las líneas metric: y query: en scaler.yaml, como se muestra en el ejemplo siguiente:

    metricName: webapp_config_open_sessions_current_count
    query: sum(webapp_config_open_sessions_current_count{app="app1"})
    

    Nota:

    Al implementar una aplicación con la oferta, se denomina app1 de forma predeterminada. Puede seguir estos pasos para acceder a la consola de administración de WLS para obtener el nombre de la aplicación:

    1. Siga los pasos anteriores para ver las salidas de implementación.
    2. El valor adminConsoleExternalUrl es el vínculo completo y visible de Internet público a la consola de administración de WLS. Seleccione el icono para copiar junto al valor de campo para copiar el vínculo en el Portapapeles.
    3. Pegue el valor en el explorador y abra la consola de administración de WLS.
    4. Inicie sesión con la cuenta de administrador de WLS, que guardó durante la sección Implementación de WLS en AKS mediante la oferta de Azure Marketplace.
    5. En Estructura de dominio, seleccione Implementaciones. Encontrará app1 en la lista.
    6. Seleccione app1 para buscar que el valor de Nombre de la aplicación sea app1. Use app1 como nombre de aplicación en la consulta.
  8. Si lo desea, modifique la línea maxReplicaCount: en scaler.yaml como se muestra en el ejemplo siguiente. Es un error establecer este valor superior al especificado en el momento de la implementación en la pestaña AKS.

    maxReplicaCount: 10
    
  9. Use el siguiente comando para crear la regla de escalador KEDA aplicando scaler.yaml:

    kubectl apply -f scaler.yaml
    

    KEDA tarda varios minutos en recuperar las métricas del área de trabajo de Azure Monitor. Puede ver el estado del escalador mediante el siguiente comando:

    kubectl get hpa -n sample-domain1-ns -w
    

    Una vez que el escalador esté listo para funcionar, la salida será similar al siguiente contenido. El valor de la columna TARGETS cambia de <unknown> a 0.

    NAME                                       REFERENCE                          TARGETS              MINPODS   MAXPODS   REPLICAS   AGE
    keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)           1         5         2          15s
    

Prueba del escalado automático

Ahora, está listo para observar la funcionalidad de escalado automático. En este artículo se abren nuevas sesiones con curl para acceder a la aplicación. Cuando el recuento medio de sesiones sea mayor que 10, se produce la acción de escalado vertical. Las sesiones duran 150 segundos y el recuento de sesiones abiertas disminuye a medida que expiran las sesiones. Cuando el recuento medio de sesiones sea inferior a 10, se produce la acción de reducción vertical. Siga estos pasos para realizar las acciones de escalado y reducción vertical:

  1. Siga estos pasos para obtener la URL de la aplicación:

    1. Siga los pasos anteriores para ver las salidas de implementación.
    2. El valor clusterExternalUrl es el vínculo completo y visible de Internet público a la aplicación de ejemplo implementada en WLS en este clúster de AKS. Para copiar el vínculo en el portapapeles, seleccione el icono de copia situado junto al valor del campo.
    3. La dirección URL para acceder a testwebapp.war es ${clusterExternalUrl}testwebapp, por ejemplo, http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/testwebapp/.
  2. Ejecute el comando curl para acceder a la aplicación y provocar nuevas sesiones. En el ejemplo siguiente se abren 22 nuevas sesiones. Las sesiones expiran después de 150 segundos. Reemplace el valor de WLS_CLUSTER_EXTERNAL_URL por el suyo.

    COUNTER=0
    MAXCURL=22
    WLS_CLUSTER_EXTERNAL_URL="http://wlsgw202403-wlsaks0314-domain1.eastus.cloudapp.azure.com/"
    APP_URL="${WLS_CLUSTER_EXTERNAL_URL}testwebapp/"
    
    while [ $COUNTER -lt $MAXCURL ]; do curl ${APP_URL}; let COUNTER=COUNTER+1; sleep 1;done
    
  3. En dos shells independientes, use los siguientes comandos:

    • Utilice el comando siguiente para observar el escalador:

      kubectl get hpa -n sample-domain1-ns -w
      

      Esto genera una salida similar a la del siguiente ejemplo:

      $ kubectl get hpa -n sample-domain1-ns -w
      NAME                                       REFERENCE                          TARGETS          MINPODS   MAXPODS   REPLICAS   AGE
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         1         24m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         1         24m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   5/10 (avg)       1         10         1         26m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   22/10 (avg)      1         10         1         27m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   7334m/10 (avg)   1         10         3         29m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   14667m/10 (avg)  1         10         3         48m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         3         30m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         3         35m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         1         35m
      keda-hpa-azure-managed-prometheus-scaler   Cluster/sample-domain1-cluster-1   0/10 (avg)       1         10         5         53m
      
    • En un shell independiente, use el siguiente comando para observar los pods de WLS:

      kubectl get pod -n sample-domain1-ns -w
      

      Esto genera una salida similar a la del siguiente ejemplo:

      $ kubectl get pod -n sample-domain1-ns -w
      NAME                             READY   STATUS              RESTARTS   AGE
      sample-domain1-admin-server      2/2     Running             0          28h
      sample-domain1-managed-server1   2/2     Running             0          28h
      sample-domain1-managed-server1   2/2     Running             0          28h
      sample-domain1-managed-server2   0/2     Pending             0          0s
      sample-domain1-managed-server2   0/2     Pending             0          0s
      sample-domain1-managed-server2   0/2     ContainerCreating   0          0s
      sample-domain1-managed-server3   0/2     Pending             0          0s
      sample-domain1-managed-server3   0/2     Pending             0          0s
      sample-domain1-managed-server3   0/2     ContainerCreating   0          0s
      sample-domain1-managed-server3   1/2     Running             0          1s
      sample-domain1-admin-server      2/2     Running             0          95m
      sample-domain1-managed-server1   2/2     Running             0          94m
      sample-domain1-managed-server2   2/2     Running             0          56s
      sample-domain1-managed-server3   2/2     Running             0          55s
      sample-domain1-managed-server4   1/2     Running             0          9s
      sample-domain1-managed-server5   1/2     Running             0          9s
      sample-domain1-managed-server5   2/2     Running             0          37s
      sample-domain1-managed-server4   2/2     Running             0          42s
      sample-domain1-managed-server5   1/2     Terminating         0          6m46s
      sample-domain1-managed-server5   1/2     Terminating         0          6m46s
      sample-domain1-managed-server4   1/2     Running             0          6m51s
      sample-domain1-managed-server4   1/2     Terminating         0          6m53s
      sample-domain1-managed-server4   1/2     Terminating         0          6m53s
      sample-domain1-managed-server3   1/2     Running             0          7m40s
      sample-domain1-managed-server3   1/2     Terminating         0          7m45s
      sample-domain1-managed-server3   1/2     Terminating         0          7m45s
      

El gráfico del área de trabajo de Azure Monitor es similar a la captura de pantalla siguiente:

Captura de pantalla de Azure Portal, donde se muestra el gráfico del Explorador de Prometheus.

Limpieza de recursos

Para evitar los cargos de Azure, se recomienda limpiar los recursos que no sean necesarios. Cuando ya no necesite el clúster, use el comando az group delete. Los siguientes comandos quitan el grupo de recursos, el servicio de contenedor, el registro de contenedor y todos los recursos relacionados:

az group delete --name <wls-resource-group-name> --yes --no-wait
az group delete --name <ama-resource-group-name> --yes --no-wait

Pasos siguientes

Continúe explorando las siguientes referencias para conocer más opciones para compilar soluciones de escalado automático y ejecutar WLS en Azure: