{"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\/en\/blog\/nash-opyt-razrabotki-csi-drajvera-v-kubernetes-dlya-yandeks-oblaka","title":{"rendered":"Our experience in developing a CSI driver in Kubernetes for Yandex.Cloud","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Our
\n
\nWe are pleased to announce that Flant has expanded its contribution to Open Source tools for Kubernetes by releasing the alpha version of the CSI driver<\/a><\/noindex> (Container Storage Interface) for Yandex.Cloud.<\/p>\n

But before diving into the implementation details, let's address the question of why this is needed at all, given that Yandex already offers Managed Service for Kubernetes<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Introduction<\/h2>\n

<\/p>\n

Why is this needed?<\/h3>\n

\nWithin our company, since the very beginning of running Kubernetes in production (i.e., for several years now), we have been developing our own tool (deckhouse), which we also plan to make available as an Open Source project soon. With it, we configure and manage all our clusters uniformly, currently numbering over 100, deployed on various hardware configurations and across all available cloud services.<\/p>\n

Clusters using deckhouse incorporate all the components necessary for operation: load balancers, monitoring with convenient graphs, metrics, and alerts, user authentication via external providers for access to all dashboards, and so on. Such an 'enhanced' cluster makes little sense to implement in a managed solution, as often this either isn't possible or would require disabling half of its components.<\/p>\n

NB<\/b>: This is our experience, and it is quite specific. We do not claim that everyone should independently deploy Kubernetes clusters instead of using ready-made solutions. By the way, we do not have any real-world experience with Yandex's Kubernetes service, and we will not make any assessments of this service in the present article.<\/i><\/p>\n

What is this and for whom?<\/h3>\n

\nSo, we have already discussed the modern approach to storage in Kubernetes: how CSI works<\/a><\/noindex> and how the community arrived<\/a><\/noindex> at such an approach.<\/p>\n

Currently, many large cloud service providers have developed drivers to use their 'cloud' disks as Persistent Volumes in Kubernetes. However, if a provider does not have such a driver but provides all necessary functions through an API, there is nothing preventing us from implementing a driver ourselves. That\u2019s how we came to create one for Yandex.Cloud.<\/p>\n

We based our development on the CSI driver for DigitalOcean<\/a><\/noindex> and a few ideas from the driver for GCP<\/a><\/noindex>, as the interaction with the APIs of these clouds (Google and Yandex) has several similarities. In particular, both APIs and GCP<\/a><\/noindex>, and Yandex<\/a><\/noindex> return an object Operation<\/code> for tracking the status of long operations (for example, creating a new disk). To interact with the Yandex.Cloud API, the Yandex.Cloud Go SDK<\/a><\/noindex>.<\/p>\n

The result of the work done is published on GitHub<\/a><\/noindex> and may be useful for those who for some reason use their own Kubernetes installation on Yandex.Cloud virtual machines (but not a ready-made managed cluster) and would like to use (order) disks via CSI.<\/p>\n

Implementation<\/h2>\n

<\/p>\n

Key Features<\/h3>\n

\nCurrently, the driver supports the following features:<\/p>\n