Versión 1.10

Configura el plano de control administrado por Google

Descripción general

El plano de control administrado por Google de Anthos Service Mesh es un servicio administrado de Google Cloud que solo necesitas configurar, mientras que Google se encarga de su confiabilidad, actualizaciones, escalamiento y seguridad de manera retrocompatible. En esta guía, se explica cómo configurar o migrar aplicaciones al plano de control administrado por Google en una configuración de uno o varios clústeres.

Puedes usar un solo plano de control administrado por Google para varios clústeres de GKE en un solo proyecto de Google Cloud.

Para obtener información sobre las funciones y limitaciones compatibles del plano de control administrado de Anthos Service Mesh, consulta Funciones compatibles del plano de control administrado por Google de Anthos Service Mesh.

Requisitos previos

En esta guía, suponemos que ya tienes lo siguiente:

Si Workload Identity no está habilitado, puedes habilitarlo con el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --zone LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog

Descarga la secuencia de comandos de instalación

  1. Descarga la versión más reciente de la secuencia de comandos que instala Anthos Service Mesh 1.10.4 en el directorio de trabajo actual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10 > install_asm
    
  2. Descarga el SHA-256 del archivo en el directorio de trabajo actual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10.sha256 > install_asm.sha256
    
  3. Con ambos archivos en el mismo directorio, verifica la descarga:

    sha256sum -c --ignore-missing install_asm.sha256
    

    Si la verificación se realiza de forma correcta, el comando genera este resultado: install_asm: OK.

    Para mayor compatibilidad, el archivo install_asm.sha256 incluye la suma de verificación dos veces a fin de permitir que cualquier versión de la secuencia de comandos cambie su nombre a install_asm. Si recibes un error que indica que --ignore-missing no existe, vuelve a ejecutar el comando anterior sin la marca --ignore-missing.

  4. Haz que la secuencia de comandos sea ejecutable:

    chmod +x install_asm
    

Configura cada clúster

Usa los siguientes pasos a fin de configurar el plano de control administrado por Google para cada clúster en la malla.

Obtén credenciales de clúster

Recupera las credenciales adecuadas. El siguiente comando también apunta el contexto kubectl al clúster de destino.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Aplica el plano de control administrado por Google

Ejecuta la secuencia de comandos de instalación para cada clúster que usará el plano de control administrado por Google:

Si no necesitas la Interfaz de red de contenedor (CNI) de Istio, omite la marca --option cni-managed en el comando install_asm que se muestra en el siguiente ejemplo. La CNI es una opción para que el plano de control administrado por Google configure la intercepción de Istio y las Herramientas de redes de bajo nivel mediante la interfaz CNI de CNCF en lugar de usar un contenedor de inicialización con alto privilegio.

./install_asm --mode install --managed \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --verbose \
    --output_dir CLUSTER_NAME \
    --enable-all \
    --option cni-managed

La secuencia de comandos se descargará en el --output_dir especificado para todos los archivos a fin de configurar el plano de control administrado e instalar una puerta de enlace de Istio, junto con la herramienta istioctl y las aplicaciones de muestra.

Instala puertas de enlace de Istio (opcional)

De manera opcional, puedes instalar una o más puertas de enlace de Istio en tu clúster para manejar el tráfico de entrada típico mediante los siguientes pasos:

  1. Elige una de estas dos opciones a fin de configurar el espacio de nombres en el que implementarás la puerta de enlace en pasos posteriores.

    • Habilita el espacio de nombres para la inserción:
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
      

    O

    • Habilita la inserción solo para el Pod de puerta de enlace, pero no para todos los Pods del espacio de nombres. Este comando quita todas las etiquetas de inyección y, luego, habilitarás la inserción en el pod:
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
      
  2. Crea un objeto Deployment y Service para la puerta de enlace mediante el siguiente ejemplo mínimo:

    kubectl apply -f - << EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
    spec:
      type: LoadBalancer
      selector:
        istio: ingressgateway
      ports:
      - port: 80
        name: http
      - port: 443
        name: https
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
    spec:
      selector:
        matchLabels:
          istio: ingressgateway
      template:
        metadata:
          annotations:
            # This is required to tell Anthos Service Mesh to inject the gateway with the
            # required configuration.
            inject.istio.io/templates: gateway
          labels:
            istio: ingressgateway
            istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
        spec:
          containers:
          - name: istio-proxy
            image: auto # The image will automatically update each time the pod starts.
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: istio-ingressgateway-sds
    subjects:
    - kind: ServiceAccount
      name: default
    EOF
    
  3. Después de crear la implementación, verifica que los servicios nuevos funcionen de forma correcta:

    kubectl get pod,service -n GATEWAY_NAMESPACE
    

    Verifica un resultado similar al siguiente:

    NAME                                      READY   STATUS    RESTARTS   AGE
    pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
    
    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
    service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Configura la detección de extremos (solo para instalaciones de varios clústeres)

El plano de control administrado de Anthos Service Mesh admite una configuración de varias instancias, de proyecto único y de red única, con la diferencia de que el plano de control no está instalado en el clúster. Una configuración de varias instancias significa que cada clúster está configurado con secretos en todos los demás clústeres, lo que permite que cada clúster descubra extremos de todos los otros clústeres.

Antes de continuar, ya deberías haber ejecutado la secuencia de comandos de instalación en cada clúster como se describe en los pasos anteriores. No es necesario indicar que un clúster es uno principal, este es el comportamiento predeterminado.

Para cada clúster, habilita el descubrimiento de extremos ejecutando los siguientes comandos una vez para cada clúster i=1..N en la malla:

  1. Para cada clúster, asegúrate de que el contexto de configuración de kubectl apunte al clúster actual:

    export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
    
  2. Habilita el descubrimiento de extremos mediante la ejecución de los siguientes comandos una vez para cada clúster i=1..N en la malla:

    export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i
    
    ./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
      kubectl apply -f - --context=${CTX}
    
  3. Ejecuta el siguiente comando para verificar que se haya creado el secreto:

    kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system
    

    Verifica el resultado esperado:

    NAME                                   TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s
    
  4. Si el clúster actual se agrega a una malla de varios clústeres existente, permite que todos los demás clústeres descubran sus extremos mediante la creación de un secreto correspondiente al clúster actual en todos los demás clústeres:

    ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
      kubectl apply -f - --context=${CTX_i}
    
  5. Además, puedes verificar el secreto del otro clúster:

    kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}
    

    Verifica el resultado esperado:

    NAME                            TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME   Opaque   1      44s
    

Para obtener más detalles y un ejemplo con dos clústeres, consulta Habilita el descubrimiento de extremos.

Implementar aplicaciones

Antes de implementar aplicaciones, quita las etiquetas istio-injection anteriores de sus espacios de nombres y configura la etiqueta istio.io/rev:asm-managed-rapid en su lugar:

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

En este punto, configuraste correctamente el plano de control administrado de Anthos Service Mesh. Ahora estás listo para implementar las aplicaciones o puedes implementar la aplicación de muestra de Bookinfo.

Si implementas una aplicación en una configuración de varios clústeres, replica la configuración del plano de control y Kubernetes en todos los clústeres, a menos que planees limitar esa configuración en particular a un subconjunto de clústeres. La configuración que se aplica a un clúster en particular es la fuente de información de ese clúster. Además, si el clúster también ejecuta Anthos Service Mesh 1.7, 1.8 o una versión posterior con la CA de Mesh en otros espacios de nombres, verifica que la aplicación pueda comunicarse con las otras aplicaciones que controla el plano de control en el clúster.

Verifica las métricas del plano de control

Para verificar que tu configuración funcione de forma correcta, sigue estos pasos:

  1. En Cloud Console, observa las métricas del plano de control:

    Ir al Explorador de métricas

  2. Elige tu lugar de trabajo y agrega una consulta personalizada con los siguientes parámetros:

    • Tipo de recurso: Contenedor de Kubernetes
    • Métrica: Clientes del proxy
    • Filtro: container_name="cr-asm-managed-rapid"
    • Agrupar por: Etiqueta de revisión y etiqueta proxy_version
    • Suma de agregador
    • Período: 1 minuto

    Cuando ejecutas Anthos Service Mesh con un plano de control administrado por Google y en el clúster, puedes distinguir las métricas por su nombre de contenedor. Por ejemplo, las métricas administradas tienen container_name="cr-asm-managed", mientras que las métricas no administradas tienen container_name="discovery". Para mostrar las métricas de ambos, quita el filtro en container_name="cr-asm-managed".

  3. Para verificar la versión del plano de control y del proxy, inspecciona los siguientes campos en el Explorador de métricas:

    • En el campo revisión, se indica la versión del plano de control.
    • El campo proxy_version indica el proxy_version.
    • El campo value indica el número de proxies conectados.

Migra aplicaciones al plano de control administrado por Google

El plano de control administrado por Google de Anthos Service Mesh solo admite la migración desde Anthos Service Mesh 1.9, que usa la CA de Mesh.

Para migrar al plano de control administrado por Google, realiza los siguientes pasos:

  1. Ejecuta la secuencia de comandos como se indica en la sección Instala el plano de control.

  2. Reemplaza la etiqueta del espacio de nombres actual por la etiqueta istio.io/rev:asm-managed-rapid:

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
        --overwrite
    
  3. Realiza una actualización progresiva de las implementaciones en el espacio de nombres:

    kubectl rollout restart deployment -n NAMESPACE
    
  4. Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.

  5. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos anteriores para cada espacio de nombres.

  6. Si implementaste la aplicación en una configuración de varios clústeres, replica la configuración de Istio y Kubernetes en todos los clústeres, a menos que exista el deseo de limitar esa configuración a un subconjunto de clústeres solamente. La configuración que se aplica a un clúster en particular es la fuente de información de ese clúster.

  7. Para verificar que las métricas aparezcan como se espera, sigue los pasos en Verifica las métricas del plano de control.

Un clúster puede tener una combinación de revisiones, por ejemplo, Anthos Service Mesh 1.7 y 1.8, y un plano de control dentro del clúster. Puedes combinar espacios de nombres con diferentes revisiones del plano de control de Anthos Service Mesh de manera indefinida.

Si estás seguro de que tu aplicación funciona como se esperaba, puedes quitar istiod en el clúster después de cambiar todos los espacios de nombres al plano de control en el cluster o mantenerlos como una copia de seguridad; istiod reducirá la escala verticalmente de forma automática para usar menos recursos. Para quitarlo, ve a Borra el plano de control anterior.

Si encuentras problemas, puedes identificarlos y resolverlos mediante la información que aparece en Resuelve problemas del plano de control administrado y, si es necesario, revertir a la versión anterior.

Borrar el plano de control anterior

Después de instalar y confirmar que todos los espacios de nombres usan el plano de control administrado por Google, puedes borrar el plano de control anterior.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Si usaste istioctl kube-inject en lugar de la inserción automática, o si instalaste puertas de enlace adicionales, verifica las métricas del plano de control y verifica que la cantidad de extremos conectados sea cero.

Revertir

Realiza los siguientes pasos si necesitas revertir a la versión anterior del plano de control:

  1. Actualiza las cargas de trabajo que se insertarán con la versión anterior del plano de control: En el siguiente comando, el valor de revisión asm-191-1 solo se usa como ejemplo. Reemplaza el valor de ejemplo por la etiqueta de revisión de tu plano de control anterior.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. Reinicia los Pods para activar la reinserción a fin de que los proxies tengan la versión de Istio:

    kubectl rollout restart deployment -n NAMESPACE
    

El plano de control administrado escalará de forma automática a cero y no usará ningún recurso cuando no esté en uso. Los webhooks y el aprovisionamiento mutados permanecerán y no afectarán el comportamiento del clúster.

La puerta de enlace ahora está configurada en la revisión asm-managed. Para revertirlo, vuelve a ejecutar el comando de instalación de Anthos Service Mesh, que volverá a implementar la puerta de enlace que apunta al plano de control en el clúster:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Espera el siguiente resultado con éxito:

deployment.apps/istio-ingressgateway rolled back

Migra una puerta de enlace al plano de control administrado por Google

  1. Crea una implementación de Kubernetes para la versión nueva de la puerta de enlace mediante la documentación. Debes configurar el servicio de Kubernetes Gateway existente para seleccionar la versión anterior y la nueva, mediante el campo selector en la configuración del servicio.

  2. Mediante el uso del comando kubectl scale, escala verticalmente y de forma gradual la implementación nueva, mientras reduces verticalmente la escala de la implementación anterior y verificas si hay indicadores de cualquier interrupción o tiempo de inactividad del servicio. Si la migración se realiza correctamente, no deberías alcanzar instancias anteriores ni experimentar interrupciones del servicio.

Desinstalar

El plano de control administrado por Google se escala automáticamente a cero cuando ningún espacio de nombres lo está utilizando; por lo tanto, no se requiere desinstalación.

Soluciona problemas

Para identificar y resolver problemas cuando usas el plano de control administrado, consulta Resuelve problemas del plano de control administrado.

Próximos pasos