Migra de Istio on GKE a Anthos Service Mesh
En esta guía, se muestra cómo actualizar un clúster de Google Kubernetes Engine (GKE) con la versión 1.4 o 1.6 (beta) de Istio en Google Kubernetes Engine (Istio on GKE) a Anthos Service Mesh administrado con el plano de control administrado por Google y la autoridad certificadora de Anthos Service Mesh (CA de Mesh).
Requisitos previos
Para completar esta guía, se requieren los siguientes requisitos:
Un clúster de GKE con Istio on GKE habilitado Si tienes varios clústeres de GKE, sigue los mismos pasos para todos los clústeres.
Istio on GKE debe ser de la versión 1.4 o 1.6.
Asegúrate de estar ejecutando la versión de GKE 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+ o posterior.
El clúster de GKE debe ejecutarse en una de estas ubicaciones.
El usuario o la cuenta de servicio que ejecuta esta secuencia de comandos requiere los permisos de IAM documentados en Configura tu proyecto.
Esta guía se prueba en Cloud Shell, por lo que te recomendamos que uses Cloud Shell para realizar los pasos de esta guía.
Objetivos
- Implementa el plano de control administrado por Google de Anthos Service Mesh en el canal normal. Esta guía es específica para los canales normales; los canales estables o rápidos requieren instrucciones ligeramente modificadas. Para obtener más información sobre los canales de versiones, visita este vínculo.
- Migra los parámetros de configuración de Istio a Anthos Service Mesh.
- Configura la CA de Mesh.
- Migrar aplicaciones a Anthos Service Mesh
- Actualiza
istio-ingressgateway
de Istio on GKE a Anthos Service Mesh. - Finaliza la migración de Anthos Service Mesh o revierte a Istio en GKE.
Configure su entorno
Para configurar tu entorno, sigue estos pasos:
En la consola de Google Cloud, activa Cloud Shell.
En la parte inferior de la consola de Google Cloud, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell con Google Cloud CLI y Google Cloud CLI ya instalados, y con los valores ya establecidos para tu proyecto actual. La sesión puede tardar unos segundos en inicializarse.
Crea las variables de entorno que se usan en esta guía:
# Enter your project ID export PROJECT_ID=PROJECT_ID # Copy and paste the following gcloud config set project ${PROJECT_ID} export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)') export CLUSTER_1=GKE_CLUSTER_NAME export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.
Crea una carpeta
WORKDIR
. Todos los archivos asociados con esta guía terminan enWORKDIR
, por lo que puedes borrarWORKDIR
cuando termines.mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
Crea un archivo
KUBECONFIG
para esta guía. También puedes usar tu archivoKUBECONFIG
existente que contiene el contexto del clúster de GKE que se migrará a Anthos Service Mesh.touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
Obtén credenciales para el clúster de GKE y almacena el contexto en una variable:
Clústeres zonales
gcloud container clusters get-credentials ${CLUSTER_1} \ --zone=${CLUSTER_1_LOCATION} export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
Clústeres regionales
gcloud container clusters get-credentials ${CLUSTER_1} \ --region=${CLUSTER_1_LOCATION} export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
Tus clústeres deben estar registrados en una flota. Este paso se puede realizar por separado antes de la instalación o como parte de ella. Para ello, debes pasar la marca --fleet-id y una de las marcas --enable-all o --enable-registration.
Tu proyecto debe tener habilitada la función de Malla de servicios. Para habilitarlo como parte de la instalación, pasa una de las marcas --enable-all o --enable-registration, o bien ejecuta el siguiente comando antes de la instalación:
gcloud container hub mesh enable --project=FLEET_PROJECT_ID
en el que FLEET_PROJECT_ID es el ID del proyecto host de la flota.
Paso opcional
Si el clúster es privado (con master-authorized-networks
habilitado), agrega tu $SHELL_IP
a la lista de entidades permitidas master-authorized-networks
.
Si ya tienes acceso a tu clúster, es posible que este paso no sea necesario.
Clústeres zonales
export SHELL_IP=$(curl ifconfig.me) gcloud container clusters update ${CLUSTER_1} \ --zone=${CLUSTER_1_LOCATION} \ --enable-master-authorized-networks \ --master-authorized-networks ${SHELL_IP}/32
Clústeres regionales
export SHELL_IP=$(curl ifconfig.me) gcloud container clusters update ${CLUSTER_1} \ --region=${CLUSTER_1_LOCATION} \ --enable-master-authorized-networks \ --master-authorized-networks ${SHELL_IP}/32
Instale Anthos Service Mesh
En esta sección, implementarás Anthos Service Mesh con el plano de control administrado por Google del canal regular en el clúster de GKE. Inicialmente, este plano de control se implementa junto como un segundo plano de control (o canary).
Descarga la versión más reciente de la secuencia de comandos que instala Anthos Service Mesh en el directorio de trabajo actual y haz que la secuencia de comandos sea ejecutable:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli chmod +x asmcli
Para configurar el clúster de GKE, ejecuta la secuencia de comandos de instalación a fin de instalar Anthos Service Mesh con el plano de control administrado por Google del canal regular:
./asmcli install \ -p ${PROJECT_ID} \ -l ${CLUSTER_1_LOCATION} \ -n ${CLUSTER_1} \ --fleet_id ${FLEET_PROJECT_ID} \ --managed \ --verbose \ --output_dir ${CLUSTER_1} \ --enable-all \ --channel regular
Esta operación puede tardar unos minutos en completarse.
Copia
istioctl
en la carpetaWORKDIR
:cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
En la siguiente sección, descargarás y ejecutarás la secuencia de comandos migrate_addon
para ayudar a migrar a Anthos Service Mesh. La utilidad de línea de comandos istioctl
debe estar en la misma carpeta que la secuencia de comandos migrate_addon
. Usas la carpeta WORKDIR
para la utilidad de línea de comandos de istioctl
y la secuencia de comandos migrate_addon
.
Migra los parámetros de configuración a Anthos Service Mesh
En esta sección, migrarás la configuración de Istio on GKE a Anthos Service Mesh. La secuencia de comandos guiada identifica qué configuraciones se pueden migrar y cuáles no.
Descarga la herramienta de migración y haz que sea ejecutable:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon chmod +x ${WORKDIR}/migrate_addon
Inhabilita el webhook de validación de Galley. Este paso es necesario para migrar algunos de los parámetros de configuración de la versión 1.4 a Anthos Service Mesh. Responde
Y
a ambas preguntas:${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook
El resultado es similar al siguiente:
tmpdir directory not present. Create directory? Continue? [Y/n] Y Disabling the Istio validation webhook... Continue? [Y/n] Y Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}] clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deleted
Verifica y migra la configuración de forma manual. Con este paso, puedes identificar algunos de los parámetros de configuración que deben migrarse de forma manual antes de migrar cargas de trabajo al plano de control administrado por Google.
${WORKDIR}/migrate_addon -d tmpdir --command config-check
El resultado es similar al siguiente:
Installing the authentication CR migration tool... OK Checking for configurations that will need to be explicitly migrated... No resources found
Cómo migrar configuraciones personalizadas
Es posible que debas migrar la configuración personalizada de forma manual antes de migrar a Anthos Service Mesh. La secuencia de comandos anterior identifica la configuración personalizada y también imprime información sobre lo que se requiere. Estas personalizaciones son las siguientes:
Los filtros de envío personalizados detectados no son compatibles con Anthos Service Mesh. Si es posible, quítalas. En la actualidad, los filtros de Envoy no son compatibles con el plano de control administrado por Google.
Se detectó un certificado de complemento personalizado. Los certificados del complemento no se migrarán a Anthos Service Mesh. Si se usan certificados de complementos con Istio on GKE, no se usarán después de que las cargas de trabajo migren al plano de control administrado por Google. Todas las cargas de trabajo usan certificados firmados por la CA de Google Mesh. Los certificados de complementos no son compatibles con la CA de Mesh. Este mensaje es informativo y no se requiere ninguna acción.
Se detectaron políticas de seguridad que no se pudieron migrar. <Error reason>. Por lo general, esto falla debido a las políticas de AuthZ alfa que se deben migrar de forma manual. Para obtener más información y contexto sobre cómo migrar políticas, consulta Migra la política de seguridad previa de Istio 1.4 Alfa a las APIs actuales. Para obtener más información sobre el mensaje de error, consulta security-policy-migration.
Se detectó una configuración de VirtualService posiblemente incompatible. <Configuración específica obsoleta>. Debes actualizar las siguientes configuraciones de
VirtualService
:- No se admite el uso de
appendHeaders
. Utilizaspec.http.headers
en lugar de esta función. - No es necesario usar
websocketUpgrade
. Está activada de forma predeterminada. - Reemplaza el campo
abort.percent
conabort.percentage
.
- No se admite el uso de
Se detectó la instalación personalizada de recursos del mezclador que no se pudieron migrar. Requiere una migración manual a telemetryv2. Si se configuran políticas de mezclador personalizadas además de la instalación predeterminada de Istio on GKE, debes migrarlas de forma manual a Telemetry v2. Para obtener más información sobre cómo hacerlo, consulta Personaliza las métricas de Istio.
La implementación <deploymentName> podría ser una puerta de enlace personalizada. Migrar esto de forma manual Debes migrar de forma manual todas las implementaciones de puerta de enlace que no sean
istio-ingressgateway
(que se instala de forma predeterminada). Si deseas obtener información sobre cómo actualizar las puertas de enlace para el plano de control administrado por Google, consulta Configura el plano de control administrado por Google.
Para migrar los parámetros de configuración, sigue estos pasos:
Migra manualmente todas las opciones de configuración personalizadas (excepto la última configuración detallada) antes de continuar con el paso 2.
Usa la herramienta de migración para migrar los parámetros de configuración que se pueden migrar (o ignorar) de forma automática.
${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs
El resultado es similar al siguiente:
Converting authentication CRs... 2021/06/25 20:44:58 found root namespace: istio-system 2021/06/25 20:44:59 SUCCESS converting policy /default Running: kubectl apply --dry-run=client -f beta-policy.yaml peerauthentication.security.istio.io/default created (dry run) Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y Running: kubectl apply -f beta-policy.yaml peerauthentication.security.istio.io/default created OK
Aplica la relación de confianza raíz de la CA de Mesh. Esto te permite migrar de la CA actual de Citadel a la CA de Mesh sin generar tiempo de inactividad en tus aplicaciones.
${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca
El resultado es similar al siguiente:
Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y Running: kubectl get cm -n istio-system istio-asm-managed -oyaml Running: kubectl -n istio-system apply -f - secret/meshca-root created Running: kubectl get cm istio -n istio-system -o yaml Running: kubectl get cm istio -n istio-system -o yaml Running: kubectl replace -f - configmap/istio replaced Running: kubectl get deploy istio-pilot -n istio-system -o yaml Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{ "name":"discovery", "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12", "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}] }]}}}} deployment.apps/istio-pilot patched Running: kubectl get deploy istio-citadel -n istio-system -o yaml Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{ "containers":[{ "name":"citadel", "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"], "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}] }], "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}] }}}} deployment.apps/istio-citadel patched OK Waiting for root certificate to distribute to all pods. This will take a few minutes... ASM root certificate not distributed to asm-system, trying again later ASM root certificate not distributed to asm-system, trying again later ASM root certificate distributed to namespace asm-system ASM root certificate distributed to namespace default ASM root certificate distributed to namespace istio-operator ASM root certificate not distributed to istio-system, trying again later ASM root certificate not distributed to istio-system, trying again later ASM root certificate distributed to namespace istio-system ASM root certificate distributed to namespace kube-node-lease ASM root certificate distributed to namespace kube-public ASM root certificate distributed to namespace kube-system ASM root certificate distributed to namespace online-boutique Waiting for proxies to pick up the new root certificate... OK Configuring Istio Addon 1.6 to trust Anthos Service Mesh... Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml Running: kubectl replace -f - configmap/istio-istio-1611 replaced Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge istiooperator.install.istio.io/istio-1-6-11-gke-0 patched Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem} Running: kubectl -n istio-system patch secret istio-ca-secret secret/istio-ca-secret patched Running: kubectl patch deploy istiod-istio-1611 -n istio-system deployment.apps/istiod-istio-1611 patched Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination... deployment "istiod-istio-1611" successfully rolled out Running: kubectl apply -f - -n istio-system envoyfilter.networking.istio.io/trigger-root-cert created Waiting for proxies to pick up the new root certificate... Running: kubectl delete envoyfilter trigger-root-cert -n istio-system OK
En este paso, el certificado raíz de Anthos Service Mesh tarda unos minutos en distribuirse a todos los espacios de nombres. Espera hasta que la secuencia de comandos termine con un mensaje
OK
.
En el paso anterior, se hace lo siguiente:
- Instala la raíz de confianza de la CA de Mesh para todas las cargas de trabajo del clúster.
Cambia la configuración de las implementaciones del plano de control
istio-pilot
,istiod
yistio-citadel
. Entre los cambios, se incluyen los siguientes:- Actualiza las imágenes a las compilaciones más recientes.
- Inhabilita la verificación de
trust-domain
configurandoPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true
. - Agrega la raíz de confianza de la CA de Mesh a
istio-citadel
para distribuirConfigMap
a todos los espacios de nombres. - Agregar la raíz de confianza de la CA de Mesh a
istio-ca-secret
para distribuir el certificado raíz
Almacena los manifiestos de configuración anteriores en el
tmpdir
.Proporciona pasos para la función de reversión (que se documentan más adelante).
Migra cargas de trabajo a Anthos Service Mesh
En esta sección, migrarás las cargas de trabajo que se ejecutan en Istio on GKE a Anthos Service Mesh. Después de la migración, verifica que se inserten los proxies de sidecar correctos (Anthos Service Mesh) en cada Pod y que la aplicación funcione como se espera.
Si realizas este procedimiento en un clúster existente, selecciona el espacio de nombres que se migrará.
Define el espacio de nombres como una variable. Este espacio de nombres se migra a Anthos Service Mesh:
export NAMESPACE=NAMESPACE_NAME
Para migrar cargas de trabajo a Anthos Service Mesh, debes volver a etiquetar el espacio de nombres de Anthos Service Mesh. El etiquetado del espacio de nombres permite que Anthos Service Mesh incorpore de forma automática los sidecars a todas las cargas de trabajo. Para etiquetar el espacio de nombres, ejecuta el siguiente comando y configura la etiqueta como
asm-managed
:kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite
Realiza un reinicio progresivo de todos los objetos Deployment en el espacio de nombres:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
El resultado es similar al siguiente:
deployment.apps/deploymentName1 restarted deployment.apps/deploymentName2 restarted ...
Asegúrate de que todos los Pods se reinicien y se ejecuten con dos contenedores por Pod:
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
El resultado es similar al siguiente:
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
Una buena forma de verificar este paso es observar el
AGE
de los Pods. Asegúrate de que el valor sea corto, por ejemplo, de unos minutos.Verifica la versión del proxy de Envoy del archivo adicional desde cualquiera de los Pods de cualquier Deployment en el espacio de nombres para confirmar que ahora tienes los proxies de Envoy de Anthos Service Mesh implementados:
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'
El resultado es similar al siguiente:
"gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3" "appContainerImage"
Verifica y prueba tus aplicaciones después de reiniciar.
kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
(Opcional) Si quieres que Google administre las actualizaciones de los proxies, habilita el plano de datos administrado por Google
Consulta el estado de la migración
Ejecuta el siguiente comando para ver el estado de la migración:
kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}
El resultado indica si las migraciones están completas, pendientes o con errores:
{"migrationStatus":"SUCCESS"} {"migrationStatus":"PENDING"} {"migrationStatus":"MIGRATION_CONFIG_ERROR"} {"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}
Si migrationStatus
muestra SUCCESS
, el plano de control se actualizó de forma correcta a Anthos Service Mesh. Para actualizar el plano de datos de forma manual, completa los pasos que se indican en Migra cargas de trabajo.
Si migrationStatus
genera un estado distinto de SUCCESS
, puedes elegir una de las siguientes opciones:
- No debes realizar ninguna acción adicional si el error de migración no afecta tus cargas de trabajo de Istio existentes en GKE. De lo contrario, deberás realizar una rollback si es necesario.
- Actualiza la configuración personalizada en el clúster y vuelve a ejecutar la migración de forma manual si
migrationStatus
muestraMIGRATION_CONFIG_ERROR
.
Puedes ver las métricas del plano de control en el Explorador de métricas después de una migración correcta. Consulta verify_control_plane_metrics
Accede a los paneles de Anthos Service Mesh
En esta sección, ve a los paneles de Anthos Service Mesh y asegúrate de recibir los indicadores de oro para todos los objetos Service. También deberías poder ver la topología de tu aplicación.
En la consola de Google Cloud, ve a la página Anthos Service Mesh.
Debería poder ver las métricas y la topología de los objetos Service.
Para obtener más información sobre los paneles de Anthos Service Mesh, consulta Explora Anthos Service Mesh en la consola de Google Cloud.
Completar una migración exitosa
En esta sección, finalizarás tu migración de Istio on GKE a Anthos Service Mesh. Antes de continuar con esta sección, asegúrate de que deseas continuar con Anthos Service Mesh. Esta sección también te ayuda a limpiar los artefactos de Istio on GKE. Si deseas revertir a Istio en GKE, continúa con la siguiente sección.
Reemplaza
istio-ingressgateway
(parte de Istio on GKE estándar) por la puerta de enlace con control de versiones del plano de control administrado por Google:${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway
El resultado es similar al siguiente:
Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite label "istio.io/rev" not found. namespace/istio-system labeled Running: kubectl apply -f - serviceaccount/asm-ingressgateway created deployment.apps/asm-ingressgateway created role.rbac.authorization.k8s.io/asm-ingressgateway created rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system deployment.apps/asm-ingressgateway condition met Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}} horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change) Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0 deployment.apps/istio-ingressgateway scaled OK
Vuelve a configurar el webhook para usar el plano de control administrado por Google. Todas las cargas de trabajo comienzan con el plano de control administrado por Google:
${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook
El resultado es similar al siguiente:
Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}] mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default' OK
Vuelve a etiquetar todos los espacios de nombres con la etiqueta de Anthos Service Mesh y realiza un reinicio progresivo de todas las cargas de trabajo para colocarlas en el plano de control administrado por Google:
export NAMESPACE=NAMESPACE_NAME \ kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite` kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
Puedes ignorar el mensaje
"istio-injection not found"
en el resultado. Esto significa que el espacio de nombres no tenía la etiquetaistio-injection
, que debería aparecer en las nuevas instalaciones de Anthos Service Mesh o en implementaciones nuevas. Debido a que la inserción automática falla si un espacio de nombres tiene las etiquetasistio-injection
y de revisión, todos los comandoskubectl label
en la documentación de Istio on GKE incluyen quitar la etiquetaistio-injection
.Ejecuta el siguiente comando para finalizar la migración:
${WORKDIR}/migrate_addon -d tmpdir --command write-marker
El resultado es similar al siguiente:
Current migration state: SUCCESS Running: kubectl apply -f - configmap/asm-addon-migration-state created OK
Inhabilita Istio en GKE mediante la ejecución del siguiente comando:
Clústeres zonales
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --zone=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLED
Clústeres regionales
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --region=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLED
Ejecuta el siguiente comando para limpiar la configuración:
${WORKDIR}/migrate_addon -d tmpdir --command cleanup
El resultado es similar a este:
Cleaning up old resources... Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus} Will delete IstioOperator/istio-1-6-11-gke-0.istio-system Will delete ServiceAccount/istio-citadel-service-account.istio-system ... Will delete DestinationRule/istio-policy.istio-system Will delete DestinationRule/istio-telemetry.istio-system Will delete Secret/istio-ca-secret.istio-system Deleting resources previously listed... Continue? [Y/n] Y Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found ... Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found secret "istio-ca-secret" deleted Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security job.batch "istio-security-post-install-1.4.10-gke.8" deleted
Asegúrate de que las implementaciones y los servicios de Istio on GKE se hayan quitado de forma correcta del clúster:
kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services
El resultado es similar al siguiente:
NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/asm-ingressgateway 1/1 1 1 10m NAME TYPE CLUSTER-IP EXTERNAL-IP AGE PORT(S) service/istio-ingressgateway LoadBalancer 10.64.5.208 34.139.100.237 95m 15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP
Solo verás el Service y la Deployment de la puerta de enlace de entrada de Anthos Service Mesh.
Felicitaciones. Migraste de forma correcta de Istio on GKE a Anthos Service Mesh con el plano de control administrado por Google y la CA de Mesh sin tiempo de inactividad en tus aplicaciones.
Cómo revertir cambios
En esta sección, si no deseas continuar con Anthos Service Mesh, puedes revertir los cambios de Anthos Service Mesh. Después de completar esta sección, tus cargas de trabajo regresarán a Istio on GKE.
Revierte los cambios del webhook de mutación:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook
Vuelve a etiquetar los espacios de nombres para usar la inyección del archivo adicional de Istio on GKE en lugar de Anthos Service Mesh mediante la ejecución del siguiente comando:
Para espacios de nombres con cargas de trabajo de la versión 1.4:
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
Para espacios de nombres con cargas de trabajo de la versión 1.6:
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite
Realiza un reinicio progresivo de todos los objetos Deployment en el espacio de nombres:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
Espera unos minutos y asegúrate de que todos los Pods se estén ejecutando:
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
El resultado es similar al siguiente:
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
Verifica la versión del proxy de Envoy del archivo adicional desde cualquiera de los Pods para confirmar que tienes los proxies de Envoy de Istio on GKE v1.4 implementados:
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'
El resultado es similar al siguiente:
"gke.gcr.io/istio/proxyv2:1.4.10-gke.8" "appContainerImage"
o
"gke.gcr.io/istio/proxyv2:1.6.14-gke.4" "appContainerImage"
Verifica y prueba tus aplicaciones después de reiniciar.
Revierte los cambios de la AC de Mesh:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
Vuelve a habilitar el webhook de Istio Galley:
${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
Revirtiste correctamente tus cambios en Istio on GKE.
Implementa Online Boutique
En esta sección, implementarás una aplicación de muestra basada en microservicios llamada Online Boutique en el clúster de GKE. Online Boutique se implementa en un espacio de nombres habilitado para Istio. Verifica que la aplicación funcione y que Istio on GKE inserte los proxies de sidecar a cada Pod.
Si ya tienes clústeres existentes con aplicaciones, puedes omitir la creación de un espacio de nombres nuevo y la implementación de Online Boutique. Puedes seguir el mismo proceso para todos los espacios de nombres en la sección Migra cargas de trabajo a Anthos Service Mesh.
Implementa Online Boutique en el clúster de GKE:
kpt pkg get \ https://github.com/GoogleCloudPlatform/microservices-demo.git/release \ online-boutique kubectl --context=${CLUSTER_1_CTX} create namespace online-boutique kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutique
Espera hasta que todos los objetos Deployment estén listos:
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice
Asegúrate de que haya dos contenedores por pod: el contenedor de la aplicación y el proxy de sidecar de Istio que Istio on GKE inserta de forma automática en el Pod:
kubectl --context=${CLUSTER_1_CTX} -n online-boutique get pods
El resultado es similar al siguiente:
NAME READY STATUS RESTARTS AGE adservice-7cbc9bd9-t92k4 2/2 Running 0 3m21s cartservice-d7db78c66-5qfmt 2/2 Running 1 3m23s checkoutservice-784bfc794f-j8rl5 2/2 Running 0 3m26s currencyservice-5898885559-lkwg4 2/2 Running 0 3m23s emailservice-6bd8b47657-llvgv 2/2 Running 0 3m27s frontend-764c5c755f-9wf97 2/2 Running 0 3m25s loadgenerator-84cbcd768c-5pdbr 2/2 Running 3 3m23s paymentservice-6c676df669-s779c 2/2 Running 0 3m25s productcatalogservice-7fcf4f8cc-hvf5x 2/2 Running 0 3m24s recommendationservice-79f5f4bbf5-6st24 2/2 Running 0 3m26s redis-cart-74594bd569-pfhkz 2/2 Running 0 3m22s shippingservice-b5879cdbf-5z7m5 2/2 Running 0 3m22s
También puedes verificar la versión del proxy de Envoy del archivo adicional desde cualquiera de los Pods para confirmar que tienes los proxies de Envoy de Istio on GKE v1.4 implementados:
export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_1_CTX} -o jsonpath='{.items[0].metadata.name}') kubectl --context=${CLUSTER_1_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'
El resultado es similar al siguiente:
"gke.gcr.io/istio/proxyv2:1.4.10-gke.8" "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
Para acceder a la aplicación, navega a la dirección IP de la dirección IP del objeto Service
istio-ingressgateway
:kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
Preguntas frecuentes
En esta sección, se describen las preguntas frecuentes y las respuestas relacionadas sobre la migración de Istio on GKE a Anthos Service Mesh.
¿Por qué se me está migrando de Istio on GKE a Anthos Service Mesh?
Istio en Google Kubernetes Engine es una función beta que implementa Istio administrado por Google en un clúster de Google Kubernetes Engine (GKE). Istio on GKE implementa una versión no compatible (versión 1.4 de Istio). Para brindarte las funciones más recientes de la malla de servicios y una implementación compatible de la malla de servicios, actualizaremos todos los usuarios de Istio on GKE a Anthos Service Mesh.
Anthos Service Mesh es el producto de malla de servicios administrado y compatible de Google con la tecnología de las APIs de Istio. Anthos Service Mesh es para Istio lo que GKE es para Kubernetes. Debido a que Anthos Service Mesh se basa en las API de Istio, puedes seguir usando tus parámetros de configuración de Istio cuando migres a Anthos Service Mesh. Además, no hay que estar atado a un proveedor.
Anthos Service Mesh proporciona los siguientes beneficios:
- Una malla de servicios administrada por Google y compatible con Google.
- API de Istio sin dependencia con un proveedor
- Paneles de telemetría listos para usar y administración de los SLO sin la necesidad de administrar soluciones de terceros adicionales.
- Opciones de autoridades certificadoras alojadas en Google.
- Integración con las herramientas de redes de Google Cloud e Identity-Aware Proxy (IAP)
- Compatibilidad con plataformas híbridas y de múltiples nubes.
Para obtener más información sobre las características y funciones de Anthos Service Mesh, consulta Funciones compatibles con el plano de control administrado por Google.
¿Hay algún tiempo de inactividad asociado con esta migración?
La secuencia de comandos de migración está diseñada para evitar el tiempo de inactividad. La secuencia de comandos instala Anthos Service Mesh como un plano de control de versiones canary junto con el plano de control de Istio existente. istio-ingressgateway
se actualiza en el lugar. Luego, vuelve a etiquetar los espacios de nombres habilitados para Istio para comenzar a usar Anthos Service Mesh con la autoridad certificada de Anthos Service Mesh (CA de Mesh).
Asegúrate de tener PodDisruptionBudgets configurado correctamente para tus aplicaciones, de modo que no experimentes ningún tiempo de inactividad de la aplicación. Aunque puedes evitar el tiempo de inactividad, si realizas esta migración por tu cuenta, te recomendamos que la realices durante un período de mantenimiento programado. Las migraciones que impulsa Google se realizan durante un período de mantenimiento de GKE. Asegúrate de que tus clústeres de GKE tengan períodos de mantenimiento configurados.
¿Hay algún costo asociado con el uso de Anthos Service Mesh?
Existen dos formas de usar Anthos Service Mesh en GKE:
Si eres suscriptor de GKE Enterprise, Anthos Service Mesh se incluye como parte de tu suscripción a GKE Enterprise.
Si no eres suscriptor de GKE Enterprise, puedes usar Anthos Service Mesh como producto independiente en GKE (en Google Cloud). Para obtener más información, consulta los detalles de precios de Anthos Service Mesh.
¿Hay funciones o parámetros de configuración que no son compatibles con la versión más reciente de Anthos Service Mesh?
La secuencia de comandos verifica todas las opciones de configuración de Istio y las migra a la versión más reciente de Anthos Service Mesh. Hay ciertas configuraciones que pueden requerir pasos adicionales para migrar de la versión 1.4 de Istio a la versión 1.10 de Anthos Service Mesh. La secuencia de comandos realiza una verificación de configuración y te informa si alguna configuración requiere pasos adicionales.
¿Cambia la migración mis configuraciones actuales de Istio?
No, las configuraciones de Istio funcionan en Anthos Service Mesh sin necesidad de ningún cambio.
Después de migrar a Anthos Service Mesh, ¿puedo migrar a Istio?
Sí, no hay compromiso de usar Anthos Service Mesh. Puedes desinstalar Anthos Service Mesh y volver a instalar Istio en cualquier momento.
Si la migración falla, ¿es posible revertirla?
Sí, la secuencia de comandos te permite revertir a tu versión anterior de Istio on GKE.
¿Qué versión de Istio puedo migrar con esta secuencia de comandos?
La secuencia de comandos te ayuda a migrar de la versión 1.4 de Istio on GKE a la versión 1.10 de Anthos Service Mesh. La secuencia de comandos valida tu versión de Istio durante la etapa previa a la migración y te informa si se puede migrar la versión de Istio.
¿Cómo puedo obtener ayuda adicional con esta migración?
Nuestro equipo de asistencia al cliente le brindará ayuda con gusto. Puedes abrir un caso de asistencia desde la consola de Google Cloud. Para obtener más información, consulta Administra casos de asistencia.
¿Qué sucede si no migro a Anthos Service Mesh?
Tus componentes de Istio continúan funcionando, pero Google ya no administra tu instalación de Istio. Ya no recibirás actualizaciones automáticas, y no se garantiza que la instalación funcione a medida que se actualiza la versión del clúster de Kubernetes.
Para obtener más información, consulta la asistencia de Istio.