{"id":34450,"date":"2019-10-31T21:58:24","date_gmt":"2019-10-31T18:58:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-zahvatit-mir-kogda-i-kak\/"},"modified":"2019-10-31T21:58:24","modified_gmt":"2019-10-31T18:58:24","slug":"kubernetes-zahvatit-mir-kogda-i-kak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"Kubernetes va conqu\u00e9rir le monde. Quand et comment?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dans l'attente de DevOpsConf<\/a><\/noindex> Vitaly Khabarov<\/b> a interview\u00e9\u00a0Dmitry Stolyarov<\/b> (distol<\/a><\/noindex>), directeur technique et co-fondateur de la soci\u00e9t\u00e9 \u00abFlant\u00bb. Vitaly a interrog\u00e9 Dmitry sur ce que fait \u00abFlant\u00bb, Kubernetes, le d\u00e9veloppement de l'\u00e9cosyst\u00e8me, le support. Ils ont discut\u00e9 de l'utilit\u00e9 de Kubernetes et de son besoin r\u00e9el. Ils ont \u00e9galement parl\u00e9 des microservices, d'Amazon AWS, de l'approche \u00abJ'ai de la chance\u00bb en DevOps, de l'avenir de Kubernetes lui-m\u00eame, pourquoi, quand et comment il va conqu\u00e9rir le monde, des perspectives du DevOps et de ce \u00e0 quoi les ing\u00e9nieurs doivent se pr\u00e9parer dans un avenir proche avec l'optimisation et les r\u00e9seaux neuronaux.<\/p>\n

L'interview originale<\/a><\/noindex> sous forme de podcast est \u00e0 \u00e9couter sur DevOps D\u00e9flop \u2014 un podcast francophone sur le DevOps, et ci-dessous se trouve la version textuelle. <\/p>\n

\"Kubernetes
\n
\nIci et ci-dessous, les questions sont pos\u00e9es par Vitaly Khabarov<\/a><\/noindex> un ing\u00e9nieur d'Express42.
\n<\/a><\/noindex><\/p>\n

\u00c0 propos de \u00abFlant\u00bb<\/h2>\n

\n\u2014 Dima, salut. Tu es le directeur technique de \u00abFlant<\/a><\/noindex>\u00bb et aussi son fondateur. Peux-tu, s'il te pla\u00eet, nous parler de ce que fait l'entreprise et de ton r\u00f4le en son sein ?<\/b><\/p>\n

\"KubernetesDmitry<\/b>: De l'ext\u00e9rieur, on dirait que nous sommes ces gars qui vont, installent Kubernetes \u00e0 tout le monde et font quelque chose avec. Mais ce n'est pas le cas. Nous avons commenc\u00e9 comme une entreprise sp\u00e9cialis\u00e9e dans Linux, mais depuis longtemps, notre principale activit\u00e9 est la gestion de projets de production et de haute charge cl\u00e9s en main. En g\u00e9n\u00e9ral, nous construisons toute l'infrastructure \u00e0 partir de z\u00e9ro et ensuite nous en sommes responsables pendant longtemps. Donc, le principal travail que \u00abFlant\u00bb fait, et pour lequel elle re\u00e7oit de l'argent, c'est prendre la responsabilit\u00e9 et r\u00e9aliser des productions cl\u00e9s en main.<\/b>.
\n

\n

\nEn tant que directeur technique et un des fondateurs de l'entreprise, je passe mes journ\u00e9es \u00e0 r\u00e9fl\u00e9chir \u00e0 comment am\u00e9liorer la disponibilit\u00e9 de la production, simplifier son exploitation, faciliter la vie des administrateurs, et rendre la vie des d\u00e9veloppeurs plus agr\u00e9able.<\/p>\n

\u00c0 propos de Kubernetes<\/h2>\n

\n\u2014 Derni\u00e8rement, j'ai vu beaucoup de pr\u00e9sentations de \u00abFlant\u00bb sur\u00a0articles<\/a><\/noindex> Kubernetes. Comment \u00eates-vous arriv\u00e9 \u00e0 cela ?<\/b><\/p>\n

Dmitry<\/b>: J'en ai d\u00e9j\u00e0 parl\u00e9 de nombreuses fois, mais cela ne me d\u00e9range pas de le r\u00e9p\u00e9ter. Je pense qu'il est important de revenir sur ce sujet car il y a de la confusion entre cause et effet.<\/p>\n

Nous avions vraiment besoin d'un outil. Nous \u00e9tions confront\u00e9s \u00e0 de nombreux probl\u00e8mes, nous avons lutt\u00e9, surmont\u00e9 ces d\u00e9fis avec divers bricolages et \u00e9prouv\u00e9 un besoin d'un v\u00e9ritable outil. Nous avons explor\u00e9 de nombreuses options, construit nos propres solutions, accumul\u00e9 de l'exp\u00e9rience. Peu \u00e0 peu, nous avons commenc\u00e9 \u00e0 utiliser Docker presque d\u00e8s son apparition - vers 2013. \u00c0 son lancement, nous avions d\u00e9j\u00e0 beaucoup d'exp\u00e9rience avec les conteneurs, et nous avions d\u00e9j\u00e0 \u00e9crit notre propre version de \"Docker\" - en quelque sorte nos bricolages en Python. Avec Docker, nous avons pu \u00e9liminer ces solutions improvis\u00e9es et utiliser une solution fiable et soutenue par la communaut\u00e9.<\/p>\n

L'histoire est similaire avec Kubernetes. Au moment o\u00f9 il a commenc\u00e9 \u00e0 gagner en popularit\u00e9 - pour nous, c'\u00e9tait la version 1.2 - nous avions d\u00e9j\u00e0 de nombreux bricolages, tant en Shell qu'en Chef, que nous tentions d'orchestrer avec Docker. Nous \u00e9tions s\u00e9rieusement orient\u00e9s vers Rancher et d'autres solutions, puis Kubernetes est arriv\u00e9, qui a tout r\u00e9alis\u00e9 exactement comme nous l'aurions fait, voire mieux. Il n'y a rien \u00e0 redire.<\/p>\n

Oui, il y a certaines imperfections ici, il y a des d\u00e9fauts l\u00e0-bas \u2014 beaucoup de choses inachev\u00e9es, et la version 1.2 est vraiment alarmante, mais\u2026 Kubernetes est comme un b\u00e2timent en construction \u2014 tu regardes le projet et tu sais que \u00e7a va \u00eatre g\u00e9nial. Si le b\u00e2timent a d\u00e9j\u00e0 des fondations et deux \u00e9tages, tu comprends qu'il vaut mieux ne pas y emm\u00e9nager pour l'instant, tandis qu'avec le logiciel, il n'y a pas ce genre de probl\u00e8me \u2014 il est d\u00e9j\u00e0 utilisable.<\/p>\n

Nous n'avons jamais eu de moment o\u00f9 nous avons h\u00e9sit\u00e9 \u00e0 utiliser Kubernetes ou non. Nous l'attendions depuis longtemps avant son apparition et tentions de cr\u00e9er nos propres analogues.<\/p><\/blockquote>\n

<\/p>\n

\u00c0 propos de Kubernetes<\/h2>\n

\n\u2014 Participez-vous directement au d\u00e9veloppement de Kubernetes ?<\/b><\/p>\n

Dmitry<\/b>: Indirectement. Nous participons plut\u00f4t au d\u00e9veloppement de l'\u00e9cosyst\u00e8me. Nous envoyons un certain nombre de pull requests : vers Prometheus, divers op\u00e9rateurs, Helm - vers l'\u00e9cosyst\u00e8me. 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\u00e9 de pull request au noyau.<\/p>\n

\u2014 Par ailleurs, d\u00e9veloppez-vous de nombreux outils autour de Kubernetes ?<\/b><\/p>\n

Dmitry<\/b>: La strat\u00e9gie est la suivante : nous allons et faisons des pull requests pour tout ce qui existe d\u00e9j\u00e0. Si les pull requests ne sont pas accept\u00e9es, nous les forkons pour nous-m\u00eames et nous continuons \u00e0 vivre avec nos versions jusqu'\u00e0 ce qu'elles soient accept\u00e9es. Ensuite, lorsque cela arrive \u00e0 la version upstream, nous retournons \u00e0 la version upstream.<\/p>\n

Par exemple, nous avons un op\u00e9rateur Prometheus, avec lequel nous avons bascul\u00e9 vers le upstream de notre build environ cinq fois, probablement. Nous avons besoin d'une fonctionnalit\u00e9, nous avons envoy\u00e9 une demande de tirage, nous devons la d\u00e9ployer demain, et nous ne voulons pas attendre qu'elle soit publi\u00e9e dans le upstream. Par cons\u00e9quent, nous rassemblons notre propre version, d\u00e9ployons notre build avec la fonctionnalit\u00e9 dont nous avons besoin sur tous nos clusters. Puis, cela est par exemple renvoy\u00e9 \u00e0 upstream avec les mots : \u00ab Les gars, faisons-le pour un cas plus g\u00e9n\u00e9ral \u00bb, nous, ou quelqu'un d'autre, le compl\u00e9tons, et avec le temps, cela fusionne \u00e0 nouveau.<\/p>\n

Tout ce qui existe, nous essayons de le d\u00e9velopper.<\/b>. De nombreux \u00e9l\u00e9ments qui n'existent pas encore, qui n'ont pas encore \u00e9t\u00e9 imagin\u00e9s ou qui ont \u00e9t\u00e9 imagin\u00e9s mais pas encore r\u00e9alis\u00e9s, nous les concevons. Et ce n'est pas parce que nous aimons le processus lui-m\u00eame ou la cr\u00e9ation de v\u00e9los en tant que domaine, mais simplement parce que nous avons besoin de cet outil. On nous pose souvent la question, pourquoi avons-nous cr\u00e9\u00e9 telle ou telle chose ? La r\u00e9ponse est simple : parce que nous devions avancer, r\u00e9soudre un probl\u00e8me pratique, et nous l'avons r\u00e9solu avec cet outil.<\/p>\n

Le chemin est toujours le m\u00eame : nous cherchons tr\u00e8s soigneusement et, si nous ne trouvons aucune solution \u00e0 comment faire un trolleybus \u00e0 partir d\u2019un pain, alors nous faisons notre propre pain et notre propre trolleybus.<\/p><\/blockquote>\n

<\/p>\n

Les outils de Flant<\/h2>\n

\n\u2014 Je sais qu'il y a maintenant des op\u00e9rateurs addon chez Flant, des op\u00e9rateurs shell, des outils dapp\/werf. Si je comprends bien, c'est le m\u00eame outil sous diff\u00e9rentes incarnations. Je comprends aussi qu'il y a encore beaucoup d'autres outils \u00e0 l'int\u00e9rieur de Flant. Est-ce correct ?<\/b><\/p>\n

Dmitry<\/b>: 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\u00e9ci\u00e9 de tous. Il est mentionn\u00e9 presque dans chaque deuxi\u00e8me article sur la surveillance de Kubernetes sur Medium. Il est impossible de d\u00e9crire bri\u00e8vement ce qu'est statusmap - un article s\u00e9par\u00e9 est n\u00e9cessaire, mais c'est un outil tr\u00e8s 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\u00e9 sur ClickHouse et un peu de magie noire pour collecter des logs dans Kubernetes.<\/p>\n

De nombreux outils ! Et il y en aura encore plus, car un certain nombre de solutions internes seront publi\u00e9es cette ann\u00e9e. Parmi les plus importantes, il y a une multitude d'addons pour Kubernetes, comme la bonne installation de sert manager \u2014 un outil pour la gestion des certificats, ou la bonne installation de Prometheus avec une multitude d'extensions \u2014 ce sont une vingtaine de binaires diff\u00e9rents qui exportent des donn\u00e9es et collectent des \u00e9l\u00e9ments, 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\u00e9 et automatis\u00e9, o\u00f9 de nombreuses questions sont d\u00e9j\u00e0 r\u00e9solues. Oui, nous faisons beaucoup de choses.<\/p>\n

D\u00e9veloppement de l'\u00e9cosyst\u00e8me<\/h2>\n

\n\u2014 Je pense que c'est une contribution tr\u00e8s importante au d\u00e9veloppement de cet outil et de ses m\u00e9thodes d'utilisation. Peux-tu estimer approximativement qui aurait \u00e9galement pu apporter une telle contribution au d\u00e9veloppement de l'\u00e9cosyst\u00e8me ?<\/b><\/p>\n

Dmitry<\/b>: En Russie, parmi les entreprises qui op\u00e8rent sur notre march\u00e9 \u2014 personne n'est m\u00eame proche.<\/b>. Bien s\u00fbr, c'est une d\u00e9claration audacieuse, car il y a de grands acteurs, comme Mail et Yandex \u2014 ils font aussi quelque chose avec Kubernetes, mais m\u00eame 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 \u00e9quipe de 80 personnes et Red Hat, qui a 300 ing\u00e9nieurs rien que pour Kubernetes, si je ne me trompe pas. C'est difficile \u00e0 comparer. Dans notre d\u00e9partement RnD, nous sommes 6, y compris moi, qui d\u00e9veloppons tous nos outils. 6 personnes contre 300 ing\u00e9nieurs de Red Hat \u2014 c'est un peu difficile \u00e0 comparer.<\/p>\n

\u2014 N\u00e9anmoins, m\u00eame lorsque ces 6 personnes peuvent faire quelque chose de vraiment utile et transf\u00e9rable, lorsqu'elles sont confront\u00e9es \u00e0 un probl\u00e8me pratique et qu'elles donnent une solution \u00e0 la communaut\u00e9 \u2014 c'est un cas int\u00e9ressant. Je comprends que dans de grandes entreprises technologiques, o\u00f9 il y a leur propre d\u00e9veloppement et une \u00e9quipe de support Kubernetes, de tels outils peuvent \u00e9galement \u00eatre d\u00e9velopp\u00e9s. C'est un exemple pour eux, montrant qu'on peut d\u00e9velopper et donner \u00e0 la communaut\u00e9, donner un coup de pouce \u00e0 toute la communaut\u00e9 qui utilise Kubernetes.<\/b><\/p>\n

Dmitry<\/b>: C'est probablement la particularit\u00e9 de l'int\u00e9grateur, sa sp\u00e9cificit\u00e9. Nous avons de nombreux projets et voyons beaucoup de situations diff\u00e9rentes. Pour nous, le principal moyen de cr\u00e9er de la valeur ajout\u00e9e est d'analyser ces cas, de trouver des points communs et de maximiser leur r\u00e9duction de co\u00fbts. Nous travaillons activement sur cela. Il m'est difficile de parler de la Russie et du monde, mais nous avons environ 40 ing\u00e9nieurs 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\u00e9cialistes connaissant Kubernetes, s'ils existent vraiment.<\/p>\n

Je comprends tout sur le nom de poste d'ing\u00e9nieur DevOps, tout le monde comprend et s'habitue \u00e0 appeler les ing\u00e9nieurs DevOps des ing\u00e9nieurs DevOps, nous ne discuterons pas de cela. Ces 40 merveilleux ing\u00e9nieurs DevOps font face chaque jour \u00e0 des probl\u00e8mes et les r\u00e9solvent, nous analysons simplement cette exp\u00e9rience 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\u00e9, un outil pr\u00eat \u00e0 l'emploi appara\u00eetra. Il n'y a aucun sens \u00e0 accumuler cette exp\u00e9rience en interne - c'est juste un gaspillage de forces et de temps dans dev\/null. Mais nous ne sommes pas du tout r\u00e9ticents. Nous publions tout avec grand plaisir et savons qu'il est n\u00e9cessaire de le publier, de le d\u00e9velopper, de le promouvoir, de le faire conna\u00eetre, afin que les gens l'utilisent et ajoutent leur propre exp\u00e9rience - alors tout grandit et vit. Dans deux ans, l'outil ne sera pas \u00e0 la poubelle. Nous ne sommes pas r\u00e9ticents \u00e0 continuer \u00e0 investir des efforts, car il est visible que des gens utilisent notre outil, et dans deux ans, tout le monde l'utilise d\u00e9j\u00e0.<\/p>\n

C'est une partie de notre grande strat\u00e9gie avec dapp\/werf<\/b>. Je ne me souviens pas quand nous avons commenc\u00e9 \u00e0 le faire, il y a semble-t-il 3 ans. \u00c0 l'origine, c'\u00e9tait enti\u00e8rement sur shell. C'\u00e9tait un super proof of concept, nous avons r\u00e9solu certaines de nos t\u00e2ches particuli\u00e8res - \u00e7a a march\u00e9 ! Mais avec shell, il y a des probl\u00e8mes, il est impossible d'\u00e9voluer davantage, programmer sur shell est en effet une activit\u00e9 assez difficile. Nous avions l'habitude de coder en Ruby, donc nous avons refait quelque chose en Ruby, et avons continu\u00e9 \u00e0 d\u00e9velopper, d\u00e9velopper, d\u00e9velopper, et avons \u00e9t\u00e9 confront\u00e9s au fait que la communaut\u00e9, la foule, qui ne dit pas \u00ab nous voulons ou ne voulons pas \u00bb, se d\u00e9tourne de Ruby, aussi dr\u00f4le que cela puisse para\u00eetre. Nous avons compris que nous devions \u00e9crire tout cela en Go, juste pour nous conformer au premier point de la liste de contr\u00f4le : L'outil DevOps doit \u00eatre un binaire statique<\/b>. Sur Go ou pas sur Go, cela n'a pas tellement d'importance, mais il vaut mieux avoir un binaire statique \u00e9crit en Go.<\/p>\n

Nous avons investi des efforts, r\u00e9\u00e9crit le dapp en Go et l'avons nomm\u00e9 werf. Le dapp n'est plus maintenu, n'est plus d\u00e9velopp\u00e9, il fonctionne dans une certaine version d\u00e9finitive, mais il existe un chemin de mise \u00e0 niveau absolu vers le haut, et il est possible de le suivre.<\/p>\n

Pourquoi le dapp a-t-il \u00e9t\u00e9 cr\u00e9\u00e9<\/h2>\n

\n\u2014 Peux-tu bri\u00e8vement expliquer pourquoi le dapp a \u00e9t\u00e9 cr\u00e9\u00e9, quels probl\u00e8mes il r\u00e9sout ?<\/b><\/p>\n

Dmitry<\/b>: La premi\u00e8re raison est la construction. Au d\u00e9part, nous avions de gros probl\u00e8mes avec la compilation, lorsque Docker ne supportait pas le multi-stage, et nous avons d\u00fb cr\u00e9er le multi-stage par nous-m\u00eames. Ensuite, nous avons eu plein de questions concernant le nettoyage des images. Tous ceux qui font du CI\/CD se heurtent t\u00f4t ou tard au probl\u00e8me de la multitude d'images construites, n\u00e9cessitant de trouver un moyen de nettoyer ce qui n'est pas n\u00e9cessaire et de conserver ce qui l'est.<\/p>\n

La deuxi\u00e8me raison est le d\u00e9ploiement. Oui, il y a Helm, mais il ne r\u00e9sout qu'une partie des t\u00e2ches. C'est dr\u00f4le \u00e0 dire, mais il est \u00e9crit que \u00ab Helm est le gestionnaire de paquets pour Kubernetes \u00bb. Exactement, \u00ab le \u00bb. Et il y a aussi les mots \u00ab gestionnaire de paquets \u00bb - quelles attentes avons-nous g\u00e9n\u00e9ralement d'un gestionnaire de paquets ? Nous disons : \u00ab Gestionnaire de paquets - installe le paquet ! \u00bb et nous nous attendons \u00e0 ce qu'il nous dise : \u00ab Paquet install\u00e9 \u00bb. <\/p>\n

C'est int\u00e9ressant, parce que nous disons : \u00ab Helm, installe le paquet \u00bb, et quand il r\u00e9pond qu'il a install\u00e9, il s'av\u00e8re qu'il a seulement commenc\u00e9 l'installation - il a indiqu\u00e9 \u00e0 Kubernetes : \u00ab Lance ce truc-l\u00e0 ! \u00bb, mais qu'il ait effectivement d\u00e9marr\u00e9 ou non, qu'il fonctionne ou non, Helm ne r\u00e9pond absolument pas \u00e0 cette question.<\/p>\n

En gros, Helm n'est qu'un pr\u00e9processeur de texte qui charge des donn\u00e9es dans Kubernetes.<\/p><\/blockquote>\n

\nMais dans le cadre de tout d\u00e9ploiement, nous voulons savoir - l'application a-t-elle \u00e9t\u00e9 mise en production ou non ? Mise en production signifie que l'application a \u00e9t\u00e9 d\u00e9ploy\u00e9e, la nouvelle version a \u00e9t\u00e9 d\u00e9ploy\u00e9e, et elle ne tombe pas et r\u00e9pond correctement. Helm ne r\u00e9sout pas cette t\u00e2che. Pour le faire, il faut investir beaucoup d'efforts, car il est n\u00e9cessaire de donner \u00e0 Kubernetes le commandement de d\u00e9ployer et de suivre ce qui se passe - a-t-il \u00e9t\u00e9 d\u00e9ploy\u00e9, a-t-il \u00e9t\u00e9 mis en production ? Et il y a encore beaucoup de t\u00e2ches li\u00e9es au d\u00e9ploiement, au nettoyage, \u00e0 la construction.<\/p>\n

Plans<\/h2>\n

\nCette ann\u00e9e, nous allons nous lancer dans le d\u00e9veloppement local. Nous souhaitons arriver \u00e0 l'\u00e9tat o\u00f9, comme auparavant avec Vagrant, il suffisait de taper \u00ab vagrant up \u00bb pour d\u00e9ployer des machines virtuelles. Nous d\u00e9sirons atteindre un point o\u00f9 il y a un projet sur Git, et o\u00f9 en \u00e9crivant \u00ab werf up \u00bb, il l\u00e8ve une copie locale de ce projet, d\u00e9ploy\u00e9e dans un mini-Kub local, avec tous les r\u00e9pertoires pratiques pour le d\u00e9veloppement connect\u00e9s. En fonction du langage de d\u00e9veloppement, cela s'effectue de diff\u00e9rentes mani\u00e8res, mais n\u00e9anmoins, il doit \u00eatre possible de mener des d\u00e9veloppements locaux confortablement avec des fichiers mont\u00e9s.<\/p>\n

La prochaine \u00e9tape pour nous est de fortement investir dans le confort des d\u00e9veloppeurs<\/b>. Avec un seul outil, d\u00e9ployer rapidement un projet localement, le d\u00e9velopper, le pousser vers Git, et il sera d\u00e9ploy\u00e9 de la m\u00eame mani\u00e8re sur stage ou pour les tests, selon les pipelines, puis m\u00eame outil pour passer en production. Cette unit\u00e9, cette unification, la reproductibilit\u00e9 de l'infrastructure de l'environnement local \u00e0 la production est un point tr\u00e8s important pour nous. Mais cela n'existe pas encore dans werf, nous pr\u00e9voyons simplement de le faire.<\/p>\n

Mais le chemin vers dapp\/werf a toujours \u00e9t\u00e9 le m\u00eame qu'avec Kubernetes au d\u00e9but. Nous avons rencontr\u00e9 des probl\u00e8mes, les avons r\u00e9solus par des d\u00e9tours - en inventant des solutions pour nous-m\u00eames sur shell, sur n'importe quoi. Ensuite, nous essayions de redresser ces d\u00e9tours, de les g\u00e9n\u00e9raliser et de les consolider dans des binaires que nous partageons simplement.<\/p>\n

Il y a aussi une autre perspective sur toute cette histoire, avec des analogies. <\/p>\n

Kubernetes est le ch\u00e2ssis d'une voiture avec un moteur. Il n'y a pas de portes, de vitres, de r\u00e9cepteur radio, de sapin de No\u00ebl - 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\u00e9maill\u00e8re, une bo\u00eete de vitesses et des roues, sinon cela ne fonctionne pas.<\/p><\/blockquote>\n

\nDans le cas de werf, c'est encore un autre composant pour Kubernetes. Actuellement, notre version alpha de werf int\u00e8gre d'ailleurs Helm directement, car nous en avions assez de le faire nous-m\u00eames. Il y a de nombreuses raisons de proc\u00e9der ainsi, et je vais parler en d\u00e9tail des raisons pour lesquelles nous avons compil\u00e9 Helm enti\u00e8rement avec Tiller \u00e0 l'int\u00e9rieur de werf lors de ma pr\u00e9sentation au RIT++<\/a><\/noindex>.<\/p>\n

Maintenant, werf est un composant plus int\u00e9gr\u00e9. Nous avons un volant pr\u00eat, un axe de direction \u2013 je ne suis pas tr\u00e8s expert en voitures, mais c'est un gros bloc qui r\u00e9sout d\u00e9j\u00e0 un large \u00e9ventail de t\u00e2ches. Nous n'avons pas besoin de fouiller dans le catalogue, de s\u00e9lectionner une pi\u00e8ce pour l'autre, de nous demander comment les assembler. Nous avons un combine pr\u00eat qui r\u00e9sout imm\u00e9diatement un grand nombre de probl\u00e8mes. Mais \u00e0 l'int\u00e9rieur, il est construit \u00e0 partir des m\u00eames composants open source, utilise toujours Docker pour la construction, Helm pour une partie des fonctionnalit\u00e9s, et il y a encore quelques autres biblioth\u00e8ques. C'est un outil int\u00e9gr\u00e9 pour obtenir rapidement et facilement un CI\/CD g\u00e9nial pr\u00eat \u00e0 l'emploi.<\/p>\n

Est-il difficile de maintenir Kubernetes?<\/h2>\n

\n\u2014 Tu parles de l'exp\u00e9rience que vous avez commenc\u00e9e \u00e0 utiliser Kubernetes, c'est pour vous un cadre, un moteur, et qu'il y a beaucoup de choses diff\u00e9rentes que l'on peut y ajouter : la carrosserie, le volant, l'assemblage des p\u00e9dales, des si\u00e8ges. La question se pose : \u00e0 quel point la maintenance de Kubernetes est-elle difficile pour vous ? Vous avez une vaste exp\u00e9rience, combien de temps et de ressources consacrez-vous \u00e0 la maintenance de Kubernetes ind\u00e9pendamment de tout le reste ?<\/b><\/p>\n

Dmitry<\/b>: C'est une question tr\u00e8s complexe et pour y r\u00e9pondre, il faut comprendre ce qu'est la maintenance et ce que nous voulons de Kubernetes. Peux-tu d\u00e9velopper?<\/p>\n

\u2014 \u00c0 ma connaissance et comme je le vois, beaucoup d'\u00e9quipes souhaitent maintenant essayer Kubernetes. Tout le monde s'y met, l'installe \u00e0 la va-vite. J'ai l'impression que les gens ne comprennent pas toujours la complexit\u00e9 de ce syst\u00e8me.<\/b><\/p>\n

Dmitry<\/b>: C'est exact.<\/p>\n

\u2014 \u00c0 quel point est-il difficile de prendre Kubernetes et de l'installer \u00e0 partir de rien pour qu'il soit pr\u00eat pour la production ?<\/b><\/p>\n

Dmitry<\/b>: Que penses-tu de la difficult\u00e9 de transplanter un c\u0153ur ? Je comprends que la question soit d\u00e9licate. Manipuler un scalp et ne pas se tromper n'est pas si compliqu\u00e9. Si on te dit o\u00f9 couper et o\u00f9 suturer, alors la proc\u00e9dure elle-m\u00eame n'est pas complexe. Ce qui est difficile, c'est de garantir \u00e0 chaque fois que \u00e7a r\u00e9ussira.<\/p>\n

Installer Kubernetes et le faire fonctionner est facile : pouf ! \u2013 \u00e7a s'installe, il y a plein de mani\u00e8res d'installation. Mais que se passera-t-il lorsque des probl\u00e8mes surgiront?<\/p><\/blockquote>\n

\nDes questions se posent toujours \u2013 qu'avons-nous encore n\u00e9glig\u00e9 ? Qu'avons-nous encore oubli\u00e9 de faire ? Quels param\u00e8tres du noyau Linux avons-nous mal sp\u00e9cifi\u00e9s ? Mon Dieu, les avons-nous m\u00eame sp\u00e9cifi\u00e9s ? Quels composants Kubernetes avons-nous install\u00e9s et lesquels n'avons-nous pas ? Des milliers de questions surgissent, et pour y r\u00e9pondre, il faut 15 \u00e0 20 ans d'exp\u00e9rience dans cette industrie.<\/p>\n

J'ai un nouvel exemple sur ce sujet qui peut illustrer la probl\u00e9matique \u00ab Est-il difficile de maintenir Kubernetes ? \u00bb. Il n'y a pas longtemps, nous avons s\u00e9rieusement envisag\u00e9 d'impl\u00e9menter Cilium comme solution r\u00e9seau dans Kubernetes.<\/p>\n

Permettez-moi de vous expliquer ce qu'est Cilium. Dans Kubernetes, il existe de nombreuses impl\u00e9mentations de sous-syst\u00e8mes r\u00e9seau, et l'une d'entre elles est particuli\u00e8rement impressionnante : Cilium. Quelle en est la raison ? Il y a quelque temps, une possibilit\u00e9 d'\u00e9crire des hooks pour le noyau a \u00e9t\u00e9 introduite, permettant de s'immiscer dans le sous-syst\u00e8me r\u00e9seau et divers autres sous-syst\u00e8mes, contournant ainsi des parties importantes du noyau.<\/p>\n

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 \u00e0 une tour de 15 briques empil\u00e9es, et vous tenez en \u00e9quilibre dessus sur une jambe \u2014 une sensation \u00e9trange. Ce syst\u00e8me a \u00e9volu\u00e9 historiquement avec de nombreuses nuances, un peu comme l'appendice dans le corps. Dans certaines situations, il existe des probl\u00e8mes de performance, par exemple.<\/p>\n

Il existe un excellent BPF et la possibilit\u00e9 d'\u00e9crire des hooks pour le noyau \u2014 l'\u00e9quipe a cr\u00e9\u00e9 ses propres hooks pour le noyau. Lorsqu'un paquet arrive dans le noyau Linux, ils l'extraient d\u00e8s l'entr\u00e9e, le traitent comme il se doit sans ponts, sans TCP, sans pile IP \u2014 en gros, en contournant tout ce qui est \u00e9crit dans le noyau Linux, et le recrache imm\u00e9diatement dans le conteneur.<\/p>\n

Quel a \u00e9t\u00e9 le r\u00e9sultat ? Une performance incroyable, des fonctionnalit\u00e9s impressionnantes \u2014 c'est tout simplement g\u00e9nial ! Mais nous observons cela et nous voyons que sur chaque machine, il y a un programme qui se connecte \u00e0 l'API Kubernetes et, en se basant sur les donn\u00e9es re\u00e7ues de cette API, g\u00e9n\u00e8re du code C et compile des binaires qui sont charg\u00e9s dans le noyau, afin que ces hooks fonctionnent en espace noyau.<\/p>\n

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\u00eamement complexe. D'un autre c\u00f4t\u00e9, il y a ces ponts, ces netfilters, ip rout \u2014 je n'ai pas lu leurs sources non plus, et 40 ing\u00e9nieurs de notre entreprise ne l'ont pas fait non plus. Peut-\u00eatre que seuls quelques-uns comprennent certaines parties.<\/p>\n

Et quelle diff\u00e9rence ? Il s'av\u00e8re 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 \u00e9t\u00e9 trouv\u00e9s, toutes les erreurs ont \u00e9t\u00e9 rencontr\u00e9es et il n'est pas n\u00e9cessaire de tout conna\u00eetre - \u00e7a fonctionne comme une bo\u00eete noire, et \u00e7a fonctionne toujours. Tout le monde sait o\u00f9 mettre quel tournevis de diagnostic, \u00e0 quel moment lancer quel tcpdump. Tout le monde conna\u00eet 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.<\/p>\n

Mais le Cilium super g\u00e9nial n'a pas 30 ans, il n'est pas encore \u00e9prouv\u00e9. Il en est de m\u00eame 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, \u00eates-vous capables de comprendre rapidement ce qui ne va pas dans une situation critique ? <\/p>\n

Quand nous parlons de la difficult\u00e9 de maintenir Kubernetes - non, c'est tr\u00e8s simple, et oui, c'est incroyablement compliqu\u00e9. Kubernetes fonctionne tr\u00e8s bien tout seul, mais avec un milliard de nuances.<\/p><\/blockquote>\n

<\/p>\n

\u00c0 propos de l'approche \u00ab J'aurai de la chance \u00bb<\/h2>\n

\n\u2014 Y a-t-il des entreprises o\u00f9 ces nuances vont presque in\u00e9vitablement appara\u00eetre ? Supposons que Yandex d\u00e9cide subitement de migrer tous ses services vers Kubernetes, il y aura une \u00e9norme charge.<\/b><\/p>\n

Dmitry<\/b>: Non, ce n'est pas une discussion sur la charge, mais sur des choses simples. Par exemple, nous avons Kubernetes, nous avons d\u00e9ploy\u00e9 une application dessus. Comment savoir si \u00e7a fonctionne ? Il n'y a tout simplement pas d'outil pr\u00eat \u00e0 l'emploi pour savoir si l'application ne tombe pas. Il n'y a pas de syst\u00e8me pr\u00eat qui envoie des alertes - il faut configurer ces alertes et chaque graphique. Et nous mettons \u00e0 jour Kubernetes.<\/p>\n

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\u00e9tail est qu'il ne nettoie pas les cgroups. Kubernetes lance des pods, cr\u00e9e des cgroups, puis supprime les pods, et d'une certaine mani\u00e8re, je ne me souviens pas des d\u00e9tails, pardonnez-moi, cela laisse des fragments de systemd. Cela entra\u00eene le ralentissement progressif de n'importe quelle machine. Ce n'est m\u00eame pas une question de haute charge. Si des pods permanents sont lanc\u00e9s, par exemple, s'il y a un Cron Job qui g\u00e9n\u00e8re continuellement des pods, alors une machine avec Ubuntu 16.04 commencera \u00e0 ralentir apr\u00e8s une semaine. Il y aura constamment une charge moyenne \u00e9lev\u00e9e en raison de la cr\u00e9ation de nombreux cgroups. C'est un probl\u00e8me rencontr\u00e9 par quiconque installe simplement Ubuntu 16 et Kubernetes au-dessus.<\/p>\n

Admettons qu'il mette \u00e0 jour systemd ou autre chose, mais dans le noyau Linux jusqu'\u00e0 4.16, c'est encore plus dr\u00f4le \u2014 lors de la suppression des cgroups, ils fuyent dans le noyau et ne sont en fait pas supprim\u00e9s. Donc, apr\u00e8s un mois d'utilisation de cette machine, il sera impossible de consulter les statistiques de m\u00e9moire pour les pods. Nous r\u00e9cup\u00e9rons un fichier, le traitons dans le programme, et un fichier met 15 secondes \u00e0 \u00eatre trait\u00e9 parce que le noyau met beaucoup de temps \u00e0 faire le calcul \u00e0 l'int\u00e9rieur avec un million de cgroups qui semblent supprimer, mais non \u2014 ils fuient.<\/p>\n

Il y a encore beaucoup de petites choses ici et l\u00e0. Ce n'est pas une question \u00e0 laquelle les grandes entreprises peuvent parfois faire face lors de charges tr\u00e8s \u00e9lev\u00e9es \u2014 non, c'est une question de choses quotidiennes. Les gens peuvent vivre ainsi pendant des mois \u2014 ils ont install\u00e9 Kubernetes, d\u00e9ploy\u00e9 une application \u2014 \u00e7a semble fonctionner. Pour beaucoup, c'est normal. Quant au fait que cette application risque de s'arr\u00eater un jour pour une raison quelconque, ils ne le sauront m\u00eame pas, pas d'alerte, mais pour eux, c'est normal. Ils vivaient avant sur des machines virtuelles sans surveillance, maintenant, ils ont migr\u00e9 vers Kubernetes aussi sans surveillance \u2014 quelle diff\u00e9rence ?<\/p>\n

La question est que lorsque nous marchons sur la glace, nous ne connaissons jamais son \u00e9paisseur, sauf si nous l'avons mesur\u00e9e au pr\u00e9alable. Beaucoup de gens marchent et ne s'en pr\u00e9occupent pas, car ils marchaient d\u00e9j\u00e0 avant.<\/p>\n

\u00c0 mon avis, le d\u00e9tail et la complexit\u00e9 de l'exploitation de tout syst\u00e8me r\u00e9sident dans la garantie que l'\u00e9paisseur de la glace est suffisamment solide pour r\u00e9soudre nos t\u00e2ches. C'est de cela qu'il s'agit.<\/p><\/blockquote>\n

\nDans le secteur informatique, il me semble qu'il y a trop d'approches \u00ab J'ai de la chance \u00bb. Beaucoup installent des logiciels, utilisent des biblioth\u00e8ques dans l'espoir d'avoir de la chance. En g\u00e9n\u00e9ral, beaucoup r\u00e9ussissent. Peut-\u00eatre que c'est pour cela que \u00e7a fonctionne.<\/p>\n

\u2014 D'apr\u00e8s ma vision pessimiste, cela ressemble \u00e0 ceci : quand les risques sont \u00e9lev\u00e9s et que l'application doit fonctionner, il faut un soutien de Flant, peut-\u00eatre de Red Hat, ou alors une \u00e9quipe interne d\u00e9di\u00e9e sp\u00e9cifiquement \u00e0 Kubernetes, pr\u00eate \u00e0 le maintenir.<\/b><\/p>\n

Dmitry<\/b>: Objectivement, c'est le cas. S'engager soi-m\u00eame dans l'univers de Kubernetes pour une petite \u00e9quipe comporte un certain nombre de risques.<\/p>\n

Avons-nous besoin de conteneurs?<\/h2>\n

\n\u2014 Peux-tu me dire \u00e0 quel point Kubernetes est r\u00e9pandu en Russie ?<\/b><\/p>\n

Dmitry<\/b>: Je n'ai pas ces donn\u00e9es, et je ne suis pas s\u00fbr qu'elles soient disponibles chez qui que ce soit. Nous parlons de \u00ab Kubernetes, Kubernetes \u00bb, mais il existe une autre perspective sur cette question. Je ne sais pas non plus \u00e0 quel point les conteneurs sont r\u00e9pandus, mais je sais qu'environ 70 % des conteneurs sont orchestr\u00e9s par Kubernetes, selon une source fiable issue d'un assez large \u00e9chantillon mondial.<\/p>\n

Ensuite, une autre question : avons-nous besoin de conteneurs ?<\/b> J'ai personnellement le sentiment, et la position g\u00e9n\u00e9rale de l'entreprise Flant est que Kubernetes est devenu le standard de facto.<\/p>\n

Rien d'autre que Kubernetes ne sera utilis\u00e9.<\/p><\/blockquote>\n

\nC'est un v\u00e9ritable bouleversement dans la gestion de l'infrastructure. Absolument, plus de Ansible, Chef, de machines virtuelles, Terraform. Je ne parle m\u00eame pas des anciennes m\u00e9thodes obsol\u00e8tes. Kubernetes est vraiment un changeur de jeu.<\/b>, et maintenant ce sera toujours comme \u00e7a.<\/p>\n

Il est \u00e9vident que certains auront besoin de quelques ann\u00e9es, d'autres de plusieurs dizaines d'ann\u00e9es 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\u00e8me d'exploitation, mais utilisons l'infrastructure en tant que code<\/b>, mais pas avec du code, avec du yml \u2013 une infrastructure d\u00e9crite de mani\u00e8re d\u00e9clarative. J'ai l'impression que \u00e7a sera toujours le cas.<\/p>\n

\u2014 Donc, les entreprises qui ne sont pas encore pass\u00e9es \u00e0 Kubernetes y passeront n\u00e9cessairement ou resteront dans l'oubli. Ai-je bien compris ?<\/b><\/p>\n

Dmitry<\/b>: Ce n'est pas tout \u00e0 fait exact non plus. Par exemple, si nous avons pour t\u00e2che 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-\u00eatre qu'apr\u00e8s 20 ans, il faudra mettre \u00e0 jour quelque chose une seule fois. Si nous parlons de logiciels qui, au format, que nous lan\u00e7ons et qui fonctionnent r\u00e9ellement pendant des ann\u00e9es sans mises \u00e0 jour ni modifications, alors, bien s\u00fbr, il n'y aura pas Kubernetes. Ce n'est pas n\u00e9cessaire l\u00e0-bas.<\/p>\n

Tout ce qui concerne le CI\/CD \u2014 partout o\u00f9 une livraison continue est n\u00e9cessaire, o\u00f9 des mises \u00e0 jour de versions sont requises, o\u00f9 des modifications actives doivent \u00eatre effectu\u00e9es, partout o\u00f9 il est n\u00e9cessaire de construire une r\u00e9sistance aux pannes \u2014 seulement Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

Concernant les microservices<\/h2>\n

\n\u2014 Ici, j'\u00e9prouve un l\u00e9ger dissonance. Pour travailler avec Kubernetes, un support externe ou interne est n\u00e9cessaire \u2014 c'est le premier point. Deuxi\u00e8mement \u2014 lorsque nous commen\u00e7ons tout juste le d\u00e9veloppement, nous sommes une petite startup, nous n'avons encore rien, le d\u00e9veloppement sous Kubernetes ou sous une architecture de microservices peut \u00eatre difficile et pas toujours justifi\u00e9 \u00e9conomiquement. J'aimerais conna\u00eetre ton avis \u2014 est-il n\u00e9cessaire pour les startups de commencer \u00e0 \u00e9crire sous Kubernetes imm\u00e9diatement ou peut-on \u00e9crire un monolithe d'abord, puis seulement passer \u00e0 Kubernetes ?<\/b><\/p>\n

Dmitry<\/b>: Bonne question. J'ai une pr\u00e9sentation sur les microservices \u00ab Microservices : la taille a son importance \u00bb.<\/a><\/noindex> J'ai souvent \u00e9t\u00e9 confront\u00e9 \u00e0 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\u00e8re. Mais quand on le fait, il faut bien comprendre ce qu'on fait. Ce que je d\u00e9teste le plus dans les microservices, c'est le mot \u00ab micro \u00bb. Historiquement, ce terme est apparu, et pour une raison quelconque, les gens pensent que micro signifie tr\u00e8s petit, moins d'un millim\u00e8tre, comme un microm\u00e8tre. Ce n'est pas le cas.<\/p>\n

Par exemple, il existe un monolithe \u00e9crit par 300 personnes, et tous ceux qui ont particip\u00e9 au d\u00e9veloppement comprennent qu'il y a des probl\u00e8mes et qu'il doit \u00eatre d\u00e9coup\u00e9 en morceaux \u2014 environ 10, que chaque groupe de 30 personnes \u00e9crit au minimum. C'est important, n\u00e9cessaire et g\u00e9nial. Mais quand un startup arrive o\u00f9 3 tr\u00e8s bons et talentueux gars ont \u00e9crit sur le pouce 60 microservices, je cherche toujours du corvalol.<\/p>\n

Il me semble que cela a d\u00e9j\u00e0 \u00e9t\u00e9 dit des milliers de fois - nous avons obtenu un monolithe distribu\u00e9 sous une forme ou une autre. C'est \u00e9conomiquement injustifiable, tr\u00e8s compliqu\u00e9 dans l'ensemble. Je l'ai simplement vu tellement de fois que \u00e7a me fait mal, c'est pourquoi je continue \u00e0 en parler.<\/p>\n

En ce qui concerne la question initiale, il existe un conflit entre le fait que, d'un c\u00f4t\u00e9, Kubernetes est terriblement difficile \u00e0 utiliser car il est impossible de savoir ce qui pourrait casser ou ne pas fonctionner, et de l'autre c\u00f4t\u00e9, il est clair que tout va vers l\u00e0 et qu'il n'y aura rien d'autre que Kubernetes. La r\u00e9ponse est - \u00e9valuer le volume de b\u00e9n\u00e9fices que vous pouvez obtenir, le volume de t\u00e2ches que vous pouvez r\u00e9soudre.<\/b>. C'est d'un c\u00f4t\u00e9 de la balance. De l'autre c\u00f4t\u00e9 se trouvent les risques li\u00e9s aux temps d'arr\u00eat ou \u00e0 la baisse du temps de r\u00e9ponse, du niveau de disponibilit\u00e9 - \u00e0 la baisse des indicateurs de performance.<\/p>\n

C'est comme \u00e7a - soit nous avan\u00e7ons rapidement, et Kubernetes permet de r\u00e9aliser de nombreuses choses beaucoup plus vite et mieux, soit nous utilisons des solutions fiables et \u00e9prouv\u00e9es, mais avan\u00e7ons beaucoup plus lentement. Ce choix doit \u00eatre fait par chaque entreprise. On peut voir cela comme un chemin dans la jungle - lorsque vous y allez pour la premi\u00e8re fois, vous pouvez rencontrer un serpent, un tigre ou un blaireau fou, mais apr\u00e8s y \u00eatre all\u00e9 10 fois - vous avez trac\u00e9 un chemin, enlev\u00e9 les branches et c'est plus facile d'y aller. Chaque fois, le sentier s'\u00e9largit. Ensuite, cela devient une route pav\u00e9e, puis plus tard un joli boulevard.<\/p>\n

Kubernetes ne reste pas sur ses lauriers. Encore une fois la question : Kubernetes, d'un c\u00f4t\u00e9, c'est 4-5 binaires, et de l'autre, c'est tout un \u00e9cosyst\u00e8me. C'est le syst\u00e8me 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\u00e9mentaires. Toutes ces choses ici ont retir\u00e9 un serpent venimeux de la route, l\u00e0 ils ont install\u00e9 une cl\u00f4ture. Kubernetes \u00e9volue tr\u00e8s rapidement et dynamiquement, et le volume des risques, le volume de l'inconnu diminue chaque mois, et par cons\u00e9quent, ces balances se r\u00e9\u00e9quilibrent.<\/p>\n

En r\u00e9pondant \u00e0 la question sur ce que doit faire une startup, je dirais : venez chez \u00abFlant\u00bb, payez 150 000 roubles et obtenez un service DevOps cl\u00e9 en main. Si vous \u00eates une petite startup avec quelques d\u00e9veloppeurs, cela fonctionne. Au lieu d'embaucher votre propre DevOps, qui devra apprendre \u00e0 r\u00e9soudre vos probl\u00e8mes tout en prenant un salaire, vous obtiendrez une solution cl\u00e9 en main \u00e0 toutes vos questions. Oui, il y a certains inconv\u00e9nients. Nous, en tant qu'experts externes, ne pouvons pas \u00eatre aussi impliqu\u00e9s et r\u00e9agir rapidement aux changements. Mais nous avons une multitude d'expertises et de bonnes pratiques. Nous garantissons qu'\u00e0 tout moment, nous saurons r\u00e9soudre rapidement n'importe quel probl\u00e8me et faire revivre n'importe quel Kubernetes. <\/p>\n

Je recommande cat\u00e9goriquement l'externalisation aux startups et aux entreprises \u00e9tablies jusqu'\u00e0 ce que vous puissiez affecter une \u00e9quipe de 10 personnes \u00e0 l'exploitation, sinon \u00e7a n'a pas de sens. C'est absolument logique d'externaliser.<\/p><\/blockquote>\n

<\/p>\n

\u00c0 propos d'Amazon et de Google<\/h2>\n

\n\u2014 Peut-on consid\u00e9rer l'h\u00e9bergement propos\u00e9 par Amazon ou Google comme une externalisation ?<\/b><\/p>\n

Dmitry<\/b>: Oui, bien s\u00fbr, cela r\u00e9sout plusieurs probl\u00e8mes. Mais encore une fois, il y a des nuances. Il faut quand m\u00eame comprendre comment l'utiliser. Par exemple, il y a mille d\u00e9tails dans le fonctionnement d'Amazon AWS : il faut pr\u00e9chauffer le Load Balancer ou faire une demande \u00e0 l'avance en disant \u00ab les gars, nous allons avoir du trafic, pr\u00e9chauffez notre Load Balancer ! \u00bb Ces nuances, il faut les conna\u00eetre.<\/p>\n

Lorsque vous faites appel \u00e0 des personnes sp\u00e9cialis\u00e9es dans ce domaine, vous obtenez presque toutes les choses standardis\u00e9es r\u00e9solues. Nous avons actuellement 40 ing\u00e9nieurs, et d'ici la fin de l'ann\u00e9e, il y en aura probablement 60 \u2014 nous avons d\u00e9j\u00e0 rencontr\u00e9 tous ces probl\u00e8mes. M\u00eame si nous sommes confront\u00e9s \u00e0 ce probl\u00e8me sur un projet, nous pouvons rapidement demander \u00e0 l'un ou l'autre et savons comment r\u00e9soudre.<\/p>\n

Probablement, la r\u00e9ponse est la suivante : bien s\u00fbr, l'histoire h\u00e9berg\u00e9e all\u00e8ge une partie des soucis. La question est de savoir si vous \u00eates pr\u00eats \u00e0 faire confiance \u00e0 ces h\u00e9bergeurs et s'ils r\u00e9soudront vos probl\u00e8mes. Amazon et Google ont bien fait leurs preuves. Pour tous nos cas, c'est certain. Nous n'avons pas d'autres exp\u00e9riences positives. Tous les autres clouds avec lesquels nous avons essay\u00e9 de travailler posent beaucoup de probl\u00e8mes \u2014 que ce soit Ager ou tout ce qui existe en Russie, et toutes sortes de d\u00e9ploiements OpenStack : Headster, Overage \u2014 tout ce que vous voulez. Ils engendrent tous des probl\u00e8mes que nous pr\u00e9f\u00e9rons ne pas avoir \u00e0 r\u00e9soudre.<\/p>\n

Donc, la r\u00e9ponse est oui, mais en r\u00e9alit\u00e9, il n'existe pas beaucoup de solutions h\u00e9berg\u00e9es matures.<\/p>\n

\u00c0 qui Kubernetes est-il destin\u00e9 ?<\/h2>\n

\n\u2014 Mais finalement, \u00e0 qui Kubernetes est-il destin\u00e9 ? Qui doit d\u00e9j\u00e0 passer \u00e0 Kubernetes, qui est le client typique de \u00ab Flant \u00bb qui vient justement pour Kubernetes ?<\/b><\/p>\n

Dmitry<\/b>: C'est une question int\u00e9ressante, car en ce moment, beaucoup de gens viennent vers nous sur la vague de Kubernetes : \u00ab Les gars, nous savons que vous faites Kubernetes, faites-le pour nous ! \u00bb. Nous leur r\u00e9pondons : \u00ab Messieurs, nous ne faisons pas Kubernetes, nous faisons de la production et tout ce qui y est li\u00e9 \u00bb. 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\u00e9 la s\u00e9paration entre le d\u00e9veloppement d'un c\u00f4t\u00e9 et l'exploitation de l'autre.<\/p>\n

Nos clients ont des attentes diverses, mais tous esp\u00e8rent un certain miracle, que leurs probl\u00e8mes divers se r\u00e9soudront avec Kubernetes. Les gens croient aux miracles. Ils comprennent intellectuellement qu'il n'y aura pas de miracle, mais ils esp\u00e8rent de tout c\u0153ur \u2014 et si Kubernetes r\u00e9solvait tout pour nous, on en parle tant ! Peut-\u00eatre qu'il va tout r\u00e9soudre, bing ! \u2014 et voil\u00e0, 100 % de disponibilit\u00e9, tous les d\u00e9veloppeurs peuvent d\u00e9ployer \u00e0 peu pr\u00e8s n'importe quoi sur la production 50 fois sans que \u00e7a tombe. En somme, un miracle !<\/p>\n

Quand ces gens viennent vers nous, nous leur disons : \u00ab D\u00e9sol\u00e9, mais il n'y a pas de miracle \u00bb. Pour \u00eatre en bonne sant\u00e9, 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 \u00eatre fait.<\/p>\n

En r\u00e9pondant \u00e0 la question de savoir \u00e0 qui Kubernetes est destin\u00e9 \u2014 Kubernetes n'est utile \u00e0 personne.<\/p><\/blockquote>\n

\nCertaines personnes ont une id\u00e9e fausse qu'elles ont besoin de Kubernetes. Les gens ont besoin de ne plus penser, se pr\u00e9occuper ou s'int\u00e9resser \u00e0 tous les probl\u00e8mes d'infrastructure et au d\u00e9ploiement de leurs applications. Ils veulent que leurs applications fonctionnent simplement et se d\u00e9ploient facilement. Pour eux, Kubernetes est un espoir de ne plus entendre des histoires comme \u00ab on tra\u00eene \u00bb ou \u00ab on ne peut pas d\u00e9ployer \u00bb, ou autre.<\/p>\n

G\u00e9n\u00e9ralement, c'est le directeur technique qui vient vers nous. De lui, on demande deux choses : d'une part, des fonctionnalit\u00e9s, d'autre part \u2014 la stabilit\u00e9. Nous proposons de prendre cela en charge et de le faire. Une solution miracle, ou plut\u00f4t une solution alt\u00e9r\u00e9e, c'est que vous cessez de penser \u00e0 ces probl\u00e8mes et de perdre du temps. Vous aurez des personnes sp\u00e9cialis\u00e9es pour s'occuper de ces questions.<\/p>\n

La formulation selon laquelle nous avons besoin de Kubernetes ou que quelqu'un en a besoin est incorrecte.<\/p><\/blockquote>\n

\nKubernetes est tr\u00e8s utile pour les administrateurs, car c'est un outil fascinant avec lequel on peut exp\u00e9rimenter et jouer. Soyons honn\u00eates, tout le monde aime les jouets. Nous avons tous un c\u00f4t\u00e9 enfant, et quand nous voyons quelque chose de nouveau, nous voulons y jouer. Pour certains, cet enthousiasme a \u00e9t\u00e9 \u00e9mouss\u00e9, par exemple en administration, parce qu'ils ont d\u00e9j\u00e0 beaucoup jou\u00e9 et que cela ne les passionne plus au point d'en perdre l'envie. Pourtant, personne n'a compl\u00e8tement perdu cet int\u00e9r\u00eat. Par exemple, m\u00eame si j'en ai assez des jouets li\u00e9s \u00e0 l'administration syst\u00e8me et au DevOps, j'aime toujours les nouveaut\u00e9s et j'en ach\u00e8te encore quelques-unes.<\/p>\n

Il ne faut pas jouer avec la production. Ce que je ne recommande cat\u00e9goriquement pas de faire, et ce que je constate massivement en ce moment : \u00ab Oh, un nouveau jouet ! \u00bb \u2013 on se pr\u00e9cipite pour l'acheter, on l'ach\u00e8te et : \u00ab Prenons-le \u00e0 l'\u00e9cole, montrons-le \u00e0 tous nos amis \u00bb. Ne faites pas \u00e7a. Je m'excuse, mes enfants grandissent et je vois constamment des choses chez eux, je le remarque en moi et ensuite je le g\u00e9n\u00e9ralise aux autres.<\/p>\n

La r\u00e9ponse d\u00e9finitive : vous n'avez pas besoin de Kubernetes. Vous devez r\u00e9soudre vos probl\u00e8mes.<\/p><\/blockquote>\n

\nIl est possible d'atteindre ce qui suit :<\/p>\n