Lorsque vous souhaitez utiliser Linux pour fournir des services à une entreprise, ces services doivent être sécurisés, résilients et évolutifs. De beaux mots, mais qu'entend-on par eux?
«Sécurisé» signifie que les utilisateurs peuvent accéder aux données dont ils ont besoin, qu’il s’agisse d’un accès en lecture seule ou d’un accès en écriture. Dans le même temps, aucune donnée n'est exposée à une partie qui n'est pas autorisée à les voir. La sécurité est trompeuse: vous pouvez penser que tout est protégé pour découvrir plus tard qu'il y a des trous. Concevoir en sécurité dès le début d'un projet est bien plus facile que d'essayer de le moderniser plus tard.
«Résilient» signifie que vos services tolèrent les pannes au sein de l’infrastructure. Un échec peut être un contrôleur de disque de serveur qui ne peut plus accéder à aucun disque, rendant les données inaccessibles. Ou la panne peut être un commutateur réseau qui ne permet plus à deux ou plusieurs systèmes de communiquer. Dans ce contexte, un «point de défaillance unique» ou SPOF est une défaillance qui affecte négativement la disponibilité du service. Une infrastructure résiliente est une infrastructure sans SPOF.
«Évolutif» décrit la capacité des systèmes à gérer les pics de demande avec élégance. Il dicte également la facilité avec laquelle des modifications peuvent être apportées aux systèmes. Par exemple, ajouter un nouvel utilisateur, augmenter la capacité de stockage ou déplacer une infrastructure d'Amazon Web Services vers Google Cloud - ou même la déplacer en interne.
Dès que votre infrastructure s'étend au-delà d'un seul serveur, il existe de nombreuses options pour augmenter la sécurité, la résilience et l'évolutivité. Nous verrons comment ces problèmes ont été résolus traditionnellement et quelles nouvelles technologies sont disponibles qui changent le visage des grandes applications informatiques.
Obtenez plus de Linux!
Vous aimez ce que vous lisez? Vous voulez plus de Linux et d'open source? Nous pouvons livrer, littéralement! Abonnez-vous au format Linux dès aujourd'hui à un prix avantageux. Vous pouvez obtenir des problèmes d'impression, des éditions numériques ou pourquoi pas les deux? Nous livrons à votre porte dans le monde entier pour un tarif annuel simple. Alors rendez votre vie meilleure et plus facile, abonnez-vous maintenant!
Pour comprendre ce qui est possible aujourd'hui, il est utile de regarder comment les projets technologiques ont été traditionnellement mis en œuvre. Autrefois, c'est-à-dire il y a plus de 10 ans, les entreprises achetaient ou louaient du matériel pour exécuter tous les composants de leurs applications. Même des applications relativement simples, comme un site Web WordPress, ont plusieurs composants. Dans le cas de WordPress, une base de données MySQL est nécessaire avec un serveur Web, tel qu'Apache, et un moyen de gérer le code PHP. Ainsi, ils construisaient un serveur, installaient Apache, PHP et MySQL, installaient WordPress et partaient.
Dans l'ensemble, cela a fonctionné. Cela a suffisamment bien fonctionné pour qu'il y ait encore un grand nombre de serveurs configurés exactement de cette manière aujourd'hui. Mais ce n’était pas parfait, et deux des plus gros problèmes étaient la résilience et l’évolutivité.
Le manque de résilience signifiait que tout problème important sur le serveur entraînerait une perte de service. De toute évidence, une panne catastrophique signifierait pas de site Web, mais il n'y avait pas non plus de place pour effectuer une maintenance planifiée sans affecter le site Web. Même l'installation et l'activation d'une mise à jour de sécurité de routine pour Apache nécessiteraient une interruption de quelques secondes pour le site Web.
Le problème de la résilience a été en grande partie résolu par la création de «grappes à haute disponibilité». Le principe était de disposer de deux serveurs exécutant le site Web, configurés de telle sorte que l’échec de l’un ou de l’autre n’entraîne pas une panne du site Web. Le service fourni était résilient même si les serveurs individuels ne l'étaient pas.
Nuages abstraitsUne partie de la puissance de Kubernetes est l'abstraction qu'il offre. Du point de vue du développeur, ils développent l'application pour qu'elle s'exécute dans un conteneur Docker. Docker ne se soucie pas de savoir s’il s’exécute sous Windows, Linux ou un autre système d’exploitation. Ce même conteneur Docker peut être extrait du MacBook du développeur et exécuté sous Kubernetes sans aucune modification.
L'installation de Kubernetes elle-même peut être une seule machine. Bien sûr, de nombreux avantages de Kubernetes ne seront pas disponibles: il n'y aura pas de mise à l'échelle automatique; il y a un point de défaillance unique évident, et ainsi de suite. En tant que preuve de concept dans un environnement de test, cependant, cela fonctionne.
Une fois que vous êtes prêt pour la production, vous pouvez l'exécuter en interne ou sur un fournisseur cloud tel qu'AWS ou Google Cloud. Les fournisseurs de cloud ont des services intégrés qui aident à exécuter Kubernetes, mais aucun d'entre eux n'est requis. Si vous souhaitez vous déplacer entre Google, Amazon et votre propre infrastructure, vous configurez Kubernetes et vous vous déplacez. Aucune de vos applications ne doit changer de quelque manière que ce soit.
Et où est Linux? Kubernetes fonctionne sous Linux, mais le système d'exploitation est invisible pour les applications. Il s'agit d'une étape significative dans la maturité et la convivialité des infrastructures informatiques.
L'effet Slashdot
Le problème de l'évolutivité est un peu plus délicat. Disons que votre site WordPress reçoit 1 000 visiteurs par mois. Un jour, votre entreprise est mentionnée sur Radio 4 ou sur la télévision du petit-déjeuner. Soudainement, vous obtenez plus d’un mois de visiteurs en 20 minutes. Nous avons tous entendu des histoires de sites Web «en panne», et c’est généralement pour cela: un manque d’évolutivité.
Les deux serveurs qui ont contribué à la résilience pourraient gérer une charge de travail plus élevée qu'un seul serveur, mais cela reste limité. Vous paieriez pour deux serveurs 100% du temps et la plupart du temps, les deux fonctionnaient parfaitement. Il est probable qu’un seul puisse gérer votre site. Ensuite, John Humphrys mentionne votre entreprise sur Today et vous auriez besoin de 10 serveurs pour gérer la charge, mais seulement pour quelques heures.
La meilleure solution au problème de résilience et d'évolutivité était le cloud computing. Configurez une ou deux instances de serveur - les petits serveurs qui exécutent vos applications - sur Amazon Web Services (AWS) ou Google Cloud, et si l'une des instances échouait pour une raison quelconque, elle serait automatiquement redémarrée. Configurez correctement la mise à l'échelle automatique et lorsque M. Humphrys entraîne une augmentation rapide de la charge de travail sur vos instances de serveur Web, des instances de serveur supplémentaires sont automatiquement démarrées pour partager la charge de travail. Plus tard, à mesure que les intérêts diminuent, ces instances supplémentaires sont arrêtées et vous ne payez que ce que vous utilisez. Parfait… ou est-ce?
Bien que la solution cloud soit beaucoup plus flexible que le serveur autonome traditionnel, des problèmes persistent. La mise à jour de toutes les instances cloud en cours d'exécution n'est pas simple. Le développement pour le cloud présente également des défis: l'ordinateur portable que vos développeurs utilisent peut être similaire à l'instance cloud, mais ce n'est pas la même chose. Si vous vous engagez dans AWS, la migration vers Google Cloud est une entreprise complexe. Et supposons que, pour une raison quelconque, vous ne vouliez tout simplement pas céder votre ordinateur à Amazon, Google ou Microsoft?
Les conteneurs sont apparus comme un moyen d'encapsuler des applications avec toutes leurs dépendances dans un seul package qui peut être exécuté n'importe où. Les conteneurs, tels que Docker, peuvent fonctionner sur les ordinateurs portables de vos développeurs de la même manière qu'ils s'exécutent sur vos instances cloud, mais la gestion d'un parc de conteneurs devient de plus en plus difficile à mesure que le nombre de conteneurs augmente.
La réponse est l'orchestration de conteneurs. Il s'agit d'un changement d'orientation important. Auparavant, nous nous assurions d'avoir suffisamment de serveurs, qu'ils soient physiques ou virtuels, pour nous assurer de pouvoir gérer la charge de travail. L'utilisation de l'autoscaling des fournisseurs de cloud a aidé, mais nous étions toujours confrontés à des instances. Nous avons dû configurer manuellement les équilibreurs de charge, les pare-feu, le stockage de données et plus encore. Avec l'orchestration de conteneurs, tout cela (et bien plus encore) est pris en charge. Nous spécifions les résultats dont nous avons besoin et nos outils d'orchestration de conteneurs répondent à nos exigences. Nous spécifions ce que nous voulons faire, plutôt que comment nous voulons que cela soit fait.
Devenez un Kubernete
Kubernetes (ku-ber-net-eez) est le principal outil d'orchestration de conteneurs aujourd'hui, et il est venu de Google. Si quelqu'un sait gérer des infrastructures informatiques à grande échelle, Google le sait. L'origine de Kubernetes est Borg, un projet interne de Google qui est encore utilisé pour exécuter la plupart des applications de Google, y compris son moteur de recherche, Gmail, Google Maps et plus encore. Borg était un secret jusqu'à ce que Google publie un article à ce sujet en 2015, mais l'article montrait clairement que Borg était la principale source d'inspiration de Kubernetes.
Borg est un système qui gère les ressources de calcul dans les centres de données de Google et maintient les applications de Google, à la fois en production et ailleurs, en cours d'exécution malgré une panne matérielle, l'épuisement des ressources ou d'autres problèmes qui auraient pu autrement provoquer une panne. Pour ce faire, il surveille attentivement les milliers de nœuds qui composent une «cellule» Borg et les conteneurs qui y sont exécutés, et démarre ou arrête les conteneurs selon les besoins en réponse à des problèmes ou des fluctuations de charge.
Kubernetes lui-même est né de l'initiative GIFEE («Google’s Infrastructure For Everyone Else») de Google et a été conçu pour être une version plus conviviale de Borg qui pourrait être utile en dehors de Google. Il a été donné à la Linux Foundation en 2015 à travers la formation de la Cloud Native Computing Foundation (CNCF).
Kubernetes fournit un système par lequel vous «déclarez» vos applications et services conteneurisés, et il s'assure que vos applications s'exécutent conformément à ces déclarations. Si vos programmes nécessitent des ressources externes, telles que le stockage ou des équilibreurs de charge, Kubernetes peut les provisionner automatiquement. Il peut faire évoluer vos applications vers le haut ou vers le bas pour suivre les changements de charge, et peut même faire évoluer l'ensemble de votre cluster si nécessaire. Les composants de votre programme n’ont même pas besoin de savoir où ils sont exécutés: Kubernetes fournit des services de dénomination internes aux applications afin qu’elles puissent se connecter à «wp_mysql» et être automatiquement connectées à la bonne ressource. »
Le résultat final est une plate-forme qui peut être utilisée pour exécuter vos applications sur n'importe quelle infrastructure, d'une seule machine via un rack de systèmes sur site à des flottes de machines virtuelles basées sur le cloud fonctionnant sur n'importe quel fournisseur de cloud majeur, utilisant tous les mêmes conteneurs. et configuration. Kubernetes est indépendant du fournisseur: exécutez-le où vous le souhaitez.
Kubernetes est un outil puissant et forcément complexe. Avant d'entrer dans un aperçu, nous devons introduire certains termes utilisés dans Kubernetes. Les conteneurs exécutent des applications uniques, comme indiqué ci-dessus, et sont regroupés en pods. Un pod est un groupe de conteneurs étroitement liés qui sont déployés ensemble sur le même hôte et partagent certaines ressources. Les conteneurs d'un pod fonctionnent en équipe: ils exécuteront des fonctions associées, telles qu'un conteneur d'application et un conteneur de journalisation avec des paramètres spécifiques pour l'application.
Les quatre composants clés de Kubernetes sont le serveur API, le planificateur, le Controller Manager et une base de données de configuration distribuée appelée etcd. Le serveur API est au cœur de Kubernetes et sert de point de terminaison principal pour toutes les demandes de gestion. Ceux-ci peuvent être générés par diverses sources, y compris d'autres composants Kubernetes, tels que le planificateur, les administrateurs via des tableaux de bord en ligne de commande ou basés sur le Web, et les applications conteneurisées elles-mêmes. Il valide les demandes et met à jour les données stockées dans etcd.
Le planificateur détermine sur quels nœuds les différents pods seront exécutés, en tenant compte des contraintes telles que les besoins en ressources, les contraintes matérielles ou logicielles, la charge de travail, les délais, etc.
Le Controller Manager surveille l'état du cluster et essaiera de démarrer ou d'arrêter les pods comme nécessaire, via le serveur API, pour amener le cluster à l'état souhaité. Il gère également certaines connexions internes et fonctionnalités de sécurité.
Chaque nœud exécute un processus Kubelet, qui communique avec le serveur API et gère les conteneurs - généralement à l'aide de Docker - et Kube-Proxy, qui gère le proxy réseau et l'équilibrage de charge au sein du cluster.
Le système de base de données distribuée etcd tire son nom du /etc dossier sur les systèmes Linux, qui est utilisé pour contenir les informations de configuration du système, plus le suffixe «d», souvent utilisé pour désigner un processus démon. Les objectifs d'etcd sont de stocker les données clé-valeur de manière distribuée, cohérente et tolérante aux pannes.
Le serveur API conserve toutes ses données d'état dans etcd et peut exécuter plusieurs instances simultanément. Le planificateur et le gestionnaire de contrôleur ne peuvent avoir qu'une seule instance active, mais utilisent un système de bail pour déterminer quelle instance en cours d'exécution est le maître. Tout cela signifie que Kubernetes peut fonctionner comme un système hautement disponible sans point de défaillance unique.
Mettre tous ensemble
Alors, comment utilisons-nous ces composants dans la pratique? Ce qui suit est un exemple de configuration d'un site Web WordPress à l'aide de Kubernetes. Si vous vouliez le faire pour de vrai, vous utiliseriez probablement une recette prédéfinie appelée graphique de barre. Ils sont disponibles pour un certain nombre d'applications courantes, mais nous examinerons ici certaines des étapes nécessaires pour qu'un site WordPress soit opérationnel sur Kubernetes.
La première tâche consiste à définir un mot de passe pour MySQL:
kubectl create secret générique mysql-pass --from-literal = password = YOUR_PASSWORD
kubectl parlera au serveur API, qui validera la commande puis stockera le mot de passe dans etcd. Nos services sont définis dans des fichiers YAML, et nous avons maintenant besoin d'un stockage persistant pour la base de données MySQL.
apiVersion: v1 kind: PersistentVolumeClaim métadonnées: nom: mysql-pv-claim labels: app: wordpress spec: accessModes: - ressources ReadWriteOnce: requêtes: stockage: 20Gi
La spécification doit être pour la plupart auto-explicative. Les champs de nom et d'étiquettes sont utilisés pour faire référence à ce stockage à partir d'autres parties de Kubernetes, dans ce cas notre conteneur WordPress.
Une fois que nous avons défini le stockage, nous pouvons définir une instance MySQL en la pointant vers le stockage prédéfini. Ensuite, définissez la base de données elle-même. Nous donnons à cette base de données un nom et une étiquette pour une référence facile dans Kubernetes.
Nous avons maintenant besoin d'un autre conteneur pour exécuter WordPress. Une partie de la spécification de déploiement de conteneur est:
kind: Métadonnées de déploiement: nom: étiquettes wordpress: application: spécification wordpress: stratégie: type: recréer
Le type de stratégie «Recréer» signifie que si l'un des codes comprenant l'application change, les instances en cours d'exécution seront supprimées et recréées. D'autres options incluent la possibilité de faire passer de nouvelles instances dans et de supprimer les instances existantes, une par une, permettant au service de continuer à s'exécuter pendant le déploiement d'une mise à jour. Enfin, nous déclarons un service pour WordPress lui-même, comprenant le code PHP et Apache. Une partie du fichier YAML déclarant cela est:
metadata: name: wordpress labels: app: wordpress spec: ports: - port: 80 selector: app: wordpress tier: frontend type: LoadBalancer
Notez la dernière ligne, définissant le type de service comme LoadBalancer. Cela demande à Kubernetes de rendre le service disponible en dehors de Kubernetes. Sans cette ligne, ce serait simplement un service interne «Kubernetes uniquement». Et c'est tout. Kubernetes utilisera désormais ces fichiers YAML comme une déclaration de ce qui est requis, et configurera les pods, les connexions, le stockage, etc. selon les besoins pour amener le cluster dans l'état «souhaité».
Cela n'a nécessairement été qu'une vue d'ensemble de haut niveau de Kubernetes, et de nombreux détails et fonctionnalités du système ont été omis. Nous avons passé en revue l'autoscaling (à la fois les pods et les nœuds qui composent un cluster), les tâches cron (démarrage des conteneurs selon un calendrier), Ingress (équilibrage de charge HTTP, réécriture et déchargement SSL), RBAC (contrôles d'accès basés sur les rôles) , les politiques réseau (pare-feu), et bien plus encore. Kubernetes est extrêmement flexible et extrêmement puissant: pour toute nouvelle infrastructure informatique, il doit être un concurrent sérieux.
Ressources
Si vous n'êtes pas familier avec Docker, commencez ici: https://docs.docker.com/get-started.
Il existe un didacticiel interactif sur le déploiement et la mise à l'échelle d'une application ici: https://kubernetes.io/docs/tutorials/kubernetes-basics.
Et consultez https://kubernetes.io/docs/setup/scratch pour savoir comment créer un cluster.
Vous pouvez jouer avec un cluster Kubernetes gratuit sur https://tryk8s.com.
Enfin, vous pouvez parcourir un long article technique avec un excellent aperçu de l'utilisation de Borg par Google et de la manière dont cela a influencé la conception de Kubernetes ici: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
En savoir plus sur Tiger Computing.
- Meilleur stockage cloud de 2022-2023 en ligne: options gratuites, payantes et professionnelles
Vous aimez ce que vous lisez? Vous voulez plus de Linux et d'open source? Nous pouvons livrer, littéralement! Abonnez-vous au format Linux dès aujourd'hui à un prix avantageux. Vous pouvez obtenir des problèmes d'impression, des éditions numériques ou pourquoi pas les deux? Nous livrons à votre porte dans le monde entier pour un tarif annuel simple. Alors rendez votre vie meilleure et plus facile, abonnez-vous maintenant!