{"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":"Reservierung in Kubernetes: Sie existiert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich hei\u00dfe Sergey, ich komme von der Firma ITSumma und ich m\u00f6chte Ihnen erz\u00e4hlen, wie wir an die Sicherung in Kubernetes herangehen. In letzter Zeit besch\u00e4ftige ich mich viel mit Beratung im Bereich der Implementierung verschiedener DevOps-L\u00f6sungen f\u00fcr unterschiedliche Teams, insbesondere arbeite ich eng an Projekten mit K8s. Auf der Uptime Day 4-Konferenz, die sich mit der Sicherung in komplexen Architekturen befasste, hielt ich einen Vortrag \u00fcber die Sicherung von \"Cubes\" und hier ist eine freie Zusammenfassung davon. Ich m\u00f6chte nur vorweg warnen, dass es sich nicht um eine unmittelbare Handlungsanleitung handelt, sondern eher um eine Zusammenfassung von \u00dcberlegungen zu diesem Thema.<\/p>\n

\"Reservierung
\n
\nIm Grunde sind \u00dcberwachung und Sicherung zwei Hauptinstrumente zur Steigerung der Ausfallsicherheit eines Projekts. Aber in Kubernetes wird alles selbst balanciert, sagen Sie, alles wird automatisch skaliert, und wenn etwas passiert \u2013 wird es von selbst hochgefahren... Das bedeutet, dass ich bei einer ersten oberfl\u00e4chlichen Untersuchung des Themas bei der Frage, wie jeder an die Sicherung von K8s herangeht, die Antwort \"Wozu?\" aus dem Internet erhielt. Viele glauben, dass Kubernetes eine magische Sache ist, die alle Infrastrukturprobleme l\u00f6st und daf\u00fcr sorgt, dass ein Projekt niemals ausf\u00e4llt. Aber... die Welt ist nicht das, was sie scheint.
\n<\/a><\/noindex>
\nWie sind wir fr\u00fcher an den Prozess der Sicherung herangegangen? Wir hatten identische Plattformen f\u00fcr die Bereitstellung \u2013 entweder virtuelle Maschinen oder physische Server<\/a>, auf die wir drei grundlegende Praktiken anwendeten: <\/p>\n

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

    \nUnd voil\u00e0: jederzeit schalten wir auf die Sicherungsplattform um, alle sind gl\u00fccklich, wir stehen auf und gehen auseinander. <\/p>\n

    \"Reservierung
    \n
    \nWas wird uns angeboten, um die st\u00e4ndige Verf\u00fcgbarkeit unserer Kubernetes-Anwendung zu erh\u00f6hen? Das erste, was die inoffizielle Dokumentation erw\u00e4hnt, ist, eine Vielzahl von Maschinen einzusetzen und viele Master-Instanzen zu erstellen \u2013 deren Anzahl muss die Bedingungen f\u00fcr das Erreichen eines Quorums im Cluster erf\u00fcllen, und auf jedem Master sollte etcd, API, MC, Scheduler... aktiv sein. Und es scheint, als ob alles wunderbar w\u00e4re: Wenn mehrere Arbeitsknoten oder Master ausfallen, wird unser Cluster neu balanciert und die Anwendung bleibt aktiv. Es sieht wieder einmal nach Magie aus! Aber oft befindet sich unser Cluster in einem einzigen Rechenzentrum, und das kann bestimmte Fragen aufwerfen. Was, wenn ein Bagger kommt und ein Kabel ausgr\u00e4bt, ein Blitz einschl\u00e4gt oder eine universelle Flut kommt? Alles ist dann verloren, unser Cluster ist nicht mehr da. Wie gehen wir mit der Hochverf\u00fcgbarkeit unter Ber\u00fccksichtigung dieser Problematik um? <\/p>\n

    Zun\u00e4chst einmal m\u00fcssen Sie einen weiteren Cluster im Hot-Standby haben, auf den Sie jederzeit umschalten k\u00f6nnen. Dabei sollten aus Sicht von Kubernetes die Infrastrukturen vollst\u00e4ndig identisch sein. Das bedeutet, dass alle nicht standardm\u00e4\u00dfigen Plugins f\u00fcr die Arbeit mit dem Dateisystem, individuelle L\u00f6sungen f\u00fcr den Ingress usw. auf Ihren beiden (oder drei, oder zehn \u2013 hier kommt es darauf an, wie viel Geld und Kapazit\u00e4t die Admins haben) Clustern identisch sein m\u00fcssen. Es ist wichtig, zwei Sets von Anwendungen (Deployments, StatefulSets, DaemonSets, CronJobs usw.) klar zu definieren: Welche davon k\u00f6nnen dauerhaft im Standby betrieben werden und welche sollten besser erst beim tats\u00e4chlichen Umschalten gestartet werden. <\/p>\n

    Sollte unser Backup-Cluster also vollst\u00e4ndig identisch mit unserem Produktionscluster sein? Nein. W\u00e4hrend wir fr\u00fcher in monolithischen Projekten mit physischer Infrastruktur weitgehend identische Umgebungen aufrechterhielten, sollte das im Zusammenhang mit Kubernetes meiner Meinung nach nicht erforderlich sein. Lassen Sie uns er\u00f6rtern, warum.<\/p>\n

    Zum Beispiel beginnen wir mit den grundlegenden Entit\u00e4ten von Kubernetes \u2013 Deployments \u2013 sie sollten identisch sein. Anwendungen m\u00fcssen laufen, die jederzeit den Datenverkehr abfangen k\u00f6nnen, um unser Projekt am Leben zu halten. Wenn es um Konfigurationsdateien geht, m\u00fcssen wir pr\u00fcfen, ob sie identisch sein sollen oder nicht. Das hei\u00dft, wenn wir kluge Menschen sind, keine verbotenen Substanzen konsumieren und die Daten in K8s nicht speichern, dann sollten unsere ConfigMaps die Zugangseinstellungen zur Produktionsdatenbank enthalten (deren Backup-Prozess separat aufgebaut ist). Entsprechend m\u00fcssen wir f\u00fcr den Zugang zum Backup-Exemplar der Datenbank eine separate Konfigurationsdatei (ConfigMap) haben. Genauso verfahren wir mit Secrets: Passw\u00f6rtern f\u00fcr den Datenbankzugang, API-Schl\u00fcsseln; zu jedem Zeitpunkt kann entweder das Produktions-Secret oder das Backup-Secret aktiv sein. Insgesamt haben wir bereits zwei Kubernetes-Entit\u00e4ten, deren Backup-Versionen nicht identisch mit den Produktionsversionen sein sollten. Die n\u00e4chste Entit\u00e4t, bei der wir halt machen sollten, ist der CronJob. Die CronJobs im Backup sollten auf keinen Fall mit der Gruppe von CronJobs im Produktionscluster identisch sein! Wenn wir einen Backup-Cluster aufbauen und ihn vollst\u00e4ndig mit allen aktivierten CronJobs hochfahren \u2013 dann werden zum Beispiel Menschen gleichzeitig zwei E-Mails von Ihnen erhalten anstatt einer. Oder eine Datenabgleich mit externen Quellen wird zweimal durchgef\u00fchrt, was dazu f\u00fchrt, dass wir anfangen zu leiden, zu weinen, zu schreien und uns zu beschweren. <\/p>\n

    \"Reservierung
    \n
    \nWie schlagen uns die Leute aus dem Internet vor, den Backup-Cluster zu organisieren? Die zweitbeliebteste Antwort nach \"Warum?\" ist die Verwendung von Kubernetes Federation. <\/p>\n

    Was ist das? Das ist, sagen wir mal, ein gro\u00dfer Meta-Cluster. Wenn wir die Architektur von Kubernetes betrachten \u2013 wo wir einen Master und mehrere Nodes haben \u2013 dann haben wir in Bezug auf die F\u00f6deration ebenfalls einen Master und mehrere Nodes, wobei jede Node ein eigener Cluster ist. Das bedeutet, wir arbeiten mit den gleichen Entit\u00e4ten und mit den gleichen Primitiven, wie bei einem einzelnen Kubernetes, nur dass wir nicht mit unseren physischen Maschinen, sondern mit ganzen Clustern arbeiten. Innerhalb der F\u00f6deration findet eine vollst\u00e4ndige Synchronisierung der f\u00f6derativen Ressourcen von den Eltern zu den Nachkommen statt. Zum Beispiel, wenn wir ein Deployment \u00fcber die F\u00f6deration starten \u2013 wird es in jedem unserer untergeordneten Cluster bereitgestellt. Wenn wir einen beliebigen ConfigMap oder Secret nehmen und ihn \u00fcber die F\u00f6deration ausrollen \u2013 wird es sich \u00fcber alle unsere untergeordneten Cluster verteilen; dabei erm\u00f6glicht die F\u00f6deration, unsere Ressourcen bei den Nachkommen zu individualisieren. Das hei\u00dft, wir nehmen einen beliebigen ConfigMap, deployen ihn \u00fcber die F\u00f6deration und wenn wir dann etwas an bestimmten Clustern anpassen m\u00fcssen, gehen wir in den spezifischen Cluster und dieses \u00c4nderung wird nicht synchronisiert. <\/p>\n

    Kubernetes Federation ist ein relativ neues Werkzeug und unterst\u00fctzt l\u00e4ngst nicht alle Ressourcen, die K8s selbst bereitstellt: Zum Zeitpunkt der Ver\u00f6ffentlichung einer der ersten Versionen der Dokumentation wurde nur die Unterst\u00fctzung f\u00fcr ConfigMaps, Deployments unter ReplicaSet und Ingress erw\u00e4hnt. Secrets wurden nicht unterst\u00fctzt, ebenso wenig die Arbeit mit Volumes. Ein viel zu begrenzter Funktionsumfang. Besonders wenn wir gerne experimentieren \u2013 zum Beispiel \u00fcber Custom Resource Definitions, um unsere eigenen Ressourcen an Kubernetes zu \u00fcbergeben \u2013 k\u00f6nnen wir diese nicht in die Federation einbringen. Das hei\u00dft, es ist eine L\u00f6sung, die zwar vielversprechend aussieht, uns aber regelm\u00e4\u00dfig in Schwierigkeiten bringt. Auf der anderen Seite erm\u00f6glicht die Federation eine flexible Verwaltung unseres ReplicaSets. Wenn wir beispielsweise 10 Replikate unserer Anwendung laufen lassen wollen, verteilt die Federation diese Standardanzahl proportional auf die Anzahl der Cluster. Und das kann man sogar konfigurieren! Man kann angeben, dass auf dem Produktionscluster 6 Replikate unserer Anwendung bereitgehalten werden sollen und auf dem Backup-Cluster, um Ressourcen zu sparen oder f\u00fcr eigene Experimente \u2013 nur 4 Replikate unserer Anwendung. Das ist ebenfalls ziemlich praktisch. Aber mit der Federation m\u00fcssen wir neue L\u00f6sungen finden, Dinge im Vorfeld bereitstellen und uns ein wenig mehr den Kopf zerbrechen\u2026 <\/p>\n

    Kann man den Prozess der Kubernetes-Reservierung einfacher angehen? Welche Werkzeuge haben wir \u00fcberhaupt zur Verf\u00fcgung?<\/p>\n

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

    Zweitens gibt es mehrere Cluster, und wir haben entweder ein oder mehrere (wenn wir schlau sind) Registries, die wir ebenfalls reserviert haben. Und es gibt ein wunderbares Tool namens kubectl, das mit mehreren Clustern gleichzeitig arbeiten kann. <\/p>\n

    \"Reservierung
    \n
    \nAlso: Meiner Meinung nach ist die einfachste und verl\u00e4sslichste L\u00f6sung f\u00fcr den Aufbau eines Backup-Clusters ein primitiver paralleler Deployment-Prozess. Es gibt eine Art Pipeline im CI\/CD-System; zun\u00e4chst bauen wir unsere Container, testen sie und rollen die Anwendungen mit kubectl auf mehrere unabh\u00e4ngige Cluster aus. Wir k\u00f6nnen gleichzeitig Releases auf mehrere Cluster bereitstellen. Dementsprechend l\u00f6sen wir die Bereitstellung der Konfigurationen auch in diesem Schritt. Man kann im Voraus einen Satz von Konfigurationen f\u00fcr unser Produktionscluster und einen Satz von Konfigurationen f\u00fcr das Backup-Cluster festlegen und im CI\/CD-System die Produktionsumgebung im Produktionscluster und die Backup-Umgebung im Backup-Cluster bereitstellen. Im Vergleich zur F\u00f6deration muss man nach der Bestimmung der f\u00f6derativen Ressource nicht zu jedem untergeordneten Cluster gehen und etwas neu definieren. Wir haben das im Voraus erledigt. Wie gro\u00dfartig wir sind.<\/p>\n

    Aber\u2026 es gibt\u2026 ich hatte geschrieben, es gibt die \u201eUrsache allen \u00dcbels\u201c, aber es gibt tats\u00e4chlich zwei. Erstens, das Dateisystem. Es gibt entweder ein PV oder wir nutzen einen externen Speicher. Wenn wir Dateien innerhalb des Clusters speichern, m\u00fcssen wir alte Praktiken anwenden, die aus der Zeit der physischen Infrastruktur stammen: zum Beispiel die Synchronisierung mit lsync. Oder mit einem anderen, von Ihnen bevorzugten Workaround. Wir rollen alles auf andere Maschinen aus und leben damit.<\/p>\n

    Zweitens und tats\u00e4chlich der wichtigere Stolperstein \u2014 die Datenbank. Wenn wir kluge Menschen sind und die Datenbank nicht in Kubernetes halten, dann ist der Prozess der Datensicherung nach dem alten Schema \u2014 Master-Slave-Replikation, dann umschalten, die Replikation nachholen und gut leben. Aber wenn wir unsere DB innerhalb des Clusters halten, gibt es viele fertige L\u00f6sungen zur Organisation derselben Master-Slave-Replikation, viele L\u00f6sungen, um eine DB innerhalb von Kubernetes zu betreiben.
    \n \u00dcber die Sicherung von Datenbanken wurden bereits Milliarden von Vortr\u00e4gen gehalten und Milliarden Artikel geschrieben, hier braucht es eigentlich nichts Neues. Insgesamt, folgen Sie Ihrem Traum, leben Sie wie Sie m\u00f6chten, erfinden Sie sich auch irgendwelche komplexen Hacks, aber denken Sie unbedingt dar\u00fcber nach, wie Sie all das sichern werden.<\/p>\n

    Und jetzt, wie der Prozess des Wechsels zu einer Backup-Plattform im Falle eines Brandes grunds\u00e4tzlich bei uns ablaufen wird. Erstens deployen wir parallel stateless Anwendungen. Sie beeinflussen nicht die Gesch\u00e4ftslogik unserer Anwendungen, unseres Projekts, wir k\u00f6nnen st\u00e4ndig zwei S\u00e4tze von laufenden Applikationen halten und sie k\u00f6nnen anfangen, Traffic zu empfangen. Es ist sehr wichtig, im Prozess des Wechsels zu einer Backup-Plattform unbedingt zu pr\u00fcfen \u2014 m\u00fcssen die Konfigurationen neu definiert werden? Zum Beispiel haben wir ein Produktionscluster in Kubernetes, ein Backup-Cluster in Kubernetes, eine externe Master-Datenbank, eine Backup-Master-Datenbank. Wir haben vier Optionen, wie diese Anwendungen in der Produktion beginnen k\u00f6nnen, miteinander zu interagieren. Die Datenbank kann umschalten, und es stellt sich heraus, dass wir den Traffic im Produktionscluster auf die neue Datenbank umschalten m\u00fcssen, oder unser Cluster kann ausfallen \u2014 und wir sind auf die Backup-Plattform umgestiegen, arbeiten aber weiterhin mit der Produktionsdatenbank, und die dritte Option ist, wenn dies ausgefallen ist und das ausgefallen ist, und wir beide Anwendungen umschalten, die Konfiguration neu definieren, damit die neuen Anwendungen bereits mit der neuen Datenbank arbeiten. <\/p>\n

    Was kann man also aus alldem ableiten? <\/p>\n

    \"Reservierung
    \n
    \nErste Erkenntnis: Mit einem Backup l\u00e4sst es sich gut leben. Aber es ist teuer. Idealerweise sollte man nicht nur mit einem Backup leben. Im Idealfall sollte man mit mehreren Backups leben. Erstens sollte das Backup mindestens nicht in einem Rechenzentrum sein und zweitens mindestens bei einem anderen Anbieter. Oft gab es das \u2014 und das habe ich pers\u00f6nlich erlebt. Einige Projekte kann ich leider nicht nennen, als genau dann der Brand im Rechenzentrum passierte\u2026 Ich dachte: Wir schalten auf das Backup um! Und die Backup-Server standen in demselben Rack\u2026<\/p>\n

    Oder stellen Sie sich vor, dass Amazon in Russland gesperrt wurde (das kam vor). Und alles: Was n\u00fctzt es, dass unser Backup bei einem anderen Amazon liegt? Es ist auch nicht erreichbar. Deshalb wiederhole ich: Halten Sie das Backup mindestens in einem anderen Rechenzentrum, und idealerweise \u2014 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 Service mit einem externen Endpoint, damit Sie beim Wechseln nicht 15 Ihrer Anwendungen neu bereitstellen m\u00fcssen, die auf dieselbe Datenbank zugreifen. Definieren Sie die Datenbank als separaten Service, kommunizieren Sie mit ihr, als w\u00e4re sie innerhalb Ihres Clusters: Wenn Ihre Datenbank ausf\u00e4llt, \u00e4ndern Sie an einer Stelle die IP und leben weiterhin gl\u00fccklich. <\/p>\n

    Und zum Schluss: Ich liebe \"Kubernetes\" genauso wie die Experimente damit. Ich teile auch gerne die Ergebnisse dieser Experimente und meine pers\u00f6nlichen Erfahrungen. Deshalb habe ich eine Reihe von Webinaren \u00fcber K8s aufgezeichnet, willkommen auf unserem YouTube-Kanal<\/a><\/noindex> f\u00fcr weitere Informationen.
    \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\udd47Notfallwiederherstellung in Kubernetes: Sie existiert | ProHoster","description":"Mein Name ist Sergey, ich komme von der Firma ITSumma, und ich m\u00f6chte Ihnen erz\u00e4hlen, wie wir an die Notfallwiederherstellung in Kubernetes herangehen.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}