რუკს თუ არა რუკს - ეს არის კითხვა

ამ თვის დასაწყისში, 3 მაისს, გამოცხადდა "Kubernetes-ში მონაცემთა განაწილებული შენახვის მართვის სისტემის" ძირითადი გამოშვება - Rook 1.0.0. ერთ წელზე მეტი ხნის წინ ჩვენ უკვე გამოქვეყნდა რუკის ზოგადი მიმოხილვა. შემდეგ გვთხოვეს გვესაუბრა მის გამოცდილებაზე გამოყენება პრაქტიკაში - და ახლა, პროექტის ისტორიაში ასეთი მნიშვნელოვანი ეტაპის დროზე, მოხარული ვართ გაგიზიაროთ ჩვენი დაგროვილი შთაბეჭდილებები.

მოკლედ, Rook არის კომპლექტი ოპერატორები Kubernetes-ისთვის, რომელიც სრულად აკონტროლებს მონაცემთა შენახვის გადაწყვეტილებების განლაგებას, მართვას, ავტომატურ აღდგენას, როგორიცაა Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

ამ დროისთვის ყველაზე განვითარებული (და ერთადერთი в სტაბილური ეტაპი) გამოსავალი არის rook-ceph-ოპერატორი.

შენიშვნა: Ceph-თან დაკავშირებული Rook 1.0.0 გამოშვების მნიშვნელოვან ცვლილებებს შორის შეგვიძლია აღვნიშნოთ Ceph Nautilus-ის მხარდაჭერა და NFS-ის გამოყენების შესაძლებლობა CephFS ან RGW თაიგულებისთვის. რაც გამოირჩევა სხვათა შორის არის EdgeFS მხარდაჭერის მომწიფება ბეტა დონეზე.

ასე რომ, ამ სტატიაში ჩვენ:

• მოდით ვუპასუხოთ კითხვას, თუ რა უპირატესობებს ვხედავთ Rook-ის გამოყენებაში Ceph-ის კუბერნეტის კლასტერში განსათავსებლად;
• ჩვენ გაგიზიარებთ ჩვენს გამოცდილებას და შთაბეჭდილებებს წარმოებაში Rook-ის გამოყენების შესახებ;
• მოდით გითხრათ, რატომ ვეუბნებით რუკს „დიახ!“ და რა გეგმები გვაქვს მისთვის.

დავიწყოთ ზოგადი ცნებებითა და თეორიით.

"მე მაქვს ერთი რუკის უპირატესობა!" (უცნობი მოჭადრაკე)

Rook-ის ერთ-ერთი მთავარი უპირატესობა ის არის, რომ მონაცემთა მაღაზიებთან ურთიერთქმედება ხორციელდება Kubernetes მექანიზმების მეშვეობით. ეს ნიშნავს, რომ თქვენ აღარ გჭირდებათ ბრძანებების კოპირება Ceph-ის კონფიგურაციისთვის ფურცლიდან კონსოლში.

— გსურთ განათავსოთ CephFS კლასტერში? უბრალოდ დაწერეთ YAML ფაილი!
- Რა? ასევე გსურთ განათავსოთ ობიექტების მაღაზია S3 API-ით? უბრალოდ დაწერეთ მეორე YAML ფაილი!

Rook იქმნება ტიპიური ოპერატორის ყველა წესის მიხედვით. მასთან ურთიერთქმედება ხდება გამოყენებით CRD (მორგებული რესურსების განმარტებები), რომელშიც ჩვენ აღვწერთ ჩვენთვის საჭირო ცეფის ერთეულების მახასიათებლებს (რადგან ეს არის ერთადერთი სტაბილური განხორციელება, ნაგულისხმევად ეს სტატია იქნება საუბარი Ceph-ზე, თუ ცალსახად არ არის ნათქვამი სხვა რამ). მითითებული პარამეტრების მიხედვით, ოპერატორი ავტომატურად შეასრულებს კონფიგურაციისთვის აუცილებელ ბრძანებებს.

მოდით შევხედოთ სპეციფიკას Object Store-ის შექმნის მაგალითის გამოყენებით, უფრო სწორად - 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 ფაილის საშუალებით, რისთვისაც ოპერატორი ასრულებს აუცილებელ ბრძანებებს და გვიბრუნებს „არც ისე რეალურ“ საიდუმლოს, რომლითაც შეგვიძლია შემდგომი მუშაობა. (იხილეთ ქვემოთ). და ზემოთ ჩამოთვლილი ცვლადებიდან შედგენილი იქნება ბრძანება და საიდუმლო სახელი.

როგორი გუნდია ეს? ობიექტის შესანახად მომხმარებლის შექმნისას, Rook ოპერატორი pod-ის შიგნით გააკეთებს შემდეგს:

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

ამ სამუშაოში ჩამოთვლილი ყველა მოქმედება შესრულდა Kubernetes-ის ფარგლებში. 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-ის გამოყენებისას ეს პრობლემა უბრალოდ არ არსებობს. სამონტაჟო პროცესი ხდება საკუთარი დრაივერების გამოყენებით, საფუძველზე Flexvolume ან CSI (ჯერ კიდევ ბეტა ეტაპზე) და ამიტომ არ საჭიროებს საიდუმლოებას.

რუკი ავტომატურად წყვეტს ბევრ პრობლემას, რაც გვაიძულებს გამოვიყენოთ იგი ახალ პროექტებში.

რუკის ალყა

მოდით დავასრულოთ პრაქტიკული ნაწილი რუკისა და ცეფის განლაგებით, რათა ჩვენ შევძლოთ საკუთარი ექსპერიმენტების ჩატარება. ამ აუღებელი კოშკის შტურმის გასაადვილებლად, დეველოპერებმა მოამზადეს 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-ის განვითარება გაჩაღებულია. მაგრამ ჯერ კიდევ არის პრობლემები, რომლებიც არ გვაძლევს საშუალებას მთლიანად მივატოვოთ Ceph-ის ხელით კონფიგურაცია:

• არ არის Rook Driver ვერ საექსპორტო მეტრიკა დამონტაჟებული ბლოკების გამოყენებაზე, რაც გვართმევს მონიტორინგს.
• Flexvolume და CSI არ ვიცი როგორ შეცვალეთ მოცულობების ზომა (იგივე RBD-ისგან განსხვავებით), ასე რომ Rook მოკლებულია სასარგებლო (და ზოგჯერ კრიტიკულად საჭირო!) ხელსაწყოს.
• რუკი ჯერ კიდევ არ არის ისეთი მოქნილი, როგორც ჩვეულებრივი ცეფი. თუ გვინდა დავაკონფიგურიროთ აუზი CephFS მეტამონაცემებისთვის SSD-ზე შესანახად, ხოლო თავად მონაცემები HDD-ზე შესანახად, ჩვენ დაგვჭირდება მოწყობილობების ცალკეული ჯგუფების რეგისტრაცია CRUSH რუკებში ხელით.
• იმისდა მიუხედავად, რომ rook-ceph-ოპერატორი ითვლება სტაბილურად, ამჟამად არის გარკვეული პრობლემები Ceph-ის 13-დან 14-მდე ვერსიის განახლებისას.

დასკვნები

”ახლა რუკი დახურულია გარე სამყაროსგან ლომბარდებით, მაგრამ ჩვენ გვჯერა, რომ ერთ დღეს ის გადამწყვეტ როლს ითამაშებს თამაშში!” (ციტატა გამოიგონეს სპეციალურად ამ სტატიისთვის)

Rook-ის პროექტმა უდავოდ მოიგო ჩვენი გული - ჩვენ გვჯერა, რომ [ყველა თავისი დადებითი და უარყოფითი მხარეებით] ის ნამდვილად იმსახურებს თქვენს ყურადღებას.

ჩვენი სამომავლო გეგმები ემყარება rook-ceph-ის მოდულს დანამატის ოპერატორი, რაც მის გამოყენებას ჩვენს მრავალრიცხოვან Kubernetes კლასტერებში კიდევ უფრო მარტივს და მოსახერხებელს გახდის.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «Rook - "თვითმომსახურების" მონაცემთა საწყობი Kubernetes-ისთვის";
• «მუდმივი მეხსიერების შექმნა Kubernetes-ში მიწოდებით Ceph-ის საფუძველზე";
• «მონაცემთა ბაზები და Kubernetes (მიმოხილვა და ვიდეო ანგარიში)";
• «Shell-ოპერატორის წარმოდგენა: Kubernetes-ისთვის ოპერატორების შექმნა ახლახან გამარტივდა";
• «ოპერატორები Kubernetes-ისთვის: როგორ გავუშვათ სახელმწიფო აპლიკაციები".

წყარო: www.habr.com