Kubernetes prendra le contrôle du monde. Quand et comment?

En prévision de DevOpsConf, Vitaliy Khabarov a interviewé Dmitry Stolyarov ( distol ), directeur technique et co-fondateur de Flant. Vitaly a demandé à Dmitry ce que faisait Flant, Kubernetes, le développement de l'écosystème, le soutien. Nous avons discuté de la raison pour laquelle Kubernetes est nécessaire et s'il est nécessaire. Et aussi sur les microservices, Amazon AWS, l'approche «I'm Lucky» dans DevOps, l'avenir de Kubernetes lui-même, pourquoi, quand et comment il prendra le contrôle du monde, les perspectives de DevOps et ce que les ingénieurs devraient préparer dans un avenir brillant et proche avec la simplification et les réseaux de neurones.

Écoutez l' interview originale sous forme de podcast sur DevOps Deflop, un podcast en russe sur DevOps, et ci-dessous est une version texte.



Ci-après, Vitaliy Khabarov est interrogé par un ingénieur d'Express42.

À propos de Flant

- Dima, salut. Vous êtes le directeur technique de Flant et également son fondateur. Dites-moi, je vous prie, que fait l'entreprise et y êtes-vous?

Dmitry : De l'extérieur, on dirait que nous sommes les gars qui partent, mettent Kubernetes sur tout le monde et font quelque chose avec lui. Mais ce n'est pas le cas. Nous avons commencé comme une entreprise qui s'occupe de Linux, mais pendant très longtemps, notre activité principale était de servir des projets de production et de charge clé en main. Habituellement, nous construisons toute l'infrastructure à partir de zéro, puis nous en sommes responsables pendant longtemps. Par conséquent, le principal travail que Flant effectue, pour lequel il reçoit de l'argent, est de prendre la responsabilité et la mise en œuvre clé en main de la production .


En tant que directeur technique et l'un des fondateurs de l'entreprise, je travaille sans relâche pour réfléchir à des moyens d'augmenter la disponibilité de la production, de simplifier son fonctionnement, de faciliter la vie des administrateurs et de rendre la vie plus agréable pour les développeurs.

À propos de Kubernetes

- La dernière fois de "Flanta", je vois beaucoup de rapports et d' articles sur Kubernetes. Comment êtes-vous venu vers lui?

Dmitry : J'en ai déjà parlé plusieurs fois, mais je ne regrette pas du tout de le répéter. Je pense qu'il est correct de répéter ce sujet, car il y a confusion entre cause et effet.

Nous avions vraiment besoin d'un outil. Nous avons été confrontés à de nombreux problèmes, avons lutté, les avons surmontés avec différentes béquilles et avons ressenti le besoin d'un instrument. Passé en revue de nombreuses options différentes, construit leurs vélos, acquis de l'expérience. Progressivement, 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 béquilles en Python. Avec l'avènement de Docker, les béquilles peuvent être jetées et utilisées par une solution fiable et prise en charge par la communauté.

Avec Kubernetes, l'histoire est similaire. Au moment où il a commencé à prendre de l'ampleur - pour nous, c'est 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 Docker. Nous avons sérieusement envisagé Rancher et diverses autres solutions, mais Kubernetes est alors apparu, dans lequel tout est mis en œuvre exactement comme nous le ferions ou même mieux. Il n'y a rien à redire.

Oui, il y a une sorte d'imperfection, il y a une sorte d'imperfection - il y a beaucoup d'imperfections, et 1.2 est généralement horrible, mais ... Kubernetes est comme un bâtiment en construction - vous regardez le projet et comprenez qu'il sera cool. Si le bâtiment a maintenant une fondation et deux étages, alors vous comprenez qu'il vaut mieux ne pas encore peupler, mais il n'y a pas de tels problèmes avec le logiciel - vous pouvez déjà l'utiliser.

Nous n'avons pas eu le moment où nous pensions utiliser Kubernetes ou non. Nous l'attendions bien avant qu'il n'apparaisse, et nous avons essayé de faire nous-mêmes des analogues.

Près de Kubernetes

- Participez-vous directement au développement de Kubernetes lui-même?

Dmitry : Médiocre. Nous sommes plus susceptibles de participer au développement de l'écosystème. Nous envoyons un certain nombre de demandes de pull: à Prométhée, à toutes sortes d'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 de notre cœur.

- Développez-vous beaucoup de vos outils autour de Kubernetes?

Dmitry : La stratégie est la suivante: nous allons tirer et tirer dans tout ce qui existe déjà. Si les demandes de tirage ne sont pas acceptées là-bas, nous les fourchons simplement pour nous-mêmes et vivons jusqu'à ce qu'elles soient acceptées avec nos versions. Puis, quand il atteint l'amont, nous revenons à la version amont.

Par exemple, nous avons probablement déjà un opérateur Prometheus avec lequel nous sommes passés 5 fois en amont et en aval de notre assemblage. 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 en amont. En conséquence, nous collectons pour nous-mêmes, roulons notre assemblage avec notre fonctionnalité, dont nous avons besoin pour une raison quelconque, à tous nos clusters. Ensuite, par exemple, ils nous enveloppent en amont avec les mots: «Les gars, faisons-le pour un cas plus général», nous, ou quelqu'un d'autre, finirons cela, et finalement fusionnerons à nouveau.

Tout ce qui existe, nous essayons de le développer . De nombreux éléments qui ne sont pas encore là n'ont pas encore été inventés ou ont été inventés, mais n'ont pas encore été mis en œuvre - nous le faisons. Et pas parce que nous aimons le processus lui-même ou la construction de vélos en tant qu'industrie, mais simplement parce que nous avons besoin de cet outil. Ils posent souvent la question, pourquoi avons-nous fait telle ou telle chose? La réponse est simple - parce que nous devions aller plus loin, résoudre un problème pratique et nous l'avons résolu avec cet outil.

Le chemin est toujours le suivant: nous regardons très attentivement et, si nous ne trouvons aucune solution, comment faire un trolleybus à partir d'une miche de pain, alors nous faisons notre propre pain et notre propre trolleybus.

Outils Flant

«Je sais que Flant a maintenant des opérateurs d'addon, des opérateurs de shell, des outils dapp / werf. Si je comprends bien, c'est le même outil dans différentes incarnations. Je comprends également qu'il existe de nombreux autres outils dans Flant. En est-il ainsi?

Dmitry : Nous avons encore beaucoup de choses sur GitHub. D'après ce dont je me souviens maintenant, nous avons une carte de statut - un panneau pour Grafana qui est allé à tout le monde. Il est mentionné dans presque tous les deux articles sur la surveillance de Kubernetes sur le support. Il est impossible de décrire brièvement ce qu'est une carte d'état - vous avez besoin d'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 un ClickHouse et une pièce à base de magie noire pour collecter des journaux dans Kubernetes.

De nombreux utilitaires! Et il y en aura encore plus, car un certain nombre de solutions internes seront publiées cette année. Parmi les très grands opérateurs basés sur des addons, il y a un tas d'addons à Kubernetes, mais comment installer le gestionnaire de sert - un outil de gestion de certificat, comment installer Prometheus avec un tas d'esquives - ce sont vingt binaires différents qui exportent des données et collectent quelque chose, pour cela Prométhée est des graphiques et des alertes impressionnants. Tout cela n'est qu'un tas d'addons à Kubernetes qui sont placés dans un cluster, et cela passe de simple à 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 outil et de ses modes d'utilisation. Pouvez-vous approximativement savoir qui d'autre apporterait la même contribution au développement de l'écosystème?

Dmitry : En Russie, aucune de ces sociétés qui opèrent sur notre marché n'est proche . Bien sûr, il s'agit d'une déclaration très médiatisée, car il existe de grands acteurs comme Mail with Yandex - ils font aussi quelque chose avec Kubernetes, mais même ils n'ont pas égalé la contribution des entreprises dans le monde, qui font beaucoup plus que nous. Il est difficile de comparer Flant avec un effectif de 80 personnes et Red Hat, dans lequel il n'y a que 300 ingénieurs Kubernetes, si je ne me trompe pas. C'est difficile à comparer. Nous avons 6 personnes au département RnD, dont moi, qui scions tous nos outils. 6 personnes contre 300 ingénieurs Red Hat - c'est en quelque sorte difficile à comparer.

- Néanmoins, quand même ces 6 personnes peuvent faire quelque chose de vraiment utile et aliéné, quand elles sont confrontées à une tâche pratique et donnent une décision à la communauté - un cas intéressant. Je comprends que dans les grandes entreprises technologiques, où elles ont leur propre développement et leur équipe d'assistance Kubernetes, en principe, les mêmes outils peuvent être développés. C'est un exemple pour eux qui peut être développé et donné à la communauté, pour donner une impulsion à toute la communauté qui utilise Kubernetes.

Dmitry : Il s'agit probablement d'une puce intégratrice, sa caractéristique. 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 les plus courants et de les rendre aussi bon marché que possible pour nous. Nous le faisons activement. C'est difficile pour moi de parler de la Russie et du monde, mais nous avons environ 40 ingénieurs DevOps chez Kubernetes. Je ne pense pas qu'en Russie, il existe de nombreuses entreprises avec un nombre comparable de spécialistes qui comprennent Kubernetes, le cas échéant.

Je comprends tout sur le titre du poste d'ingénieur DevOps, tout le monde comprend tout et a l'habitude d'appeler des ingénieurs DevOps ingénieurs DevOps, nous n'en discuterons pas. Tous ces 40 merveilleux ingénieurs DevOps font face à des problèmes chaque jour et les résolvent, nous analysons simplement cette expérience et essayons de résumer. Nous comprenons que s'il reste avec nous, alors dans un an ou deux, l'outil sera inutile, car quelque part dans la communauté, un outil prêt à l'emploi apparaîtra. Cela n'a aucun sens d'accumuler cette expérience à l'intérieur - c'est juste un drain de temps et d'énergie en dev / null. Et donc nous ne sommes pas du tout désolés. C'est avec grand plaisir que nous publions tout et comprenons qu'il est nécessaire de le publier, de le développer, de le promouvoir, de le promouvoir afin que les gens utilisent et ajoutent leur expérience - alors tout grandit et vit. Puis, après deux ans, l'outil ne passe pas à la poubelle. Ce n'est pas dommage de continuer à verser de l'énergie, 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, semble-t-il, il y a environ 3 ans. Au départ, c'était généralement sur la coquille. C'était une super preuve de concept, nous avons résolu certaines de nos tâches privées - il s'est avéré! Mais il y a des problèmes avec le shell, il est impossible de le construire davantage, la programmation sur le shell est autre chose. Nous avions l'habitude d'écrire en Ruby, respectivement, en Ruby, nous avons refait quelque chose, développé, développé, développé et reposé sur le fait que la communauté, une foule qui ne dit pas "nous voulons ou ne voulons pas", tourne le nez de Ruby, ce n'est pas drôle. Nous avons réalisé que nous devrions écrire tout cela sur Go, juste pour correspondre au premier paragraphe de la liste de contrôle: DevOps-tool devrait être un binaire statique . On Go ou pas Go n'est pas si important, mais un binaire statique écrit en Go est mieux.

A déployé des efforts, réécrit dapp sur Go et l'a nommé werf. Dapp n'est plus pris en charge, ne se développe pas, il fonctionne dans une dernière version, mais il existe un chemin de mise à niveau absolu vers le haut, et vous pouvez le suivre.

Pourquoi Dapp a-t-il été créé?

- Pouvez-vous nous expliquer brièvement pourquoi dapp a été créé, quels problèmes cela résout-il?

Dmitry : La première raison de l'assemblage. Au départ, nous avons eu de gros problèmes de construction lorsque Docker ne savait pas comment effectuer plusieurs étapes, et nous l'avons fait nous-mêmes. Ensuite, nous avons eu un tas de questions avec l'image de nettoyage. Quiconque fait du CI / CD, tôt ou tard, est confronté au problème qu'il y a un tas d'images collectées, vous devez en quelque sorte nettoyer ce qui n'est pas nécessaire et laisser ce qui est nécessaire.

La deuxième raison réside dans le déploiement. Oui, il y a Helm, mais cela ne résout qu'une partie des problèmes. Ironiquement, il est écrit que "Helm - le gestionnaire de paquets pour Kubernetes". A savoir que "le". Il y a aussi les mots «Gestionnaire de packages» - quelle est l'attente habituelle du Gestionnaire de packages? Nous disons: "Gestionnaire de paquets - livrez le colis!" et attendez-lui à ce qu'il nous dise: "Le colis a été livré."

Il est intéressant que nous disions: "Helm, mettez le paquet", et quand il répond qu'il l'a installé, il s'avère qu'il vient de commencer l'installation - Kubernetes a souligné: "Exécutez cette chose!", Que cela ait commencé 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 des données dans Kubernetes.

Mais nous voulons savoir dans le cadre de tout déploiement - l'application a-t-elle été déployée ou non? Le déploiement vers le prod signifie que l'application y est allée, une nouvelle version s'est déployée, et au moins elle ne s'est pas plantée et répond correctement. Helm ne résout pas ce problème. Pour le résoudre, vous devez dépenser beaucoup d'énergie, car vous devez donner à Kubernetes la commande de déployer et de surveiller ce qui s'y passe - s'il s'est retourné, s'il s'est déroulé. Et il y a aussi un tas de tâches liées au déploiement, au nettoyage et à l'assemblage.

Plans

Cette année, nous irons au développement local. Nous voulons arriver à ce qui était auparavant dans Vagrant - nous avons tapé «vagrant up» et nous avons déployé des machines virtuelles. Nous voulons arriver à un tel état qu'il existe un projet dans Git, nous y écrivons «werf up» et il génère 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 de différentes manières, mais néanmoins pour qu'il soit commode d'effectuer le développement local sous les fichiers montés.

La prochaine étape pour nous est d' investir massivement dans la commodité pour les développeurs . Afin de déployer rapidement un projet localement, avec un seul outil, pour terminer, poussez dans Git, et il sera également déployé sur scène ou tests, selon les pipelines, puis accédez au prod avec le même outil. Cette unité, l'unification, la reproductibilité de l'infrastructure de l'environnement local à la vente est un moment très important pour nous. Mais ce n'est pas encore dans werf - il suffit de planifier pour 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 solutions de contournement - nous avons trouvé une sorte de solution pour nous-mêmes sur le shell, sur n'importe quoi. Ensuite, ces solutions de contournement ont tenté en quelque sorte de redresser, de généraliser et de consolider les fichiers binaires dans ce cas, que nous partageons simplement.

Il y a une autre vision de toute cette histoire, avec des analogies.

Kubernetes est un châssis de voiture avec un moteur. Il n'y a pas de portes, de fenêtres, de radio, d'arbres de Noël - rien du tout. Seul le cadre et le moteur. Et il y a Helm - c'est le volant. Cool - il y a un volant, mais il faut toujours un axe de direction, une crémaillère de direction, une boîte de vitesses et des roues, mais sans eux rien.

Dans le cas de werf, c'est un autre composant de Kubernetes. Ce n'est que maintenant dans notre version alpha de werf, par exemple, que Helm se compile en werf, car nous sommes fatigués de le faire nous-mêmes. Il y a de nombreuses raisons de le faire, en détail sur la raison pour laquelle nous avons compilé Helm dans son ensemble avec tiller inside werf, je le dirai juste dans le rapport sur RIT ++ .

Maintenant, werf est un composant plus intégré. Nous obtenons un volant prêt à l'emploi, un axe de direction - je ne suis pas très bon dans les voitures, mais c'est un gros bloc qui résout déjà un éventail assez large de tâches. Nous n'avons pas besoin de grimper le catalogue nous-mêmes, de ramasser une partie à l'autre, de réfléchir à la façon de les fixer les uns aux autres. Nous obtenons une moissonneuse-batteuse prête à l'emploi qui résout immédiatement un large éventail de tâches. Mais à l'intérieur, il est composé de tous les mêmes composants open source, il utilise également Docker pour l'assemblage, Helm pour une partie de la fonctionnalité et il existe plusieurs autres bibliothèques. Il s'agit d'un outil intégré pour sortir rapidement et commodément des CI / CD sympas de la boîte.

Kubernetes est-il difficile à entretenir?

- Vous parlez de l'expérience que vous avez commencé à utiliser Kubernetes, c'est un cadre, un moteur pour vous, et que vous pouvez y accrocher beaucoup de choses différentes: corps, volant, attachez les pédales, les sièges. La question est: dans quelle mesure le support Kubernetes est-il difficile pour vous? Vous avez une riche expérience, combien de temps et de ressources vous faut-il pour prendre en charge Kubernetes séparément de tout le reste?

Dmitry : C'est une question très difficile et pour y répondre, vous devez comprendre ce qu'est le support et ce que nous attendons de Kubernetes. Peut-être révélerez-vous?

- Pour autant que je sache et comme je le vois, maintenant de nombreuses équipes veulent essayer Kubernetes. Tout le monde attelé à lui, mis à genoux. J'ai le sentiment que les gens ne comprennent pas toujours la complexité de ce système.

Dmitry : C'est ça.

- Est-il difficile de prendre et de livrer Kubernetes sans rien pour le préparer à la production?

Dmitry : Pensez-vous combien il est difficile de transplanter un cœur? Je comprends, la question est compromettante. Porter avec un scalpel et ne pas se tromper n'est pas si difficile. Si l'on vous dit où couper et où coudre, la procédure elle-même est simple. Il est difficile de garantir de temps en temps que tout se passera bien.

Mettez Kubernetes et faites-le fonctionner simplement: chick! - livré, il existe un tas de méthodes d'installation. Mais que se passe-t-il lorsque des problèmes surviennent?

Des questions se posent toujours - que n'avons-nous pas encore pris en compte? Qu'avons-nous pas encore fait? Quels paramètres du noyau Linux avez-vous mal spécifiés? Seigneur, les avons-nous même signalés?! Quels composants Kubernetes avons-nous livrés et lesquels ne le sont pas? Des milliers de questions se posent et pour y répondre, vous devez cuisiner pendant 15 à 20 ans dans cette industrie.

J'ai un nouvel exemple sur ce sujet qui peut révéler la signification du problème «Est-il difficile de maintenir Kubernetes?». Il y a quelque temps, nous nous sommes sérieusement demandé si nous devions essayer de mettre en œuvre Cilium en tant que réseau dans Kubernetes.

Permettez-moi d'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 cool - c'est Cilium. Quelle est sa signification? Il y a quelque temps, dans le noyau, il est devenu possible d'écrire des points d'ancrage pour le noyau qui envahissent le sous-système réseau et divers autres sous-systèmes et vous permettent de contourner de gros morceaux dans le noyau.

Historiquement, le noyau Linux a une routage ip, un superfiltre, des ponts et de nombreux anciens composants différents qui ont 15, 20, 30 ans. En général, ils fonctionnent, tout est cool, mais maintenant ils ont fait un conteneur de 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 développé historiquement avec de nombreuses nuances, comme une annexe dans le corps. Dans certaines situations, il y a des problèmes de performances, par exemple.

Il y a un BPF merveilleux et la possibilité d'écrire des crochets pour le noyau - les gars ont écrit leurs crochets pour le noyau. Le paquet arrive au noyau Linux, ils le sortent directement à l'entrée, le traitent eux-mêmes sans ponts, sans TCP, sans la pile IP - en bref, contournant tout ce qui est écrit dans le noyau Linux, et le recrachent immédiatement dans le conteneur.

Que s'est-il passé? Performance très cool, fonctionnalités intéressantes - tout simplement génial! Mais nous regardons cela et voyons que sur chaque machine il y a un programme qui se connecte à l'API Kubernetes et, selon les données reçues de cette API, génère du code C et compile les binaires qu'il charge dans le noyau afin que ces crochets fonctionnent dans l'espace du noyau .

Que se passe-t-il en cas de problème? Nous ne le savons pas. Pour comprendre cela, vous devez lire tout ce code, comprendre toute la logique, et cela est stupéfait, combien difficile. Mais, d'un autre côté, il y a ces ponts, filtres de réseau, rout ip - je n'ai pas lu leurs sources, et 40 ingénieurs qui travaillent aussi dans notre entreprise. Peut-être que certaines pièces comprennent les unités.

Et quelle est la différence? Il s'avère qu'il existe une déroute ip, le noyau Linux et un nouvel outil - quelle est la différence, 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 plus de 30 ans tous les bugs ont été trouvés, tous les râteaux sont venus et vous n'avez pas besoin de tout savoir - cela fonctionne comme une boîte noire, et ça marche toujours. Tout le monde sait quel tournevis de diagnostic coller à quel endroit, quel tcpdump à quel moment commencer. Tout le monde connaît bien les utilitaires de diagnostic et comprend comment cet ensemble de composants fonctionne dans le noyau Linux - pas comment il fonctionne, mais comment l'utiliser.

Et Cilium incroyablement cool n'a pas 30 ans, il n'est pas encore mature. Avec Kubernetes le même problème, copiez. Que Cilium est parfaitement réglé, que Kubernetes est parfaitement réglé, mais quand quelque chose ne va pas dans la prod, êtes-vous capable de comprendre rapidement ce qui ne va pas dans une situation critique?

Quand on dit que c'est difficile de maintenir Kubernetes, non, c'est très simple, et oui, c'est incroyablement difficile. Kubernetes , .

« »

— , ? , Kubernetes, - .

: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.

Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.

, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .

. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?

, , , . , .

, , , , . .

IT, , « ». , , . , . .

— : , , «», , Red Hat, , Kubernetes, .

: . Kubernetes — .

?

— , Kubernetes ?

: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .

— ? «» , Kubernetes — -.

, Kubernetes .

game-changer . — , Ansible, Chef, , Terraform. . Kubernetes — changer , .

, - , - , . , , Kubernetes : , infrastructure as code , , yml — . , .

— , Kubernetes, . ?

: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .

, CI/CD — , Continuous Delivery, , , , — Kubernetes.

— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?

: . «: ». , . , . , , . «». , , - , — , , . Ce n'est pas le cas.

, , 300 , , , , , - — 10, 30 . , . , 3 60 , .

, — . , . , , .

, , , , Kubernetes , , , , , , Kubernetes, . — , , , . . — , , — .

— , Kubernetes , , , . . — , , , 10 — , . . , .

Kubernetes . : Kubernetes, , 4-5 , — . , . Qu'est ce que c'est Ubuntu Curios? Linux, . , . Kubernetes , , , , .

, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.

, 10 , . .

Amazon Google

— Amazon Google?

: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .

, , . 40 , , , 60 — . - , , .

, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .

, — , , , hosted- .

Kubernetes?

— - Kubernetes? Kubernetes, «», Kubernetes?

: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .

, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !

, : «, ». , . , . CI/CD, . , .

, Kubernetes — Kubernetes .

, Kubernetes. , , , . , . Kubernetes — , , « », « », - .

. : , , — . . , , , , . , .

, - Kubernetes — .

Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .

. : «, !» — , : « , ». . , , - , , .

: Kubernetes. .

, :

• ;
  
• , , - ;
  
• , , , .
  

: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .

À propos de sans serveur

- Si vous regardez un peu plus loin dans l'avenir, puis essayez de résoudre le problème du manque de maux de tête avec l'infrastructure, avec la vitesse de déploiement et la vitesse de changement d'application, de nouvelles solutions apparaissent, par exemple, sans serveur. Sentez-vous un potentiel dans cette direction et, disons-le, un danger pour Kubernetes et des solutions similaires?

Dmitry : Ici, nous devons à nouveau faire une remarque, que je ne suis pas un visionnaire qui regarde vers l'avenir 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, hein? Nous rencontrons quelques bugs dans le CPU.

Rendre sans serveur suffisamment fiable, bon marché, efficace et pratique, en résolvant tous les problèmes d'écosystème Ensuite, je suis d'accord avec Elon Mask que nous avons besoin d'une deuxième planète pour faire de la tolérance aux fautes pour l'humanité. Bien que je ne sache pas ce qu'il dit, je comprends que je ne suis pas prêt à voler vers Mars moi-même et ce ne sera pas demain.

Avec sans serveur, il est clair que c'est la chose idéologiquement correcte, comme tolérance aux fautes pour l'humanité - deux planètes valent mieux qu'une. Mais comment faire maintenant? Envoyer une expédition n'est pas un problème si nous nous concentrons sur cet effort. Envoyer plusieurs expéditions et y peupler plusieurs milliers de personnes est, je pense, aussi réaliste. Mais c’est complètement pour faire de la tolérance aux fautes que la moitié de l’humanité y vit, il me semble désormais impossible, non envisagé.

Avec un à un sans serveur: la chose est cool, mais c'est loin des problèmes de 2019. Plus près de 2030 - vivons pour le voir. Je ne doute pas que nous survivrons, nous survivrons certainement (répétez avant le coucher), mais maintenant nous devons résoudre d'autres problèmes. C'est comme croire en un fabuleux poney Rainbow. Oui, quelques pour cent des cas sont résolus et parfaitement résolus, mais subjectivement sans serveur est un arc-en-ciel ... Pour moi, ce sujet est trop loin et trop incompréhensible. Je ne suis pas prêt à parler. En 2019, sans serveur, vous n'écrirez pas une seule application.

Comment Kubernetes se développera

"Alors que nous nous dirigeons vers cet avenir potentiellement magnifique et lointain, que pensez-vous qui développera Kubernetes et l'écosystème qui l'entoure?"

Dmitry : J'y ai beaucoup réfléchi et j'ai une réponse claire. Le premier est d'État - encore apatride est plus facile à faire. Kubernetes a d'abord investi davantage, tout a commencé avec. Les apatrides fonctionnent presque parfaitement à Kubernetes, il n'y a rien à redire. Par état, il y a encore beaucoup de problèmes, ou plutôt de nuances. Tout fonctionne déjà bien pour nous là-bas, mais nous le sommes. Pour que cela fonctionne pour tout le monde, vous avez besoin d'au moins quelques années de plus. Ce n'est pas un indicateur calculé, mais mon sentiment de la tête.

En bref, Statefull doit - et va - se développer beaucoup, car toutes nos applications ont un statut, il n'y a pas d'applications sans état. C'est une illusion, vous avez toujours besoin d'une sorte de base de données et d'autre chose. Statefull est la rectification de tout ce qui est possible, la correction de tous les bugs, l'amélioration de tous les problèmes auxquels nous sommes actuellement confrontés - appelons cela l'adoption.

Le niveau de l'inconnu, le niveau des problèmes non résolus, le niveau de probabilité de rencontrer quelque chose, chutera fortement. Ceci est une histoire importante. Et les opérateurs - tout ce qui concerne la codification de la logique d'administration, la logique de contrôle, pour obtenir un service facile: MySQL easy service, RabbitMQ easy service, Memcache easy service - en général, tous ces composants dont nous avons besoin pour être sûrs de fonctionner prêts à l'emploi. Cela résout simplement la douleur que nous voulons une base de données, mais que nous ne voulons pas l’administrer ou que nous voulons Kubernetes, mais que nous ne voulons pas l’administrer.

Cette histoire avec le développement des opérateurs sous une forme ou une autre sera importante dans les prochaines années.

Je pense que la facilité d'utilisation devrait considérablement augmenter - la box deviendra de plus en plus noire, de plus en plus fiable, avec des torsions de plus en plus simples.

J’ai une fois écouté l’ancienne interview d’Isaac Asimov des années 80 sur YouTube dans Saturday Night Live, une émission de type Urgant qui est juste intéressante. On lui a posé des questions sur l'avenir des ordinateurs. Il a dit que l'avenir est simple, comme ce fut le cas avec la radio. La radio était à l'origine une chose compliquée. Pour attraper la vague, il a fallu 15 minutes pour faire tourner les tourbillons, faire tourner les brochettes et savoir généralement comment tout fonctionne, pour comprendre la physique de la transmission des ondes radio. En conséquence, une torsion est restée à la radio.

Maintenant en 2019, quelle radio? Dans la voiture, la radio retrouve toutes les ondes, le nom des stations. La physique du processus n'a pas changé depuis 100 ans, la facilité d'utilisation a changé. Maintenant, et pas seulement maintenant, déjà en 1980, quand il y a eu une interview avec Azimov, tout le monde a utilisé la radio et personne n'a réfléchi à la façon dont elle était arrangée. Cela a toujours fonctionné - c'est une donnée.

Azimov a ensuite déclaré que ce serait similaire avec les ordinateurs - la facilité d'utilisation augmenterait . Si, en 1980, vous devez suivre une formation spécialisée 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. À mon avis, cela est évident - cela se trouve à la surface.

Que faire des ingénieurs?

- Et qu'adviendra-t-il des ingénieurs, administrateurs système qui prennent en charge Kubernetes?

Dmitry : Et qu'est-il arrivé au comptable après l'apparition de 1C? À peu près la même chose. Avant cela, ils ont réfléchi sur un morceau de papier - maintenant dans le programme. La productivité du travail a augmenté de plusieurs ordres de grandeur, et le travail lui-même n'en a pas disparu. Auparavant, 10 ingénieurs devaient visser l'ampoule, mais maintenant, un suffira.

Il me semble que le nombre de logiciels et le nombre de tâches augmentent à une vitesse supérieure à celle des nouveaux DevOps et l'efficacité augmente. Il y a une pénurie spécifique sur le marché et elle durera longtemps. Plus tard, tout ira dans une certaine norme, à laquelle l'efficacité du travail augmentera, il deviendra plus sans serveur, ils attacheront un neurone à Kubernetes, qui sélectionnera toutes les ressources comme il se doit, et en général, il fera tout comme il le devrait - la personne s'éloigne et ne dérange pas.

Mais de toute façon, quelqu'un devra prendre des décisions. Il est clair que le niveau de qualification et de spécialisation de cette personne est plus élevé. Maintenant, dans le département de comptabilité, vous n'avez pas besoin de 10 employés qui tiennent des livres pour que leur main ne se fatigue pas. 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 chef comptable intelligent suffit, déjà avec des compétences beaucoup plus grandes, avec une bonne compréhension.

En général, une telle voie dans tous les secteurs. C'est la même chose avec les voitures: auparavant, un mécanicien automobile et trois conducteurs étaient attachés à la voiture. Maintenant, conduire une voiture est le processus le plus simple auquel nous participons tous chaque jour. Personne ne pense qu'une voiture est quelque chose de compliqué.

Le DevOps ou l'ingénierie des systèmes n'ira nulle part - l'efficacité de haut niveau et opérationnelle augmentera.

- J'ai également entendu une idée intéressante selon laquelle le travail va en fait augmenter.

Dmitry : Bien sûr, à cent pour cent! Parce que la quantité de logiciels que nous écrivons est en constante augmentation. Le nombre de problèmes que nous résolvons avec les logiciels est en constante augmentation. La quantité de travail augmente. Maintenant, le marché DevOps est terriblement surchauffé. Cela ressort clairement des attentes salariales. Dans le bon sens, sans entrer 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. Et maintenant, si vous regardez le marché des salaires DevOps de Moscou, le junior veut de X à 3X et le senior veut de X à 3X.

Personne ne sait combien cela coûte. Votre niveau de salaire est mesuré par votre confiance - une folie complète, pour être honnête, un marché terriblement surchauffé.

Bien sûr, cette situation va changer très bientôt - une certaine saturation devrait arriver. Avec le développement de logiciels, ce n'est pas le cas - 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 combien cela coûte - l'industrie s'est installée. Ce n'est pas le cas avec DevOps.

- D'après ce que j'ai entendu, j'ai conclu que l'administrateur système actuel ne devrait pas être très inquiet, mais il est temps de télécharger des compétences et de se préparer au fait que demain il y aura plus de travail, mais il sera plus hautement qualifié.

Dmitry : Absolument. En général, nous vivons en 2019 et la règle de vie est la suivante: l' apprentissage à vie - nous apprenons toute notre vie . Il me semble que maintenant tout le monde le sait et le ressent, mais en savoir un peu est nécessaire. Chaque jour, nous devons changer. Si nous ne le faisons pas, tôt ou tard, nous serons déposés en marge de la profession.

Préparez-vous pour des virages serrés à 180 degrés. Je n'exclus pas une situation où quelque chose change radicalement, ils proposent quelque chose de nouveau - cela arrive. Hop! - et maintenant nous agissons différemment. Il est important de s'y préparer et de ne pas cuire à la vapeur. Il peut arriver que demain tout ce que je fais soit inutile - rien, j'ai étudié toute ma vie et je suis prêt à apprendre autre chose. Ce n'est pas un problème. Vous ne devez pas avoir peur de la sécurité d'emploi, mais vous devez être prêt à apprendre constamment quelque chose de nouveau.

Souhaits et une minute de publicité

- Aurez-vous 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 dans le service vidéo. Nous aurons un tas de contenu éducatif sur Kubernetes, ouvert et différent: des choses pratiques, jusqu'aux laboratoires, aux choses théoriques fondamentales et comment appliquer Kubernetes au niveau des principes et des modèles.

Le deuxième souhait mercantile - aller à GitHub et mettre des étoiles, parce que nous les mangeons. Si vous ne nous donnez pas d'étoiles, nous n'aurons rien à manger. C'est comme du mana dans un jeu vidéo. Nous faisons quelque chose, faisons, essayons, quelqu'un dit que ce sont des vélos terribles, quelqu'un que tout va généralement mal, et nous continuons et agissons de façon absolument honnête. Nous voyons le problème, le résolvons et partageons notre expérience. Par conséquent, donnez-nous un astérisque, il ne diminuera pas de vous, mais il viendra à nous, parce que nous les mangeons.

Le troisième désir, important et non plus mercantile - arrêtez de croire aux contes de fées . Vous êtes des professionnels. DevOps est une profession très sérieuse et responsable. Arrêtez de jouer sur le lieu de travail. Laissez-vous cliquer et vous le comprendrez. Imaginez que vous viendrez à l'hôpital et que le médecin expérimentera avec vous. Je comprends que cela peut être offensant pour quelqu'un, mais il ne s'agit probablement pas de vous, mais de quelqu'un d'autre. Dites aux autres d'arrêter aussi. Cela gâche vraiment la vie pour nous tous - beaucoup commencent à se rapporter à l'exploitation, aux admins et aux DevOps, comme aux mecs qui ont encore cassé quelque chose. Cela a été «cassé» le plus souvent en raison du fait que nous sommes allés jouer et que nous n'avons pas regardé avec une conscience froide que c'était comme ça, mais de cette façon.

Cela ne signifie pas que vous n'avez pas besoin d'expérimenter. Nous devons expérimenter, nous le faisons nous-mêmes. Pour être honnête, nous jouons aussi nous-mêmes parfois - cela, bien sûr, est très mauvais, mais rien d'humain ne nous est étranger. Déclarons 2019 l'année des expériences sérieuses et réfléchies, pas des jeux sur prod. Probablement.

- Merci beaucoup!

Dmitry : Merci, Vitaly, pour le temps et pour l'interview. Chers lecteurs, merci beaucoup si vous êtes soudainement arrivé à ce point. J'espère qu'au moins quelques réflexions que nous vous avons apportées.

Dans une interview, Dmitry a évoqué werf. Maintenant, c'est un couteau suisse universel qui résout presque toutes les tâches. Mais cela n'a pas toujours été le cas. À DevOpsConf au festival RIT ++ , Dmitry Stolyarov parlera de cet outil en détail. Le rapport «werf est notre outil pour CI / CD dans Kubernetes» aura tout: les problèmes et les nuances cachées de Kubernetes, les solutions à ces difficultés et l'implémentation actuelle de werf en détail. Rejoignez-nous les 27 et 28 mai, nous créerons des outils idéaux.