Esta documentación es para la versión más reciente de Knative serving, que usa flotas y Anthos Service Mesh. Obtén más información.

La versión anterior (Cloud Run for Anthos) se archivó, pero la documentación permanece disponible para los usuarios existentes.

Versiones disponibles

Más reciente
Archivo

Esta página se ha traducido con Cloud Translation API.

Actualizar el servicio de Knative en VMware a flotas

Consulta cómo migrar Knative Serving en VMware para usar flotas y, así, poder actualizar a la versión 1.8 de Anthos.

Knative Serving ahora es una experiencia independiente del producto gestionado Cloud Run y se proporciona como un componente de flota en tus clústeres. Instalar Knative Serving en las funciones de VMware como componente de tu flota te permite gestionar y actualizar tu instalación de forma independiente de otros componentes de la flota.

A grandes rasgos, para migrar tu instalación de Knative Serving en VMware para usar una flota, debes hacer lo siguiente:

Configura tu instalación de Knative Serving en VMware para que cumpla los requisitos de la flota.
Habilita el componente de función de servicio de Knative en tu flota.

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

Para obtener información sobre cómo realizar una nueva instalación del servicio de Knative en VMware, consulta el artículo Instalar el servicio de Knative en VMware.

Antes de empezar

Debes cumplir los siguientes requisitos:

Para seguir estos pasos, tu clúster de Knative Serving en VMware debe estar registrado en una flota y ser visible en la consola: Google Cloud

Ir a clústeres de GKE
Tu instalación de Knative Serving en VMware se encuentra 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 Cloud Service Mesh en tu flota y configurar tu instalación de Knative Serving antes de actualizar ese clúster a la versión 1.8.

Consulta las instrucciones de Cloud Service Mesh para obtener información sobre la instalación en Google Distributed Cloud.

Ten en cuenta que Cloud Service Mesh requiere que tu clúster use un tipo de máquina que tenga al menos cuatro vCPUs, como e2-standard-4. Si necesitas cambiar el tipo de máquina de tu clúster, consulta Migrar cargas de trabajo a diferentes tipos de máquinas.
Hay dos opciones para migrar Knative Serving a Cloud Service Mesh:
- Obtén una nueva dirección IP externa en la que configurar el balanceador de carga.
- Reutiliza la dirección IP del balanceador de carga.
  
  Advertencia: El proceso de reutilización de una dirección IP para configurar Cloud Service Mesh provoca un tiempo de inactividad de la conexión de aproximadamente 2 minutos. Debes planificar este periodo durante el cual tus servicios de Knative Serving no podrán conectarse.
Asegúrate de que tu entorno de línea de comandos esté configurado y actualizado.

Migrar a flotas

Para actualizar Anthos a la versión 1.8, primero debes seguir estos pasos para asegurarte de que tu instalación de Knative Serving en VMware se migre para usar el componente de flota.

Acceder a tu clúster de administrador

Obtén la ruta y el nombre de archivo del archivo kubeconfig de tu clúster de administrador y, a continuación, crea la variable de entorno ADMIN_KUBECONFIG:

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

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

Configurar cada clúster de usuarios

Crea las siguientes variables de entorno locales para el clúster de usuarios:

Crea la variable de entorno USER_KUBECONFIG con la ruta del archivo kubeconfig de tu clúster de usuario:
```
export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
```
Sustituye [USER_CLUSTER_KUBECONFIG] por la ruta y el nombre de archivo del archivo kubeconfig de tu clúster de usuario.

Crea variables de entorno para las siguientes configuraciones:

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

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']}")

Elimina la configuración de cloudrun del recurso personalizado OnPremUserCluster de tu clúster de usuarios:

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}

Quitar cloudRun de OnPremUserCluster:

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

Valida que cloudRun se ha quitado correctamente de OnPremUserCluster. Para ello, ejecuta el mismo comando get y comprueba que no se devuelve ninguna configuración:
```
kubectl get onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --output=jsonpath="{.spec.cloudRun}"
```
No debería aparecer ningún resultado en tu terminal.

Actualiza el secreto create-config de tu clúster de usuarios:
1. Crea una copia local en formato YAML 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, a continuación, elimina el campo cloudrun de spec.
3. Codifica el archivo ${CLUSTER_NAME}_cluster_create_secret.yaml en Base64 para obtener un archivo .b64:
```
cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
```
4. En tu editor, abre el archivo .b64 local que acabas de crear y copia la cadena del atributo data.cfg para usarla en el siguiente paso.
  
  Debe asegurarse de copiar solo el contenido del atributo cfg. Por ejemplo, no incluya ningún salto de línea (\n).
5. Ejecuta el siguiente comando para editar el secreto en tu clúster de usuario:
```
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}"
```
6. En el editor que se abre, sustituye el campo data[cfg] por la cadena que has copiado del archivo .b64 local y, a continuación, guarda los cambios.
7. Verifica que los cambios se hayan implementado en tu clúster de usuarios y que el atributo cloudrun se haya eliminado correctamente de los secretos create-config:
```
kubectl get secret create-config \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace ${CLUSTER_NAME} \
  --output=jsonpath={.data.cfg} \
  | base64 -d
```

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

Elimina el operador cloudrun-operator del knative-serving espacio de nombres:

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

Aplica un parche al mapa de configuración 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}}}'

Elimina la configuración de cloudrun.enabled del archivo de configuración del clúster de usuarios user-config.yaml de tu instalación de Google Distributed Cloud.

Debe eliminar los siguientes atributos del archivo user-config.yaml:
```
cloudRun:
  enabled: true
```
Cuando actualices el clúster a la versión 1.8 de Anthos, se implementará este cambio de configuración.
Si tienes varios clústeres de usuarios, debes repetir todos los pasos de la sección "Configurar cada clúster de usuarios" para cada clúster de usuarios.

Configurar el componente de flota

Habilita el componente de servicio de Knative en tu flota:
```
gcloud container fleet cloudrun enable --project=$PROJECT_ID
```
Para obtener más información y ver otras opciones, consulta la referencia de gcloud container fleet cloudrun enable.
Opcional: Verifica que el componente de la función de servicio de Knative esté habilitado:
Consola
Comprueba si el componente de servicio de Knative está habilitado en la Google Cloud consola:

Ir a Gestor de funciones
Línea de comandos
Para ver si el estado appdevexperience es ENABLED, haz lo siguiente:
```
gcloud container fleet features list --project=$PROJECT_ID
```
Para obtener más información y ver otras opciones, consulta la lista de funciones de gcloud container fleet.

Resultado:
```
NAME               STATE
appdevexperience   ENABLED
```
Despliega el recurso personalizado CloudRun para instalar el servicio de Knative en VMware en cada uno de tus clústeres de usuario. De forma predeterminada, se implementa la versión latest de Knative Serving.

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

Ejecuta el siguiente comando kubectl apply para implementar la configuración predeterminada del recurso personalizado 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
```

Configurar Cloud Service Mesh

Configura el balanceador de carga de Cloud Service Mesh para cada uno de tus clústeres de usuario.

Puedes configurar la pasarela de entrada de Cloud Service Mesh de dos formas: configurando una nueva dirección IP externa o reutilizando la que ya tienes:

Con la nueva dirección IP externa que has obtenido, configura el balanceador de carga siguiendo los pasos que se indican en la documentación de Cloud Service Mesh.

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

Alternativa: Sigue estos pasos para configurar el balanceador de carga de Cloud Service Mesh en tu dirección IP.

Configura la pasarela de tus servicios en Cloud Service Mesh ejecutando 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}}"

Elimina los ajustes de configuración de Istio actuales:

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}}'

Verificar la migración

Puedes comprobar si appdevexperience-operator está en funcionamiento para verificar que tu servicio de Knative en VMware se ha migrado correctamente a tu flota.

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

 kubectl get deployment -n appdevexperience appdevexperience-operator

El appdevexperience-operator operador debería 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 consigue alcanzar el estado de preparado, puedes ver la página de cargas de trabajo de tu clúster en la Google Cloud consola para identificar problemas con los recursos:

Ir a las cargas de trabajo de Google Kubernetes Engine

Actualizar un clúster

Ahora que has migrado tu instalación de Knative Serving en VMware para usar el componente de flota, puedes actualizar tu clúster a Anthos 1.8. Sigue las instrucciones detalladas que se indican en el artículo Actualizar GKE On-Prem.

Solución de problemas

El proceso de actualización del clúster de usuarios no se completa

El pod cluster-local-gateway del espacio de nombres gke-system puede impedir que tu 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 sin problemas.

Para ayudar manualmente en el proceso de actualización, puedes quitar manualmente el pod cluster-local-gateway reduciendo las réplicas de tu implementación a 0. Por ejemplo:

Reduce la escala de cluster-local-gateway:
```
kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
```
Se elimina el pod cluster-local-gateway del espacio de nombres gke-system y todas las cargas de trabajo del espacio de nombres knative-serving.
Espera a que se complete el proceso de actualización.

Consulta más información sobre cómo escalar implementaciones.