रुकलाई कि रुकलाई होइन - त्यो प्रश्न हो

यस महिनाको सुरुमा, मे 3 मा, "कुबर्नेट्समा वितरित डाटा भण्डारणको लागि व्यवस्थापन प्रणाली" को एक प्रमुख रिलीज घोषणा गरिएको थियो - रुक १.०.०। एक वर्ष भन्दा बढी पहिले नै हामी पहिले नै प्रकाशित Rook को सामान्य सिंहावलोकन। त्यसपछि हामीलाई उहाँको अनुभवको बारेमा कुरा गर्न भनियो व्यवहारमा प्रयोग गर्नुहोस् — र अब, परियोजनाको इतिहासमा यस्तो महत्त्वपूर्ण कोसेढुङ्गाको लागि समयमै, हामी हाम्रा संचित छापहरू साझा गर्न पाउँदा खुसी छौं।

छोटकरीमा, रुक एक सेट हो अपरेटरहरु Kubernetes को लागि, जसले Ceph, EdgeFS, Minio, Cassandra, CockroachDB जस्ता डेटा भण्डारण समाधानहरूको तैनाती, व्यवस्थापन, स्वचालित रिकभरीको पूर्ण नियन्त्रण लिन्छ।

यस समयमा सबैभन्दा विकसित (र एक मात्र в स्थिर चरण) समाधान हो rook-ceph-operator.

भन्नु: Ceph सँग सम्बन्धित Rook 1.0.0 रिलीजमा भएका महत्त्वपूर्ण परिवर्तनहरू मध्ये, हामी Ceph Nautilus को समर्थन र CephFS वा RGW बकेटहरूको लागि NFS प्रयोग गर्ने क्षमतालाई नोट गर्न सक्छौं। अरूको बीचमा के बाहिर खडा छ बीटा स्तरमा EdgeFS समर्थनको परिपक्वता।

त्यसोभए, यस लेखमा हामी:

• कुबर्नेट्स क्लस्टरमा सेफ तैनाथ गर्न रुक प्रयोग गर्दा हामीले के फाइदाहरू देख्छौं भन्ने प्रश्नको जवाफ दिनुहोस्;
• हामी उत्पादनमा रुक प्रयोग गर्ने हाम्रो अनुभव र प्रभावहरू साझा गर्नेछौं;
• रुकलाई हामीले किन “हो!” भन्यौं, र उहाँका लागि हाम्रो योजनाहरूको बारेमा बताउनुहोस्।

सामान्य अवधारणा र सिद्धान्त संग सुरु गरौं।

"मसँग एउटा रुकको फाइदा छ!" (अज्ञात चेस खेलाडी)

रुकको मुख्य फाइदाहरू मध्ये एक यो हो कि डाटा स्टोरहरूसँग अन्तरक्रिया Kubernetes संयन्त्रहरू मार्फत गरिन्छ। यसको मतलब यो हो कि तपाईंले अब कन्सोलमा पानाबाट Ceph कन्फिगर गर्न आदेशहरू प्रतिलिपि गर्न आवश्यक छैन।

— के तपाईं क्लस्टरमा CephFS डिप्लोय गर्न चाहनुहुन्छ? केवल YAML फाइल लेख्नुहोस्!
- के? के तपाइँ S3 API सँग कुनै वस्तु स्टोर पनि डिप्लोय गर्न चाहनुहुन्छ? केवल दोस्रो YAML फाइल लेख्नुहोस्!

Rook एक ठेठ अपरेटर को सबै नियमहरु अनुसार सिर्जना गरिएको छ। प्रयोग गरेर उहाँसँग अन्तरक्रिया हुन्छ CRD (कस्टम रिसोर्स परिभाषा), जसमा हामीले हामीलाई चाहिने Ceph संस्थाहरूको विशेषताहरू वर्णन गर्छौं (यो मात्र स्थिर कार्यान्वयन भएकोले, पूर्वनिर्धारित रूपमा यस लेखले 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 }}

यस कार्यमा सूचीबद्ध सबै कार्यहरू Kubernetes को ढाँचा भित्र प्रदर्शन गरिएको थियो। 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

यसबाहेक, थप कम्पोनेन्टहरू इच्छित रूपमा कन्फिगर गर्न सकिन्छ। तिनीहरूको बारेमा थप विवरणहरूमा संकेत गरिएको छ कागजात। प्रशासनको लागि, हामी दृढताका साथ ड्यासबोर्ड र उपकरण बाकस स्थापना गर्न सिफारिस गर्दछौं।

रुक र हुक: के रुक सबै कुराको लागि पर्याप्त छ?

तपाईले देख्न सक्नुहुन्छ, रुकको विकास पूर्ण स्विंगमा छ। तर त्यहाँ अझै पनि समस्याहरू छन् जसले हामीलाई Ceph को म्यानुअल कन्फिगरेसन पूर्ण रूपमा त्याग्न अनुमति दिँदैन:

• रुक चालक छैन सकदिन माउन्टेड ब्लकहरूको प्रयोगमा निर्यात मेट्रिक्स, जसले हामीलाई अनुगमनबाट वञ्चित गर्दछ।
• Flexvolume र CSI थाहा छैन कसरी भोल्युमको साइज परिवर्तन गर्नुहोस् (एउटै RBD को विपरीत), त्यसैले Rook उपयोगी (र कहिलेकाहीँ आलोचनात्मक रूपमा आवश्यक छ!) उपकरणबाट वञ्चित छ।
• रुक अझै पनि नियमित Ceph जत्तिकै लचिलो छैन। यदि हामी CephFS मेटाडेटा SSD मा भण्डारण गर्नको लागि पूल कन्फिगर गर्न चाहन्छौं, र डेटा आफै HDD मा भण्डारण गर्न, हामीले CRUSH नक्सामा म्यानुअल रूपमा यन्त्रहरूको अलग समूह दर्ता गर्न आवश्यक हुनेछ।
• रुक-सेफ-अपरेटरलाई स्थिर मानिन्छ भन्ने तथ्यको बावजुद, संस्करण 13 बाट 14 बाट Ceph स्तरवृद्धि गर्दा हाल केही समस्याहरू छन्।

निष्कर्ष

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

रुक परियोजनाले निस्सन्देह हाम्रो मन जितेको छ - हामी विश्वास गर्छौं कि [यसका सबै फाइदा र विपक्षका साथ] यो निश्चित रूपमा तपाईंको ध्यानको योग्य छ।

हाम्रा भावी योजनाहरू रुक-सेफलाई मोड्युल बनाउनका लागि उबलिएका छन् addon-operator, जसले हाम्रो असंख्य Kubernetes क्लस्टरहरूमा यसको प्रयोग अझ सरल र थप सुविधाजनक बनाउनेछ।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «रुक - Kubernetes को लागि "स्व-सेवा" डाटा गोदाम»;
• «Ceph मा आधारित Kubernetes मा प्रावधान संग लगातार भण्डारण सिर्जना गर्दै»;
• «डाटाबेस र Kubernetes (समीक्षा र भिडियो रिपोर्ट)»;
• «शेल-अपरेटरको परिचय दिँदै: Kubernetes को लागि अपरेटरहरू सिर्जना गर्न सजिलो भयो»;
• «Kubernetes को लागी अपरेटरहरू: स्टेटफुल अनुप्रयोगहरू कसरी चलाउने"।

स्रोत: www.habr.com