Menjadi Benteng atau tidak menjadi Benteng - itulah pertanyaannya

Pada awal bulan ini, pada tanggal 3 Mei, rilis besar dari “sistem manajemen untuk penyimpanan data terdistribusi di Kubernetes” diumumkan - Benteng 1.0.0. Lebih dari setahun yang lalu kita sudah diterbitkan gambaran umum tentang Benteng. Kemudian kami diminta menceritakan pengalamannya digunakan dalam praktik — dan sekarang, tepat pada saat tonggak penting dalam sejarah proyek ini, kami dengan senang hati membagikan kesan yang kami kumpulkan.

Singkatnya, Benteng adalah satu set operator untuk Kubernetes, yang mengambil kendali penuh atas penerapan, pengelolaan, pemulihan otomatis solusi penyimpanan data seperti Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Saat ini yang paling berkembang (dan satu-satunya в stabil tahap) solusinya adalah operator benteng-ceph.

Catatan: Di antara perubahan signifikan dalam rilis Rook 1.0.0 terkait Ceph, kami dapat mencatat dukungan untuk Ceph Nautilus dan kemampuan menggunakan NFS untuk bucket CephFS atau RGW. Yang menonjol antara lain adalah matangnya dukungan EdgeFS ke level beta.

Jadi, dalam artikel ini kami:

• Mari kita jawab pertanyaan tentang keuntungan apa yang kita lihat dalam menggunakan Rook untuk menerapkan Ceph di cluster Kubernetes;
• Kami akan berbagi pengalaman dan kesan kami menggunakan Benteng dalam produksi;
• Mari beri tahu kamu alasan kami mengatakan “Ya!” pada Benteng, dan tentang rencana kami untuknya.

Mari kita mulai dengan konsep dan teori umum.

“Aku punya keuntungan dari satu Benteng!” (pemain catur tidak dikenal)

Salah satu keunggulan utama Rook adalah interaksi dengan penyimpanan data dilakukan melalui mekanisme Kubernetes. Ini berarti Anda tidak perlu lagi menyalin perintah untuk mengkonfigurasi Ceph dari sheet ke konsol.

— Apakah Anda ingin menerapkan CephFS dalam sebuah cluster? Cukup tulis file YAML!
- Apa? Apakah Anda juga ingin menerapkan penyimpanan objek dengan S3 API? Cukup tulis file YAML kedua!

Benteng dibuat sesuai dengan semua aturan operator pada umumnya. Interaksi dengannya terjadi melalui penggunaan CRD (Definisi Sumber Daya Kustom), di mana kami menjelaskan karakteristik entitas Ceph yang kami perlukan (karena ini adalah satu-satunya implementasi yang stabil, secara default artikel ini akan membahas tentang Ceph, kecuali dinyatakan lain secara eksplisit). Berdasarkan parameter yang ditentukan, operator akan secara otomatis menjalankan perintah yang diperlukan untuk konfigurasi.

Mari kita lihat secara spesifik menggunakan contoh pembuatan Object Store, 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 daftar cukup standar dan hampir tidak memerlukan komentar, namun perlu memberikan perhatian khusus pada parameter yang dialokasikan untuk variabel templat.

Skema kerja umum bermuara pada fakta bahwa kita "memesan" sumber daya melalui file YAML, yang mana operator menjalankan perintah yang diperlukan dan mengembalikan kepada kita rahasia "tidak terlalu nyata" yang dapat kita gunakan lebih lanjut. (Lihat di bawah). Dan dari variabel yang tercantum di atas, perintah dan nama rahasia akan dikompilasi.

Tim macam apa ini? Saat membuat pengguna untuk penyimpanan objek, operator Benteng di dalam pod akan melakukan hal berikut:

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

Hasil dari menjalankan perintah 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 - aplikasi masa depan apa yang diperlukan untuk mengakses penyimpanan objek melalui S3 API. Operator Benteng dengan baik hati memilihnya dan menempatkannya di namespacenya dalam bentuk rahasia dengan namanya rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Untuk menggunakan data dari rahasia ini, cukup tambahkan ke wadah sebagai variabel lingkungan. Sebagai contoh, saya akan memberikan template untuk Pekerjaan, di mana kita secara otomatis membuat keranjang untuk setiap lingkungan 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 tercantum dalam Tugas ini dilakukan dalam kerangka Kubernetes. Struktur yang dijelaskan dalam file YAML disimpan dalam repositori Git dan digunakan kembali berkali-kali. Kami melihat ini sebagai nilai tambah yang besar bagi para insinyur DevOps dan proses CI/CD secara keseluruhan.

Senang dengan Benteng dan Rados

Penggunaan kombinasi Ceph + RBD menerapkan batasan tertentu pada pemasangan volume ke pod.

Secara khusus, namespace harus berisi rahasia untuk mengakses Ceph agar aplikasi stateful dapat berfungsi. Tidak apa-apa jika Anda memiliki 2-3 lingkungan di namespacenya: Anda dapat membuka dan menyalin rahasianya secara manual. Namun bagaimana jika untuk setiap fitur, lingkungan terpisah dengan namespacenya sendiri dibuat untuk pengembang?

Kami memecahkan masalah ini sendiri dengan menggunakan operator shell, yang secara otomatis menyalin rahasia ke namespace baru (contoh pengait tersebut dijelaskan di 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

Namun, ketika menggunakan Rook, masalah ini sama sekali tidak ada. Proses pemasangan dilakukan menggunakan driver berbasis Volume fleksibel или CSI (masih dalam tahap beta) dan karenanya tidak memerlukan rahasia.

Benteng secara otomatis menyelesaikan banyak masalah, yang mendorong kami untuk menggunakannya dalam proyek baru.

Pengepungan Benteng

Mari selesaikan bagian praktisnya dengan mengerahkan Rook dan Ceph sehingga kita bisa melakukan eksperimen kita sendiri. Untuk memudahkan menyerbu menara yang tidak dapat ditembus ini, pengembang telah menyiapkan paket Helm. Ayo unduh:

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

Dalam file rook-ceph/values.yaml Anda dapat menemukan banyak pengaturan berbeda. Yang paling penting adalah menentukan toleransi untuk agen dan pencarian. Kami menjelaskan secara rinci untuk apa mekanisme noda/toleransi dapat digunakan Artikel ini.

Singkatnya, kami tidak ingin pod aplikasi klien ditempatkan pada node yang sama dengan disk penyimpanan data. Alasannya sederhana: dengan cara ini kerja agen Benteng tidak akan mempengaruhi aplikasi itu sendiri.

Jadi, buka file tersebut rook-ceph/values.yaml dengan editor favorit Anda dan tambahkan blok berikut di akhir:

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

Untuk setiap node yang dicadangkan untuk penyimpanan data, tambahkan taint yang sesuai:

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

Kemudian install grafik Helm dengan perintah:

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

Sekarang Anda perlu membuat cluster dan menentukan lokasinya 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"

Memeriksa status Ceph - berharap untuk melihatnya 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 saat yang sama, mari kita periksa apakah pod dengan aplikasi klien tidak berakhir di node yang dicadangkan untuk Ceph:

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

Selanjutnya, komponen tambahan dapat dikonfigurasi sesuai keinginan. Rincian lebih lanjut tentang mereka ditunjukkan dalam dokumentasi. Untuk administrasi, kami sangat menyarankan untuk memasang dashboard dan toolbox.

Benteng dan kait: apakah Benteng cukup untuk semuanya?

Seperti yang bisa kamu lihat, perkembangan Benteng sedang berjalan lancar. Namun masih ada masalah yang tidak memungkinkan kita untuk sepenuhnya meninggalkan konfigurasi manual Ceph:

• Tidak Ada Pengemudi Benteng tidak bisa mengekspor metrik pada penggunaan blok terpasang, yang membuat kami tidak dapat memantaunya.
• Flexvolume dan CSI tidak tahu bagaimana mengubah ukuran volume (berbeda dengan RBD yang sama), sehingga Benteng tidak memiliki alat yang berguna (dan terkadang sangat dibutuhkan!).
• Rook masih belum sefleksibel Ceph biasa. Jika kita ingin mengonfigurasi kumpulan metadata CephFS untuk disimpan di SSD, dan datanya sendiri untuk disimpan di HDD, kita perlu mendaftarkan grup perangkat terpisah di peta CRUSH secara manual.
• Meskipun rook-ceph-operator dianggap stabil, saat ini terdapat beberapa masalah saat mengupgrade Ceph dari versi 13 ke 14.

Temuan

“Saat ini Benteng tertutup dari dunia luar oleh pion, tapi kami yakin suatu hari nanti dia akan memainkan peran yang menentukan dalam Game!” (kutipan diciptakan khusus untuk artikel ini)

Proyek Benteng tidak diragukan lagi telah memenangkan hati kami - kami percaya bahwa [dengan segala kelebihan dan kekurangannya] proyek ini patut mendapat perhatian Anda.

Rencana masa depan kami adalah menjadikan rook-ceph sebagai modul addon-operator, yang akan membuat penggunaannya di banyak cluster Kubernetes kami menjadi lebih sederhana dan nyaman.

PS

Baca juga di blog kami:

• «Benteng - gudang data “layanan mandiri” untuk Kubernetes»;
• «Membuat penyimpanan persisten dengan penyediaan di Kubernetes berdasarkan Ceph»;
• «Database dan Kubernetes (ikhtisar dan laporan video)»;
• «Memperkenalkan operator shell: membuat operator untuk Kubernetes menjadi lebih mudah»;
• «Operator untuk Kubernetes: cara menjalankan aplikasi stateful'.

Sumber: www.habr.com