{"id":33773,"date":"2019-10-31T21:54:36","date_gmt":"2019-10-31T18:54:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervirovanie-v-kubernetes-ono-sushhestvuet\/"},"modified":"2019-10-31T21:54:36","modified_gmt":"2019-10-31T18:54:36","slug":"rezervirovanie-v-kubernetes-ono-sushhestvuet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Back-up in Kubernetes: het bestaat","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mijn naam is Sergey, ik kom van ITSumma en ik wil u vertellen hoe wij het reserveren in Kubernetes benaderen. De laatste tijd houd ik me veel bezig met advieswerk over de implementatie van verschillende devops-oplossingen voor diverse teams, en specifiek werk ik nauw samen aan projecten met K8s. Tijdens de Uptime Day 4-conferentie, die gewijd was aan reserveren in complexe architecturen, presenteerde ik een lezing over het reserveren van de \"kubus\", en hier is een vrije samenvatting ervan. Maar ik waarschuw u vooraf dat het geen directe handleiding is, maar eerder een samenvatting van gedachten over het onderwerp.<\/p>\n

\"Back-up
\n
\nIn principe zijn monitoring en reserveren twee essenti\u00eble instrumenten voor het verhogen van de fouttolerantie van elk project. Maar u zegt misschien, in K8s balanceert alles zichzelf, alles schaalt vanzelf, en als er iets gebeurt, zal het zichzelf weer opstarten... Dus, bij een oppervlakkig onderzoek van het onderwerp, gaf het internet mij als antwoord op de vraag hoe mensen het reserveren in K8s benaderen: \"waarom?\" Veel mensen denken dat K8s een soort magische oplossing is die alle infrastructuurproblemen oplost en ervoor zorgt dat een project nooit uitvalt. Maar... de wereld is niet wat ze lijkt.
\n<\/a><\/noindex>
\nHoe zijn we vroeger met het reserveringsproces omgegaan? We hadden identieke platforms voor hosting - of het waren virtuele machines, of het waren fysieke servers servers<\/a>, waar we drie basale praktijken op toepasten: <\/p>\n

    \n
  1. code en statische bestanden synchroniseren<\/li>\n
  2. configuraties synchroniseren<\/li>\n
  3. database replicatie<\/li>\n<\/ol>\n

    \nEn voila: op elk moment kunnen we overschakelen naar het reserveplatform, iedereen is blij, we staan op en gaan uiteen. <\/p>\n

    \"Back-up
    \n
    \nWat wordt er voorgesteld om de constante beschikbaarheid van onze Kubernetes-applicatie te vergroten? Het eerste wat de niet-offici\u00eble documentatie zegt, is dat je veel machines moet zetten, veel masters moet hebben \u2014 het aantal moet voldoen aan de voorwaarden voor quorum binnen de cluster, en op elke master moet etcd, api, MC, scheduler\u2026 draaien. En het lijkt geweldig: wanneer een aantal werkknopen of masters uitvalt, wordt onze cluster opnieuw in balans gebracht en blijft de applicatie draaien. Het lijkt opnieuw magie! Maar vaak bevindt onze cluster zich binnen \u00e9\u00e9n datacenter en dat kan bepaalde vragen oproepen. Wat als er een graafmachine aan komt rijden en een kabel opgraaft, een bliksem inslaat, of een wereldwijde overstroming plaatsvindt? Alles is verloren, onze cluster is er niet meer. Hoe moeten we het opnemen voor redundantie met het oog op dit probleem? <\/p>\n

    In de eerste plaats moet je een andere cluster in warme reserve hebben, dat wil zeggen een cluster waarop je op elk moment kunt overschakelen. Wat betreft Kubernetes moeten de infrastructuren volledig identiek zijn. Dus als er standaard plugins zijn voor het werken met het bestandssysteem, aangepaste oplossingen voor ingress, moeten deze volledig identiek zijn op je twee (of drie, of tien, afhankelijk van hoeveel geld en middelen de beheerders hebben) clusters. Het is noodzakelijk om twee sets applicaties (deployments, statefulsets, daemonsets, cronjobs, enz.) duidelijk te defini\u00ebren: welke daarvan continu op de reserve kunnen draaien, en welke je beter niet kunt starten totdat de daadwerkelijke overschakeling plaatsvindt. <\/p>\n

    Moet onze reservecluster volledig identiek zijn aan onze productiecluster? Nee. Als we eerder binnen monolithische projecten, met fysieke infrastructuur, vrijwel volledig identieke omgevingen handhaafden, denk ik dat dit binnen Kubernetes niet nodig is. Laten we eens bekijken waarom.<\/p>\n

    Bijvoorbeeld, laten we beginnen met de basisentiteiten van Kubernetes - deployments - ze moeten identiek zijn. Applicaties moeten draaien die op elk moment de verwerking van verkeer kunnen overnemen en ons project in leven kunnen houden. Als we het hebben over configuratiebestanden, moeten we bekijken of ze identiek moeten zijn of niet. Dat wil zeggen, als we slimme mensen zijn die geen verboden middelen gebruiken en de database niet in K8s houden, dan moeten we in de configmaps de toegang instellingen hebben tot de productie database (het proces van back-up is apart georganiseerd). Daarom moeten we voor de toegang tot de back-up versie van de database een apart configuratiebestand (configmap) hebben. Op dezelfde manier werken we met secrets: wachtwoorden voor database toegang, API-sleutels; op elk gegeven moment kan ofwel de productie secret, ofwel de back-up actief zijn. Dus hebben we nu al twee Kubernetes-entiteiten, waarvan de back-up versies niet identiek mogen zijn aan de productieversies. De volgende entiteit waar we bij stil moeten staan is de cronjob. Cronjobs in de back-up mogen in geen geval identiek zijn aan de set cronjobs van de productiecluster! Als we een back-up cluster opzetten en dit volledig opbouwen met alle ingeschakelde cronjobs - dan zouden mensen bijvoorbeeld twee e-mails tegelijkertijd van jou ontvangen in plaats van \u00e9\u00e9n. Of een datasychronisatie met externe bronnen zal twee keer plaatsvinden, waardoor we beginnen te lijden, te huilen, te schreeuwen en te schelden. <\/p>\n

    \"Back-up
    \n
    \nEn hoe stellen mensen op het internet voor om een reserve cluster te organiseren? Het op \u00e9\u00e9n na populairste antwoord na \"waarom?\" is het gebruik van Kubernetes Federation. <\/p>\n

    Wat is dit? Dit is een grote meta-cluster. Als we de architectuur van Kubernetes voorstellen \u2014 waar we een master en meerdere nodes hebben \u2014 hebben we ook vanuit het perspectief van federatie een master en meerdere nodes, waarbij elke node een aparte cluster is. Dit betekent dat we met dezelfde entiteiten en primitieven werken als met een enkele Kubernetes-cluster, maar dan niet met onze fysieke machines, maar met complete clusters. Binnen de federatie is er volledige synchronisatie van federatieve resources van ouders naar kinderen. Bijvoorbeeld, als we een bepaalde deployment via de federatie hebben gestart, wordt deze op elke dochtercluster gedeployed. Als we een configmap of secret nemen en deze via de federatie verspreiden, wordt het naar al onze dochterclusters verspreid; tegelijkertijd stelt de federatie ons in staat om onze resources op de kinderen aan te passen. Dit betekent dat we een bepaalde configmap via de federatie hebben gedeployed en als we vervolgens iets willen aanpassen op specifieke clusters, gaan we de wijzigingen aanbrengen op de afzonderlijke cluster en deze wijziging zal niet verder gesynchroniseerd worden. <\/p>\n

    Kubernetes Federation is a relatively recent tool, and it doesn\u2019t support the full range of resources provided by K8s itself: at the time of publishing one of the first versions of the documentation, it mentioned support only for config maps, deployment under replica set, and ingress. Secrets were not supported, and volume management was also not supported. A very limited set. Especially if we like to have fun\u2014 for example, passing our own resources to Kubernetes through a custom resource definition\u2014 we can't push them into the federation. So it\u2019s kind of\u2026 a decision that seems almost truthful, but makes us occasionally shoot ourselves in the foot. On the other hand, the federation allows us to manage our replicaset flexibly. For example, if we want to run 10 replicas of our application, by default, the federation will distribute this number proportionally among the clusters. And this can also be configured! Thus, we can specify that our production cluster needs to maintain 6 replicas of our application, while on the backup cluster, for resource saving or for our own entertainment\u2014 only 4 replicas of our application. Which is also quite convenient. However, with the federation, we have to use some new solutions, deploy something on the fly, making us think just a bit more\u2026 <\/p>\n

    Is there a simpler way to approach the process of reserving Kubernetes? What tools do we actually have?<\/p>\n

    First of all, we always have some sort of CI\/CD system, which means we do not manually access the servers to write create\/apply commands. The system generates YAML files for our containers. <\/p>\n

    Secondly, there are several clusters; we either have one or multiple (if we are smart) registries that we have also reserved. And we have a wonderful utility called kubectl, which can work with multiple clusters simultaneously. <\/p>\n

    \"Back-up
    \n
    \nDus, naar mijn mening is de eenvoudigste en meest betrouwbare oplossing voor het opzetten van een back-upcluster een primitieve parallelle deploy. Er is een pipeline in het CI\/CD-systeem; we bouwen eerst onze containers, testen en rollen de applicaties uit via kubectl naar meerdere onafhankelijke clusters. We kunnen gelijktijdige uitrol naar meerdere clusters uitvoeren. Bijgevolg lossen we ook de levering van configuraties op in deze fase. We kunnen vooraf een set configuraties voor ons productieve cluster defini\u00ebren, een set configuraties voor het back-upcluster, en op het niveau van het CI\/CD-systeem kunnen we de productie-omgeving naar het productiecluster uitrollen, de back-upomgeving naar het back-upcluster. In tegenstelling tot een federatie hoeven we, na het bepalen van de federatieve resource, niet naar elk subcluster te gaan en iets te herdefini\u00ebren. We hebben dit van tevoren gedaan. Wat zijn wij geweldig.<\/p>\n

    But\u2026 there are\u2026 I could say there is the 'root of all evil,' but in fact, there are two. Firstly, there is the file system. There\u2019s some PV, or we use external storage. If we keep files within the cluster, we have to act according to the old practices that have remained since the days of physical infrastructures: for example, synchronizing with lsync. Or any other preferred workaround that you personally like. We deploy everything to other machines and carry on.<\/p>\n

    Ten tweede, en eigenlijk zelfs een belangrijker knelpunt \u2014 de database. Als we slimme mensen zijn en de database niet in Kubernetes houden, dan is het proces van gegevensback-up volgens dezelfde oude methode \u2014 master-slave replicatie, dan overschakelen, de replicatie bijwerken en we leven goed. Maar als we onze DB binnen het cluster houden, zijn er in principe veel kant-en-klare oplossingen voor het organiseren van dezelfde master-slave replicatie, veel oplossingen voor het opzetten van een DB binnen Kubernetes.
    \n Er zijn al miljarden presentaties en artikelen geschreven over het back-uppen van databases, er is hier eigenlijk niets nieuws te zeggen. Kortom, volg uw droom, leef zoals u wilt, verzin ook wat ingewikkelde oplossingen voor uzelf, maar denk goed na over hoe u al dit alles gaat back-uppen.<\/p>\n

    En nu over hoe we het proces van overschakelen naar de reserve locatie in het geval van brand zullen aanpakken. Ten eerste implementeren we parallel stateless applicaties. Ze hebben geen invloed op de bedrijfslogica van onze applicaties, ons project, we kunnen constant twee sets draaiende applicaties hebben, en ze kunnen beginnen met het ontvangen van verkeer. Het is erg belangrijk om tijdens het overschakelen naar de reserve locatie te kijken of de configuraties moeten worden overschreven. Bijvoorbeeld, we hebben een productieklast van Kubernetes, er is een reserve Kubernetes-klaar, er is een externe masterdatabase en er is een reserve masterdatabase. We hebben vier opties hoe deze applicaties in productie met elkaar kunnen gaan interageren. Onze database kan overschakelen, en dan moet het verkeer in de productieklast naar de nieuwe database worden omgeleid, of onze cluster kan uitvallen \u2014 dan zijn we overgestapt naar de reserve, maar blijven we werken met de productiedatabase, en de derde optie is dat zowel dit als dat is uitgevallen, en we schakelen beide applicaties over, herschrijven onze configuratie zodat de nieuwe applicaties met de nieuwe database werken. <\/p>\n

    En wat voor conclusies kunnen we hieruit trekken? <\/p>\n

    \"Back-up
    \n
    \nConclusie \u00e9\u00e9n: leven met een reserve is goed. Maar duur. Idealiter zou je niet met \u00e9\u00e9n reserve moeten leven. Idealiter zou je met meerdere reserves moeten leven. Ten eerste moet de reserve minstens niet in \u00e9\u00e9n datacenter zijn, en ten tweede, bij voorkeur, bij een andere provider. Het is vaak voorgekomen \u2014 en dat heb ik zelf meegemaakt. Helaas kan ik de projecten niet noemen, precies toen er een brand was in het datacenter... Ik zei: we schakelen over naar de reserve! Maar de reserve servers stonden in dezelfde rack...<\/p>\n

    Of stel je voor dat Amazon in Rusland is geblokkeerd (en dat is gebeurd). En dat is het: wat heeft het voor zin dat onze reserve zich in een andere Amazon bevindt? Die is ook niet beschikbaar. Dus ik herhaal: houd een reserve, bij voorkeur in een ander datacenter, maar het liefst bij een andere provider. <\/p>\n

    The second takeaway: if you have an application in Kubernetes that communicates with some external sources (which can be a database or some external API), always define it as a service with an external endpoint, so that at the moment of switching, you don\u2019t have to redeploy 15 of your applications that are accessing the same database. Define the database as a separate service, and access it as if it were inside your cluster: if your database goes down, you only change the IP in one place and continue living happily. <\/p>\n

    En tot slot: ik hou van de 'kubus', net als van de experimenten ermee. Ook deel ik graag de resultaten van deze experimenten en mijn persoonlijke ervaringen. Daarom heb ik een serie webinars over K8s opgenomen, welkom op ons YouTube-kanaal<\/a><\/noindex> voor meer details.
    \n
    Bron:     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\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\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Redundantie in Kubernetes: het bestaat | ProHoster","description":"Mijn naam is Sergey, ik kom van ITSumma, en ik wil je vertellen hoe wij omgaan met redundantie in Kubernetes.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\u0420\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u043e\u043d\u043e \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 | ProHoster","og:description":"\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.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","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:54:36+00:00","article:modified_time":"2019-10-31T18:54:36+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33773","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 17:03:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:33:25","updated":"2026-02-09 17:03:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}