Qu'est-ce que Kubernetes ? Guide de conteneurisation et de déploiement

Il y a peu de temps, nous avons utilisé l'application Web monolithique : d'énormes bases de code qui se sont développées dans de nouvelles fonctions et fonctionnalités jusqu'à ce qu'elles se transforment en géants énormes, lents et difficiles à gérer. Aujourd'hui, un nombre croissant de développeurs, d'architectes et d'experts DevOps sont d'avis qu'il vaut mieux utiliser des microservices qu'un monolithe géant. Habituellement, l'utilisation d'une architecture basée sur des microservices signifie diviser votre monolithe en au moins deux applications : l'application frontale et une application principale (l'API). Après la décision d'utiliser des microservices, une question se pose : dans quel environnement est-il préférable d'exécuter des microservices ? Que dois-je choisir pour rendre mon service stable, facile à gérer et à déployer ? La réponse courte est : utilisez Docker !

Dans cet article, je vais vous présenter les conteneurs, expliquer Kubernetes et vous apprendre à conteneuriser et déployer une application sur un cluster Kubernetes à l'aide de CircleCI.

Docker? Qu'est-ce que Docker ?

Docker est un outil conçu pour faciliter DevOps (et votre vie). Avec Docker, un développeur peut créer, déployer et exécuter des applications dans des conteneurs . Les conteneurs permettent à un développeur de regrouper une application avec toutes les parties dont elle a besoin, telles que des bibliothèques et d'autres dépendances, et de l'expédier dans un seul package.

À l'aide de conteneurs, les développeurs peuvent facilement (re)déployer une image sur n'importe quel système d'exploitation. Installez simplement Docker, exécutez une commande et votre application est opérationnelle. Oh, et ne vous inquiétez pas des incohérences avec la nouvelle version des bibliothèques du système d'exploitation hôte. De plus, vous pouvez lancer plusieurs conteneurs sur le même hôte. S'agira-t-il de la même application ou d'une autre ? Cela n'a pas d'importance.

On dirait que Docker est un outil génial. Mais comment et où lancer des conteneurs ?

Il existe de nombreuses options pour savoir comment et où exécuter les conteneurs : AWS Elastic Container Service (AWS Fargate ou une instance réservée avec mise à l'échelle automatique horizontale et verticale) ; une instance cloud avec une image Docker prédéfinie dans Azure ou Google Cloud (avec des modèles, des groupes d'instances et une mise à l'échelle automatique) ; sur votre propre serveur avec Docker ; ou, bien sûr, Kubernetes ! Kubernetes a été créé spécialement pour la virtualisation et les conteneurs par les ingénieurs de Google en 2014.

Kubernetes ? Qu'est-ce que c'est?

Kubernetes est un système open source qui vous permet d'exécuter des conteneurs, de les gérer, d'automatiser les déploiements, de mettre à l'échelle les déploiements, de créer et de configurer des entrées, de déployer des applications sans état ou avec état, et bien d'autres choses. Fondamentalement, vous pouvez lancer une ou plusieurs instances et installer Kubernetes pour les faire fonctionner en tant que cluster Kubernetes. Obtenez ensuite le point de terminaison API du cluster Kubernetes, configurez kubectl (un outil de gestion des clusters Kubernetes) et Kubernetes est prêt à servir.

Alors pourquoi devrais-je l'utiliser ?

Avec Kubernetes, vous pouvez utiliser au maximum les ressources de calcul. Avec Kubernetes, vous serez le capitaine de votre navire (infrastructure) avec Kubernetes dans vos voiles. Avec Kubernetes, votre service sera HA. Et surtout, avec Kubernetes, vous économiserez beaucoup d'argent.

Cela semble prometteur! Surtout si cela vous fera économiser de l'argent ! Parlons-en davantage !

Kubernetes gagne en popularité jour après jour. Allons plus loin et enquêtons sur ce qu'il y a sous le capot.

Sous le capot : qu'est-ce que Kubernetes ?

Kubernetes est le nom de l'ensemble du système, mais comme votre voiture, il existe de nombreux petits éléments qui fonctionnent ensemble en parfaite harmonie pour faire fonctionner Kubernetes. Apprenons ce qu'ils sont.

Nœud maître – Un panneau de contrôle pour l'ensemble du cluster Kubernetes. Les composants du maître peuvent être exécutés sur n'importe quel nœud du cluster. Les composants clés sont :

• Serveur API : le point d'entrée pour toutes les commandes REST, le seul composant du nœud maître accessible à l'utilisateur.
• Datastore : stockage clé-valeur solide, cohérent et hautement disponible utilisé par le cluster Kubernetes.
• Planificateur : surveille les pods nouvellement créés et les attribue aux nœuds. Le déploiement de pods et de services sur les nœuds se produit à cause du planificateur.
• Gestionnaire de contrôleur : exécute tous les contrôleurs qui gèrent les tâches de routine dans le cluster.
• Nœuds de travail : agent de nœud principal, également appelé nœuds minion. Les pods sont exécutés ici. Les nœuds de travail contiennent tous les services nécessaires pour gérer la mise en réseau entre les conteneurs, communiquer avec le nœud maître et affecter des ressources aux conteneurs planifiés.
• Docker : s'exécute sur chaque nœud de travail et télécharge les images et les conteneurs de démarrage.
• Kubelet : surveille l'état d'un pod et s'assure que les conteneurs sont opérationnels. Il communique également avec le magasin de données, obtenant des informations sur les services et écrivant des détails sur ceux qui viennent d'être créés.
• Kube-proxy : un proxy réseau et un équilibreur de charge pour un service sur un nœud de travail unique. Il est responsable du routage du trafic.
• Kubectl : un outil CLI permettant aux utilisateurs de communiquer avec le serveur d'API Kubernetes.

Que sont les pods et les services ?

Les pods sont la plus petite unité du cluster Kubernetes, c'est comme une brique dans le mur d'un immense bâtiment. Un pod est un ensemble de conteneurs qui doivent fonctionner ensemble et peuvent partager des ressources (espaces de noms Linux, cgroups, adresses IP). Les gousses ne sont pas destinées à vivre longtemps.

Les services sont une abstraction au-dessus d'un certain nombre de pods, nécessitant généralement un proxy en plus pour que d'autres services communiquent avec lui via une adresse IP virtuelle.

Exemple de déploiement simple

J'utiliserai une simple application Ruby on Rails et GKE comme plate-forme pour exécuter Kubernetes. En fait, vous pouvez utiliser Kubernetes dans AWS ou Azure ou même créer un cluster dans votre propre matériel ou exécuter Kubernetes localement en utilisant minikube - toutes les options que vous trouverez sur cette page.

Les fichiers source de cette application se trouvent dans ce référentiel GitHub.

Pour créer une nouvelle application Rails, exécutez :

 rails new blog

Pour configurer la connexion MySQL pour la production dans le config/database.yml file :

 production: adapter: mysql2 encoding: utf8 pool: 5 port: 3306 database: <%= ENV['DATABASE_NAME'] %> host: 127.0.0.1 username: <%= ENV['DATABASE_USERNAME'] %> password: <%= ENV['DATABASE_PASSWORD'] %>

Pour créer un modèle d'article, un contrôleur, des vues et une migration, exécutez :

 rails g scaffold Article title:string description:text

Pour ajouter des gemmes au Gemfile :

 gem 'mysql2', '< 0.6.0', '>= 0.4.4' gem 'health_check'

Pour créer l'image Docker, saisissez mon Dockerfile et exécutez :

 docker build -t REPO_NAME/IMAGE_NAME:TAG . && docker push REPO_NAME/IMAGE_NAME:TAG

Il est temps de créer un cluster Kubernetes. Ouvrez la page GKE et créez un cluster Kubernetes. Lorsque le cluster est créé, cliquez sur "Connect button" et copiez la commande - assurez-vous que l'outil gCloud CLI (comment faire) et kubectl sont installés et configurés. Exécutez la commande copiée sur votre PC et vérifiez la connexion au cluster Kubernetes ; exécutez kubectl cluster-info .

L'application est prête à être déployée sur le cluster k8s. Créons une base de données MySQL. Ouvrez la page SQL dans la console gCloud et créez une instance de base de données MySQL pour l'application. Lorsque l'instance est prête, créez l'utilisateur et la base de données et copiez le nom de connexion de l'instance .

De plus, nous devons créer une clé de compte de service dans la page API et services pour accéder à une base de données MySQL à partir d'un conteneur side-car. Vous pouvez trouver plus d'informations sur ce processus ici. Renommez le fichier téléchargé en service-account.json . Nous reviendrons plus tard sur ce dossier.

Nous sommes prêts à déployer notre application sur Kubernetes, mais nous devons d'abord créer des secrets pour notre application, un objet secret dans Kubernetes créé pour stocker des données sensibles. Importez le fichier service-account.json précédemment téléchargé :

 kubectl create secret generic mysql-instance-credentials \ --from-file=credentials.json=service-account.json

Créez des secrets pour l'application :

 kubectl create secret generic simple-app-secrets \ --from-literal=username=$MYSQL_PASSWORD \ --from-literal=password=$MYSQL_PASSWORD \ --from-literal=database-name=$MYSQL_DB_NAME \ --from-literal=secretkey=$SECRET_RAILS_KEY

N'oubliez pas de remplacer les valeurs ou de définir les variables d'environnement avec vos valeurs.

Avant de créer un déploiement, examinons le fichier de déploiement. J'ai concaténé trois fichiers en un seul; la première partie est un service qui exposera le port 80 et transmettra toutes les connexions arrivant au port 80 vers 3000. Le service a un sélecteur avec lequel le service sait à quels pods il doit transférer les connexions.

La partie suivante du fichier est le déploiement, qui décrit la stratégie de déploiement - les conteneurs qui seront lancés à l'intérieur du pod, les variables d'environnement, les ressources, les sondes, les montages pour chaque conteneur et d'autres informations.

La dernière partie est le Horizontal Pod Autoscaler. HPA a une configuration assez simple. Gardez à l'esprit que si vous ne définissez pas de ressources pour le conteneur dans la section de déploiement, HPA ne fonctionnera pas.

Vous pouvez configurer l'autoscaler vertical pour votre cluster Kubernetes sur la page de modification de GKE. Il a également une configuration assez simple.

Il est temps de l'expédier au cluster GKE ! Tout d'abord, nous devrions exécuter les migrations via job. Exécuter:

kubectl apply -f rake-tasks-job.yaml – Cette tâche sera utile pour le processus CI/CD.

kubectl apply -f deployment.yaml – pour créer un service, un déploiement et HPA.

Et ensuite vérifiez votre pod en exécutant la commande : kubectl get pods -w

 NAME READY STATUS RESTARTS AGE sample-799bf9fd9c-86cqf 2/2 Running 0 1m sample-799bf9fd9c-887vv 2/2 Running 0 1m sample-799bf9fd9c-pkscp 2/2 Running 0 1m

Créons maintenant une entrée pour l'application :

1. Créez une adresse IP statique : gcloud compute addresses create sample-ip --global
2. Créez l'entrée (fichier) : kubectl apply -f ingress.yaml
3. Vérifiez que l'entrée a été créée et récupérez l'IP : kubectl get ingress -w
4. Créez le domaine/sous-domaine pour votre application.

IC/CD

Créons un pipeline CI/CD à l'aide de CircleCI. En fait, il est facile de créer un pipeline CI/CD à l'aide de CircleCI, mais gardez à l'esprit qu'un processus de déploiement entièrement automatisé rapide et sale sans tests comme celui-ci fonctionnera pour de petits projets, mais s'il vous plaît ne le faites pas pour quelque chose de sérieux car , si un nouveau code rencontre des problèmes de production, vous allez perdre de l'argent. C'est pourquoi vous devez penser à concevoir un processus de déploiement robuste, lancer des tâches Canary avant le déploiement complet, vérifier les erreurs dans les journaux après le démarrage du Canary, etc.

Actuellement, nous avons un petit projet simple, alors créons un processus de déploiement CI/CD entièrement automatisé, sans test. Tout d'abord, vous devez intégrer CircleCI à votre référentiel - vous pouvez trouver toutes les instructions ici. Ensuite, nous devrions créer un fichier de configuration avec des instructions pour le système CircleCI. La config a l'air assez simple. Les points principaux sont qu'il y a deux branches dans le référentiel GitHub : master et production .

1. La branche master est pour le développement, pour le nouveau code. Lorsque quelqu'un envoie un nouveau code à la branche principale, CircleCI démarre un flux de travail pour la branche principale : créez et testez le code.
2. La branche de production sert à déployer une nouvelle version dans l'environnement de production. Le flux de travail pour la branche de production est le suivant : poussez le nouveau code (ou mieux encore, ouvrez PR de la branche principale à la production) pour déclencher un nouveau processus de construction et de déploiement ; pendant la construction, CircleCI crée de nouvelles images Docker, les pousse vers le GCR et crée un nouveau déploiement pour le déploiement ; si le déploiement échoue, CircleCI déclenche le processus de restauration.

Avant d'exécuter une construction, vous devez configurer un projet dans CircleCI. Créez un nouveau compte de service dans l'API et une page Services dans GCloud avec ces rôles : accès complet au GCR et GKE, ouvrez le fichier JSON téléchargé et copiez le contenu, puis créez une nouvelle variable d'environnement dans les paramètres du projet dans CircleCI avec le nom GCLOUD_SERVICE_KEY et collez le contenu du fichier de compte de service en tant que valeur. En outre, vous devez créer les variables d'environnement suivantes : GOOGLE_PROJECT_ID (vous pouvez le trouver sur la page d'accueil de la console GCloud), GOOGLE_COMPUTE_ZONE (une zone pour votre cluster GKE) et GOOGLE_CLUSTER_NAME (nom du cluster GKE).

La dernière étape (déploiement) chez CircleCI ressemblera à :

 kubectl patch deployment sample -p '{"spec":{"template":{"spec":{"containers":[{"name":"sample","image":"gcr.io/test-d6bf8/simple:'"$CIRCLE_SHA1"'"}]}}}}' if ! kubectl rollout status deploy/sample; then echo "DEPLOY FAILED, ROLLING BACK TO PREVIOUS" kubectl rollout undo deploy/sample # Deploy failed -> notify slack else echo "Deploy succeeded, current version: ${CIRCLE_SHA1}" # Deploy succeeded -> notify slack fi deployment.extensions/sample patched Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... deployment "sample" successfully rolled out Deploy succeeded, current version: 512eabb11c463c5431a1af4ed0b9ebd23597edd9

Conclusion

On dirait que le processus de création d'un nouveau cluster Kubernetes n'est pas si difficile ! Et le processus CI/CD est vraiment génial !

Oui! Kubernetes est génial ! Avec Kubernetes, votre système sera plus stable, facilement gérable et fera de vous le capitaine de votre système. Sans oublier que Kubernetes gamifie un peu le système et donnera +100 points pour votre marketing !

Maintenant que vous maîtrisez les bases, vous pouvez aller plus loin et transformer cela en une configuration plus avancée. Je prévois d'en couvrir plus dans un futur article, mais en attendant, voici un défi : créez un cluster Kubernetes robuste pour votre application avec une base de données avec état située à l'intérieur du cluster (y compris un pod sidecar pour effectuer des sauvegardes), installez Jenkins à l'intérieur du même cluster Kubernetes pour le pipeline CI/CD, et laissez Jenkins utiliser les pods comme esclaves pour les builds. Utilisez certmanager pour ajouter/obtenir un certificat SSL pour votre entrée. Créez un système de surveillance et d'alerte pour votre application à l'aide de Stackdriver.

Kubernetes est génial car il évolue facilement, il n'y a pas de verrouillage du fournisseur et, puisque vous payez pour les instances, vous économisez de l'argent. Cependant, tout le monde n'est pas un expert de Kubernetes ou n'a pas le temps de mettre en place un nouveau cluster - pour une vue alternative, son collègue Toptaler Amin Shah Gilani plaide en faveur de l'utilisation de Heroku, GitLab CI et d'une grande quantité d'automatisation qu'il a déjà compris afin d'écrire plus de code et d'effectuer moins de tâches opérationnelles dans How to Build an Effective Initial Deployment Pipeline .