Environnement d'exécution amélioré

Cette version publique d'aperçu de l'environnement d'exécution amélioré pour Migrate for Anthos and GKE ajoute de nouvelles fonctionnalités qui vous permettent de déployer des charges de travail de conteneurs migrés :

  • Clusters GKE Autopilot

  • Cloud Run

L'environnement d'exécution amélioré résout également les problèmes de compatibilité avec les plug-ins Kubernetes. Par exemple, l'environnement d'exécution actuel nécessite des modifications de configuration supplémentaires lors du déploiement de conteneurs sur Anthos clusters on AWS qui utilisent Workload Identity.

À propos des clusters GKE Autopilot

Autopilot est un nouveau mode de fonctionnement dans Google Kubernetes Engine (GKE), conçu pour réduire les coûts opérationnels liés à la gestion des clusters, optimiser vos clusters pour la production et accroître la disponibilité de vos charges de travail. En mode Autopilot, GKE provisionne et gère l'infrastructure sous-jacente au cluster, y compris les nœuds et les pools de nœuds, ce qui vous permet de bénéficier d'un cluster optimisé sans intervention de votre part.

Pour en savoir plus, consultez la page Présentation d'Autopilot.

À propos de Cloud Run

Cloud Run est une plate-forme de calcul gérée qui permet d'exécuter des conteneurs sans état accessibles via des requêtes Web ou des événements Cloud Pub/Sub. L'environnement d'exécution de conteneur amélioré vous permet de déployer vos charges de travail de conteneur migrés sur Cloud Run.

À propos de Anthos clusters on AWS et de Workload Identity

Workload Identity pour Anthos clusters on AWS vous permet d'associer des comptes de service Kubernetes à des comptes AWS IAM avec des autorisations spécifiques. Workload Identity se sert des autorisations AWS IAM pour bloquer les accès indésirables aux ressources cloud.

L'environnement d'exécution actuel vous permet de déployer vos charges de travail migrées sur Anthos clusters on AWS en utilisant Workload Identity. Cependant, vous devez effectuer des étapes supplémentaires pour configurer votre environnement de déploiement en définissant les variables d'environnement suivantes pour votre système init spécifique :

  • AWS_ROLE_ARN : nom de la ressource Amazon (ARN) du rôle IAM.
  • AWS_WEB_IDENTITY_TOKEN_FILE : chemin d'accès au jeton stocké.

L'environnement d'exécution amélioré vous permet de déployer vos conteneurs sans effectuer cette configuration supplémentaire.

Modifications par rapport à l'environnement d'exécution existant

Pour utiliser l'environnement d'exécution amélioré, vous devez prendre en compte les modifications et les limites suivantes concernant l'environnement d'exécution existant.

Nouveau fichier d'artefact config.yaml ajouté

Si vous activez l'environnement d'exécution amélioré, Migrate for Anthos and GKE crée un fichier d'artefact, config.yaml, lorsque vous générez les artefacts de migration. Utilisez ce fichier pour contrôler l'initialisation de l'application sur un conteneur déployé. Pour en savoir plus, consultez la page Utiliser config.yaml.

Vérifications de préparation

Lorsque vous utilisez l'environnement d'exécution actuel, Migrate for Anthos and GKE ajoute une vérification de préparation dans le fichier deployment_spec.yaml. Lorsque vous activez l'environnement d'exécution amélioré, aucune vérification de préparation n'est ajoutée.

Si vous souhaitez ajouter une vérification de préparation, nous vous recommandons d'utiliser une vérification de préparation HTTP. Pour en savoir plus, consultez la section Définir des vérifications de préparation.

        readinessProbe:
          exec:
            command:
            - /.m4a/gamma status

Cependant, cette vérification peut renvoyer un résultat de faux négatif.

Compatibilité avec syslog

L'environnement d'exécution amélioré crée un socket Unix à /dev/log pour la prise en charge de syslog. L'environnement d'exécution amélioré transfère ces messages de journal à stdout afin qu'ils soient enregistrés par Kubernetes en tant que journaux de conteneurs.

Limites

Tenez compte des limites suivantes lorsque vous utilisez la version d'évaluation publique de l'environnement d'exécution amélioré.

Limites de charge de travail

Cet aperçu public fonctionne mieux avec les types de charges de travail suivants :

  • Apache
  • Tomcat
  • Redis
  • mysql

Limites de systemd

Si vous utilisez systemd comme système init, tenez compte des limites suivantes :

  • Les types de services systemd de simple, exec et notify sont traités comme des services exec. Cela signifie que le service est considéré comme démarré si exec réussit.

  • Les sockets de notification ne sont pas compatibles, les services de type notify n'ont pas la variable d'environnement NOTIFY_SOCKET fournie, et sd_notify ne fait rien.

    Vous devez fournir d'autres vérifications d'aptitude si nécessaire. Par exemple, une vérification HTTP ou un autre type de vérification.

  • Les fichiers d'unités de type socket ne sont pas compatibles. Les sockets ne sont pas créés, ni aucune variable d'environnement.