{"id":40721,"date":"2020-02-03T14:41:59","date_gmt":"2020-02-03T11:41:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka"},"modified":"2020-02-03T14:41:59","modified_gmt":"2020-02-03T11:41:59","slug":"nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka","title":{"rendered":"Unsere Erfahrungen bei der Entwicklung eines CSI-Treibers in Kubernetes f\u00fcr Yandex.Cloud","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Unsere Erfahrungen bei der Entwicklung eines CSI-Treibers in Kubernetes f\u00fcr Yandex.Cloud\" src=\"\/wp-content\/uploads\/2020\/02\/86adf77b2ee08c426bf79c5b9b2d3d1e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWir freuen uns, bekannt zu geben, dass das Unternehmen \u201eFlant\u201c seinen Beitrag zu Open Source-Tools f\u00fcr Kubernetes erweitert, indem es <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/yandex-csi-driver\">die Alpha-Version des CSI-Treibers<\/a><\/noindex> (Container Storage Interface) f\u00fcr Yandex.Cloud ver\u00f6ffentlicht.<\/p>\n<p>Bevor wir jedoch auf die Einzelheiten der Implementierung eingehen, wollen wir die Frage beantworten, wozu das \u00fcberhaupt n\u00f6tig ist, wenn Yandex bereits den Dienst <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.yandex.ru\/docs\/managed-kubernetes\/\">Managed Service for Kubernetes<\/a><\/noindex>.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Einf\u00fchrung<\/h2>\n<p><\/p>\n<h3>Warum das?<\/h3>\n<p>\nanbietet. Innerhalb unseres Unternehmens entwickelt sich seit den ersten Tagen des Betriebs von Kubernetes in der Produktion (also seit mehreren Jahren) ein eigenes Tool (Deckhouse), das wir \u00fcbrigens auch bald als Open Source-Projekt verf\u00fcgbar machen wollen. Mit diesem Tool konfigurieren und verwalten wir unsere Cluster einheitlich, und derzeit haben wir \u00fcber 100 Cluster, die auf den unterschiedlichsten Hardwarekonfigurationen und in allen verf\u00fcgbaren Cloud-Services laufen.<\/p>\n<p>Die Cluster, die Deckhouse verwenden, haben alle erforderlichen Komponenten f\u00fcr den Betrieb: Load Balancer, Monitoring mit benutzerfreundlichen Diagrammen, Metriken und Alarme, Benutzerauthentication \u00fcber externe Anbieter f\u00fcr den Zugang zu allen Dashboards und vieles mehr. Ein solch \u201eaufger\u00fcsteter\u201c Cluster macht in einer verwalteten L\u00f6sung keinen Sinn, da dies oft entweder unm\u00f6glich ist oder zur Notwendigkeit f\u00fchrt, die H\u00e4lfte der Komponenten abzuschalten.<\/p>\n<p><i><b>NB<\/b>: Das ist unsere Erfahrung, und sie ist recht spezifisch. Wir behaupten keineswegs, dass alle selbst Cluster von Kubernetes bereitstellen sollten, anstatt fertige L\u00f6sungen zu nutzen. \u00dcbrigens haben wir keine praktische Erfahrung mit dem Betrieb von Kubernetes bei Yandex, und in diesem Artikel werden wir keine Bewertung dieses Dienstes abgeben.<\/i><\/p>\n<h3>Was ist das und f\u00fcr wen?<\/h3>\n<p>\nAlso, wir haben bereits \u00fcber den modernen Ansatz zur Speicherung in Kubernetes gesprochen: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424211\/\">wie CSI funktioniert<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465417\/\">wie die Gemeinschaft zu diesem Ansatz gekommen ist.<\/a><\/noindex> Derzeit haben viele gro\u00dfe Cloud-Anbieter Treiber entwickelt, um ihre \u201eCloud\u201c-Festplatten als Persistent Volume in Kubernetes zu nutzen. Wenn ein Anbieter jedoch keinen solchen Treiber hat, aber alle notwendigen Funktionen \u00fcber die API bereitstellt, steht der Implementierung eines eigenen Treibers nichts im Wege. So ist es uns mit Yandex.Cloud ergangen.<\/p>\n<p>Als Grundlage f\u00fcr die Entwicklung haben wir<\/p>\n<p>den CSI-Treiber f\u00fcr die Cloud von DigitalOcean <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/digitalocean\/csi-digitalocean\">und ein paar Ideen aus<\/a><\/noindex> dem Treiber f\u00fcr GCP <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-sigs\/gcp-compute-persistent-disk-csi-driver\">, da die Interaktion mit der API dieser Clouds (Google und Yandex) einige \u00c4hnlichkeiten aufweist. Insbesondere sind die APIs bei<\/a><\/noindex>sowohl <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/compute\/docs\/api\/how-tos\/api-requests-responses#handling_api_responses\">GCP<\/a><\/noindex>als auch <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.yandex.ru\/docs\/api-design-guide\/concepts\/about-async\">Yandex.<\/a><\/noindex> Geben das Objekt zur\u00fcck <code>Betrieb<\/code> zur Verfolgung des Status von langfristigen Operationen (zum Beispiel der Erstellung eines neuen Datentr\u00e4gers). Zur Interaktion mit der API von Yandex.Cloud wird verwendet <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/yandex-cloud\/go-sdk\">Yandex.Cloud Go SDK<\/a><\/noindex>.<\/p>\n<p>Das Ergebnis der geleisteten Arbeit <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/yandex-csi-driver\">wurde auf GitHub ver\u00f6ffentlicht<\/a><\/noindex> und kann f\u00fcr diejenigen n\u00fctzlich sein, die aus irgendeinem Grund ihre eigene Kubernetes-Installation auf virtuellen Maschinen von Yandex.Cloud verwenden (aber nicht ein fertiger verwalteter Cluster) und die Disks \u00fcber CSI nutzen m\u00f6chten (bestellen).<\/p>\n<h2>Implementierung<\/h2>\n<p><\/p>\n<h3>Hauptmerkmale<\/h3>\n<p>\nAktuell unterst\u00fctzt der Treiber folgende Funktionen:<\/p>\n<ul>\n<li> Bestellung von Disks in allen Cluster-Zonen gem\u00e4\u00df der Topologie der vorhandenen Knoten im Cluster;<\/li>\n<li> L\u00f6schen zuvor bestellter Disks;<\/li>\n<li> Offline-Gr\u00f6\u00dfe f\u00fcr Disks (Yandex.Cloud <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.yandex.ru\/docs\/compute\/operations\/disk-control\/update#change-disk-size\">unterst\u00fctzt<\/a><\/noindex> Erh\u00f6hung von Disks, die an einer virtuellen Maschine angemeldet sind). Wie der Treiber bearbeitet werden musste, um die Gr\u00f6\u00dfe m\u00f6glichst schmerzfrei zu \u00e4ndern, siehe weiter unten.<\/li>\n<\/ul>\n<p>\nZuk\u00fcnftig ist die Unterst\u00fctzung f\u00fcr die Erstellung und L\u00f6schung von Snapshots von Disks geplant.<\/p>\n<h3>Die Hauptschwierigkeit und deren \u00dcberwindung<\/h3>\n<p>\nDas Fehlen der M\u00f6glichkeit in der API von Yandex.Cloud, Disks in Echtzeit zu vergr\u00f6\u00dfern \u2013 eine Einschr\u00e4nkung, die die Resize-Operation f\u00fcr PV (Persistent Volume) kompliziert: Denn in diesem Fall muss sichergestellt werden, dass das Pod der Anwendung, das die Disk verwendet, gestoppt wird, was zu Ausfallzeiten der Anwendung f\u00fchren kann.<\/p>\n<p>Laut <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/container-storage-interface\/spec\">der CSI-Spezifikation,<\/a><\/noindex>, wenn der CSI-Controller meldet, dass er die Gr\u00f6\u00dfe der Disks nur \u201eoffline\u201c anpassen kann (<code>VolumeExpansion.OFFLINE<\/code>), muss der Prozess der Diskvergr\u00f6\u00dferung folgenderma\u00dfen ablaufen:<\/p>\n<blockquote><p>Wenn das Plugin nur <code>VolumeExpansion.OFFLINE<\/code> die Erweiterungsf\u00e4higkeit besitzt und das Volume derzeit auf einem Knoten ver\u00f6ffentlicht oder verf\u00fcgbar ist, dann <code>ControllerExpandVolume<\/code> muss NUR nach einem der folgenden Aufrufe erfolgen:<\/p>\n<ul>\n<li> Das Plugin hat Controller- <code>PUBLISH_UNPUBLISH_VOLUME<\/code> F\u00e4higkeit und <code>ControllerUnpublishVolume<\/code> wurde erfolgreich aufgerufen.<\/li>\n<\/ul>\n<p>\nODER<\/p>\n<ul>\n<li> Das Plugin hat NICHT die controller- <code>PUBLISH_UNPUBLISH_VOLUME<\/code> F\u00e4higkeit, das Plugin hat node- <code>STAGE_UNSTAGE_VOLUME<\/code> F\u00e4higkeit, und <code>NodeUnstageVolume<\/code> wurde erfolgreich abgeschlossen.<\/li>\n<\/ul>\n<p>\nODER<\/p>\n<ul>\n<li>Das Plugin hat NICHT die controller- <code>PUBLISH_UNPUBLISH_VOLUME<\/code> F\u00e4higkeit, noch node- <code>STAGE_UNSTAGE_VOLUME<\/code> F\u00e4higkeit, und <code>NodeUnpublishVolume<\/code> wurde erfolgreich abgeschlossen.<\/li>\n<\/ul>\n<\/blockquote>\n<p>\nIm Grunde bedeutet dies, dass die Disk von der virtuellen Maschine getrennt werden muss, bevor sie vergr\u00f6\u00dfert wird.<\/p>\n<p>Leider jedoch <b>die Implementierung<\/b> entspricht die CSI-Spezifikation \u00fcber Sidecars diesen Anforderungen nicht:<\/p>\n<ul>\n<li> Im Sidecar-Container <code>csi-attacher<\/code>, der daf\u00fcr verantwortlich sein sollte, dass der n\u00f6tige Abstand zwischen den Montierungen gewahrt bleibt, wurde diese Funktionalit\u00e4t beim Offline-Resize einfach nicht implementiert. Die Diskussion dar\u00fcber wurde initiiert <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-csi\/external-attacher\/issues\/207\">hier<\/a><\/noindex>.<\/li>\n<li> Was ist \u00fcberhaupt ein Sidecar-Container in diesem Kontext? Das CSI-Plugin kommuniziert nicht mit der Kubernetes-API, sondern reagiert nur auf gRPC-Aufrufe, die von Sidecar-Containern gesendet werden. Letztere <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes-csi.github.io\/docs\/sidecar-containers.html\">werden entwickelt<\/a><\/noindex> sind Teil der Kubernetes-Community.<\/li>\n<\/ul>\n<p>\nIn unserem Fall (CSI-Plugin) sieht der Vorgang zur Erweiterung des Volumes folgenderma\u00dfen aus:<\/p>\n<ol>\n<li> Wir erhalten einen gRPC-Aufruf <code>ControllerExpandVolume<\/code>;<\/li>\n<li> Wir versuchen, das Volume \u00fcber die API zu vergr\u00f6\u00dfern, erhalten jedoch einen Fehler, dass der Vorgang nicht ausgef\u00fchrt werden kann, da das Volume gemountet ist;<\/li>\n<li> Wir speichern die ID des Volumes in einer Map, die die Volumes enth\u00e4lt, f\u00fcr die der Vergr\u00f6\u00dferungsvorgang durchgef\u00fchrt werden muss. Um der K\u00fcrze willen werden wir diesen Map als <code>volumeResizeRequired<\/code>;<\/li>\n<li> manuell l\u00f6schen wir den Pod, der das Volume verwendet. Kubernetes wird ihn daraufhin neu starten. Um zu verhindern, dass das Volume sich bereits<code>ControllerPublishVolume<\/code>) vor Abschluss des Vergr\u00f6\u00dferungsvorgangs beim Versuch des Mountens gemountet wird, \u00fcberpr\u00fcfen wir, ob sich dieses Volume noch in <code>volumeResizeRequired<\/code> und geben einen Fehler zur\u00fcck;<\/li>\n<li> Der CSI-Treiber versucht, den Resize-Vorgang erneut auszuf\u00fchren. Wenn der Vorgang erfolgreich war, entfernen wir das Volume aus <code>volumeResizeRequired<\/code>;<\/li>\n<li> Da die ID des Volumes nicht in <code>volumeResizeRequired<\/code>, <code>ControllerPublishVolume<\/code> vorhanden ist, verl\u00e4uft der Vorgang erfolgreich, das Volume wird gemountet und der Pod startet.<\/li>\n<\/ol>\n<p>\nAlles scheint recht einfach zu sein, aber wie immer gibt es einige Fallstricke. F\u00fcr die Vergr\u00f6\u00dferung von Volumes ist <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes-csi.github.io\/docs\/external-resizer.html\">external-resizer<\/a><\/noindex>, der im Falle eines Fehlers beim Ausf\u00fchren des Vorgangs <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes-csi\/external-resizer\/blob\/master\/vendor\/k8s.io\/client-go\/util\/workqueue\/default_rate_limiters.go#L41\">eine Warteschlange<\/a><\/noindex> mit exponentieller Zeit\u00fcberschreitungsverl\u00e4ngerung bis zu 1000 Sekunden verwendet:<\/p>\n<pre><code class=\"go\">func DefaultControllerRateLimiter() RateLimiter {\n  return NewMaxOfRateLimiter(\n  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),\n  \n  &amp;BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},\n  )\n}<\/code><\/pre>\n<p>\nDas kann dazu f\u00fchren, dass der Vorgang zur Vergr\u00f6\u00dferung des Volumes 15 Minuten oder l\u00e4nger dauert und somit der entsprechende Pod nicht verf\u00fcgbar ist.<\/p>\n<p>Die einzige M\u00f6glichkeit, die uns relativ einfach und schmerzfrei geholfen hat, potenzielle Ausfallzeiten zu reduzieren, war die Verwendung unserer eigenen Version des external-resizers mit einer maximalen Zeit\u00fcberschreitung <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/external-resizer\/blob\/faster-workqueue\/pkg\/controller\/controller.go#L81\">von 5 Sekunden<\/a><\/noindex>:<\/p>\n<pre><code class=\"go\">workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)<\/code><\/pre>\n<p>\nWir hielten es nicht f\u00fcr notwendig, kurzfristig eine Diskussion zu initiieren und external-resizer zu patchen, da das Offline-Resize von Volumes ein Relikt ist, das bald bei allen Cloud-Anbietern verschwinden wird.<\/p>\n<h2>Wie f\u00e4ngt man an?<\/h2>\n<p>\nDer Treiber wird in Kubernetes version 1.15 und h\u00f6her unterst\u00fctzt. F\u00fcr die Funktionsweise des Treibers m\u00fcssen folgende Anforderungen erf\u00fcllt sein:<\/p>\n<ul>\n<li> Flag <code>--allow-privileged<\/code> auf <code>true<\/code> f\u00fcr den API-Server und kubelet;<\/li>\n<li> Aktiviert <code>--feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true<\/code> f\u00fcr den API-Server und kubelet;<\/li>\n<li> Mount-Popagation (<noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/volumes\/#mount-propagation\">mount propagation<\/a><\/noindex>) muss im Cluster aktiviert sein. Bei der Verwendung von Docker muss der Daemon so konfiguriert sein, dass gemeinsame Mount-Objekte (shared mounts) erlaubt sind.<\/li>\n<\/ul>\n<p>\nAlle notwendigen Schritte zur Installation <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/yandex-csi-driver#installing-driver\">sind in der README<\/a><\/noindex>. Die Installation besteht darin, Objekte in Kubernetes aus Manifesten zu erstellen.<\/p>\n<p>F\u00fcr den Betrieb des Treibers ben\u00f6tigen Sie Folgendes:<\/p>\n<ul>\n<li> Geben Sie im Manifest die ID des Ordners (<code>folder-id<\/code>) von Yandex.Cloud an (<noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.yandex.ru\/docs\/resource-manager\/operations\/folder\/get-id\">siehe Dokumentation<\/a><\/noindex>);<\/li>\n<li> Zur Interaktion mit der Yandex.Cloud API wird im CSI-Treiber ein Dienstkonto verwendet. Im Secret-Manifest m\u00fcssen Sie <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.yandex.com\/docs\/iam\/concepts\/authorization\/key\">die autorisierten Schl\u00fcssel<\/a><\/noindex> des Dienstkontos \u00fcbergeben. In der Dokumentation <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.yandex.ru\/docs\/iam\/quickstart-sa\">beschrieben<\/a><\/noindex>, wie Sie ein Dienstkonto erstellen und Schl\u00fcssel erhalten.<\/li>\n<\/ul>\n<p>\nIm Allgemeinen \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/yandex-csi-driver\">versuchen Sie es<\/a><\/noindex>, und wir freuen uns auf Ihr Feedback und <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/yandex-csi-driver\/issues\">neue Issues<\/a><\/noindex>, falls Sie auf Probleme sto\u00dfen!<\/p>\n<h2>Weitere Unterst\u00fctzung<\/h2>\n<p>\nZum Schluss m\u00f6chten wir betonen, dass wir diesen CSI-Treiber nicht aus einem gro\u00dfen Wunsch heraus, Anwendungen in Go zu schreiben, entwickelt haben, sondern aus einer dringenden Notwendigkeit im Unternehmen. Es scheint uns nicht sinnvoll, die eigene Implementierung zu unterst\u00fctzen, daher w\u00fcrden wir, falls Yandex Interesse zeigt und die Unterst\u00fctzung des Treibers fortsetzt, gerne das Repository in deren Verantwortung \u00fcbergeben.<\/p>\n<p>Au\u00dferdem hat Yandex wahrscheinlich im verwalteten Kubernetes-Cluster eine eigene Implementierung des CSI-Treibers, die als Open Source ver\u00f6ffentlicht werden kann. Diese Entwicklungsm\u00f6glichkeit sehen wir ebenfalls positiv \u2014 die Community kann von einem bew\u00e4hrten Treiber des Dienstanbieters profitieren und nicht von einer dritten Partei.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465417\/\">Volumes-Plugins f\u00fcr Speicher in Kubernetes: von Flexvolume zu CSI<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/424211\/\">Verstehen Sie die Container Storage Interface (in Kubernetes und nicht nur)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/455543\/\">Kubernetes-Cluster einfach und bequem einrichten? Wir k\u00fcndigen den Addon-Operator an<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/455543\/\">Erweiterung und Erg\u00e4nzung von Kubernetes (\u00dcbersicht und Video des Berichts)<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/486190\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0420\u0430\u0434\u044b \u043e\u0431\u044a\u044f\u0432\u0438\u0442\u044c, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f \u00ab\u0424\u043b\u0430\u043d\u0442\u00bb \u043f\u043e\u043f\u043e\u043b\u043d\u044f\u0435\u0442 \u0441\u0432\u043e\u0439 \u0432\u043a\u043b\u0430\u0434 \u0432 Open Source-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0434\u043b\u044f Kubernetes, \u0432\u044b\u043f\u0443\u0441\u0442\u0438\u0432 \u0430\u043b\u044c\u0444\u0430-\u0432\u0435\u0440\u0441\u0438\u044e \u0434\u0440\u0430\u0439\u0432\u0435\u0440\u0430 CSI (Container Storage Interface) \u0434\u043b\u044f \u042f\u043d\u0434\u0435\u043a\u0441.\u041e\u0431\u043b\u0430\u043a\u0430. \u041d\u043e \u043f\u0435\u0440\u0435\u0434 \u0442\u0435\u043c, \u043a\u0430\u043a \u043f\u0435\u0440\u0435\u0439\u0442\u0438 \u043a \u0434\u0435\u0442\u0430\u043b\u044f\u043c \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438, \u043e\u0442\u0432\u0435\u0442\u0438\u043c \u043d\u0430 \u0432\u043e\u043f\u0440\u043e\u0441, \u0437\u0430\u0447\u0435\u043c \u044d\u0442\u043e \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0443\u0436\u043d\u043e, \u043a\u043e\u0433\u0434\u0430 \u0443 \u042f\u043d\u0434\u0435\u043a\u0441\u0430 \u0443\u0436\u0435 \u0435\u0441\u0442\u044c \u0443\u0441\u043b\u0443\u0433\u0430 Managed Service for Kubernetes. \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0417\u0430\u0447\u0435\u043c \u044d\u0442\u043e? \u0412\u043d\u0443\u0442\u0440\u0438 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0435\u0449\u0451 \u0441 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":40722,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-40721","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0420\u0430\u0434\u044b \u043e\u0431\u044a\u044f\u0432\u0438\u0442\u044c, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041d\u0430\u0448 \u043e\u043f\u044b\u0442 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 CSI-\u0434\u0440\u0430\u0439\u0432\u0435\u0440\u0430 \u0432 Kubernetes \u0434\u043b\u044f \u042f\u043d\u0434\u0435\u043a\u0441.\u041e\u0431\u043b\u0430\u043a\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0420\u0430\u0434\u044b \u043e\u0431\u044a\u044f\u0432\u0438\u0442\u044c, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-03T11:41:59+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-03T11:41:59+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Unsere Erfahrungen bei der Entwicklung eines CSI-Treibers in Kubernetes f\u00fcr Yandex.Cloud | ProHoster","description":"Wir freuen uns, bekannt zu geben, dass die Firma.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka","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\u041d\u0430\u0448 \u043e\u043f\u044b\u0442 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 CSI-\u0434\u0440\u0430\u0439\u0432\u0435\u0440\u0430 \u0432 Kubernetes \u0434\u043b\u044f \u042f\u043d\u0434\u0435\u043a\u0441.\u041e\u0431\u043b\u0430\u043a\u0430 | ProHoster","og:description":"\u0420\u0430\u0434\u044b \u043e\u0431\u044a\u044f\u0432\u0438\u0442\u044c, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f.","og:url":"https:\/\/prohoster.info\/de\/blog\/nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka","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":"2020-02-03T11:41:59+00:00","article:modified_time":"2020-02-03T11:41:59+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"40721","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:32:40","updated":"2022-09-30 15:42:14","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\/40721","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=40721"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/40721\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/40722"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=40721"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=40721"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=40721"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}