Rook یا نه Rook، دا پوښتنه ده

د دې میاشتې په پیل کې، د می په 3 کې، د "کوبرنیټس کې د توزیع شوي ډیټا ذخیره کولو مدیریت سیسټم" یو لوی خپور اعلان شو - روک 1.0.0. د یو کال څخه زیات موږ لا دمخه خپور شوی د Rook عمومي کتنه. بیا موږ وغوښتل شو چې د هغه د تجربې په اړه خبرې وکړو په عمل کې کارول - او اوس، د پروژې په تاریخ کې د داسې یو مهم پړاو لپاره په وخت کې، موږ خوشحاله یو چې خپل راټول شوي تاثیرات شریک کړو.

په لنډه توګه، Rook یوه جوړه ده چلونکي د Kubernetes لپاره، کوم چې د ډیټا ذخیره کولو حلونو لکه Ceph، EdgeFS، Minio، Cassandra، CockroachDB د ګمارنې، مدیریت، اتوماتیک بیا رغونې بشپړ کنټرول په غاړه لري.

اوس مهال ترټولو پرمختللی (او یوازینی یو в باثباته مرحله) د حل لاره ده rook-ceph-operator.

تبصره: د Ceph پورې اړوند د Rook 1.0.0 خوشې کولو کې د پام وړ بدلونونو څخه، موږ کولی شو د Ceph Nautilus ملاتړ او د CephFS یا RGW بالټونو لپاره د NFS کارولو وړتیا یادونه وکړو. هغه څه چې د نورو په مینځ کې څرګند دي د بیټا کچې ته د EdgeFS ملاتړ بشپړتیا ده.

نو، پدې مقاله کې موږ:

• راځئ چې دې پوښتنې ته ځواب ووایو چې موږ د کوبرنیټس کلستر کې د سیف ځای پرځای کولو لپاره د روک کارولو کې کومې ګټې ګورو؛
• موږ به په تولید کې د روک کارولو تجربه او تاثیرات شریک کړو؛
• راځئ چې تاسو ته ووایو چې ولې موږ روک ته "هو!" ووایو، او د هغه لپاره زموږ د پلانونو په اړه.

راځئ چې د عمومي مفکورو او تیوري سره پیل وکړو.

"زه د یوې روک څخه ګټه لرم!" (نامعلوم شطرنج لوبغاړی)

د روک یوه اصلي ګټه دا ده چې د ډیټا پلورنځیو سره متقابل عمل د کوبرنیټس میکانیزمونو له لارې ترسره کیږي. دا پدې مانا ده چې تاسو نور اړتیا نلرئ د شیټ څخه کنسول ته د سیف تنظیم کولو لپاره کمانډونه کاپي کړئ.

- ایا تاسو غواړئ CephFS په کلستر کې ځای په ځای کړئ؟ یوازې د YAML فایل ولیکئ!
- څه؟ ایا تاسو هم غواړئ د S3 API سره د اعتراض پلورنځی ځای په ځای کړئ؟ یوازې د دوهم YAML فایل ولیکئ!

Rook د یو عادي آپریټر د ټولو قواعدو سره سم رامینځته شوی. د هغه سره تعامل په کارولو سره پیښیږي CRD (د ګمرک سرچینې تعریفونه)په کوم کې چې موږ د سیف ادارو ځانګړتیاوې بیانوو چې موږ ورته اړتیا لرو (ځکه چې دا یوازینی باثباته تطبیق دی، د ډیفالټ په واسطه دا مقاله به د سیف په اړه وغږیږي، پرته لدې چې په واضح ډول بل ډول وویل شي). د ټاکل شوي پیرامیټونو سره سم، آپریټر به په اوتومات ډول د ترتیب لپاره اړین امرونه اجرا کړي.

راځئ چې د آبجیکٹ پلورنځي رامینځته کولو مثال په کارولو سره توضیحات وګورو ، یا بلکه - 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 او 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

اوس تاسو اړتیا لرئ یو کلستر جوړ کړئ او ځای مشخص کړئ 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"

د 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

برسېره پر دې، اضافي اجزا د مطلوب په توګه تنظیم کیدی شي. د هغوی په اړه نور جزئيات په کې ښودل شوي دي اسناد. د ادارې لپاره، موږ په کلکه د ډشبورډ او اوزار بکس نصبولو وړاندیز کوو.

روک او هکس: ایا روک د هرڅه لپاره کافي دی؟

لکه څنګه چې تاسو لیدلی شئ، د روک پرمختګ په بشپړ ډول روان دی. مګر لاهم ستونزې شتون لري چې موږ ته اجازه نه راکوي په بشپړ ډول د سیف لارښود ترتیب پریږدو:

• د موټر چلوونکی نشته نشي کولی د نصب شوي بلاکونو کارولو په اړه د صادراتو اندازه، کوم چې موږ د څارنې څخه محروموي.
• Flexvolume او CSI نه پوهیږم څنګه د حجمونو اندازه بدل کړئ (لکه څنګه چې د ورته RBD سره مخالف وي)، نو روک د ګټور (او ځینې وختونه جدي اړتیا لري!) وسیلې څخه محروم دی.
• روک لاهم د منظم سیف په څیر انعطاف منونکی ندی. که موږ غواړو د CephFS میټاډاټا لپاره حوض ترتیب کړو چې په SSD کې زیرمه شي، او ډاټا پخپله په HDD کې زیرمه شي، موږ به اړتیا ولرو چې د وسیلو جلا ګروپونه په لاسي ډول په CRUSH نقشو کې ثبت کړو.
• د دې حقیقت سره سره چې rook-ceph-operator باثباته ګڼل کیږي، اوس مهال ځینې ستونزې شتون لري کله چې Ceph له 13 څخه تر 14 نسخه پورې لوړ کړي.

موندنو

"اوس مهال روک له بهرنۍ نړۍ څخه د پیادو لخوا تړل شوی، مګر موږ باور لرو چې یوه ورځ به هغه په ​​لوبه کې پریکړه کونکی رول ولوبوي!" (اقتباس په ځانګړي ډول د دې مقالې لپاره اختراع شوی)

د روک پروژې بې له شکه زموږ زړونه ګټلي دي - موږ باور لرو چې [د دې ټولو ګټو او زیانونو سره] دا یقینا ستاسو د پاملرنې وړ دی.

زموږ راتلونکي پلانونه د Rook-ceph لپاره د ماډل جوړولو لپاره غوړیږي addon-operator، کوم چې به یې زموږ په ډیری کبرنیټ کلسترونو کې حتی ساده او ډیر اسانه کړي.

PS

زموږ په بلاګ کې هم ولولئ:

• «روک - د کبرنیټس لپاره "د ځان خدمت" ډیټا ګودام»
• «د سیف پراساس په کبرنیټس کې د چمتو کولو سره دوامداره ذخیره رامینځته کول»
• «ډیټابیس او کوبرنیټس (بیا کتنه او ویډیو راپور)»
• «د شیل آپریټر معرفي کول: د کوبرنیټس لپاره آپریټرونه رامینځته کول خورا اسانه شوي»
• «د کوبرنیټس لپاره چلونکي: د دولتي غوښتنلیکونو چلولو څرنګوالی".

سرچینه: www.habr.com