Rookmi yoki yo'qmi - bu savol

Shu oyning boshida, 3-may kuni, "Kubernetes-da taqsimlangan ma'lumotlarni saqlashni boshqarish tizimi" ning asosiy versiyasi e'lon qilindi - Rook 1.0.0. Bir yildan ko'proq vaqt oldin biz allaqachon nashr etilgan Rook haqida umumiy ma'lumot. Keyin bizdan uning tajribasi haqida gapirishni so'rashdi amaliyotda foydalanish — va hozir, loyiha tarixidagi shunday muhim bosqichga to‘g‘ri kelganda, biz to‘plangan taassurotlarimiz bilan o‘rtoqlashishdan xursandmiz.

Qisqasi, Rook - bu to'plam operatorlar Ceph, EdgeFS, Minio, Cassandra, CockroachDB kabi ma'lumotlarni saqlash echimlarini joylashtirish, boshqarish va avtomatik tiklashni to'liq nazorat qiladigan Kubernetes uchun.

Ayni paytda eng rivojlangan (va yagona в barqaror bosqich) yechim hisoblanadi rook-ceph-operator.

nota: Ceph bilan bog'liq Rook 1.0.0 versiyasidagi muhim o'zgarishlar orasida Ceph Nautilus-ni qo'llab-quvvatlash va CephFS yoki RGW chelaklari uchun NFS-dan foydalanish qobiliyatini qayd etishimiz mumkin. Boshqalar orasida ajralib turadigan narsa - EdgeFS qo'llab-quvvatlashining beta-darajaga etukligi.

Shunday qilib, ushbu maqolada biz:

• Keling, Kubernetes klasterida Cephni joylashtirish uchun Rook-dan foydalanishning qanday afzalliklarini ko'rishimiz haqidagi savolga javob beraylik;
• Biz ishlab chiqarishda Rookdan foydalanish tajribamiz va taassurotlarimizni baham ko'ramiz;
• Keling, nima uchun Rukka “Ha!” deyishimiz va u uchun rejalarimiz haqida gapiraylik.

Keling, umumiy tushunchalar va nazariyadan boshlaylik.

"Menda bitta Rookning afzalligi bor!" (noma'lum shaxmatchi)

Rookning asosiy afzalliklaridan biri shundaki, ma'lumotlar do'konlari bilan o'zaro aloqa Kubernetes mexanizmlari orqali amalga oshiriladi. Bu shuni anglatadiki, endi Cephni varaqdan konsolga sozlash uchun buyruqlarni nusxalash kerak emas.

— Siz CephFS-ni klasterda joylashtirmoqchimisiz? Faqat YAML faylini yozing!
- Nima? S3 API bilan ob'ektlar do'konini joylashtirmoqchimisiz? Faqat ikkinchi YAML faylini yozing!

Rook tipik operatorning barcha qoidalariga muvofiq yaratilgan. U bilan o'zaro ta'sir yordamida sodir bo'ladi CRD (maxsus manba ta'riflari), unda biz zarur bo'lgan Ceph ob'ektlarining xususiyatlarini tasvirlaymiz (Bu yagona barqaror dastur bo'lgani uchun, agar boshqacha ko'rsatilmagan bo'lsa, sukut bo'yicha ushbu maqola Ceph haqida gapiradi). Belgilangan parametrlarga ko'ra, operator avtomatik ravishda konfiguratsiya uchun zarur bo'lgan buyruqlarni bajaradi.

Keling, ob'ektlar do'konini yaratish misolidan foydalanib, xususiyatlarni ko'rib chiqaylik, aniqrog'i - 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 }}

Ro'yxatda ko'rsatilgan parametrlar juda standart va sharhlarga muhtoj emas, ammo shablon o'zgaruvchilari uchun ajratilganlarga alohida e'tibor qaratish lozim.

Ishning umumiy sxemasi shundan iboratki, biz YAML fayli orqali resurslarga "buyurtma beramiz", buning uchun operator kerakli buyruqlarni bajaradi va bizga "haqiqiy bo'lmagan" sirni qaytaradi, bu bilan biz keyinchalik ishlashimiz mumkin. (pastga qarang). Va yuqorida sanab o'tilgan o'zgaruvchilardan buyruq va maxfiy nom kompilyatsiya qilinadi.

Bu qanday jamoa? Ob'ektni saqlash uchun foydalanuvchi yaratishda pod ichidagi Rook operatori quyidagilarni bajaradi:

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

Ushbu buyruqni bajarish natijasi JSON tuzilishi bo'ladi:

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

Keys - S3 API orqali ob'yekt xotirasiga kirish uchun kelajakda qanday ilovalar kerak bo'ladi. Rook operatori ularni mehribonlik bilan tanlaydi va ularni nomi bilan sir ko'rinishida o'z nom maydoniga joylashtiradi. rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Ushbu maxfiy ma'lumotlardan foydalanish uchun uni konteynerga muhit o'zgaruvchilari sifatida qo'shing. Misol tariqasida, men Ish uchun shablonni beraman, unda biz har bir foydalanuvchi muhiti uchun avtomatik chelaklar yaratamiz:

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

Ushbu Ishda sanab o'tilgan barcha harakatlar Kubernetes doirasida amalga oshirildi. YAML fayllarida tasvirlangan tuzilmalar Git omborida saqlanadi va ko'p marta qayta ishlatiladi. Biz buni DevOps muhandislari va umuman CI/CD jarayoni uchun katta ortiqcha deb bilamiz.

Rook va Radosdan xursandman

Ceph + RBD kombinatsiyasidan foydalanish hajmlarni podkalarga o'rnatishda ma'lum cheklovlarni qo'yadi.

Xususan, statistik ilovalar ishlashi uchun nomlar maydoni Cephga kirish sirini o'z ichiga olishi kerak. Agar ularning nomlari boʻshliqlarida 2-3 ta muhit boʻlsa, yaxshi boʻladi: borib, sirni qoʻlda nusxalashingiz mumkin. Ammo har bir xususiyat uchun ishlab chiquvchilar uchun o'z nom maydoniga ega alohida muhit yaratilgan bo'lsa-chi?

Biz bu muammoni o'zimiz yordamida hal qildik qobiq operatori, bu sirlarni avtomatik ravishda yangi nom maydonlariga ko'chiradi (bunday ilgakning misoli quyidagi maqolada tasvirlangan. Ushbu maqola).

#! /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

Biroq, Rook-dan foydalanganda bu muammo oddiygina mavjud emas. O'rnatish jarayoni o'z drayverlari asosida amalga oshiriladi Egiluvchan hajm yoki CSI (hali beta bosqichida) va shuning uchun sirlarni talab qilmaydi.

Rook avtomatik ravishda ko'plab muammolarni hal qiladi, bu bizni yangi loyihalarda foydalanishga undaydi.

Rookni qamal qilish

Keling, o'z tajribalarimizni o'tkazishimiz uchun Rook va Cephni qo'llash orqali amaliy qismni yakunlaylik. Ushbu chidab bo'lmas minoraga hujum qilishni osonlashtirish uchun ishlab chiquvchilar Helm paketini tayyorladilar. Keling, yuklab olamiz:

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

Fayl ichida rook-ceph/values.yaml turli xil sozlamalarni topishingiz mumkin. Eng muhimi, agentlar va qidiruvlar uchun tolerantliklarni belgilashdir. Biz ifloslanishlar/tolerantlik mexanizmi nima uchun ishlatilishi mumkinligini batafsil bayon qildik Ushbu maqola.

Muxtasar qilib aytganda, biz mijoz ilovalari podkastlari ma'lumotlarni saqlash disklari bilan bir xil tugunlarda joylashgan bo'lishini xohlamaymiz. Sababi oddiy: shu tarzda Rook agentlarining ishi dasturning o'ziga ta'sir qilmaydi.

Shunday qilib, faylni oching rook-ceph/values.yaml sevimli muharriringiz bilan va oxirida quyidagi blokni qo'shing:

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

Ma'lumotlarni saqlash uchun ajratilgan har bir tugun uchun mos keladigan dog'ni qo'shing:

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

Keyin Helm diagrammasini buyruq bilan o'rnating:

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

Endi siz klaster yaratishingiz va joylashuvni belgilashingiz kerak 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 holatini tekshirish - ko'rishni kuting 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

Shu bilan birga, mijoz ilovasi bo'lgan podlar Ceph uchun ajratilgan tugunlarda tugamasligini tekshirib ko'raylik:

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

Bundan tashqari, qo'shimcha komponentlar xohlagancha sozlanishi mumkin. Ular haqida batafsil ma'lumot maqolada keltirilgan hujjatlar. Boshqaruv uchun asboblar paneli va asboblar qutisini o'rnatishni tavsiya qilamiz.

Rook va ilgaklar: Rook hamma narsa uchun etarlimi?

Ko'rib turganingizdek, Rookning rivojlanishi jadal davom etmoqda. Ammo hali ham Ceph-ning qo'lda konfiguratsiyasidan butunlay voz kechishga imkon bermaydigan muammolar mavjud:

• Rook haydovchi yo'q qila olmaydi o'rnatilgan bloklardan foydalanish bo'yicha eksport ko'rsatkichlari, bu bizni monitoringdan mahrum qiladi.
• Flexvolume va CSI qanday qilib bilmayman hajmlar hajmini o'zgartirish (bir xil RBD dan farqli o'laroq), shuning uchun Ruk foydali (va ba'zan juda zarur!) Asbobdan mahrum.
• Rook hali ham oddiy Ceph kabi moslashuvchan emas. Agar biz CephFS metama'lumotlarini SSD-da saqlash uchun hovuzni va ma'lumotlarning o'zi HDD-da saqlanishi uchun sozlashni istasak, CRUSH xaritalarida alohida qurilmalar guruhlarini qo'lda ro'yxatdan o'tkazishimiz kerak bo'ladi.
• Rook-ceph-operator barqaror deb hisoblanishiga qaramay, hozirda Ceph-ni 13-dan 14-versiyaga yangilashda ba'zi muammolar mavjud.

topilmalar

"Hozirda Ruk tashqi dunyodan piyonlar tomonidan yopilgan, ammo biz bir kun kelib u o'yinda hal qiluvchi rol o'ynashiga ishonamiz!" (iqtibos ushbu maqola uchun maxsus ixtiro qilingan)

Rook loyihasi, shubhasiz, bizning qalblarimizni zabt etdi - biz [barcha ijobiy va salbiy tomonlari bilan] albatta sizning e'tiboringizga loyiq deb hisoblaymiz.

Bizning kelajakdagi rejalarimiz rook-cephni modulga aylantirishdan iborat addon-operator, bu bizning ko'plab Kubernetes klasterlarimizda foydalanishni yanada sodda va qulayroq qiladi.

PS

Shuningdek, bizning blogimizda o'qing:

• «Rook - Kubernetes uchun "o'z-o'ziga xizmat ko'rsatish" ma'lumotlar ombori";
• «Ceph asosidagi Kubernetesda provayder bilan doimiy xotira yaratish";
• «Ma'lumotlar bazalari va Kubernetes (ko'rib chiqish va video hisobot)";
• «Shell-operator bilan tanishish: Kubernetes uchun operatorlarni yaratish endi osonlashdi";
• «Kubernetes uchun operatorlar: davlat dasturlarini qanday ishga tushirish kerak".

Manba: www.habr.com