Kubernetes 스토리지용 볼륨 플러그인: Flexvolume에서 CSI까지

Kubernetes가 v1.0.0이었을 때 볼륨 플러그인이 있었습니다. 영구(영구) 컨테이너 데이터를 저장하기 위해 시스템을 Kubernetes에 연결하는 데 필요했습니다. 그 수는 적었고 첫 번째로는 GCE PD, Ceph, AWS EBS 등과 같은 스토리지 제공업체가 있었습니다.

플러그인은 Kubernetes와 함께 제공되었으므로 이름이 in-tree인 이유입니다. 그러나 많은 경우 이러한 플러그인의 기존 세트로는 충분하지 않은 것으로 나타났습니다. 장인들은 패치를 사용하여 Kubernetes 코어에 간단한 플러그인을 추가한 후 자체 Kubernetes를 조립하고 서버에 설치했습니다. 그러나 시간이 지나면서 Kubernetes 개발자들은 다음과 같은 사실을 깨달았습니다. 물고기 문제는 해결될 수 없습니다. 사람들은 필요 낚싯대. 그리고 Kubernetes v1.2.0 릴리스에서 나타났습니다...

Flexvolume 플러그인: 최소 낚싯대

Kubernetes 개발자는 타사 개발자가 구현한 Flexvolume 드라이버를 사용하기 위한 변수 및 방법의 논리적 프레임워크인 FlexVolume 플러그인을 만들었습니다.

잠시 멈추고 FlexVolume 드라이버가 무엇인지 자세히 살펴보겠습니다. 이는 특정 실행 가능 파일 (바이너리 파일, Python 스크립트, Bash 스크립트 등), 실행 시 명령줄 인수를 입력으로 사용하고 JSON 형식의 미리 알려진 필드가 포함된 메시지를 반환합니다. 관례적으로 첫 번째 명령줄 인수는 항상 메서드이고 나머지 인수는 해당 매개 변수입니다.

OpenShift의 CIFS 공유에 대한 연결 다이어그램. Flexvolume 드라이버 - 중앙에 위치

최소 메소드 세트 그것은 다음과 같습니다 :

flexvolume_driver mount # отвечает за присоединение тома к pod'у
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
}

flexvolume_driver unmount # отвечает за отсоединение тома от pod'а
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
}

flexvolume_driver init # отвечает за инициализацию плагина
# Формат возвращаемого сообщения:
{
  "status": "Success"/"Failure"/"Not supported",
  "message": "По какой причине был возвращен именно такой статус",
  // Определяет, использует ли драйвер методы attach/deatach
  "capabilities":{"attach": True/False}
}

메소드 사용 attach и detach 드라이버를 호출할 때 kubelet이 향후 작동할 시나리오를 정의합니다. 특별한 방법도 있어요 expandvolume и expandfs, 볼륨의 크기를 동적으로 조정하는 역할을 합니다.

메소드가 추가하는 변경사항의 예 expandvolume, 실시간으로 볼륨 크기를 조정하는 기능을 통해 다음 사항에 익숙해질 수 있습니다. 우리의 풀 리퀘스트 Rook Ceph Operator에서.

다음은 NFS 작업을 위한 Flexvolume 드라이버 구현의 예입니다.

usage() {
    err "Invalid usage. Usage: "
    err "t$0 init"
    err "t$0 mount <mount dir> <json params>"
    err "t$0 unmount <mount dir>"
    exit 1
}

err() {
    echo -ne $* 1>&2
}

log() {
    echo -ne $* >&1
}

ismounted() {
    MOUNT=`findmnt -n ${MNTPATH} 2>/dev/null | cut -d' ' -f1`
    if [ "${MOUNT}" == "${MNTPATH}" ]; then
        echo "1"
    else
        echo "0"
    fi
}

domount() {
    MNTPATH=$1

    NFS_SERVER=$(echo $2 | jq -r '.server')
    SHARE=$(echo $2 | jq -r '.share')

    if [ $(ismounted) -eq 1 ] ; then
        log '{"status": "Success"}'
        exit 0
    fi

    mkdir -p ${MNTPATH} &> /dev/null

    mount -t nfs ${NFS_SERVER}:/${SHARE} ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Failure", "message": "Failed to mount ${NFS_SERVER}:${SHARE} at ${MNTPATH}"}"
        exit 1
    fi
    log '{"status": "Success"}'
    exit 0
}

unmount() {
    MNTPATH=$1
    if [ $(ismounted) -eq 0 ] ; then
        log '{"status": "Success"}'
        exit 0
    fi

    umount ${MNTPATH} &> /dev/null
    if [ $? -ne 0 ]; then
        err "{ "status": "Failed", "message": "Failed to unmount volume at ${MNTPATH}"}"
        exit 1
    fi

    log '{"status": "Success"}'
    exit 0
}

op=$1

if [ "$op" = "init" ]; then
    log '{"status": "Success", "capabilities": {"attach": false}}'
    exit 0
fi

if [ $# -lt 2 ]; then
    usage
fi

shift

case "$op" in
    mount)
        domount $*
        ;;
    unmount)
        unmount $*
        ;;
    *)
        log '{"status": "Not supported"}'
        exit 0
esac

exit 1

따라서 실제 실행 파일을 준비한 후에는 Kubernetes 클러스터에 드라이버 업로드. 드라이버는 미리 결정된 경로에 따라 각 클러스터 노드에 위치해야 합니다. 기본적으로 다음이 선택되었습니다.

/usr/libexec/kubernetes/kubelet-plugins/volume/exec/имя_поставщика_хранилища~имя_драйвера/

... 하지만 다른 Kubernetes 배포판(OpenShift, Rancher...)을 사용하는 경우 경로가 다를 수 있습니다.

Flexvolume 문제: 낚싯대를 올바르게 캐스팅하는 방법은 무엇입니까?

Flexvolume 드라이버를 클러스터 노드에 업로드하는 것은 간단한 작업이 아닌 것으로 나타났습니다. 작업을 수동으로 한 번 수행하면 새 노드 추가, 자동 수평 확장 또는 오작동으로 인한 노드 교체로 인해 클러스터에 새 노드가 나타나는 상황이 발생하기 쉽습니다. 이 경우 해당 노드의 스토리지 작업을 수행해야 합니다. 불가능한, Flexvolume 드라이버를 수동으로 추가할 때까지.

이 문제에 대한 해결책은 Kubernetes 기본 요소 중 하나였습니다. DaemonSet. 클러스터에 새 노드가 나타나면 Flexvolume 드라이버를 찾기 위한 경로를 따라 로컬 볼륨이 연결되는 DaemonSet의 포드가 자동으로 포함됩니다. 성공적으로 생성되면 포드는 드라이버가 디스크에 작동하는 데 필요한 파일을 복사합니다.

다음은 Flexvolume 플러그인을 배치하기 위한 DaemonSet의 예입니다.

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: flex-set
spec:
  template:
    metadata:
      name: flex-deploy
      labels:
        app: flex-deploy
    spec:
      containers:
        - image: <deployment_image>
          name: flex-deploy
          securityContext:
              privileged: true
          volumeMounts:
            - mountPath: /flexmnt
              name: flexvolume-mount
      volumes:
        - name: flexvolume-mount
          hostPath:
            path: <host_driver_directory>

... 그리고 Flexvolume 드라이버를 배치하기 위한 Bash 스크립트의 예:

#!/bin/sh

set -o errexit
set -o pipefail

VENDOR=k8s.io
DRIVER=nfs

driver_dir=$VENDOR${VENDOR:+"~"}${DRIVER}
if [ ! -d "/flexmnt/$driver_dir" ]; then
  mkdir "/flexmnt/$driver_dir"
fi

cp "/$DRIVER" "/flexmnt/$driver_dir/.$DRIVER"
mv -f "/flexmnt/$driver_dir/.$DRIVER" "/flexmnt/$driver_dir/$DRIVER"

while : ; do
  sleep 3600
done

복사 작업을 잊지 않는 것이 중요합니다. 원자적이지 않다. 프로비저닝 프로세스가 완료되기 전에 kubelet이 드라이버를 사용하기 시작하여 시스템 충돌을 일으킬 가능성이 높습니다. 올바른 접근 방식은 먼저 드라이버 파일을 다른 이름으로 복사한 다음 원자적 이름 바꾸기 작업을 사용하는 것입니다.

Rook 운영자의 Ceph 작업 다이어그램: 다이어그램의 Flexvolume 드라이버는 Rook 에이전트 내부에 있습니다.

Flexvolume 드라이버를 사용할 때의 다음 문제는 클러스터 노드의 대부분의 스토리지에 대한 것입니다. 이를 위해 필요한 소프트웨어를 설치해야 합니다 (예: Ceph용 ceph-common 패키지) 처음에는 Flexvolume 플러그인이 이러한 복잡한 시스템을 구현하도록 설계되지 않았습니다.

이 문제에 대한 원래의 해결책은 Rook 연산자의 Flexvolume 드라이버 구현에서 볼 수 있습니다.

드라이버 자체는 RPC 클라이언트로 설계되었습니다. 통신을 위한 IPC 소켓은 드라이버 자체와 동일한 디렉터리에 있습니다. 드라이버 파일을 복사하려면 디렉터리를 드라이버와 볼륨으로 연결하는 DaemonSet을 사용하는 것이 좋을 것이라는 점을 기억합니다. 필요한 루크 드라이버 파일을 복사한 후 이 포드는 죽지 않고 본격적인 RPC 서버로서 연결된 볼륨을 통해 IPC 소켓에 연결됩니다. ceph-common 패키지는 이미 포드 컨테이너 내부에 설치되어 있습니다. IPC 소켓은 kubelet이 동일한 노드에 있는 Pod와 정확하게 통신하도록 보장합니다. 독창적인 모든 것은 간단합니다!..

안녕, 우리의 다정한... 트리 내 플러그인들!

Kubernetes 개발자는 코어 내 스토리지용 플러그인 수가 XNUMX개라는 사실을 발견했습니다. 그리고 각각의 변경 사항은 어떤 식으로든 전체 Kubernetes 릴리스 주기를 거칩니다.

새로운 버전의 저장소 플러그인을 사용하려면, 전체 클러스터를 업데이트해야 합니다. 이에 더해, 새 버전의 Kubernetes가 갑자기 사용 중인 Linux 커널과 호환되지 않게 된다는 사실에 놀라실 수도 있습니다... 따라서 눈물을 닦고 이를 악물고 경영진 및 사용자와 협의하여 다음 작업을 수행해야 합니다. Linux 커널 및 Kubernetes 클러스터를 업데이트합니다. 서비스 제공 시 가동 중지 시간이 발생할 수 있습니다.

상황이 우스꽝스럽다고 생각하지 않나요? 이 접근 방식이 효과가 없다는 것이 전체 커뮤니티에 분명해졌습니다. 의도적인 결정에 따라 Kubernetes 개발자는 스토리지 작업을 위한 새로운 플러그인이 더 이상 커널에 허용되지 않을 것이라고 발표했습니다. 또한 이미 알고 있듯이 Flexvolume 플러그인 구현에서 여러 가지 단점이 확인되었습니다...

Kubernetes의 볼륨용으로 최근 추가된 플러그인인 CSI는 영구 데이터 스토리지 문제를 완전히 해결하기 위해 요청되었습니다. Out-of-Tree CSI Volume Plugins라고 더 자세히 알려진 알파 버전이 릴리스에서 발표되었습니다. 쿠버네티스 1.9.

컨테이너 스토리지 인터페이스 또는 CSI 3000 스피닝 로드!

우선, CSI는 단순한 볼륨 플러그인이 아니라 실제 플러그인이라는 점에 주목하고 싶습니다. 표준 데이터 웨어하우스 작업을 위한 사용자 정의 구성 요소 생성에 대해. Kubernetes 및 Mesos와 같은 컨테이너 오케스트레이션 시스템은 이 표준에 따라 구현된 구성 요소로 작업하는 방법을 "학습"해야 했습니다. 그리고 이제 저는 이미 Kubernetes를 배웠습니다.

Kubernetes의 CSI 플러그인 구조는 무엇입니까? CSI 플러그인은 특수 드라이버(CSI 드라이버) 타사 개발자가 작성했습니다. Kubernetes의 CSI 드라이버는 최소한 두 가지 구성 요소(포드)로 구성되어야 합니다.

• 제어 장치 — 외부 영구 저장소를 관리합니다. 프리미티브를 사용하는 gRPC 서버로 구현됩니다. StatefulSet.
• 노드 — 영구 스토리지를 클러스터 노드에 마운트하는 역할을 담당합니다. gRPC 서버로도 구현되지만 이를 위해 프리미티브가 사용됩니다. DaemonSet.

Kubernetes에서 CSI 플러그인이 작동하는 방식

예를 들어 다음 기사에서 CSI 작업의 다른 세부 사항에 대해 알아볼 수 있습니다.C.S.I에 대한 이해" 어느 것의 번역 우리는 XNUMX년 전에 출판했습니다.

이러한 구현의 장점

• 노드 드라이버 등록과 같은 기본적인 작업을 위해 Kubernetes 개발자는 컨테이너 세트를 구현했습니다. Flexvolume 플러그인에서처럼 더 이상 기능이 포함된 JSON 응답을 직접 생성할 필요가 없습니다.
• 실행 파일을 노드에 "슬립"하는 대신 이제 클러스터에 포드를 업로드합니다. 이것이 우리가 처음에 Kubernetes에서 기대하는 것입니다. 모든 프로세스는 Kubernetes 프리미티브를 사용하여 배포된 컨테이너 내에서 발생합니다.
• 복잡한 드라이버를 구현하기 위해 더 이상 RPC 서버와 RPC 클라이언트를 개발할 필요가 없습니다. 클라이언트는 Kubernetes 개발자가 우리를 위해 구현했습니다.
• gRPC 프로토콜을 통해 작업할 인수를 전달하는 것은 명령줄 인수를 통해 전달하는 것보다 훨씬 편리하고 유연하며 안정적입니다. 표준화된 gRPC 방법을 추가하여 CSI에 볼륨 사용량 측정항목에 대한 지원을 추가하는 방법을 이해하려면 다음을 읽어보세요. 우리의 풀 리퀘스트 vsphere-csi 드라이버용.
• 통신은 IPC 소켓을 통해 이루어지므로 kubelet이 올바른 Pod에 요청을 보냈는지 혼동하지 않습니다.

이 목록에 생각나는 것이 있나요? CSI의 장점은 같은 문제를 해결하다, 이는 Flexvolume 플러그인을 개발할 때 고려되지 않았습니다.

조사 결과

데이터 웨어하우스와 상호 작용하기 위한 사용자 정의 플러그인을 구현하기 위한 표준인 CSI는 커뮤니티에서 매우 호평을 받았습니다. 또한 장점과 다양성으로 인해 Ceph 또는 AWS EBS와 같은 스토리지 시스템용 CSI 드라이버도 생성되며, Kubernetes의 첫 번째 버전에 추가된 작업용 플러그인입니다.

2019년 초, 트리 내 플러그인 더 이상 사용되지 않는 것으로 선언되었습니다.. 우리는 Flexvolume 플러그인을 계속 지원할 계획이지만 이에 대한 새로운 기능을 개발하지는 않을 것입니다.

우리는 이미 ceph-csi, vsphere-csi를 사용한 경험이 있으며 이 목록에 추가할 준비가 되어 있습니다! 지금까지 CSI는 할당된 작업을 성공적으로 처리하고 있지만 기다려 보겠습니다.

새로운 것은 모두 잘 생각한 오래된 것임을 잊지 마십시오!

PS

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

• «우리는 컨테이너 스토리지 인터페이스를 이해합니다(Kubernetes뿐만 아니라)";
• «Rook이냐 아니냐-그것이 문제로다";
• «Kubernetes의 볼륨 스냅샷 알파 버전 소개".

출처 : habr.com