Migrer vers Kubernetes : avantages et bonnes pratiques

La modification de l'architecture des serveurs est toujours une étape importante pour tout projet. Chez Dysnix, nous guidons la plupart de nos clients tout au long de ce processus en fournissant des services Kubernetes. Et chaque fois, cela a été une expérience différente.

Si votre entreprise choisit une stratégie de migration vers Kubernetes, il y a évidemment une bonne raison à cela : une stabilité accrue, une unification de l'environnement et une mise à l'échelle automatique rapide.

Kubernetes est le mieux adapté aux architectures de microserveurs. En fait, plus les entités du cluster sont distinctes, mieux c'est. Cela permet de :

• Fixer des limites précises pour chaque service
• Établir uniquement les connexions nécessaires
• Choix du type d'entité Kubernetes unique à chaque service (Deployment, ReplicationController, DaemonSet, etc.)

Avant même d'expliquer le processus, j'aimerais que vous imaginiez véritable objectif de votre migration.

• Pourquoi Envisagez-vous de migrer vers Kubernetes ?
• S'il est nécessaire de modifier la logique de votre application, disposerez-vous de suffisamment de ressources pour la modifier ? Le design de votre application peut-il être qualifié de « natif des conteneurs » ?
• Quels avantages de Kubernetes espérez-vous obtenir par la suite ?

Ces questions et d'autres doivent être prises en compte avant de commencer à migrer vers Kubernetes, car ce processus n'est pas une blague pour les développeurs et les entreprises en général. Sous la pointe de l'iceberg, toute une montagne de retouches peut attendre votre équipe. Votre personnel doit donc absolument être prêt et savoir avec certitude à quoi servent ces actions. D'autre part, même si la migration vers Kubernetes se termine sans problème, la conception de votre application ou votre logique métier ne peuvent tirer aucun avantage de Kubernetes dans votre cas particulier.

Dans cet article, je vais partager l'expertise de Dysnix en matière de migration vers les processus et les outils Kubernetes, décrire les erreurs courantes et les moyens de les éviter.

Ground Zero : décomposition d'une application et sa réinvention pour la rendre native de Kubernetes

Dans la continuité logique du point précédent, je passe du point de vue de la stratégie à celui de la tactique. Voyons ce que vous devez prendre en compte et ce que vous devez faire avec les réponses que vous obtenez aux questions sur les « objectifs ».

Vérifiez et visualisez votre architecture actuelle

Votre documentation, vos outils de visualisation et votre planification globale vous aideront à estimer le temps et les ressources dont vous aurez besoin pour effectuer la migration. Décrivez chaque partie de votre application et les connexions entre les deux, puis marquez-les sur le schéma. Utilisez un déploiement ou une vue hexagonale pour vous faciliter la tâche, ou même un simple diagramme de flux de données fera de même. Une fois cette étape terminée, vous aurez une carte complète des modules et de la façon dont ils sont connectés. Cela vous permettra de bien comprendre ce qui sera migré exactement vers Kubernetes.

Repensez l'architecture actuelle des applications

Malgré l'enthousiasme que vous pourriez ressentir à ce stade, « Réécrivons tout ! » — vous devez garder votre sang-froid et créer l'ordre de migration de vos modules du plus simple au plus difficile. Grâce à cette approche, vous serez en mesure de former votre équipe et de vous préparer aux « tâches herculéennes » les plus « herculéennes ». Ou essayez de préparer votre plan en utilisant un autre concept : choisissez les modules les plus essentiels, ceux qui sont responsables du travail de logique métier, par exemple, et définissez-les comme les plus importants. Les autres modules peuvent être marqués comme secondaires, puis y travailler une fois le cœur de l'application migré vers k8s.

Les tâches que vous devrez résoudre ici seront les suivantes :

1. Trouvez une méthode de journalisation applicable à votre application ;
2. Choisissez le mode de stockage de vos sessions (en mémoire partagée, par exemple) ;
3. Réfléchissez à la manière dont vous allez implémenter le stockage de fichiers pour votre future application k8s ;
4. Réfléchissez aux nouveaux défis liés aux tests et au dépannage de votre application.

Je dois mentionner que selon le type de votre application, certaines étapes peuvent être réduites ou étendues avec le temps, et ce n'est pas grave. De plus, vous pourriez avoir besoin d'embaucher du personnel supplémentaire et de multiplier l'expertise de votre équipe. Chaque entreprise fait l'expérience de la migration de manière individuelle.

Mais revenons à l'ensemble du processus suivant dans une brève description :

• Étape de conteneurisation. Ici, vous allez préparer un conteneur de lancement Docker avec des configurations pour votre application. Il décrit l'environnement, les langages de programmation et les autres préférences pour l'image de Docker. Plus tard, je décrirai comment lancer un conteneur dans un cas d'utilisation pratique.
• Obtenez le schéma des modules de votre application et choisissez des objets Kubernetes pour chaque module. Cette étape se déroule généralement sans heurts car il existe une grande variété de types et d'options pour les composants de votre application. Ensuite, vous devez écrire des fichiers YAML pour créer des objets Kubernetes mappés.
• Adaptation des bases de données. La pratique la plus courante consiste à le laisser tel quel, mais à se connecter à une nouvelle application basée sur Kubernetes. Après avoir lancé un conteneur Docker, vous n'avez besoin que de la décision exécutive pour prendre et conteneuriser l'ensemble de l'application, y compris votre base de données.

Vous avez maintenant une idée générale de l'adoption de Kubernetes. Approfondissons le thème à l'aide de particularités techniques, de bonnes pratiques en matière de migration d'applications et de cas d'utilisation de Kubernetes.

Migrer l'application vers Kubernetes étape par étape

Stockage de données persistantes

Lorsque nous développons l'architecture d'un projet, nous essayons d'éviter complètement de stocker des données dans des fichiers. Pourquoi ?

• La plupart des plateformes (AWS, Google) n'autorisent l'installation d'un stockage au niveau des blocs qu'à partir d'un seul point. Il impose des limites à la mise à l'échelle horizontale des conteneurs utilisée par Persistent Volume.
• Lorsqu'un système de fichiers contient de nombreux fichiers, des problèmes d'accès au système de fichiers se produisent, ce qui nuit considérablement à la réactivité générale de la ressource.

Les moyens d'éviter cela sont les suivants :

• Nous stockons le contenu statique dans Object Storage. Si c'est à Amazon que nous avons affaire, nous utilisons S3. S'il s'agit d'un cluster matériel : Ceph RDB pour le stockage persistant et Ceph rados pour S3.
• Nous essayons de stocker la plupart des données sur des stockages DB et/ou NoSQL (tels que ElasticSearch).
• Nous stockons les sessions et le cache sur des bases de données en mémoire (redis/memcache).

Néanmoins, si c'est un volume persistant qui est requis, il doit être préparé correctement.

1. Tout d'abord, collectez la liste de TOUS les catalogues qui stockent des données persistantes. Si vous ne le faites pas, les données seront enregistrées sans erreur, mais après le redémarrage du conteneur ou la migration vers un autre nœud, TOUTES les données seront PERDUES.
2. Essayez de compiler les catalogues de manière à ce que toutes vos données soient stockées dans un seul catalogue en bas, car il est nécessaire de ne pouvoir utiliser qu'un seul volume persistant pour un conteneur. Cette règle n'est pas toujours applicable et il est parfois simplement nécessaire de répartir les données entre plusieurs PV. Seul l'architecte de l'application, qui connaît l'objectif d'un stockage persistant et le volume de données prévu qui y est stocké, peut donner la réponse ultime.
3. Sélectionnez un système de fichiers approprié. Ext4 convient à la plupart des tâches, mais le choix d'un système de fichiers plus adapté peut parfois améliorer les performances.
4. Sélectionnez un PV de taille optimale. Ne vous inquiétez pas, vous pourrez facilement l'étendre si nécessaire. Toutefois, si un système de fichiers est surchargé, le redimensionnement nécessite encore plus de ressources et peut affecter les performances.

Lorsque toutes les conditions sont remplies, créez un fichier YAML pour Kubernetes Persistent Volume. Dans le cas d'AWS, cela peut ressembler à ceci :

apiVersion: v1
    kind: PersistentVolume
    metadata:
        name: example-my-pv
        annotations:
            volume.beta.kubernetes.io/storage-class: "default"
    spec:
        capacity:
            storage: 100Gi
        accessModes:
            - ReadWriteOnce
        awsElasticBlockStore:
            volumeID: vol-0dc1fcf80ac20300a
            fsType: ext4