Yandex.Cloud용 Kubernetes에서 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분 이상 연장되어 해당 포드를 사용할 수 없게 될 수 있습니다.

잠재적인 가동 중지 시간을 아주 쉽고 고통 없이 줄일 수 있는 유일한 옵션은 최대 시간 초과 제한이 있는 외부 크기 조정기 버전을 사용하는 것이었습니다. 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을 전달해야 합니다. 승인된 키 서비스 계정에서. 문서에서 설명, 서비스 계정을 만들고 키를 얻는 방법.

전체적으로- 시도하다, 우리는 피드백을 받고 기뻐할 것입니다. 새로운 문제문제가 발생하면!

추가 지원

결과적으로 우리는 Go에서 애플리케이션을 작성하는 재미를 느끼고 싶어서가 아니라 회사 내 긴급한 필요 때문에 이 CSI 드라이버를 구현했다는 점을 지적하고 싶습니다. 자체 구현을 유지하는 것은 실용적이지 않은 것 같으므로 Yandex가 관심을 보이고 드라이버를 계속 지원하기로 결정하면 저장소를 기꺼이 그들에게 이전할 것입니다.

또한 Yandex는 아마도 관리형 Kubernetes 클러스터에 오픈 소스로 출시될 수 있는 CSI 드라이버의 자체 구현을 가지고 있을 것입니다. 우리는 또한 이 개발 옵션이 유리하다고 생각합니다. 커뮤니티는 제XNUMX자 회사가 아닌 서비스 제공업체의 입증된 드라이버를 사용할 수 있을 것입니다.

PS

블로그에서도 읽어보세요.

• «Kubernetes 스토리지용 볼륨 플러그인: Flexvolume에서 CSI까지";
• «우리는 컨테이너 스토리지 인터페이스를 이해합니다(Kubernetes뿐만 아니라)";
• «Kubernetes 클러스터를 준비하는 것이 쉽고 편리합니까? 애드온 운영자 발표";
• «Kubernetes 확장 및 보완(개요 및 동영상 보고서)".

출처 : habr.com