Cette documentation concerne la dernière version de Knative serving, qui utilise des parcs et Anthos Service Mesh. En savoir plus

La version antérieure (Cloud Run for Anthos) a été archivée, mais la documentation reste disponible pour les utilisateurs existants.

Versions disponibles

Le plus récent
Archiver

Cette page a été traduite par l'API Cloud Translation.

Mettre à niveau Knative serving sur VMware vers les parcs

Découvrez comment migrer Knative serving sur VMware afin d'utiliser des parcs afin de pouvoir passer à Anthos version 1.8.

Knative serving est désormais une expérience distincte du produit Cloud Run géré et est désormais fourni en tant que composant de parc dans vos clusters. L'installation des fonctionnalités 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.

De manière générale, pour migrer votre installation Knative serving sur VMware vers un parc, vous devez:

Configurez votre installation Knative serving sur VMware pour répondre aux exigences du parc.
Activez 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 savoir comment 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 :

Ces étapes nécessitent que votre cluster Knative serving sur VMware soit enregistré dans GKE Enterprise:

Accéder aux clusters GKE Enterprise

Découvrez comment enregistrer un cluster.
Votre installation de Knative serving sur VMware se trouve sur un cluster exécutant Anthos version 1.7 ou antérieure.
Istio n'est plus compatible avec Anthos 1.8. Vous devez installer Cloud Service Mesh version 1.18 dans votre parc et configurer votre installation de Knative serving avant de mettre à niveau ce cluster vers la version 1.8.

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

Notez que Cloud Service Mesh nécessite que votre cluster utilise un type de machine comportant au moins quatre processeurs virtuels, tel 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 s'offrent à vous 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 un temps d'arrêt de la connexion d'environ deux minutes. Vous devez prévoir 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 les parcs

Pour mettre à niveau Anthos vers la version 1.8, vous devez d'abord effectuer les étapes suivantes pour vous assurer que votre installation Knative serving existante sur VMware est migrée vers 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}"

Result:

{"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 user-config.yaml du cluster d'utilisateur de votre installation GKE sur VMware.

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 le composant de votre 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 aux fonctionnalités de GKE Enterprise
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 configurant une nouvelle adresse IP externe ou en réutilisant votre adresse IP existante:

Avec la nouvelle adresse IP externe que vous avez obtenue, configurez l'équilibreur de charge en suivant les étapes décrites dans la documentation Cloud Service Mesh.

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

Alternative: Procédez comme suit pour configurer l'équilibreur de charge Cloud Service Mesh sur votre adresse IP existante.

Configurez la passerelle de vos services vers 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 appdevexperience-operator est opérationnel pour vous assurer que votre service 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 à atteindre l'état de disponibilité, 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 du 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 le 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