Aprende a migrar Knative serving en VMware para usar flotas de modo que puedas hacer lo siguiente: y actualizar a la versión 1.8.
Knative serving ahora es una experiencia independiente de la administrada Cloud Run y ahora se proporciona como un componente de la flota en tus clústeres. Instala funciones de Knative serving en VMware como un de tu flota te permite administrar y actualizar tus de la instalación independientemente de otros componentes de la flota.
En un nivel alto, si quieres migrar tu instalación de Knative serving en VMware para usar un flota, debes hacer lo siguiente:
- Configura tu instalación de Knative serving en VMware para cumplir con los los requisitos de la flota.
- Habilita el componente de función Knative serving en tu de la flota.
Ten en cuenta que el servidor de la API de Kubernetes no se verá afectado durante esta migración.
Para obtener detalles sobre cómo realizar una nueva instalación de Knative serving en VMware, ver Instala Knative serving en VMware.
Antes de comenzar
Debes cumplir con los siguientes requisitos:
Estos pasos requieren que tu clúster de Knative serving en VMware esté registrado en una flota y sea visible en la consola de Google Cloud:
Tu instalación de Knative serving en VMware se encuentra en un clúster con la versión 1.7 o anterior de Anthos.
Istio ya no es compatible con Anthos 1.8. Versión de Cloud Service Mesh 1.18 debe estar instalado en tu flota y la instalación de Knative serving debe configurarse antes de actualizar ese clúster a Versión 1.8.
Consulta las instrucciones de la malla de servicios de Cloud para obtener detalles 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 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 Knative serving En Cloud Service Mesh, puedes hacer lo siguiente:
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.
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 sigue estos pasos para garantizar que tu servicio existente de Knative serving de la instalación se migra al componente de flota.
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
Crea las siguientes variables de entorno local para el clúster de usuario:
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.
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']}")
Quita la configuración
cloudrun
del recurso personalizadoOnPremUserCluster
del clúster de usuario:Verifica que
cloudRun
esté configurado enOnPremUserCluster
:$ kubectl get onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --output=jsonpath="{.spec.cloudRun}"
Resultado:
{"enabled":true}
Quita
cloudRun
deOnPremUserCluster
:kubectl patch onpremusercluster \ "${CLUSTER_NAME}" \ --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \ --kubeconfig="${ADMIN_KUBECONFIG}" \ --type="merge" \ --patch '{"spec": {"cloudRun": null}}'
Para validar que
cloudRun
se haya quitado deOnPremUserCluster
de forma correcta, ejecuta el mismo comando deget
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.
Actualiza el secreto create-config del clúster de usuario:
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"
Abre el archivo
${CLUSTER_NAME}_create_secret.yaml
que acabas de crear en un editor y, luego, quita el campocloudrun
despec
.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"
En el editor, abre el archivo
.b64
local que acabas de crear y, luego, copia la string desde el atributodata.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
).Ejecuta el siguiente comando para editar secreto en el clúster de usuario:
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \ --namespace "${CLUSTER_NAME}"
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.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 secretoscreate-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 el clúster de usuario:Borra el operador
cloudrun-operator
del espacio de nombresknative-serving
:kubectl delete deployments.apps --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving cloudrun-operator
Aplica un parche al configmap
config-network
en el espacio de nombresknative-serving
:kubectl patch configmap --kubeconfig=${USER_KUBECONFIG} --namespace knative-serving config-network --patch '{"metadata": {"annotations":{"knative.dev/example-checksum": null}}}'
Quita la configuración
cloudrun.enabled
del clúster de usuario archivo de configuraciónuser-config.yaml
de tu instalación de Google Distributed Cloud.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.
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
Habilita el componente de Knative serving 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.
Opcional: Verifica que el componente de la función Knative serving habilitado:
Console
Consulta si el componente de Knative serving está Habilitado en la Consola de Google Cloud:
Línea de comandos
Comprueba si el estado
appdevexperience
esENABLED
: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
Implementa el recurso personalizado
CloudRun
para realizar la instalación Knative serving en VMware en cada uno de tus clústeres de usuario. De forma predeterminada, el Se implementólatest
versión de Knative serving.Ejecuta el siguiente comando de
kubectl apply
para implementar la configuración predeterminada de los recursos personalizados deCloudRun
: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 Cloud Service Mesh
Configurar el balanceador de cargas de la malla de servicios de Cloud para cada uno de los clústeres de usuario
Puedes configurar la puerta de enlace de entrada de Cloud Service Mesh de las siguientes maneras: Configura una dirección IP externa nueva o reutiliza la dirección IP existente:
Con la nueva dirección IP externa que obtuviste, configura la carga el balanceador siguiendo los pasos Documentación de Cloud Service Mesh.
Ten en cuenta que esta opción garantiza que tus servicios de Knative serving se reinició sin interrupciones.
Alternativa: Usa los siguientes pasos para configurar la malla de servicios de Cloud balanceador de cargas a tu dirección IP existente.
Para configurar la puerta de enlace de tus servicios a Cloud Service Mesh, ejecuta el siguiente comando: 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}}"
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 el appdevexperience-operator
está funcionando para verificar que Knative serving en VMware se ha
se migró correctamente a tu flota.
Para cada clúster de usuario, ejecuta el siguiente comando:
kubectl get deployment -n appdevexperience appdevexperience-operator
El appdevexperience-operator
operador
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 tu instalación de Knative serving en VMware para usar componente de flota, puedes actualizar tu clúster a Anthos Versión 1.8. 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 nombresgke-system
puede impedir que el clúster de usuario complete la actualización a la versión 1.8 de Anthos. El Podcluster-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 a0
. Por ejemplo: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 nombresgke-system
y todas las cargas de trabajo en el espacio de nombresknative-serving
.Espera a que se complete el proceso de actualización.
Obtén más información sobre el escalamiento de implementaciones.