Рүүк үү, үгүй ​​юу - энэ бол асуулт юм

Энэ сарын эхээр 3-р сарын XNUMX-нд "Кубернетес дэх тархсан өгөгдөл хадгалах удирдлагын систем"-ийн томоохон хувилбарыг зарлав. Rook 1.0.0. Жил гаруйн өмнө бид аль хэдийн хэвлэгдсэн Rook-ийн ерөнхий тойм. Дараа нь бид түүний туршлагын талаар ярилцахыг хүссэн практикт ашиглах - Одоо, төслийн түүхэнд ийм чухал үйл явдал тохиож байгаа энэ үед бид хуримтлагдсан сэтгэгдлээ хуваалцахдаа баяртай байна.

Товчхондоо, Rook бол багц юм операторууд Ceph, EdgeFS, Minio, Cassandra, CockroachDB зэрэг өгөгдөл хадгалах шийдлүүдийг байршуулах, удирдах, автоматаар сэргээхэд бүрэн хяналт тавьдаг Kubernetes-д зориулагдсан.

Одоогийн байдлаар хамгийн хөгжсөн (ба цор ганц в тогтвортой үе шат) шийдэл байна rook-ceph-operator.

тайлбар: Ceph-тэй холбоотой Rook 1.0.0 хувилбарт гарсан томоохон өөрчлөлтүүдийн дунд бид Ceph Nautilus-ийн дэмжлэг болон CephFS эсвэл RGW хувинуудад NFS ашиглах чадварыг тэмдэглэж болно. Бусад хүмүүсийн дундаас ялгарах зүйл бол EdgeFS-ийн дэмжлэгийг бета түвшинд хүргэсэн явдал юм.

Тиймээс, энэ нийтлэлд бид:

• Kubernetes кластерт Ceph-г байрлуулахын тулд Rook-ийг ашиглах нь ямар давуу талтай вэ гэсэн асуултад хариулъя;
• Бид үйлдвэрлэлд Rook ашиглах туршлага, сэтгэгдлээ хуваалцах болно;
• Бид яагаад Рүкэд “Тийм!” гэж хэлснээ болон түүний талаар хийх төлөвлөгөөнийхөө талаар хэлье.

Ерөнхий ойлголт, онолоос эхэлье.

"Надад нэг Rook давуу тал бий!" (үл мэдэгдэх шатарчин)

Rook-ийн гол давуу талуудын нэг нь мэдээллийн дэлгүүрүүдтэй харилцах нь Kubernetes механизмаар явагддаг явдал юм. Энэ нь та хуудаснаас Ceph-ийг консол руу тохируулах командуудыг хуулах шаардлагагүй гэсэн үг юм.

— Та CephFS-ийг кластерт байрлуулахыг хүсч байна уу? Зүгээр л YAML файл бичээрэй!
- Юу? Та мөн S3 API-тай объектын дэлгүүрийг байршуулахыг хүсч байна уу? Зүгээр л хоёр дахь YAML файл бичээрэй!

Rook нь ердийн операторын бүх дүрмийн дагуу бүтээгдсэн. Түүнтэй харилцах нь ашиглан үүсдэг CRD (Захиалгат нөөцийн тодорхойлолт), үүнд бид хэрэгтэй Цеф аж ахуйн нэгжүүдийн шинж чанарыг дүрсэлсэн (энэ нь цорын ганц тогтвортой хэрэгжилт тул өөрөөр заагаагүй бол энэ нийтлэлд анхдагчаар 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 файлаар дамжуулан нөөцийг "захиалах" явдал бөгөөд үүний тулд оператор шаардлагатай тушаалуудыг гүйцэтгэж, цаашдын ажиллах боломжтой "тийм ч бодит бус" нууцыг бидэнд буцааж өгдөг. (доороос үзнэ үү). Мөн дээр дурдсан хувьсагчдаас команд болон нууц нэр эмхэтгэгдэх болно.

Энэ ямар баг вэ? Объект хадгалах хэрэглэгчийг үүсгэх үед pod доторх 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 }}.

Энэ нууцын өгөгдлийг ашиглахын тулд үүнийг контейнерт орчны хувьсагч болгон нэмнэ үү. Жишээ болгон би ажлын загвар өгөх бөгөөд үүнд бид хэрэглэгчийн орчин бүрд автоматаар хувин үүсгэдэг:

{{- 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 }}

Энэ ажилд жагсаасан бүх үйлдлүүд Кубернетесийн хүрээнд хийгдсэн. YAML файлд дүрслэгдсэн бүтэц нь Git репозиторид хадгалагдаж, олон удаа дахин ашиглагддаг. Үүнийг бид DevOps-ийн инженерүүд болон CI/CD процессын хувьд маш том давуу тал гэж харж байна.

Рүк, Радос хоёрт баяртай байна

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-ийн бүслэлт

Бид өөрсдийн туршилтаа явуулахын тулд Рүк, Цеф хоёрыг байрлуулснаар практик хэсгийг гүйцээцгээе. Энэхүү үл тэвчих цамхаг руу дайрахад хялбар болгохын тулд хөгжүүлэгчид 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

Өгөгдөл хадгалахад зориулагдсан зангилаа бүрийн хувьд харгалзах бохирдлыг нэмнэ:

$ 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"

Цефийн статусыг шалгаж байна - харахыг хүлээж байна 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's and Hooks: Рук бүх зүйлд хангалттай юу?

Таны харж байгаагаар Rook-ийн хөгжил эрчимтэй явагдаж байна. Гэхдээ Ceph-ийн гарын авлагын тохиргооноос бүрэн татгалзах боломжийг бидэнд олгодоггүй асуудлууд байсаар байна.

• Rook Driver байхгүй чадахгүй суурилуулсан блокуудыг ашиглах хэмжүүрүүдийг экспортлох нь биднийг хяналт тавихаас татгалздаг.
• Flexvolume ба CSI яаж мэдэхгүй байна эзлэхүүний хэмжээг өөрчлөх (ижил RBD-ээс ялгаатай), тиймээс Rook нь ашигтай (заримдаа маш их хэрэгтэй!) хэрэглүүрээс хасагдана.
• Rook энгийн Ceph шиг уян хатан биш хэвээр байна. Хэрэв бид CephFS мета өгөгдлийн санг SSD дээр, мөн өгөгдлийг өөрөө HDD дээр хадгалахаар тохируулахыг хүсвэл CRUSH газрын зурагт тусдаа бүлгүүдийг гараар бүртгэх шаардлагатай болно.
• Хэдийгээр rook-ceph-operator нь тогтвортой гэж тооцогддог ч Ceph-ийг 13-аас 14-р хувилбар руу шинэчлэхэд одоогоор зарим асуудал гарч байна.

үр дүн нь

"Яг одоо Рук гадаад ертөнцөөс гар хөлөөр хаагдсан ч хэзээ нэгэн цагт тэр тоглоомонд шийдвэрлэх үүрэг гүйцэтгэнэ гэдэгт бид итгэж байна!" (энэ нийтлэлд зориулж тусгайлан бүтээсэн ишлэл)

Rook төсөл нь бидний зүрх сэтгэлийг байлдан дагуулсан нь эргэлзээгүй - [бүх давуу болон сул талуудтай] энэ нь таны анхаарлыг татах ёстой гэдэгт бид итгэдэг.

Бидний ирээдүйн төлөвлөгөө нь rook-ceph-ийг модуль болгоход чиглэгддэг addon-operator, энэ нь манай олон тооны Kubernetes кластерт ашиглахыг илүү хялбар, илүү хялбар болгоно.

PS

Мөн манай блог дээрээс уншина уу:

• «Rook - Kubernetes-д зориулсан "өөртөө үйлчлэх" мэдээллийн агуулах";
• «Ceph дээр суурилсан Kubernetes-д нөөцийн тусламжтайгаар байнгын хадгалах санг бий болгож байна";
• «Өгөгдлийн сан ба Кубернетес (хяналт, видео тайлан)";
• «Бүрхүүлийн операторыг танилцуулж байна: Kubernetes-д оператор үүсгэх нь илүү хялбар болсон";
• «Kubernetes-д зориулсан операторууд: төлөвтэй програмуудыг хэрхэн ажиллуулах вэ".

Эх сурвалж: www.habr.com