روڪ ڏانهن يا روڪ ڏانهن نه - اهو سوال آهي

هن مهيني جي شروعات ۾، 3 مئي تي، "ڪبرنيٽس ۾ ورهايل ڊيٽا اسٽوريج لاءِ مينيجمينٽ سسٽم" جي هڪ وڏي رليز جو اعلان ڪيو ويو - روڪ 1.0.0. اسان اڳ ۾ ئي هڪ سال کان وڌيڪ شايع ٿيل روڪ جو عام جائزو. پوءِ اسان کي سندس تجربي بابت ڳالهائڻ لاءِ چيو ويو عملي طور استعمال ڪريو - ۽ هاڻي، منصوبي جي تاريخ ۾ اهڙي اهم سنگ ميل جي وقت ۾، اسان پنهنجي جمع ٿيل تاثرات کي حصيداري ڪرڻ ۾ خوش آهيون.

مختصر ۾، روڪ هڪ سيٽ آهي آپريٽرز ڪبرنيٽس لاءِ، جيڪي ڊيٽا اسٽوريج حلن جي ڊيٽنگ، مئنيجمينٽ، خودڪار وصولي جو مڪمل ڪنٽرول ڪن ٿا جهڙوڪ Ceph، EdgeFS، Minio، Cassandra، CockroachDB.

هن وقت سڀ کان وڌيڪ ترقي يافته (۽ واحد в مستحڪم اسٽيج) حل آهي rook-ceph-آپريٽر.

ويچاري: Ceph سان لاڳاپيل Rook 1.0.0 رليز ۾ اهم تبديلين مان، اسان Ceph Nautilus لاءِ سپورٽ ۽ CephFS يا RGW بالٽ لاءِ NFS استعمال ڪرڻ جي صلاحيت کي نوٽ ڪري سگھون ٿا. ٻين جي وچ ۾ ڇا بيٺو آهي بيٽا سطح تي EdgeFS سپورٽ جي پختگي.

تنهن ڪري، هن مضمون ۾ اسين:

• اچو ته ان سوال جو جواب ڏيون ته ڪبرنيٽس ڪلستر ۾ ڪيف کي ترتيب ڏيڻ لاءِ روڪ استعمال ڪرڻ ۾ اسان ڪهڙا فائدا ڏسون ٿا؛
• اسان پيداوار ۾ Rook استعمال ڪرڻ جو اسان جو تجربو ۽ تاثر شيئر ڪنداسين؛
• اچو ته توهان کي ٻڌايون ته اسان ڇو چوندا آهيون “ها!” روڪ کي، ۽ هن لاءِ اسان جي منصوبن بابت.

اچو ته عام تصورات ۽ نظريي سان شروع ڪريون.

"مون کي هڪ روڪ جو فائدو آهي!" (نامعلوم شطرنج رانديگر)

Rook جي مکيه فائدن مان هڪ اهو آهي ته ڊيٽا اسٽورن سان رابطي کي ڪبرنيٽس ميڪانيزم ذريعي ڪيو ويندو آهي. هن جو مطلب اهو آهي ته توهان کي هاڻي شيٽ مان ڪيف کي ڪنسول ۾ ترتيب ڏيڻ لاء حڪمن کي نقل ڪرڻ جي ضرورت ناهي.

- ڇا توھان ھڪڙي ڪلستر ۾ 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 }}

هن نوڪري ۾ درج ڪيل سڀئي ڪارناما Kubernetes جي فريم ورڪ ۾ ڪيا ويا. YAML فائلن ۾ بيان ڪيل جوڙجڪ Git مخزن ۾ ذخيرو ٿيل آهن ۽ ڪيترائي ڀيرا ٻيهر استعمال ڪيا ويا آهن. اسان هن کي ڏسون ٿا هڪ وڏي پلس لاءِ DevOps انجنيئرز ۽ مجموعي طور تي CI/CD عمل.

Rook ۽ Rados سان خوش ٿيو

Ceph + RBD جي ميلاپ کي استعمال ڪندي ڪجهه پابنديون لاڳو ڪري ٿو پوڊس جي مقدار کي وڌائڻ تي.

خاص طور تي، نالي جي جڳھ ۾ لازمي طور تي سيف تائين رسائي حاصل ڪرڻ لاءِ راز ھوندو آھي جيئن رياستي ايپليڪيشنن کي ڪم ڪرڻ لاءِ. اھو ٺيڪ آھي جيڪڏھن توھان وٽ آھن 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 ۽ Ceph کي ترتيب ڏيون ته جيئن اسان پنهنجا تجربا ڪري سگهون. هن ناقابل تسخير ٽاور کي طوفان ڪرڻ آسان بڻائڻ لاء، ڊولپرز هڪ هيلم پيڪيج تيار ڪيو آهي. اچو ته ڊائون لوڊ ڪريون:

$ 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

ساڳئي وقت، اچو ته چيڪ ڪريون ته ڪلائنٽ ايپليڪيشن سان پوڊس ڪيف لاءِ محفوظ ڪيل نوڊس تي ختم نه ٿين:

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

ان کان سواء، اضافي اجزاء ترتيب ڏئي سگهجي ٿو جيئن گهربل. انهن جي باري ۾ وڌيڪ تفصيل ۾ بيان ڪيو ويو آهي دستاويز. انتظاميه لاءِ، اسان ڊيش بورڊ ۽ ٽول باڪس کي انسٽال ڪرڻ جي سختي سان صلاح ڏيون ٿا.

روڪ ۽ ٿلهو: ڇا روڪ هر شيءِ لاءِ ڪافي آهي؟

جئين توهان ڏسي سگهو ٿا، روڪ جي ترقي مڪمل جھول ۾ آهي. پر اڃا به اهڙا مسئلا آهن جيڪي اسان کي مڪمل طور تي Ceph جي دستيابي ترتيب کي ختم ڪرڻ جي اجازت نٿا ڏين:

• نه روڪ ڊرائيور نٿو ڪري سگهان ايڪسپورٽ ميٽرڪ تي نصب ٿيل بلاڪ جي استعمال تي، جيڪو اسان کي نگراني کان محروم ڪري ٿو.
• Flexvolume ۽ CSI خبر ناهي ڪيئن حجم جي سائيز کي تبديل ڪريو (جيئن ساڳي آر بي ڊي جي مخالفت)، تنهنڪري روڪ هڪ مفيد (۽ ڪڏهن ڪڏهن نازڪ ضرورت آهي!) اوزار کان محروم آهي.
• روڪ اڃا تائين باقاعده ڪيف وانگر لچڪدار نه آهي. جيڪڏهن اسان پول کي ترتيب ڏيڻ چاهيون ٿا CephFS ميٽا ڊيٽا لاءِ SSD تي ذخيرو ٿيڻ لاءِ، ۽ ڊيٽا پاڻ کي HDD تي محفوظ ڪرڻ لاءِ، اسان کي دستي طور CRUSH نقشن ۾ ڊوائيسز جا الڳ گروپ رجسٽر ڪرڻ گهرجن.
• ان حقيقت جي باوجود ته روڪ-سيف-آپريٽر کي مستحڪم سمجهيو ويندو آهي، في الحال ڪجهه مسئلا آهن جڏهن سيف کي اپڊيٽ ڪرڻ وقت 13 کان 14 ورزن تائين.

پهچڻ

"هن وقت روڪ ٻاهرئين دنيا کان بند ٿيل آهي، پر اسان کي يقين آهي ته هڪ ڏينهن هوء راند ۾ فيصلو ڪندڙ ڪردار ادا ڪندي!" (اقتباس خاص طور تي هن مضمون لاء ايجاد ڪيو ويو)

روڪ پروجيڪٽ بلاشبہ اسان جي دلين کي فتح ڪيو آهي - اسان يقين رکون ٿا ته [ان جي سڀني فائدن ۽ نقصانن سان] اهو ضرور توهان جي توجه جو مستحق آهي.

اسان جي مستقبل جا منصوبا روڪ-سيف لاءِ ماڊل ٺاهڻ لاءِ تيار آهن اضافو آپريٽر، جيڪو اسان جي ڪيترن ئي ڪبرنيٽس ڪلسٽرن ۾ ان جي استعمال کي وڌيڪ آسان ۽ وڌيڪ آسان بڻائيندو.

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

• «روڪ - ڪبرنيٽس لاءِ ”خود-خدمت“ ڊيٽا گودام"؛
• «ڪيف جي بنياد تي ڪبرنيٽس ۾ روزي رکڻ سان مسلسل اسٽوريج ٺاهڻ"؛
• «ڊيٽابيس ۽ ڪبرنيٽس (جائزو ۽ وڊيو رپورٽ)"؛
• «شيل آپريٽر جو تعارف: ڪبرنيٽس لاءِ آپريٽر ٺاهڻ بلڪل آسان ٿي ويو آهي"؛
• «ڪبرنيٽس لاءِ آپريٽر: رياستي ايپليڪيشنن کي ڪيئن هلائڻ».

جو ذريعو: www.habr.com