Rook və ya yox - bu sualdır

Bu ayın əvvəlində, mayın 3-də, "Kubernetes-də paylanmış məlumatların saxlanması üçün idarəetmə sisteminin" əsas buraxılışı elan edildi - Qala 1.0.0. Artıq bir ildən çoxdur ki, biz nəşr edilmişdir Rook-a ümumi baxış. Sonra bizdən onun təcrübəsi barədə danışmağı xahiş etdilər praktikada istifadə edin — və indi, layihənin tarixində belə bir əlamətdar mərhələnin baş verdiyi vaxtda toplanmış təəssüratlarımızı bölüşməkdən məmnunuq.

Bir sözlə, Rook bir dəstdir operatorlar Ceph, EdgeFS, Minio, Cassandra, CockroachDB kimi məlumat saxlama həllərinin yerləşdirilməsinə, idarə edilməsinə, avtomatik bərpasına tam nəzarət edən Kubernetes üçün.

Hal-hazırda ən inkişaf etmiş (və yeganə в sabit mərhələ) həll yoludur rook-ceph-operator.

Qeyd: Ceph ilə əlaqəli Rook 1.0.0 buraxılışında əhəmiyyətli dəyişikliklər arasında Ceph Nautilus dəstəyini və CephFS və ya RGW vedrələri üçün NFS istifadə etmək qabiliyyətini qeyd edə bilərik. Digərləri arasında fərqlənən EdgeFS dəstəyinin beta səviyyəsinə çatmasıdır.

Beləliklə, bu məqalədə biz:

• Kubernetes klasterində Ceph yerləşdirmək üçün Rook-dan istifadə edərkən hansı üstünlükləri gördüyümüz sualına cavab verək;
• Biz istehsalda Rookdan istifadə təcrübəmizi və təəssüratlarımızı bölüşəcəyik;
• Gəlin sizə Ruka niyə “Bəli!” dediyimizi və onunla bağlı planlarımızdan danışaq.

Ümumi anlayışlar və nəzəriyyə ilə başlayaq.

"Mənim bir Qala üstünlüyüm var!" (naməlum şahmatçı)

Rook-un əsas üstünlüklərindən biri məlumat anbarları ilə qarşılıqlı əlaqənin Kubernetes mexanizmləri vasitəsilə həyata keçirilməsidir. Bu o deməkdir ki, daha Ceph-i vərəqdən konsola konfiqurasiya etmək üçün əmrləri kopyalamağa ehtiyac yoxdur.

— Siz CephFS-i klasterdə yerləşdirmək istəyirsiniz? Sadəcə YAML faylı yazın!
- Nə? Siz həmçinin S3 API ilə obyekt mağazası yerləşdirmək istəyirsiniz? Sadəcə ikinci YAML faylı yazın!

Rook tipik operatorun bütün qaydalarına uyğun olaraq yaradılmışdır. Onunla qarşılıqlı əlaqə istifadə edərək baş verir CRD (Xüsusi Resurs Tərifləri), burada bizə lazım olan Ceph varlıqlarının xüsusiyyətlərini təsvir edirik (bu yeganə sabit tətbiq olduğundan, başqa cür göstərilmədiyi təqdirdə, bu məqalə standart olaraq Ceph haqqında danışacaq). Göstərilən parametrlərə görə operator avtomatik olaraq konfiqurasiya üçün lazım olan əmrləri yerinə yetirəcək.

Obyekt Mağazası yaratmaq nümunəsindən istifadə edərək, xüsusiyyətləri nəzərdən keçirək, daha doğrusu - 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 }}

Siyahıda göstərilən parametrlər olduqca standartdır və şərhlərə ehtiyac duymur, lakin şablon dəyişənlərinə ayrılanlara xüsusi diqqət yetirməyə dəyər.

İşin ümumi sxemi ondan ibarətdir ki, biz resursları YAML faylı vasitəsilə “sifariş edirik”, bunun üçün operator lazımi əmrləri yerinə yetirir və bizə daha da işləyə biləcəyimiz “qeyri-real” sirri qaytarır. (aşağıya bax). Və yuxarıda sadalanan dəyişənlərdən əmr və gizli ad tərtib ediləcək.

Bu necə komandadır? Obyektin saxlanması üçün istifadəçi yaratarkən, pod daxilindəki Rook operatoru aşağıdakıları edəcək:

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

Bu əmrin icrasının nəticəsi JSON strukturu olacaq:

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

Keys - S3 API vasitəsilə obyekt yaddaşına daxil olmaq üçün hansı gələcək tətbiqlərə ehtiyac olacaq. Rook operatoru onları mehribanlıqla seçir və adı ilə sirr şəklində öz ad məkanına qoyur. rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Bu sirrdəki məlumatlardan istifadə etmək üçün onu mühit dəyişənləri kimi konteynerə əlavə etmək kifayətdir. Nümunə olaraq, hər bir istifadəçi mühiti üçün avtomatik olaraq vedrələr yaratdığımız İş üçün şablon verəcəyəm:

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

Bu İşdə sadalanan bütün hərəkətlər Kubernetes çərçivəsində həyata keçirilib. YAML fayllarında təsvir edilən strukturlar Git deposunda saxlanılır və dəfələrlə təkrar istifadə olunur. Biz bunu DevOps mühəndisləri və bütövlükdə CI/CD prosesi üçün böyük bir artı kimi görürük.

Rook və Radosdan xoşbəxtəm

Ceph + RBD birləşməsindən istifadə həcmlərin podlara quraşdırılmasına müəyyən məhdudiyyətlər qoyur.

Xüsusilə, statuslu proqramların işləməsi üçün ad məkanında Ceph-ə daxil olmaq üçün sirr olmalıdır. Onların ad boşluqlarında 2-3 mühit varsa, yaxşıdır: gedib sirri əl ilə köçürə bilərsiniz. Bəs hər bir xüsusiyyət üçün tərtibatçılar üçün öz ad sahəsi olan ayrıca mühit yaradılarsa necə?

Bu problemi özümüz istifadə edərək həll etdik mərmi operatoru, sirləri avtomatik olaraq yeni ad boşluqlarına kopyalayan (belə bir qarmaq nümunəsi aşağıda təsvir edilmişdir) Bu məqalə).

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

Ancaq Rook istifadə edərkən bu problem sadəcə mövcud deyil. Quraşdırma prosesi öz sürücülərindən istifadə edərək baş verir Çevik həcm və ya CSI (hələ beta mərhələsində) və buna görə də sirləri tələb etmir.

Rook avtomatik olaraq bir çox problemləri həll edir, bu da bizi yeni layihələrdə istifadə etməyə təşviq edir.

Rookun mühasirəsi

Rook və Ceph-i yerləşdirməklə praktiki hissəni tamamlayaq ki, öz təcrübələrimizi keçirək. Bu keçilməz qülləyə hücum etməyi asanlaşdırmaq üçün tərtibatçılar Helm paketi hazırlayıblar. Yükləyək:

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

Faylda rook-ceph/values.yaml çox müxtəlif parametrlər tapa bilərsiniz. Ən vacibi agentlər və axtarış üçün tolerantlıqları müəyyən etməkdir. Ləkə/tolerantlıq mexanizminin nə üçün istifadə oluna biləcəyini ətraflı təsvir etdik Bu məqalə.

Qısacası, biz istəmirik ki, müştəri tətbiqi podları məlumat saxlama diskləri ilə eyni qovşaqlarda yerləşsin. Səbəb sadədir: bu şəkildə Rook agentlərinin işi tətbiqin özünə təsir etməyəcək.

Beləliklə, faylı açın rook-ceph/values.yaml sevimli redaktorunuzla və sonunda aşağıdakı bloku əlavə edin:

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

Məlumatların saxlanması üçün ayrılmış hər bir node üçün müvafiq ləkə əlavə edin:

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

Sonra komanda ilə Helm diaqramını quraşdırın:

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

İndi bir klaster yaratmalı və yeri göstərməlisiniz 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 statusu yoxlanılır - görməyi gözləyin 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

Eyni zamanda, müştəri tətbiqi ilə podların Ceph üçün ayrılmış qovşaqlarda bitmədiyini yoxlayaq:

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

Bundan əlavə, əlavə komponentlər istədiyiniz kimi konfiqurasiya edilə bilər. Onlar haqqında daha ətraflı məlumat verilmişdir sənədləşdirmə. İdarəetmə üçün tablosunu və alətlər qutusunu quraşdırmağı tövsiyə edirik.

Rook və qarmaqlar: Rook hər şey üçün kifayətdirmi?

Gördüyünüz kimi, Rookun inkişafı tam sürətlə davam edir. Ancaq hələ də Ceph-in əl ilə konfiqurasiyasından tamamilə imtina etməyə imkan verməyən problemlər var:

• Rook Sürücü yoxdur bilməz quraşdırılmış blokların istifadəsi üzrə ölçüləri ixrac edirik ki, bu da bizi monitorinqdən məhrum edir.
• Flexvolume və CSI necə bilmirəm həcmlərin ölçüsünü dəyişdirin (eyni RBD-dən fərqli olaraq), beləliklə, Rook faydalı (və bəzən çox ehtiyac duyulan!) Alətdən məhrumdur.
• Rook hələ də adi Ceph qədər çevik deyil. Əgər biz CephFS metadatasının SSD-də saxlanması üçün hovuzu konfiqurasiya etmək istəyiriksə və verilənlərin özünün də HDD-də saxlanmasını istəyiriksə, CRUSH xəritələrində ayrı-ayrı cihaz qruplarını əl ilə qeyd etməliyik.
• Rook-ceph-operatorun stabil hesab edilməsinə baxmayaraq, hazırda Ceph-i 13-dən 14-ə yüksəldərkən bəzi problemlər var.

Tapıntılar

"Hal-hazırda Rook xarici dünyadan piyadalar tərəfindən bağlanıb, lakin biz inanırıq ki, bir gün o, oyunda həlledici rol oynayacaq!" (sitat bu məqalə üçün xüsusi olaraq icad edilmişdir)

Rook layihəsi, şübhəsiz ki, ürəyimizi fəth etdi - inanırıq ki, [bütün müsbət və mənfi cəhətləri ilə] mütləq diqqətinizə layiqdir.

Gələcək planlarımız rook-ceph-i modul etməkdən ibarətdir addon-operator, bu, bizim çoxsaylı Kubernetes klasterlərimizdə istifadəsini daha da sadə və rahat edəcək.

PS

Bloqumuzda da oxuyun:

• «Rook - Kubernetes üçün "özünə xidmət" məlumat anbarı";
• «Ceph əsasında Kubernetes-də təminatla davamlı yaddaşın yaradılması";
• «Verilənlər bazaları və Kubernetes (baxış və video hesabat)";
• «Shell-operatorun təqdimatı: Kubernetes üçün operatorlar yaratmaq daha asan oldu";
• «Kubernetes üçün operatorlar: dövlət proqramlarını necə işə salmaq olar.

Mənbə: www.habr.com