Actualiza la entrega de Knative en VMware a las flotas

Aprende a migrar la entrega de Knative en VMware a fin de usar flotas para poder actualizar a la versión 1.8 de Anthos.

Importante: La versión 1.8 de Anthos requiere que todas las instalaciones anteriores de Knative Serving en VMware se migren para usar flotas. Debes migrar la entrega de Knative antes de actualizar los clústeres de GKE a la versión 1.8.

Si decides permanecer en la versión 1.7 de Anthos o una anterior, no es necesario que migres tu instalación de inmediato. Sin embargo, a partir de Anthos 1.8, las instalaciones nuevas y las actualizaciones de la entrega de Knative solo están disponibles a través de flotas.

La entrega de Knative ahora es una experiencia independiente del producto administrado de Cloud Run y se proporciona como un componente de flota en tus clústeres. Instalar la entrega de Knative en funciones de VMware como un componente de tu flota te permite administrar y actualizar la instalación independientemente de otros componentes de la flota.

En un nivel alto, para migrar la instalación de Knative en VMware a fin de usar una flota, debes hacer lo siguiente:

• Configura la instalación de Knative en VMware para cumplir con los requisitos de la flota.
• Habilita el componente de entrega de Knative en tu flota.

Ten en cuenta que el servidor de la API de Kubernetes no se verá afectado durante esta migración.

Si deseas obtener detalles sobre cómo realizar una instalación nueva de la entrega de Knative en VMware, consulta Instala la entrega de Knative en VMware.

Antes de comenzar

Debes cumplir con los siguientes requisitos:

• En estos pasos, se requiere que la entrega de Knative en el clúster de VMware esté registrada en GKE Enterprise:

  Ir a Clústeres de GKE Enterprise

  Aprende a registrar un clúster.

• La instalación de la entrega de Knative en VMware está en un clúster que ejecuta Anthos 1.7 o una versión anterior.

• Istio ya no es compatible con Anthos 1.8. Debes instalar la versión 1.18 de Anthos Service Mesh en tu flota y la instalación de la entrega de Knative antes de actualizar ese clúster a la versión 1.8.

  Consulta las instrucciones de Anthos Service Mesh para obtener detalles sobre la instalación en GKE en VMware.

  Ten en cuenta que Anthos Service Mesh requiere que el clúster use un tipo de máquina que tenga al menos cuatro CPU virtuales, como e2-standard-4. Si necesitas cambiar el tipo de máquina del clúster, consulta la sección sobre cómo migrar cargas de trabajo a diferentes tipos de máquina.

• Existen dos opciones para migrar la entrega de Knative a Anthos Service Mesh:

  • Obtén una nueva dirección IP externa en la que configurarás el balanceador de cargas.

  • Vuelve a usar la dirección IP del balanceador de cargas existente.

    Advertencia: El proceso de reutilizar una dirección IP existente para configurar Anthos Service Mesh causa alrededor de 2 minutos de tiempo de inactividad de conexión. Debes planificar este período durante el cual los servicios de entrega de Knative no puedan conectarse.

• Asegúrate de que el entorno de la línea de comandos esté configurado y actualizado.

Migra a flotas

Para actualizar Anthos a la versión 1.8, primero debes realizar los siguientes pasos a fin de asegurarte de que tu instalación existente de Knative en VMware se migre al uso del componente de flota.

Importante: La mayoría de los pasos de este proceso requieren que configures todos los clústeres de usuario y, por lo tanto, debes repetir varios pasos para cada uno de ellos.

Accede a tu clúster de administrador

Obtén la ruta de acceso y el nombre del archivo kubeconfig del clúster de administrador y, luego, crea la variable de entorno ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

Reemplaza [ADMIN_CLUSTER_KUBECONFIG] por la ruta de acceso y el nombre del archivo por el archivo kubeconfig del clúster de administrador.

Configura cada clúster de usuario

Importante: Si tienes varios clústeres de usuario, debes repetir los pasos de esta sección para cada uno de ellos.

1. Crea las siguientes variables de entorno local para el clúster de usuario:

   1. Crea la variable de entorno USER_KUBECONFIG con la ruta de acceso del archivo kubeconfig del clúster de usuario:

      export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
      

      Reemplaza [USER_CLUSTER_KUBECONFIG] por la ruta de acceso y el nombre del archivo por el archivo kubeconfig del clúster de usuario.

   2. Crea variables de entorno para los siguientes parámetros de configuración:

      • ID de tu proyecto de Google Cloud.
      • Ubicación de tus recursos de Google Cloud.
      • Nombre del clúster de usuario.

      export PROJECT_ID=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-project-id']}")
      export CLUSTER_LOCATION=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-gcp-location']}")
      export CLUSTER_NAME=$(kubectl get configmaps --namespace knative-serving config-observability --output jsonpath="{.data['metrics\.stackdriver-cluster-name']}")
      

2. Quita la configuración cloudrun del recurso personalizado OnPremUserCluster del clúster de usuario:

   1. Verifica que cloudRun esté configurado en OnPremUserCluster:

      $ kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      Resultado:

      {"enabled":true}
      

   2. Quita cloudRun de OnPremUserCluster:

      kubectl patch onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --type="merge" \
        --patch '{"spec": {"cloudRun": null}}'
      

   3. Para validar que cloudRun se haya quitado de OnPremUserCluster de forma correcta, ejecuta el mismo comando de get y verifica que no se muestre ninguna configuración:

      kubectl get onpremusercluster \
        "${CLUSTER_NAME}" \
        --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --output=jsonpath="{.spec.cloudRun}"
      

      No debería haber ningún resultado en tu terminal.

3. Actualiza el secreto create-config del clúster de usuario:

   1. Crea una copia YAML local del archivo create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}" \
        --output=jsonpath={.data.cfg} \
        | base64 -d > "${CLUSTER_NAME}_create_secret.yaml"
      

   2. Abre el archivo ${CLUSTER_NAME}_create_secret.yaml que acabas de crear en un editor y, luego, quita el campo cloudrun de spec.

   3. Codifica en Base64 el archivo ${CLUSTER_NAME}_cluster_create_secret.yaml en un archivo .b64:

      cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
      

   4. En el editor, abre el archivo .b64 local que acabas de crear y, luego, copia la string desde el atributo data.cfg para usarla en el siguiente paso.

      Debes asegurarte de copiar solo el contenido del atributo cfg. Por ejemplo, no incluyas saltos de línea (\n).

   5. Ejecuta el siguiente comando para editar el secreto en el clúster de usuario:

      kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace "${CLUSTER_NAME}"
      

   6. En el editor que se abre, reemplaza el campo data[cfg] por la string que copiaste del archivo .b64 local y, luego, guarda los cambios.

   7. Verifica que los cambios se hayan implementado en el clúster de usuario y que el atributo cloudrun se haya quitado de forma correcta de los secretos create-config:

      kubectl get secret create-config \
        --kubeconfig="${ADMIN_KUBECONFIG}" \
        --namespace ${CLUSTER_NAME} \
        --output=jsonpath={.data.cfg} \
        | base64 -d
      

4. Configura el espacio de nombres knative-serving en el clúster de usuario:

   1. Borra el operador cloudrun-operator del espacio de nombres knative-serving:

      kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
      

   2. Aplica un parche al configmap config-network en el espacio de nombres knative-serving:

      kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
      

5. Quita la configuración cloudrun.enabled del archivo de configuración del clúster de usuario user-config.yaml de tu instalación de GKE en VMware.

   Los siguientes atributos deben borrarse del archivo user-config.yaml:

   cloudRun:
     enabled: true
   

   Cuando realizas la actualización del clúster a la versión 1.8 de Anthos, se implementa este cambio de configuración.

6. Si tienes varios clústeres de usuario, debes repetir todos los pasos de esta sección, “Configura cada clúster de usuario”, para cada uno de ellos.

Configura el componente de tu flota

1. Habilita el componente de entrega de Knative en tu flota:

   gcloud container fleet cloudrun enable --project=$PROJECT_ID
   

   Para obtener detalles y opciones adicionales, consulta la referencia de gcloud container fleet cloudrun enable.

2. Verifica que el componente de función de entrega de Knative esté habilitado (opcional):

   Console

   Observa si el componente de entrega de Knative está Habilitado en la consola de Google Cloud:

   Ir a Funciones de GKE Enterprise

   Línea de comandos

   Comprueba si el estado appdevexperience es ENABLED:

   gcloud container fleet features list --project=$PROJECT_ID
   

   Para obtener detalles y opciones adicionales, consulta la referencia de gcloud container fleet features list.

   Resultado:

   NAME               STATE
   appdevexperience   ENABLED
   

3. Implementa el recurso personalizado CloudRun para instalar la entrega de Knative en VMware en cada uno de tus clústeres de usuario. De forma predeterminada, se implementa la versión latest de la entrega de Knative.

   Importante: Si tienes varios clústeres de usuario, debes repetir este paso para cada uno de ellos.

   Ejecuta el siguiente comando de kubectl apply para implementar la configuración predeterminada de los recursos personalizados de CloudRun:

   cat <<EOF | kubectl apply -f -
   apiVersion: operator.run.cloud.google.com/v1alpha1
   kind: CloudRun
   metadata:
     name: cloud-run
   spec:
     metricscollector:
       stackdriver:
         projectid: $PROJECT_ID
         gcpzone: $CLUSTER_LOCATION
         clustername: $CLUSTER_NAME
         secretname: "stackdriver-service-account-key"
         secretkey: "key.json"
   EOF
   

Configura Anthos Service Mesh

Configura el balanceador de cargas de Anthos Service Mesh para cada uno de los clústeres de usuario.

Importante: Si tienes varios clústeres de usuario, debes repetir los pasos de esta sección para cada uno de ellos.

Puedes configurar la puerta de enlace de entrada de Anthos Service Mesh si configuras una nueva dirección IP externa o reutilizas tu dirección IP existente:

• Con la dirección IP externa nueva que obtuviste, configura el balanceador de cargas mediante los pasos en la documentación de Anthos Service Mesh.

  Ten en cuenta que esta opción garantiza que tus servicios de entrega de Knative se reinicien sin interrupciones.

• Alternativa: Sigue estos pasos para configurar el balanceador de cargas de Anthos Service Mesh en tu dirección IP existente.

  Advertencia: La migración a Anthos Service Mesh mediante tu dirección IP existente causa unos 2 minutos de tiempo de inactividad de conexión. Debes planificar este período, durante el cual los servicios de entrega de Knative no puedan conectarse.

  1. Configura la puerta de enlace de tus servicios a Anthos Service Mesh mediante la ejecución de los siguientes comandos:

     export CURRENT_INGRESS_IP=$(kubectl get service --namespace gke-system istio-ingress --output jsonpath='{.spec.loadBalancerIP}')
     kubectl patch service --namespace istio-system istio-ingressgateway --patch "{\"spec\":{\"loadBalancerIP\": \"$CURRENT_INGRESS_IP\"}}"
     kubectl patch service --namespace gke-system istio-ingress --patch "{\"spec\":{\"loadBalancerIP\": null}}"
     

  2. Quita la configuración actual de Istio:

     kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"local-gateway.cluster-local-gateway": null}}'
     kubectl patch configmap --namespace knative-serving config-istio --patch '{"data":{"gateway.gke-system-gateway": null}}'
     

Verifica la migración

Puedes comprobar si appdevexperience-operator está en funcionamiento para verificar que la entrega de Knative en VMware se haya migrado de forma correcta a tu flota.

Para cada clúster de usuario, ejecuta el siguiente comando:

 kubectl get deployment -n appdevexperience appdevexperience-operator

El operador appdevexperience-operator debe mostrar 1/1 como listo, por ejemplo:

 NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
 appdevexperience-operator   1/1     1            1           1h

Si el operador no logra alcanzar el estado de listo, puedes ver la página de cargas de trabajo de tu clúster en la consola de Google Cloud para identificar los problemas de recursos:

Ir a Cargas de trabajo de Google Kubernetes Engine

Actualiza tu clúster

Ahora que migraste la instalación de Knative entrega en VMware para usar el componente de flota, puedes actualizar tu clúster a la versión 1.8 de Anthos. Sigue las instrucciones detalladas en Actualiza GKE On-Prem.

Soluciona problemas

No se puede completar el proceso de actualización del clúster de usuario

El Pod cluster-local-gateway en el espacio de nombres gke-system puede impedir que el clúster de usuario complete la actualización a la versión 1.8 de Anthos. El Pod cluster-local-gateway ya no es necesario y se puede quitar de forma segura.

A fin de asistir de manualmente con el proceso de actualización, puedes quitar el Pod cluster-local-gateway de forma manual reduciendo la escala vertical de tus réplicas de implementación a 0. Por ejemplo:

1. Reduce verticalmente la escala de cluster-local-gateway:

   kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
   

   Se quitan el Pod cluster-local-gateway en el espacio de nombres gke-system y todas las cargas de trabajo en el espacio de nombres knative-serving.

2. Espera a que se complete el proceso de actualización.

Obtén más información sobre el escalamiento de implementaciones.