Implementa GKE en clústeres de Bare Metal en el perímetro

En este instructivo, se presenta una solución lista para usar que utiliza GKE en Bare Metal y el Sincronizador de configuración para implementar clústeres de Kubernetes en el perímetro a gran escala. Este instructivo es para desarrolladores y operadores de plataformas. Debes estar familiarizado con las siguientes tecnologías y conceptos:

En este instructivo, usarás máquinas virtuales (VMs) de Compute Engine para emular nodos implementados en el perímetro y una aplicación de punto de venta de muestra como la carga de trabajo perimetral. GKE en Bare Metal y el Sincronizador de configuración proporcionan administración y control centralizados para tu clúster perimetral. El Sincronizador de configuración extrae de forma dinámica parámetros de configuración nuevos de GitHub y aplica estas políticas y los parámetros de configuración a tus clústeres.

Arquitectura de implementación perimetral

Una implementación perimetral de venta minorista es una buena manera de ilustrar la arquitectura que se usa en una implementación típica de GKE en Bare Metal.

Una tienda física de venta minorista es el punto de interacción más cercano entre una unidad de negocios empresarial y el consumidor. Los sistemas de software dentro de las tiendas deben ejecutar sus cargas de trabajo, recibir actualizaciones oportunas y también informar las métricas críticas de forma aislada desde el sistema de administración central de la empresa. Además, estos sistemas de software deben diseñarse para que puedan expandirse a más ubicaciones de tiendas en el futuro. Si bien GKE en Bare Metal cumple con todos estos requisitos para los sistemas de software de tienda, el perfil perimetral permite un caso práctico importante: implementaciones en entornos con recursos de hardware limitados, como una tienda de venta minorista.

En el siguiente diagrama, se muestra una implementación de GKE en Bare Metal que usa el perfil perimetral en una tienda minorista:

Implementación de GKE en Bare Metal que usa el perfil perimetral en una tienda minorista

En el diagrama anterior, se muestra una tienda física de venta minorista típica. La tienda tiene dispositivos inteligentes, como lectores de tarjetas, máquinas de punto de venta, impresoras y cámaras. La tienda también tiene tres dispositivos de hardware de procesamiento físico (etiquetados Node 1, Node 2 y Node 3). Todos estos dispositivos están conectados a un switch de red central. Por lo tanto, los tres dispositivos informáticos se conectan entre sí a través de una red de capa 2. Los dispositivos de computación conectados en red conforman la infraestructura sin sistema operativo. GKE en Bare Metal se ejecuta dentro de cada uno de los tres dispositivos de procesamiento. Estos dispositivos también tienen su propio almacenamiento en disco y están configurados para la replicación de datos entre ellos para ofrecer alta disponibilidad.

En el diagrama, también se muestran los siguientes componentes clave que forman parte de una implementación de GKE en Bare Metal:

  • El componente marcado como MetalLB es el balanceador de cargas en paquetes que se implementa con GKE en Bare Metal.
  • El componente del Sincronizador de configuración permite sincronizar el estado del clúster con los repositorios de origen. Es un complemento opcional altamente recomendado que requiere una instalación y configuración independientes. Para obtener más información sobre cómo configurar el Sincronizador de configuración y la nomenclatura diferente, consulta la documentación del Sincronizador de configuración.

  • El repositorio raíz y el repositorio de espacios de nombres que se muestran en la parte superior del diagrama fuera de la ubicación del almacén representan dos repositorios de origen.

    Los cambios del clúster se envían a estos repositorios centrales de código fuente. Las implementaciones de GKE en Bare Metal en varias ubicaciones perimetrales extraen actualizaciones de los repositorios de origen. Este comportamiento se representa con las flechas que conectan los dos repositorios del diagrama a los componentes del Sincronizador de configuración dentro del clúster de GKE en Bare Metal que se ejecuta en los dispositivos.

  • Otro componente clave que se representa como parte del clúster es el entorno de ejecución de VM en GDC. El entorno de ejecución de VM en GDC permite ejecutar cargas de trabajo existentes basadas en VM dentro del clúster sin la necesidad de crear contenedores. En la documentación del entorno de ejecución de VM en GDC, se explica cómo habilitarlo y, luego, implementar las cargas de trabajo de la VM en el clúster.

  • El componente marcado como Aplicación denota el software que la tienda minorista implementa en el clúster. La aplicación de punto de venta que se ve en los kioscos de una tienda minorista podría ser un ejemplo de una aplicación de este tipo.

Los cuadros en la parte inferior del diagrama representan los distintos dispositivos (como kioscos, tablets o cámaras) dentro de una tienda minorista, todos conectados a un interruptor de red central. Las redes locales dentro del almacén permiten que las aplicaciones que se ejecutan dentro de la implementación de GKE en Bare Metal lleguen a estos dispositivos.

En la siguiente sección, verás la emulación de esta implementación de tienda minorista en Google Cloud mediante las VM de Compute Engine. Esta emulación es la que usarás en el instructivo que sigue para experimentar con GKE en Bare Metal.

Implementación perimetral emulada en Google Cloud

En el siguiente diagrama, se representa todo lo que configuraste en Google Cloud en este instructivo. Este diagrama se correlaciona con el diagrama de la tienda minorista de la sección anterior. Esta implementación representa una ubicación emulada del perímetro en la que se implementa la aplicación de punto de venta. La arquitectura también muestra una carga de trabajo simple de la aplicación de muestra de punto de venta que usarás en este instructivo. Puedes acceder a la aplicación de punto de venta dentro del clúster mediante un navegador web como un kiosco.

Arquitectura de la aplicación de punto de venta y cómo se implementa dentro de un clúster de GKE en Bare Metal que se ejecuta en VMs de Compute Engine

Las tres máquinas virtuales (VM) de Compute Engine del diagrama anterior representan el hardware físico (o nodos) en una ubicación perimetral típica. Este hardware se conectaría junto con los conmutadores de red para constituir la infraestructura sin sistema operativo. En nuestro entorno emulado en Google Cloud, estas VM están conectadas entre sí a través de la red predeterminada de nube privada virtual (VPC) en el proyecto de Google Cloud.

En una instalación típica de GKE en Bare Metal, puedes configurar tus propios balanceadores de cargas. Sin embargo, para este instructivo no debes configurar un balanceador de cargas externo. En su lugar, usa el balanceador de cargas de MetalLB incluido que se instala con GKE en Bare Metal. El balanceador de cargas en paquetes de MetalLB requiere conectividad de red de capa 2 entre los nodos. Por lo tanto, la conectividad de capa 2 entre las VM de Compute Engine se habilita mediante la creación de una red de superposición VxLAN sobre la red de nube privada virtual (VPC) predeterminada.

Dentro del rectángulo con la etiqueta "L2 superposiciones network (VxLAN)", se muestran los componentes de software que se ejecutan dentro de las tres VMs de Compute Engine. Este rectángulo incluye el clúster de GKE en Bare Metal y un proxy inverso. El clúster se representa con el rectángulo “GKE en Bare Metal”. Este rectángulo que representa el clúster incluye otro rectángulo marcado como "Espacio de nombres de Kubernetes (pos)". Esto representa un espacio de nombres de Kubernetes dentro del clúster. Todos los componentes dentro de este espacio de nombres de Kubernetes conforman la aplicación de punto de venta que se implementa en el clúster de GKE en Bare Metal. La aplicación de punto de venta tiene tres microservicios: servidor de la API, inventario y pagos. Todos estos componentes juntos representan una “aplicación” que se muestra en el diagrama anterior de la arquitectura de lanzamiento de Edge.

No se puede acceder directamente al balanceador de cargas en paquetes de MetalLB del clúster de GKE en Bare Metal desde fuera de las VM. En el diagrama, se muestra un proxy inverso NGINX que se configura para ejecutarse dentro de las VMs a fin de enrutar el tráfico que llega a las VMs de Compute Engine hacia el balanceador de cargas. Esta es solo una solución alternativa para los fines de este instructivo, en la que los nodos perimetrales se emulan mediante las VM de Google Cloud Compute Engine. En una ubicación perimetral real, esto se puede hacer con la configuración de red adecuada.

Objetivos

  1. Usa VMs de Compute Engine para emular una infraestructura de equipos físicos que se ejecuta en una ubicación perimetral.
  2. Crear un clúster de GKE en Bare Metal en la infraestructura perimetral emulada
  3. Conectar y registrar el clúster con Google Cloud
  4. Implementa una carga de trabajo de muestra de la aplicación de punto de venta en el clúster de GKE en Bare Metal.
  5. Usa la consola de Google Cloud para verificar y supervisar la aplicación de punto de venta que opera en la ubicación perimetral.
  6. Usa el Sincronizador de configuración para actualizar la aplicación de punto de venta que se ejecuta en el clúster de GKE en Bare Metal.

Antes de comenzar

  1. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

    Ir a la selección del proyecto

  2. Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Obtén información sobre cómo verificar si la facturación está habilitada en un proyecto.

  3. Instala e initialize la Google Cloud CLI.

Bifurca y clona el repositorio de anthos-samples

Todas las secuencias de comandos que se usan en este instructivo se almacenan en el repositorio anthos-samples. La estructura de carpetas en /anthos-bm-edge-deployment/acm-config-sink se organiza de acuerdo con lo que espera el Sincronizador de configuración. Clona este repositorio en tu propia cuenta de GitHub antes de continuar con los siguientes pasos.

  1. Si aún no tienes una cuenta de GitHub, crea una.

  2. Crea un token de acceso personal para usarlo en la configuración del Sincronizador de configuración. Esto es necesario para que los componentes del Sincronizador de configuración en el clúster se autentiquen con tu cuenta de GitHub cuando intentes sincronizar cambios nuevos.

    1. Selecciona solo el permiso public_repo.
    2. Guarda el token de acceso que creaste en un lugar seguro para usarlo más adelante.

  3. Bifurca el repositorio anthos-samples en tu propia cuenta de GitHub:

    1. Ve al repositorio anhos-samples.
    2. Haz clic en el ícono Fork ubicado en la esquina superior derecha de la página.
    3. Haz clic en la cuenta de usuario de GitHub en la que deseas bifurcar el repositorio. Se te redireccionará automáticamente a la página con la versión bifurcada del repositorio anthos-samples.

  4. Abre una terminal en tu entorno local.

  5. Clona el repositorio bifurcado mediante la ejecución del siguiente comando, en el que GITHUB_USERNAME es el nombre de usuario de tu cuenta de GitHub:

    git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment

Configura el entorno de la estación de trabajo

Para completar la implementación perimetral descrita en este documento, necesitas una estación de trabajo con acceso a Internet y las siguientes herramientas instaladas:

Ejecuta todos los comandos del instructivo en la estación de trabajo que configurarás en esta sección.

  1. En tu estación de trabajo, inicializa las variables de entorno en una instancia de shell nueva:

    export PROJECT_ID="PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

# port on the admin Compute Engine instance you use to set up an nginx proxy
# this allows to reach the workloads inside the cluster via the VM IP
export PROXY_PORT="8082"

# should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
export GCE_COUNT="3"

# url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples
export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples"

# this is the username used to authenticate to your fork of this repository
export SCM_TOKEN_USER="GITHUB_USERNAME"

# access token created in the earlier step
export SCM_TOKEN_TOKEN="ACCESS_TOKEN"

    Reemplaza los siguientes valores:

    • PROJECT_ID: tu ID del proyecto de Google Cloud.
    • GITHUB_USERNAME: es tu nombre de usuario de GitHub.
    • ACCESS_TOKEN: Es el token de acceso personal que creaste para el repositorio de GitHub.

    Mantén los valores predeterminados de las otras variables de entorno. Se explican en las siguientes secciones.

  2. En tu estación de trabajo, inicializa Google Cloud CLI:

    gcloud config set project "${PROJECT_ID}"
gcloud services enable compute.googleapis.com

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

  3. En tu estación de trabajo, crea la cuenta de servicio de Google Cloud para las instancias de Compute Engine. Con esta secuencia de comandos, se crea el archivo de claves JSON para la cuenta de servicio nueva en <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. También configura el llavero de claves y la clave de Cloud Key Management Service para la encriptación de claves privadas SSH.

    ./scripts/create-primary-gsa.sh

    El siguiente ejemplo es solo una parte de la secuencia de comandos. Para ver la secuencia de comandos completa, haz clic en Ver en GitHub.

    # ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Aprovisiona las instancias de Compute Engine

En esta sección, crearás las VM de Compute Engine en las que se instalará GKE en Bare Metal. También debes verificar la conectividad a estas VM antes de continuar a la sección de instalación.

  1. En tu estación de trabajo, crea claves SSH que se usan para la comunicación entre las instancias de Compute Engine.

    ssh-keygen -f ./build-artifacts/consumer-edge-machine

  2. Encriptar la clave privada SSH con Cloud Key Management Service

    gcloud kms encrypt \
    --key gdc-ssh-key \
    --keyring gdc-ce-keyring \
    --location global \
    --plaintext-file build-artifacts/consumer-edge-machine \
    --ciphertext-file build-artifacts/consumer-edge-machine.encrypted

  3. Genera el archivo de configuración del entorno .envrc y su fuente. Después de crearlo, inspecciona el archivo .envrc para asegurarte de que las variables de entorno se hayan reemplazado por los valores correctos.

    envsubst < templates/envrc-template.sh > .envrc
source .envrc

    El siguiente es un ejemplo de un archivo .envrc que se genera reemplazando las variables de entorno en el archivo templates/envrc-template.sh. Observa que las líneas que se actualizaron están destacadas: 

    # GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

  4. Crea instancias de Compute Engine en las que esté instalado GKE en Bare Metal.

    ./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

Instala GKE en Bare Metal con Ansible

La secuencia de comandos que se usa en esta guía crea clústeres de GKE en Bare Metal en grupos de tres instancias de Compute Engine. La variable de entorno GCE_COUNT controla la cantidad de clústeres creados. Por ejemplo, configura la variable de entorno GCE_COUNT como 6 para crear dos clústeres de GKE en Bare Metal con instancias de VM 3 cada uno. De forma predeterminada, la variable de entorno GCE_COUNT se establece en 3. Por lo tanto, en esta guía, se creará un clúster con 3 instancias de Compute Engine. Las instancias de VM se nombran con un prefijo cnuc- seguido de un número. La primera instancia de VM de cada clúster actúa como la estación de trabajo de administrador desde la que se activa la instalación. El clúster también tiene el mismo nombre que la VM de la estación de trabajo de administrador (por ejemplo, cnuc-1, cnuc-4, cnuc-7).

La guía de Ansible realiza las siguientes acciones:

  • Configura las instancias de Compute Engine con las herramientas necesarias, como docker, bmctl, gcloud y nomos.
  • Instala GKE en Bare Metal en las instancias configuradas de Compute Engine.
  • Crea un clúster independiente de GKE en Bare Metal llamado cnuc-1.
  • Registra el clúster cnuc-1 en Google Cloud.
  • Instala el Sincronizador de configuración en el clúster cnuc-1.
  • Configura el Sincronizador de configuración para que se sincronice con la configuración del clúster ubicada en anthos-bm-edge-deployment/acm-config-sink en el repositorio bifurcado.
  • Genera el Login token para el clúster.

Completa los siguientes pasos para configurar e iniciar el proceso de instalación:

  1. En tu estación de trabajo, crea la imagen de Docker que se usa para la instalación. Esta imagen tiene todas las herramientas necesarias para el proceso de instalación, como Ansible, Python y Google Cloud CLI.

    gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

    Cuando la compilación se ejecuta correctamente, genera un resultado como el siguiente:

    ...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

  2. Genera el archivo de inventario de Ansible a partir de una plantilla.

    envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

  3. Ejecuta la secuencia de comandos de instalación que inicia un contenedor de Docker a partir de la imagen compilada con anterioridad. La secuencia de comandos usa Docker internamente para generar el contenedor con una activación de volumen en el directorio de trabajo actual. Después de completar con éxito esta secuencia de comandos, debes estar dentro del contenedor de Docker que se creó. La instalación de Ansible se activa desde este contenedor.

    ./install.sh

    Cuando la secuencia de comandos se ejecuta correctamente, se produce un resultado similar al siguiente:

    ...
Check the values above and if correct, do you want to proceed? (y/N): y
Starting the installation
Pulling docker install image...

==============================
Starting the docker container. You will need to run the following 2 commands (cut-copy-paste)
==============================
1: ./scripts/health-check.sh
2: ansible-playbook all-full-install.yaml -i inventory
3: Type 'exit' to exit the Docker shell after installation
==============================
Thank you for using the quick helper script!
(you are now inside the Docker shell)

  4. Desde el contenedor de Docker, verifica el acceso a las instancias de Compute Engine.

    ./scripts/health-check.sh

    Cuando la secuencia de comandos se ejecuta correctamente, se produce un resultado similar al siguiente:

    ...
cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}

  5. Desde el interior del contenedor de Docker, ejecuta la guía de Ansible para instalar GKE en Bare Metal en instancias de Compute Engine. Cuando finalice, verás el Login Token del clúster impreso en la pantalla.

    ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

    Cuando la instalación se ejecuta de forma correcta, se produce un resultado similar al siguiente:

    ...
TASK [abm-login-token : Display login token] **************************************************************************
ok: [cnuc-1] => {
    "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW
iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd
4CwanGlof6s-fbu8"
}
skipping: [cnuc-2]
skipping: [cnuc-3]

PLAY RECAP ***********************************************************************************************************
cnuc-1                     : ok=205  changed=156  unreachable=0    failed=0    skipped=48   rescued=0    ignored=12
cnuc-2                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2
cnuc-3                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2

Accede al clúster de GKE en Bare Metal en la consola de Google Cloud

Una vez que la guía de Ansible se ejecuta hasta su finalización, se instala un clúster independiente de GKE en Bare Metal dentro de las VM de Compute Engine. Este clúster también está registrado en Google Cloud mediante el agente de Connect. Sin embargo, para ver los detalles de este clúster, debes acceder al clúster desde la consola de Google Cloud. Para acceder al clúster de GKE, completa los siguientes pasos.

  1. Copia el token de la salida de la guía de Ansible en la sección anterior.

  2. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes y usa el token copiado para acceder al clúster cnuc-1.

    Ir a la página Clústeres de Kubernetes

    1. En la lista de clústeres, haz clic en Acciones junto al clúster cnuc-1 y, luego, en Acceder.
    2. Selecciona Token y pega el token copiado.
    3. Haz clic en Login.
  3. En la consola de Google Cloud, ve a la página Configuración en la sección Funciones.

    Ir a Configuración

    4. En la pestaña Paquetes, verifica la columna Estado de sincronización en la tabla de clústeres. Verifica que el estado sea Sincronizado. El estado Sincronizado indica que el Sincronizador de configuración sincronizó correctamente tus parámetros de configuración de GitHub con el clúster implementado, cnuc-1.

Configura un proxy para el tráfico externo

El clúster de GKE en Bare Metal instalado en los pasos anteriores usa un balanceador de cargas agrupado llamado MetalLB. Solo se puede acceder a este servicio de balanceador de cargas a través de una dirección IP de nube privada virtual (VPC). Para enrutar el tráfico que llega a través de su IP externa al balanceador de cargas en paquetes, configura un servicio de proxy inverso en el host de administrador (cnuc-1). Este servicio de proxy inverso te permite acceder al servidor de la API de la aplicación de punto de venta a través de la IP externa del host de administrador (cnuc-1).

Las secuencias de comandos de instalación en los pasos anteriores instalaron NGINX en los hosts de administrador junto con un archivo de configuración de muestra. Actualiza este archivo para usar la dirección IP del servicio de balanceador de cargas y reinicia NGINX.

  1. En tu estación de trabajo, usa SSH para acceder a la estación de trabajo de administrador:

    ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1

  2. Desde el interior de la estación de trabajo de administrador, configura el proxy inverso de NGINX para enrutar el tráfico al servicio del balanceador de cargas del servidor de la API. Obtén la dirección IP del servicio de Kubernetes del tipo de balanceador de cargas:

    ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)

  3. Actualiza el archivo de configuración de plantillas con la dirección IP recuperada:

    sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

  4. Reinicia NGINX para asegurarte de que se aplique la configuración nueva:

    sudo systemctl restart nginx

  5. Verifica y verifica el estado del servidor NGINX para informar "active (running)":

    sudo systemctl status nginx

    Cuando NGINX se ejecuta de forma correcta, genera un resultado como el del siguiente ejemplo:

    ● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago
    Docs: man:nginx(8)
    Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 92573 (nginx)
    Tasks: 17 (limit: 72331)
    Memory: 13.2M
    CGroup: /system.slice/nginx.service
            ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─92574 nginx: worker process
            ├─92575 nginx: worker process
            ├─92577 nginx: ....
            ...
            ...

  6. Sal de la sesión de SSH a la estación de trabajo de administrador:

    exit

  7. Sal de la sesión de shell en el contenedor de Docker. Cuando sales de la instancia de administrador, te encuentras dentro del contenedor de Docker que se usó para la instalación:

    exit

Accede a la aplicación de punto de venta

Con la configuración del proxy externo, puedes acceder a la aplicación que se ejecuta dentro del clúster de GKE. Para acceder a la aplicación de punto de venta de muestra, completa los siguientes pasos.

  1. En tu estación de trabajo, obtén la dirección IP externa de la instancia de administrador de Compute Engine y accede a la IU de la aplicación de punto de venta:

    EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

    Cuando las secuencias de comandos se ejecutan de forma correcta, producen resultados como los siguientes:

    Point the browser to: 34.134.194.84:8082

  2. Abre el navegador web y navega a la dirección IP que se muestra en el resultado del comando anterior. Puedes acceder a la aplicación de punto de venta de muestra y probarla, como se ve en la siguiente captura de pantalla de ejemplo:

    Versión 1 de la aplicación de punto de venta implementada

Usa el Sincronizador de configuración para actualizar el servidor de la API

La aplicación de muestra se puede actualizar a una versión más reciente si actualizas los archivos de configuración en el repositorio raíz. El Sincronizador de configuración detecta las actualizaciones y realiza los cambios automáticamente en tu clúster. En este ejemplo, el repositorio raíz es el repositorio anthos-samples que clonaste al comienzo de esta guía. Para ver cómo la aplicación de punto de venta de muestra puede pasar por una implementación de actualización a una versión más reciente, completa los siguientes pasos.

  1. En tu estación de trabajo, actualiza el campo image para cambiar la versión del servidor de la API de v1 a v2. La configuración YAML para la implementación está en el archivo en anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml. 

    containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1

  2. Agrega, confirma y envía los cambios al repositorio bifurcado:

    git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

  3. En la consola de Google Cloud, ve a la página Config Management para verificar el estado de las especificaciones de configuración. Verifica que el estado sea Sincronizado.

    Ir a la página Config Management

  4. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes Engine para verificar que la Implementación esté actualizada.

    Ir a la página Cargas de trabajo de Kubernetes Engine

  5. Cuando el estado de Implementación sea Correcto, apunta el navegador a la dirección IP de la sección anterior para ver la aplicación de punto de venta. Ten en cuenta que la versión en el título muestra “V2”, lo que indica que se implementó el cambio de tu aplicación, como se muestra en la siguiente captura de pantalla de ejemplo:

    Versión 2 de la aplicación de punto de venta implementada

    Es posible que debas actualizar la pestaña del navegador para ver los cambios.

Limpia

A fin de evitar cargos innecesarios de Google Cloud, borra los recursos que se usaron para esta guía cuando termines. Puedes borrar estos recursos de forma manual o borrar el proyecto de Google Cloud, lo que también elimina todos los recursos. Además, también puedes limpiar los cambios realizados en tu estación de trabajo local:

Estación de trabajo local

Los siguientes archivos deben actualizarse para borrar los cambios que realizaron las secuencias de comandos de instalación.

  • Quita las direcciones IP de la VM de Compute Engine que se agregan al archivo /etc/hosts.
  • Quita la configuración SSH para cnuc-* en el archivo ~/.ssh/config.
  • Quita las huellas digitales de la VM de Compute Engine del archivo ~/.ssh/known_hosts.

Borrar proyecto

Si creaste un proyecto dedicado para este procedimiento, borra el proyecto de Google Cloud de la consola de Cloud.

  • En la consola de Google Cloud, ve a la página Administrar recursos.

    Ir a Administrar recursos

  • En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  • En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

    • Manual

    Si usaste un proyecto existente para este procedimiento, haz lo siguiente:

    • Cancela el registro de todos los clústeres de Kubernetes que tengan un nombre con el prefijo cnuc-.
    • Borra todas las VM de Compute Engine con un nombre con el prefijo cnuc-.
    • Borra el bucket de Cloud Storage con un nombre con el prefijo abm-edge-boot.
    • Borra las reglas de firewall allow-pod-ingress y allow-pod-egress.
    • Borra el secreto de Secret Manager install-pub-key.

    Próximos pasos

    Puedes expandir esta guía si agregas otra ubicación perimetral. Si configuras la variable de entorno GCE_COUNT como 6 y vuelves a ejecutar los mismos pasos de las secciones anteriores, se crean tres instancias nuevas de Compute Engine (cnuc-4, cnuc-5 y cnuc-6) y un nuevo clúster independiente de GKE en Bare Metal llamado cnuc-4.

    También puedes intentar actualizar las opciones de configuración de los clústeres en tu repositorio bifurcado para aplicar de forma selectiva diferentes versiones de la aplicación de punto de venta a los dos clústeres, cnuc-1 y cnuc-4, mediante ClusterSelectors.

    Para obtener detalles sobre los pasos individuales de esta guía, las secuencias de comandos involucradas, consulta el repositorio de anthos-samples.