Kubernetes で Yandex.Cloud 用の CSI ドライバーを開発した経験

Flant がリリースをリリースすることで、Kubernetes 用のオープンソース ツールへの貢献を拡大していることを発表できることを嬉しく思います。 CSIドライバーのアルファ版 Yandex.Cloud の (コンテナ ストレージ インターフェイス)。

ただし、実装の詳細に進む前に、Yandex にはすでにサービスがあるのに、なぜこれが必要なのかという質問に答えてみましょう。 Kubernetes のマネージド サービス.

導入

これはなぜですか？

当社では、実稼働環境で Kubernetes を使用し始めた当初から (つまりここ数年)、独自のツール (デッキハウス) を開発してきました。ちなみに、これも間もなくオープンソース プロジェクトとして利用可能にする予定です。 。 その助けを借りて、すべてのクラスターを均一に構成しており、現在、さまざまなハードウェア構成と利用可能なすべてのクラウド サービス上に、すでに 100 を超えるクラスターが存在しています。

デッキハウスを使用するクラスターには、バランサー、便利なチャートによるモニタリング、メトリックとアラート、すべてのダッシュボードにアクセスするための外部プロバイダーによるユーザー認証など、運用に必要なすべてのコンポーネントが含まれています。 このような「ポンプアップされた」クラスターを管理ソリューションにインストールすることは、多くの場合不可能であるか、コンポーネントの半分を無効にする必要があるため、意味がありません。

NB: これは私たちの経験であり、非常に具体的です。 私たちは、誰もが既製のソリューションを使用するのではなく、独自に Kubernetes クラスターをデプロイする必要があると提案しているわけではありません。 ちなみに、私たちには Yandex から Kubernetes を運用した実際の経験はなく、この記事ではこのサービスの評価は行いません。

それは何ですか、誰のためですか?

したがって、Kubernetes のストレージに対する最新のアプローチについてはすでに説明しました。 CSIはどのように機能しますか? и コミュニティはどのようにして生まれたのか このアプローチに。

現在、多くの大規模クラウド サービス プロバイダーは、クラウド ディスクを Kubernetes の永続ボリュームとして使用するためのドライバーを開発しています。 サプライヤーがそのようなドライバーを持っていないが、必要な機能がすべて API 経由で提供されている場合は、ドライバーを自分で実装することを妨げるものはありません。 これがYandex.Cloudで起こったことです。

開発の基礎として採用しました DigitalOcean クラウド用の CSI ドライバー そしていくつかのアイデアを GCP 用ドライバー、これらのクラウド (Google と Yandex) の API とのやり取りには多くの類似点があるためです。 特に、API と GCPそしてあなた Yandexの オブジェクトを返す Operation 長時間実行操作 (新しいディスクの作成など) のステータスを追跡します。 Yandex.Cloud API と対話するには、次を使用します。 Yandex.Cloud Go SDK.

行われた作業の結果 GitHub で公開 また、何らかの理由で、Yandex.Cloud 仮想マシン (ただし、既製のマネージド クラスターではない) 上で独自の Kubernetes インストールを使用し、CSI を通じてディスクを使用 (注文) したい人にとっては役立つかもしれません。

具現化

主な機能

現在、ドライバーは次の機能をサポートしています。

• クラスター内のノードのトポロジーに従って、クラスターのすべてのゾーン内のディスクを順序付けします。
• 以前に注文したディスクを削除する。
• ディスクのオフライン サイズ変更 (Yandex.Cloud) サポートしていません 仮想マシンにマウントされるディスクを増やします)。 サイズ変更をできるだけ簡単に行うためにドライバーをどのように変更する必要があるかについては、以下を参照してください。

将来的には、ディスク スナップショットの作成と削除のサポートを実装する予定です。

主な困難とそれを克服する方法

Yandex.Cloud API にはリアルタイムでディスクを増やす機能がないため、PV (永続ボリューム) のサイズ変更操作が複雑になります。この場合、ディスクを使用するアプリケーション ポッドを停止する必要があります。これにより、アプリケーションのダウンタイムが発生する可能性があります。

による CSI仕様、CSI コントローラーが「オフライン」でのみディスクのサイズを変更できると報告した場合 (VolumeExpansion.OFFLINE)、ディスクを増やすプロセスは次のようになります。

プラグインにのみある場合 VolumeExpansion.OFFLINE 拡張機能とボリュームが現在公開されているか、ノード上で利用可能である場合 ControllerExpandVolume 次のいずれかの後にのみ呼び出す必要があります。

• プラグインにはコントローラーがあります PUBLISH_UNPUBLISH_VOLUME 能力と ControllerUnpublishVolume 正常に呼び出されています。

あるいはそれ以外

• プラグインにはコントローラーがありません PUBLISH_UNPUBLISH_VOLUME 機能、プラグインにはノードがあります STAGE_UNSTAGE_VOLUME 能力、そして NodeUnstageVolume 正常に完了しました。

あるいはそれ以外

• プラグインにはコントローラーがありません PUBLISH_UNPUBLISH_VOLUME 能力もノードも STAGE_UNSTAGE_VOLUME 能力、そして NodeUnpublishVolume 正常に完了しました。

これは基本的に、仮想マシンを拡張する前にディスクを仮想マシンから切り離す必要があることを意味します。

ただし、残念ながら 実装 サイドカーを介した CSI 仕様は、次の要件を満たしていません。

• サイドカーコンテナ内 csi-attacherマウント間に必要なギャップが存在する原因となるはずですが、この機能は単にオフライン サイズ変更では実装されていません。 これについての議論が始まりました ここで.
• この文脈におけるサイドカー コンテナとは正確には何でしょうか? CSI プラグイン自体は Kubernetes API と対話せず、サイドカー コンテナーによって送信された gRPC 呼び出しにのみ応答します。 最新 開発中です Kubernetes コミュニティによる。

私たちの場合 (CSI プラグイン)、ディスクを増やす操作は次のようになります。

1. gRPC 呼び出しを受信します ControllerExpandVolume;
2. API でディスクを増やそうとしていますが、ディスクがマウントされているため操作を実行できないというエラーが表示されます。
3. 増加操作を実行する必要があるディスクを含むマップにディスク識別子を保存します。 以下では、簡潔にするために、このマップを次のように呼びます。 volumeResizeRequired;
4. ディスクを使用しているポッドを手動で削除します。 Kubernetes が再起動します。 ディスクをマウントする時間がないように (ControllerPublishVolume) マウントしようとするときに増加操作を完了する前に、指定されたディスクがまだ存在することを確認します。 volumeResizeRequired そしてエラーを返します。
5. CSI ドライバーは、サイズ変更操作の再実行を試行します。 操作が成功した場合は、ディスクを次から取り外します。 volumeResizeRequired;
6. なぜならディスク ID がありません volumeResizeRequired, ControllerPublishVolume 成功すると、ディスクがマウントされ、ポッドが開始されます。

すべてが非常に単純に見えますが、いつものように落とし穴があります。 ディスクを拡大します 外部リサイザー、操作中にエラーが発生した場合 キューを使用する タイムアウト時間は最大 1000 秒まで指数関数的に増加します。

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

これにより、ディスク拡張操作が 15 分以上延長され、対応するポッドが使用できなくなることが定期的に発生する可能性があります。

潜在的なダウンタイムを非常に簡単かつ苦痛なく削減できる唯一のオプションは、最大タイムアウト制限を備えたバージョンの external-resizer を使用することでした。 5秒以内に:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

ディスクのオフライン サイズ変更は、まもなくすべてのクラウド プロバイダーから廃止される先祖返りであるため、緊急に議論を開始して外部リサイザーにパッチを適用する必要があるとは考えませんでした。

使用を開始するにはどうすればよいですか?

このドライバーは、Kubernetes バージョン 1.15 以降でサポートされています。 ドライバーが動作するには、次の要件を満たす必要があります。

• Флаг --allow-privileged 値に設定 true API サーバーと kubelet の場合。
• 付属 --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API サーバーと kubelet の場合。
• マウント伝播 (マウント伝播) をクラスター上で有効にする必要があります。 Docker を使用する場合、共有マウントを許可するようにデーモンを構成する必要があります。

インストール自体に必要なすべての手順 READMEに記載されている。 インストールには、マニフェストから Kubernetes にオブジェクトを作成することが含まれます。

ドライバーが動作するには、次のものが必要です。

• マニフェストでディレクトリ識別子を指定します (folder-id) Yandex.Cloud (ドキュメントを参照してください);
• Yandex.Cloud API と対話するために、CSI ドライバーはサービス アカウントを使用します。 マニフェストでは Secret を渡す必要があります 認可されたキー サービスアカウントから。 ドキュメントでは 説明された、サービス アカウントを作成してキーを取得する方法。

全体として - 試してみるフィードバックをお待ちしております。 新しい問題何か問題が発生した場合は！

さらなるサポート

その結果、この CSI ドライバーを実装したのは、Go でアプリケーションを楽しく書きたいという強い願望からではなく、社内での緊急の必要性からであることに注意してください。 私たちにとって、独自の実装を維持することは現実的ではないと思われるため、Yandex が関心を示し、ドライバーのサポートを継続することを決定した場合は、喜んでリポジトリを彼らに転送します。

さらに、Yandex はおそらく、マネージド Kubernetes クラスターに CSI ドライバーの独自の実装を持っており、オープンソースでリリースできます。 また、この開発オプションは有利であると考えています。コミュニティは、サードパーティ企業ではなく、サービス プロバイダーの実績のあるドライバーを使用できるようになります。

PS

私たちのブログもお読みください:

• «Kubernetes ストレージのボリューム プラグイン: Flexvolume から CSI まで";
• «私たちはコンテナ ストレージ インターフェイス (Kubernetes だけでなく) を理解しています。";
• «Kubernetes クラスターを準備するのは簡単で便利ですか? アドオンオペレーターの発表";
• «Kubernetes の拡張と補足 (概要とビデオ レポート)'。

出所： habr.com