Kubernetes va conquérir le monde. Quand et comment?

Dans l'attente de DevOpsConf Vitaly Khabarov a interviewé Dmitry Stolyarov (distol), directeur technique et co-fondateur de la société «Flant». Vitaly a interrogé Dmitry sur ce que fait «Flant», Kubernetes, le développement de l'écosystème, le support. Ils ont discuté de l'utilité de Kubernetes et de son besoin réel. Ils ont également parlé des microservices, d'Amazon AWS, de l'approche «J'ai de la chance» en DevOps, de l'avenir de Kubernetes lui-même, pourquoi, quand et comment il va conquérir le monde, des perspectives du DevOps et de ce à quoi les ingénieurs doivent se préparer dans un avenir proche avec l'optimisation et les réseaux neuronaux.

L'interview originale sous forme de podcast est à écouter sur DevOps Déflop — un podcast francophone sur le DevOps, et ci-dessous se trouve la version textuelle.

Ici et ci-dessous, les questions sont posées par Vitaly Khabarov un ingénieur d'Express42.

À propos de «Flant»

— Dima, salut. Tu es le directeur technique de «Flant» et aussi son fondateur. Peux-tu, s'il te plaît, nous parler de ce que fait l'entreprise et de ton rôle en son sein ?

Dmitry: De l'extérieur, on dirait que nous sommes ces gars qui vont, installent Kubernetes à tout le monde et font quelque chose avec. Mais ce n'est pas le cas. Nous avons commencé comme une entreprise spécialisée dans Linux, mais depuis longtemps, notre principale activité est la gestion de projets de production et de haute charge clés en main. En général, nous construisons toute l'infrastructure à partir de zéro et ensuite nous en sommes responsables pendant longtemps. Donc, le principal travail que «Flant» fait, et pour lequel elle reçoit de l'argent, c'est prendre la responsabilité et réaliser des productions clés en main..




En tant que directeur technique et un des fondateurs de l'entreprise, je passe mes journées à réfléchir à comment améliorer la disponibilité de la production, simplifier son exploitation, faciliter la vie des administrateurs, et rendre la vie des développeurs plus agréable.

À propos de Kubernetes

— Dernièrement, j'ai vu beaucoup de présentations de «Flant» sur articles Kubernetes. Comment êtes-vous arrivé à cela ?

Dmitry: J'en ai déjà parlé de nombreuses fois, mais cela ne me dérange pas de le répéter. Je pense qu'il est important de revenir sur ce sujet car il y a de la confusion entre cause et effet.

Nous avions vraiment besoin d'un outil. Nous étions confrontés à de nombreux problèmes, nous avons lutté, surmonté ces défis avec divers bricolages et éprouvé un besoin d'un véritable outil. Nous avons exploré de nombreuses options, construit nos propres solutions, accumulé de l'expérience. Peu à peu, nous avons commencé à utiliser Docker presque dès son apparition - vers 2013. À son lancement, nous avions déjà beaucoup d'expérience avec les conteneurs, et nous avions déjà écrit notre propre version de "Docker" - en quelque sorte nos bricolages en Python. Avec Docker, nous avons pu éliminer ces solutions improvisées et utiliser une solution fiable et soutenue par la communauté.

L'histoire est similaire avec Kubernetes. Au moment où il a commencé à gagner en popularité - pour nous, c'était la version 1.2 - nous avions déjà de nombreux bricolages, tant en Shell qu'en Chef, que nous tentions d'orchestrer avec Docker. Nous étions sérieusement orientés vers Rancher et d'autres solutions, puis Kubernetes est arrivé, qui a tout réalisé exactement comme nous l'aurions fait, voire mieux. Il n'y a rien à redire.

Oui, il y a des imperfections ici et là - beaucoup d'éléments non finalisés, et la version 1.2 était vraiment terrible, mais... Kubernetes est comme un bâtiment en construction - on regarde le projet et on sait que ça va être génial. Si le bâtiment a actuellement un fondement et deux étages, on comprend qu'il vaut mieux ne pas emménager tout de suite, mais avec les logiciels, ce n'est pas un problème - on peut déjà l'utiliser.

Nous n'avons jamais eu de moment où nous avons hésité à utiliser Kubernetes ou non. Nous l'attendions depuis longtemps avant son apparition et tentions de créer nos propres analogues.

À propos de Kubernetes

— Participez-vous directement au développement de Kubernetes ?

Dmitry: Indirectement. Nous participons plutôt au développement de l'écosystème. Nous envoyons un certain nombre de pull requests : vers Prometheus, divers opérateurs, Helm - vers l'écosystème. Malheureusement, je ne suis pas en mesure de suivre tout ce que nous faisons et je peux me tromper, mais nous n'avons pas envoyé de pull request au noyau.

— Par ailleurs, développez-vous de nombreux outils autour de Kubernetes ?

Dmitry: La stratégie est la suivante : nous allons et faisons des pull requests pour tout ce qui existe déjà. Si les pull requests ne sont pas acceptées, nous les forkons pour nous-mêmes et nous continuons à vivre avec nos versions jusqu'à ce qu'elles soient acceptées. Ensuite, lorsque cela arrive à la version upstream, nous retournons à la version upstream.

Par exemple, nous avons un opérateur Prometheus, avec lequel nous avons basculé vers le upstream de notre build environ cinq fois, probablement. Nous avons besoin d'une fonctionnalité, nous avons envoyé une demande de tirage, nous devons la déployer demain, et nous ne voulons pas attendre qu'elle soit publiée dans le upstream. Par conséquent, nous rassemblons notre propre version, déployons notre build avec la fonctionnalité dont nous avons besoin sur tous nos clusters. Puis, cela est par exemple renvoyé à upstream avec les mots : « Les gars, faisons-le pour un cas plus général », nous, ou quelqu'un d'autre, le complétons, et avec le temps, cela fusionne à nouveau.

Tout ce qui existe, nous essayons de le développer.. De nombreux éléments qui n'existent pas encore, qui n'ont pas encore été imaginés ou qui ont été imaginés mais pas encore réalisés, nous les concevons. Et ce n'est pas parce que nous aimons le processus lui-même ou la création de vélos en tant que domaine, mais simplement parce que nous avons besoin de cet outil. On nous pose souvent la question, pourquoi avons-nous créé telle ou telle chose ? La réponse est simple : parce que nous devions avancer, résoudre un problème pratique, et nous l'avons résolu avec cet outil.

Le chemin est toujours le même : nous cherchons très soigneusement et, si nous ne trouvons aucune solution à comment faire un trolleybus à partir d’un pain, alors nous faisons notre propre pain et notre propre trolleybus.

Les outils de Flant

— Je sais qu'il y a maintenant des opérateurs addon chez Flant, des opérateurs shell, des outils dapp/werf. Si je comprends bien, c'est le même outil sous différentes incarnations. Je comprends aussi qu'il y a encore beaucoup d'autres outils à l'intérieur de Flant. Est-ce correct ?

Dmitry: Nous avons encore beaucoup de choses sur GitHub. Parmi ce dont je me souviens maintenant, nous avons statusmap - un tableau pour Grafana, qui est apprécié de tous. Il est mentionné presque dans chaque deuxième article sur la surveillance de Kubernetes sur Medium. Il est impossible de décrire brièvement ce qu'est statusmap - un article séparé est nécessaire, mais c'est un outil très utile pour surveiller le statut dans le temps, car dans Kubernetes, nous devons souvent montrer le statut au fil du temps. Nous avons aussi LogHouse - c'est un outil basé sur ClickHouse et un peu de magie noire pour collecter des logs dans Kubernetes.

De nombreux outils ! Et il y en aura encore plus, car un certain nombre de solutions internes seront publiées cette année. Parmi les plus importantes, il y a une multitude d'addons pour Kubernetes, comme la bonne installation de sert manager — un outil pour la gestion des certificats, ou la bonne installation de Prometheus avec une multitude d'extensions — ce sont une vingtaine de binaires différents qui exportent des données et collectent des éléments, et avec Prometheus, c'est une superbe interface graphique et des alertes. Tout cela constitue une multitude d'addons pour Kubernetes qui s'installent dans le cluster, le transformant d'un simple en un puissant, sophistiqué et automatisé, où de nombreuses questions sont déjà résolues. Oui, nous faisons beaucoup de choses.

Développement de l'écosystème

— Je pense que c'est une contribution très importante au développement de cet outil et de ses méthodes d'utilisation. Peux-tu estimer approximativement qui aurait également pu apporter une telle contribution au développement de l'écosystème ?

Dmitry: En Russie, parmi les entreprises qui opèrent sur notre marché — personne n'est même proche.. Bien sûr, c'est une déclaration audacieuse, car il y a de grands acteurs, comme Mail et Yandex — ils font aussi quelque chose avec Kubernetes, mais même eux ne se rapprochent pas de la contribution des entreprises dans le monde entier, qui en font beaucoup plus que nous. Il est difficile de comparer "Flant" avec une équipe de 80 personnes et Red Hat, qui a 300 ingénieurs rien que pour Kubernetes, si je ne me trompe pas. C'est difficile à comparer. Dans notre département RnD, nous sommes 6, y compris moi, qui développons tous nos outils. 6 personnes contre 300 ingénieurs de Red Hat — c'est un peu difficile à comparer.

— Néanmoins, même lorsque ces 6 personnes peuvent faire quelque chose de vraiment utile et transférable, lorsqu'elles sont confrontées à un problème pratique et qu'elles donnent une solution à la communauté — c'est un cas intéressant. Je comprends que dans de grandes entreprises technologiques, où il y a leur propre développement et une équipe de support Kubernetes, de tels outils peuvent également être développés. C'est un exemple pour eux, montrant qu'on peut développer et donner à la communauté, donner un coup de pouce à toute la communauté qui utilise Kubernetes.

Dmitry: C'est probablement la particularité de l'intégrateur, sa spécificité. Nous avons de nombreux projets et voyons beaucoup de 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 maximiser leur réduction de coûts. Nous travaillons activement sur cela. Il m'est difficile de parler de la Russie et du monde, mais nous avons environ 40 ingénieurs DevOps dans notre entreprise qui s'occupent de Kubernetes. Je ne pense pas qu'il y ait beaucoup d'entreprises en Russie avec un nombre comparable de spécialistes connaissant Kubernetes, s'ils existent vraiment.

Je comprends tout sur le nom de poste d'ingénieur DevOps, tout le monde comprend et s'habitue à appeler les ingénieurs DevOps des ingénieurs DevOps, nous ne discuterons pas de cela. Ces 40 merveilleux ingénieurs DevOps font face chaque jour à des problèmes et les résolvent, nous analysons simplement cette expérience et essayons de l'universaliser. Nous comprenons que si cela reste en interne, dans un an ou deux, l'outil devient inutile, car quelque part dans la communauté, un outil prêt à l'emploi apparaîtra. Il n'y a aucun sens à accumuler cette expérience en interne - c'est juste un gaspillage de forces et de temps dans dev/null. Mais nous ne sommes pas du tout réticents. Nous publions tout avec grand plaisir et savons qu'il est nécessaire de le publier, de le développer, de le promouvoir, de le faire connaître, afin que les gens l'utilisent et ajoutent leur propre expérience - alors tout grandit et vit. Dans deux ans, l'outil ne sera pas à la poubelle. Nous ne sommes pas réticents à continuer à investir des efforts, car il est visible que des gens utilisent notre outil, et dans deux ans, tout le monde l'utilise déjà.

C'est une partie de notre grande stratégie avec dapp/werf. Je ne me souviens pas quand nous avons commencé à le faire, il y a semble-t-il 3 ans. À l'origine, c'était entièrement sur shell. C'était un super proof of concept, nous avons résolu certaines de nos tâches particulières - ça a marché ! Mais avec shell, il y a des problèmes, il est impossible d'évoluer davantage, programmer sur shell est en effet une activité assez difficile. Nous avions l'habitude de coder en Ruby, donc nous avons refait quelque chose en Ruby, et avons continué à développer, développer, développer, et avons été confrontés au fait que la communauté, la foule, qui ne dit pas « nous voulons ou ne voulons pas », se détourne de Ruby, aussi drôle que cela puisse paraître. Nous avons compris que nous devions écrire tout cela en Go, juste pour nous conformer au premier point de la liste de contrôle : L'outil DevOps doit être un binaire statique. Sur Go ou pas sur Go, cela n'a pas tellement d'importance, mais il vaut mieux avoir un binaire statique écrit en Go.

Nous avons investi des efforts, réécrit le dapp en Go et l'avons nommé werf. Le dapp n'est plus maintenu, n'est plus développé, il fonctionne dans une certaine version définitive, mais il existe un chemin de mise à niveau absolu vers le haut, et il est possible de le suivre.

Pourquoi le dapp a-t-il été créé

— Peux-tu brièvement expliquer pourquoi le dapp a été créé, quels problèmes il résout ?

Dmitry: La première raison est la construction. Au départ, nous avions de gros problèmes avec la compilation, lorsque Docker ne supportait pas le multi-stage, et nous avons dû créer le multi-stage par nous-mêmes. Ensuite, nous avons eu plein de questions concernant le nettoyage des images. Tous ceux qui font du CI/CD se heurtent tôt ou tard au problème de la multitude d'images construites, nécessitant de trouver un moyen de nettoyer ce qui n'est pas nécessaire et de conserver ce qui l'est.

La deuxième raison est le déploiement. Oui, il y a Helm, mais il ne résout qu'une partie des tâches. C'est drôle à dire, mais il est écrit que « Helm est le gestionnaire de paquets pour Kubernetes ». Exactement, « le ». Et il y a aussi les mots « gestionnaire de paquets » - quelles attentes avons-nous généralement d'un gestionnaire de paquets ? Nous disons : « Gestionnaire de paquets - installe le paquet ! » et nous nous attendons à ce qu'il nous dise : « Paquet installé ».

C'est intéressant, parce que nous disons : « Helm, installe le paquet », et quand il répond qu'il a installé, il s'avère qu'il a seulement commencé l'installation - il a indiqué à Kubernetes : « Lance ce truc-là ! », mais qu'il ait effectivement démarré ou non, qu'il fonctionne ou non, Helm ne répond absolument pas à cette question.

En gros, Helm n'est qu'un préprocesseur de texte qui charge des données dans Kubernetes.

Mais dans le cadre de tout déploiement, nous voulons savoir - l'application a-t-elle été mise en production ou non ? Mise en production signifie que l'application a été déployée, la nouvelle version a été déployée, et elle ne tombe pas et répond correctement. Helm ne résout pas cette tâche. Pour le faire, il faut investir beaucoup d'efforts, car il est nécessaire de donner à Kubernetes le commandement de déployer et de suivre ce qui se passe - a-t-il été déployé, a-t-il été mis en production ? Et il y a encore beaucoup de tâches liées au déploiement, au nettoyage, à la construction.

Plans

Cette année, nous allons nous lancer dans le développement local. Nous souhaitons arriver à l'état où, comme auparavant avec Vagrant, il suffisait de taper « vagrant up » pour déployer des machines virtuelles. Nous désirons atteindre un point où il y a un projet sur Git, et où en écrivant « werf up », il lève 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. En fonction du langage de développement, cela s'effectue de différentes manières, mais néanmoins, il doit être possible de mener des développements locaux confortablement avec des fichiers montés.

La prochaine étape pour nous est de fortement investir dans le confort des développeurs. Avec un seul outil, déployer rapidement un projet localement, le développer, le pousser vers Git, et il sera déployé de la même manière sur stage ou pour les tests, selon les pipelines, puis même outil pour passer en production. Cette unité, cette unification, la reproductibilité de l'infrastructure de l'environnement local à la production est un point très important pour nous. Mais cela n'existe pas encore dans werf, 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 par des détours - en inventant des solutions pour nous-mêmes sur shell, sur n'importe quoi. Ensuite, nous essayions de redresser ces détours, de les généraliser et de les consolider dans des binaires que nous partageons simplement.

Il y a aussi une autre perspective sur toute cette histoire, avec des analogies.

Kubernetes est le châssis d'une voiture avec un moteur. Il n'y a pas de portes, de vitres, de récepteur radio, de sapin de Noël - il n'y a rien. Juste le cadre et le moteur. Et il y a Helm - c'est le volant. C'est super - il y a le volant, mais il nous faut aussi un axe de direction, une crémaillère, une boîte de vitesses et des roues, sinon cela ne fonctionne pas.

Dans le cas de werf, c'est encore un autre composant pour Kubernetes. Actuellement, notre version alpha de werf intègre d'ailleurs Helm directement, car nous en avions assez de le faire nous-mêmes. Il y a de nombreuses raisons de procéder ainsi, et je vais parler en détail des raisons pour lesquelles nous avons compilé Helm entièrement avec Tiller à l'intérieur de werf lors de ma présentation au RIT++.

Maintenant, werf est un composant plus intégré. Nous avons un volant prêt, un axe de direction – je ne suis pas très expert en voitures, mais c'est un gros bloc qui résout déjà un large éventail de tâches. Nous n'avons pas besoin de fouiller dans le catalogue, de sélectionner une pièce pour l'autre, de nous demander comment les assembler. Nous avons un combine prêt qui résout immédiatement un grand nombre de problèmes. Mais à l'intérieur, il est construit à partir des mêmes composants open source, utilise toujours Docker pour la construction, Helm pour une partie des fonctionnalités, et il y a encore quelques autres bibliothèques. C'est un outil intégré pour obtenir rapidement et facilement un CI/CD génial prêt à l'emploi.

Est-il difficile de maintenir Kubernetes?

— Tu parles de l'expérience que vous avez commencée à utiliser Kubernetes, c'est pour vous un cadre, un moteur, et qu'il y a beaucoup de choses différentes que l'on peut y ajouter : la carrosserie, le volant, l'assemblage des pédales, des sièges. La question se pose : à quel point la maintenance de Kubernetes est-elle difficile pour vous ? Vous avez une vaste expérience, combien de temps et de ressources consacrez-vous à la maintenance de Kubernetes indépendamment de tout le reste ?

Dmitry: C'est une question très complexe et pour y répondre, il faut comprendre ce qu'est la maintenance et ce que nous voulons de Kubernetes. Peux-tu développer?

— À ma connaissance et comme je le vois, beaucoup d'équipes souhaitent maintenant essayer Kubernetes. Tout le monde s'y met, l'installe à la va-vite. J'ai l'impression que les gens ne comprennent pas toujours la complexité de ce système.

Dmitry: C'est exact.

— À quel point est-il difficile de prendre Kubernetes et de l'installer à partir de rien pour qu'il soit prêt pour la production ?

Dmitry: Que penses-tu de la difficulté de transplanter un cœur ? Je comprends que la question soit délicate. Manipuler un scalp et ne pas se tromper n'est pas si compliqué. Si on te dit où couper et où suturer, alors la procédure elle-même n'est pas complexe. Ce qui est difficile, c'est de garantir à chaque fois que ça réussira.

Installer Kubernetes et le faire fonctionner est facile : pouf ! – ça s'installe, il y a plein de manières d'installation. Mais que se passera-t-il lorsque des problèmes surgiront?

Des questions se posent toujours – qu'avons-nous encore négligé ? Qu'avons-nous encore oublié de faire ? Quels paramètres du noyau Linux avons-nous mal spécifiés ? Mon Dieu, les avons-nous même spécifiés ? Quels composants Kubernetes avons-nous installés et lesquels n'avons-nous pas ? Des milliers de questions surgissent, et pour y répondre, il faut 15 à 20 ans d'expérience dans cette industrie.

J'ai un nouvel exemple sur ce sujet qui peut illustrer la problématique « Est-il difficile de maintenir Kubernetes ? ». Il n'y a pas longtemps, nous avons sérieusement envisagé d'implémenter Cilium comme solution réseau dans Kubernetes.

Permettez-moi de vous expliquer ce qu'est Cilium. Dans Kubernetes, il existe de nombreuses implémentations de sous-systèmes réseau, et l'une d'entre elles est particulièrement impressionnante : Cilium. Quelle en est la raison ? Il y a quelque temps, une possibilité d'écrire des hooks pour le noyau a été introduite, permettant de s'immiscer dans le sous-système réseau et divers autres sous-systèmes, contournant ainsi des parties importantes du noyau.

Historiquement, le noyau Linux comporte des composants anciens tels que ip rout, netfilter et des ponts, qui ont tous environ 15, 20 ou 30 ans. Dans l'ensemble, cela fonctionne bien, mais aujourd'hui, avec l'essor des conteneurs, cela ressemble à une tour de 15 briques empilées, et vous tenez en équilibre dessus sur une jambe — une sensation étrange. Ce système a évolué historiquement avec de nombreuses nuances, un peu comme l'appendice dans le corps. Dans certaines situations, il existe des problèmes de performance, par exemple.

Il existe un excellent BPF et la possibilité d'écrire des hooks pour le noyau — l'équipe a créé ses propres hooks pour le noyau. Lorsqu'un paquet arrive dans le noyau Linux, ils l'extraient dès l'entrée, le traitent comme il se doit sans ponts, sans TCP, sans pile IP — en gros, en contournant tout ce qui est écrit dans le noyau Linux, et le recrache immédiatement dans le conteneur.

Quel a été le résultat ? Une performance incroyable, des fonctionnalités impressionnantes — c'est tout simplement génial ! Mais nous observons cela et nous voyons que sur chaque machine, il y a un programme qui se connecte à l'API Kubernetes et, en se basant sur les données reçues de cette API, génère du code C et compile des binaires qui sont chargés dans le noyau, afin que ces hooks fonctionnent en espace noyau.

Que se passera-t-il si quelque chose ne fonctionne pas ? Nous ne le savons pas. Pour le comprendre, il faudrait lire tout ce code et saisir toute la logique, ce qui est extrêmement complexe. D'un autre côté, il y a ces ponts, ces netfilters, ip rout — je n'ai pas lu leurs sources non plus, et 40 ingénieurs de notre entreprise ne l'ont pas fait non plus. Peut-être que seuls quelques-uns comprennent certaines parties.

Et quelle différence ? Il s'avère qu'il y a un routage IP, un noyau Linux, et un nouvel outil - quelle importance, nous ne comprenons ni l'un ni l'autre. Mais nous avons peur d'utiliser le nouveau - pourquoi ? Parce que si l'outil a 30 ans, alors pendant 30 ans tous les bugs ont été trouvés, toutes les erreurs ont été rencontrées et il n'est pas nécessaire de tout connaître - ça fonctionne comme une boîte noire, et ça fonctionne toujours. Tout le monde sait où mettre quel tournevis de diagnostic, à quel moment lancer quel tcpdump. 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 est construit, mais comment l'utiliser.

Mais le Cilium super génial n'a pas 30 ans, il n'est pas encore éprouvé. Il en est de même pour Kubernetes, tout est une copie. Que Cilium s'installe parfaitement, que Kubernetes s'installe parfaitement, mais quand quelque chose ne se passe pas bien en production, êtes-vous capables de comprendre rapidement ce qui ne va pas dans une situation critique ?

Quand nous parlons de la difficulté de maintenir Kubernetes - non, c'est très simple, et oui, c'est incroyablement compliqué. Kubernetes fonctionne très bien tout seul, mais avec un milliard de nuances.

À propos de l'approche « J'aurai de la chance »

— Y a-t-il des entreprises où ces nuances vont presque inévitablement apparaître ? Supposons que Yandex décide subitement de migrer tous ses services vers Kubernetes, il y aura une énorme charge.

Dmitry: Non, ce n'est pas une discussion sur la charge, mais sur des choses simples. Par exemple, nous avons Kubernetes, nous avons déployé une application dessus. Comment savoir si ça fonctionne ? Il n'y a tout simplement pas d'outil prêt à l'emploi pour savoir si l'application ne tombe pas. Il n'y a pas de système prêt qui envoie des alertes - il faut configurer ces alertes et chaque graphique. Et nous mettons à jour Kubernetes.

Nous avons Ubuntu 16.04. On peut dire que c'est une version ancienne, mais nous y sommes encore, car c'est une LTS. Elle utilise systemd, dont le détail est qu'il ne nettoie pas les cgroups. Kubernetes lance des pods, crée des cgroups, puis supprime les pods, et d'une certaine manière, je ne me souviens pas des détails, pardonnez-moi, cela laisse des fragments de systemd. Cela entraîne le ralentissement progressif de n'importe quelle machine. Ce n'est même pas une question de haute charge. Si des pods permanents sont lancés, par exemple, s'il y a un Cron Job qui génère continuellement des pods, alors une machine avec Ubuntu 16.04 commencera à ralentir après une semaine. Il y aura constamment une charge moyenne élevée en raison de la création de nombreux cgroups. C'est un problème rencontré par quiconque installe simplement Ubuntu 16 et Kubernetes au-dessus.

Admettons qu'il mette à jour systemd ou autre chose, mais dans le noyau Linux jusqu'à 4.16, c'est encore plus drôle — lors de la suppression des cgroups, ils fuyent dans le noyau et ne sont en fait pas supprimés. Donc, après un mois d'utilisation de cette machine, il sera impossible de consulter les statistiques de mémoire pour les pods. Nous récupérons un fichier, le traitons dans le programme, et un fichier met 15 secondes à être traité parce que le noyau met beaucoup de temps à faire le calcul à l'intérieur avec un million de cgroups qui semblent supprimer, mais non — ils fuient.

Il y a encore beaucoup de petites choses ici et là. Ce n'est pas une question à laquelle les grandes entreprises peuvent parfois faire face lors de charges très élevées — non, c'est une question de choses quotidiennes. Les gens peuvent vivre ainsi pendant des mois — ils ont installé Kubernetes, déployé une application — ça semble fonctionner. Pour beaucoup, c'est normal. Quant au fait que cette application risque de s'arrêter un jour pour une raison quelconque, ils ne le sauront même pas, pas d'alerte, mais pour eux, c'est normal. Ils vivaient avant sur des machines virtuelles sans surveillance, maintenant, ils ont migré vers Kubernetes aussi sans surveillance — quelle différence ?

La question est que lorsque nous marchons sur la glace, nous ne connaissons jamais son épaisseur, sauf si nous l'avons mesurée au préalable. Beaucoup de gens marchent et ne s'en préoccupent pas, car ils marchaient déjà avant.

À mon avis, le détail et la complexité de l'exploitation de tout système résident dans la garantie que l'épaisseur de la glace est suffisamment solide pour résoudre nos tâches. C'est de cela qu'il s'agit.

Dans le secteur informatique, il me semble qu'il y a trop d'approches « J'ai de la chance ». Beaucoup installent des logiciels, utilisent des bibliothèques dans l'espoir d'avoir de la chance. En général, beaucoup réussissent. Peut-être que c'est pour cela que ça fonctionne.

— D'après ma vision pessimiste, cela ressemble à ceci : quand les risques sont élevés et que l'application doit fonctionner, il faut un soutien de Flant, peut-être de Red Hat, ou alors une équipe interne dédiée spécifiquement à Kubernetes, prête à le maintenir.

Dmitry: Objectivement, c'est le cas. S'engager soi-même dans l'univers de Kubernetes pour une petite équipe comporte un certain nombre de risques.

Avons-nous besoin de conteneurs?

— Peux-tu me dire à quel point Kubernetes est répandu en Russie ?

Dmitry: Je n'ai pas ces données, et je ne suis pas sûr qu'elles soient disponibles chez qui que ce soit. Nous parlons de « Kubernetes, Kubernetes », mais il existe une autre perspective sur cette question. Je ne sais pas non plus à quel point les conteneurs sont répandus, mais je sais qu'environ 70 % des conteneurs sont orchestrés par Kubernetes, selon une source fiable issue d'un assez large échantillon mondial.

Ensuite, une autre question : avons-nous besoin de conteneurs ? J'ai personnellement le sentiment, et la position générale de l'entreprise Flant est que Kubernetes est devenu le standard de facto.

Rien d'autre que Kubernetes ne sera utilisé.

C'est un véritable bouleversement dans la gestion de l'infrastructure. Absolument, plus de Ansible, Chef, de machines virtuelles, Terraform. Je ne parle même pas des anciennes méthodes obsolètes. Kubernetes est vraiment un changeur de jeu., et maintenant ce sera toujours comme ça.

Il est évident que certains auront besoin de quelques années, d'autres de plusieurs dizaines d'années pour en prendre conscience. Je ne doute pas qu'il n'y aura rien d'autre que Kubernetes et cette nouvelle perspective : nous ne compromettons plus le système d'exploitation, mais utilisons l'infrastructure en tant que code, mais pas avec du code, avec du yml – une infrastructure décrite de manière déclarative. J'ai l'impression que ça sera toujours le cas.

— Donc, les entreprises qui ne sont pas encore passées à Kubernetes y passeront nécessairement ou resteront dans l'oubli. Ai-je bien compris ?

Dmitry: Ce n'est pas tout à fait exact non plus. Par exemple, si nous avons pour tâche de lancer un serveur DNS, nous pouvons le faire sur FreeBSD 4.10 et il peut fonctionner parfaitement pendant 20 ans. Juste fonctionner, c'est tout. Peut-être qu'après 20 ans, il faudra mettre à jour quelque chose une seule fois. Si nous parlons de logiciels qui, au format, que nous lançons et qui fonctionnent réellement pendant des années sans mises à jour ni modifications, alors, bien sûr, il n'y aura pas Kubernetes. Ce n'est pas nécessaire là-bas.

Tout ce qui concerne le CI/CD — partout où une livraison continue est nécessaire, où des mises à jour de versions sont requises, où des modifications actives doivent être effectuées, partout où il est nécessaire de construire une résistance aux pannes — seulement Kubernetes.

Concernant les microservices

— Ici, j'éprouve un léger dissonance. Pour travailler avec Kubernetes, un support externe ou interne est nécessaire — 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 sous Kubernetes ou sous une architecture de microservices peut être difficile et pas toujours justifié économiquement. J'aimerais connaître ton avis — est-il nécessaire pour les startups de commencer à écrire sous Kubernetes immédiatement ou peut-on écrire un monolithe d'abord, puis seulement passer à Kubernetes ?

Dmitry: Bonne question. J'ai une présentation sur les microservices « Microservices : la taille a son importance ». J'ai souvent été confronté à des gens qui essaient de taper des clous avec un microscope. L'approche en soi est correcte, nous concevons aussi notre logiciel interne de cette manière. Mais quand on le fait, il faut bien comprendre ce qu'on fait. Ce que je déteste le plus dans les microservices, c'est le mot « micro ». Historiquement, ce terme est apparu, et pour une raison quelconque, les gens pensent que micro signifie très petit, moins d'un millimètre, comme un micromètre. Ce n'est pas le cas.

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 et qu'il doit être découpé en morceaux — environ 10, que chaque groupe de 30 personnes écrit au minimum. C'est important, nécessaire et génial. Mais quand un startup arrive où 3 très bons et talentueux gars ont écrit sur le pouce 60 microservices, je cherche toujours du 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. C'est économiquement injustifiable, très compliqué dans l'ensemble. Je l'ai simplement vu tellement de fois que ça me fait mal, c'est pourquoi je continue à en parler.

En ce qui concerne la question initiale, il existe un conflit entre le fait que, d'un côté, Kubernetes est terriblement difficile à utiliser car il est impossible de savoir ce qui pourrait casser ou ne pas fonctionner, et de l'autre côté, il est clair que tout va vers là et qu'il n'y aura rien d'autre que Kubernetes. La réponse est - évaluer le volume de bénéfices que vous pouvez obtenir, le volume de tâches que vous pouvez résoudre.. C'est d'un côté de la balance. De l'autre côté se trouvent les risques liés aux temps d'arrêt ou à la baisse du temps de réponse, du niveau de disponibilité - à la baisse des indicateurs de performance.

C'est comme ça - soit nous avançons rapidement, et Kubernetes permet de réaliser de nombreuses choses beaucoup plus vite et mieux, soit nous utilisons des solutions fiables et éprouvées, mais avançons beaucoup plus lentement. Ce choix doit être fait par chaque entreprise. On peut voir cela comme un chemin dans la jungle - lorsque vous y allez pour la première fois, vous pouvez rencontrer un serpent, un tigre ou un blaireau fou, mais après y être allé 10 fois - vous avez tracé un chemin, enlevé les branches et c'est plus facile d'y aller. Chaque fois, le sentier s'élargit. Ensuite, cela devient une route pavée, puis plus tard un joli boulevard.

Kubernetes ne reste pas sur ses lauriers. Encore une fois la question : Kubernetes, d'un côté, c'est 4-5 binaires, et de l'autre, c'est tout un écosystème. C'est le système d'exploitation qui se trouve sur nos machines. De quoi s'agit-il ? Ubuntu ou Curios ? C'est un noyau Linux, plein de composants supplémentaires. Toutes ces choses ici ont retiré un serpent venimeux de la route, là ils ont installé une clôture. Kubernetes évolue très rapidement et dynamiquement, et le volume des risques, le volume de l'inconnu diminue chaque mois, et par conséquent, ces balances se rééquilibrent.

En répondant à la question sur ce que doit faire une startup, je dirais : venez chez «Flant», payez 150 000 roubles et obtenez un service DevOps clé en main. 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 tout en prenant un salaire, vous obtiendrez une solution clé en main à toutes vos questions. Oui, il y a certains inconvénients. Nous, en tant qu'experts externes, ne pouvons pas être aussi impliqués et réagir rapidement aux changements. Mais nous avons une multitude d'expertises et de bonnes pratiques. Nous garantissons qu'à tout moment, nous saurons résoudre rapidement n'importe quel problème et faire revivre n'importe quel Kubernetes.

Je recommande catégoriquement l'externalisation aux startups et aux entreprises établies jusqu'à ce que vous puissiez affecter une équipe de 10 personnes à l'exploitation, sinon ça n'a pas de sens. C'est absolument logique d'externaliser.

À propos d'Amazon et de Google

— Peut-on considérer l'hébergement proposé par Amazon ou Google comme une externalisation ?

Dmitry: Oui, bien sûr, cela résout plusieurs problèmes. Mais encore une fois, il y a des nuances. Il faut quand même comprendre comment l'utiliser. Par exemple, il y a mille détails dans le fonctionnement d'Amazon AWS : il faut préchauffer le Load Balancer ou faire une demande à l'avance en disant « les gars, nous allons avoir du trafic, préchauffez notre Load Balancer ! » Ces nuances, il faut les connaître.

Lorsque vous faites appel à des personnes spécialisées dans ce domaine, vous obtenez presque toutes les choses standardisées résolues. Nous avons actuellement 40 ingénieurs, et d'ici la fin de l'année, il y en aura probablement 60 — nous avons déjà rencontré tous ces problèmes. Même si nous sommes confrontés à ce problème sur un projet, nous pouvons rapidement demander à l'un ou l'autre et savons comment résoudre.

Probablement, la réponse est la suivante : bien sûr, l'histoire hébergée allège une partie des soucis. La question est de savoir si vous êtes prêts à faire confiance à ces hébergeurs et s'ils résoudront vos problèmes. Amazon et Google ont bien fait leurs preuves. Pour tous nos cas, c'est certain. Nous n'avons pas d'autres expériences positives. Tous les autres clouds avec lesquels nous avons essayé de travailler posent beaucoup de problèmes — que ce soit Ager ou tout ce qui existe en Russie, et toutes sortes de déploiements OpenStack : Headster, Overage — tout ce que vous voulez. Ils engendrent tous des problèmes que nous préférons ne pas avoir à résoudre.

Donc, la réponse est oui, mais en réalité, il n'existe pas beaucoup de solutions hébergées matures.

À qui Kubernetes est-il destiné ?

— Mais finalement, à qui Kubernetes est-il destiné ? Qui doit déjà passer à Kubernetes, qui est le client typique de « Flant » qui vient justement pour Kubernetes ?

Dmitry: C'est une question intéressante, car en ce moment, beaucoup de gens viennent vers nous sur la vague de Kubernetes : « Les gars, nous savons que vous faites Kubernetes, faites-le pour nous ! ». Nous leur répondons : « Messieurs, nous ne faisons pas Kubernetes, nous faisons de la production et tout ce qui y est lié ». Parce que faire de la production sans avoir mis en place tout le CI/CD et toute cette histoire est tout simplement impossible aujourd'hui. Tout le monde a abandonné la séparation entre le développement d'un côté et l'exploitation de l'autre.

Nos clients ont des attentes diverses, mais tous espèrent un certain miracle, que leurs problèmes divers se résoudront avec Kubernetes. Les gens croient aux miracles. Ils comprennent intellectuellement qu'il n'y aura pas de miracle, mais ils espèrent de tout cœur — et si Kubernetes résolvait tout pour nous, on en parle tant ! Peut-être qu'il va tout résoudre, bing ! — et voilà, 100 % de disponibilité, tous les développeurs peuvent déployer à peu près n'importe quoi sur la production 50 fois sans que ça tombe. En somme, un miracle !

Quand ces gens viennent vers nous, nous leur disons : « Désolé, mais il n'y a pas de miracle ». Pour être en bonne santé, il faut bien manger et faire du sport. Pour avoir une production fiable, il faut la rendre fiable. Pour avoir un CI/CD pratique, il faut le mettre en place. C'est beaucoup de travail qui doit être fait.

En répondant à la question de savoir à qui Kubernetes est destiné — Kubernetes n'est utile à personne.

Certaines personnes ont une idée fausse qu'elles ont besoin de Kubernetes. Les gens ont besoin de ne plus penser, se préoccuper ou s'intéresser à tous les problèmes d'infrastructure et au déploiement de leurs applications. Ils veulent que leurs applications fonctionnent simplement et se déploient facilement. Pour eux, Kubernetes est un espoir de ne plus entendre des histoires comme « on traîne » ou « on ne peut pas déployer », ou autre.

Généralement, c'est le directeur technique qui vient vers nous. De lui, on demande deux choses : d'une part, des fonctionnalités, d'autre part — la stabilité. Nous proposons de prendre cela en charge et de le faire. Une solution miracle, ou plutôt une solution altérée, c'est que vous cessez de penser à ces problèmes et de perdre du temps. Vous aurez des personnes spécialisées pour s'occuper de ces questions.

La formulation selon laquelle nous avons besoin de Kubernetes ou que quelqu'un en a besoin est incorrecte.

Kubernetes est très utile pour les administrateurs, car c'est un outil fascinant avec lequel on peut expérimenter et jouer. Soyons honnêtes, tout le monde aime les jouets. Nous avons tous un côté enfant, et quand nous voyons quelque chose de nouveau, nous voulons y jouer. Pour certains, cet enthousiasme a été émoussé, par exemple en administration, parce qu'ils ont déjà beaucoup joué et que cela ne les passionne plus au point d'en perdre l'envie. Pourtant, personne n'a complètement perdu cet intérêt. Par exemple, même si j'en ai assez des jouets liés à l'administration système et au DevOps, j'aime toujours les nouveautés et j'en achète encore quelques-unes.

Il ne faut pas jouer avec la production. Ce que je ne recommande catégoriquement pas de faire, et ce que je constate massivement en ce moment : « Oh, un nouveau jouet ! » – on se précipite pour l'acheter, on l'achète et : « Prenons-le à l'école, montrons-le à tous nos amis ». Ne faites pas ça. Je m'excuse, mes enfants grandissent et je vois constamment des choses chez eux, je le remarque en moi et ensuite je le généralise aux autres.

La réponse définitive : vous n'avez pas besoin de Kubernetes. Vous devez résoudre vos problèmes.

Il est possible d'atteindre ce qui suit :

• la production ne tombe pas ;
• même si elle essaie de tomber, nous en sommes informés à l'avance et nous pouvons prendre des mesures ;
• nous pouvons la modifier à la vitesse requise par nos affaires, et ce de manière confortable, cela ne nous pose pas de problèmes.

Les réelles nécessités sont deux : la fiabilité et la dynamique / flexibilité des déploiements. Tous ceux qui réalisent actuellement des projets IT, peu importe le secteur d'activité – des logiciels pour simplifier le monde, et qui comprennent cela, doivent répondre à ces besoins. Kubernetes, avec la bonne approche, une bonne compréhension et une expérience suffisante, permet de les satisfaire.

À propos de serverless

– Si l'on regarde un peu plus loin dans le futur, en essayant de résoudre le problème des maux de tête liés à l'infrastructure, à la vitesse de déploiement et à la rapidité d'évolution des applications, de nouvelles solutions apparaissent, comme le serverless. Ressens-tu un certain potentiel dans cette direction et, disons, un danger pour Kubernetes et des solutions similaires ?

Dmitry: Il faut encore faire une remarque ici, je ne suis pas un voyant qui regarde vers l'avenir et dit - cela se passera comme ça ! Bien que je viens juste de faire la même chose. Je regarde sous mes pieds et je vois un tas de problèmes, par exemple, comment fonctionnent les transistors dans un ordinateur. C'est presque risible, n'est-ce pas ? Nous rencontrons certains bugs dans le CPU.

Rendre le serverless suffisamment fiable, bon marché, efficace et pratique, tout en résolvant toutes les questions écologiques. Je suis d'accord avec Elon Musk qu'il nous faut une deuxième planète pour assurer la résilience de l'humanité. Bien que je ne sache pas exactement ce qu'il dit, je comprends que je ne suis pas prêt à aller moi-même sur Mars et que cela ne sera pas pour demain.

Avec le serverless, c'est clair que c'est quelque chose d'idéologiquement correct, tout comme la résilience pour l'humanité - avoir deux planètes est mieux qu'une. Mais comment y parvenir maintenant ? Envoyer une expédition - pas de problème, si on concentre les efforts là-dessus. Envoyer plusieurs expéditions et y établir plusieurs milliers de personnes, je pense que c'est aussi réaliste. Mais réaliser une résilience complète, pour que la moitié de l'humanité y vive, me semble actuellement impossible, hors de question.

C'est la même chose avec le serverless : c'est un concept génial, mais il est loin des problèmes de 2019. Vers 2030 - vivons d'abord jusque-là. Je ne doute pas que nous y arriverons, nous y arriverons certainement (répétez avant de dormir), mais pour l'instant, il faut s'attaquer à d'autres problèmes. C'est comme croire au poney magique Rainbow. Oui, quelques pourcentages de cas sont résolus, et ils le sont très bien, mais subjectivement, le serverless - c'est un arc-en-ciel… Pour moi, ce sujet est trop éloigné et trop flou. Je ne suis pas prêt à en parler. En 2019, vous ne pouvez pas écrire une seule application en serverless.

Comment Kubernetes va-t-il évoluer ?

— En attendant d'atteindre cet avenir potentiellement merveilleux et lointain, que penses-tu de l'évolution de Kubernetes et de l'écosystème qui l'entoure ?

Dmitry: J'ai beaucoup réfléchi à ce sujet et j'ai une réponse claire. Premièrement, le stateful est en fait plus facile à faire stateless. Kubernetes y a investi beaucoup dès le départ, c'est là que tout a commencé. Le stateless fonctionne pratiquement parfaitement sous Kubernetes, il n'y a simplement rien à redire. Il reste encore beaucoup de problèmes en stateful, ou plutôt, de nuances. Maintenant, tout fonctionne bien pour nous là-bas, mais c'est nous. Pour que cela fonctionne pour tout le monde, il faut encore au moins quelques années. Ce n'est pas un indicateur calculé, c'est juste une impression que j'ai dans la tête.

En gros, le stateful doit vraiment — et va — se développer fortement, car toutes nos applications conservent un état, il n'existe pas d'applications stateless. C'est une illusion, il faut toujours une sorte de base de données et quelque chose d'autre. Le stateful consiste à simplifier tout ce qui peut l'être, à corriger tous les bugs, à améliorer tous les problèmes auxquels nous faisons face actuellement — appelons cela l'adoption.

Le niveau d'inexploré, le niveau des problèmes non résolus, le niveau de probabilité de rencontrer certains problèmes, va fortement diminuer. C'est une histoire importante. Et les opérateurs — tout ce qui concerne la codification de la logique d'administration, la logique de gestion, afin d'obtenir un service facile : service MySQL facile, service RabbitMQ facile, service Memcache facile — en fait, tous ces composants dont nous avons besoin pour garantir le bon fonctionnement dès la sortie de la boîte. Cela répond précisément aux douleurs 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 dans une forme ou une autre sera importante dans les prochaines années.

Je pense que la simplicité d'exploitation devrait considérablement augmenter — la boîte deviendra de plus en plus noire, de plus en plus fiable, avec des réglages de plus en plus simples.

J'ai écouté une vieille interview d'Isaac Asimov des années 80 sur YouTube dans l'émission Saturday Night Live — un type de programme comme Urgant, mais intéressant. On lui a demandé ce qu'il pensait de l'avenir des ordinateurs. Il a dit que l'avenir était dans la simplicité, comme cela l'était avec le récepteur radio. Initialement, le récepteur radio était une chose complexe. Pour capter une onde, il fallait tourner les boutons pendant 15 minutes, manœuvrer, et en fait savoir comment tout cela fonctionnait, comprendre la physique de la transmission des ondes radio. Au final, il ne reste qu'un seul bouton sur la radio.

Quelle est la radio en 2019 ? Dans la voiture, le récepteur radio capte toutes les ondes et les noms des stations. La physique du processus n'a pas changé en 100 ans, ce qui a changé, c'est la simplicité d'utilisation. Actuellement, et pas seulement maintenant, déjà en 1980, lors d'une interview avec Asimov, tout le monde utilisait la radio sans se soucier de son fonctionnement. Cela a toujours fonctionné — c'est un fait.

Asimov a alors dit que cela serait similaire avec les ordinateurs — la simplicité d'utilisation augmentera. Si en 1980, il fallait une formation spéciale pour appuyer sur les touches d'un ordinateur, à l'avenir, ce ne sera plus le cas.

J'ai l'impression qu'avec Kubernetes et l'infrastructure, la simplicité d'utilisation va également augmenter considérablement. C'est, à mon avis, évident — c'est manifeste.

Que faire avec les ingénieurs ?

— Que va-t-il advenir des ingénieurs, des administrateurs systèmes qui maintiennent Kubernetes ?

Dmitry: Qu'est-il arrivé aux comptables après l'apparition de 1C ? À peu près la même chose. Avant, on faisait des calculs sur papier — maintenant, c'est dans un programme. La productivité a augmenté de manière exponentielle, mais le travail lui-même n'a pas disparu. Autrefois, il fallait 10 ingénieurs pour visser une ampoule, maintenant il suffit d'un seul.

Le nombre de logiciels et le nombre de tâches, il me semble, augmente actuellement à une vitesse plus rapide que n'apparaissent de nouveaux DevOps et que l'efficacité augmente. Il y a une pénurie spécifique sur le marché et elle va durer longtemps. Plus tard, tout reviendra à une certaine norme, à laquelle l'efficacité du travail augmentera, il y aura de plus en plus de solutions serverless, et Kubernetes sera connecté à un réseau neuronal qui choisira toutes les ressources exactement comme il le faut, et tout fera tout seul, comme il se doit — l'homme, recule et ne dérange pas.

Mais, de toute façon, il faudra que quelqu'un prenne des décisions. Il est clair que le niveau de qualification et de spécialisation de cette personne sera plus élevé. Actuellement, dans le département de comptabilité, vous n'avez pas besoin de 10 employés qui tiennent les livres, pour que leur bras ne se fatigue pas. C'est simplement inutile. De nombreux documents sont automatiquement scannés et reconnus par le système de gestion électronique des documents. Un seul comptable principal intelligent, déjà avec des compétences beaucoup plus avancées et une bonne compréhension, est suffisant.

Dans l'ensemble, ce chemin est commun à tous les secteurs. Avec les voitures, c'est pareil : avant, une voiture venait avec un mécanicien et trois conducteurs. Maintenant, conduire une voiture est un processus simple auquel nous participons tous les jours. Personne ne pense que la voiture est quelque chose de complexe.

Le DevOps ou l'ingénierie système ne disparaîtront pas – le niveau élevé et l'efficacité du travail vont augmenter.

— J'ai également entendu une idée intéressante, selon laquelle en réalité, le travail va également augmenter.

Dmitry: Bien sûr, c'est sûr à cent pour cent ! Parce que le nombre de logiciels que nous écrivons augmente constamment. Le nombre de problèmes que nous résolvons avec des logiciels augmente constamment. Le volume de travail augmente. Actuellement, le marché du DevOps est incroyablement surchauffé. Cela se voit dans les attentes salariales. En toute honnêteté, sans se plonger dans les détails, il devrait y avoir des juniors qui veulent X, des intermédiaires qui veulent 1,5X et des seniors qui veulent 2X. Mais maintenant, si l'on regarde le marché des salaires DevOps à Moscou, un junior veut entre X et 3X et un senior veut entre X et 3X.

Personne ne sait combien ça coûte. Le niveau de salaire est mesuré par ta confiance – c'est un vrai bazar, pour être honnête, un marché extrêmement surchauffé.

Bien sûr, cette situation va changer très bientôt – il doit y avoir un certain équilibre. Avec le développement de logiciels, ce n'est pas aussi simple – même si les développeurs sont très demandés, et que les bons développeurs sont recherchés, le marché sait qui vaut quoi – le secteur s'est stabilisé. Ce n'est pas le cas avec DevOps en ce moment.

— D'après ce que j'ai entendu, je conclue qu'un administrateur système actuel ne doit pas s'inquiéter trop, mais qu'il est temps de développer ses compétences et de se préparer à un avenir où le travail va augmenter, mais sera plus qualifié.

Dmitry: C'est sûr à cent pour cent. En général, nous vivons en 2019 et la règle de vie est la suivante : lifetime learning – nous apprenons toute notre vie. Je pense que tout le monde le sait et le ressent déjà, mais il ne suffit pas de savoir – il faut agir. Chaque jour, nous devons changer. Si nous ne le faisons pas, tôt ou tard, nous serons laissés au bord de la profession.

Soyez prêt à des changements brusques de 180 degrés. Je ne exclue pas des situations où quelque chose changera radicalement, des nouveautés seront inventées - cela arrive. Hop ! - et nous agissons désormais différemment. Il est important d'être prêt pour cela et de ne pas s'en faire. Il se peut qu'il arrive que demain tout ce que je fais devienne inutile - peu importe, j'ai appris toute ma vie et je suis prêt à apprendre autre chose. Ce n'est pas un problème. Il ne faut pas avoir peur de la sécurité de l'emploi, mais il faut être prêt à apprendre constamment de nouvelles choses.

Souhaits et petite publicité

— As-tu un souhait ?

Dmitry: Oui, j'ai quelques souhaits.

Le premier et mercantile - abonnez-vous à YouTube. Chers lecteurs, allez sur YouTube et abonnez-vous à notre chaîne. Dans environ un mois, nous commencerons une expansion active sur la plateforme vidéo, et nous aurons plein de contenu éducatif sur Kubernetes, ouvert et varié : des choses pratiques, même des laboratoires, jusqu'à des principes théoriques profonds et comment appliquer Kubernetes au niveau des principes et des patterns.

Le deuxième souhait mercantile - allez sur GitHub et mettez des étoiles car nous en avons besoin. Si vous ne nous mettez pas d'étoiles, nous n'aurons rien à manger. C'est comme de la manne dans un jeu vidéo. Nous faisons des choses, nous travaillons dur, certains disent que ce sont de terribles vieilles histoires, d'autres que tout est injuste, mais nous continuons et agissons en toute honnêteté. Nous voyons un problème, nous le résolvons et partageons notre expérience. Donc, mettez-nous une étoile, cela ne vous coûtera rien, mais cela nous profitera, car nous en avons besoin.

Troisième souhait, important, et déjà non mercantile - cessez de croire aux contes de fées. Vous êtes des professionnels. DevOps est une profession très sérieuse et responsable. Cessez de jouer au travail. Que cela vous choque, et vous comprendrez cela. Imaginez que vous arrivez dans un hôpital, et là un médecin fait des expériences sur vous. Je comprends que cela peut blesser certains, mais c'est probablement à propos de quelqu'un d'autre. Dites aux autres de cesser également. Cela nuit vraiment à notre vie à tous - beaucoup commencent à traiter les opérations, les administrateurs et les DevOps comme des gars qui ont encore cassé quelque chose. Ce "cassé" est le plus souvent dû au fait que nous sommes allés jouer plutôt que d'observer calmement que cela fonctionnait ainsi et que cela fonctionnait ainsi.

Cela ne signifie pas qu'il ne faut pas expérimenter. Il faut expérimenter, c'est ce que nous faisons nous-mêmes. Pour être honnête, nous jouons parfois aussi — c'est bien sûr très mal, mais rien de ce qui est humain ne nous est étranger. Déclarons 2019 l'année des expériences sérieuses et réfléchies, et non des jeux en production. Peut-être que ce sera ainsi.

— Merci beaucoup !

Dmitry: Merci à toi, Vitaly, pour le temps et pour l'interview. Chers lecteurs, un grand merci à vous si vous êtes arrivés jusqu'à ce moment. J'espère que nous vous avons apporté au moins quelques réflexions.

Dans l'interview, Dmitry a abordé la question de werf. C'est actuellement un outil polyvalent qui résout presque tous les problèmes. Mais cela n'a pas toujours été le cas. Au DevOpsConf  festival RIT++ Dmitry Stolyarov expliquera cet outil en détail. Dans son intervention «werf — notre outil pour CI/CD dans Kubernetes» tout sera là : les problèmes et les nuances cachées de Kubernetes, les options de solutions à ces difficultés et la mise en œuvre actuelle de werf en détail. Rejoignez-nous les 27 et 28 mai, nous allons créer des outils parfaits.

Source : habr.com