{"id":34596,"date":"2019-10-31T21:59:16","date_gmt":"2019-10-31T18:59:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zhivut-li-bazy-dannyh-v-kubernetes\/"},"modified":"2019-10-31T21:59:16","modified_gmt":"2019-10-31T18:59:16","slug":"zhivut-li-bazy-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"Est-ce que les bases de donn\u00e9es vivent dans Kubernetes ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Est-ce
\n
\nIl s'est historiquement \u00e9tabli que l'industrie informatique se divise en deux camps conditionnels : ceux qui sont \"pour\" et ceux qui sont \"contre\". Et les sujets de d\u00e9bat peuvent \u00eatre absolument arbitraires. Quel est le meilleur syst\u00e8me d'exploitation : Windows ou Linux ? Sur un smartphone, Android ou iOS ? Stocker tout dans le cloud ou le transf\u00e9rer sur des dispositifs RAID froids et mettre les disques dans un coffre-fort ? Les d\u00e9veloppeurs PHP ont-ils le droit de se faire appeler programmeurs ? Ces d\u00e9bats sont parfois d'une nature purement existentielle et ne reposent sur aucune autre base, \u00e0 part l'int\u00e9r\u00eat sportif.<\/p>\n

Il se trouve qu'avec l'apparition des conteneurs et de toute cette cuisine que nous aimons tant avec Docker et le Kubernetes suppos\u00e9, les d\u00e9bats \"pour\" et \"contre\" l'utilisation de nouvelles possibilit\u00e9s dans divers domaines de backend ont commenc\u00e9. (Pr\u00e9cisons d'embl\u00e9e que, bien que Kubernetes soit souvent cit\u00e9 comme orchestrateur dans ce raisonnement, le choix de cet outil en particulier n'est pas fondamental. N'importe quel autre outil que vous jugez plus pratique et familier peut \u00eatre substitu\u00e9 \u00e0 celui-ci.)<\/p>\n

Et, on pourrait penser qu'il s'agissait d'un simple d\u00e9bat entre deux c\u00f4t\u00e9s d'une m\u00eame m\u00e9daille. Tout aussi inutile et implacable que l'\u00e9ternelle rivalit\u00e9 entre Windows et Linux, o\u00f9 des personnes sens\u00e9es existent quelque part au milieu. Cependant, dans le cas de la conteneurisation, tout n'est pas si simple. Dans de tels d\u00e9bats, il n'y a g\u00e9n\u00e9ralement pas de partie droite, mais dans le cas de \"utiliser\" ou \"ne pas utiliser\" des conteneurs pour le stockage des bases de donn\u00e9es, tout devient sens dessus dessous. Car, dans un certain sens, tant les partisans que les adversaires de cette approche ont raison.
\n<\/a><\/noindex><\/p>\n

C\u00f4t\u00e9 lumineux<\/h4>\n

\nD\u00e9crire bri\u00e8vement l'argumentation du C\u00f4t\u00e9 lumineux en une phrase : \"Eh, 2019 est dehors !\" Cela peut sembler du populisme, sans aucun doute, mais en approfondissant la question, il y a ses avantages. C'est ce que nous allons explorer maintenant.<\/p>\n

Imaginons que vous ayez un grand projet web. Il a pu \u00eatre initialement construit sur la base d'une approche microservices, ou bien il y est arriv\u00e9 par un chemin \u00e9volutif \u00e0 un moment donn\u00e9 \u2014 cela n'a pas vraiment d'importance, en fait. Vous avez r\u00e9parti votre projet en diff\u00e9rents microservices, configur\u00e9 l'orchestration, l'\u00e9quilibrage de charge, le scaling. Et maintenant, en toute tranquillit\u00e9, vous sirotez un mojito dans un hamac pendant les effets de Habr au lieu de red\u00e9marrer des serveurs tomb\u00e9s. Mais dans toutes ces actions, il faut \u00eatre coh\u00e9rent. Tr\u00e8s souvent, seul le code de l'application elle-m\u00eame est containeris\u00e9. Et qu'avons-nous d'autre en plus du code ?<\/p>\n

C'est exact, les donn\u00e9es. Le c\u0153ur de tout projet ce sont ses donn\u00e9es : cela peut \u00eatre une base de donn\u00e9es typique comme MySQL, Postgre, MongoDB, ou des stockages utilis\u00e9s pour la recherche (ElasticSearch), et des stockages cl\u00e9-valeur pour le caching \u2014 par exemple, redis, etc. Pour le moment, nous ne parlerons pas des solutions de backend probl\u00e9matiques o\u00f9 la base de donn\u00e9es \u00e9choue \u00e0 cause de requ\u00eates mal \u00e9crites, mais nous discuterons plut\u00f4t de la mise en place de la r\u00e9silience de cette base de donn\u00e9es sous la charge des clients. En effet, lorsque nous containerisons notre application et lui permettons de se redimensionner librement pour traiter n'importe quel nombre de requ\u00eates entrantes, cela augmente in\u00e9vitablement la charge sur la base de donn\u00e9es.<\/p>\n

En fait, le canal d'acc\u00e8s \u00e0 la base de donn\u00e9es et le serveur sur lequel elle fonctionne deviennent le goulot d'\u00e9tranglement dans notre magnifique backend containeris\u00e9. Le principal objectif de la virtualisation par conteneur est la mobilit\u00e9 et la flexibilit\u00e9 de la structure, permettant d'organiser la r\u00e9partition de la charge de pointe sur toute l'infrastructure disponible de la mani\u00e8re la plus efficace possible. Ainsi, si nous ne containerisons pas et ne d\u00e9ployons pas tous les \u00e9l\u00e9ments du syst\u00e8me sur un cluster, nous commettons une tr\u00e8s grave erreur.<\/p>\n

Il est beaucoup plus logique de clusteriser non seulement l'application elle-m\u00eame, mais aussi les services charg\u00e9s du stockage des donn\u00e9es. Lors de la clusterisation et du d\u00e9ploiement de serveurs web ind\u00e9pendants qui r\u00e9partissent la charge entre eux dans k8s, nous r\u00e9solvons d\u00e9j\u00e0 le probl\u00e8me de synchronisation des donn\u00e9es \u2014 comme les commentaires sur les publications, pour prendre l'exemple d'un m\u00e9dia ou d'une plateforme de blog. Nous avons de toute fa\u00e7on une repr\u00e9sentation interne du cluster, m\u00eame si elle est virtuelle, de la base de donn\u00e9es en tant que ExternalService. La question est que la base de donn\u00e9es elle-m\u00eame n'est pas encore clusteris\u00e9e \u2014 les serveurs web d\u00e9ploy\u00e9s dans le cluster obtiennent les informations sur les changements de notre base de donn\u00e9es statique qui fonctionne s\u00e9par\u00e9ment.<\/p>\n

Vous sentez un pi\u00e8ge ? Nous utilisons k8s ou Swarm pour r\u00e9partir la charge et \u00e9viter que le principal serveur web<\/a>, mais nous ne faisons pas cela pour la base de donn\u00e9es. Mais si la base de donn\u00e9es tombe, alors il n'y a aucun sens dans notre infrastructure clusteris\u00e9e \u2014 \u00e0 quoi bon des pages web vides qui renvoient une erreur d'acc\u00e8s \u00e0 la base de donn\u00e9es ?<\/p>\n

C'est pourquoi il est n\u00e9cessaire de clusteriser non seulement les serveurs web, comme c'est g\u00e9n\u00e9ralement fait, mais aussi l'infrastructure de la base de donn\u00e9es. Ce n'est qu'ainsi que nous pouvons garantir une structure pleinement fonctionnelle, mais \u00e0 la fois ind\u00e9pendante, qui travaillera ensemble. M\u00eame si la moiti\u00e9 de notre backend \"s'effondre\" sous la charge, l'autre moiti\u00e9 survivra, et le syst\u00e8me de synchronisation de la base de donn\u00e9es entre eux dans le cluster ainsi que la possibilit\u00e9 d'une scalabilit\u00e9 infinie et de d\u00e9ploiement de nouveaux clusters aidera \u00e0 atteindre rapidement les capacit\u00e9s n\u00e9cessaires \u2014 tant qu'il y a des racks dans le centre de donn\u00e9es.<\/p>\n

De plus, le mod\u00e8le de base de donn\u00e9es distribu\u00e9 en clusters permet de d\u00e9placer cette base de donn\u00e9es l\u00e0 o\u00f9 elle est n\u00e9cessaire ; si nous parlons d'un service global, il est assez illogique d'avoir un cluster web quelque part pr\u00e8s de San Francisco tout en dirigeant les paquets vers la base de donn\u00e9es en Russie et de retour.<\/p>\n

De plus, la conteneurisation de la base de donn\u00e9es permet de construire tous les \u00e9l\u00e9ments du syst\u00e8me \u00e0 un m\u00eame niveau d'abstraction. Ce qui, en retour, rend possible la gestion de ce syst\u00e8me directement depuis le code, par les d\u00e9veloppeurs, sans avoir besoin d'impliquer activement les administrateurs. Les d\u00e9veloppeurs ont pens\u00e9 qu'il leur fallait une base de donn\u00e9es distincte pour un nouveau sous-projet \u2014 facile ! ils ont \u00e9crit un fichier yaml, l'ont charg\u00e9 dans le cluster et c'est pr\u00eat.<\/p>\n

Et bien s\u00fbr, l'exploitation interne est simplifi\u00e9e de mani\u00e8re significative. Dites-moi, combien de fois avez-vous ferm\u00e9 les yeux lorsque qu'un nouveau membre de l'\u00e9quipe a tent\u00e9 d'acc\u00e9der \u00e0 la base de donn\u00e9es en production ? Celle que vous avez, au fait, est unique et tourne justement en ce moment ? Bien s\u00fbr, nous sommes tous des adultes ici, et quelque part, nous avons une sauvegarde r\u00e9cente, et plus loin - derri\u00e8re l'\u00e9tag\u00e8re avec les concombres de grand-m\u00e8re et les vieux skis - une autre sauvegarde, peut-\u00eatre m\u00eame sur un stockage froid, parce qu'un jour, votre bureau a d\u00e9j\u00e0 br\u00fbl\u00e9. Mais quand m\u00eame, chaque nouvel ajout \u00e0 l'\u00e9quipe ayant acc\u00e8s \u00e0 l'infrastructure de production et, bien s\u00fbr, \u00e0 la base de donn\u00e9es en production, c'est un seau de valium pour tout le monde. Qui sait, peut-\u00eatre que ce novice est malhabile ? Terrifiant, n'est-ce pas ?<\/p>\n

La conteneurisation et, en fait, la topologie physique distribu\u00e9e de la base de donn\u00e9es de votre projet aident \u00e0 \u00e9viter de tels moments de stress. Vous ne faites pas confiance au d\u00e9butant ? D'accord ! Cr\u00e9ons-lui un cluster \u00e0 lui pour travailler et d\u00e9connectons-le des autres clusters de la base de donn\u00e9es - la synchronisation se fera uniquement par pouss\u00e9e manuelle et activation synchronis\u00e9e de deux cl\u00e9s (une pour le leader, l'autre pour l'administrateur). Et tout le monde est heureux.<\/p>\n

Il est maintenant temps de se transformer en opposants \u00e0 la clusterisation des bases de donn\u00e9es.<\/p>\n

C\u00f4t\u00e9 Obscur<\/h4>\n

\nEn r\u00e9fl\u00e9chissant \u00e0 pourquoi il ne faut pas conteneuriser la base de donn\u00e9es et continuer \u00e0 l'exploiter sur un syst\u00e8me central le serveur<\/a>, ne tombons pas dans la rh\u00e9torique des orthodoxes et dans des affirmations comme \u00ab nos anc\u00eatres faisaient tourner les bases de donn\u00e9es sur du mat\u00e9riel, et nous le ferons ! \u00bb Au lieu de cela, essayons d'imaginer une situation dans laquelle la conteneurisation apporterait vraiment des dividendes significatifs.<\/p>\n

Soyons d'accord, les projets qui n\u00e9cessitent r\u00e9ellement une base dans un conteneur peuvent \u00eatre compt\u00e9s sur les doigts d'une main m\u00eame d'un fraiseur moyen. Dans la plupart des cas, m\u00eame l'utilisation de k8s ou de Docker Swarm est redondante - ces outils sont souvent employ\u00e9s en raison de l'engouement g\u00e9n\u00e9ral pour ces technologies et des conseils d'en haut pour tout passer dans le cloud et les conteneurs. Oui, parce que c'est \u00e0 la mode et que tout le monde le fait.<\/p>\n

Dans au moins la moiti\u00e9 des cas, utiliser Kubernetes ou simplement Docker pour un projet est excessif. Le probl\u00e8me, c'est que toutes les \u00e9quipes ou entreprises de sous-traitance engag\u00e9es pour g\u00e9rer l'infrastructure du client ne se rendent pas compte de cela. Pire encore, lorsque les conteneurs sont impos\u00e9s parce qu'ils co\u00fbtent un certain montant au client.<\/p>\n

En fait, il est commun\u00e9ment admis que la mafia Docker\/Kubernetes \u00e9crase litt\u00e9ralement les clients qui confient ces questions d'infrastructure \u00e0 la sous-traitance. Pour travailler avec des clusters, il faut des ing\u00e9nieurs capables de le faire et qui comprennent l'architecture de la solution mise en place. Nous avons d\u00e9j\u00e0 d\u00e9crit notre cas avec le publication Republic \u2014 l\u00e0, nous avons form\u00e9 l'\u00e9quipe du client \u00e0 travailler dans le contexte de Kubernetes, et tout le monde \u00e9tait satisfait. Et c'\u00e9tait honn\u00eate. Souvent, les 'impl\u00e9menteurs' de Kubernetes prennent l'infrastructure du client en otage \u2014 car maintenant, seuls eux comprennent comment tout fonctionne, alors que le client n'a pas de sp\u00e9cialistes.<\/p>\n

Et maintenant imaginez que nous confions non seulement la partie serveur web \u00e0 la sous-traitance, mais aussi la gestion de la base de donn\u00e9es. Nous avons dit que la base de donn\u00e9es est le c\u0153ur, et perdre le c\u0153ur est fatal pour tout organisme vivant. En gros, les perspectives ne sont pas les meilleures. Donc, au lieu du Kubernetes \u00e0 la mode, de nombreux projets devraient simplement ne pas h\u00e9siter \u00e0 investir dans un tarif normal chez AWS, qui r\u00e9soudrait tous leurs probl\u00e8mes de charge sur leur site\/projet. Mais AWS n'est plus \u00e0 la mode, et les apparences sont plus importantes que l'argent \u2014 malheureusement, c'est aussi le cas dans le domaine de l'informatique.<\/p>\n

D'accord. Peut-\u00eatre que la mise en cluster est r\u00e9ellement n\u00e9cessaire pour le projet, mais si tout est clair avec les applications sans \u00e9tat, comment alors assurer une connectivit\u00e9 r\u00e9seau ad\u00e9quate pour une base de donn\u00e9es en cluster?<\/p>\n

Lorsque nous parlons d'une solution d'ing\u00e9nierie sans couture, qui est ce que repr\u00e9sente la transition vers k8s, notre principale pr\u00e9occupation est la r\u00e9plique des donn\u00e9es dans une base de donn\u00e9es clusteris\u00e9e. Certaines SGBD sont au d\u00e9part assez conciliantes quant \u00e0 la distribution des donn\u00e9es entre leurs diff\u00e9rentes instances. D'autres, en revanche, ne sont pas si accueillants. Et souvent, le principal crit\u00e8re pour choisir un SGBD pour notre projet n'est pas tant sa capacit\u00e9 \u00e0 se r\u00e9pliquer avec des co\u00fbts mat\u00e9riels et d'ing\u00e9nierie minimaux. Surtout si le projet n'\u00e9tait pas initialement pr\u00e9vu comme microservices, mais a simplement \u00e9volu\u00e9 dans cette direction. <\/p>\n

Nous pensons qu'il n'est pas n\u00e9cessaire de parler de la vitesse des disques r\u00e9seau \u2014 ils sont lents. C'est-\u00e0-dire que, s'il y a besoin, nous n'avons pas la possibilit\u00e9 de relancer une instance de SGBD ailleurs, par exemple l\u00e0 o\u00f9 il y a plus de puissance processeur ou de m\u00e9moire vive disponible. Nous allons rapidement atteindre la limite de performance du sous-syst\u00e8me de disques virtualis\u00e9s. En cons\u00e9quence, le SGBD doit \u00eatre attach\u00e9 \u00e0 son propre ensemble de machines personnelles, situ\u00e9es \u00e0 proximit\u00e9 directe. Sinon, il faut trouver un moyen de synchroniser s\u00e9par\u00e9ment les donn\u00e9es assez rapidement vers les r\u00e9serves pr\u00e9vues. <\/p>\n

Pour continuer sur le sujet des syst\u00e8mes de fichiers virtuels : les volumes Docker, malheureusement, ne sont pas sans probl\u00e8me. Dans l'ensemble, pour une t\u00e2che telle que le stockage fiable \u00e0 long terme des donn\u00e9es, il faudrait se contenter de sch\u00e9mas techniques aussi simples que possible. L'ajout d'une nouvelle couche d'abstraction entre le syst\u00e8me de fichiers du conteneur et celui de l'h\u00f4te parent constitue d\u00e9j\u00e0 un risque en soi. Mais quand, en plus, des difficult\u00e9s surgissent dans le syst\u00e8me de conteneurisation concernant la transmission des donn\u00e9es entre ces couches, c'est vraiment probl\u00e9matique. \u00c0 l'heure actuelle, la plupart des probl\u00e8mes connus et progressifs semblent \u00eatre \u00e9radiqu\u00e9s. Mais vous comprenez, plus le m\u00e9canisme est complexe, plus il est susceptible de se briser.<\/p>\n

\u00c0 la lumi\u00e8re de toutes ces \u00ab aventures \u00bb, il est beaucoup plus avantageux et simple de garder la base de donn\u00e9es \u00e0 un seul endroit. M\u00eame si vous avez besoin de la conteneuriser, laissez-la fonctionner de mani\u00e8re autonome et passez par une passerelle de r\u00e9partition pour \u00e9tablir une connexion simultan\u00e9e avec une base de donn\u00e9es qui ne sera lue et \u00e9crite qu'une seule fois, \u00e0 un seul endroit. Cette approche r\u00e9duit la probabilit\u00e9 d'erreurs et de d\u00e9synchronisations au minimum.<\/p>\n

O\u00f9 voulons-nous en venir ? Au fait que la conteneurisation de la base de donn\u00e9es n'est pertinente que l\u00e0 o\u00f9 il y a un vrai besoin. On ne peut pas emballer une base SaaS compl\u00e8te et la faire fonctionner comme si vous aviez une vingtaine de microservices \u2014 \u00e7a ne fonctionne pas ainsi. Et il est crucial de comprendre cela.<\/p>\n

Au lieu d'une conclusion<\/h4>\n

\nSi vous attendez une r\u00e9ponse claire \u00e0 la question \u00ab virtualiser ou non la base de donn\u00e9es \u00bb, nous sommes d\u00e9sol\u00e9s : elle n'existe pas ici. Parce qu'\u00e0 la cr\u00e9ation de toute solution d'infrastructure, il faut se guider non pas par la mode et le progr\u00e8s, mais avant tout, par le bon sens.<\/p>\n

Il existe des projets pour lesquels les principes et outils li\u00e9s \u00e0 Kubernetes s'appliquent parfaitement, et dans de tels projets, il y a une certaine harmonie, au moins dans le domaine du backend. Et puis il y a des projets qui n\u00e9cessitent non pas la conteneurisation, mais une infrastructure serveur normale, car ils ne peuvent tout simplement pas \u00eatre redimensionn\u00e9s selon un mod\u00e8le de cluster microservices, sinon ils \u00e9choueront.
\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e \u043b\u044e\u0431\u043e\u043c\u0443 \u043f\u043e\u0432\u043e\u0434\u0443 \u0440\u0430\u0437\u0431\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0430 \u0434\u0432\u0430 \u0443\u0441\u043b\u043e\u0432\u043d\u044b\u0445 \u043b\u0430\u0433\u0435\u0440\u044f: \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u0437\u0430\u00bb \u0438 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u043f\u0440\u043e\u0442\u0438\u0432\u00bb. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u0441\u043f\u043e\u0440\u043e\u0432 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u044b\u043c. \u041a\u0430\u043a\u0430\u044f \u041e\u0421 \u043b\u0443\u0447\u0448\u0435: Win \u0438\u043b\u0438 Linux? \u041d\u0430 \u0441\u043c\u0430\u0440\u0442\u0444\u043e\u043d\u0435 Android \u0438\u043b\u0438 iOS? \u0425\u0440\u0430\u043d\u0438\u0442\u044c \u0432\u0441\u0435 \u0432 \u043e\u0431\u043b\u0430\u043a\u0430\u0445 \u0438\u043b\u0438 \u0437\u0430\u043b\u0438\u0432\u0430\u0442\u044c \u043d\u0430 \u0445\u043e\u043b\u043e\u0434\u043d\u044b\u0435 RAID-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0438 \u043a\u043b\u0430\u0441\u0442\u044c \u0432\u0438\u043d\u0442\u044b \u0432 \u0441\u0435\u0439\u0444? \u0418\u043c\u0435\u044e\u0442 \u043b\u0438 PHP-\u0448\u043d\u0438\u043a\u0438 \u043f\u0440\u0430\u0432\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34596","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Les bases de donn\u00e9es vivent-elles dans Kubernetes ? | ProHoster","description":"Il s'est historiquement \u00e9tabli que l'industrie IT est.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0416\u0438\u0432\u0443\u0442 \u043b\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Kubernetes? | ProHoster","og:description":"\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:59:16+00:00","article:modified_time":"2019-10-31T18:59:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34596","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 21:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:18:36","updated":"2026-02-09 21:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/34596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}