🗝️ 🔕 👵🏾 "Docker est déjà mort" ou tout ce que vous vouliez savoir sur Devops mais que vous aviez peur de demander 🚻 🤝 📜

Récemment, Alexander Chistyakov, DevOps avec 7 ans d'expérience et co-fondateur de la St. Petersburg DevOps Engineers Community, s'est exprimé sur nos réseaux sociaux.

Sasha est l'un des meilleurs orateurs dans ce domaine, il a joué sur les scènes principales de Highload ++, RIT ++, PiterPy, Strike, faisant au moins 100 reportages au total. Lundi dernier, il a répondu aux questions des téléspectateurs et a parlé de son expérience.

Nous partageons l'enregistrement et la transcription de l'émission.

Je m'appelle Alexander Chistyakov, je travaille en tant qu'ingénieur DevOps depuis de nombreuses années. Je conseille depuis longtemps diverses entreprises sur la mise en œuvre des pratiques DevOps, l'utilisation d'outils DevOps modernes et l'organisation des infrastructures afin que nous puissions tous bien dormir la nuit et que les gens continuent à recevoir de l'argent pour leurs biens et services.

En gros, j'ai consulté des entreprises étrangères.

Nous parlerons de la façon dont les gens utilisent Kubernetes dans la pratique quotidienne, pourquoi il est nécessaire, pourquoi vous ne devriez pas en avoir peur, à quoi vous devriez faire attention et ce qui va se passer ensuite.

Je pense que les administrateurs système, les ingénieurs DevOps, les DSI et autres gestionnaires d'infrastructure (et supporters) le trouveront utile.

Comment ce paysage s'est-il développé? Je me souviens d'ordinateurs avec ROM Basic installé et il était possible d'écrire des programmes sans système d'exploitation installé. Depuis, beaucoup d'eau a coulé sous le pont. Au début, il n'y avait pas de système d'exploitation en tant que tel (plus précisément, ils étaient écrits en langage d'assemblage). Puis le langage C est apparu et la situation s'est considérablement améliorée. Bien sûr, nous connaissons maintenant tous le concept d'un OS: c'est une plateforme qui nous permet d'exécuter des applications personnalisées et de gérer les ressources que nous avons sur cet ordinateur. Ou d'autres, s'il est distribué. Même alors, il était possible d'assembler un cluster de calcul haute performance à partir de votre ordinateur portable et de votre ordinateur de bureau - c'est ce que les étudiants ont fait dans le dortoir de l'école polytechnique de Saint-Pétersbourg en 97.

Ensuite, il s'est avéré - j'ai probablement lu cet article il y a 10 ans - que Google, qui a inventé la messagerie Web, construit un système d'exploitation autour de cette messagerie Web afin que les utilisateurs puissent l'utiliser à partir de tablettes et de téléphones. C'était inattendu, généralement le système d'exploitation exécute les binaires, et lorsque vous regardez l'application via le navigateur, vous ne savez même pas si le binaire est là. Vous pouvez lire le courrier, discuter dans un messager en ligne, dessiner des diapositives, éditer des documents ensemble. Il s'est avéré que cela convient à beaucoup.

Certes, Google n'était pas très cohérent et fabriquait de nombreux produits de ce type qui n'étaient pas nécessaires et n'allaient pas au-delà du prototype - par exemple, Google Wave. Eh bien, c'est la politique de toute grande entreprise: agir rapidement, s'effondrer souvent, jusqu'à ce que l'entreprise cesse d'exister.

Néanmoins, dans la conscience de masse, il y a eu un glissement vers l'idée du système d'exploitation en tant que plate-forme qui ne fournit pas les services qui étaient autrefois approuvés par un comité de normalisation et qui lui étaient assignés, mais qui répond simplement aux besoins des utilisateurs. Quels sont ces besoins?

Il était de coutume de demander au développeur sur quoi il écrit. Il y avait des spécialistes C ++ (probablement, et maintenant il y en a quelque part), maintenant il y a beaucoup de spécialistes PHP (ils se moquent d'eux-mêmes, ça arrive) et beaucoup de développeurs JavaScript. Typescript, le langage GoLang vers lequel les personnes ayant des connaissances PHP sont passées, gagne maintenant en popularité. Il y avait le langage Perl (il reste probablement encore, mais a beaucoup perdu en popularité), le langage Ruby. En général, une application peut être écrite dans n'importe quoi. Si vous vivez dans le monde réel, vous avez probablement rencontré le fait qu'ils sont écrits dans n'importe quoi: Javascript, Rust, C; trouver un nom - quelque chose était écrit dessus.

Et tout cela doit être exploité. Il s'est avéré que dans un système aussi hétérogène, d'une part, des spécialistes sont nécessaires pour développer dans différentes langues et, d'autre part, une plate-forme est nécessaire qui vous permet de lancer un service dans un environnement agréable et de suivre son cycle de vie. Il y a un certain contrat avec cette plate-forme, qui dans le monde moderne ressemble à ceci: vous avez une image de conteneur (le système de gestion de conteneurs est maintenant partout - Docker, même si je ne peux rien dire de bon à ce sujet; nous parlerons des problèmes plus tard).

Malgré le fait que l'humanité avance dans un certain processus évolutif, ce processus a une convergence. Dans notre industrie, il s'avère que quelqu'un écrit toujours du code en Perl (sous mod_perl Apache), et que quelqu'un écrit déjà une architecture de microservice en GoLang. Il s'est avéré que le contrat avec la plate-forme est très important, le contenu de la plate-forme est très important et il est très important que la plate-forme aide une personne. Il devient très coûteux de faire des opérations manuelles pour conclure et démarrer le service. J'ai rencontré des projets où il y avait 20 services - et ce n'était pas un très gros projet; J'ai entendu parler de gars qui ont mille services différents. 20 est un montant normal; et chaque ensemble de services est développé par sa propre équipe dans sa propre langue, ils ne sont connectés que par le protocole d'échange.

En ce qui concerne le fonctionnement du contrat d'application. Il existe un "manifeste d'application à 12 facteurs" - 12 règles sur la manière dont une application doit être organisée de manière à être pratique à utiliser. Je ne l'aime pas. En particulier, il indique que vous devez fournir des configurations via des variables d'environnement; et j'ai rencontré à plusieurs reprises le fait que chez Amazon, par exemple, le nombre de variables d'environnement qui peuvent être transmises à Elastic Beanstalk est une page du noyau Linux - 4 kilo-octets. Et ils débordent très rapidement; lorsque vous avez 80 variables différentes, 81 est difficile à tenir. De plus, c'est un espace de configuration plat - quand il y a des variables, elles doivent être nommées en majuscules avec un trait de soulignement, et il n'y a pas de hiérarchie entre elles; il est difficile de comprendre ce qui se passe. Je n'ai pas encore trouvé comment gérer cela, et je n'ai personne avec qui en discuter - il n'y a pas de groupe de passionnés,qui serait contre une telle approche. Si tout à coup cela ne convient pas à quelqu'un non plus - écrivez-moi (déméliorateur dans Telegram), je saurai que je ne suis pas seul. Je n'aime absolument pas ça. Il est difficile de gérer, difficile de transférer des données hiérarchiques; il s'avère que le travail d'un ingénieur moderne est de savoir où se trouvent les variables, ce qu'elles signifient, si elles sont correctement définies, combien il est facile de les modifier. Je pense que les bonnes vieilles règles de configuration étaient meilleures.s'ils sont correctement configurés, combien il est facile de les changer. Il me semble que les bonnes vieilles règles de configuration étaient meilleures.s'ils sont correctement configurés, combien il est facile de les changer. Il me semble que les bonnes vieilles règles de configuration étaient meilleures.

Revenir au contrat. Il s'avère que vous avez besoin d'une image Docker: vous aurez besoin de Docker lui-même (malgré le fait qu'il soit lui-même pauvre - j'espère que certains Microsoft les achèteront et l'enterreront ou le développeront normalement). Si vous n'êtes pas satisfait de Docker, vous pouvez essayer Red Hat's Stack; Je ne peux rien dire sur lui, même s'il me semble que ça devrait être mieux que juste de la vanille Kubernetes. Les gars de Red Hat accordent beaucoup plus d'attention aux problèmes de sécurité, ils savent même comment faire des installations multi-tournées, multi-utilisateurs, multi-clients, avec une séparation normale des droits - en général, ils s'assurent que la gestion des droits est en place.

Attardons-nous sur les questions de sécurité. C'est mauvais avec elle partout, pas seulement sur Kubernetes. Si nous parlons de problèmes de sécurité et d'orchestration de conteneurs, j'ai de grands espoirs pour l'assemblage Web, qui est effectué côté serveur, et pour les applications d'assemblage Web, il sera possible de limiter la consommation de ressources, les appels système peuvent être liés dans des conteneurs spéciaux, dans Rust. Ce serait une bonne réponse à la question de sécurité. Et Kubernetes n'a aucune sécurité.

Disons que nous avons une application. C'est une image Docker, elle est à 12 facteurs - c'est-à-dire qu'elle peut prendre votre configuration à partir de variables d'environnement, d'un fichier que vous montez à l'intérieur du conteneur. Il peut être lancé - à l'intérieur il est autonome, vous pouvez essayer de le lier à d'autres applications via des configurations, automatiquement. Et il devrait écrire des journaux sur la sortie standard - ce qui est probablement le moins mauvais; lorsque le conteneur écrit des journaux dans des fichiers, il n'est pas très facile de les collecter à partir de là. Même Nginx a été patché pour qu'il soit possible de collecter des journaux à partir de la sortie standard du conteneur, cela est acceptable (par opposition au passage de la configuration via un paramètre). En fait, nous avions plusieurs orchestrateurs: Rancher, Marathon Mesos, Nomad; mais, comme le dit le principe d'Anna Karenina à propos des systèmes techniques,les systèmes techniques complexes sont organisés de la même manière.

Avec Kubernetes, nous avons la même situation que pour les compagnies aériennes avec le Boeing 737 MAX - il ne vole pas car il y a une erreur, mais il n'y a rien d'autre, car la conception est très complexe. Je ne peux pas dire que je l'aime - comme le langage GoLang, et le contrôle via le format YAML, quand vous avez une syntaxe, et qu'il n'y a rien dessus - pas de contrôle sur ce que vous écrivez, pas de types de données. Toutes les vérifications que vous effectuez avant d'appliquer des configurations dans Kubernetes sont des rudiments. Vous pouvez essayer d'appliquer la mauvaise configuration et elle s'appliquera sans question et vous ne savez pas quoi. Il est très facile d'écrire le mauvais fichier de configuration. C'est un gros problème, et les gens ont déjà commencé à le résoudre lentement en utilisant DSL et Kubernetes dans les langages Kotlin, même Typescript. Il y a un projet Pulumi,il existe un projet Amazon EKS - bien qu'il soit plus axé sur Amazon; Pulumi est un Terraform, uniquement en TypeScript. J'aurais aimé avoir essayé Pulumi encore parce que je crois que c'est l'avenir. La configuration doit être décrite dans un langage de programmation avec un typage statique fort, de sorte qu'avant d'utiliser, qui peut potentiellement détruire le cluster, on vous dise au moins au moment de la compilation que ce n'est pas possible.

Ainsi, pour le moment, il n'y a qu'un seul orchestrateur. Je sais qu'il reste quelques utilisateurs MATA, je leur serre la main; J'espère que personne d'autre n'utilise Docker Swarm - mon expérience avec celui-ci a été assez négative. Je pense qu'il pourrait en être autrement, mais je ne sais pas pourquoi; Je ne prévois pas de développement ultérieur de Docker Swarm, et je ne pense pas que les gens qui le publient vont en faire quoi que ce soit maintenant. Capitalisme; si vous ne gagnez pas d'argent, alors il n'y a rien à dépenser pour le développement - et leur entreprise est dans la «vallée de la mort» pour les startups depuis deux ans: personne ne veut leur donner de l'argent. Vous pouvez placer des offres sur qui les achètera. Microsoft n'était pas intéressé. Peut-être que certains Microfocus le feront si Docker survit.

Puisqu'il ne reste qu'un seul Kubernetes, parlons-en. Il y a une belle image avec un pentagramme de cinq de ses binaires; il est écrit que Kubernetes est très simple, seulement cinq binaires. Mais je suis loin de mesurer la complexité d'un système dans le nombre de binaires dans lesquels il est compilé et dans le nombre de services qui composent le cœur du système. Peu importe le nombre de binaires, ce qui compte, c'est ce que Kubernetes peut faire et comment il fonctionne en interne.

Que peut-il faire? Imaginez simplement que vous ayez besoin d'expliquer à un enfant de cinq ans ce que vous avez fait au travail. Et maintenant papa, qui a essayé d'écrire des playbooks et des rôles sur Ansible qui lui permettraient de faire un déploiement bleu-vert basé sur Nginx sur un hôte et un ensemble de conteneurs qui ne sont enregistrés avec rien d'autre que tv-ansible, dit: «Vous savez, mon fils, j'ai tout essayé il est temps de créer votre propre Kubernetes. Ça ne marche pas bien, c'est mal testé, je ne le comprends pas bien, je ne connais pas toutes les conditions aux limites, ça marche dans la même machine, mais c'est la mienne! " J'ai vu cela de façon injustifiée plusieurs fois - je l'ai juste regardé 2 ou 3 fois, et 2 fois j'ai participé à l'écriture de quelque chose comme ça. Tôt ou tard, une personne qui participe à cela se rend compte qu'il ne devrait pas y avoir de 4ème fois. C'est comme mes amis automobilesqui a restauré une fois le VAZ-2101 - installé des vitres électriques, réparé l'intérieur avec du floc, l'a peint en métal. Créer votre propre orchestrateur est quelque chose comme ça. Vous pouvez l'essayer une fois pour vous assurer que vous le pouvez, mais je ne suis pas prêt à le recommander à tout le monde - pas seulement aux passionnés. Par conséquent, la gestion du cycle de vie, la gestion de l'état des conteneurs est la tâche de Kubernetes.

Il peut s'assurer que le conteneur s'exécute sur le nœud où il y a des ressources, il peut redémarrer un conteneur mort, il peut s'assurer que si le conteneur ne démarre pas, le trafic n'y ira pas s'il y a un nouveau déploiement. Nous avons également commencé par dire que Kubernetes est le système d'exploitation; là où se trouve le système d'exploitation, il devrait y avoir un gestionnaire de paquets. Lorsque Kubernetes a démarré, les descriptions d'objets étaient impératives; L'ensemble avec état et la description du code sont des descriptions qui fonctionnent directement, et vous devez ajouter quelque chose par-dessus pour rendre l'état de votre [??? 18:52 - pépin d'enregistrement]. En fait, la différence radicale avec Ansible et d'autres systèmes de gestion de configuration similaires est que dans Kubernetes, vous décrivez ce qui devrait se passer, pas comment cela devrait se passer. Vous décrivez naturellementquels objets vous possédez et quelles propriétés ils possèdent. Les objets sont service, déploiement, daemonset, statefulset. Il est intéressant de noter qu'en plus des objets qui peuvent être créés de manière standard, il existe également des objets personnalisés qui peuvent être décrits et créés dans Kubernetes. C'est très utile; cela réduira également considérablement les rangs des administrateurs système et des ingénieurs devops.

Quand Kubernetes mourra-t-il?

Bonne question. Cela dépend de ce que signifie le mot «mourir». Voici Docker - il y a un an, nous nous sommes rencontrés lors d'une conférence à Saint-Pétersbourg, il y a eu une table ronde et nous avons décidé conjointement (enfin, puisque nous sommes une industrie, je pense qu'il y avait une majorité qualifiée là-bas, et nous pourrions bien nous permettre de parler pour tout le monde) que Docker déjà mort. Pourquoi? Parce qu'à la conférence, il n'y a pas eu de discussions sur Docker, même s'il ne date pas de si longtemps. Personne n'a rien dit de lui. Nous avons parlé de Kubernetes, des prochaines étapes - Kube Flow, par exemple, sur l'utilisation des opérateurs, sur la façon de placer les bases Kubernetes. Tout sauf Docker. C'est la mort - quand vous êtes si mauvais que vous semblez être vivant, mais que personne ne vient à vous.

Docker est déjà mort. Quand Kubernetes mourra - attendons 5 ans. Il ne mourra pas, tout le monde l'aura - ce sera à l'intérieur de Tesla, à l'intérieur de votre téléphone, partout, et personne ne sera intéressé à en parler. Je pense que c'est la mort. Peut-être même pas dans 5 ans, mais dans 3. Une autre question est de savoir ce qui la remplacera: une nouvelle technologie bruyante dont tout le monde parlera, peut-être pas du tout du monde DevOps. Maintenant, ils parlent de Kubernetes, même juste pour poursuivre la conversation, et ce n'est pas grave - c'est à la mode.

Quel est le problème avec Docker?

Tout. C'est un binaire unique pour tout gérer, c'est un service qui doit être lancé dans le système, c'est une pièce qui est également contrôlée via une socket. C'est un produit qui a beaucoup de code qui n'a été revu par personne, comme je pense. Il s'agit d'un produit pour lequel, dans l'ensemble, il n'y a pas d'argent d'entreprise. Red Hat a des gens très intelligents, j'ai beaucoup de respect pour eux, et si vous êtes un ingénieur moyen, vous devriez regarder ce qu'ils font car cela pourrait définir le paysage pour les 5 prochaines années. Eh bien, Red Hat a complètement abandonné Docker. Ils s'orientent vers ne pas l'avoir. Jusqu'à présent, ils ne peuvent pas le faire jusqu'à la fin, mais ils sont proches et tôt ou tard ils finiront Docker. Lui, en plus de tout ce que j'ai énuméré, a une énorme zone d'attaque. Il n'y a pas de sécurité là-bas. Peu de CVE ont été soulevées à ce sujet, mais si vous les regardez, il est clair que,comme dans tout autre projet où la sécurité n'est pas au premier plan, elle est traitée sur une base résiduelle. C'est la loi. La sécurité est longue, coûteuse, morne, limite le développeur, complique grandement la vie. Bien faire la sécurité est un travail difficile et vous devez payer pour cela. Si vous parlez à un professionnel de la sécurité, quelles que soient ses qualifications, vous entendrez de nombreuses histoires d'horreur sur Docker et des histoires sur la gravité des choses. Ils sont en partie liés à Docker lui-même, en partie aux personnes qui l'exploitent, mais Docker lui-même pourrait aider les gens et effectuer des contrôles de sécurité en lui-même; par exemple, ne démarrez pas un processus dans un conteneur à partir de la racine, sauf indication contraire explicite.limite le développeur, rend la vie très difficile. Bien faire la sécurité est un travail difficile et vous devez payer pour cela. Si vous parlez à un professionnel de la sécurité, quelles que soient ses qualifications, vous entendrez de nombreuses histoires d'horreur sur Docker et des histoires sur la gravité des choses. Ils sont en partie liés à Docker lui-même, en partie aux personnes qui l'exploitent, mais Docker lui-même pourrait aider les gens et effectuer des contrôles de sécurité en lui-même; par exemple, ne démarrez pas un processus dans un conteneur à partir de la racine, sauf indication explicite de le faire.limite le développeur, rend la vie très difficile. Bien faire la sécurité est un travail difficile et vous devez payer pour cela. Si vous parlez à un professionnel de la sécurité, quelles que soient ses qualifications, vous entendrez de nombreuses histoires d'horreur sur Docker et des histoires sur la gravité des choses. Ils sont en partie liés à Docker lui-même, en partie aux personnes qui l'exploitent, mais Docker lui-même pourrait aider les gens et effectuer des contrôles de sécurité en lui-même; par exemple, ne démarrez pas un processus dans un conteneur à partir de la racine, sauf indication explicite de le faire.partiellement - avec les personnes qui l'exploitent, mais Docker lui-même pourrait aider les gens et effectuer des contrôles de sécurité en lui-même; par exemple, ne démarrez pas un processus dans un conteneur à partir de la racine, sauf indication explicite de le faire.partiellement - avec les personnes qui l'exploitent, mais Docker lui-même pourrait aider les gens et effectuer des contrôles de sécurité en lui-même; par exemple, ne démarrez pas un processus dans un conteneur à partir de la racine, sauf indication explicite de le faire.

Comment stocker les états? Puis-je héberger la base de données sur Kubernetes?

Si vous demandez au DBA, ou à la personne qui était responsable de l'infrastructure de cette base de données avant que vous ne décidiez de la mettre sur Kubernetes, cette personne vous dira non. Je pense qu'à de nombreuses tables rondes, les gens diront qu'il ne devrait pas y avoir de bases de données dans Kubernetes: c'est difficile, peu fiable, on ne sait pas comment le gérer.

Je crois que les bases de données dans Kubernetes peuvent être représentées. Quelle est sa fiabilité? Eh bien, regardez: nous avons affaire à un système distribué. Lorsque vous placez une base de données dans un cluster, vous devez comprendre que vous avez une exigence de tolérance aux pannes. Si vous avez une telle exigence, il est fort probable que ce que vous mettez dans votre Kubernetes soit un cluster de base de données. Combien de personnes dans le monde moderne savent comment créer un cluster de base de données normal? De nombreuses bases de données offrent-elles des capacités de clustering? Ici commence la division des bases de données en traditionnelles - relationnelles et non relationnelles. Leur différence n'est pas que ces derniers ne prennent pas en charge SQL sous une forme ou une autre. La différence est que les bases de données non relationnelles sont bien mieux adaptées au travail en clusters, car elles ont été initialement écrites pour que la base de données soit distribuée. Donc,si pour certains MongoDB ou Cassandra vous voulez faire de l'hébergement dans Kubernetes, je ne peux pas vous en dissuader, mais vous devriez avoir une très bonne idée de ce qui va se passer ensuite. Vous devez très bien comprendre où se trouvent vos données, ce qui se passera en cas de panne et de récupération, comment les sauvegardes se déroulent, où se trouve le point de récupération et combien de temps il faudra pour récupérer. Ces questions ne concernent pas Kubernetes; ils ont à voir avec la façon dont vous gérez essentiellement une solution de cluster basée sur des bases de données conventionnelles. C'est plus facile avec les solutions NoSQL, elles sont immédiatement prêtes pour le cloud.où est le point de restauration et combien de temps cela prendra-t-il pour récupérer. Ces questions ne concernent pas Kubernetes; ils ont à voir avec la façon dont vous gérez essentiellement une solution de cluster basée sur des bases de données conventionnelles. C'est plus facile avec les solutions NoSQL, elles sont immédiatement prêtes pour le cloud.où est le point de restauration et combien de temps cela prendra-t-il pour récupérer. Ces questions ne concernent pas Kubernetes; ils ont à voir avec la façon dont vous gérez essentiellement une solution de cluster basée sur des bases de données conventionnelles. C'est plus facile avec les solutions NoSQL, elles sont immédiatement prêtes pour le cloud.

Mais quand même, la question se pose: pourquoi mettre la base de données dans Kubernetes? Vous pouvez prendre un service fourni par votre fournisseur, une solution gérée; vous pouvez prendre RDS d'Amazon, ainsi que la base de données gérée de Google. Et même un cluster géographiquement distribué de cette base de données, dans le cas d'Amazon, c'est Aurora, vous pouvez installer et utiliser. Mais, si vous allez installer un cluster géographiquement distribué de la base, lisez attentivement la documentation; J'ai rencontré des clusters Aurora avec un seul nœud - ils n'étaient même pas divisés en deux régions. De plus, la deuxième région n’était pas du tout nécessaire. En général, les gens ont des choses très étranges dans la tête: ils pensent que l'essentiel est de choisir un produit, puis il se fournira et fonctionnera comme il se doit. Non. Les bases de données relationnelles n'étaient pas du tout prêtes à fonctionner, même dans un cluster ordinaire,sans parler de géo-distribué. Par conséquent, si vous faites quelque chose de complexe basé sur eux, consultez la documentation.

Fondamentalement, j'ai de l'expérience dans l'exploitation d'une base de données dans Kubernetes. Il n'y avait rien de terrible. Il y a eu plusieurs plantages liés à la chute du nœud; le déplacement fonctionnait normalement vers un autre nœud. Tout est sous contrôle. La seule chose que je ne peux pas vous plaire et dire qu'il y avait un nombre énorme de milliers de demandes par seconde.

Si vous avez une solution moyenne ou petite - une solution moyenne pour la Russie correspond à peu près à une grande agence de presse comme Lenta - alors il ne devrait pas y avoir un grand nombre de requêtes complexes dans la base de données. Si la base ne fait pas face, alors, probablement, vous faites quelque chose de mal et vous devez y réfléchir. N'agrandissez pas sans réfléchir. Déplacer une solution non clusterisée vers un cluster a ses avantages, mais aussi un grand nombre d'inconvénients, surtout si vous prenez un cluster postgres basé sur Patroni ou Stallone. Il existe de nombreuses conditions aux limites; Je ne les ai pas rencontrés, mais des collègues de Data Egret se feront un plaisir de vous expliquer comment cela se passe. Il y a un merveilleux rapport d'Alexei Lesovsky sur ce qui se passera si vous essayez de transférer votre base dans un cluster sans réfléchir.

Environ des milliers de requêtes par seconde. Si vous disposez d'une seule instance de base de données, son réglage à des milliers de requêtes par seconde est toujours en cours de mise à l'échelle. Tôt ou tard, vous rencontrerez des ennuis. Il me semble qu'il vaut mieux, si une charge lourde est prévue, d'envisager des options de mise à l'échelle horizontale. Trouvez la plus grande table de votre base de données, voyez ce qu'elle contient et réfléchissez à la possibilité de la déplacer vers un stockage non relationnel. Réfléchissez à la façon de ne pas stocker dans une base de données relationnelle ce que vous y stockez habituellement - par exemple, les journaux d'accès au système, dont beaucoup tombent, et vous y accédez généralement selon le même modèle par lequel vous accédez au stockage clé-valeur. ... Alors pourquoi ne pas écrire des journaux dans Cassandra? C'est une question pour un architecte. Garder une petite instance de base pas très occupée dans Kubernetes est la chose mêmecar la magie de l'opérateur commence à en être responsable.

En gros, si vous regardez ce qu'est Kubernetes en tant que système d'exploitation et plate-forme, alors il s'agit d'un constructeur à faire soi-même. Il y a tout pour vous pour créer une architecture de microservice, y compris la possibilité de stocker des états sur des disques, d'organiser la télémétrie, la surveillance et les alertes. Ceci est fait par Helm, le gestionnaire de packages Kubernetes. Il existe un grand nombre de Helm Charts open source et accessibles au public sur Internet. Le moyen le plus simple d'élever l'infrastructure d'un projet est de prendre le Helm Chart qui met votre application, votre service, si ce service est une base de données Redis, PostgreSQL, Patroni - peu importe; commencez à le configurer et appliquez cette configuration. C'est complètement déclaratif; tout ce qui peut être prévu, les auteurs des Helm Charts fournissent généralement. Votre application est également mieux publiée avec Helm.Le troisième Helm ne contient pas de services côté cluster; le second contenait, il avait un service fonctionnant constamment de l'administrateur du cluster, qui était nécessaire pour distribuer les versions par espace de noms, mais le troisième Helm a fermé cette faille de sécurité.

Helm est un tel moteur de modèle basé sur la syntaxe de modèle GoLang. Il faut une liste de variables, qui sont une structure non planaire (Dieu merci, c'est hiérarchique - écrit en YAML); En utilisant Helm, ces variables sont placées aux bons endroits dans les modèles Helm, puis vous appliquez tout cela dans un espace de noms, vos codes, vos services y sont lancés, vos rôles sont créés. Il existe un générateur d'échafaudage qui permet d'écrire Helm Chart sans reprendre conscience. La seule chose que je n'aime pas, c'est le besoin de connaître la syntaxe des modèles de GoLang et des branches conditionnelles dans Helm lui-même; ils sont réalisés selon le principe lisp, avec une notation de préfixe. C'est bien que quelqu'un d'autre l'aime, mais cela fait changer la tête à chaque fois. Eh bien, on s'en remettra.

Maintenant, un peu de ce qui va se passer ensuite. Je ressemblais déjà à des opérateurs; ce sont les services qui vivent à l'intérieur du cluster Kubernetes et gèrent le cycle de vie d'une autre application plus grande. Assez dur. Vous pouvez considérer un opérateur comme votre ingénieur de fiabilité de site domestique en silicium; il est certain qu'à l'avenir, les gens écriront de plus en plus d'opérateurs, car personne ne veut garder un changement de personnes de premier niveau de support qui suivraient le calendrier de Nagios, remarqueraient les pannes et prendraient des mesures manuellement. L'opérateur comprend quels états système sont possibles; c'est une machine à états. Maintenant, la concentration de connaissances humaines, écrites en langage GoLang ou autre, est compilée, mise en cluster et fait beaucoup de travail pour vous: ajoute ou supprime des nœuds, reconfigure, s'assure que celui qui est tombé remonte,de sorte que les données accostent aux codes désirés d'où elles se trouvent. En général, il gère le cycle de vie de ce qui est installé en dessous. Les opérateurs sont désormais littéralement pour tout. Je me suis amusé avec le fait qu'en utilisant l'opérateur Rook, j'ai mis sev directement dans le cluster Kubernetes. J'ai regardé comment cela se passe, et j'en suis très heureux, et je pense que davantage d'opérateurs sont nécessaires, et nous devrions tous participer à leur test. Le temps que vous passez à corriger l'opérateur de quelqu'un d'autre est un cadeau pour l'humanité. Vous n'avez plus besoin de faire le même travail encore et encore. Vous pouvez mettre ce travail sous une forme aliénée dans le référentiel, puis un programme intelligent le fera pour vous - n'est-ce pas le bonheur?Les opérateurs sont désormais littéralement pour tout. Je me suis amusé à utiliser l'opérateur Rook pour mettre sev directement dans le cluster Kubernetes. J'ai regardé comment cela se passe, et j'en suis très heureux, et je pense que davantage d'opérateurs sont nécessaires, et nous devrions tous participer à leur test. Le temps que vous passez à corriger l'opérateur de quelqu'un d'autre est un cadeau pour l'humanité. Vous n'avez plus besoin de faire le même travail encore et encore. Vous pouvez mettre ce travail sous une forme aliénée dans le référentiel, puis un programme intelligent le fera pour vous - n'est-ce pas le bonheur?Les opérateurs sont désormais littéralement pour tout. Je me suis amusé avec le fait qu'en utilisant l'opérateur Rook, j'ai mis sev directement dans le cluster Kubernetes. J'ai regardé comment cela se passe, et j'en suis très heureux, et je pense qu'il faut plus d'opérateurs, et nous devrions tous participer à leur test. Le temps que vous passez à corriger l'opérateur de quelqu'un d'autre est un cadeau pour l'humanité. Vous n'avez plus besoin de faire le même travail encore et encore. Vous pouvez mettre ce travail sous une forme aliénée dans le référentiel, puis un programme intelligent le fera pour vous - n'est-ce pas le bonheur?que vous dépensez pour corriger l'opérateur de quelqu'un d'autre est un cadeau pour l'humanité. Vous n'avez plus besoin de faire le même travail encore et encore. Vous pouvez mettre ce travail sous une forme aliénée dans le référentiel, puis un programme intelligent le fera pour vous - n'est-ce pas le bonheur?que vous dépensez pour corriger l'opérateur de quelqu'un d'autre est un cadeau pour l'humanité. Vous n'avez plus besoin de faire le même travail encore et encore. Vous pouvez mettre ce travail sous une forme aliénée dans le référentiel, puis un programme intelligent le fera pour vous - n'est-ce pas le bonheur?

J'ai téléchargé le livre Red Hat - ils le distribuent gratuitement - sur le fonctionnement des opérateurs Kubernetes et comment écrire le vôtre, je vous recommande d'aller sur leur site Web et de le télécharger aussi, le livre est très intéressant. Quand je l'ai lu dans son intégralité, nous pourrons peut-être analyser un opérateur ensemble.

Qui soutient Swarm? Outre Docker Inc?

Personne. Et Docker Inc. déjà déchiré en deux moitiés, et une moitié vendue quelque part. Je ne suis pas ce qui se passe avec eux; à un moment donné, ils ont appelé le produit Mobi, mais c'était une version open source, c'est-à-dire que ce n'était pas une version ouverte. Et quelque chose a été vendu avec des droits, mais quelque chose n'a pas été vendu. Pour moi, cela ressemble à "un patient a transpiré avant sa mort" - les gens essaient en quelque sorte d'extraire l'argent investi. En général, personne ne le soutient.

Maître d'esclave

Ça marche. Si le maître / esclave cesse de fonctionner dans une base de données relationnelle, alors le monde s'arrêtera là. Kubernetes n'interfère en aucun cas avec le fonctionnement de la base de données; la seule chose qu'il apporte est différents contrôles de santé, qui peuvent être désactivés si vous le souhaitez, et, en principe, la gestion de l'état. Il est conseillé de ne pas le désactiver - votre opérateur, qui gère la base de données, devrait voir son état.

Quel est le nom du livre Red Hat?

Les opérateurs Kubernetes s'appellent ainsi. Le canard y est dessiné. Le livre d'O'Reilly, maintenant redessiné les couvertures; de nombreux livres ont été publiés en collaboration avec Red Hat. Red Hat propose 3 ou 4 livres Kubernetes supplémentaires que vous pouvez télécharger gratuitement: par exemple, Kubernetes Patterns, gRPC. Le protocole gRPC, bien qu'il ne soit pas directement lié à Kubernetes, est utilisé par beaucoup pour échanger des données entre microservices. De plus, il est utilisé dans les équilibreurs de charge de nouvelle génération, par exemple dans Envoy.

Qu'est-ce qu'un SRA?

C'est le genre de personne qui comprend le calendrier des changements qui se produisent dans un système distribué. En gros, il comprend à quel point vous vous êtes déjà allongé ce mois-ci, combien vous pouvez en plus, si vous pouvez donner la permission pour la libération. Gère les clés à partir des sauvegardes, des plans de récupération, des problèmes de reprise après sinistre, des problèmes de maintenance d'infrastructure pour une application industrielle qui devrait fonctionner 24/7. Il a des métriques pour l'état et l'état commercial de l'application dans les métriques de l'application - combien de latence, où et combien de demandes; ces mêmes 4 signaux d'or. En outre, le SRA, sur la base de ces paramètres, peut prendre des mesures pour ramener le système en état de préparation au combat, il a un plan sur la façon de le faire. Pour une raison quelconque, cela n'est pas obligatoire dans le DevOps classique, cela aide simplement le développeur à lancer l'application, généralement à la déployer quelque part.Et SRA résiste également au flux de demandes provenant de différents côtés.

J'ai promis de parler de sécurité. Vous savez, c'est un sujet assez récent dans Kubernetes. Je ne connais que les bases: par exemple, vous ne devez pas exécuter une application dans un service à partir de la racine, car dès que cela se produit, il a accès à tout ce qui se trouve dans l'espace de noms, les droits de superutilisateur, et vous pouvez essayer de casser le noyau du système hôte, ce qui, probablement cela fonctionnera (et effectuera toutes les autres opérations à partir de la racine). Ne donnez pas aux pirates un indice comme ça; si possible, accordez aux utilisateurs le moins de droits possible et gérez bien les entrées utilisateur. Il me semble que si nous parlons de la sécurité de Kubernetes, elle devrait être retirée quelque part dans les circuits fermés que nous avons actuellement. Ou, si vous voulez vraiment entrer dans des problèmes de sécurité, vous devriez consulter le projet Cilium. Il sait utiliser les parasurtenseurs,Différenciation du trafic réseau basée sur BPF - cela fonctionne mieux que iptables. Tel est le futur. Il me semble qu'en dehors de la Californie, personne ne l'utilise vraiment, mais vous pouvez déjà commencer. Il y aura peut-être un autre projet, mais j'en doute. En général, l'humanité a peu de mains actives.

Par conséquent, je n'ai rien de spécial à dire sur la sécurité. Il existe différentes options pour la location montée dans Kubernetes, mais là, vous devez vous asseoir avec un crayon et déterminer ce que les gens ont fait, quelle vulnérabilité ils ont fermé, si cela a du sens, si cela s'applique à votre modèle de menace. En passant, je recommande de commencer par chercher une description de la façon dont le modèle de menace est construit et de le construire pour vous-même. Il existe des méthodes plus ou moins formelles. Dessinez, regardez-le, et peut-être qu'un aperçu se produira, et vous comprendrez ce dont vous avez besoin et ce qui n'est pas nécessaire dans la situation actuelle. Il suffira peut-être de conduire tous les Kubernetes dans une boucle fermée. En passant, c'est la bonne décision; Je suis tombé sur ça, et c'est impénétrable. Si vous pouvez accéder au système uniquement en présentant un laissez-passer à la montre, et qu'il n'y a pas d'Internet à l'intérieur et que l'échange passe par une passerelle spéciale,situé dans la DMZ et est difficile à briser car il est écrit de manière inhabituelle - alors c'est un système bien protégé. Comment faire cela par des moyens techniques - eh bien, vous devez surveiller le marché actuel des solutions. Cela change beaucoup, la sécurité est un sujet brûlant. Il y a beaucoup de joueurs qui essaient de l'être, mais lesquels d'entre eux ment et qui ne le sont pas - je ne prétends pas le dire. Si Red Hat ne ment probablement pas, il n'est pas en avance sur tout le monde. Vous avez juste besoin de faire des recherches (et moi aussi), car ce n'est pas encore clair.Vous avez juste besoin de faire des recherches (et moi aussi), car ce n'est pas encore clair.Vous avez juste besoin de faire des recherches (et moi aussi), car ce n'est pas encore clair.

Parlons de ce que le cluster Kubernetes devrait avoir d'autre. Puisque nous avons la possibilité d'y installer des applications gratuitement, et que nous n'avons pas peur d'y stocker la base de données. À propos, si vous avez Managed Kubernetes, alors il n'y a pas de questions sur l'emplacement de stockage de la base de données: vous disposez d'un stockage tolérant aux pannes, sous une forme ou une autre (souvent sous la forme de périphériques blocs) fourni à partir du cloud dans lequel se trouve Managed Kubernetes. Vous pouvez placer en toute sécurité des disques de ce stockage dans votre cluster et utiliser des instantanés pour effectuer des sauvegardes cohérentes. N'oubliez pas que l'instantané n'est pas une sauvegarde, vous devez également copier l'instantané quelque part. C'est évident, mais il est bon de répéter les choses évidentes pour ne pas les oublier.

Lorsque vous disposez d'une plate-forme d'architecture de microservices, il est très important de la rendre traçable, observable, afin que vous puissiez comprendre où se trouvent les demandes et où elles perdent du temps, etc. Construire une telle plate-forme demande beaucoup de travail. Vous aurez besoin de Prométhée. Il sera nécessaire car il s'agit d'un projet Cloud Native Computing Foundation; il est spécialement conçu pour surveiller Kubernetes. Contient un grand nombre d'exportateurs, de collecteurs de métriques; certaines applications contiennent nativement tous ses tableaux de bord. Si votre application ne les contient pas, il faut 20 minutes pour se connecter à l'application de tableau de bord Prometheus à longue durée de vie. Bien que pour une raison quelconque, personne ne l'attache. D'après mon expérience, cela se produit parce que les gens gardent leurs produits dans les nuages. Il y a Amazon CloudWatch, Google StackDriver,et vous pouvez y envoyer des métriques de la même manière - même si cela coûtera de l'argent. Autrement dit, si les gens paient encore pour l'infrastructure, ils paient pour les outils de surveillance qui y sont attachés. Néanmoins, Prometheus peut être très pratique si vous avez plusieurs endroits différents d'où vous prenez des métriques, si le cloud n'est pas au même endroit, s'il est hybride, si vous avez des machines sur site et avez besoin d'une infrastructure centralisée. Alors Prometheus est votre choix.si vous avez des machines sur site et avez besoin d'une infrastructure centralisée. Alors Prometheus est votre choix.si vous avez des machines sur site et avez besoin d'une infrastructure centralisée. Alors Prometheus est votre choix.

De quoi d'autres avez-vous besoin? Il est clair que là où Prometheus est, il y a aussi un besoin pour Alert Manager. Et vous avez également besoin d'une sorte de traçage distribué de vos demandes. Comment faire cela dans Kubernetes - eh bien, prenez un produit comme jaeger, ou zipkin, ou tout ce qui se trouve en haut en ce moment; aussi Cassandra pour stocker vos traces, aussi Grafana pour les rendre. Pour autant que je sache, cette fonctionnalité est apparue récemment dans Grafana, mais ce n'est pas une raison pour ne pas la mettre en œuvre. Autrement dit, vous pouvez assembler manuellement un environnement dans lequel les applications [pépins 49:14] (auront?) Par ce runtime, les compteurs et autres métriques appropriés pour la construction, la visualisation de vos traces distribuées: où l'application passe combien de temps?

Il est moins commode d'en parler que de le montrer, mais il n'y a rien à me montrer maintenant; Je n'ai rien de tout cela dans mon laboratoire maintenant. Un jour, je me préparerai probablement.

Je pense avoir dit tout ce que je voulais dire. Je répéterai encore une fois les principales dispositions.

Premièrement: Kubernetes vous évite d'avoir à écrire un mécanisme de remplacement sécurisé d'un conteneur par un autre sur Ansible Engine X.

Deuxièmement: Kubernetes ne disparaîtra nulle part. Il peut "mourir", mais il n'est plus possible d'arrêter de l'utiliser, il a conquis la majeure partie du marché. A la question "quand Kubernetes mourra-t-il:" Je veux demander "quand WordPress mourra-t-il?" Et il doit encore vivre et vivre. Définissons l'ordre: d'abord WP, puis Kubernetes.

Donc Kubernetes est avec nous. Ce n'est plutôt pas lui-même qui est intéressant, mais les services qui sont enroulés en haut sont intéressants - ce sont les opérateurs et la définition de ressource personnalisée. La possibilité de prendre et d'écrire votre propre ressource, qui sera appelée "cluster PostgreSQL", de la décrire avec un footcloth YAML et de la jeter dans le cluster.

Que se passera-t-il d'autre? Il sera également possible de gérer tout cela, des langages de programmation statiquement typés tels que GoLang et TypeScript. Et je crois vraiment en Kotlin - beaucoup de DSL sympas sont déjà écrits dessus. Et plus sera écrit.

Il y aura également Helm Chart payant, des applications payantes qui peuvent être lancées sur site, certaines sous licence, par abonnement. Il y aura intégration de divers services - en fait, il existe déjà, par exemple, DataDog s'intègre déjà à Kubernetes. Et les nouveaux venus qui apparaîtront sur le marché des alertes de surveillance s'intégreront également à Kubernetes, pour des raisons évidentes. Aucun produit cloud ne passera par Kubernetes, d'une manière ou d'une autre. C'est la plateforme que tout le monde visera.

Mais tout cela ne signifie pas que Kubernetes est bon, et rien ne pourrait être mieux. Je le compare à ce qu'il était avant - avec les solutions Amazon: ECS, Elastic Beanstalk. Ceux qui les ont rencontrés savent que dans mon ancienne analogie, une chose, une autre ne serait pas seulement le 737 MAX, mais le 737 MAX, fait de ruban électrique et de pâte à modeler. Par conséquent, les principaux acteurs - Amazon, Microsoft Azure, Google - sont déjà tous dans Kubernetes. Probablement Yandex et Mail.ru le sont aussi, mais je ne les suis pas. C'est un avenir si commun. Un avenir commun si mauvais, mais «assez bon», sur lequel tout le monde s'accorde jusqu'à présent. Qu'est-ce que tout cela mute encore, vous devez demander à Red Hat - ils sont plus intelligents que moi.

Que pense Java de Kubernetes?

Bien.

Quel système d'exploitation utilisez-vous sur votre PC?

Les deux sont sur macOS.

Les spécialistes DevOps sont-ils actuellement activement recrutés?

Oui, ils ont toujours été activement pris dans un endroit éloigné, et maintenant ils le sont activement de la même manière. La situation ne changera pas fondamentalement, je pense. En général, je ne considère pas le travail non supprimé: toutes les bonnes entreprises n'ont pas de bureau à Saint-Pétersbourg. Bien sûr, il y aura une distance, et les événements actuels ont montré aux gens que c'était possible. Le nombre de personnes qui sont plus à l'aise avec cela ne fera qu'augmenter. On nous dit que «beaucoup de gens l'ont essayé et sont retournés au bureau» - eh bien, retourner au bureau coûte de l'argent. Pas d'argent - pas de choix, et de nombreuses entreprises économisent maintenant.

"Docker est déjà mort" ou tout ce que vous vouliez savoir sur Devops mais que vous aviez peur de demander