{"id":39203,"date":"2019-10-31T22:28:25","date_gmt":"2019-10-31T19:28:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf\/"},"modified":"2019-10-31T22:28:25","modified_gmt":"2019-10-31T19:28:25","slug":"zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Wir schlie\u00dfen die L\u00fccken im Kubernetes-Cluster. Vortrag und Transkription von DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, L\u00f6sungsarchitekt bei Southbridge und Dozent von Slurm, hielt einen Vortrag auf der DevOpsConf 2019. Dieser Vortrag ist Teil eines der Themen im vertieften Kurs zu Kubernetes \"Slurm Mega\".<\/p>\n

<\/p>\n

Slurm Basis: Einf\u00fchrung in Kubernetes<\/a><\/noindex> findet in Moskau vom 18. bis 20. November statt.
\nSlurm Mega: Ein Blick unter die Haube von Kubernetes<\/a><\/noindex> \u2014 Moskau, 22. bis 24. November.
\nSlurm Online: beide Kurse zu Kubernetes<\/a><\/noindex> sind jederzeit verf\u00fcgbar.<\/p>\n

\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Nach dem Schnitt \u2014 die Transkription des Vortrags.<\/p>\n

<\/a><\/noindex><\/p>\n

Guten Tag, Kollegen und Interessierte. Heute werde ich \u00fcber Sicherheit sprechen.<\/p>\n

<\/p>\n

Ich sehe, dass heute viele Sicherheitsfachleute im Raum sind. Ich entschuldige mich im Voraus, wenn ich Sicherheitsbegriffe nicht ganz so verwende, wie es bei Ihnen \u00fcblich ist. <\/p>\n

<\/p>\n

Es ist so passiert, dass mir vor etwa einem halben Jahr ein \u00f6ffentliches Kubernetes-Cluster in die H\u00e4nde gefallen ist. \u00d6ffentlich bedeutet, dass es eine bestimmte Anzahl von Namespaces gibt, in diesen Namespaces gibt es Benutzer, die in ihrem eigenen Namespace isoliert sind. Alle diese Benutzer geh\u00f6ren unterschiedlichen Unternehmen. Nun, es wurde angenommen, dass dieses Cluster als CDN genutzt werden sollte. Das hei\u00dft, Ihnen wird ein Cluster gegeben, Sie erhalten einen Benutzer, Sie kommen in Ihren Namespace und deployen Ihre Frontends. <\/p>\n

<\/p>\n

In meinem vorherigen Unternehmen wurde mir ein solcher Service angeboten. Und ich wurde gebeten, den Cluster zu testen, um herauszufinden, ob diese L\u00f6sung geeignet ist oder nicht. <\/p>\n

<\/p>\n

Als ich in diesen Cluster kam, bekam ich eingeschr\u00e4nkte Rechte und einen beschr\u00e4nkten Namespace. Die Leute dort verstanden, was Sicherheit bedeutet. Sie hatten sich mit Role-based Access Control (RBAC) von Kubernetes besch\u00e4ftigt und so eingestellt, dass ich Pods nicht unabh\u00e4ngig von Deployments starten konnte. Ich erinnere mich nicht an die Aufgabe, die ich zu l\u00f6sen versuchte, als ich einen Pod ohne Deployment starten wollte, aber ich wollte einfach einen Pod starten. Ich entschied mich aus Interesse zu \u00fcberpr\u00fcfen, welche Rechte ich im Cluster habe, was ich kann und was nicht, und was sie dort eingestellt haben. Au\u00dferdem werde ich erz\u00e4hlen, was in ihrem RBAC falsch konfiguriert ist. <\/p>\n

<\/p>\n

Nach zwei Minuten hatte ich Admin-Rechte f\u00fcr ihren Cluster erhalten, sah mir alle benachbarten Namespaces an und entdeckte dort laufende Produktions-Frontends von Unternehmen, die bereits den Service gekauft und deployed hatten. Ich konnte mich kaum zur\u00fcckhalten, nicht zu jemandem ins Frontend zu gehen und auf die Startseite ein obsz\u00f6nes Wort zu setzen. <\/p>\n

<\/p>\n

Ich werde anhand von Beispielen erkl\u00e4ren, wie ich das gemacht habe und wie man sich davor sch\u00fctzen sollte. <\/p>\n

<\/p>\n

Zun\u00e4chst m\u00f6chte ich mich vorstellen. Mein Name ist Pavel Selivanov. Ich bin Architekt bei der Firma Southbridge. Ich kenne mich gut mit Kubernetes, DevOps und anderen angesagten Technologien aus. Gemeinsam mit den Ingenieuren von Southbridge baue ich all das auf, w\u00e4hrend ich berate. <\/p>\n

<\/p>\n

Neben unserer Hauptt\u00e4tigkeit haben wir vor kurzem Projekte gestartet, die wir Sl\u00ebrmy nennen. Unser Ziel ist es, unser Wissen \u00fcber Kubernetes in die Breite zu tragen und andere Menschen darin zu schulen, ebenfalls mit K8s zu arbeiten. <\/p>\n

<\/p>\n

Wor\u00fcber ich heute sprechen werde. Das Thema meines Vortrags ist offensichtlich \u2014 die Sicherheit von Kubernetes-Clustern. Aber ich m\u00f6chte gleich zu Beginn sagen, dass dieses Thema sehr umfangreich ist. Daher m\u00f6chte ich klarstellen, wor\u00fcber ich definitiv nicht sprechen werde. Ich werde keine abgedroschenen Begriffe behandeln, die im Internet schon hundertmal diskutiert wurden, wie RBAC und Zertifikate. <\/p>\n

<\/p>\n

Ich werde dar\u00fcber berichten, was mir und meinen Kollegen bei der Sicherheit in Kubernetes-Clustern Sorgen bereitet. Wir sehen diese Probleme sowohl bei Anbietern, die Kubernetes-Cluster bereitstellen, als auch bei Kunden, die zu uns kommen. Und selbst bei Kunden, die von anderen Beratungs-Admin-Unternehmen zu uns kommen. Das Ausma\u00df der Trag\u00f6die ist tats\u00e4chlich sehr gro\u00df. <\/p>\n

<\/p>\n

Wirklich drei Punkte, \u00fcber die ich heute sprechen m\u00f6chte: <\/p>\n

<\/p>\n

    \n
  1. Benutzerrechte vs. Pod-Rechte. Benutzerrechte und Pod-Rechte sind nicht dasselbe. <\/li>\n
  2. Informationssammlung \u00fcber den Cluster. Ich werde zeigen, dass wir alle notwendigen Informationen aus dem Cluster sammeln k\u00f6nnen, ohne besondere Zugriffsrechte zu ben\u00f6tigen. <\/li>\n
  3. DoS-Angriff auf den Cluster. Auch wenn wir keine Informationen sammeln k\u00f6nnen, k\u00f6nnen wir den Cluster dennoch zum Absturz bringen. Ich werde \u00fcber DoS-Angriffe auf die Steuerelemente des Clusters sprechen. <\/li>\n<\/ol>\n

    <\/p>\n

    Ein weiterer allgemeiner Punkt, auf den ich hinweisen m\u00f6chte, ist, worauf ich all dies getestet habe und was ich mit Sicherheit sagen kann, dass es funktioniert.<\/p>\n

    <\/p>\n

    Wir verwenden zur Grundlage die Installation eines Kubernetes-Clusters mit Kubespray. Wer es nicht wei\u00df, das ist praktischerweise eine Sammlung von Rollen f\u00fcr Ansible. Wir nutzen es regelm\u00e4\u00dfig in unserer Arbeit. Es ist gut, da es \u00fcberall eingesetzt werden kann \u2013 sowohl auf physischer Hardware als auch in der Cloud. Eine Installationsmethode eignet sich grunds\u00e4tzlich f\u00fcr alles. <\/p>\n

    <\/p>\n

    In diesem Cluster werde ich Kubernetes v1.14.5 haben. Der gesamte Kubernetes-Cluster, den wir betrachten werden, ist in Namespaces unterteilt, wobei jeder Namespace einem eigenen Team geh\u00f6rt und die Mitglieder dieses Teams Zugriff auf ihren eigenen Namespace haben. Sie k\u00f6nnen nicht zu anderen Namespaces gehen, nur in ihren eigenen. Es gibt jedoch ein Admin-Konto, das \u00fcber Berechtigungen f\u00fcr den gesamten Cluster verf\u00fcgt. <\/p>\n

    <\/p>\n

    \"Wir<\/p>\n

    <\/p>\n

    Ich habe versprochen, dass wir zun\u00e4chst Admin-Rechte f\u00fcr den Cluster erhalten werden. Wir brauchen einen speziell vorbereiteten Pod, der den Kubernetes-Cluster angreift. Alles, was wir tun m\u00fcssen, ist, ihn im Kubernetes-Cluster anzuwenden. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Dieser Pod wird auf einen der Master-Knoten des Kubernetes-Clusters gelangen. Und nach diesem Vorgang gibt uns der Cluster die Datei zur\u00fcck, die admin.conf hei\u00dft. In dieser Datei sind alle Zertifikate des Admins gespeichert und zudem ist die API des Clusters konfiguriert. So einfach kann man Admin-Zugriff erhalten, ich denke, das gilt f\u00fcr 98% der Kubernetes-Cluster. <\/p>\n
    <\/p>\n
    Nochmals, dieser Pod wurde von einem Entwickler in Ihrem Cluster erstellt, der Zugriff hat, um seine Vorschl\u00e4ge in einen kleinen Namespace zu deployen, dieser ist ganz durch RBAC eingeschr\u00e4nkt. Er hatte keine Rechte. Dennoch wurde das Zertifikat zur\u00fcckgegeben. <\/p>\n
    <\/p>\n
    Nun zu dem speziell vorbereiteten Pod. Wir starten mit jedem Image. Zum Beispiel nehmen wir debian:jessie. <\/p>\n
    <\/p>\n
    Wir haben so etwas: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Was ist eine Toleranz? Master-Knoten im Kubernetes-Cluster sind normalerweise mit etwas gekennzeichnet, das als Taint bezeichnet wird. Und der Sinn dieses \u201eTaints\u201c ist, dass auf Master-Knoten keine Pods zugewiesen werden d\u00fcrfen. Aber niemand hindert uns daran, in einem beliebigen Pod anzugeben, dass er gegen den \u201eTaint\u201c tolerant ist. Der Abschnitt Toleration sagt genau das: Wenn auf einem Knoten NoSchedule steht, ist unser Pod tolerant gegen\u00fcber diesem Taint \u2014 und es gibt keine Probleme. <\/p>\n
    <\/p>\n
    Dar\u00fcber hinaus sagen wir, dass unser Pod nicht nur tolerant ist, sondern auch speziell auf den Master gelangen m\u00f6chte. Denn auf den Mastern befinden sich die wertvollsten Dinge, die wir brauchen \u2014 alle Zertifikate. Daher geben wir nodeSelector an \u2014 und wir haben ein Standardlabel auf den Mastern, das es erm\u00f6glicht, aus allen Knoten des Clusters gerade die Knoten auszuw\u00e4hlen, die Master sind. <\/p>\n
    <\/p>\n
    Mit diesen beiden Abschnitten wird der Pod auf jeden Fall auf dem Master ankommen. Und er wird dort wohnen d\u00fcrfen. <\/p>\n
    <\/p>\n
    Es reicht nicht aus, einfach zum Master zu kommen. Das bringt uns nichts. Daher haben wir zwei Dinge:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Wir geben an, dass unser Pod, den wir starten, im Namespace des Kernels sowie im Netzwerk- und PID-Namespace leben wird. Sobald der Pod auf dem Master l\u00e4uft, kann er alle echten, aktiven Interfaces dieses Nodes sehen, den gesamten Traffic abh\u00f6ren und die PIDs aller Prozesse einsehen.<\/p>\n
    <\/p>\n
    Jetzt kommt das Wesentliche. Nehmen Sie etcd und lesen Sie, was Sie m\u00f6chten. <\/p>\n
    <\/p>\n
    Das Interessanteste ist, dass diese M\u00f6glichkeit in Kubernetes standardm\u00e4\u00dfig vorhanden ist. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Directory \n  name: host <\/code><\/pre>\n
    <\/p>\n
    Und die Essenz davon ist, dass wir im Pod, den wir starten, sogar ohne Berechtigungen f\u00fcr diesen Cluster sagen k\u00f6nnen, dass wir ein Volume vom Typ hostPath erstellen m\u00f6chten. Das bedeutet, den Pfad vom Host, auf dem wir starten, zu nehmen und ihn als Volume zu verwenden. Wir nennen es dann name: host. Dieses ganze hostPath mounten wir innerhalb des Pods, in diesem Beispiel im Verzeichnis \/host. <\/p>\n
    <\/p>\n
    Um es noch einmal zu wiederholen. Wir haben dem Pod gesagt, dass er zum Master kommen, hostNetwork und hostPID beziehen und das gesamte Root des Masters in diesen Pod mounten soll. <\/p>\n
    <\/p>\n
    Sie verstehen, dass wir in Debian bash laufen haben, und dieses Bash l\u00e4uft unter root. Das hei\u00dft, wir haben gerade root auf dem Master erhalten, ohne irgendwelche Berechtigungen im Kubernetes-Cluster zu haben.<\/p>\n
    <\/p>\n
    Die gesamte Aufgabe besteht dann darin, in das Pod-Verzeichnis \/host\/etc\/kubernetes\/pki zu gelangen, wenn ich mich nicht irre, und dort alle Master-Zertifikate des Clusters abzuholen und somit Administrator des Clusters zu werden. <\/p>\n
    <\/p>\n
    Wenn man dar\u00fcber nachdenkt, sind das einige der gef\u00e4hrlichsten Berechtigungen in Pods \u2014 unabh\u00e4ngig davon, welche Berechtigungen der Benutzer hat:
    \n\"Wir<\/p>\n
    <\/p>\n
    Wenn ich das Recht habe, ein Pod in einem bestimmten Namespace des Clusters zu starten, dann hat dieses Pod diese Berechtigungen standardm\u00e4\u00dfig. Ich kann privilegierte Pods starten, und das sind praktisch alle Berechtigungen, quasi root auf dem Node. <\/p>\n
    <\/p>\n
    Mein Favorit ist der Root-Benutzer. Kubernetes bietet jedoch die Option \u201eRun As Non-Root\u201c. Das ist so eine Art Schutz vor Hackern. Wissen Sie, was ein \u201emoldawisches Virus\u201c ist? Wenn Sie zuf\u00e4llig ein Hacker sind und in mein Kubernetes-Cluster eindringen, dann bitten wir, die armen Administratoren: \u201eBitte geben Sie in Ihren Pods, mit denen Sie mein Cluster hacken werden, an, dass Sie als Nicht-Root ausf\u00fchren. Andernfalls werden Sie den Prozess in Ihrem Pod als Root ausf\u00fchren und es wird sehr einfach sein, mich zu hacken. Sch\u00fctzen Sie sich bitte selbst.\u201c <\/p>\n
    <\/p>\n
    Der Host-Pfad-Volume ist meiner Meinung nach der schnellste Weg, um das gew\u00fcnschte Ergebnis aus dem Kubernetes-Cluster zu erzielen. <\/p>\n
    <\/p>\n
    Aber was soll man mit alledem machen? <\/p>\n
    <\/p>\n
    Gedanken, die jedem normalen Administrator durch den Kopf gehen sollten, der mit Kubernetes konfrontiert wird: \u201eAha, ich habe es gesagt, Kubernetes funktioniert nicht. Es hat L\u00fccken. Und das ganze Zeug ist M\u00fcll.\u201c In Wirklichkeit gibt es so etwas wie Dokumentation, und wenn man dort nachschaut, gibt es einen Abschnitt Pod-Sicherheitsrichtlinie<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Das ist ein YAML-Objekt, das wir in einem Kubernetes-Cluster erstellen k\u00f6nnen und das die Sicherheitsaspekte in der Pod-Beschreibung steuert. Es kontrolliert im Wesentlichen die Berechtigungen zur Verwendung von hostNetwork, hostPID und bestimmten Typen von Volumes, die beim Starten in Pods vorhanden sind. Mit der Pod Security Policy kann all dies beschrieben werden. <\/p>\n
    <\/p>\n
    Das Interessanteste an der Pod Security Policy ist, dass alle PSP-Installationen im Kubernetes-Cluster nicht nur nicht beschrieben sind, sondern standardm\u00e4\u00dfig einfach deaktiviert sind. Die Pod Security Policy wird durch ein Admission-Plugin aktiviert.<\/p>\n
    <\/p>\n
    Okay, wir deployen die Pod Security Policy in den Cluster und sagen, dass wir einige Dienst-Pods im Namespace haben, auf den nur Administratoren Zugriff haben. In allen anderen Pods gelten eingeschr\u00e4nkte Berechtigungen. Denn wahrscheinlich m\u00fcssen Entwickler keine privilegierten Pods in Ihrem Cluster starten. <\/p>\n
    <\/p>\n
    Und anscheinend ist alles in Ordnung. Und unser Kubernetes-Cluster kann nicht in zwei Minuten gehackt werden. <\/p>\n
    <\/p>\n
    Es gibt ein Problem. Wahrscheinlich haben Sie ein Kubernetes-Cluster, in dem \u00dcberwachung eingerichtet ist. Ich wage sogar die Vorhersage, dass es in Ihrem Cluster als Prometheus bekannt ist. <\/p>\n
    <\/p>\n
    Was ich jetzt erz\u00e4hle, gilt sowohl f\u00fcr den Prometheus-Operator als auch f\u00fcr Prometheus in seiner reinen Form. Die Frage ist, wenn ich im Cluster nicht so schnell einen Administrator bekommen kann, bedeutet das, dass ich mehr suchen muss. Und ich kann mit Ihrer \u00dcberwachung suchen.<\/p>\n
    <\/p>\n
    Wahrscheinlich haben alle die gleichen Artikel auf Habr\u00e9 gelesen, und die \u00dcberwachung befindet sich im Namespace monitoring. Das Helm-Chart hat bei allen \u00e4hnliche Namen. Ich gehe davon aus, dass wenn Sie helm install stable\/prometheus machen, Sie ungef\u00e4hr die gleichen Bezeichnungen erhalten. Und wahrscheinlich muss ich den DNS-Namen in Ihrem Cluster nicht erraten, denn er ist standardm\u00e4\u00dfig. <\/p>\n
    <\/p>\n
    \"Wir<\/p>\n
    <\/p>\n
    Dann haben wir einen bestimmten Dev-Namespace, in dem man einen Pod starten kann. Und aus diesem Pod heraus ist es sehr einfach, Folgendes zu machen: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics ist einer der Exporter von Prometheus, der Metriken aus der Kubernetes-API sammelt. Dort gibt es viele Daten dar\u00fcber, was in Ihrem Cluster l\u00e4uft, wie es aussieht und welche Probleme Sie damit haben. <\/p>\n
    <\/p>\n
    Ein einfaches Beispiel: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system»,pod=»kube-apiserver-k8s- 1″,container=»kube-apiserver»,image= <\/p>\n
    <\/p>\n
    «gcr.io\/google-containers\/kube-apiserver:v1.14.5» <\/strong><\/p>\n
    <\/p>\n
    ,image_id=»docker-pullable:\/\/gcr.io\/google-containers\/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1 <\/p>\n
    <\/p>\n
    Durch einen einfachen Curl-Befehl aus einem nicht privilegierten Pod k\u00f6nnen Sie solche Informationen abrufen. Wenn Sie nicht wissen, welche Version von Kubernetes Sie verwenden, wird es Ihnen dies ganz leicht mitteilen. <\/p>\n
    <\/p>\n
    Das Interessanteste ist, dass Sie neben kube-state-metrics auch direkt auf Prometheus zugreifen k\u00f6nnen. Sie k\u00f6nnen Metriken von dort abrufen. Sie k\u00f6nnen sogar Metriken von dort erstellen. Theoretisch k\u00f6nnen Sie sogar eine Anfrage von einem Cluster an Prometheus stellen, die ihn einfach abschaltet. Dadurch funktioniert Ihre \u00dcberwachung im Cluster \u00fcberhaupt nicht mehr. <\/p>\n
    <\/p>\n
    Hier stellt sich die Frage, ob eine externe \u00dcberwachung Ihre \u00dcberwachung \u00fcberwacht. Gerade hatte ich die M\u00f6glichkeit, im Kubernetes-Cluster zu agieren, ohne irgendwelche Konsequenzen f\u00fcr mich zu haben. Sie werden nicht einmal erfahren, dass ich dort t\u00e4tig bin, da die \u00dcberwachung bereits nicht mehr existiert. <\/p>\n
    <\/p>\n
    Es f\u00fchlt sich \u00e4hnlich an wie mit PSP, als ob das Problem darin liegt, dass all diese modernen Technologien \u2013 Kubernetes, Prometheus \u2013 einfach nicht funktionieren und voller L\u00f6cher sind. In Wirklichkeit ist das nicht so. <\/p>\n
    <\/p>\n
    Es gibt so etwas wie \u2013 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Wenn Sie ein normaler Administrator sind, wissen Sie wahrscheinlich, dass Network Policy ein weiteres YAML ist, von denen es im Cluster ohnehin schon viele gibt. Und Network Policies sind sicherlich nicht unbedingt erforderlich. Selbst wenn Sie gelesen haben, was eine Network Policy ist, dass es eine YAML-Firewall von Kubernetes ist, die den Zugriff zwischen Namespaces und Pods einschr\u00e4nkt, dann haben Sie sicherlich beschlossen, dass eine Firewall im YAML-Format in Kubernetes bei den n\u00e4chsten Abstraktionen\u2026 Nein, nein. Das ist auf jeden Fall nicht n\u00f6tig. <\/p>\n
    <\/p>\n
    Selbst wenn Ihren Sicherheitsexperten nicht gesagt wurde, dass Sie mit Ihrem Kubernetes ganz einfach und unkompliziert eine sehr granulare Firewall erstellen k\u00f6nnen. Falls sie das noch nicht wissen und nicht fragen: \u201eNa, geben Sie, geben Sie\u2026\u201c Brauchen Sie in jedem Fall eine Network Policy, um den Zugriff auf bestimmte administrative Stellen zu sperren, die Sie aus Ihrem Cluster abrufen k\u00f6nnen, ohne jegliche Autorisierung. <\/p>\n
    <\/p>\n
    Wie im Beispiel, das ich angef\u00fchrt habe, kann kube state metrics aus jedem Namespace im Kubernetes-Cluster abgerufen werden, ohne daf\u00fcr irgendwelche Berechtigungen zu haben. Die Netzwerkrichtlinien haben den Zugang von allen anderen Namespaces zum Monitoring-Namespace gesperrt, und das war's: kein Zugang, kein Problem. In allen Charts, sowohl in der Standard-Prometheus-Implementation als auch in der Prometheus-Version, die im Operator verwendet wird, gibt es einfach die Option in den Helm-Values, die Netzwerkrichtlinien zu aktivieren. Man muss sie nur aktivieren, und sie werden funktionieren. <\/p>\n
    <\/p>\n
    Es gibt allerdings ein Problem. Als normaler, erfahrener Administrator haben Sie wahrscheinlich beschlossen, dass Netzwerkrichtlinien nicht notwendig sind. Und nachdem Sie verschiedene Artikel auf Plattformen wie Habr gelesen haben, haben Sie entschieden, dass Flannel, insbesondere im Host-Gateway-Modus, das Beste ist, was Sie w\u00e4hlen k\u00f6nnen. <\/p>\n
    <\/p>\n
    Was tun? <\/p>\n
    <\/p>\n
    Sie k\u00f6nnen versuchen, die Netzwerkl\u00f6sung, die Sie in Ihrem Kubernetes-Cluster haben, neu bereitzustellen und sie durch etwas Funktionaleres zu ersetzen, zum Beispiel durch das gleiche Calico. Aber ich m\u00f6chte gleich sagen, dass die Aufgabe, die Netzwerkl\u00f6sung in einem produktiven Kubernetes-Cluster zu \u00e4ndern, ziemlich komplex ist. Ich habe das zweimal gel\u00f6st (beide Male zwar theoretisch), aber wir haben sogar in Sl\u00ebrms gezeigt, wie das geht. F\u00fcr unsere Sch\u00fcler haben wir gezeigt, wie man die Netzwerkl\u00f6sung in einem Kubernetes-Cluster \u00e4ndert. Im Grunde k\u00f6nnen Sie versuchen, dies so zu machen, dass es im Produktiv-Cluster keine Ausfallzeiten gibt. Aber wahrscheinlich wird es Ihnen nicht gelingen. <\/p>\n
    <\/p>\n
    Das Problem l\u00e4sst sich tats\u00e4chlich sehr einfach l\u00f6sen. Im Cluster gibt es Zertifikate, und Sie wissen, dass Ihre Zertifikate in einem Jahr ablaufen werden. Nun, und normalerweise ist die \u00fcbliche L\u00f6sung mit Zertifikaten im Cluster \u2014 warum sich damit belasten? Wir heben einfach einen neuen Cluster daneben hoch, der alte kann ablaufen, und wir deployen alles neu. Nat\u00fcrlich, wenn es abl\u00e4uft, liegt alles einen Tag lang still, aber das neue Cluster steht bereit. <\/p>\n
    <\/p>\n
    Wenn Sie den neuen Cluster erstellen, f\u00fcgen Sie gleich Calico anstelle von Flannel ein. <\/p>\n
    <\/p>\n
    Was tun, wenn Sie Zertifikate f\u00fcr hundert Jahre ausgestellt haben und das Cluster nicht neu bereitstellen m\u00f6chten? Es gibt eine L\u00f6sung namens Kube-RBAC-Proxy. Diese gro\u00dfartige Entwicklung erm\u00f6glicht es, sich als Sidecar-Container in jeden Pod im Kubernetes-Cluster einzuf\u00fcgen und f\u00fcgt diesem Pod tats\u00e4chlich eine Autorisierung \u00fcber das RBAC von Kubernetes hinzu. <\/p>\n
    <\/p>\n
    Es gibt ein Problem. Fr\u00fcher war die L\u00f6sung Kube-RBAC-Proxy im Prometheus-Operator integriert. Das ist nicht mehr der Fall. Aktuelle Versionen setzen voraus, dass Sie eine Netzwerkpolice haben und diese verwenden. Daher m\u00fcssen die Charts ein wenig umgeschrieben werden. Wenn Sie tats\u00e4chlich auf dieses Repository erstellen,<\/a><\/noindex>, schauen, gibt es Beispiele, wie man es als Sidecar verwenden kann, und die Charts m\u00fcssen nur minimal umgeschrieben werden. <\/p>\n
    <\/p>\n
    Es gibt noch ein weiteres kleines Problem. Nicht nur Prometheus gibt seine Metriken an beliebige Empf\u00e4nger weiter. Auch alle Komponenten im Kubernetes-Cluster k\u00f6nnen ihre eigenen Metriken bereitstellen. <\/p>\n
    <\/p>\n
    Aber wie ich bereits sagte, wenn Sie keinen Zugang zum Cluster haben und keine Informationen sammeln k\u00f6nnen, k\u00f6nnen Sie wenigstens etwas Schaden anrichten. <\/p>\n
    <\/p>\n
    Ich werde Ihnen also schnell zwei Methoden zeigen, wie man die Gesundheit eines Kubernetes-Clusters beeintr\u00e4chtigen kann. <\/p>\n
    <\/p>\n
    Sie werden lachen, wenn ich das erz\u00e4hle, es sind zwei F\u00e4lle aus dem wirklichen Leben. <\/p>\n
    <\/p>\n
    Erste Methode. Ressourcenersch\u00f6pfung. <\/p>\n
    <\/p>\n
    Wir starten einen weiteren speziellen Pod. Er wird so eine Sektion haben. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Wie Sie wissen, sind requests die Menge an CPU und Speicher, die auf dem Host f\u00fcr bestimmte Pods mit Requests reserviert ist. Wenn wir einen vierkernigen Host im Kubernetes-Cluster haben und ein Pod mit einem Request von vier CPU ankommt, dann kann kein weiterer Pod mit Requests auf diesem Host ankommen. <\/p>\n
    <\/p>\n
    Wenn ich solch einen Pod starte, mache ich dann den Befehl: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Dann kann niemand mehr im Kubernetes-Cluster deployen. Denn in allen Nodes gehen die Requests aus. Auf diese Weise w\u00fcrde ich Ihren Kubernetes-Cluster zum Stillstand bringen. Wenn ich das am Abend mache, kann ich die Deployments ziemlich lange stoppen. <\/p>\n
    <\/p>\n
    Wenn wir ein weiteres Mal in die Kubernetes-Dokumentation schauen, sehen wir etwas, das als Limit Range bezeichnet wird. Es legt die Ressourcen f\u00fcr Clusterobjekte fest. Sie k\u00f6nnen ein YAML-Objekt f\u00fcr den Limit Range schreiben und es in bestimmten Namespaces anwenden \u2014 und dann in diesem Namespace k\u00f6nnen Sie angeben, dass Sie Standard-, Maximal- und Minimalressourcen f\u00fcr Pods haben.<\/p>\n
    <\/p>\n
    Mit so einem Mechanismus k\u00f6nnen wir Benutzer in bestimmten Produktnamespaces von Teams darin beschr\u00e4nken, jeglichen Unsinn in ihren Pods anzugeben. Aber leider, selbst wenn Sie dem Benutzer sagen, dass er Pods mit Requests von mehr als einer CPU nicht starten kann, gibt es diesen wunderbaren Befehl scale, oder \u00fcber das Dashboard k\u00f6nnen sie die Skalierung durchf\u00fchren.<\/p>\n
    <\/p>\n
    Und hieraus ergibt sich die zweite Methode. Wir starten 11 111 111 111 111 Pods. Das sind elf Milliarden. Das liegt nicht daran, dass ich mir diese Zahl ausgedacht habe, sondern weil ich es selbst gesehen habe. <\/p>\n
    <\/p>\n
    Echte Geschichte. Sp\u00e4t abends wollte ich bereits das B\u00fcro verlassen. Ich sah in einer Ecke eine Gruppe von Entwicklern, die hektisch an ihren Laptops arbeiteten. Ich ging zu den Jungs und fragte: \u201eWas ist denn los bei euch?\u201c<\/p>\n
    <\/p>\n
    Kurz nach neun Uhr abends wollte einer der Entwickler nach Hause gehen. Er dachte sich: \u201eIch werde jetzt meine Anwendung auf eins skalieren\u201c. Er dr\u00fcckte auf eins, aber das Internet stockte ein wenig. Er dr\u00fcckte erneut auf eins, dr\u00fcckte darauf und klackte auf Enter. Er tippte auf alles, was er konnte. Pl\u00f6tzlich lebte das Internet wieder auf \u2014 und alles begann, auf diese Zahl zu skalieren. <\/p>\n
    <\/p>\n
    Allerdings geschah diese Geschichte nicht auf Kubernetes, zu diesem Zeitpunkt war es Nomad. Das endete damit, dass nach einer Stunde unserer Versuche, Nomad von seinen hartn\u00e4ckigen Skalierungsversuchen abzuhalten, Nomad antwortete, dass es nicht aufh\u00f6ren w\u00fcrde zu skalieren und sich mit nichts anderem besch\u00e4ftigen w\u00fcrde. \u201eIch bin m\u00fcde, ich gehe\u201c. Und zog sich zur\u00fcck. <\/p>\n
    <\/p>\n
    Nat\u00fcrlich versuchte ich, dasselbe auf Kubernetes zu tun. Elf Milliarden Pods freuten Kubernetes nicht, es sagte: \u201eIch kann nicht. \u00dcberschreitet die internen Limits\u201c. Aber 1 000 000 000 Pods konnten skaliert werden. <\/p>\n
    <\/p>\n
    Als Reaktion auf eine Milliarden Pods hat sich Kubernetes nicht verabschiedet. Es hat tats\u00e4chlich begonnen, zu skalieren. Je weiter der Prozess voranschritt, desto mehr Zeit ben\u00f6tigte er, um neue Pods zu erstellen. Aber der Prozess lief trotzdem weiter. Das einzige Problem ist, dass ich in meinem Namespace unbegrenzt Pods starten kann. Selbst ohne Requests und Limits kann ich Aufgaben so viele Pods starten, dass die Knoten anfangen, hinsichtlich Speicher und CPU zu \u00fcberlasten. Wenn ich so viele Pods starte, m\u00fcssen die Informationen darin in den Speicher gelangen, sprich etcd. Und wenn zu viele Informationen dort ankommen, beginnt der Speicher, zu langsam zu antworten \u2014 und Kubernetes bekommt Verz\u00f6gerungen. <\/p>\n
    <\/p>\n
    Ein weiteres Problem\u2026 Wie Sie wissen, sind die Kubernetes-Steuerelemente nicht eine zentrale Einheit, sondern mehrere Komponenten. Dazu geh\u00f6ren unter anderem der Controller-Manager, der Scheduler und so weiter. All diese Komponenten beginnen gleichzeitig mit unn\u00f6tiger und ineffizienter Arbeit, die im Laufe der Zeit immer mehr Zeit in Anspruch nehmen wird. Der Controller-Manager wird neue Pods erstellen. Der Scheduler wird versuchen, ihnen einen neuen Node zuzuweisen. Die neuen Nodes in Ihrem Cluster werden wahrscheinlich bald ausgehen. Der Kubernetes-Cluster wird immer langsamer arbeiten.<\/p>\n
    <\/p>\n
    Aber ich habe mich entschieden, noch weiter zu gehen. Wie Sie wissen, gibt es in Kubernetes etwas, das Services genannt wird. Standardm\u00e4\u00dfig funktioniert der Service in Ihren Clustern wahrscheinlich \u00fcber IP-Tabellen. <\/p>\n
    <\/p>\n
    Wenn Sie beispielsweise eine Milliarde Pods starten und dann mit einem Skript Kubernetes anweisen, neue Services zu erstellen: <\/p>\n
    <\/p>\n
    for i in {1..1111111}; do\n    kubectl expose deployment test --port 80  \n        --overrides=\"{\"apiVersion\": \"v1\", \n           \"metadata\": {\"name\": \"nginx$i\"}}\"; \ndone <\/code><\/pre>\n
    <\/p>\n
    Auf allen Knoten des Clusters werden gleichzeitig st\u00e4ndig neue iptables-Regeln generiert. F\u00fcr jeden Dienst werden jeweils eine Milliarde iptables-Regeln erstellt. <\/p>\n
    <\/p>\n
    Ich habe das Ganze bei mehreren Tausend bis hin zu einem Dutzend \u00fcberpr\u00fcft. Und das Problem ist, dass es bereits an diesem Punkt ziemlich schwierig ist, eine SSH-Verbindung zu einem Knoten herzustellen. Da Pakete durch so viele Ketten laufen, beginnen sie, sich nicht besonders gut zu verhalten. <\/p>\n
    <\/p>\n
    Auch das l\u00e4sst sich mit Kubernetes l\u00f6sen. Es gibt ein Objekt, das Resource Quota hei\u00dft. Es legt die Anzahl der verf\u00fcgbaren Ressourcen und Objekte f\u00fcr einen Namespace im Cluster fest. Wir k\u00f6nnen ein YAML-Objekt in jedem Namespace des Kubernetes-Clusters erstellen. Mit diesem Objekt k\u00f6nnen wir angeben, dass f\u00fcr diesen Namespace eine bestimmte Anzahl an Requests und Limits zugewiesen ist, und wir k\u00f6nnen dann festlegen, dass in diesem Namespace 10 Dienste und 10 Pods erstellt werden k\u00f6nnen. Und der Entwickler kann sich am Abend damit besch\u00e4ftigen. Kubernetes wird ihm sagen: \u201eEs ist nicht m\u00f6glich, Ihre Pods auf diese Anzahl zu skalieren, da dies das Ressourcenquota \u00fcberschreitet.\u201c Problem gel\u00f6st. Dokumentation hier<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Ein problematischer Punkt ergibt sich dabei. Sie sp\u00fcren, wie schwierig es wird, einen Namespace in Kubernetes zu erstellen. Um ihn zu erstellen, m\u00fcssen wir eine Menge Aspekte ber\u00fccksichtigen.<\/p>\n
    <\/p>\n
    Ressourcenkontingent + Limitbereich + RBAC
    \n\u2022 Namespace erstellen
    \n\u2022 Limitbereich innerhalb erstellen
    \n\u2022 Ressourcenkontingent innerhalb erstellen
    \n\u2022 Servicekonto f\u00fcr CI erstellen
    \n\u2022 RoleBinding f\u00fcr CI und Benutzer erstellen
    \n\u2022 Optional ben\u00f6tigte Hilfspods starten <\/p>\n
    <\/p>\n
    Deshalb m\u00f6chte ich die Gelegenheit nutzen, um meine Entwicklungen zu teilen. Es gibt etwas, das nennt sich Operator SDK. Damit k\u00f6nnen Sie im Kubernetes-Cluster Operatoren schreiben. Sie k\u00f6nnen Operatoren mit Ansible erstellen.<\/p>\n
    <\/p>\n
    Zuerst hatten wir es in Ansible geschrieben, dann habe ich gesehen, dass es das Operator SDK gibt und ich die Ansible-Rolle in einen Operator umgeschrieben habe. Dieser Operator erm\u00f6glicht es, im Kubernetes-Cluster ein Objekt zu erstellen, das als Command bezeichnet wird. Innerhalb des Commands erlaubt es, die Umgebung f\u00fcr diesen Command in YAML zu beschreiben. Und innerhalb der Umgebung des Commands erm\u00f6glicht es, die Ressourcen, die wir zuweisen, anzugeben. <\/p>\n
    <\/p>\n
    Klein Erleichterung dieses gesamten komplexen Prozesses<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Und abschlie\u00dfend. Was machen wir jetzt mit all dem?
    \nZuerst: Eine Pod Security Policy ist wichtig. Und obwohl bis heute keiner der Kubernetes-Installer sie verwendet, sollten sie dennoch in Ihren Clustern genutzt werden. <\/p>\n
    <\/p>\n
    Eine Network Policy ist keine unn\u00f6tige Funktion. Sie ist tats\u00e4chlich notwendig f\u00fcr den Cluster. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota sollten definitiv eingesetzt werden. Wir nutzen das schon lange, und ich war lange Zeit \u00fcberzeugt, dass jeder das anwendet. Es stellte sich heraus, dass das eher selten ist. <\/p>\n
    <\/p>\n
    Neben dem, was ich in meinem Vortrag erw\u00e4hnt habe, gibt es undocumented Features, die Angriffe auf den Cluster erm\u00f6glichen. Neu ver\u00f6ffentlicht wurde eine umfangreiche Analyse von Kubernetes-Sicherheitsl\u00fccken.<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Einige Dinge sind so traurig und frustrierend. Beispielsweise k\u00f6nnen unter bestimmten Bedingungen die Kubelets im Kubernetes-Cluster den Inhalt des Verzeichnisses warlocks an nicht autorisierte Benutzer ausgeben. <\/p>\n
    <\/p>\n
    Hier<\/a><\/noindex> Es gibt Anleitungen zur Reproduzierung alles, was ich erkl\u00e4rt habe. Dort liegen Dateien mit Produktionsbeispielen, wie ResourceQuota und Pod Security Policy aussehen. Und all das kann man ausprobieren. <\/p>\n
    <\/p>\n
    Danke an alle.<\/p>\n
    Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39203","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\udd47Wir stopfen die L\u00f6cher im Kubernetes-Cluster. Vortrag und Transkript von der DevOpsConf | ProHoster","description":"Pavel Selivanov, Solutions Architect bei Southbridge und Dozent f\u00fcr Slurm, hielt einen Vortrag auf der DevOpsConf 2019. Diese Pr\u00e4sentation ist Teil eines der Themen des vertieften Kurses zu Kubernetes \u201eSlurm Mega\u201c. Slurm Basics: Einf\u00fchrung in Kubernetes findet in Moskau vom 18. bis 20. November statt. Slurm Mega: Ein Blick unter die Haube von Kubernetes \u2014 Moskau, 22. bis 24. November. Slurm Online: Beide Kubernetes-Kurse sind jederzeit verf\u00fcgbar.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","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\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","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-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","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-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/39203","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=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}