Del perímetro a la malla: Implementa aplicaciones de la malla de servicios a través la puerta de enlace de GKE

Last reviewed 2024-01-31 UTC

En esta implementación, se muestra cómo combinar Anthos Service Mesh con Cloud Load Balancing para exponer aplicaciones en una malla de servicios a los clientes de Internet.

Puedes exponer una aplicación a los clientes de muchas maneras, según la ubicación en que estos se encuentren. En esta implementación, se muestra cómo exponer una aplicación a los clientes a través de la combinación de Cloud Load Balancing con Anthos Service Mesh para integrar balanceadores de cargas en una malla de servicios. Esta implementación está dirigida a profesionales avanzados que ejecutan Anthos Service Mesh, pero también funciona para Istio en Google Kubernetes Engine.

Arquitectura

En el siguiente diagrama, se muestra cómo puedes usar las puertas de enlace de entrada de la malla para integrar los balanceadores de cargas en una malla de servicios:

Un balanceador de cargas externo enruta los clientes externos a la malla a través de proxies de puerta de enlace de entrada.

La entrada de la nube actúa como puerta de enlace para el tráfico externo que ingresa a la malla a través de la red de VPC.

En la topología del diagrama anterior, la capa de entrada de la nube, que se programa a través de la puerta de enlace de GKE, origina el tráfico desde el exterior de la malla de servicios y lo dirige a la capa de entrada de la malla. Luego, la capa de entrada de la malla dirige el tráfico a los backends de aplicaciones alojadas en la malla.

La entrada de la nube verifica el estado de la entrada de la malla, y la entrada de la malla verifica el estado de los backends de la aplicación.

La topología anterior tiene las siguientes consideraciones:

  • Entrada de la nube: en esta arquitectura de referencia, debes configurar el balanceador de cargas de Google Cloud a través de la puerta de enlace de GKE para verificar el estado de los proxies de entrada de la malla en sus puertos de verificación de estado expuestos.
  • Entrada de la malla: en la aplicación de la malla, debes realizar verificaciones de estado directamente en los backends, de modo que puedas ejecutar el balanceo de cargas y la administración de tráfico de forma local.

La seguridad se implementa mediante certificados administrados ubicados fuera de la malla y certificados internos dentro de la malla.

En el siguiente diagrama, se ilustra la encriptación HTTPS del cliente al balanceador de cargas de Google Cloud, del balanceador de cargas al proxy de entrada de la malla y del proxy de entrada al proxy de sidecar.

Objetivos

  • Implementar un clúster de Google Kubernetes Engine (GKE) en Google Cloud
  • Implementar Anthos Service Mesh basada en Istio en el clúster de GKE
  • Configura la puerta de enlace de GKE para finalizar el tráfico de HTTPS público y dirigir ese tráfico a las aplicaciones alojadas en la malla de servicios
  • Implementar la aplicación Online Boutique en el clúster de GKE que expones a los clientes en Internet

Optimización de costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

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 al selector de proyectos

  2. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

  3. En la consola de Google Cloud, activa Cloud Shell.

    Activar Cloud Shell

    Ejecuta todos los comandos de terminal de esta implementación desde Cloud Shell.

  4. Actualiza a la versión más reciente de Google Cloud CLI:

    gcloud components update
    
  5. Configura un proyecto predeterminado de Google Cloud:

    export PROJECT=PROJECT
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
    gcloud config set project ${PROJECT}
    

    Reemplaza PROJECT por el ID del proyecto que deseas usar para esta implementación.

  6. Crea un directorio de trabajo:

    mkdir -p ${HOME}/edge-to-mesh
    cd ${HOME}/edge-to-mesh
    export WORKDIR=`pwd`
    

    Después de finalizar esta implementación, puedes borrar el directorio de trabajo.

Crea clústeres de GKE

Las funciones que se describen en esta implementación requieren una versión 1.16 o posterior del clúster de GKE.

  1. En Cloud Shell, crea un archivo kubeconfig nuevo. Con este paso te aseguras de no causar un conflicto con el archivo kubeconfig (predeterminado) existente.

    touch edge2mesh_kubeconfig
    export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig
    
  2. Define las variables de entorno para el clúster de GKE:

    export CLUSTER_NAME=edge-to-mesh
    export CLUSTER_LOCATION=us-central1
    
  3. Habilita la API de Google Kubernetes Engine:

    gcloud services enable container.googleapis.com
    
  4. Crea un clúster de GKE Autopilot:

    gcloud container --project ${PROJECT} clusters create-auto
    ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid
    
  5. Asegúrate de que el clúster esté en ejecución:

    gcloud container clusters list
    

    El resultado es similar al siguiente:

    NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    edge-to-mesh  us-central1  1.27.3-gke.1700   34.122.84.52  e2-medium  1.27.3-gke.1700   3          RUNNING
    

Instala una malla de servicios

En esta sección, debes configurar Anthos Service Mesh administrado con la API de Fleet.

  1. En Cloud Shell, habilita las APIs requeridas:

    gcloud services enable mesh.googleapis.com
    
  2. Habilita Anthos Service Mesh en la flota:

    gcloud container fleet mesh enable
    
  3. Registra el clúster en la flota:

    gcloud container fleet memberships register ${CLUSTER_NAME} \
      --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME
    
  4. Aplica la etiqueta mesh_id al clúster edge-to-mesh:

    gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}
    
  5. Habilita la administración automática del plano de control y el plano de datos administrados:

    gcloud container fleet mesh update \
      --management automatic \
      --memberships ${CLUSTER_NAME}
    
  6. Después de unos minutos, verifica que el estado del plano de control sea ACTIVE:

    gcloud container fleet mesh describe
    

    El resultado es similar al siguiente:

    ...
    membershipSpecs:
      projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
        mesh:
          management: MANAGEMENT_AUTOMATIC
    membershipStates:
      projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
        servicemesh:
          controlPlaneManagement:
            details:
            - code: REVISION_READY
              details: 'Ready: asm-managed-rapid'
            state: ACTIVE
          dataPlaneManagement:
            details:
            - code: OK
              details: Service is running.
            state: ACTIVE
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed-rapid.'
          updateTime: '2023-08-04T02:54:39.495937877Z'
    name: projects/e2m-doc-01/locations/global/features/servicemesh
    resourceState:
      state: ACTIVE
    ...
    

Implementa la puerta de enlace de GKE

En los siguientes pasos, implementarás el balanceador de cargas de aplicaciones externo a través de GKE Gateway Controller. El recurso de puerta de enlace de GKE automatiza el aprovisionamiento del balanceador de cargas y la verificación de estado del backend. Además, usarás el Administrador de certificados para aprovisionar y administrar un certificado TLS, y Endpoints para aprovisionar de forma automática un nombre de DNS público para la aplicación.

Instala una puerta de enlace de entrada de la malla de servicios

Como práctica recomendada de seguridad, te recomendamos que implementes la puerta de enlace de entrada en un espacio de nombres diferente en el plano de control.

  1. En Cloud Shell, crea un espacio de nombres asm-ingress dedicado:

    kubectl create namespace asm-ingress
    
  2. Agrega una etiqueta de espacio de nombres al espacio de nombres asm-ingress:

    kubectl label namespace asm-ingress istio-injection=enabled
    

    El resultado es similar a este:

    namespace/asm-ingress labeled
    

    Si etiquetas el espacio de nombres asm-ingress con istio-injection=enabled, se indica a Anthos Service Mesh que inserte de manera automática proxies de sidecar de Envoy cuando se implementa una aplicación.

  3. Crea un certificado autofirmado que usa la puerta de enlace de entrada para finalizar las conexiones TLS entre el balanceador de cargas de Google Cloud (que se configurará más adelante a través GKE Gateway Controller) y la puerta de enlace de entrada, y almacena el certificado autofirmado como un Secret de Kubernetes:

    openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
     -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \
     -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \
     -out frontend.endpoints.${PROJECT}.cloud.goog.crt
    
    kubectl -n asm-ingress create secret tls edge2mesh-credential \
     --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
     --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
    

    Para obtener más detalles sobre los requisitos para el certificado de puerta de enlace de entrada, consulta la guía de consideraciones del protocolo de backend seguro.

  4. Ejecuta los siguientes comandos para crear el YAML del recurso de la puerta de enlace de entrada:

    mkdir -p ${WORKDIR}/asm-ig/base
    cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml
    resources:
      - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
    EOF
    
    mkdir ${WORKDIR}/asm-ig/variant
    cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: asm-ingressgateway
      namespace: asm-ingress
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: asm-ingressgateway
    subjects:
      - kind: ServiceAccount
        name: asm-ingressgateway
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: asm-ingressgateway
    spec:
      ports:
      - name: status-port
        port: 15021
        protocol: TCP
        targetPort: 15021
      - name: http
        port: 80
        targetPort: 8080
      - name: https
        port: 443
        targetPort: 8443
        appProtocol: HTTP2
      type: ClusterIP
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml
    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: asm-ingressgateway
    spec:
      servers:
      - port:
          number: 443
          name: https
          protocol: HTTPS
        hosts:
        - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below
        tls:
          mode: SIMPLE
          credentialName: edge2mesh-credential
    EOF
    
    cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml
    namespace: asm-ingress
    resources:
    - ../base
    - role.yaml
    - rolebinding.yaml
    patches:
    - path: service-proto-type.yaml
      target:
        kind: Service
    - path: gateway.yaml
      target:
        kind: Gateway
    EOF
    
  5. Aplica las CRD de la puerta de enlace de entrada:

    kubectl apply -k ${WORKDIR}/asm-ig/variant
    
  6. Asegúrate de que todas las implementaciones estén en funcionamiento:

    kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress
    

    El resultado es similar al siguiente:

    deployment.apps/asm-ingressgateway condition met
    

Aplica una verificación de estado de la puerta de enlace de entrada de la malla de servicios

Cuando se integra una puerta de enlace de entrada de la malla de servicios a un balanceador de cargas de aplicaciones de Google Cloud, el balanceador de cargas de aplicaciones debe configurarse para realizar verificaciones de estado en los Pods de la puerta de enlace de entrada. La CRD de HealthCheckPolicy proporciona una API para configurar esa verificación de estado.

  1. En Cloud Shell, crea el archivo HealthCheckPolicy.yaml:

    cat <<EOF >${WORKDIR}/ingress-gateway-healthcheck.yaml
    apiVersion: networking.gke.io/v1
    kind: HealthCheckPolicy
    metadata:
      name: ingress-gateway-healthcheck
      namespace: asm-ingress
    spec:
      default:
        checkIntervalSec: 20
        timeoutSec: 5
        #healthyThreshold: HEALTHY_THRESHOLD
        #unhealthyThreshold: UNHEALTHY_THRESHOLD
        logConfig:
          enabled: True
        config:
          type: HTTP
          httpHealthCheck:
            #portSpecification: USE_NAMED_PORT
            port: 15021
            portName: status-port
            #host: HOST
            requestPath: /healthz/ready
            #response: RESPONSE
            #proxyHeader: PROXY_HEADER
        #requestPath: /healthz/ready
        #port: 15021
      targetRef:
        group: ""
        kind: Service
        name: asm-ingressgateway
    EOF
    
  2. Aplica el HealthCheckPolicy:

    kubectl apply -f ${WORKDIR}/ingress-gateway-healthchec