Je m'appelle Sergey, je viens d'ITSumma et je veux vous dire comment nous abordons la réservation à Kubernetes. Récemment, j'ai effectué de nombreux travaux de conseil sur la mise en œuvre d'une variété de solutions devops pour différentes équipes, et, en particulier, je travaille en étroite collaboration sur des projets utilisant des K8. Lors de la conférence Uptime day 4, dédiée à la redondance dans les architectures complexes, j'ai fait une présentation sur le cube redondant, et voici sa nouvelle version gratuite. Je ne préviendrai qu'à l'avance qu'il n'est pas un guide direct de l'action, mais plutôt une généralisation des réflexions sur ce sujet.
En principe, le suivi et la redondance sont les deux principaux outils pour augmenter la résilience de tout projet. Mais dans le cuber, tout est équilibré par lui-même, dites-vous, tout est mis à l'échelle par lui-même, et si quelque chose se produit, il augmentera de lui-même ... ? " Beaucoup de gens pensent qu'un cuber est une chose tellement magique qui élimine tous les problèmes d'infrastructure et fait que le projet ne tombe jamais. Mais ... le monde n'est pas ce qu'il semble.
Comment avons-nous abordé le processus de sauvegarde auparavant? Nous avions des plates-formes de placement identiques - soit des machines virtuelles, soit des serveurs de fer, auxquels nous avons appliqué trois pratiques de base:
- synchronisation de code et statique
- synchronisation de la configuration
- réplication de base de données
Et le tour est joué: à tout moment on passe au site de réserve, tout le monde est content, on se lève, on n'est pas d'accord.
Et que nous proposent-ils pour augmenter la disponibilité constante de notre application kubernetes? La première chose que dit la documentation non officielle est de mettre beaucoup de machines, de faire beaucoup de maîtres - leur nombre doit satisfaire les conditions pour atteindre un quorum au sein du cluster, et pour que etcd, api, MC, le planificateur soit élevé sur chacun des maîtres ... Et, il semble, tout va bien : lorsque plusieurs nœuds ou maîtres actifs échouent, notre cluster est rééquilibré et l'application continue de fonctionner. Ressemble à nouveau à la magie! Mais souvent, notre cluster est situé dans le même centre de données, ce qui peut poser certaines questions. Et si une excavatrice arrivait et détenait un câble, la foudre frappait, il y avait une inondation universelle? Tout est couvert, notre cluster n'est plus. Comment aborder la réservation en tenant compte de ce côté du problème?
Tout d'abord, vous devez avoir un autre cluster dans la réserve chaude, c'est-à-dire un cluster auquel vous pouvez basculer à tout moment. En même temps, du point de vue du cuber, les infrastructures doivent être complètement identiques. Autrement dit, s'il existe des plugins non standard pour travailler avec le système de fichiers, des solutions personnalisées pour l'entrée, ils devraient être complètement identiques sur vos deux (ou trois, ou dix, il y a assez d'argent et de force d'administrateur). Il est nécessaire de définir clairement deux ensembles d'applications (deployment'ov, statefulset'ov, daemonset'ov, cronjob'ov, etc.): lesquels d'entre eux peuvent fonctionner en permanence sur une réserve, et lesquels sont préférables de ne pas démarrer avant la commutation directe.
Notre cluster de sauvegarde doit-il donc être complètement identique à notre cluster de combat? Non. Auparavant, dans le cadre du travail avec des projets monolithiques, avec des infrastructures en fer, nous avons gardé un environnement presque complètement identique, mais dans le cadre du cuber, je pense que cela ne devrait pas être le cas. Voyons pourquoi.
Par exemple, commençons par les entités de base de kubernetes - les déploiements - elles doivent être identiques. Des applications devraient être lancées qui peuvent intercepter le traitement du trafic à tout moment et permettre à notre projet de continuer à vivre. Si nous parlons de fichiers de configuration, nous devons voir ici s'ils doivent être identiques ou non. Autrement dit, si nous, les gens intelligents, n'utilisons aucune substance interdite et ne gardons pas la base dans les K8, alors dans les cartes de configuration, nous devrions avoir des paramètres d'accès à la base de combat (dont le processus de sauvegarde est construit séparément). Par conséquent, pour garantir l'accès à l'instance de base de données de sauvegarde, nous devons disposer d'un fichier de configuration distinct (configmap). Exactement de la même manière que nous travaillons avec les secrets: mots de passe pour accéder à la base de données, clés api; à tout moment, un secret de combat ou une réserve, on peut travailler avec nous. Au total, nous avons déjà deux entités kubernetes dont les versions de sauvegarde ne doivent pas être identiques à celles de combat. La prochaine entité qui mérite d'être étudiée est cronjob. Les cronjobs en réserve ne doivent en aucun cas être identiques à l'ensemble des clusters de production de cronjobs! Si nous augmentons le cluster de sauvegarde et l'élévons complètement avec tous les cronjob activés, alors, par exemple, les gens recevront deux lettres de vous en même temps au lieu d'une. Ou une sorte de synchronisation des données avec des sources externes aura lieu deux fois, respectivement, nous commençons à nous blesser, à pleurer, à crier et à jurer.
Mais comment les internautes nous proposent-ils d'organiser un cluster de sauvegarde? La deuxième réponse la plus populaire après «pourquoi?» - utilisation de la Fédération Kubernetes.
Qu'est ce que c'est Il s'agit, disons, d'un grand méta-cluster. Si nous imaginons l'architecture du cuber - où nous avons un maître, plusieurs nœuds - alors du point de vue de la fédération, nous avons aussi un maître et plusieurs nœuds, seul chaque nœud est un cluster séparé. Autrement dit, nous travaillons avec les mêmes entités, avec les mêmes primitives qu'avec un seul cuber, mais nous tournons et tournons non pas nos machines physiques, mais des grappes entières. Dans le cadre de la fédération, nous sommes en totale synchronisation des ressources fédérales des parents aux descendants. Par exemple, si nous avons lancé un déploiement via la fédération, il sera déployé sur chacun de nos clusters subsidiaires. Si nous prenons une configmap, le secret est de la faire rouler vers la fédération - elle se répandra dans tous nos clusters enfants; en même temps, la fédération nous permet de personnaliser nos ressources pour les enfants. Autrement dit, nous avons pris une configmap, l'avons déployée via la fédération, puis, si nous devons corriger quelque chose sur des clusters spécifiques, nous allons éditer sur un cluster séparé, et cette modification ne sera synchronisée nulle part.
La Fédération Kubernetes n'est pas si longtemps un outil existant et ne prend pas en charge l'ensemble des ressources que K8 fournit lui-même: au moment de la publication de l'une des premières versions de la documentation, il s'agissait de ne prendre en charge que les cartes de configuration, le déploiement d'un jeu de répliques, l'entrée. Les secrets n'étaient pas pris en charge, le travail avec le volume n'était pas non plus pris en charge. Ensemble trop limité. Surtout si nous aimons nous amuser, par exemple, grâce à la définition de ressource personnalisée pour transférer nos propres ressources vers les kubernetes, nous ne les poussons pas dans la fédération. C'est, pour ainsi dire ... une décision très similaire à la vérité, mais elle nous fait périodiquement nous tirer une balle dans le pied. D'autre part, la fédération vous permet de gérer de manière flexible notre jeu de répliques. Par exemple, nous voulons que 10 répliques de notre application soient lancées, par défaut, la fédération divisera ce nombre proportionnellement entre le nombre de clusters. Et tout cela peut également être configuré! Autrement dit, vous pouvez spécifier que vous devez conserver 6 répliques de notre application sur le cluster de combat, et seulement 4 répliques de notre application sur le cluster de sauvegarde, pour économiser des ressources ou pour votre propre divertissement. Ce qui est également assez pratique. Mais avec la fédération, nous devons utiliser de nouvelles solutions, terminer quelque chose en cours et nous forcer à réfléchir un peu plus ...
Est-il possible d'aborder le processus de réservation d'un cuber en quelque sorte plus simplement? Quels outils avons-nous du tout?
Premièrement, nous avons toujours une sorte de système ci / cd, c'est-à-dire que nous ne faisons pas le tour manuellement, n'écrivons pas créer / appliquer sur les serveurs. Le système génère des yaml'ics pour nos conteneurs.
Deuxièmement, il existe plusieurs clusters, nous avons un ou plusieurs registres (si nous sommes intelligents), que nous avons également pris et réservés. Et il existe un merveilleux utilitaire kubectl qui peut fonctionner avec plusieurs clusters simultanément.
Donc: à mon avis, la solution la plus simple et la plus correcte pour créer un cluster de sauvegarde est un déploiement parallèle primitif. Il existe une sorte de pipeline dans le système ci / cd; nous construisons d'abord nos conteneurs, testons et déployons des applications via kubectl vers plusieurs clusters indépendants. Nous pouvons construire des calculs simultanés sur plusieurs clusters. En conséquence, nous décidons également de livrer des configurations à ce stade. Vous pouvez prédéfinir l'ensemble de configurations pour notre cluster de combat, l'ensemble de configurations pour le cluster de sauvegarde et au niveau ci / cd du système rouler le pro-environnement vers le pro-cluster, l'environnement de sauvegarde vers le cluster de sauvegarde. Par rapport à la fédération, vous n'avez pas besoin de définir une ressource fédérale pour chaque cluster enfant et de redéfinir quelque chose. Nous l'avons fait à l'avance. Quels bons amis nous sommes.
Mais ... il y a ... j'ai écrit, il y a la "racine de tout mal", mais il y en a en fait deux. Le premier est le système de fichiers. Il existe une sorte de PV, ou nous utilisons un stockage externe. Si nous stockons des fichiers à l'intérieur du cluster, nous devons suivre les anciennes pratiques laissées par les infrastructures de fer: par exemple, synchroniser avec lsync. Eh bien, ou toute autre béquille que vous préférez personnellement. Nous roulons tout sur d'autres voitures et vivons.
Deuxièmement, et, en fait, une pierre d'achoppement encore plus importante est la base de données. Si nous sommes des gens intelligents et que nous ne gardons pas la base de données dans le cube, le processus de sauvegarde des données selon le même ancien schéma est la réplication maître-esclave, puis la commutation, nous rattraperons la réplique et nous vivrons bien. Mais si nous gardons notre base de données à l'intérieur du cluster, il existe en principe de nombreuses solutions toutes faites pour organiser la même réplique maître-esclave, de nombreuses solutions pour élever la base de données à l'intérieur du cube.
Un milliard de rapports ont déjà été lus sur les sauvegardes de bases de données, un milliard d'articles ont été écrits, rien de nouveau n'est nécessaire ici, en fait. En général, suivez votre rêve, vivez comme vous le souhaitez, inventez aussi des béquilles compliquées, mais pensez à la façon dont vous réserverez tout cela.
Et maintenant, comment en principe, nous aurons le processus de basculement vers le site de sauvegarde en cas d'incendie. Tout d'abord, nous déployons des applications sans état en parallèle. Ils n'affectent pas la logique métier de nos applications, notre projet, nous pouvons constamment garder deux ensembles d'applications en cours d'exécution, et ils peuvent commencer à recevoir du trafic. Il est très important dans le processus de basculement vers le site de sauvegarde de voir définitivement si les configurations doivent être redéfinies Par exemple, nous avons un cluster de vente kubernetes, un cluster de sauvegarde kubernetes, une base de données maître externe et une base de données maître de sauvegarde. Nous avons quatre options sur la façon dont ces applications dans le prod peuvent commencer à interagir les unes avec les autres. Notre base peut changer, et il s'avère que nous devons transférer le trafic vers la nouvelle base dans le cluster prod, ou nous pouvons obtenir le cluster et nous sommes passés à la réserve, mais nous continuons à travailler avec la base pro, enfin, la troisième option, quand nous l'avons , puis c'est foutu, et nous changeons les deux applications, redéfinissons notre configuration pour que les nouvelles applications fonctionnent déjà avec la nouvelle base de données.
Eh bien, en fait, quelles conclusions peut-on tirer de tout cela?
Première conclusion: bien vivre avec une réserve. Mais cher. Mais idéalement, vivre avec plus d'une réserve. Idéalement, vous devez généralement vivre avec plusieurs réserves. Premièrement, la réserve ne devrait pas être au moins dans un DC, et deuxièmement, au moins, dans un autre hébergeur. Cela arrivait souvent - et dans ma pratique, ça l'était. Malheureusement, je ne peux pas nommer les projets, juste au moment où il y a eu un incendie dans le centre de données ... Je suis comme ça: on passe à la réserve! Et les serveurs de sauvegarde dans le même rack se tenaient ...
Ou imaginez qu'Amazon a été interdit en Russie (et c'était le cas). Et tout: le sens du fait que dans une autre amazone se trouve notre réserve? Il est également indisponible. Je répète donc: nous gardons la réserve, au moins, dans un autre DC, et de préférence avec un autre hôte.
Deuxième conclusion: si votre application communique avec certaines sources externes (il peut s'agir d'une base de données ou d'une API externe), assurez-vous de la définir comme un service avec un point de terminaison externe afin de ne pas avoir à le réparer au moment du basculement 15 de vos applications qui frappent sur la même base. Définissez la base de données en tant que service distinct, frappez dessus comme si elle se trouvait à l'intérieur de votre cluster: si vous avez une base de données, vous changez ip en un seul endroit et continuez à vivre heureux.
Et enfin: j'adore le «cube», ainsi que ses expériences. J'aime aussi partager les résultats de ces expériences et, en général, mon expérience personnelle. Par conséquent, j'ai enregistré une série de webinaires sur les K8, bien sur
notre chaîne YouTube pour plus de détails.