Cette documentation concerne la version la plus récente de Knative serving, qui utilise les parcs et Anthos Service Mesh. En savoir plus

L'ancienne version (Cloud Run for Anthos) a été archivée, mais la documentation reste disponible pour les utilisateurs existants.

Versions disponibles

Le plus récent
Archiver

Mettre à niveau Knative serving sur VMware vers des parcs

Découvrez comment migrer Knative serving sur VMware afin d'utiliser des parcs pour effectuer la mise à niveau vers la version 1.8 d'Anthos.

Knative serving est désormais dissocié du produit Cloud Run géré. Il est désormais fourni en tant que composant de parc dans vos clusters. L'installation des fonctionnalités de Knative serving sur VMware en tant que composant de votre parc vous permet de gérer et de mettre à niveau votre installation indépendamment des autres composants du parc.

En règle générale, pour migrer votre installation Knative serving sur VMware afin d'utiliser un parc, vous devez effectuer les actions suivantes :

Configurer votre installation Knative serving sur VMware pour répondre aux exigences du parc.
Activer le composant de fonctionnalité Knative serving dans votre parc.

Notez que le serveur d'API Kubernetes n'est pas affecté lors de cette migration.

Pour en savoir plus sur la façon d'effectuer une nouvelle installation de Knative serving sur VMware, consultez la page Installer Knative serving sur VMware.

Avant de commencer

Vous devez remplir les conditions suivantes :

Pour suivre cette procédure, votre cluster Knative serving sur VMware doit être enregistré dans un parc et être visible dans la console Google Cloud :

Accéder aux clusters GKE
Votre installation Knative serving sur VMware s'effectue sur un cluster exécutant Anthos version 1.7 ou antérieure.
Istio n'est plus compatible avec Anthos 1.8. Vous devez installer la version 1.18 de Cloud Service Mesh dans votre parc et configurer votre installation Knative serving avant de mettre à niveau le cluster vers la version 1.8.

Consultez les instructions de Cloud Service Mesh pour en savoir plus sur l'installation sur Google Distributed Cloud.

Notez que Cloud Service Mesh nécessite que votre cluster utilise un type de machine comportant au moins quatre processeurs virtuels, tels que e2-standard-4. Si vous devez modifier le type de machine de votre cluster, consultez la page Migrer des charges de travail vers différents types de machines.
Deux options sont possibles pour migrer Knative serving vers Cloud Service Mesh :
- Obtenez une nouvelle adresse IP externe sur laquelle vous configurez l'équilibreur de charge.
- Réutilisez votre adresse IP d'équilibreur de charge existante.
  
  Avertissement : Le processus de réutilisation d'une adresse IP existante pour configurer Cloud Service Mesh entraîne une interruption de connexion d'environ deux minutes. Vous devez planifier cette période pendant laquelle vos services Knative serving ne peuvent pas se connecter.
Assurez-vous que votre environnement de ligne de commande est configuré et à jour.

Migrer vers des parcs

Pour mettre à niveau Anthos vers la version 1.8, vous devez d'abord effectuer les étapes suivantes afin de vous assurer que la migration de votre installation Knative serving sur VMware existante est effectuée en utilisant le composant de parc.

Accéder à votre cluster d'administrateur

Obtenez le chemin d'accès et le nom du fichier kubeconfig de votre cluster d'administrateur, puis créez la variable d'environnement ADMIN_KUBECONFIG :

export ADMIN_KUBECONFIG=[ADMIN_CLUSTER_KUBECONFIG]

Remplacez [ADMIN_CLUSTER_KUBECONFIG] par le chemin d'accès et le nom du fichier kubeconfig de votre cluster d'utilisateur.

Configurer chaque cluster d'utilisateur

Créez les variables d'environnement locales suivantes pour le cluster d'utilisateur :

Créez la variable d'environnement USER_KUBECONFIG avec le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur :
```
export USER_KUBECONFIG=[USER_CLUSTER_KUBECONFIG]
```
Remplacez [USER_CLUSTER_KUBECONFIG] par le chemin d'accès et le nom du fichier kubeconfig de votre cluster d'utilisateur.

Créez des variables d'environnement pour les configurations suivantes :

ID de votre projet Google Cloud.
Emplacement de vos ressources Google Cloud.
Nom du cluster d'utilisateur.

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

Supprimez la configuration cloudrun de la ressource personnalisée OnPremUserCluster de votre cluster d'administrateur :

Vérifiez que cloudRun est défini dans OnPremUserCluster :

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

Résultat :

{"enabled":true}

Supprimez cloudRun de OnPremUserCluster.

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

Vérifiez que cloudRun a bien été supprimé de OnPremUserCluster en exécutant la même commande get et en vérifiant qu'aucune configuration n'est renvoyée :
```
kubectl get onpremusercluster \
  "${CLUSTER_NAME}" \
  --namespace "${CLUSTER_NAME}-gke-onprem-mgmt" \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --output=jsonpath="{.spec.cloudRun}"
```
Aucune sortie ne doit s'afficher sur le terminal.

Mettez à jour le secret create-config de votre cluster d'utilisateur :
1. Créez une copie YAML locale du fichier 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. Ouvrez le fichier ${CLUSTER_NAME}_create_secret.yaml que vous venez de créer dans un éditeur, puis supprimez le champ cloudrun sous spec.
3. Encodez en base64 le fichier ${CLUSTER_NAME}_cluster_create_secret.yaml dans un fichier .b64 :
```
cat "${CLUSTER_NAME}_create_secret.yaml" | base64 -w0 > "${CLUSTER_NAME}_create_secret.b64"
```
4. Dans l'éditeur, ouvrez le fichier .b64 local que vous venez de créer, puis copiez la chaîne qui figure sous l'attribut data.cfg pour l'utiliser à l'étape suivante.
  
  Vous devez vous assurer de ne copier que le contenu de l'attribut cfg. Par exemple, n'incluez aucune nouvelle ligne (\n).
5. Exécutez la commande suivante pour modifier le secret sur votre cluster d'utilisateur :
```
kubectl edit secret create-config --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace "${CLUSTER_NAME}"
```
6. Dans l'éditeur qui s'ouvre, remplacez le champ data[cfg] par la chaîne que vous avez copiée à partir du fichier .b64 local, puis enregistrez vos modifications.
7. Vérifiez que vos modifications sont déployées sur votre cluster d'utilisateur et que l'attribut cloudrun a bien été supprimé des secrets create-config :
```
kubectl get secret create-config \
  --kubeconfig="${ADMIN_KUBECONFIG}" \
  --namespace ${CLUSTER_NAME} \
  --output=jsonpath={.data.cfg} \
  | base64 -d
```

Configurez l'espace de noms knative-serving dans votre cluster d'utilisateur :

Supprimez l'opérateur cloudrun-operator de l'espace de noms knative-serving :

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

Appliquez le correctif au ConfigMap config-network dans l'espace de noms knative-serving :

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

Supprimez la configuration cloudrun.enabled du fichier de configuration du cluster d'utilisateur user-config.yaml de votre installation Google Distributed Cloud.

Les attributs suivants doivent être supprimés de votre fichier user-config.yaml :
```
cloudRun:
  enabled: true
```
Lorsque vous effectuez la mise à niveau du cluster vers la version 1.8 d'Anthos, cette modification de configuration est déployée.
Si vous disposez de plusieurs clusters d'utilisateur, vous devez répéter toutes les étapes de la section Configurer chaque cluster d'utilisateur pour chaque cluster d'utilisateur.

Configurer votre composant de parc

Activez le composant Knative Serving dans votre parc :
```
gcloud container fleet cloudrun enable --project=$PROJECT_ID
```
Pour obtenir plus d'informations et d'options, consultez la documentation de référence de gcloud container fleet cloudrun enable.
Facultatif : Vérifiez que le composant de fonctionnalité Knative serving est activé :
Console
Vérifiez si le composant Knative serving est activé dans la console Google Cloud :

Accéder au gestionnaire de fonctionnalités
Ligne de commande
Vérifiez si l'état de appdevexperience est défini sur ENABLED :
```
gcloud container fleet features list --project=$PROJECT_ID
```
Pour obtenir plus d'informations et découvrir des options supplémentaires, consultez la documentation de référence de gcloud container fleet features list.

Résultat :
```
NAME               STATE
appdevexperience   ENABLED
```
Déployez la ressource personnalisée CloudRun pour installer Knative serving sur VMware sur chacun de vos clusters d'utilisateur. Par défaut, la version latest de Knative Serving est déployée.

Important : Si vous disposez de plusieurs clusters d'utilisateur, vous devez répéter cette étape pour chacun d'eux.

Exécutez la commande kubectl apply suivante pour déployer la configuration par défaut de la ressource personnalisée 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
```

Configurer Cloud Service Mesh

Configurez l'équilibreur de charge Cloud Service Mesh pour chacun de vos clusters d'utilisateur.

Vous pouvez configurer la passerelle d'entrée de Cloud Service Mesh en définissant une nouvelle adresse IP externe ou en réutilisant votre adresse IP existante :

Avec la nouvelle adresse IP externe obtenue, configurez l'équilibreur de charge en suivant la procédure décrite dans la documentation de Cloud Service Mesh.

Cette option garantit que vos services Knative serving sont redémarrés sans interruption.

Vous pouvez également suivre la procédure ci-dessous pour configurer l'équilibreur de charge Cloud Service Mesh sur votre adresse IP existante.

Configurez la passerelle de vos services dans Cloud Service Mesh en exécutant les commandes suivantes :

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

Supprimez les paramètres de configuration Istio actuels :

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

Valider la migration

Vous pouvez vérifier si le service appdevexperience-operator est opérationnel et si Knative serving sur VMware a bien été migré vers votre parc.

Pour chaque cluster d'utilisateur, exécutez la commande suivante :

 kubectl get deployment -n appdevexperience appdevexperience-operator

L'opérateur appdevexperience-operator doit afficher 1/1 comme étant prêt, par exemple :

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

Si l'opérateur ne parvient pas à obtenir l'état "Ready", vous pouvez afficher la page des charges de travail de votre cluster dans la console Google Cloud pour identifier les problèmes de ressources :

Accéder aux charges de travail Google Kubernetes Engine

Mettre à niveau votre cluster

Maintenant que vous avez migré votre installation Knative serving sur VMware pour utiliser le composant de parc, vous pouvez mettre à niveau votre cluster vers la version 1.8 d'Anthos. Suivez les instructions détaillées de la page Mettre à niveau GKE On-Prem.

Dépannage

Échec du processus de mise à niveau de votre cluster d'utilisateur

Le pod cluster-local-gateway de l'espace de noms gke-system peut empêcher votre cluster d'utilisateur d'effectuer la mise à niveau vers Anthos version 1.8. Le pod cluster-local-gateway n'est plus nécessaire et peut être supprimé en toute sécurité.

Pour aider manuellement le processus de mise à niveau, vous pouvez supprimer manuellement le pod cluster-local-gateway en réduisant vos instances dupliquées de déploiement à 0. Exemple :

Réduisez la valeur de cluster-local-gateway :
```
kubectl scale deployment cluster-local-gateway --replicas 0 --namespace gke-system
```
Le pod cluster-local-gateway de l'espace de noms gke-system et toutes les charges de travail de l'espace de noms knative-serving sont supprimés.
Attendez la fin de la mise à niveau.

En savoir plus sur le scaling des déploiements