r\u00e9plication de bases de donn\u00e9es<\/li>\n<\/ol>\n\nEt voil\u00e0 : \u00e0 tout moment, nous basculons vers la plateforme de sauvegarde, tout le monde est heureux, nous nous levons et nous nous \u00e9loignons. <\/p>\n
Avant tout, vous devez avoir un autre cluster en r\u00e9serve chaude, c'est-\u00e0-dire un cluster vers lequel vous pouvez basculer \u00e0 tout moment. Du point de vue de Kubernetes, les infrastructures doivent \u00eatre totalement identiques. Cela signifie que s'il existe des plugins non standards pour travailler avec le syst\u00e8me de fichiers, des solutions personnalis\u00e9es pour l'ingress, elles doivent \u00eatre compl\u00e8tement identiques sur vos deux (ou trois, ou dix, selon vos moyens financiers et la disponibilit\u00e9 des administrateurs) clusters. Il est n\u00e9cessaire de d\u00e9finir clairement deux ensembles d'applications (d\u00e9ploiements, statefulsets, daemonsets, cronjobs, etc.) : lesquels peuvent fonctionner en r\u00e9serve en permanence, et lesquels vaut mieux ne pas lancer avant un basculement imm\u00e9diat. <\/p>\n
Notre cluster de secours doit-il \u00eatre compl\u00e8tement identique \u00e0 notre cluster de production ? Non. Alors que, dans le cadre de projets monolithiques avec une infrastructure mat\u00e9rielle, nous maintenions des environnements presque totalement identiques, cela ne doit pas \u00eatre le cas avec Kubernetes. Voyons pourquoi.<\/p>\n
Par exemple, commen\u00e7ons par les entit\u00e9s de base de Kubernetes \u2014 les d\u00e9ploiements \u2014 elles doivent \u00eatre identiques. Des applications doivent \u00eatre lanc\u00e9es, capables de prendre \u00e0 tout moment le relais du traitement du trafic et de permettre \u00e0 notre projet de continuer \u00e0 vivre. Si nous parlons de fichiers de configuration, il faut examiner s'ils doivent \u00eatre identiques ou non. Autrement dit, si nous, des personnes sens\u00e9es, ne consommons pas de substances interdites et ne gardons pas la base dans K8s, alors nous devons avoir dans nos configmaps des param\u00e8tres d\u2019acc\u00e8s \u00e0 la base de donn\u00e9es de production (le processus de sauvegarde de celle-ci \u00e9tant mis en place s\u00e9par\u00e9ment). Ainsi, pour garantir l'acc\u00e8s \u00e0 l'instance de sauvegarde de la base de donn\u00e9es, nous devons disposer d'un fichier de configuration s\u00e9par\u00e9 (configmap). De la m\u00eame mani\u00e8re, nous traitons les secrets : les mots de passe d'acc\u00e8s \u00e0 la base, les cl\u00e9s API ; \u00e0 tout moment, nous pouvons avoir soit un secret de production, soit un secret de secours. Ainsi, nous avons d\u00e9j\u00e0 deux entit\u00e9s Kubernetes, dont les versions de secours ne doivent pas \u00eatre identiques aux versions de production. La prochaine entit\u00e9 sur laquelle il est crucial de s'arr\u00eater est le cronjob. Les cronjobs de secours ne doivent en aucun cas \u00eatre identiques \u00e0 l'ensemble des cronjobs du cluster de production ! Si nous mettons en place un cluster de secours et que nous le configurons enti\u00e8rement avec tous les cronjobs activ\u00e9s, par exemple, les gens recevront deux courriels \u00e0 la fois au lieu d'un seul. Ou une synchronisation des donn\u00e9es avec des sources externes se produira deux fois, ce qui nous fera donc souffrir, pleurer, crier et nous f\u00e2cher. <\/p>\n
Qu'est-ce que c'est ? C'est, disons, un grand m\u00e9ta-cluster. Si nous imaginons l'architecture de Kubernetes \u2014 o\u00f9 nous avons un ma\u00eetre, plusieurs n\u0153uds \u2014 du point de vue de la f\u00e9d\u00e9ration, nous avons aussi un ma\u00eetre et plusieurs n\u0153uds, sauf que chaque n\u0153ud est un cluster distinct. Cela signifie que nous travaillons avec les m\u00eames entit\u00e9s, avec les m\u00eames primitives, que pour un seul Kubernetes, sauf que nous manipulons non pas nos machines physiques, mais de v\u00e9ritables clusters. Dans le cadre de la f\u00e9d\u00e9ration, nous avons une synchronisation compl\u00e8te des ressources f\u00e9d\u00e9ratives entre les parents et les descendants. Par exemple, si nous avons lanc\u00e9 un d\u00e9ploiement via la f\u00e9d\u00e9ration \u2014 il ser\u00e1 d\u00e9ploy\u00e9 sur chacun de nos clusters enfants. Si nous prenons un configmap ou un secret et que nous le d\u00e9ployons via la f\u00e9d\u00e9ration \u2014 il se propage \u00e0 tous nos clusters enfants ; tout en permettant \u00e0 la f\u00e9d\u00e9ration de personnaliser nos ressources sur les enfants. Ainsi, nous avons pris un configmap, l'avons d\u00e9ploy\u00e9 via la f\u00e9d\u00e9ration et ensuite, si nous avons besoin de modifier quelque chose sur des clusters sp\u00e9cifiques, nous allons ajuster sur le cluster particulier, et ce changement ne sera plus synchronis\u00e9 nulle part. <\/p>\n
Kubernetes Federation est un outil relativement r\u00e9cent qui ne supporte pas encore l'ensemble des ressources que fournit K8s. \u00c0 l'\u00e9poque de la publication d'une des premi\u00e8res versions de la documentation, il \u00e9tait indiqu\u00e9 que seuls les ConfigMaps, le d\u00e9ploiement sous ReplicaSet et l'Ingress \u00e9taient pris en charge. Les secrets n'\u00e9taient pas support\u00e9s, tout comme le travail avec les volumes. L'ensemble des fonctionnalit\u00e9s est donc trop limit\u00e9. Surtout si nous aimons exp\u00e9rimenter, par exemple, en transmettant nos propres ressources \u00e0 Kubernetes via des d\u00e9finitions de ressources personnalis\u00e9es, nous ne pourrons pas les inclure dans la f\u00e9d\u00e9ration. En d'autres termes, c'est une solution qui semble presque vraie mais qui nous pousse \u00e0 nous tirer des balles dans le pied. D'un autre c\u00f4t\u00e9, la f\u00e9d\u00e9ration permet de g\u00e9rer de mani\u00e8re flexible notre ReplicaSet. Par exemple, nous souhaitons avoir 10 r\u00e9pliques de notre application, et par d\u00e9faut, la f\u00e9d\u00e9ration r\u00e9partira ce nombre proportionnellement entre les diff\u00e9rents clusters. Et tout cela est \u00e9galement configurable ! En d'autres termes, nous pouvons indiquer que sur le cluster de production, nous devons maintenir 6 r\u00e9pliques de notre application, tandis que sur le cluster de secours, pour \u00e9conomiser des ressources ou pour notre propre divertissement, seulement 4 r\u00e9pliques de notre application. Ce qui est \u00e9galement assez pratique. Mais avec la f\u00e9d\u00e9ration, nous devons utiliser certaines nouvelles solutions, d\u00e9ployer certains \u00e9l\u00e9ments \u00e0 la vol\u00e9e, et nous forcer \u00e0 r\u00e9fl\u00e9chir un peu plus... <\/p>\n
Peut-on aborder le processus de r\u00e9servation de Kubernetes d'une mani\u00e8re plus simple ? Quels outils avons-nous \u00e0 notre disposition ?<\/p>\n
Tout d'abord, nous avons toujours un syst\u00e8me CI\/CD, ce qui signifie que nous ne devons pas nous rendre manuellement sur les serveurs pour \u00e9crire des create\/apply. Le syst\u00e8me g\u00e9n\u00e8re des fichiers yaml pour nos conteneurs. <\/p>\n
Deuxi\u00e8mement, nous avons plusieurs clusters, avec soit un seul, soit plusieurs (si nous sommes pr\u00e9voyants) registries que nous avons \u00e9galement r\u00e9serv\u00e9s. Et il existe une merveilleuse utilitaire kubectl qui peut fonctionner avec plusieurs clusters simultan\u00e9ment. <\/p>\n
Mais... il y a... je l'ai \u00e9crit, il y a en fait \"deux racines de tous les maux\". Tout d'abord, le syst\u00e8me de fichiers. Il y a un certain PV, ou nous utilisons un stockage externe. Si nous stockons des fichiers \u00e0 l'int\u00e9rieur du cluster, il faut revenir aux anciennes pratiques h\u00e9rit\u00e9es des infrastructures mat\u00e9rielles : par exemple, synchroniser avec lsync. Ou tout autre rustine que vous pr\u00e9f\u00e9rez personnellement. Nous d\u00e9ployons tout sur d'autres machines et continuons \u00e0 vivre.<\/p>\n
Deuxi\u00e8mement, et c'est en r\u00e9alit\u00e9 un point d'accroche encore plus important \u2014 la base de donn\u00e9es. Si nous sommes des gens intelligents et ne maintenons pas la base dans Kubernetes, alors le processus de sauvegarde des donn\u00e9es selon l'ancien sch\u00e9ma \u2014 r\u00e9plication master-esclave, puis basculement, nous rattraperons la r\u00e9plique et nous vivrons bien. Mais si nous maintenons notre base de donn\u00e9es \u00e0 l'int\u00e9rieur du cluster, il existe en principe de nombreuses solutions pr\u00eates \u00e0 l'emploi pour organiser la m\u00eame r\u00e9plication master-esclave, de nombreuses solutions pour mettre en place une base de donn\u00e9es \u00e0 l'int\u00e9rieur de Kubernetes.
Maintenant, parlons de la fa\u00e7on dont nous allons proc\u00e9der au basculement vers le site de secours en cas d'incendie. Tout d'abord, nous d\u00e9ployons en parall\u00e8le des applications stateless. Celles-ci n'affectent pas la logique commerciale de nos applications, de notre projet ; nous pouvons maintenir en permanence deux ensembles d'applications en cours d'ex\u00e9cution, pr\u00eates \u00e0 recevoir du trafic. Il est tr\u00e8s important, lors du basculement vers le site de secours, de v\u00e9rifier si les configurations doivent \u00eatre red\u00e9finies. Par exemple, nous avons un cluster Kubernetes en production, un cluster Kubernetes de secours, une base de donn\u00e9es principale externe et une base de donn\u00e9es principale de secours. Nous avons quatre options quant \u00e0 la mani\u00e8re dont ces applications en production peuvent interagir entre elles. La base de donn\u00e9es peut basculer, et il s'av\u00e8re qu'il est n\u00e9cessaire de rediriger le trafic vers la nouvelle base dans le cluster de production, ou bien le cluster peut planter \u2014 et nous passons sur le secours, tout en continuant \u00e0 travailler avec la base production. Il y a aussi la troisi\u00e8me option, o\u00f9 il y a eu une d\u00e9faillance ici et l\u00e0, et nous redirigeons les deux applications, red\u00e9finissant notre configuration, afin que les nouvelles applications fonctionnent d\u00e9j\u00e0 avec la nouvelle base de donn\u00e9es. <\/p>\n
Alors, quelles conclusions peut-on tirer de tout cela ? <\/p>\n
Ou imaginez que Amazon soit interdit en Russie (et cela a d\u00e9j\u00e0 eu lieu). Et voil\u00e0 : \u00e0 quoi bon que notre r\u00e9serve soit dans un autre Amazon ? Elle est \u00e9galement inaccessible. Donc, je le r\u00e9p\u00e8te : gardons une r\u00e9serve, au minimum dans un autre centre de donn\u00e9es, et de pr\u00e9f\u00e9rence \u2014 chez un autre h\u00e9bergeur. <\/p>\n
Deuxi\u00e8me conclusion : si votre application sous Kubernetes communique avec des sources externes (cela peut \u00eatre une base de donn\u00e9es ou un API externe), d\u00e9finissez-la absolument comme un service avec un Endpoint externe, pour \u00e9viter de red\u00e9ployer 15 de vos applications qui touchent \u00e0 la m\u00eame base au moment du changement. D\u00e9finissez la base comme un service distinct et connectez-vous \u00e0 elle comme si elle \u00e9tait \u00e0 l'int\u00e9rieur de votre cluster : si votre base plante, vous modifiez l'IP \u00e0 un seul endroit et continuez \u00e0 vivre heureux. <\/p>\n
Et enfin : j'aime \u00ab le cube \u00bb, tout comme les exp\u00e9riences qui l'entourent. J'aime \u00e9galement partager les r\u00e9sultats de ces exp\u00e9riences et mon exp\u00e9rience personnelle en g\u00e9n\u00e9ral. C'est pourquoi j'ai enregistr\u00e9 une s\u00e9rie de webinaires sur K8s, bienvenue sur notre cha\u00eene YouTube<\/a><\/noindex> pour plus de d\u00e9tails. habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0421\u0435\u0440\u0433\u0435\u0439, \u044f \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 ITSumma, \u0438 \u044f \u0445\u043e\u0447\u0443 \u0432\u0430\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u043c \u043a \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 Kubernetes. \u0412 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u0435 \u0432\u0440\u0435\u043c\u044f \u044f \u043c\u043d\u043e\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c \u043a\u043e\u043d\u0441\u0443\u043b\u044c\u0442\u0430\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u043e\u0439 \u043f\u043e \u0432\u043d\u0435\u0434\u0440\u0435\u043d\u0438\u044e \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u044b\u0445 devops-\u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u0434\u043b\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043a\u043e\u043c\u0430\u043d\u0434, \u0438, \u0432 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u043f\u043b\u043e\u0442\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u043f\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c \u0441 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435\u043c K8s. \u041d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 Uptime day 4, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0431\u044b\u043b\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0432 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25449,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33773","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"La](\"\/wp-content\/uploads\/2019\/05\/4797b240a8e9fd4bbbce4370b9b44108.png\")