En prévision Vitaly Khabarov interviewé Dmitri Stoliarov (), directeur technique et co-fondateur de la société Flant. Vitaly a demandé à Dmitry ce que fait Flant, Kubernetes, le développement de l'écosystème et le support. Nous avons discuté de la nécessité de Kubernetes et de sa pertinence. Et aussi sur les microservices, Amazon AWS, l'approche « J'aurai de la chance » en matière de DevOps, l'avenir de Kubernetes lui-même, pourquoi, quand et comment il conquiert le monde, les perspectives du DevOps et ce à quoi les ingénieurs doivent se préparer dans le futur. un avenir brillant et proche avec la simplification et les réseaux de neurones.
écoutez en podcast sur DevOps Deflop - un podcast en russe sur DevOps, et ci-dessous se trouve la version texte.
Ici et ci-dessous, il pose des questions ingénieur d'Express42.
À propos de "Flant"
- Bonjour Dima. Vous êtes le directeur technique "" et aussi son fondateur. S'il vous plaît, dites-nous ce que fait l'entreprise et ce que vous y faites ?
Dmitry: De l'extérieur, il semble que nous soyons ceux qui installent Kubernetes pour tout le monde et en font quelque chose. Mais ce n'est pas vrai. Nous avons commencé comme une entreprise qui s'occupait de Linux, mais depuis très longtemps, notre activité principale a été le service de projets clé en main de production et à forte charge. Habituellement, nous construisons toute l’infrastructure à partir de zéro et en sommes ensuite responsables pendant très, très longtemps. Par conséquent, le travail principal réalisé par « Flant », pour lequel il reçoit de l'argent, est prendre ses responsabilités et mettre en œuvre une production clé en main.
En tant que directeur technique et l'un des fondateurs de l'entreprise, je passe toute la journée et toute la nuit à essayer de comprendre comment augmenter l'accessibilité de la production, simplifier son fonctionnement, rendre la vie des administrateurs plus facile et celle des développeurs plus agréable. .
À propos de Kubernetes
— Dernièrement, j'ai vu beaucoup de rapports de Flant et à propos de Kubernetes. Comment en êtes-vous arrivé là ?
Dmitry: J’en ai déjà parlé à plusieurs reprises, mais cela ne me dérange pas du tout de le répéter. Je pense qu'il est juste de répéter ce sujet car il existe une confusion entre cause et effet.
Il nous fallait vraiment un outil. Nous avons rencontré beaucoup de problèmes, nous nous sommes battus, nous les avons surmontés avec diverses béquilles et avons ressenti le besoin d'un outil. Nous avons examiné de nombreuses options différentes, construit nos propres vélos et acquis de l'expérience. Peu à peu, nous sommes arrivés au point où nous avons commencé à utiliser Docker presque dès son apparition, vers 2013. Au moment de son apparition, nous avions déjà beaucoup d'expérience avec les conteneurs, nous avions déjà écrit un analogue de "Docker" - certaines de nos propres béquilles en Python. Avec l’avènement de Docker, il est devenu possible de jeter les béquilles et d’utiliser une solution fiable et soutenue par la communauté.
Avec Kubernetes, l’histoire est similaire. Au moment où cela a commencé à prendre de l'ampleur - pour nous, il s'agit de la version 1.2 - nous avions déjà un tas de béquilles sur Shell et Chef, que nous avons en quelque sorte essayé d'orchestrer avec Docker. Nous nous tournions sérieusement vers Rancher et diverses autres solutions, mais ensuite Kubernetes est apparu, dans lequel tout est implémenté exactement comme nous l'aurions fait, voire mieux. Il n'y a rien à redire.
Oui, il y a une sorte d'imperfection ici, il y a une sorte d'imperfection là-bas - il y a beaucoup d'imperfections, et 1.2 est généralement terrible, mais... Kubernetes est comme un bâtiment en construction - vous regardez le projet et comprenez que ce sera cool. Si le bâtiment a maintenant une fondation et deux étages, alors vous comprenez qu'il vaut mieux ne pas emménager pour l'instant, mais il n'y a pas de tels problèmes avec le logiciel - vous pouvez déjà l'utiliser.
Nous n’avons pas eu un moment où nous avons pensé à utiliser Kubernetes ou non. Nous l'attendions bien avant son apparition et avons essayé de créer nous-mêmes des analogues.
À propos de Kubernetes
— Êtes-vous directement impliqué dans le développement de Kubernetes lui-même ?
Dmitry: Médiocre. Nous participons plutôt au développement de l’écosystème. Nous envoyons un certain nombre de pull request : à Prometheus, à différents opérateurs, à Helm - à l'écosystème. Malheureusement, je ne suis pas en mesure de suivre tout ce que nous faisons et je peux me tromper, mais il n'y a pas un seul pool entre nous et le noyau.
— En parallèle, développez-vous beaucoup de vos outils autour de Kubernetes ?
Dmitry: La stratégie est la suivante : on va tirer des requêtes sur tout ce qui existe déjà. Si les demandes d'extraction n'y sont pas acceptées, nous les forçons simplement nous-mêmes et vivons jusqu'à ce qu'elles soient acceptées avec nos builds. Puis, lorsqu'il atteint l'amont, on revient à la version amont.
Par exemple, nous avons un opérateur Prometheus, avec lequel nous avons probablement déjà basculé 5 fois en amont de notre assemblage. Nous avons besoin d'une sorte de fonctionnalité, nous avons envoyé une pull request, nous devons la déployer demain, mais nous ne voulons pas attendre qu'elle soit publiée en amont. En conséquence, nous assemblons nous-mêmes, déployons notre assemblage avec notre fonctionnalité, dont nous avons besoin pour une raison quelconque, sur tous nos clusters. Ensuite, par exemple, ils nous le remettent en amont avec les mots : « Les gars, faisons-le pour un cas plus général », nous, ou quelqu'un d'autre, le terminons, et au fil du temps, il fusionne à nouveau.
Nous essayons de développer tout ce qui existe. De nombreux éléments qui n'existent pas encore, n'ont pas encore été inventés, ou ont été inventés, mais n'ont pas eu le temps d'être mis en œuvre - nous le faisons. Et non pas parce que nous aimons le processus de construction de vélos en tant qu'industrie, mais simplement parce que nous avons besoin de cet outil. La question est souvent posée : pourquoi avons-nous fait telle ou telle chose ? La réponse est simple : oui, car nous devions aller plus loin, résoudre un problème pratique, et nous l'avons résolu avec ce tula.
Le chemin est toujours ainsi : nous cherchons très attentivement et, si nous ne trouvons aucune solution pour fabriquer un trolleybus avec une miche de pain, alors nous fabriquons notre propre miche et notre propre trolleybus.
Outils Flanta
— Je sais que Flant dispose désormais d'opérateurs complémentaires, d'opérateurs shell et d'outils dapp/werf. Si je comprends bien, il s'agit du même instrument dans différentes incarnations. Je comprends également qu'il existe de nombreux autres outils différents dans Flaunt. C'est vrai?
Dmitry: Nous en avons beaucoup plus sur GitHub. D'après ce dont je me souviens maintenant, nous avons une carte de statut - un panneau pour Grafana que tout le monde a rencontré. Il est mentionné dans presque un article sur deux sur la surveillance de Kubernetes sur Medium. Il est impossible d'expliquer brièvement ce qu'est une carte d'état - elle nécessite un article séparé, mais c'est une chose très utile pour surveiller l'état au fil du temps, car dans Kubernetes, nous devons souvent afficher l'état au fil du temps. Nous avons également LogHouse - c'est une chose basée sur ClickHouse et la magie noire pour collecter des journaux dans Kubernetes.
Beaucoup d'utilitaires ! Et il y en aura encore plus, car de nombreuses solutions internes seront publiées cette année. Parmi les très gros basés sur l'opérateur addon, il existe un tas d'addons pour Kubernetes, comme comment installer correctement sert manager - un outil de gestion des certificats, comment installer correctement Prometheus avec un tas d'accessoires - il y en a une vingtaine différents des binaires qui exportent des données et collectent quelque chose, Prometheus possède les graphiques et les alertes les plus étonnants. Tout cela n'est qu'un tas d'addons à Kubernetes, qui sont installés dans un cluster, et cela passe du simple au cool, sophistiqué, automatique, dans lequel de nombreux problèmes ont déjà été résolus. Oui, nous faisons beaucoup.
Développement de l'écosystème
"Il me semble que c'est une très grande contribution au développement de cet instrument et de ses méthodes d'utilisation." Pouvez-vous estimer approximativement qui d’autre apporterait la même contribution au développement de l’écosystème ?
Dmitry: En Russie, parmi les entreprises qui opèrent sur notre marché, aucune n'est proche. Bien sûr, c'est une déclaration forte, car il existe des acteurs majeurs comme Mail et Yandex - ils font aussi quelque chose avec Kubernetes, mais même eux ne se rapprochent pas de la contribution des entreprises du monde entier qui font bien plus que nous. Il est difficile de comparer Flant, qui compte 80 personnes, et Red Hat, qui compte 300 ingénieurs par Kubernetes seul, si je ne me trompe pas. C'est difficile de comparer. Nous avons 6 personnes au département RnD, dont moi, qui coupent tous nos outils. 6 personnes contre 300 ingénieurs Red Hat - c'est en quelque sorte difficile à comparer.
- Cependant, lorsque même ces 6 personnes peuvent faire quelque chose de vraiment utile et aliénant, lorsqu'elles sont confrontées à un problème pratique et donnent la solution à la communauté, c'est un cas intéressant. Je comprends que dans les grandes entreprises technologiques, où elles disposent de leur propre équipe de développement et de support Kubernetes, les mêmes outils peuvent en principe être développés. C'est pour eux un exemple de ce qui peut être développé et donné à la communauté, donnant une impulsion à toute la communauté qui utilise Kubernetes.
Dmitry: C'est probablement une caractéristique de l'intégrateur, sa particularité. Nous avons de nombreux projets et nous voyons de nombreuses situations différentes. Pour nous, le principal moyen de créer de la valeur ajoutée est d'analyser ces cas, de trouver des points communs et de les rendre aussi bon marché que possible pour nous. Nous y travaillons activement. Il m'est difficile de parler de la Russie et du monde, mais nous avons environ 40 ingénieurs DevOps dans l'entreprise qui travaillent sur Kubernetes. Je ne pense pas qu’il existe en Russie beaucoup d’entreprises avec un nombre comparable de spécialistes qui comprennent Kubernetes, voire pas du tout.
Je comprends tout du titre de poste d'ingénieur DevOps, tout le monde comprend tout et a l'habitude d'appeler les ingénieurs DevOps des ingénieurs DevOps, on n'en parlera pas. Tous ces 40 incroyables ingénieurs DevOps sont confrontés et résolvent des problèmes chaque jour, nous analysons simplement cette expérience et essayons de généraliser. Nous comprenons que s'il reste en nous, alors dans un an ou deux, l'outil sera inutile, car quelque part dans la communauté, un Tula tout fait apparaîtra. Cela ne sert à rien d'accumuler cette expérience en interne - cela revient simplement à drainer de l'énergie et du temps dans dev/null. Et nous ne le regrettons pas du tout. Nous publions tout avec grand plaisir et comprenons qu'il doit être publié, développé, promu, promu, afin que les gens l'utilisent et ajoutent leur expérience - alors tout grandit et vit. Puis au bout de deux ans l’instrument ne va plus à la poubelle. Ce n’est pas dommage de continuer à déployer des forces, car il est clair que quelqu’un utilise votre outil, et après deux ans, tout le monde l’utilise.
Cela fait partie de notre grande stratégie avec dapp/werf. Je ne me souviens pas quand nous avons commencé à le faire, il me semble qu’il y a 3 ans. Au départ, c'était généralement sur la coque. C'était une super preuve de concept, nous avons résolu certains de nos problèmes particuliers - ça a fonctionné ! Mais il y a des problèmes avec le shell, il est impossible de l'étendre davantage, la programmation sur le shell est une autre tâche. Nous avions l'habitude d'écrire en Ruby, en conséquence, nous avons refait quelque chose en Ruby, développé, développé, développé, et nous sommes tombés sur le fait que la communauté, la foule qui ne dit pas « on le veut ou on ne le veut pas », » tourne le nez vers Ruby, c'est pas drôle ? Nous avons réalisé que nous devrions écrire tout cela dans Go juste pour répondre au premier point de la liste de contrôle : L'outil DevOps doit être un binaire statique. Être Go ou pas n'est pas si important, mais un binaire statique écrit en Go est préférable.
Nous avons dépensé notre énergie, réécrit le dapp en Go et l'avons appelé werf. Le Dapp n'est plus pris en charge, n'est pas développé, fonctionne dans une version la plus récente, mais il existe un chemin de mise à niveau absolu vers le sommet, et vous pouvez le suivre.
Pourquoi la dapp a-t-elle été créée ?
— Pouvez-vous nous expliquer brièvement pourquoi le dapp a été créé, quels problèmes il résout ?
Dmitry: La première raison est dans l'assemblée. Au départ, nous avons eu de sérieux problèmes avec la construction lorsque Docker n'avait pas de capacités multi-étapes, nous avons donc créé nous-mêmes le multi-étapes. Ensuite, nous avons eu encore beaucoup de problèmes avec le nettoyage de l’image. Tous ceux qui font du CI/CD, le plus tôt possible, sont confrontés au problème qu'il y a un tas d'images collectées, vous devez d'une manière ou d'une autre nettoyer ce qui n'est pas nécessaire et laisser ce qui est nécessaire.
La deuxième raison est le déploiement. Oui, il existe Helm, mais cela ne résout qu'une partie des problèmes. Curieusement, il est écrit que « Helm est le gestionnaire de packages pour Kubernetes ». Exactement ce que « le ». Il y a aussi les mots « Package Manager » - qu'est-ce qu'on attend habituellement d'un Package Manager ? Nous disons : « Package Manager - installez le package ! » et on s'attend à ce qu'il nous dise : « Le colis a été livré ».
C'est intéressant que nous disons : « Helm, installez le paquet », et quand il répond qu'il l'a installé, il s'avère qu'il vient de démarrer l'installation - il a indiqué Kubernetes : « Lancez ce truc ! », et s'il a démarré ou non , que cela fonctionne ou non, Helm ne résout pas du tout ce problème.
Il s'avère que Helm n'est qu'un préprocesseur de texte qui charge les données dans Kubernetes.
Mais dans le cadre de tout déploiement, nous souhaitons savoir si l’application a été mise en production ou non ? Déployé en production signifie que l'application a été déplacée là-bas, que la nouvelle version a été déployée et qu'au moins elle ne plante pas là-bas et répond correctement. Helm ne résout en aucun cas ce problème. Pour le résoudre, vous devez déployer beaucoup d'efforts, car vous devez donner à Kubernetes la commande de se déployer et de surveiller ce qui s'y passe - qu'il soit déployé ou déployé. Et il y a aussi de nombreuses tâches liées au déploiement, au nettoyage et à l’assemblage.
Plans
Cette année, nous commencerons le développement local. Nous voulons réaliser ce qui était auparavant dans Vagrant - nous avons tapé « vagrant up » et nous avons déployé des machines virtuelles. Nous voulons arriver au point où il y a un projet dans Git, nous y écrivons « werf up », et cela fait apparaître une copie locale de ce projet, déployée dans un mini-Kub local, avec tous les répertoires pratiques pour le développement connectés . Selon le langage de développement, cela se fait différemment, mais néanmoins, afin que le développement local puisse être effectué facilement sous des fichiers montés.
La prochaine étape pour nous est investir dans la commodité pour les développeurs. Pour déployer rapidement un projet localement avec un seul outil, développez-le, poussez-le dans Git, et il sera également déployé en phase de tests, en fonction des pipelines, puis utilisera le même outil pour passer en production. Cette unité, unification, reproductibilité des infrastructures depuis l'environnement local jusqu'à la vente est un point très important pour nous. Mais ce n’est pas encore à l’ordre du jour – nous prévoyons simplement de le faire.
Mais le chemin vers dapp/werf a toujours été le même qu’avec Kubernetes au début. Nous avons rencontré des problèmes, les avons résolus avec des solutions de contournement - nous avons trouvé des solutions pour nous-mêmes sur le shell, sur n'importe quoi. Ensuite, ils ont essayé d'une manière ou d'une autre de corriger ces solutions de contournement, de les généraliser et de les consolider en binaires dans ce cas, que nous partageons simplement.
Il existe une autre façon de voir toute cette histoire, avec des analogies.
Kubernetes est un châssis de voiture doté d'un moteur. Il n'y a ni portes, ni vitres, ni radio, ni sapin de Noël, rien du tout. Juste le cadre et le moteur. Et il y a Helm - c'est le volant. Cool - il y a un volant, mais vous avez également besoin d'un axe de direction, d'une crémaillère de direction, d'une boîte de vitesses et de roues, et vous ne pouvez pas vous en passer.
Dans le cas de Werf, il s'agit d'un autre composant de Kubernetes. Seulement maintenant, dans la version alpha de werf, par exemple, Helm est compilé dans werf, car nous en avons assez de le faire nous-mêmes. Il y a de nombreuses raisons de le faire, je vais vous expliquer en détail pourquoi nous avons compilé l'intégralité de la barre avec la barre à l'intérieur du werf. .
Werf est désormais un composant plus intégré. Nous obtenons un volant fini, un axe de direction - je ne suis pas très doué en voitures, mais c'est un gros bloc qui résout déjà un assez large éventail de problèmes. Nous n’avons pas besoin de parcourir nous-mêmes le catalogue, de sélectionner une pièce pour une autre, de réfléchir à la manière de les visser ensemble. Nous obtenons une moissonneuse-batteuse prête à l'emploi qui résout un grand nombre de problèmes à la fois. Mais à l'intérieur, il est construit à partir des mêmes composants open source, il utilise toujours Docker pour l'assemblage, Helm pour certaines fonctionnalités et il existe plusieurs autres bibliothèques. Il s'agit d'un outil intégré permettant de sortir rapidement et facilement des CI/CD sympas de la boîte.
Kubernetes est-il difficile à maintenir ?
— Vous parlez de l'expérience que vous avez commencé à utiliser Kubernetes, c'est un cadre pour vous, un moteur, et que vous pouvez y accrocher beaucoup de choses différentes : une carrosserie, un volant, des pédales à visser, des sièges. La question se pose : à quel point le support de Kubernetes est-il difficile pour vous ? Vous avez beaucoup d'expérience, combien de temps et de ressources consacrez-vous au support de Kubernetes indépendamment de tout le reste ?
Dmitry: C'est une question très difficile et pour y répondre, nous devons comprendre ce qu'est le support et ce que nous attendons de Kubernetes. Peut-être que tu peux révéler ?
— Pour autant que je sache et comme je le vois, de nombreuses équipes souhaitent désormais essayer Kubernetes. Chacun s'y attele, le met à genoux. J'ai le sentiment que les gens ne comprennent pas toujours la complexité de ce système.
Dmitry: C'est comme ça.
— Dans quelle mesure est-il difficile de prendre et d'installer Kubernetes à partir de zéro pour qu'il soit prêt pour la production ?
Dmitry: Selon vous, à quel point est-il difficile de transplanter un cœur ? Je comprends que c'est une question compromettante. Utiliser un scalpel et ne pas se tromper n’est pas si difficile. S'ils vous disent où couper et où coudre, alors la procédure en elle-même n'est pas compliquée. Il est difficile de garantir à chaque fois que tout s’arrangera.
Installer Kubernetes et le faire fonctionner est simple : poussin ! — installé, il existe de nombreuses méthodes d'installation. Mais que se passe-t-il lorsque des problèmes surviennent ?
Des questions se posent toujours : qu’est-ce que nous n’avons pas encore pris en compte ? Qu'est-ce qu'on n'a pas encore fait ? Quels paramètres du noyau Linux ont été mal spécifiés ? Seigneur, les avons-nous même mentionnés ?! Quels composants Kubernetes avons-nous livrés et lesquels n'avons-nous pas été livrés ? Des milliers de questions se posent et pour y répondre, il faut passer 15 à 20 ans dans cette industrie.
J'ai un exemple récent sur ce sujet qui peut révéler le sens du problème « Kubernetes est-il difficile à maintenir ? Il y a quelque temps, nous avons sérieusement réfléchi à la possibilité d'essayer d'implémenter Cilium en tant que réseau dans Kubernetes.
Laissez-moi vous expliquer ce qu'est Cilium. Kubernetes a de nombreuses implémentations différentes du sous-système réseau, et l'une d'entre elles est très intéressante : Cilium. Quelle est sa signification ? Dans le noyau, il y a quelque temps, il est devenu possible d'écrire des hooks pour le noyau, qui envahissent d'une manière ou d'une autre le sous-système réseau et divers autres sous-systèmes, et vous permettent de contourner de gros morceaux du noyau.
Le noyau Linux a historiquement une déroute IP, un surfiltre, des ponts et de nombreux anciens composants vieux de 15, 20, 30 ans. En général, ils fonctionnent, tout va bien, mais maintenant ils ont empilé des conteneurs, et cela ressemble à une tour de 15 briques les unes sur les autres, et vous vous tenez dessus sur une jambe - une sensation étrange. Ce système s'est historiquement développé avec de nombreuses nuances, comme l'appendice du corps. Dans certaines situations, il existe des problèmes de performances, par exemple.
Il existe un merveilleux BPF et la possibilité d'écrire des hooks pour le noyau - les gars ont écrit leurs propres hooks pour le noyau. Le paquet entre dans le noyau Linux, ils le sortent directement en entrée, le traitent eux-mêmes comme il se doit sans ponts, sans TCP, sans pile IP - bref, en contournant tout ce qui est écrit dans le noyau Linux, puis crachent versez-le dans le conteneur.
Ce qui s'est passé? Des performances très cool, des fonctionnalités intéressantes - tout simplement cool ! Mais nous regardons cela et voyons que sur chaque machine il y a un programme qui se connecte à l'API Kubernetes et, sur la base des données qu'il reçoit de cette API, génère du code C et compile les binaires qu'il charge dans le noyau pour que ces hooks fonctionnent. dans l'espace du noyau.
Que se passe-t-il si quelque chose ne va pas ? Nous ne savons pas. Pour comprendre cela, vous devez lire tout ce code, comprendre toute la logique, et c’est incroyable à quel point c’est difficile. Mais d’un autre côté, il y a ces ponts, ces filtres de réseau, ces routages IP – je n’ai pas lu leur code source, ni les 40 ingénieurs qui travaillent dans notre entreprise non plus. Peut-être que seuls quelques-uns comprennent certaines parties.
Et quelle est la différence ? Il s'avère qu'il existe ip rout, le noyau Linux, et qu'il existe un nouvel outil - quelle différence cela fait-il, nous ne comprenons pas l'un ou l'autre. Mais nous avons peur d’utiliser quelque chose de nouveau – pourquoi ? Parce que si l'outil a 30 ans, alors en 30 ans tous les bugs ont été trouvés, toutes les erreurs ont été corrigées et vous n'avez pas besoin de tout savoir - il fonctionne comme une boîte noire et fonctionne toujours. Tout le monde sait quel tournevis de diagnostic coller à quel endroit, quel tcpdump exécuter à quel moment. Tout le monde connaît bien les utilitaires de diagnostic et comprend comment cet ensemble de composants fonctionne dans le noyau Linux - non pas comment il fonctionne, mais comment l'utiliser.
Et le Cilium, incroyablement cool, n’a pas 30 ans, il n’a pas encore vieilli. Kubernetes a le même problème, copiez. Que Cilium est parfaitement installé, que Kubernetes est parfaitement installé, mais quand quelque chose ne va pas en production, êtes-vous capable de comprendre rapidement dans une situation critique ce qui n'a pas fonctionné ?
Quand nous disons qu'il est difficile de maintenir Kubernetes, non, c'est très facile, et oui, c'est incroyablement difficile. Kubernetes fonctionne très bien seul, mais avec un milliard de nuances.
À propos de l’approche « J’aurai de la chance »
— Existe-t-il des entreprises où ces nuances sont presque garanties d'apparaître ? Supposons que Yandex transfère soudainement tous les services vers Kubernetes, la charge y sera énorme.
Dmitry: Non, ce n'est pas une conversation sur la charge, mais sur les choses les plus simples. Par exemple, nous avons Kubernetes, nous y avons déployé l'application. Comment sais-tu que ça marche ? Il n'existe tout simplement pas d'outil prêt à l'emploi pour comprendre que l'application ne plante pas. Il n'existe pas de système prêt à l'emploi qui envoie des alertes ; vous devez configurer ces alertes et chaque planification. Et nous mettons à jour Kubernetes.
J'ai Ubuntu 16.04. On peut dire qu'il s'agit d'une ancienne version, mais nous y sommes toujours car c'est LTS. Il existe systemd, dont la nuance est qu'il ne nettoie pas les groupes C. Kubernetes lance les pods, crée des groupes C, puis supprime les pods, et d'une manière ou d'une autre, il s'avère - je ne me souviens pas des détails, désolé - que les tranches systemd restent. Cela conduit au fait qu'avec le temps, toute voiture commence à ralentir fortement. Ce n’est même pas une question de chargement élevé. Si des pods permanents sont lancés, par exemple s'il existe une tâche Cron qui génère constamment des pods, alors la machine avec Ubuntu 16.04 commencera à ralentir après une semaine. Il y aura une charge moyenne constamment élevée en raison du fait qu'un certain nombre de groupes C ont été créés. C’est le problème auquel sera confrontée toute personne qui installe simplement Ubuntu 16 et Kubernetes par-dessus.
Disons qu'il met à jour d'une manière ou d'une autre systemd ou autre chose, mais dans le noyau Linux jusqu'à 4.16, c'est encore plus drôle - lorsque vous supprimez des groupes C, ils fuient dans le noyau et ne sont pas réellement supprimés. Ainsi, après un mois de travail sur cette machine, il sera impossible de consulter les statistiques de mémoire des foyers. Nous retirons un fichier, le roulons dans le programme, et un fichier roule pendant 15 secondes, car le noyau met très longtemps à compter un million de groupes C en lui-même, qui semblent être supprimés, mais non - ils fuient .
Il y a encore beaucoup de petites choses ici et là. Il ne s’agit pas d’un problème auquel les entreprises géantes sont parfois confrontées sous des charges très lourdes – non, il s’agit de choses quotidiennes. Les gens peuvent vivre ainsi pendant des mois – ils ont installé Kubernetes, déployé l’application – cela semble fonctionner. Pour beaucoup de gens, c'est normal. Ils ne sauront même pas que cette application va planter pour une raison quelconque, ils ne recevront pas d’alerte, mais pour eux, c’est la norme. Auparavant, nous vivions sur des machines virtuelles sans surveillance, maintenant nous sommes passés à Kubernetes, également sans surveillance - quelle est la différence ?
Le problème est que lorsque nous marchons sur la glace, nous ne connaissons jamais son épaisseur à moins de la mesurer à l’avance. Beaucoup de gens marchent et ne s’inquiètent pas, car ils ont déjà marché.
De mon point de vue, la nuance et la complexité du fonctionnement de tout système sont de garantir que l’épaisseur de la glace est exactement suffisante pour résoudre nos problèmes. C'est de cela dont nous parlons.
En informatique, il me semble qu'il y a trop d'approches « j'aurai de la chance ». De nombreuses personnes installent des logiciels et utilisent des bibliothèques de logiciels dans l’espoir d’avoir de la chance. En général, beaucoup de gens ont de la chance. C'est probablement pour ça que ça marche.
— D'après mon évaluation pessimiste, cela ressemble à ceci : lorsque les risques sont élevés et que l'application doit fonctionner, alors le support de Flaunt, peut-être de Red Hat, est nécessaire, ou vous avez besoin de votre propre équipe interne dédiée spécifiquement à Kubernetes, qui est prête pour le retirer.
Dmitry: Objectivement, c'est le cas. Se lancer seul dans l’histoire de Kubernetes pour une petite équipe comporte un certain nombre de risques.
Avons-nous besoin de conteneurs ?
— Pouvez-vous nous dire quelle est l'étendue de Kubernetes en Russie ?
Dmitry: Je n'ai pas ces données, et je ne suis pas sûr que quelqu'un d'autre les ait. Nous disons : « Kubernetes, Kubernetes », mais il existe une autre façon d'aborder cette question. Je ne sais pas non plus à quel point les conteneurs sont répandus, mais je connais un chiffre tiré de rapports sur Internet selon lequel 70 % des conteneurs sont orchestrés par Kubernetes. Il s’agissait d’une source fiable pour un échantillon assez important dans le monde entier.
Puis une autre question : avons-nous besoin de conteneurs ? Mon sentiment personnel et la position globale de la société Flant est que Kubernetes est un standard de facto.
Il n'y aura rien d'autre que Kubernetes.
Cela change absolument la donne dans le domaine de la gestion des infrastructures. Juste absolu - c'est tout, plus d'Ansible, Chef, de machines virtuelles, Terraform. Je ne parle pas des anciennes méthodes des fermes collectives. Kubernetes est un changement absolu, et maintenant ce ne sera que comme ça.
Il est clair que pour certains, il faudra quelques années, et pour d’autres, quelques décennies, pour s’en rendre compte. Je n'ai aucun doute qu'il n'y aura que Kubernetes et ce nouveau look : on n'endommage plus le système d'exploitation, mais on utilise infrastructure en tant que code, mais pas avec du code, mais avec yml - une infrastructure décrite de manière déclarative. J'ai le sentiment que ce sera toujours comme ça.
— Autrement dit, les entreprises qui ne sont pas encore passées à Kubernetes y passeront certainement ou resteront dans l'oubli. Je t'ai bien compris ?
Dmitry: Ce n'est pas non plus tout à fait vrai. Par exemple, si nous avons pour tâche d'exécuter un serveur DNS, il peut alors être exécuté sur FreeBSD 4.10 et fonctionner parfaitement pendant 20 ans. Travaillez et c'est tout. Peut-être que dans 20 ans, quelque chose devra être mis à jour une fois. Si nous parlons d'un logiciel dans le format que nous avons lancé et qu'il fonctionne réellement pendant de nombreuses années sans aucune mise à jour, sans apporter de modifications, alors, bien sûr, il n'y aura pas de Kubernetes. Il n'est pas nécessaire là-bas.
Tout ce qui concerne CI/CD - partout où une livraison continue est nécessaire, où vous devez mettre à jour les versions, apporter des modifications actives, partout où vous devez développer une tolérance aux pannes - uniquement Kubernetes.
À propos des microservices
- Ici j'ai une légère dissonance. Pour travailler avec Kubernetes, vous avez besoin d'un support externe ou interne - c'est le premier point. Deuxièmement, lorsque nous commençons tout juste le développement, nous sommes une petite startup, nous n'avons encore rien, le développement pour Kubernetes ou l'architecture des microservices en général peut être complexe et pas toujours économiquement justifié. Votre avis m'intéresse : les startups doivent-elles immédiatement commencer à écrire pour Kubernetes à partir de zéro, ou peuvent-elles toujours écrire un monolithe, puis venir uniquement à Kubernetes ?
Dmitry: Question sympa. J'ai une discussion sur les microservices J’ai souvent rencontré des gens essayant d’enfoncer des clous avec un microscope. L'approche elle-même est correcte : nous concevons nous-mêmes notre logiciel interne de cette façon. Mais lorsque vous faites cela, vous devez clairement comprendre ce que vous faites. Le mot que je déteste le plus à propos des microservices est « micro ». Historiquement, ce mot est né là-bas, et pour une raison quelconque, les gens pensent que micro est très petit, moins d'un millimètre, comme un micromètre. C'est faux.
Par exemple, il existe un monolithe écrit par 300 personnes, et tous ceux qui ont participé au développement comprennent qu'il y a des problèmes là-bas, et il devrait être divisé en micro-morceaux - environ 10 morceaux, chacun étant écrit par 30 personnes. dans une version minimale. C’est important, nécessaire et cool. Mais quand une startup vient vers nous, où 3 gars très cool et talentueux ont écrit 60 microservices à genoux, à chaque fois je cherche Corvalol.
Il me semble que cela a déjà été dit des milliers de fois - nous avons obtenu un monolithe distribué sous une forme ou une autre. Ce n'est pas économiquement justifié, c'est très difficile en général dans tout. J’ai vu ça tellement de fois que ça me fait vraiment mal, alors je continue d’en parler.
A la question initiale, il y a un conflit entre le fait que, d'une part, Kubernetes est effrayant à utiliser, car on ne sait pas ce qui pourrait y tomber en panne ou ne pas fonctionner, d'autre part, il est clair que tout y passe et rien d'autre que Kubernetes n'existera. Répondre - pesez le montant des avantages qui en découlent, le nombre de tâches que vous pouvez résoudre. C'est d'un côté de l'échelle. D'autre part, il existe des risques liés aux temps d'arrêt ou à une diminution du temps de réponse, du niveau de disponibilité - avec une diminution des indicateurs de performance.
Voilà : soit nous avançons rapidement, et Kubernetes nous permet de faire beaucoup de choses beaucoup plus rapidement et mieux, soit nous utilisons des solutions fiables et éprouvées, mais avançons beaucoup plus lentement. C’est un choix que chaque entreprise doit faire. Vous pouvez le considérer comme un chemin dans la jungle : lorsque vous marchez pour la première fois, vous pouvez rencontrer un serpent, un tigre ou un blaireau fou, et lorsque vous avez marché 10 fois, vous avez parcouru le chemin, retiré les branches et marcher plus facilement. À chaque fois, le chemin s’élargit. Ensuite c'est une route goudronnée, et plus tard un beau boulevard.
Kubernetes ne reste pas immobile. Question encore : Kubernetes, d'une part, c'est 4 à 5 binaires, d'autre part, c'est l'ensemble de l'écosystème. C'est le système d'exploitation que nous avons sur nos machines. Qu'est-ce que c'est? Ubuntu ou Curios ? Il s'agit du noyau Linux, un tas de composants supplémentaires. Toutes ces choses ici, un serpent venimeux a été jeté hors de la route, une clôture y a été érigée. Kubernetes se développe très rapidement et de manière dynamique, et le volume des risques, le volume de l'inconnu diminue chaque mois et, par conséquent, ces échelles se rééquilibrent.
Répondant à la question de savoir ce qu'une startup devrait faire, je dirais : venez chez Flaunt, payez 150 XNUMX roubles et bénéficiez d'un service DevOps clé en main simple. Si vous êtes une petite startup avec quelques développeurs, cela fonctionne. Au lieu d'embaucher votre propre DevOps, qui devra apprendre à résoudre vos problèmes et à payer un salaire à ce moment-là, vous obtiendrez une solution clé en main à tous les problèmes. Oui, il y a certains inconvénients. En tant qu'externalisateur, nous ne pouvons pas être aussi impliqués et réagir rapidement aux changements. Mais nous avons beaucoup d’expertise et de pratiques toutes faites. Nous garantissons que dans n'importe quelle situation, nous le comprendrons rapidement et ressusciterons tous Kubernetes d'entre les morts.
Je recommande fortement l'externalisation vers des startups et des entreprises établies jusqu'à une taille où vous pouvez consacrer une équipe de 10 personnes aux opérations, car sinon cela ne sert à rien. Il est tout à fait logique d’externaliser cette tâche.
À propos d'Amazon et de Google
— Un hébergeur d'une solution d'Amazon ou de Google peut-il être considéré comme un sous-traitant ?
Dmitry: Oui, bien sûr, cela résout un certain nombre de problèmes. Mais là encore, il y a des nuances. Encore faut-il comprendre comment l'utiliser. Par exemple, il y a mille petites choses dans le travail d'Amazon AWS : le Load Balancer doit être réchauffé ou une demande doit être écrite à l'avance selon laquelle « les gars, nous recevrons du trafic, réchauffez le Load Balancer pour nous ! Vous devez connaître ces nuances.
Lorsque vous vous tournez vers des personnes spécialisées dans ce domaine, vous obtenez presque toutes les choses typiques fermées. Nous avons aujourd'hui 40 ingénieurs, et d'ici la fin de l'année ils seront probablement 60 - nous avons certainement rencontré toutes ces choses. Même si nous rencontrons à nouveau ce problème sur certains projets, nous nous le posons rapidement et savons comment le résoudre.
La réponse est probablement : bien sûr, une histoire hébergée facilite certaines parties. La question est de savoir si vous êtes prêt à faire confiance à ces hébergeurs et s’ils résoudront vos problèmes. Amazon et Google ont bien réussi. Pour tous nos cas – exactement. Nous n'avons plus d'expériences positives. Tous les autres cloud avec lesquels nous avons essayé de travailler créent beaucoup de problèmes - Ager, et tout ce qui existe en Russie, et toutes sortes d'OpenStack dans différentes implémentations : Headster, Overage - tout ce que vous voulez. Ils créent tous des problèmes que vous ne voulez pas résoudre.
La réponse est donc oui, mais en réalité, il n’existe pas beaucoup de solutions hébergées matures.
Qui a besoin de Kubernetes ?
— Et pourtant, qui a besoin de Kubernetes ? Qui devrait déjà passer à Kubernetes, qui est le client Flaunt typique spécialement conçu pour Kubernetes ?
Dmitry: C'est une question intéressante, car en ce moment, dans le sillage de Kubernetes, beaucoup de gens viennent nous voir : « Les gars, nous savons que vous faites Kubernetes, faites-le pour nous ! Nous leur répondons : « Messieurs, nous ne faisons pas de Kubernetes, nous faisons de la prod et tout ce qui s'y rapporte. Parce qu'il est actuellement tout simplement impossible de créer un produit sans faire tout le CI/CD et toute cette histoire. Tout le monde s’est éloigné de la division selon laquelle nous avons développement par développement, puis exploitation par exploitation.
Nos clients attendent des choses différentes, mais tout le monde attend un bon miracle qu'ils aient certains problèmes, et maintenant - hop ! — Kubernetes les résoudra. Les gens croient aux miracles. Dans leur esprit, ils comprennent qu'il n'y aura pas de miracle, mais dans leur âme, ils espèrent - et si ce Kubernetes résolvait maintenant tout pour nous, ils en parlent tellement ! Soudain, il - éternuez ! - et une solution miracle, éternuez ! - et nous avons une disponibilité de 100 %, tous les développeurs peuvent publier tout ce qui entre en production 50 fois, et cela ne plante pas. En général, un miracle !
Lorsque de telles personnes viennent nous voir, nous leur disons : « Désolé, mais le miracle n’existe pas. » Pour être en bonne santé, il faut bien manger et faire de l'exercice. Pour avoir un produit fiable, il doit être fabriqué de manière fiable. Pour avoir un CI/CD pratique, vous devez le faire comme ceci. Cela représente beaucoup de travail à faire.
Répondre à la question de savoir qui a besoin de Kubernetes : personne n'a besoin de Kubernetes.
Certaines personnes pensent à tort qu’elles ont besoin de Kubernetes. Les gens ont besoin, ils ont un besoin profond d’arrêter de penser, d’étudier et de s’intéresser à tous les problèmes d’infrastructure et aux problèmes de fonctionnement de leurs applications. Ils veulent que les applications fonctionnent et se déploient simplement. Pour eux, Kubernetes est l’espoir qu’ils cesseront d’entendre l’histoire selon laquelle « nous restions là », ou « nous ne pouvons pas déployer », ou autre chose.
Le directeur technique vient généralement chez nous. Ils lui demandent deux choses : d'une part, nous donner des fonctionnalités, d'autre part, de la stabilité. Nous vous suggérons de prendre sur vous et de le faire. La solution miracle, ou plutôt argentée, est que vous arrêterez de penser à ces problèmes et de perdre du temps. Vous aurez des personnes spéciales qui clôtureront ce numéro.
La formulation selon laquelle nous ou quelqu'un d'autre avons besoin de Kubernetes est incorrecte.
Les administrateurs ont vraiment besoin de Kubernetes, car c'est un jouet très intéressant avec lequel vous pouvez jouer et bricoler. Soyons honnêtes : tout le monde aime les jouets. Nous sommes tous des enfants quelque part, et quand nous en voyons un nouveau, nous avons envie d'y jouer. Pour certains, cela a été découragé, par exemple au sein de l’administration, parce qu’ils ont déjà assez joué et sont déjà fatigués au point qu’ils ne veulent tout simplement pas le faire. Mais cela n’est complètement perdu pour personne. Par exemple, si je suis fatigué depuis longtemps des jouets dans le domaine de l'administration système et du DevOps, alors j'aime toujours les jouets, j'en achète toujours de nouveaux. Tout le monde, d'une manière ou d'une autre, veut toujours une sorte de jouet.
Pas besoin de jouer avec la production. Quoi que je recommande catégoriquement de ne pas faire et ce que je vois maintenant en masse : « Oh, un nouveau jouet ! - ils ont couru pour l'acheter, l'ont acheté et : "Maintenant, apportons-le à l'école et montrons-le à tous nos amis." Ne fais pas ça. Je m'excuse, mes enfants ne font que grandir, je vois constamment quelque chose chez les enfants, je le remarque en moi-même, puis je le généralise aux autres.
La réponse finale est : vous n’avez pas besoin de Kubernetes. Vous devez résoudre vos problèmes.
Ce que vous pouvez réaliser, c'est :
- l'aiguillon ne tombe pas ;
- même s'il essaie de tomber, on le sait d'avance, et on peut y mettre quelque chose ;
- nous pouvons le modifier à la vitesse à laquelle notre activité l’exige, et nous pouvons le faire facilement ; cela ne nous pose aucun problème.
Il y a deux vrais besoins : la fiabilité et le dynamisme/flexibilité du déploiement. Tous ceux qui réalisent actuellement des projets informatiques, quel que soit leur type d'entreprise - un logiciel pour faciliter le monde, et qui comprennent cela, doivent répondre à ces besoins. Kubernetes avec la bonne approche, avec la bonne compréhension et avec suffisamment d'expérience vous permet de les résoudre.
À propos du sans serveur
— Si vous regardez un peu plus loin dans l'avenir, en essayant de résoudre le problème de l'absence de problèmes d'infrastructure, avec la rapidité de déploiement et la rapidité des changements d'applications, de nouvelles solutions apparaissent, par exemple sans serveur. Ressentez-vous un potentiel dans cette direction et, disons, un danger pour Kubernetes et les solutions similaires ?
Dmitry: Ici, nous devons encore une fois faire une remarque : je ne suis pas un voyant qui regarde devant lui et dit : ce sera comme ça ! Même si je viens de faire la même chose. Je regarde mes pieds et j'y vois un tas de problèmes, par exemple, comment fonctionnent les transistors dans un ordinateur. C'est drôle, non ? Nous rencontrons quelques bugs au niveau du CPU.
Rendre le sans serveur assez fiable, bon marché, efficace et pratique, résolvant tous les problèmes de l'écosystème. Ici, je suis d’accord avec Elon Musk sur le fait qu’une deuxième planète est nécessaire pour créer une tolérance aux pannes pour l’humanité. Même si je ne sais pas ce qu’il dit, je comprends que je ne suis pas prêt à voler moi-même vers Mars et que cela n’arrivera pas demain.
Avec le sans serveur, il est clairement clair qu'il s'agit d'une chose idéologiquement correcte, comme la tolérance aux pannes pour l'humanité : avoir deux planètes vaut mieux qu'une. Mais comment faire maintenant ? Envoyer une expédition n'est pas un problème si vous concentrez vos efforts dessus. Envoyer plusieurs expéditions et y installer plusieurs milliers de personnes, je pense, est également réaliste. Mais le rendre totalement tolérant aux pannes pour que la moitié de l'humanité y vive, cela me semble désormais impossible, ne pas être envisagé.
Avec le face-à-face sans serveur : le truc est cool, mais on est loin des problèmes de 2019. Plus près de 2030 – vivons pour le voir. Je n'ai aucun doute que nous vivrons, nous vivrons certainement (je le répète avant de nous coucher), mais maintenant nous devons résoudre d'autres problèmes. C'est comme croire au poney de conte de fées Rainbow. Oui, quelques pour cent des cas sont résolus, et ils sont parfaitement résolus, mais subjectivement, le sans serveur est un arc-en-ciel... Pour moi, ce sujet est trop lointain et trop incompréhensible. Je ne suis pas prêt à parler. En 2019, vous ne pouvez pas écrire une seule application sans serveur.
Comment Kubernetes va évoluer
— Alors que nous nous dirigeons vers cet avenir lointain potentiellement merveilleux, comment pensez-vous que Kubernetes et l'écosystème qui l'entoure vont se développer ?
Dmitry: J'y ai beaucoup réfléchi et j'ai une réponse claire. Le premier est avec état - après tout, l'apatride est plus facile à réaliser. Kubernetes a initialement investi davantage dans ce domaine, tout a commencé avec cela. Stateless fonctionne presque parfaitement dans Kubernetes, il n'y a tout simplement rien à redire. Il y a encore beaucoup de problèmes, ou plutôt de nuances. Tout là-bas fonctionne déjà très bien pour nous, mais c'est nous. Il faudra encore au moins quelques années pour que cela fonctionne pour tout le monde. Ce n'est pas un indicateur calculé, mais mon ressenti dans ma tête.
Bref, le statefull devrait - et va - se développer très fortement, car toutes nos applications stockent des statuts ; il n'y a pas d'applications stateless. C'est une illusion : vous avez toujours besoin d'une sorte de base de données et d'autre chose. Statefull consiste à redresser tout ce qui est possible, à corriger tous les bugs, à améliorer tous les problèmes actuellement rencontrés - appelons cela l'adoption.
Le niveau d'inconnu, le niveau de problèmes non résolus, le niveau de probabilité de rencontrer quelque chose diminueront considérablement. C'est une histoire importante. Et les opérateurs - tout ce qui concerne la codification de la logique d'administration, la logique de contrôle afin d'obtenir un service facile : MySQL easy service, RabbitMQ easy service, Memcache easy service - en général, tous ces composants dont nous devons être sûrs de fonctionner. la boîte. Cela résout simplement le problème que nous voulons une base de données, mais nous ne voulons pas l'administrer, ou nous voulons Kubernetes, mais nous ne voulons pas l'administrer.
Cette histoire de développement des opérateurs sous une forme ou une autre sera importante dans les deux prochaines années.
Je pense que la facilité d'utilisation devrait grandement augmenter - la box deviendra de plus en plus noire, de plus en plus fiable, avec des boutons de plus en plus simples.
Une fois, j'ai écouté une vieille interview d'Isaac Asimov des années 80 sur YouTube dans l'émission Saturday Night Live - un programme comme Urgant, seulement intéressant. Ils l'ont interrogé sur l'avenir des ordinateurs. Il a dit que l'avenir était dans la simplicité, tout comme la radio. Le récepteur radio était à l’origine une chose complexe. Pour capter une vague, il fallait tourner les boutons pendant 15 minutes, tourner les brochettes et généralement savoir comment tout fonctionne, comprendre la physique de la transmission des ondes radio. En conséquence, il ne restait qu'un seul bouton dans la radio.
Maintenant en 2019 quelle radio ? Dans la voiture, le récepteur radio retrouve toutes les ondes et les noms des stations. La physique du processus n’a pas changé depuis 100 ans, mais la facilité d’utilisation a changé. Aujourd’hui, et pas seulement aujourd’hui, déjà en 1980, lors d’une interview avec Azimov, tout le monde utilisait la radio et personne ne pensait à son fonctionnement. Cela a toujours fonctionné – c’est une évidence.
Azimov a alors déclaré qu'il en serait de même avec les ordinateurs - la facilité d'utilisation augmentera. Alors qu’en 1980 il fallait être formé pour appuyer sur les boutons d’un ordinateur, ce ne sera plus le cas à l’avenir.
J'ai le sentiment qu'avec Kubernetes et l'infrastructure, la facilité d'utilisation augmentera également considérablement. Ceci, à mon avis, est évident – cela se situe en surface.
Que faire des ingénieurs ?
— Qu'arrivera-t-il alors aux ingénieurs et aux administrateurs système qui prennent en charge Kubernetes ?
Dmitry: Qu'est-il arrivé au comptable après l'avènement du 1C ? À peu près pareil. Avant cela, ils comptaient sur le papier - maintenant au programme. La productivité du travail a augmenté de plusieurs ordres de grandeur, mais le travail lui-même n’a pas disparu. Si auparavant il fallait 10 ingénieurs pour visser une ampoule, désormais un seul suffira.
Il me semble que la quantité de logiciels et le nombre de tâches augmentent désormais à un rythme plus rapide que l'apparition de nouveaux DevOps et que l'efficacité augmente. Il existe actuellement une pénurie spécifique sur le marché et elle durera longtemps. Plus tard, tout reviendra à une sorte de normalité, dans laquelle l'efficacité du travail augmentera, il y aura de plus en plus de serveurs sans serveur, un neurone sera attaché à Kubernetes, qui sélectionnera toutes les ressources exactement selon les besoins, et en général faites tout elle-même, comme il se doit - la personne s'éloigne et n'intervient pas.
Mais il faudra quand même que quelqu’un prenne des décisions. Force est de constater que le niveau de qualification et de spécialisation de cette personne est plus élevé. De nos jours, dans le service comptable, il n'est pas nécessaire que 10 employés tiennent les livres pour ne pas avoir les mains fatiguées. Ce n'est tout simplement pas nécessaire. De nombreux documents sont automatiquement numérisés et reconnus par le système de gestion électronique des documents. Un seul chef comptable intelligent suffit, avec déjà des compétences bien supérieures et une bonne compréhension.
En général, c’est la voie à suivre dans toutes les industries. C’est pareil avec les voitures : auparavant, une voiture arrivait avec un mécanicien et trois chauffeurs. De nos jours, conduire une voiture est un processus simple auquel nous participons tous au quotidien. Personne ne pense qu’une voiture est quelque chose de compliqué.
Le DevOps ou l’ingénierie système ne disparaîtront pas – le travail de haut niveau et l’efficacité augmenteront.
— J'ai aussi entendu une idée intéressante selon laquelle le travail allait effectivement augmenter.
Dmitry: Bien sûr, à cent pour cent ! Parce que la quantité de logiciels que nous écrivons ne cesse de croître. Le nombre de problèmes que nous résolvons avec des logiciels ne cesse de croître. La quantité de travail augmente. Aujourd’hui, le marché du DevOps est terriblement surchauffé. Cela se voit dans les attentes salariales. Dans le bon sens, sans entrer dans les détails, il devrait y avoir des juniors qui veulent X, des middles qui veulent 1,5X et des seniors qui veulent 2X. Et maintenant, si vous regardez le marché salarial DevOps de Moscou, un junior veut de X à 3X et un senior veut de X à 3X.
Personne ne sait combien cela coûte. Le niveau de salaire se mesure par votre confiance - une véritable maison de fous, pour être honnête, un marché terriblement surchauffé.
Bien entendu, cette situation va changer très prochainement – une certaine saturation devrait se produire. Ce n'est pas le cas du développement de logiciels - malgré le fait que tout le monde a besoin de développeurs et que tout le monde a besoin de bons développeurs, le marché comprend qui vaut quoi - l'industrie s'est stabilisée. Ce n'est pas le cas avec DevOps de nos jours.
— D'après ce que j'ai entendu, j'ai conclu que l'administrateur système actuel ne devrait pas trop s'inquiéter, mais qu'il est temps d'améliorer ses compétences et de se préparer au fait que demain il y aura plus de travail, mais il sera plus qualifié.
Dmitry: Cent pour cent. En général, nous vivons en 2019 et la règle de vie est la suivante : apprentissage à vie - nous apprenons tout au long de notre vie. Il me semble que maintenant tout le monde le sait et le ressent déjà, mais il ne suffit pas de le savoir, il faut le faire. Chaque jour, nous devons changer. Si nous ne le faisons pas, nous serons tôt ou tard mis à l’écart de la profession.
Préparez-vous à des virages serrés à 180 degrés. Je n'exclus pas une situation où quelque chose change radicalement, où quelque chose de nouveau est inventé - cela arrive. Houblon! - et nous agissons désormais différemment. Il est important de s’y préparer et de ne pas s’inquiéter. Il se peut que demain tout ce que je fais s'avère inutile - rien, j'ai étudié toute ma vie et je suis prêt à apprendre autre chose. Ce n'est pas un problème. Il n’y a pas lieu d’avoir peur de la sécurité de l’emploi, mais vous devez être prêt à apprendre constamment quelque chose de nouveau.
Souhaits et une minute de publicité
- As-tu un souhait ?
Dmitry: Oui, j'ai plusieurs souhaits.
Premier et mercantile - abonnez-vous à . Chers lecteurs, allez sur YouTube et abonnez-vous à notre chaîne. Dans environ un mois, nous commencerons l'expansion active du service vidéo. Nous aurons beaucoup de contenus éducatifs sur Kubernetes, ouverts et variés : des choses pratiques, jusqu'aux laboratoires, jusqu'aux choses théoriques fondamentales profondes et comment utiliser Kubernetes au niveau niveau de principes et de modèles.
Le deuxième souhait mercantile - aller à et mettre des étoiles parce que nous nous en nourrissons. Si vous ne nous donnez pas d'étoiles, nous n'aurons rien à manger. C'est comme le mana dans un jeu vidéo. Nous faisons quelque chose, nous le faisons, nous essayons, quelqu'un dit que ce sont des vélos horribles, quelqu'un que tout ne va pas du tout, mais nous continuons et agissons en toute honnêteté. Nous voyons un problème, le résolvons et partageons notre expérience. Donnez-nous donc une étoile, elle ne vous quittera pas, mais elle viendra à nous, car nous nous en nourrissons.
Troisième souhait important et non plus mercantile - arrête de croire aux contes de fées. Vous êtes des professionnels. DevOps est un métier très sérieux et responsable. Arrêtez de jouer sur le lieu de travail. Laissez-le cliquer pour vous et vous le comprendrez. Imaginez que vous venez à l'hôpital et que le médecin fait des expériences sur vous. Je comprends que cela peut être offensant pour quelqu'un, mais, très probablement, il ne s'agit pas de vous, mais de quelqu'un d'autre. Dites aux autres d’arrêter aussi. Cela ruine vraiment la vie de nous tous - beaucoup commencent à traiter les opérations, les administrateurs et les DevOps comme des types qui ont encore cassé quelque chose. Cela était « cassé » le plus souvent parce que nous allions jouer et que nous ne regardions pas avec une froide conscience que c'est comme ça, et c'est comme ça.
Cela ne veut pas dire que vous ne devriez pas expérimenter. Nous devons expérimenter, nous le faisons nous-mêmes. Pour être honnête, nous jouons nous-mêmes parfois à des jeux - c'est bien sûr très mauvais, mais rien d'humain ne nous est étranger. Déclarons 2019 une année d'expérimentations sérieuses et réfléchies, et non de jeux en production. Probablement.
- Merci beaucoup!
Dmitry: Merci, Vitaly, à la fois pour le temps et pour l'interview. Chers lecteurs, merci beaucoup si vous en êtes soudainement arrivé à ce point. J'espère que nous vous avons apporté au moins quelques réflexions.
Dans l'interview, Dmitry a abordé la question du werf. C'est désormais un couteau suisse universel qui résout presque tous les problèmes. Mais ce ne fut pas toujours ainsi. Sur au festival Dmitry Stolyarov vous parlera en détail de cet outil. dans le rapport il y aura de tout : les problèmes et les nuances cachées de Kubernetes, les options pour résoudre ces difficultés et la mise en œuvre actuelle de werf en détail. Rejoignez-nous les 27 et 28 mai, nous créerons les outils parfaits.
Source: habr.com