🥇Rook की नाही Rook - हा प्रश्न आहे

या महिन्याच्या सुरूवातीस, 3 मे रोजी, "कुबर्नेट्समध्ये वितरित डेटा स्टोरेजसाठी व्यवस्थापन प्रणाली" चे एक मोठे प्रकाशन घोषित करण्यात आले - रुक 1.0.0. एक वर्षापूर्वी आम्ही आधीच प्रकाशित रुकचे सामान्य विहंगावलोकन. मग आम्हाला त्याच्या अनुभवाबद्दल बोलण्यास सांगितले सराव मध्ये वापरा — आणि आता, प्रकल्पाच्या इतिहासातील अशा महत्त्वपूर्ण मैलाच्या दगडासाठी, आम्ही आमच्या संचित छाप सामायिक करण्यात आनंदी आहोत.

थोडक्यात, रुक हा एक संच आहे ऑपरेटर Kubernetes साठी, जे Ceph, EdgeFS, Minio, Cassandra, CockroachDB सारख्या डेटा स्टोरेज सोल्यूशन्सच्या तैनाती, व्यवस्थापन, स्वयंचलित पुनर्प्राप्तीवर पूर्ण नियंत्रण ठेवतात.

याक्षणी सर्वात विकसित (आणि फक्त एक в स्थिर स्टेज) उपाय आहे rook-ceph-operator.

शेरा: Ceph शी संबंधित Rook 1.0.0 प्रकाशनातील महत्त्वपूर्ण बदलांपैकी, आम्ही Ceph Nautilus साठी समर्थन आणि CephFS किंवा RGW बकेटसाठी NFS वापरण्याची क्षमता लक्षात घेऊ शकतो. एजएफएस सपोर्टचे बीटा स्तरावरील परिपक्वता हे इतरांमध्ये वेगळे आहे.

तर, या लेखात आम्ही:

कुबर्नेट्स क्लस्टरमध्ये सेफ तैनात करण्यासाठी रुकचा वापर करताना आपल्याला कोणते फायदे दिसतात या प्रश्नाचे उत्तर देऊया;
आम्ही उत्पादनात रुक वापरण्याचा आमचा अनुभव आणि छाप सामायिक करू;
रुकला आम्ही “होय!” का म्हणतो आणि त्याच्यासाठीच्या आमच्या योजनांबद्दल सांगू.

चला सामान्य संकल्पना आणि सिद्धांतासह प्रारंभ करूया.

"मला एका रुकचा फायदा आहे!" (अज्ञात बुद्धिबळपटू)

रुकचा एक मुख्य फायदा असा आहे की डेटा स्टोअर्सशी परस्परसंवाद कुबर्नेट्स यंत्रणेद्वारे केला जातो. याचा अर्थ असा की तुम्हाला यापुढे शीटमधून कन्सोलमध्ये Ceph कॉन्फिगर करण्यासाठी कमांड कॉपी करण्याची आवश्यकता नाही.

— तुम्हाला क्लस्टरमध्ये CephFS तैनात करायचे आहे का? फक्त एक YAML फाइल लिहा!
- काय? तुम्ही S3 API सह ऑब्जेक्ट स्टोअर देखील तैनात करू इच्छिता? फक्त दुसरी YAML फाईल लिहा!

रूक एका सामान्य ऑपरेटरच्या सर्व नियमांनुसार तयार केला जातो. वापरून त्याच्याशी संवाद साधला जातो CRD (सानुकूल संसाधन व्याख्या), ज्यामध्ये आम्ही आम्हाला आवश्यक असलेल्या Ceph घटकांच्या वैशिष्ट्यांचे वर्णन करतो (हे एकमेव स्थिर अंमलबजावणी असल्याने, डीफॉल्टनुसार हा लेख सेफबद्दल बोलेल, जोपर्यंत स्पष्टपणे अन्यथा सांगितले जात नाही). निर्दिष्ट पॅरामीटर्सनुसार, ऑपरेटर कॉन्फिगरेशनसाठी आवश्यक कमांड स्वयंचलितपणे कार्यान्वित करेल.

ऑब्जेक्ट स्टोअर तयार करण्याचे उदाहरण वापरून तपशील पाहूया, किंवा त्याऐवजी - 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 फाईलद्वारे संसाधने "ऑर्डर" करतो, ज्यासाठी ऑपरेटर आवश्यक कमांड्स कार्यान्वित करतो आणि आम्हाला एक "वास्तविक नसलेले" रहस्य परत करतो ज्याद्वारे आम्ही पुढे काम करू शकतो. (खाली पहा). आणि वर सूचीबद्ध केलेल्या व्हेरिएबल्समधून, कमांड आणि गुप्त नाव संकलित केले जाईल.

हा कोणत्या प्रकारचा संघ आहे? ऑब्जेक्ट स्टोरेजसाठी वापरकर्ता तयार करताना, पॉडमधील रुक ऑपरेटर खालील गोष्टी करेल:

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

या जॉबमध्ये सूचीबद्ध केलेल्या सर्व क्रिया कुबर्नेट्सच्या चौकटीत केल्या गेल्या. YAML फाइल्समध्ये वर्णन केलेल्या रचना Git रिपॉझिटरीमध्ये संग्रहित केल्या जातात आणि बर्याच वेळा पुन्हा वापरल्या जातात. आम्ही याला DevOps अभियंत्यांसाठी आणि संपूर्णपणे CI/CD प्रक्रियेसाठी एक मोठा प्लस म्हणून पाहतो.

Rook आणि Rados सह आनंदी

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

तथापि, रुक वापरताना ही समस्या अस्तित्वात नाही. माउंटिंग प्रक्रिया त्याच्या स्वत: च्या ड्रायव्हर्सवर आधारित वापरून उद्भवते फ्लेक्स व्हॉल्यूम किंवा CSI (अद्याप बीटा अवस्थेत) आणि म्हणून गुपितांची आवश्यकता नाही.

रुक आपोआप अनेक समस्या सोडवते, जे आम्हाला नवीन प्रकल्पांमध्ये वापरण्यास प्रोत्साहित करते.

Rook चा वेढा

रुक आणि सेफ तैनात करून व्यावहारिक भाग पूर्ण करूया जेणेकरून आपण स्वतःचे प्रयोग करू शकू. या अभेद्य टॉवरवर हल्ला करणे सोपे करण्यासाठी, विकासकांनी हेल्म पॅकेज तयार केले आहे. चला ते डाउनलोड करूया:

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

फाईलमध्ये rook-ceph/values.yaml तुम्ही अनेक भिन्न सेटिंग्ज शोधू शकता. सर्वात महत्वाची गोष्ट म्हणजे एजंट आणि शोधासाठी सहनशीलता निर्दिष्ट करणे. डाग/सहिष्णुता यंत्रणा कशासाठी वापरली जाऊ शकते याचे आम्ही तपशीलवार वर्णन केले आहे हा लेख.

थोडक्यात, क्लायंट ऍप्लिकेशन पॉड्स डेटा स्टोरेज डिस्क्स सारख्याच नोड्सवर असू नयेत अशी आमची इच्छा आहे. कारण सोपे आहे: अशा प्रकारे रूक एजंट्सच्या कार्याचा अनुप्रयोगावरच परिणाम होणार नाही.

तर, फाईल उघडा 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 install --namespace ${ROOK_NAMESPACE} ./rook-ceph

आता तुम्हाला क्लस्टर तयार करण्याची आणि स्थान निर्दिष्ट करण्याची आवश्यकता आहे ओएसडी:

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 स्थिती तपासत आहे - पाहण्याची अपेक्षा करा 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

पुढे, इच्छेनुसार अतिरिक्त घटक कॉन्फिगर केले जाऊ शकतात. त्यांच्याबद्दल अधिक तपशील मध्ये सूचित केले आहेत दस्तऐवजीकरण. प्रशासनासाठी, आम्ही डॅशबोर्ड आणि टूलबॉक्स स्थापित करण्याची जोरदार शिफारस करतो.

रुक आणि हुक: रुक प्रत्येक गोष्टीसाठी पुरेसा आहे का?

तुम्ही बघू शकता, रुकचा विकास जोरात सुरू आहे. परंतु तरीही अशा समस्या आहेत ज्या आम्हाला सेफचे मॅन्युअल कॉन्फिगरेशन पूर्णपणे सोडून देण्याची परवानगी देत नाहीत:

रुक ड्रायव्हर नाही करू शकत नाही माउंटेड ब्लॉक्सच्या वापरावरील एक्सपोर्ट मेट्रिक्स, जे आम्हाला मॉनिटरिंगपासून वंचित ठेवतात.
फ्लेक्स व्हॉल्यूम आणि CSI कसे माहित नाही व्हॉल्यूमचा आकार बदला (त्याच RBD च्या विरूद्ध), त्यामुळे Rook उपयुक्त (आणि कधीकधी गंभीरपणे आवश्यक!) साधनापासून वंचित आहे.
रुक अजूनही नियमित सेफइतका लवचिक नाही. जर आम्हाला सेफएफएस मेटाडेटा SSD वर संग्रहित करण्यासाठी पूल कॉन्फिगर करायचा असेल आणि डेटा स्वतः HDD वर संग्रहित करायचा असेल, तर आम्हाला CRUSH नकाशेमध्ये डिव्हाइसेसचे स्वतंत्र गट मॅन्युअली नोंदणी करणे आवश्यक आहे.
रूक-सेफ-ऑपरेटरला स्थिर मानले जात असूनही, सेफ आवृत्ती 13 ते 14 पर्यंत श्रेणीसुधारित करताना सध्या काही समस्या आहेत.

निष्कर्ष

"सध्या रुक बाहेरच्या जगापासून प्याद्यांनी बंद केले आहे, परंतु आम्हाला विश्वास आहे की एक दिवस ती गेममध्ये निर्णायक भूमिका बजावेल!" (कोट विशेषतः या लेखासाठी शोधला आहे)

रुक प्रकल्पाने निःसंशयपणे आमची मने जिंकली आहेत - आमचा विश्वास आहे की [त्याच्या सर्व साधक आणि बाधकांसह] ते निश्चितपणे तुमचे लक्ष देण्यास पात्र आहे.

आमच्या भविष्यातील योजना रुक-सेफसाठी एक मॉड्यूल बनवण्यापर्यंत वाढतात अॅडऑन-ऑपरेटर, जे आमच्या असंख्य Kubernetes क्लस्टर्समध्ये त्याचा वापर आणखी सोपे आणि अधिक सोयीस्कर करेल.

PS

आमच्या ब्लॉगवर देखील वाचा:

स्त्रोत: www.habr.com

रुककडे किंवा रुककडे नाही - हा प्रश्न आहे

"मला एका रुकचा फायदा आहे!" (अज्ञात बुद्धिबळपटू)

Rook आणि Rados सह आनंदी

Rook चा वेढा

रुक आणि हुक: रुक प्रत्येक गोष्टीसाठी पुरेसा आहे का?

निष्कर्ष

PS

एक टिप्पणी जोडा Отменить ответ