Nouvel environnement d'exécution amélioré

Le gestionnaire de services Linux d'origine pour Migrate to Containers s'appuyait sur sysv init et systemd. Le gestionnaire de services Linux simplifié le remplace et propose une alternative simplifiée et adaptée aux conteneurs.

Ce gestionnaire de services Linux simplifié ajoute des fonctionnalités qui vous permettent de déployer vos charges de travail de conteneurs migrées vers ce qui suit :

  • Clusters GKE Autopilot

  • Cloud Run

Le gestionnaire de services Linux simplifié résout également les problèmes de compatibilité avec les plug-ins Kubernetes. Par exemple, le gestionnaire de services Linux simplifié supprime l'obligation de définir un hostpath pour /sys/fs/cgroup dans le fichier deployment_spec.yaml et la nécessité de créer des conteneurs privilégiés.

Avant de commencer

  • Migrate to Containers fournit un outil que vous exécutez sur une charge de travail de VM pour déterminer si elle est adaptée à la migration vers un conteneur. Pour en savoir plus, consultez la page Utiliser l'outil d'évaluation de l'adéquation.

À propos des clusters GKE Autopilot

Autopilot est un mode de fonctionnement dans Google Kubernetes Engine (GKE). Autopilot est conçu pour réduire les coûts d'exploitation liés à la gestion des clusters, optimiser vos clusters pour la production et augmenter la disponibilité des charges de travail. En mode Autopilot, GKE provisionne et gère l'infrastructure sous-jacente du cluster, y compris les nœuds et les pools de nœuds, offrant ainsi un cluster optimisé pour une expérience automatisée.

Pour en savoir plus, consultez la 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 Pub/Sub. Le gestionnaire de services Linux simplifié vous permet de déployer vos charges de travail de conteneurs migrées sur Cloud Run.

Utiliser Workload Identity avec Migrate to Containers et GKE

Migrate to Containers et GKE vous permettent de déployer vos charges de travail migrées vers Google Distributed Cloud Virtual pour Bare Metal. Parfois, vous pouvez utiliser un seul et même cluster comme cluster de traitement et comme cluster de déploiement. Si vous avez activé Workload Identity sur votre cluster de déploiement, veillez à configurer votre environnement de déploiement pour qu'il soit compatible avec Migrate to Containers et GKE.

Vous devez également vous assurer que tous les services démarrés dans le cadre du processus init sont correctement configurés pour Workload Identity. Les étapes à suivre dépendent du gestionnaire de services de votre cluster. Consultez la page Déployer une charge de travail Linux sur un cluster cible pour connaître la procédure de configuration.

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

Pour utiliser le gestionnaire de services Linux simplifié, vous devez connaître les modifications et les limites suivantes liées à l'environnement d'exécution existant.

Ajout du nouveau fichier d'artefact services-config.yaml

Si vous activez le gestionnaire de services Linux simplifié, Migrate to Containers crée un fichier d'artefact services-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 services-config.yaml.

Vérifications de préparation

Lorsque vous utilisez l'environnement d'exécution actuel, Migrate to Containers ajoute une vérification d'aptitude dans le fichier deployment_spec.yaml. Lorsque vous activez le gestionnaire de services Linux simplifié, aucune vérification d'aptitude 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

Le gestionnaire de services Linux simplifié crée un socket Unix sur /dev/log pour assurer la compatibilité avec syslog. Le gestionnaire de services Linux simplifié 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 le gestionnaire de services Linux simplifié.

Limites de charge de travail

Le gestionnaire de services Linux simplifié fonctionne mieux avec les charges de travail suivantes :

Image OS Services
Compute Engine Ubuntu 12.04 Ubuntu 12.04 apache2
Compute Engine Ubuntu 14.04 Ubuntu 14.04 redis, mysql, apache2
Compute Engine Ubuntu 18.04 Ubuntu 18.04 apache2, mysql, redis-server, tomcat
RHEL SAP 7.4 Red Hat httpd
Bitnami Ubuntu bitnami
Compute Engine Memcached image Debian 10.9 bitnami
Compute Engine Marketplace wordpress Debian 9.13 apache2, mysql, php
Compute Engine Marketplace tomcat Debian 9.13 tomcat8
Compute Engine Marketplace jenkins Debian 10.9 apache2, jenkins
Compute Engine Marketplace moodle Debian 9.13 apache2, mysql, php7.4 fpm, phpsessionclean
Compute Engine Marketplace Odoo Debian 9.13 odoo, nginx
Compute Engine Marketplace Opencart Debian 9.13 apache2, mysql, php7.0 fpm, supervisor, mariadb
Compute Engine Marketplace Erpnext Debian 10.9 nginx, redis-server, supervisor, mariadb
Compute Engine Marketplace wildfly Debian 10.10 wildfly, cron

Limites de systemd

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

  • Les services systemd de type 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 compatibles avec sd_notify() que pour les messages READY=1.

    Si nécessaire, vous pouvez fournir d'autres vérifications d'aptitude. 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.

Mises à jour de la version 1.9.0

Le gestionnaire de services Linux simplifié pour la version 1.9.0 contient les mises à jour suivantes :

Mises à jour de la version 1.8.1

Le gestionnaire de services Linux simplifié a été initialement publié dans la version bêta publique dans le cadre de la version 1.8 de Migrate to Containers. Le gestionnaire de services Linux simplifié pour la version 1.8.1 contient les mises à jour suivantes :

  • Vous ne définissez plus d'annotation dans le plan de migration pour activer le gestionnaire de services Linux simplifié. À la place, vous devez maintenant définir v2kServiceManager. Pour en savoir plus, consultez la page Déployer des conteneurs sur des clusters Autopilot.

  • La variable d'environnement HC_GAMMA_RUNTIME a été renommée HC_V2K_SERVICE_MANAGER.

  • Les entrées prestart et poststart du fichier services-config.yaml sont désormais renseignées automatiquement. Pour en savoir plus, consultez la page Using services-config.yaml.

  • Ajout de la compatibilité avec le fichier services-config.yaml, qui vous permet de spécifier des variables d'environnement au niveau global ou au niveau de l'application. Pour en savoir plus, consultez la page Using services-config.yaml.

  • Ajout de la prise en charge de la journalisation, qui vous permet de personnaliser les données de journalisation écrites dans Cloud Logging. Pour en savoir plus, consultez la section Personnaliser les données de journaux écrites dans Cloud Logging.

Étapes suivantes