Introduction de Jack: Pour conclure 2019, nous avons invité certains de nos contributeurs fréquents à rédiger un dernier article sur n'importe quel sujet qui les intéresse actuellement. Quand Rachel a mentionné Kubernetes, j'ai pensé que c'était génial. Je sais que j'ai parcouru certaines parties du discours d'ouverture de VMworld 2019 en souhaitant avoir le temps d'en savoir plus!
Kubernetes (souvent appelé K8s) est «un système d'orchestration de conteneurs open source pour automatiser le déploiement, la mise à l'échelle et la gestion des applications». (Cette définition concise provient de Wikipedia.) Cela signifie essentiellement que c'est quelque chose qui est utile pour DevOps, la livraison les gestionnaires et les développeurs.
Kubernetes n'est pas quelque chose qui affecte manifestement ou directement l'utilisateur final ou le client pour la plupart des fournisseurs, mais peut résoudre de nombreux problèmes auxquels les fournisseurs sont confrontés en fournissant des produits de haute qualité et des expériences utilisateur réactives à leurs clients finaux.
Commençons par quelques défis réels auxquels les fournisseurs sont confrontés et qui ont un impact sur ce que les clients vivent réellement:
- Bogues dans l'application uniquement et spécifiques au matériel. La plupart des gens connaissent le scénario où un client appelle le support technique pour un problème logiciel, mais le support technique ne peut tout simplement pas reproduire le problème. Il peut y avoir des allers-retours tandis que le support obtient une vidéo du client et une tonne de vidages système et d'informations sur le matériel, et certains courent pour trouver du matériel similaire, mais personne ne sait vraiment pourquoi le problème n'apparaît que sur le système d'origine. À ce stade, cela peut s'intensifier dans le développement, et un développeur grincheux peut très bien se plaindre du fait que le support ne fournit pas suffisamment de détails tangibles pour résoudre le problème, et un "ne peut pas reproduire le drapeau" peut bien être attaché au ticket.
- Un fournisseur lance une application basée sur un service Web, par exemple, une carte cliquable de leurs emplacements de bureau, elle est promue par une célébrité et la demande augmente. Tout d'un coup, le back-end de l'application ne peut pas faire face et le serveur d'hébergement se bloque ou se bloque; l'utilisateur final trouve que la carte est lente, ne répond pas ou peut-être pas disponible.
- Une institution financière ou une banque peut exécuter de nombreuses applications pour accéder aux comptes clients; ceux-ci peuvent très bien être appelés par une chaîne d'applications, par exemple, la demande d'émettre une déclaration. Le contrôle et la limitation des applications pouvant accéder aux fonctionnalités sont essentiels pour la sécurité.
Sommaire
Notions de base sur les conteneurs
Avant d'entrer dans les détails de Kubernetes, commençons par les bases des conteneurs. En 2007, certains ingénieurs de Google ont ajouté des fonctionnalités au noyau Linux sous le terme générique cgroups; natives et intrinsèques au noyau, ces fonctionnalités ont fourni des fonctionnalités pour limiter et isoler les ressources (CPU, mémoire, E / S disque, réseau, etc.) utilisées par les collections de processus. Tirer parti de ces fonctionnalités a permis aux conteneurs d'apparaître, à savoir LXC (Linux Containers), une méthode de virtualisation au niveau du système d'exploitation pour exécuter plusieurs systèmes Linux isolés (conteneurs) sur un hôte de contrôle à l'aide d'un seul noyau Linux. En plus du contrôle des ressources cgroup, une fonctionnalité a été fournie pour l'isolement de l'espace de noms, ainsi que l'isolement complet de la vue d'une application de l'environnement d'exploitation, y compris les arborescences de processus, la mise en réseau, les ID utilisateur et les systèmes de fichiers montés. En d'autres termes, c'était un moyen de virtualiser en toute sécurité une application dans le noyau Linux lui-même, sans avoir besoin de faire tourner une machine virtuelle (VM).
Dans la virtualisation traditionnelle, chaque machine virtuelle a son propre système d'exploitation. Cela signifie que la séparation des applications en les plaçant dans des machines virtuelles distinctes a un coût élevé, car cela implique de faire tourner la machine virtuelle et de la doter de ressources en termes de temps et de matériel. En revanche, les conteneurs sont très évolutifs et légers, et également très sécurisés en particulier, car ils ne peuvent interagir que via des interfaces définies. Souvent, les conteneurs sont appelés environnements virtuels (VE), et parce qu'ils sont intégrés au noyau, il n'y a pas de surcharge d'émulation et vous obtenez des performances natives.
Il n’existe pas de méthode unique pour définir les conteneurs; et plusieurs LXC étendus au genre ont évolué. Docker est probablement le profil le plus élevé; il résume un peu plus l'utilisateur final et automatise le processus de définition des conteneurs, la façon dont ils communiquent, etc. Il existe une FAQ utile sur le site Docker qui explique cela plus en détail, y compris la configuration des conteneurs et la fonctionnalité de création de modèles. L'une des principales caractéristiques est que Docker fournit un mécanisme pour générer des conteneurs portables sur différentes machines, bien que de nombreux autres mécanismes existent déjà. Il convient également de noter que bien que le cadre Kubernetes soit open source, Docker est un produit propriétaire, en effet qui a très récemment changé de mains.
Une fois que nous avons des conteneurs, nous avons maintenant une solution au problème de ces bogues in-application ou "ça marche sur ma machine". Si une application est déployée dans un conteneur, sa vision du monde est toujours la même. La ségrégation et le sandboxing signifient qu'une autre application ne peut pas écraser la mémoire utilisée, etc. Les conteneurs peuvent être utiles aux développeurs individuels et gérés et scriptés à petite échelle par de nombreux mécanismes.
Les conteneurs sont strictement définis, et en tant que tels, la façon dont ils peuvent communiquer peut être très étroitement contrôlée et limitée. Les applications peuvent être conçues pour des tâches très spécifiques, qui ne sont autorisées à communiquer qu'avec un public très restreint. Ce type d'architecture permet des microservices, qui sont intrinsèquement sécurisés et évolutifs. Les conteneurs prennent en charge de petites applications très spécifiques qui peuvent effectuer des tâches très personnalisées et fournir des services spécifiques (par exemple, imprimer un relevé bancaire pour un client). Les architectures de microservices présentent de nombreux avantages: surface à faible attaque, donc sécurisée; et des fonctionnalités clairement définies, de sorte que la propriété et la maintenance sont faciles.
Kubernetes, l'option populaire
Kubernetes est l'un des frameworks d'orchestration de conteneurs les plus populaires, provenant à nouveau de Google, et désormais open source. Il existe des alternatives (certains ont construit leur propre orchestration en interne) et de nombreux produits qui consomment Kubernetes pour produire des systèmes d'orchestration propriétaires et pris en charge, ou même des produits / services IaaS / PaaS (de la même manière que la façon dont KVM open-source est consommé). ). La possibilité d'orchestrer de nombreux conteneurs permet de résoudre ce problème causé par l'application de carte occupée, avec l'orchestration pour fournir une application hautement disponible. Plusieurs conteneurs avec des configurations identiques peuvent être filés associés à un équilibre de charge, et en cas de surtension d'utilisation, plus de conteneurs peuvent être filés très rapidement. Ou en cas d'échec, le basculement peut être géré.
Kubernetes lui-même n'est cependant qu'un cadre, c'est probablement pourquoi tant d'explications sont simplement turgescentes alors qu'elles plongent dans la discussion de la structure des composants de Kubernetes (pods, espaces de noms, etc.). En tant que framework, vous devez généralement ajouter énormément d'outils ou de fonctionnalités tiers pour créer un système fonctionnel. Il est incroyablement flexible, car les possibilités sont infinies, mais pour construire votre propre système, vous devez comprendre l'architecture. Si vous voulez aller plus loin, le point de départ le plus accessible est probablement le «Guide illustré pour enfants de Kubernetes», disponible sur YouTube. Docker est probablement la définition de conteneur la plus connue utilisée par Kubernetes pour orchestrer, mais de nombreuses autres options sont possibles, et l'utilisation de Kubernetes est indépendante du choix de Docker ou d'une alternative. (Parfois, les deux technologies sont confondues / confondues dans les explications.)
Les types de produits et services ajoutés à Kubernetes donnent une idée de ce qui est nécessaire: stockage et gestion des hôtes (AWS, Ceph, Terraform), création de modèles de conteneurs et enregistrement de services (Docker, Rancher, Helm, JFrog), journalisation et mesures ( Grafana, Fluentd), construction et publication de code (Jenkins, GitHub) et équilibrage de charge (NetScaler / Citrix ADC).
La conteneurisation est presque certainement la voie à suivre si vous avez des produits qui doivent s'exécuter à travers l'infrastructure d'entreprise et cloud. Alors, qui est susceptible d'adopter l'orchestration de conteneurs, qui est susceptible de gagner de l'argent grâce à la demande croissante, et quels marchés (par exemple, l'IoT) pourrait-il ouvrir pour les fournisseurs qui investissent dans les flux technologiques de type Kubernetes?
Vendeurs EUC internes
Les solutions EUC incluent généralement un grand nombre de produits en interaction de nombreux fournisseurs communiquant via des intégrations, des plug-ins et des API. Les technologies à composants bénéficient naturellement de la conteneurisation au sein de leur infrastructure de développement et de test, améliorant la qualité des produits et réduisant les problèmes de support et les appels. En tant que tel, si vous êtes un directeur de l'ingénierie chez un fournisseur EUC, c'est quelque chose que vous devez vraiment examiner.
Clients Enterprise EUC
Pour ceux qui ont déjà investi dans le VDI à grande échelle, les déploiements de conteneurs gérés ont du sens pour leurs propres produits de développement et de service. Pensez à ces gros clients financiers et fédéraux qui développent des applications et des services ainsi que consomment du VDI. Si vous êtes déjà un magasin VMware, obtenir votre DevOps et votre architecture de conteneur auprès de votre fournisseur d'entreprise existant est très logique. En effet, VMware semble très conscient de cela et a une histoire Kubernetes crédible avec son plan de contrôle de gestion Kubernetes VMware PKS. Pour le lecteur EUC, les informations concernant l'offre de VMware sont probablement l'une des meilleures informations sur ce marché, VMware a également publié de beaux livres blancs de haut niveau (lisibles) dans ce domaine: «Démystifier Kubernetes» et «Conduire la transformation numérique avec Conteneurs et Kubernetes. ”
Parmi les fournisseurs de VDI, VMware semble être le seul acteur sérieux à l'heure actuelle, les plus grands acteurs du cloud étant leur concurrence la plus importante (Amazon AWS, Microsoft Azure et Google GCP). La seule petite poche de Citrix qui semble être très investie dans la tendance générale de l'industrie est leur équipe NetScaler / ADC (équilibrage de charge et fonctionnalités similaires). Il s'agit simplement d'une intégration qui permet à ceux qui utilisent Kubernetes d'ajouter Citrix ADC à un cadre Kubernetes, mais rien n'indique que l'organisation au sens large recherche une partie de l'action, avec un jeu à impliquer dans cette gestion ou cette infrastructure. Ils ont cependant de bons blogs sur l'intégration d'ADC, "Pourquoi tout le monde parle de Citrix et Kubernetes" et "Citrix ADC pour Kubernetes frappe à Kubernetes Front Door".
Les clients EUC existants qui consultent VMware sont susceptibles de jeter un œil aux offres de plus en plus matures provenant directement des grands clouds tels que AWS EKS d'Amazon, AKS de Microsoft Azure (Azure Kubernetes Service) et GKE de Google GCP (Google Kubernetes Engine). Avec des options sur site et des options VDI cloud croissantes (en particulier le WVD de Microsoft) entre elles, il est clair pourquoi VMware pourrait être désireux de garder les magasins VMware heureux plutôt que de laisser le grand DevOps et le marché des applications de leur grande base d'entreprise traditionnelle ouverte.
En dehors d'EUC / VDI, les grands fournisseurs traditionnels d'entreprise sur site utilisent également une infrastructure de type Kubernetes, comme IBM, Oracle et SAP, c'est donc certainement une tendance d'entreprise dominante sur laquelle VMware s'aligne et avec le chevauchement des leur clientèle a beaucoup de sens pour eux.
Les produits conteneurisés pourraient-ils pousser ceux basés sur la virtualisation traditionnelle?
Considérez les économies de produits utilisant des conteneurs (VE) au lieu de VM: il existe des produits cloud là où le VDI traditionnel peut être utilisé, mais les conteneurs offrent des avantages similaires avec une plus grande évolutivité et une meilleure économie. Un exemple évident est les produits de navigation à distance dont nous avons vu une surabondance et que nous avons examinés. Il y a quelques mois, nous avons examiné l'offre basée sur les conteneurs de Menlo. Pour les fournisseurs VDI traditionnels offrant des machines virtuelles similaires mais basées sur des machines virtuelles, les coûts plus élevés de l'infrastructure pour prendre en charge les machines virtuelles peuvent rendre ces produits beaucoup moins viables que ceux tels que Menlo (un produit tel que Citrix Remote Browser peut-il évoluer aussi facilement et sans coûts plus élevés?). Il y a des offres «cloud» des fournisseurs EUC où ils ont évidemment pris leur technologie VM héritée et l'ont piratée dans le cloud – vous pouvez littéralement voir (et attendre) que les VM tournoient pour prendre en charge les DDC, etc. Produits architecturés pour le cloud pourrait bien avoir un avantage concurrentiel; avec des conteneurs, vous pouvez souvent obtenir 2 à 3 fois plus d'utilisateurs sur un serveur qu'avec la virtualisation traditionnelle basée sur une machine virtuelle.
Une bonne stratégie Kubernetes pourrait être bonne pour les marchés IoT
La nature microservice de la conteneurisation se prête également très bien aux produits IoT. Avec potentiellement des millions d'appareils intelligents et connectés à mettre à jour, la nature légère de la conteneurisation et l'évolutivité inhérente de Kubernetes sont une bonne correspondance et se complètent bien. Nous avons écrit il y a un certain temps s'il y avait une place pour les fournisseurs EUC dans l'IoT, depuis lors, VMware a continué d'investir dans l'IoT, et en tandem avec leur jeu Kubernetes géré, ils sont bien placés pour construire une plate-forme IoT, tandis que OctoBlu IoT de Citrix l'acquisition a depuis cessé d'être soutenue. Encore une fois, c'est un domaine où Citrix a fait du bruit et des démos (commande Alexa de votre machine virtuelle ou un truc de type ampoule) mais peu tangible en a résulté qui ressemble à un produit évolutif de qualité entreprise.
Au-delà de Kubernetes: fournisseurs d'hébergement géré et PaaS
Kubernetes est sans aucun doute une bête absolue, qui nécessite un engagement important de budget, de DevOps qualifiés et d'administration; même avec les services de gestion de Kubernetes proposés, c'est un énorme engagement. Pour de nombreuses entreprises, en particulier les petites et moyennes entreprises, mais aussi pour les grandes organisations ayant des besoins assez homogènes (par exemple, des sites Web à grande échelle, des applications Web à gérer), un produit de niveau supérieur peut être un meilleur choix. Il existe des radeaux d'organisations avec des centaines, voire des milliers de sites Web et d'applications, où l'orchestration de conteneurs offre de nombreux avantages, mais la création de votre propre Kubernetes est bien exagérée.
Les deux fournisseurs d'hébergement géré ou les plus petits PaaS sur mesure (Platform as a Service) peuvent offrir une offre plus clé en main. En particulier avec les offres PaaS, le fournisseur prend en charge la mise en œuvre et la maintenance de Kubernetes / framework similaire et de tous les produits composants en son sein, afin que vos développeurs, les responsables de la livraison des applications, les responsables du contenu et les administrateurs système n'aient pas à se soucier de savoir si tous les les produits dans le cadre sont corrigés de sécurité ou comment ils interagissent et ils fournissent des SLA pour une haute disponibilité. En cas de problème, des accords de support d'entreprise et des services d'assistance sont disponibles sans avoir à prendre en charge le support en interne. Un nom que EUC connaît peut-être dans ce domaine est DigitalOcean, où l'ancien PDG de Citrix, Mark Templeton, a déménagé pendant un certain temps.
Il est révélateur que, sous le capot, de nombreux fournisseurs répertoriés dans Gartner Magic Quadrants, tels que «Digital Experience Platforms» ou «Web Content Management», sont essentiellement de l'orchestration Kubernetes / conteneur avec beaucoup de produits hors du commun. plomberie et outillage de boîte et quelques babioles GUI / WYSIWYG faciles à utiliser.
Conclusion
Bien que n'étant pas sur le radar d'un utilisateur XenApp ou Horizon de 500 sièges, l'adoption généralisée et la tendance à l'échelle de l'industrie pour Kubernetes ressemblent à un mastodonte avec un énorme élan. C’est certainement une chose à savoir; même s'il est peu probable que vous déployiez vous-même des K8, il est bon d'en savoir un peu mais sur la direction sous-jacente du cloud et de l'infrastructure d'entreprise.
Commentaires
Laisser un commentaire