Rook이냐 아니냐-그것이 문제로다

이달 초인 3월 XNUMX일 '쿠버네티스의 분산 데이터 저장을 위한 관리 시스템'의 주요 릴리스가 발표되었습니다. 루크 1.0.0. XNUMX년여 전에 우리는 이미 출판 Rook의 일반적인 개요. 그런 다음 우리는 그의 경험에 대해 이야기해 달라는 요청을 받았습니다. 실제로 사용 — 그리고 이제 프로젝트 역사상 중요한 이정표가 되는 시점에 우리는 축적된 인상을 공유하게 되어 기쁘게 생각합니다.

간단히 말해서 Rook은 세트입니다. 연산자 Ceph, EdgeFS, Minio, Cassandra, CockroachDB와 같은 데이터 스토리지 솔루션의 배포, 관리, 자동 복구를 완전히 제어하는 ​​Kubernetes용입니다.

현재 가장 발전된 (그리고 유일한 в 안정된 단계) 해결책은 루크 세프 운영자.

주의: Ceph와 관련된 Rook 1.0.0 릴리스의 중요한 변경 사항 중 Ceph Nautilus에 대한 지원과 CephFS 또는 RGW 버킷에 NFS를 사용하는 기능을 주목할 수 있습니다. 무엇보다도 눈에 띄는 점은 EdgeFS 지원이 베타 수준으로 성숙되었다는 점입니다.

따라서 이 기사에서는 다음을 수행합니다.

• Rook을 사용하여 Kubernetes 클러스터에 Ceph를 배포할 때 어떤 이점이 있는지에 대한 질문에 답해 보겠습니다.
• 프로덕션에서 Rook을 사용한 경험과 인상을 공유하겠습니다.
• 우리가 Rook에게 “예!”라고 말하는 이유와 그를 위한 우리의 계획에 대해 이야기해 봅시다.

일반적인 개념과 이론부터 시작하겠습니다.

“나에겐 한 루크의 장점이 있어요!” (알 수 없는 체스 플레이어)

Rook의 주요 장점 중 하나는 데이터 저장소와의 상호 작용이 Kubernetes 메커니즘을 통해 수행된다는 것입니다. 이는 더 이상 Ceph를 구성하기 위해 시트에서 콘솔로 명령을 복사할 필요가 없음을 의미합니다.

— CephFS를 클러스터에 배포하시겠습니까? YAML 파일을 작성하면 됩니다!
- 무엇? S3 API를 사용하여 객체 저장소도 배포하시겠습니까? 두 번째 YAML 파일을 작성하면 됩니다!

Rook은 일반적인 연산자의 모든 규칙에 따라 생성됩니다. 그와의 상호 작용은 다음을 사용하여 발생합니다. CRD(사용자 정의 리소스 정의), 필요한 Ceph 엔터티의 특성을 설명합니다. (이것은 유일하게 안정적인 구현이므로 달리 명시적으로 언급하지 않는 한 기본적으로 이 기사에서는 Ceph에 대해 설명합니다.). 지정된 매개변수에 따라 운영자는 구성에 필요한 명령을 자동으로 실행합니다.

객체 저장소를 생성하는 예를 사용하여 세부 사항을 살펴보겠습니다. CephObjectStoreUser.

apiVersion: ceph.rook.io/v1
kind: CephObjectStore
metadata:
  name: {{ .Values.s3.crdName }}
  namespace: kube-rook
spec:
  metadataPool:
    failureDomain: host
    replicated:
      size: 3
  dataPool:
    failureDomain: host
    erasureCoded:
      dataChunks: 2
      codingChunks: 1
  gateway:
    type: s3
    sslCertificateRef:
    port: 80
    securePort:
    instances: 1
    allNodes: false
---
apiVersion: ceph.rook.io/v1
kind: CephObjectStoreUser
metadata:
  name: {{ .Values.s3.crdName }}
  namespace: kube-rook
spec:
  store: {{ .Values.s3.crdName }}
  displayName: {{ .Values.s3.username }}

목록에 표시된 매개변수는 매우 표준적이며 주석이 거의 필요하지 않지만 템플릿 변수에 할당된 매개변수에는 특별한 주의를 기울일 가치가 있습니다.

일반적인 작업 계획은 YAML 파일을 통해 리소스를 "주문"한다는 사실로 귀결됩니다. 이를 위해 운영자는 필요한 명령을 실행하고 추가 작업을 할 수 있는 "그렇지 않은" 비밀을 반환합니다. (아래 참조). 그리고 위에 나열된 변수에서 명령과 비밀 이름이 컴파일됩니다.

이 팀은 어떤 팀인가요? 객체 스토리지용 사용자를 생성할 때 포드 내부의 Rook 운영자는 다음을 수행합니다.

radosgw-admin user create --uid="rook-user" --display-name="{{ .Values.s3.username }}"

이 명령을 실행한 결과는 JSON 구조입니다.

{
    "user_id": "rook-user",
    "display_name": "{{ .Values.s3.username }}",
    "keys": [
        {
           "user": "rook-user",
           "access_key": "NRWGT19TWMYOB1YDBV1Y",
           "secret_key": "gr1VEGIV7rxcP3xvXDFCo4UDwwl2YoNrmtRlIAty"
        }
    ],
    ...
}

Keys - S3 API를 통해 객체 스토리지에 액세스하려면 향후 애플리케이션에 필요한 것이 무엇입니까? Rook 운영자는 친절하게 이를 선택하여 이름이 있는 비밀 형식으로 네임스페이스에 넣습니다. rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

이 비밀의 데이터를 사용하려면 환경 변수로 컨테이너에 추가하기만 하면 됩니다. 예를 들어, 각 사용자 환경에 대한 버킷을 자동으로 생성하는 Job용 템플릿을 제공하겠습니다.

{{- range $bucket := $.Values.s3.bucketNames }}
apiVersion: batch/v1
kind: Job
metadata:
  name: create-{{ $bucket }}-bucket-job
  annotations:
    "helm.sh/hook": post-install
    "helm.sh/hook-weight": "2"
spec:
  template:
    metadata:
      name: create-{{ $bucket }}-bucket-job
    spec:
      restartPolicy: Never
      initContainers:
      - name: waitdns
        image: alpine:3.6
        command: ["/bin/sh", "-c", "while ! getent ahostsv4 rook-ceph-rgw-{{ $.Values.s3.crdName }}; do sleep 1; done" ]
      - name: config
        image: rook/ceph:v1.0.0
        command: ["/bin/sh", "-c"]
        args: ["s3cmd --configure --access_key=$(ACCESS-KEY) --secret_key=$(SECRET-KEY) -s --no-ssl --dump-config | tee /config/.s3cfg"]
        volumeMounts:
        - name: config
          mountPath: /config
        env:
        - name: ACCESS-KEY
          valueFrom:
            secretKeyRef:
              name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}
              key: AccessKey
        - name: SECRET-KEY
          valueFrom:
            secretKeyRef:
              name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}
              key: SecretKey
      containers:
      - name: create-bucket
        image: rook/ceph:v1.0.0
        command: 
        - "s3cmd"
        - "mb"
        - "--host=rook-ceph-rgw-{{ $.Values.s3.crdName }}"
        - "--host-bucket= "
        - "s3://{{ $bucket }}"
        ports:
        - name: s3-no-sll
          containerPort: 80
        volumeMounts:
        - name: config
          mountPath: /root
      volumes:
      - name: config
        emptyDir: {}
---
{{- end }}

이 작업에 나열된 모든 작업은 Kubernetes 프레임워크 내에서 수행되었습니다. YAML 파일에 설명된 구조는 Git 저장소에 저장되며 여러 번 재사용됩니다. 우리는 이것이 DevOps 엔지니어와 CI/CD 프로세스 전체에 큰 장점이라고 생각합니다.

Rook과 Rados에 만족함

Ceph + RBD 조합을 사용하면 포드에 볼륨을 마운트하는 데 특정 제한이 적용됩니다.

특히, 상태 저장 애플리케이션이 작동하려면 네임스페이스에 Ceph에 액세스하기 위한 비밀이 포함되어야 합니다. 네임스페이스에 2~3개의 환경이 있어도 괜찮습니다. 가서 비밀을 수동으로 복사할 수 있습니다. 하지만 각 기능에 대해 자체 네임스페이스가 있는 별도의 환경이 개발자를 위해 생성된다면 어떻게 될까요?

우리는 다음을 사용하여 이 문제를 스스로 해결했습니다. 쉘 연산자, 비밀을 새 네임스페이스에 자동으로 복사합니다(이러한 후크의 예는 이 기사).

#! /bin/bash

if [[ $1 == “--config” ]]; then
   cat <<EOF
{"onKubernetesEvent":[
 {"name": "OnNewNamespace",
  "kind": "namespace",
  "event": ["add"]
  }
]}
EOF
else
    NAMESPACE=$(kubectl get namespace -o json | jq '.items | max_by( .metadata.creationTimestamp ) | .metadata.name')
    kubectl -n ${CEPH_SECRET_NAMESPACE} get secret ${CEPH_SECRET_NAME} -o json | jq ".metadata.namespace="${NAMESPACE}"" | kubectl apply -f -
fi

그러나 Rook을 사용하면 이 문제가 전혀 발생하지 않습니다. 장착 프로세스는 다음을 기반으로 하는 자체 드라이버를 사용하여 수행됩니다. 플렉스볼륨 또는 CSI (아직 베타 단계임) 따라서 비밀이 필요하지 않습니다.

Rook은 많은 문제를 자동으로 해결하므로 새로운 프로젝트에서 이를 사용하도록 권장됩니다.

루크 공성전

자체적으로 실험을 수행할 수 있도록 Rook 및 Ceph를 배포하여 실습을 완료해 보겠습니다. 이 난공불락의 타워를 더 쉽게 습격할 수 있도록 개발자는 Helm 패키지를 준비했습니다. 다운로드하자:

$ helm fetch rook-master/rook-ceph --untar --version 1.0.0

파일에서 rook-ceph/values.yaml 다양한 설정을 찾을 수 있습니다. 가장 중요한 것은 에이전트와 검색에 대한 허용 범위를 지정하는 것입니다. 우리는 오염/관용 메커니즘이 어떤 용도로 사용될 수 있는지 자세히 설명했습니다. 이 기사.

간단히 말해서, 우리는 클라이언트 애플리케이션 포드가 데이터 스토리지 디스크와 동일한 노드에 위치하는 것을 원하지 않습니다. 이유는 간단합니다. 이렇게 하면 Rook 에이전트의 작업이 애플리케이션 자체에 영향을 미치지 않습니다.

그럼 파일을 열어보세요 rook-ceph/values.yaml 좋아하는 편집기를 사용하여 끝에 다음 블록을 추가하십시오.

discover:
  toleration: NoExecute
  tolerationKey: node-role/storage
agent:
  toleration: NoExecute
  tolerationKey: node-role/storage
  mountSecurityMode: Any

데이터 저장용으로 예약된 각 노드에 대해 해당 taint를 추가합니다.

$ kubectl taint node ${NODE_NAME} node-role/storage="":NoExecute

그런 다음 다음 명령을 사용하여 Helm 차트를 설치합니다.

$ helm install --namespace ${ROOK_NAMESPACE} ./rook-ceph

이제 클러스터를 생성하고 위치를 지정해야 합니다. OSD:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  clusterName: "ceph"
  finalizers:
  - cephcluster.ceph.rook.io
  generation: 1
  name: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v13
  dashboard:
    enabled: true
  dataDirHostPath: /var/lib/rook/osd
  mon:
    allowMultiplePerNode: false
    count: 3
  network:
    hostNetwork: true
  rbdMirroring:
    workers: 1
  placement:
    all:
      tolerations:
      - key: node-role/storage
        operator: Exists
  storage:
    useAllNodes: false
    useAllDevices: false
    config:
      osdsPerDevice: "1"
      storeType: filestore
    resources:
      limits:
        memory: "1024Mi"
      requests:
        memory: "1024Mi"
    nodes:
    - name: host-1
      directories:
      - path: "/mnt/osd"
    - name: host-2
      directories:
      - path: "/mnt/osd"
    - name: host-3
      directories:
      - path: "/mnt/osd"

Ceph 상태 확인 중 - 확인 가능 HEALTH_OK:

$ kubectl -n ${ROOK_NAMESPACE} exec $(kubectl -n ${ROOK_NAMESPACE} get pod -l app=rook-ceph-operator -o name -o jsonpath='{.items[0].metadata.name}') -- ceph -s

동시에 클라이언트 애플리케이션이 있는 포드가 Ceph용으로 예약된 노드에 있지 않은지 확인해 보겠습니다.

$ kubectl -n ${APPLICATION_NAMESPACE} get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName

또한 원하는 대로 추가 구성 요소를 구성할 수 있습니다. 이에 대한 자세한 내용은 선적 서류 비치. 관리를 위해서는 대시보드와 도구 상자를 설치하는 것이 좋습니다.

루크와 후크: 루크는 모든 것에 충분합니까?

보시다시피 Rook의 개발이 본격화되고 있습니다. 그러나 Ceph의 수동 구성을 완전히 포기할 수 없는 문제가 여전히 있습니다.

• 루크 드라이버 없음 할 수 없다 마운트된 블록 사용에 대한 측정항목을 내보내면 모니터링이 불가능해집니다.
• Flexvolume 및 CSI 방법을 모르겠어 (동일한 RBD와 반대로) 볼륨 크기를 변경하므로 Rook에는 유용한(때로는 매우 필요한) 도구가 없습니다.
• Rook은 여전히 ​​일반 Ceph만큼 유연하지 않습니다. CephFS 메타데이터용 풀을 SSD에 저장하고 데이터 자체를 HDD에 저장하도록 구성하려면 CRUSH 맵에 별도의 장치 그룹을 수동으로 등록해야 합니다.
• rook-ceph-operator가 안정적인 것으로 간주된다는 사실에도 불구하고 현재 Ceph를 버전 13에서 14로 업그레이드할 때 몇 가지 문제가 있습니다.

조사 결과

"지금은 Rook이 폰에 의해 외부 세계와 차단되어 있지만 언젠가는 Rook이 게임에서 결정적인 역할을 하게 될 것이라고 믿습니다!" (이 기사를 위해 특별히 고안된 인용문)

Rook 프로젝트는 의심할 여지없이 우리의 마음을 사로잡았습니다. 우리는 [모든 장단점에도 불구하고] 확실히 여러분의 관심을 받을 가치가 있다고 믿습니다.

우리의 향후 계획은 rook-ceph를 다음 모듈로 만드는 것입니다. 애드온 연산자, 이를 통해 수많은 Kubernetes 클러스터에서 더욱 간단하고 편리하게 사용할 수 있습니다.

PS

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

• «Rook - Kubernetes용 "셀프 서비스" 데이터 웨어하우스";
• «Ceph 기반 Kubernetes에서 프로비저닝을 통해 영구 스토리지 생성";
• «데이터베이스 및 Kubernetes(개요 및 동영상 보고서)";
• «Shell-Operator 소개: Kubernetes용 연산자 생성이 더욱 쉬워졌습니다.";
• «Kubernetes용 연산자: 상태 저장 애플리케이션을 실행하는 방법".

출처 : habr.com