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 passez à la version 1.8 d'Anthos.

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

De manière générale, pour migrer votre installation Knative serving sur VMware afin d'utiliser un vous devez:

Configurez votre installation Knative serving sur VMware afin qu'elle respecte les les exigences du parc.
Activez le composant de fonctionnalité Knative serving dans votre de votre parc d'appareils.

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, voir 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 un parc et visible dans la console Google Cloud:

Accéder aux clusters GKE
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. Version de Cloud Service Mesh 1.18 doit être installé dans votre parc et votre installation de Vous devez configurer Knative serving avant de mettre à niveau ce cluster vers Version 1.8.

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

Notez que Cloud Service Mesh nécessite que votre cluster utilise un type de machine disposant d'au moins quatre processeurs virtuels, par exemple 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.
Il existe deux options pour migrer Knative serving Cloud Service Mesh, vous pouvez:
- 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 consistant à réutiliser une adresse IP existante pour configurer Cloud Service Mesh entraîne une connexion d'environ deux minutes les temps de pause. Vous devez prévoir cette période pendant laquelle vos Les services Knative serving ne parviennent 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 la pour vous assurer que votre service Knative serving existant sur VMware l'installation est migrée vers l'utilisation du 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 cluster d'utilisateur fichier de configuration 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 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 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éployer la ressource personnalisée CloudRun à installer Knative serving sur VMware sur chacun de vos clusters d'utilisateur. Par défaut, latest version 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 de l'une des manières suivantes : en configurant une nouvelle adresse IP externe ou en réutilisant votre adresse IP existante:

Avec la nouvelle adresse IP externe obtenue, vous configurez la charge en suivant la procédure décrite dans le Documentation Cloud Service Mesh

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

Autre solution: Procédez comme suit pour configurer Cloud Service Mesh vers 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 vérifier que votre service Knative serving sur VMware a été migré vers votre parc.

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

 kubectl get deployment -n appdevexperience appdevexperience-operator

appdevexperience-operator opérateur 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 "prêt", vous pouvez afficher l'état du cluster de la page "Charges de travail" de 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 de parc, vous pouvez mettre à niveau votre cluster vers Anthos Version 1.8. 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