Kepada Rook atau tidak kepada Rook - itulah persoalannya

Pada awal bulan ini, pada 3 Mei, keluaran utama "sistem pengurusan untuk penyimpanan data teragih dalam Kubernetes" telah diumumkan - Benteng 1.0.0. Lebih daripada setahun yang lalu kita sudah diterbitkan gambaran umum tentang Rook. Kemudian kami diminta bercerita tentang pengalamannya gunakan dalam amalan — dan sekarang, tepat pada masanya untuk peristiwa penting dalam sejarah projek, kami gembira untuk berkongsi tera terkumpul kami.

Pendek kata, Rook adalah satu set pengendali untuk Kubernetes, yang mengawal sepenuhnya penggunaan, pengurusan, pemulihan automatik penyelesaian storan data seperti Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Pada masa ini yang paling maju (dan hanya satu в stabil peringkat) penyelesaiannya ialah rook-ceph-operator.

Nota: Antara perubahan ketara dalam keluaran Rook 1.0.0 yang berkaitan dengan Ceph, kita boleh perhatikan sokongan untuk Ceph Nautilus dan keupayaan untuk menggunakan NFS untuk baldi CephFS atau RGW. Apa yang menonjol antara lain ialah kematangan sokongan EdgeFS ke tahap beta.

Jadi, dalam artikel ini kami:

• Mari jawab soalan tentang kelebihan yang kita lihat dalam menggunakan Rook untuk menggunakan Ceph dalam kelompok Kubernetes;
• Kami akan berkongsi pengalaman dan tanggapan kami menggunakan Rook dalam pengeluaran;
• Mari beritahu anda mengapa kami berkata "Ya!" kepada Rook, dan tentang rancangan kami untuknya.

Mari kita mulakan dengan konsep dan teori umum.

"Saya mempunyai kelebihan satu Rook!" (pemain catur tidak dikenali)

Salah satu kelebihan utama Rook ialah interaksi dengan stor data dijalankan melalui mekanisme Kubernetes. Ini bermakna anda tidak perlu lagi menyalin arahan untuk mengkonfigurasi Ceph daripada helaian ke dalam konsol.

— Adakah anda mahu menggunakan CephFS dalam kelompok? Tulis sahaja fail YAML!
- Apa? Adakah anda juga mahu menggunakan stor objek dengan API S3? Hanya tulis fail YAML kedua!

Rook dicipta mengikut semua peraturan pengendali biasa. Interaksi dengannya berlaku menggunakan CRD (Takrifan Sumber Tersuai), di mana kami menerangkan ciri entiti Ceph yang kami perlukan (memandangkan ini adalah satu-satunya pelaksanaan yang stabil, secara lalai artikel ini akan bercakap tentang Ceph, melainkan dinyatakan sebaliknya secara eksplisit). Mengikut parameter yang ditentukan, pengendali secara automatik akan melaksanakan arahan yang diperlukan untuk konfigurasi.

Mari kita lihat spesifik menggunakan contoh mencipta Kedai Objek, atau lebih tepatnya - 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 }}

Parameter yang ditunjukkan dalam penyenaraian adalah agak standard dan hampir tidak memerlukan ulasan, tetapi ia patut diberi perhatian khusus kepada yang diperuntukkan kepada pembolehubah templat.

Skim kerja umum datang kepada fakta bahawa kami "memesan" sumber melalui fail YAML, yang mana pengendali melaksanakan arahan yang diperlukan dan mengembalikan kepada kami rahsia "tidak begitu nyata" yang boleh kami kerjakan selanjutnya (lihat di bawah). Dan daripada pembolehubah yang disenaraikan di atas, arahan dan nama rahsia akan disusun.

Pasukan jenis apakah ini? Apabila mencipta pengguna untuk penyimpanan objek, pengendali Rook di dalam pod akan melakukan perkara berikut:

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

Hasil daripada melaksanakan arahan ini akan menjadi struktur JSON:

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

Keys - apakah aplikasi masa hadapan yang diperlukan untuk mengakses storan objek melalui API S3. Pengendali Rook dengan baik hati memilihnya dan meletakkannya dalam ruang namanya dalam bentuk rahsia dengan nama itu rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Untuk menggunakan data daripada rahsia ini, cuma tambahkannya pada bekas sebagai pembolehubah persekitaran. Sebagai contoh, saya akan memberikan templat untuk Job, di mana kami membuat baldi secara automatik untuk setiap persekitaran pengguna:

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

Semua tindakan yang disenaraikan dalam Kerja ini telah dilakukan dalam rangka kerja Kubernetes. Struktur yang diterangkan dalam fail YAML disimpan dalam repositori Git dan digunakan semula berkali-kali. Kami melihat ini sebagai tambahan yang besar untuk jurutera DevOps dan proses CI/CD secara keseluruhan.

Gembira dengan Rook dan Rados

Menggunakan gabungan Ceph + RBD mengenakan sekatan tertentu pada volum pelekap pada pod.

Khususnya, ruang nama mesti mengandungi rahsia untuk mengakses Ceph agar aplikasi stateful berfungsi. Tidak mengapa jika anda mempunyai 2-3 persekitaran dalam ruang nama mereka: anda boleh pergi dan menyalin rahsia secara manual. Tetapi bagaimana jika untuk setiap ciri persekitaran yang berasingan dengan ruang nama sendiri dicipta untuk pembangun?

Kami menyelesaikan masalah ini sendiri menggunakan pengendali shell, yang secara automatik menyalin rahsia ke ruang nama baharu (contoh cangkuk sedemikian diterangkan dalam artikel ini).

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

Walau bagaimanapun, apabila menggunakan Rook masalah ini tidak wujud. Proses pemasangan berlaku menggunakan pemacu sendiri berdasarkan Flexvolume atau CSI (masih dalam peringkat beta) dan oleh itu tidak memerlukan rahsia.

Rook secara automatik menyelesaikan banyak masalah, yang menggalakkan kami menggunakannya dalam projek baharu.

Pengepungan Rook

Mari lengkapkan bahagian praktikal dengan menggunakan Rook dan Ceph supaya kita boleh menjalankan eksperimen kita sendiri. Untuk memudahkan untuk menyerbu menara yang tidak dapat ditembusi ini, pemaju telah menyediakan pakej Helm. Jom muat turun:

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

Dalam fail rook-ceph/values.yaml anda boleh menemui banyak tetapan yang berbeza. Perkara yang paling penting ialah menentukan toleransi untuk ejen dan carian. Kami menerangkan secara terperinci tentang mekanisme cemar/toleransi yang boleh digunakan artikel ini.

Ringkasnya, kami tidak mahu pod aplikasi klien terletak pada nod yang sama dengan cakera storan data. Sebabnya mudah: dengan cara ini kerja ejen Rook tidak akan menjejaskan aplikasi itu sendiri.

Jadi, buka fail rook-ceph/values.yaml dengan editor kegemaran anda dan tambahkan blok berikut pada penghujung:

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

Untuk setiap nod yang dikhaskan untuk penyimpanan data, tambahkan taint yang sepadan:

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

Kemudian pasang carta Helm dengan arahan:

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

Kini anda perlu membuat kluster dan menentukan lokasi 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"

Menyemak status Ceph - mengharapkan untuk melihat 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

Pada masa yang sama, mari semak bahawa pod dengan aplikasi klien tidak berakhir pada nod yang dikhaskan untuk Ceph:

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

Selanjutnya, komponen tambahan boleh dikonfigurasikan seperti yang dikehendaki. Butiran lanjut tentang mereka ditunjukkan dalam dokumentasi. Untuk pentadbiran, kami amat mengesyorkan memasang papan pemuka dan kotak alat.

Rook's and hooks: adakah Rook cukup untuk segala-galanya?

Seperti yang anda lihat, pembangunan Rook sedang giat dijalankan. Tetapi masih terdapat masalah yang tidak membenarkan kami meninggalkan sepenuhnya konfigurasi manual Ceph:

• Tiada Pemandu Rook tak boleh metrik eksport mengenai penggunaan blok yang dipasang, yang menghalang kami daripada pemantauan.
• Flexvolume dan CSI tidak tahu bagaimana menukar saiz volum (berbanding dengan RBD yang sama), jadi Rook kehilangan alat yang berguna (dan kadangkala sangat diperlukan!).
• Rook masih tidak fleksibel seperti Ceph biasa. Jika kami ingin mengkonfigurasi kumpulan untuk metadata CephFS untuk disimpan pada SSD, dan data itu sendiri untuk disimpan pada HDD, kami perlu mendaftarkan kumpulan peranti yang berasingan dalam peta CRUSH secara manual.
• Walaupun fakta bahawa pengendali rook-ceph dianggap stabil, pada masa ini terdapat beberapa masalah semasa menaik taraf Ceph daripada versi 13 kepada 14.

Penemuan

"Sekarang Rook ditutup dari dunia luar oleh bidak, tetapi kami percaya bahawa suatu hari nanti dia akan memainkan peranan penting dalam permainan!" (petikan dicipta khusus untuk artikel ini)

Projek Rook sudah pasti telah memenangi hati kami - kami percaya bahawa [dengan segala kebaikan dan keburukannya] pastinya ia patut mendapat perhatian anda.

Rancangan masa depan kami bermuara kepada menjadikan rook-ceph sebagai modul pengendali tambahan, yang akan menjadikan penggunaannya dalam banyak kluster Kubernetes kami lebih mudah dan lebih mudah.

PS

Baca juga di blog kami:

• «Rook - gudang data "layan diri" untuk Kubernetes»;
• «Mencipta storan berterusan dengan peruntukan dalam Kubernetes berdasarkan Ceph»;
• «Pangkalan data dan Kubernetes (semakan dan laporan video)»;
• «Memperkenalkan shell-operator: membuat operator untuk Kubernetes semakin mudah»;
• «Operator untuk Kubernetes: cara menjalankan aplikasi stateful'.

Sumber: www.habr.com