{"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\/de\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","title":{"rendered":"Backup in Kubernetes: Es gibt ihn","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mein Name ist Sergey, ich komme von der Firma ITSumma, und ich m\u00f6chte Ihnen erz\u00e4hlen, wie wir an Backups in Kubernetes herangehen. In letzter Zeit habe ich viel Beratungsarbeit im Bereich der Implementierung verschiedener DevOps-L\u00f6sungen f\u00fcr verschiedene Teams geleistet und arbeite insbesondere an Projekten mit K8s. Auf der Konferenz Uptime Day 4, die sich mit Backup in komplexen Architekturen besch\u00e4ftigte, hielt ich einen Vortrag \u00fcber das Backup des 'Kuben', und hier ist eine freie Zusammenfassung davon. Ich m\u00f6chte nur vorweg warnen, dass es sich nicht um eine direkte Anleitung handelt, sondern eher um eine Zusammenfassung von Gedanken zu diesem Thema.<\/p>\n

\"Backup
\n
\nIm Grunde genommen sind Monitoring und Backup zwei grundlegende Werkzeuge zur Verbesserung der Ausfallsicherheit jedes Projekts. Aber in Kubernetes wird doch alles selbst balanciert, werden Skalierungen automatisch vorgenommen, und wenn etwas passiert, wird es einfach wieder hochgefahren... Bei einer ersten oberfl\u00e4chlichen Untersuchung des Themas, auf die Frage, wie man beim Backup von K8s vorgeht, erhielt ich im Internet die Antwort: \"Warum?\" Viele glauben, dass Kubernetes eine magische L\u00f6sung ist, die alle Infrastrukturprobleme beseitigt und sicherstellt, dass das Projekt niemals ausf\u00e4llt. Doch die Realit\u00e4t sieht anders aus.
\n<\/a><\/noindex>
\nWie ging es uns fr\u00fcher beim Thema Backup? Wir hatten identische Umgebungen f\u00fcr das Hosting \u2013 entweder virtuelle Maschinen oder physische Server, Server<\/a>, auf die wir drei grundlegende Praktiken anwendeten: <\/p>\n

    \n
  1. Synchronisierung von Code und Statischen Inhalten<\/li>\n
  2. Synchronisierung der Konfigurationen<\/li>\n
  3. Datenbank-Replikation<\/li>\n<\/ol>\n

    \nUnd voil\u00e0: Jederzeit k\u00f6nnen wir auf die Backup-Umgebung umschalten, alle sind zufrieden, wir stehen auf und gehen auseinander. <\/p>\n

    \"Backup
    \n
    \nWas wird uns angeboten, um die permanente Verf\u00fcgbarkeit unserer Kubernetes-Anwendung zu erh\u00f6hen? Der erste Punkt, den die inoffizielle Dokumentation anspricht, ist, mehrere Maschinen zu installieren und viele Master-Instanzen einzurichten \u2013 ihre Anzahl sollte in der Lage sein, die Anforderungen f\u00fcr das Erreichen des Quorums innerhalb des Clusters zu erf\u00fcllen, und auf jedem Master sollte etcd, API, MC, Scheduler usw. laufen\u2026 Und es scheint, als w\u00e4re alles wunderbar: Wenn mehrere Arbeitsknoten oder Master ausfallen, wird unser Cluster neu ausbalanciert und die Anwendung bleibt betriebsbereit. Es klingt wieder nach Magie! Aber oft befindet sich unser Cluster in einem einzigen Rechenzentrum, was bestimmte Fragen aufwerfen kann. Was passiert, wenn ein Bagger kommt und ein Kabel ausgr\u00e4bt, ein Blitz einschl\u00e4gt oder eine universelle Flut eintritt? Alles w\u00e4re kaputt, und unser Cluster w\u00e4re nicht mehr vorhanden. Wie geht man mit der Hochverf\u00fcgbarkeit in Anbetracht dieser Problematik um? <\/p>\n

    Zun\u00e4chst einmal sollten Sie einen weiteren Cluster in hei\u00dfer Reserve haben, also einen Cluster, auf den Sie jederzeit umschalten k\u00f6nnen. In Bezug auf Kubernetes m\u00fcssen die Infrastrukturen vollst\u00e4ndig identisch sein. Das bedeutet, dass, wenn es irgendwelche speziellen Plugins f\u00fcr die Dateisystemintegration oder ma\u00dfgeschneiderte L\u00f6sungen f\u00fcr Ingress gibt, diese auf Ihren beiden (oder drei, oder zehn, hier kommt es darauf an, wie viel Geld und Ressourcen die Administratoren haben) Clustern vollst\u00e4ndig gleich sein m\u00fcssen. Es ist erforderlich, zwei S\u00e4tze von Anwendungen (Deployments, StatefulSets, DaemonSets, CronJobs usw.) klar zu definieren: welche von ihnen kontinuierlich im Reservebetrieb laufen k\u00f6nnen und welche besser erst beim tats\u00e4chlichen Umschalten gestartet werden sollten. <\/p>\n

    Sollte unser Backup-Cluster also vollst\u00e4ndig identisch mit unserem Produktions-Cluster sein? Nein. W\u00e4hrend wir fr\u00fcher bei monolithischen Projekten und physischer Infrastruktur praktisch identische Umgebungen pflegten, sollte dies in Kubernetes meiner Meinung nach nicht der Fall sein. Lassen Sie uns ansehen, warum.<\/p>\n

    Zum Beispiel beginnen wir mit den grundlegenden Entit\u00e4ten von Kubernetes \u2013 Deployments \u2013 diese m\u00fcssen identisch sein. Die Anwendungen m\u00fcssen so gestartet werden, dass sie jederzeit den Datenverkehr \u00fcbernehmen k\u00f6nnen und unser Projekt weiterhin leben kann. Wenn wir \u00fcber Konfigurationsdateien sprechen, m\u00fcssen wir pr\u00fcfen, ob diese identisch sein sollten oder nicht. Das hei\u00dft, wenn wir, intelligente Menschen, keine verbotenen Substanzen konsumieren und die Datenbank nicht in K8s halten, m\u00fcssen wir in den ConfigMaps die Zugangseinstellungen zur produktiven Datenbank haben (deren Backup-Prozess separat aufgebaut ist). Um den Zugang zur Backup-Datenbank zu gew\u00e4hrleisten, m\u00fcssen wir eine separate Konfigurationsdatei (ConfigMap) haben. Ebenso arbeiten wir mit Secrets: Passw\u00f6rtern f\u00fcr den Datenbankzugang, API-Keys; zu jedem Zeitpunkt kann entweder das produktive Secret oder das Backup aktiv sein. Insgesamt haben wir bereits zwei Kubernetes-Entit\u00e4ten, deren Backup-Versionen nicht identisch mit den produktiven sein sollten. Die n\u00e4chste Entit\u00e4t, auf die wir eingehen sollten, ist der CronJob. CronJobs im Backup sollten keinesfalls mit dem Set von CronJobs des Produktionsclusters identisch sein! Wenn wir einen Backup-Cluster hochfahren und dabei alle CronJobs aktivieren \u2013 dann werden die Leute beispielsweise zwei E-Mails gleichzeitig anstelle einer erhalten. Oder eine Datenanpassung mit externen Quellen wird zweimal durchgef\u00fchrt, entsprechend beginnen wir zu leiden, zu weinen, zu schreien und uns zu beschweren. <\/p>\n

    \"Backup
    \n
    \nWie schlagen uns die Leute aus dem Internet vor, einen Cluster zur Sicherung zu organisieren? Die zweith\u00e4ufigste Antwort nach \"Warum?\" ist die Nutzung von Kubernetes Federation. <\/p>\n

    Was ist das? Es handelt sich sozusagen um einen gro\u00dfen Meta-Cluster. Wenn wir die Architektur von Kubernetes betrachten \u2014 wo wir einen Master und mehrere Nodes haben \u2014 dann gibt es aus Sicht der Federation ebenfalls einen Master und mehrere Nodes, wobei jede Node ein eigener Cluster ist. Das bedeutet, wir arbeiten mit denselben Entit\u00e4ten und Primitiven wie bei einem einzelnen Kubernetes-Cluster, nur dass wir nicht mit unseren physischen Maschinen, sondern mit ganzen Clustern arbeiten. Innerhalb der Federation erfolgt eine vollst\u00e4ndige Synchronisierung der f\u00f6derativen Ressourcen von Eltern zu Nachkommen. Wenn wir beispielsweise ein Deployment \u00fcber die Federation gestartet haben, wird es in jedem unserer untergeordneten Cluster bereitgestellt. Wenn wir ein ConfigMap oder Secret nehmen und es \u00fcber die Federation ausrollen, verteilt es sich auf alle unsere untergeordneten Cluster; dabei erm\u00f6glicht die Federation die Anpassung unserer Ressourcen in den Nachfolger-Clustern. Das hei\u00dft, wir haben ein ConfigMap genommen, \u00fcber die Federation bereitgestellt und wenn wir dann etwas auf bestimmten Clustern anpassen m\u00fcssen, gehen wir zu dem spezifischen Cluster und diese \u00c4nderung wird nicht weiter synchronisiert. <\/p>\n

    Kubernetes Federation ist ein relativ neues Tool und unterst\u00fctzt nicht das gesamte Spektrum an Ressourcen, das K8s selbst bietet. Zum Zeitpunkt der Ver\u00f6ffentlichung einer der ersten Dokumentationen wurde lediglich Unterst\u00fctzung f\u00fcr ConfigMaps, Deployment unter ReplicaSet und Ingress erw\u00e4hnt. Secrets wurden nicht unterst\u00fctzt, ebenso wenig die Arbeit mit Volumes. Das ist ein zu eingeschr\u00e4nkter Funktionsumfang, besonders wenn wir gerne mit eigenen Ressourcen \u00fcber Custom Resource Definitions experimentieren \u2013 die k\u00f6nnen wir in der Federation nicht integrieren. Es klingt zwar plausibel, aber bringt uns gelegentlich in die Bredouille. Auf der anderen Seite erm\u00f6glicht die Federation eine flexible Verwaltung unseres ReplicaSets. Wenn wir zum Beispiel 10 Replikate unserer Anwendung starten m\u00f6chten, verteilt die Federation diese Zahl proportional auf die verf\u00fcgbaren Cluster. Und es l\u00e4sst sich auch konfigurieren! So k\u00f6nnen wir einstellen, dass auf dem Produktionscluster 6 Replikate unserer Anwendung bereitgestellt werden, w\u00e4hrend auf dem Backup-Cluster, um Ressourcen zu sparen oder aus anderen Gr\u00fcnden, nur 4 Replikate laufen. Das ist ebenfalls sehr praktisch. Allerdings m\u00fcssen wir bei der Federation neue L\u00f6sungen implementieren, etwas mehr improvisieren und uns mehr Gedanken machen\u2026 <\/p>\n

    Kann man den Prozess der Kubernetes-Reservierung einfacher gestalten? Welche Werkzeuge stehen uns \u00fcberhaupt zur Verf\u00fcgung?<\/p>\n

    Zun\u00e4chst einmal haben wir immer ein CI\/CD-System, das hei\u00dft, wir gehen nicht manuell auf die Server und schreiben create\/apply. Das System generiert YAML-Dateien f\u00fcr unsere Container. <\/p>\n

    Au\u00dferdem gibt es mehrere Cluster; wir haben entweder eines oder mehrere (wenn wir klug sind) Registrys, die wir ebenfalls reserviert haben. Und es gibt ein gro\u00dfartiges Tool namens kubectl, das mit mehreren Clustern gleichzeitig arbeiten kann. <\/p>\n

    \"Backup
    \n
    \nIch bin der Meinung, dass die einfachste und effektivste L\u00f6sung f\u00fcr den Aufbau eines Backup-Clusters ein einfacher paralleler Deploy ist. Es gibt eine Pipeline im CI\/CD-System; zuerst bauen wir unsere Container, testen sie und deployen die Anwendungen \u00fcber kubectl auf mehrere unabh\u00e4ngige Cluster. Wir k\u00f6nnen gleichzeitig Deployments auf mehreren Clustern durchf\u00fchren. Entsprechend l\u00f6sen wir auch die Bereitstellung der Konfigurationen in diesem Schritt. Im Voraus kann man ein Set von Konfigurationen f\u00fcr unser Produktionscluster und ein Set von Konfigurationen f\u00fcr das Backup-Cluster definieren, und im CI\/CD-System die Produktionsumgebung auf das Produktionscluster und die Backup-Umgebung auf das Backup-Cluster ausrollen. Im Vergleich zur F\u00f6deration m\u00fcssen wir nicht nach der Festlegung der f\u00f6derativen Ressource auf jeden Kind-Cluster gehen und etwas \u00fcberschreiben. Das haben wir im Voraus erledigt. Gut gemacht von uns.<\/p>\n

    Aber\u2026 es gibt\u2026 ich hatte geschrieben, dass es den \"Ursprung allen \u00dcbels\" gibt, aber tats\u00e4chlich sind es zwei. Erstens, das Dateisystem. Es gibt irgendeinen PV, oder wir verwenden einen externen Speicher. Wenn wir Dateien innerhalb des Clusters speichern, m\u00fcssen wir nach den alten Praktiken vorgehen, die aus der Zeit der physikalischen Infrastrukturen stammen: zum Beispiel mit lsync synchronisieren. Oder mit einem anderen, von Ihnen pers\u00f6nlich bevorzugten Workaround. Wir rollen alles auf andere Maschinen aus und machen einfach weiter.<\/p>\n

    Zweitens, und eigentlich ein noch wichtigerer Streitpunkt \u2013 die Datenbank. Wenn wir kluge Leute sind und die Datenbank nicht in Kubernetes halten, erfolgt die Datensicherung nach dem alten Schema \u2013 Master-Slave-Replikation, dann Umschaltung, die Replikation holen wir nach und leben gut. Aber wenn wir unsere DB im Cluster haben, gibt es prinzipiell viele fertige L\u00f6sungen zur Organisation derselben Master-Slave-Replikation, viele L\u00f6sungen, um eine DB innerhalb von Kubernetes hochzuziehen.
    \n \u00dcber Datenbanksicherung wurden bereits unz\u00e4hlige Berichte verfasst und ebenso viele Artikel geschrieben. Hier gibt es wirklich nichts Neues zu sagen. Im Gro\u00dfen und Ganzen: Verfolgen Sie Ihre Tr\u00e4ume, leben Sie, wie Sie wollen, erfinden Sie auch komplizierte L\u00f6sungen, aber denken Sie immer daran, wie Sie alles sichern werden.<\/p>\n

    Jetzt m\u00f6chte ich erkl\u00e4ren, wie der Prozess des Wechsels zu einer Backup-Plattform im Falle eines Brandes grunds\u00e4tzlich ablaufen wird. Zun\u00e4chst implementieren wir parallel die stateless-Anwendungen. Diese beeinflussen nicht die Gesch\u00e4ftslogik unserer Anwendungen und unseres Projekts; wir k\u00f6nnen st\u00e4ndig zwei Satzentwicklungen von Anwendungen laufen lassen, die gleichzeitig mit dem Verkehr beginnen k\u00f6nnen. Es ist sehr wichtig, beim Wechsel zur Backup-Plattform darauf zu achten, ob Konfigurationen angepasst werden m\u00fcssen. Zum Beispiel haben wir einen Produktions-Clustering in Kubernetes, einen Backup-Cluster in Kubernetes und eine externe Master-Datenbank sowie eine Backup-Master-Datenbank. Wir haben vier Optionen, wie diese Anwendungen in der Produktion miteinander interagieren k\u00f6nnen. Unsere Datenbank kann umschalten, was bedeutet, dass der Verkehr im Produktions-Cluster auf eine neue Datenbank umgeleitet werden muss; ein Cluster kann ausfallen, und wir sind auf die Backup-Plattform umgezogen, arbeiten aber weiterhin mit der Produktionsdatenbank. Schlie\u00dflich gibt es noch die dritte Option, bei der sowohl das eine als auch das andere ausf\u00e4llt. In diesem Fall schalten wir beide Anwendungen um und passen unsere Konfiguration an, damit die neuen Anwendungen bereits mit der neuen Datenbank arbeiten. <\/p>\n

    Welche Schlussfolgerungen k\u00f6nnen wir also daraus ziehen? <\/p>\n

    \"Backup
    \n
    \nErste Schlussfolgerung: Mit einem Backup zu leben, ist gut. Aber es ist teuer. Im Idealfall sollte man nicht nur mit einem Backup leben. Idealerweise braucht man mehrere Backups. Zuerst sollte das Backup mindestens in einem anderen Rechenzentrum sein, und zweitens bei einem anderen Anbieter. Das habe ich oft erlebt \u2013 und das ist auch in meiner Praxis vorgekommen. Projekte kann ich leider nicht benennen, besonders als es einen Brand im Rechenzentrum gab\u2026 Ich dachte: Wir wechseln auf das Backup! Und die Backup-Server standen im gleichen Rack\u2026<\/p>\n

    Oder stellen Sie sich vor, Amazon wird in Russland gesperrt (das ist passiert). Und was bringt es, dass unser Backup bei einem anderen Amazon liegt? Das ist ebenfalls nicht verf\u00fcgbar. Daher nochmals: Halten Sie das Backup mindestens in einem anderen Rechenzentrum, idealerweise bei einem anderen Anbieter. <\/p>\n

    Die zweite Erkenntnis: Wenn Ihre Anwendung in Kubernetes mit externen Quellen kommuniziert (das kann eine Datenbank oder eine externe API sein), definieren Sie sie unbedingt als Dienst mit einem externen Endpoint, damit Sie beim Wechsel nicht 15 Ihrer Anwendungen neu bereitstellen m\u00fcssen, die auf dieselbe Datenbank zugreifen. Definieren Sie die Datenbank als separaten Dienst und greifen Sie darauf zu, als ob sie sich innerhalb Ihres Clusters befindet: Wenn Ihre Datenbank ausf\u00e4llt, \u00e4ndern Sie die IP an einer Stelle und leben weiterhin gl\u00fccklich. <\/p>\n

    Und zum Schluss: Ich liebe den \"Kuben\" sowie die Experimente damit. Au\u00dferdem teile ich gerne die Ergebnisse dieser Experimente und generell meine pers\u00f6nlichen Erfahrungen. Deshalb habe ich eine Webinarreihe \u00fcber K8s aufgezeichnet, willkommen auf unserem YouTube-Kanal<\/a><\/noindex> f\u00fcr weitere Details.
    \n
    Quelle:     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\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\udd47 Hochverf\u00fcgbarkeit in Kubernetes: Sie existiert | ProHoster","description":"Mein Name ist Sergej, ich komme von ITSumma, und ich m\u00f6chte Ihnen erz\u00e4hlen, wie wir das Thema Hochverf\u00fcgbarkeit in Kubernetes angehen. In letzter Zeit habe ich viel beratend an der Implementierung verschiedener DevOps-L\u00f6sungen f\u00fcr verschiedene Teams gearbeitet und insbesondere an Projekten mit K8s. Auf der Uptime Day 4 Konferenz, die sich mit Hochverf\u00fcgbarkeit in komplexen Umgebungen besch\u00e4ftigt hat, habe ich mehrere Erkenntnisse gewonnen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rezervirovanie-v-kubernetes-ono-sushhestvuet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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. \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","og:url":"https:\/\/prohoster.info\/de\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/33773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=33773"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/33773\/revisions"}],"predecessor-version":[{"id":159074,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/33773\/revisions\/159074"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/25449"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=33773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=33773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=33773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}