Rook သို့မဟုတ် Rook သို့မဟုတျ - အဲဒါက မေးစရာပါ။

ယခုလအစတွင်၊ မေလ 3 ရက်နေ့တွင် Kubernetes တွင်ဖြန့်ဝေထားသောဒေတာသိုလှောင်မှုဆိုင်ရာစီမံခန့်ခွဲမှုစနစ်၏အဓိကထုတ်ဝေမှုကိုကြေငြာခဲ့သည် - Rook 1.0.0. လွန်ခဲ့တဲ့ တစ်နှစ်ကျော်လောက်က ငါတို့ဖြစ်နေပြီ။ ထုတ်ဝေခဲ့သည်။ Rook ၏ ယေဘုယျ ခြုံငုံသုံးသပ်ချက်။ ထို့နောက် သူ့အတွေ့အကြုံကို ပြောပြခိုင်းသည်။ လက်တွေ့အသုံးပြုပါ။ — ယခု၊ ပရောဂျက်၏သမိုင်းတွင် ဤမျှထူးခြားသောမှတ်တိုင်တစ်ခုအတွက် အချိန်မီတွင်၊ ကျွန်ုပ်တို့၏စုဆောင်းထားသော အထင်အမြင်များကို မျှဝေရန် ပျော်ရွှင်ပါသည်။

အတိုချုပ်ပြောရလျှင် Rook သည် set တစ်ခုဖြစ်သည်။ အော်ပရေတာများ ဖြန့်ကျက်မှု၊ စီမံခန့်ခွဲမှု၊ Ceph၊ EdgeFS၊ Minio၊ Cassandra၊ CockroachDB ကဲ့သို့သော ဒေတာသိုလှောင်မှုဖြေရှင်းချက်များအား အလိုအလျောက်ပြန်လည်ရယူသည့် အပြည့်အဝထိန်းချုပ်နိုင်သည့် Kubernetes အတွက်။

ယခုအချိန်တွင် အတိုးတက်ဆုံး (နှင့် တစ်ခုတည်း в တည်ငြိမ်သည်။ အဆင့်) ဖြေရှင်းချက် rook-ceph-operator.

ပွောဆိုCeph နှင့်ဆက်စပ်သော Rook 1.0.0 ထုတ်ဝေမှုတွင် သိသာထင်ရှားသောပြောင်းလဲမှုများထဲတွင် Ceph Nautilus အတွက် အထောက်အပံ့နှင့် CephFS သို့မဟုတ် RGW ပုံးများအတွက် NFS အသုံးပြုနိုင်စွမ်းကို ကျွန်ုပ်တို့ မှတ်သားနိုင်ပါသည်။ အခြားသူများကြားတွင် ထူးခြားချက်မှာ EdgeFS ပံ့ပိုးမှု၏ ရင့်ကျက်မှုသည် beta အဆင့်အထိဖြစ်သည်။

ထို့ကြောင့်၊ ဤဆောင်းပါး၌ကျွန်ုပ်တို့သည်:

• Kubernetes အစုအဝေးတွင် Ceph ကိုအသုံးပြုရန် Rook ကိုအသုံးပြုခြင်းတွင် ကျွန်ုပ်တို့တွေ့မြင်ရသည့် အကျိုးကျေးဇူးများအကြောင်း မေးခွန်းကို ဖြေကြပါစို့။
• ကျွန်ုပ်တို့သည် ထုတ်လုပ်ရေးတွင် Rook ကိုအသုံးပြုခြင်း၏အတွေ့အကြုံနှင့် အထင်အမြင်များကို မျှဝေပါမည်။
• Rook ကို ဘာကြောင့် “Yes!” လို့ပြောရတာနဲ့ သူ့အတွက် အစီအစဉ်တွေအကြောင်း ပြောပြပါရစေ။

ယေဘုယျသဘောတရားများနှင့် သီအိုရီများဖြင့် စတင်ကြပါစို့။

"ငါ့မှာ Rook တစ်ယောက်ရဲ့ အားသာချက်ရှိတယ်!" (အမည်မသိ စစ်တုရင်ကစားသမား)

Rook ၏အဓိကအားသာချက်များထဲမှတစ်ခုမှာ Kubernetes ယန္တရားများမှတဆင့်ဒေတာစတိုးဆိုင်များနှင့်အပြန်အလှန်အပြန်အလှန်လုပ်ဆောင်ခြင်းဖြစ်သည်။ ဆိုလိုသည်မှာ စာရွက်မှ Ceph ကို configure လုပ်ရန် command များကို ကူးယူရန် မလိုအပ်တော့ပါ။

— သင် CephFS ကို အစုအဝေးတစ်ခုတွင် အသုံးပြုလိုပါသလား။ YAML ဖိုင်တစ်ခုရေးပါ။
- ဘာလဲ? S3 API ဖြင့် အရာဝတ္ထုစတိုးတစ်ခုကိုလည်း အသုံးချလိုပါသလား။ ဒုတိယ YAML ဖိုင်တစ်ခုရေးပါ။

Rook ကို ပုံမှန်အော်ပရေတာတစ်ခု၏ စည်းမျဉ်းများအားလုံးအရ ဖန်တီးထားသည်။ သူနဲ့ အပြန်အလှန် ဆက်ဆံမှု တွေ ကို သုံးပြီး ဖြစ်ပေါ် လာပါတယ်။ CRD (စိတ်ကြိုက်အရင်းအမြစ် အဓိပ္ပါယ်ဖွင့်ဆိုချက်များ)ကျွန်ုပ်တို့လိုအပ်သော Ceph entities များ၏ဝိသေသလက္ခဏာများကိုဖော်ပြသည်။ (၎င်းသည် တစ်ခုတည်းသော တည်ငြိမ်သော အကောင်အထည်ဖော်မှုဖြစ်သောကြောင့်၊ ပုံမှန်အားဖြင့် ဤဆောင်းပါးသည် 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 }}

စာရင်းတွင်ဖော်ပြထားသော ကန့်သတ်ဘောင်များသည် အတော်လေး စံထားပြီး မှတ်ချက်များ မလိုအပ်သော်လည်း template variable များအတွက် ခွဲဝေချထားပေးသူများကို အထူးဂရုပြုသင့်ပါသည်။

အလုပ်၏ ယေဘူယျအစီအစဥ်သည် YAML ဖိုင်တစ်ခုမှတစ်ဆင့် ကျွန်ုပ်တို့၏အရင်းအမြစ်များကို "မှာယူသည်" ဟူသောအချက်ကြောင့်၊ အော်ပရေတာသည် လိုအပ်သောအမိန့်များကိုလုပ်ဆောင်ပြီး ကျွန်ုပ်တို့ထပ်မံလုပ်ဆောင်နိုင်သည့် "တကယ်မဟုတ်သော" လျှို့ဝှက်ချက်ကို ပြန်ပေးသည့်အချက်ကြောင့်ဖြစ်သည်။ (အောက်တွင်ကြည့်ပါ). အထက်တွင်ဖော်ပြထားသော ကိန်းရှင်များမှ၊ အမိန့်နှင့် လျှို့ဝှက်အမည်ကို ပြုစုမည်ဖြစ်သည်။

ဒါက ဘယ်လိုအဖွဲ့လဲ။ အရာဝတ္ထုသိုလှောင်မှုအတွက် အသုံးပြုသူတစ်ဦးကို ဖန်တီးသောအခါ၊ pod အတွင်းရှိ Rook အော်ပရေတာသည် အောက်ပါတို့ကို လုပ်ဆောင်လိမ့်မည်-

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

ဤလျှို့ဝှက်ချက်မှ ဒေတာကို အသုံးပြုရန်၊ ၎င်းကို ကွန်တိန်နာတွင် ပတ်၀န်းကျင် ပြောင်းလဲနိုင်သော ကိန်းရှင်များအဖြစ် ထည့်ပါ။ ဥပမာအနေဖြင့်၊ အသုံးပြုသူပတ်ဝန်းကျင်တစ်ခုစီအတွက် ကျွန်ုပ်တို့ အလိုအလျောက်ပုံးများဖန်တီးပေးသည့် Job အတွက် နမူနာပုံစံတစ်ခုကို ပေးပါမည်။

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

ဤ Job တွင်ဖော်ပြထားသော လုပ်ဆောင်ချက်များအားလုံးကို Kubernetes ၏ဘောင်အတွင်း လုပ်ဆောင်ခဲ့ပါသည်။ YAML ဖိုင်များတွင် ဖော်ပြထားသော ဖွဲ့စည်းပုံများကို Git repository တွင် သိမ်းဆည်းထားပြီး အကြိမ်များစွာ ပြန်လည်အသုံးပြုနိုင်ပါသည်။ ၎င်းကို DevOps အင်ဂျင်နီယာများနှင့် CI/CD လုပ်ငန်းစဉ်တစ်ခုလုံးအတွက် ကြီးမားသော အားသာချက်အဖြစ် ကျွန်ုပ်တို့မြင်သည်။

Rook နှင့် Rados တို့နှင့်အတူ ပျော်ရွှင်ပါစေ။

Ceph + RBD ပေါင်းစပ်အသုံးပြုခြင်းဖြင့် pods များသို့ volumes များတပ်ဆင်ခြင်းအပေါ်အချို့သောကန့်သတ်ချက်များချမှတ်သည်။

အထူးသဖြင့်၊ ပြည်နယ်အလိုက် အပလီကေးရှင်းများ လုပ်ဆောင်နိုင်စေရန်အတွက် Namespace တွင် Ceph ကို ဝင်ရောက်ခြင်းအတွက် လျှို့ဝှက်ချက်တစ်ခု ပါရှိရပါမည်။ သင့်တွင် ၎င်းတို့၏ အမည်နေရာများအတွင်း ပတ်ဝန်းကျင် 2-3 ခု ရှိပါက အဆင်ပြေပါသည်- သင်သည် လျှို့ဝှက်ချက်ကို ကိုယ်တိုင်သွားပြီး ကူးယူနိုင်ပါသည်။ သို့သော် အင်္ဂါရပ်တစ်ခုစီအတွက် ၎င်း၏ကိုယ်ပိုင် namespace ပါသည့် သီးခြားပတ်ဝန်းကျင်တစ်ခုကို ဆော့ဖ်ဝဲရေးသားသူများအတွက် ဖန်တီးထားလျှင်ကော။

ဒီပြဿနာကို ကျွန်တော်တို့ကိုယ်တိုင် ဖြေရှင်းခဲ့ပါတယ်။ shell-အော်ပရေတာလျှို့ဝှက်ချက်များကို namespace အသစ်များသို့ အလိုအလျောက်ကူးယူပေးသော (ထိုကဲ့သို့သောချိတ်တစ်ခု၏ ဥပမာကို တွင်ဖော်ပြထားပါသည်။ ဤဆောင်းပါးတွင်).

#! /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 ကိုအသုံးပြုသောအခါဤပြဿနာသည်ရိုးရှင်းစွာမရှိပါ။ အဆိုပါ mounting လုပ်ငန်းစဉ်အပေါ်အခြေခံပြီး၎င်း၏ကိုယ်ပိုင် drivers တွေကို အသုံးပြု Flexvolume သို့မဟုတ် CSI (ဘီတာအဆင့်တွင်ရှိနေသေးသည်) ထို့ကြောင့် လျှို့ဝှက်ချက်မလိုအပ်ပါ။

Rook သည် ပြဿနာများစွာကို အလိုအလျောက်ဖြေရှင်းပေးသည်၊ ၎င်းသည် ပရောဂျက်အသစ်များတွင် ၎င်းကိုအသုံးပြုရန် ကျွန်ုပ်တို့အားပေးသည်။

Rook ကိုဝိုင်းရံထားသည်။

ကျွန်ုပ်တို့၏ကိုယ်ပိုင်စမ်းသပ်မှုများကို ပြုလုပ်နိုင်စေရန် Rook နှင့် Ceph ကိုအသုံးပြုခြင်းဖြင့် လက်တွေ့အပိုင်းကို ပြီးမြောက်ကြပါစို့။ ဤ impregnable မျှော်စင်ကို ဝင်ရောက်ရန် လွယ်ကူစေရန်အတွက် developer များသည် Helm package ကို ပြင်ဆင်ထားပါသည်။ ဒေါင်းလုဒ်လုပ်ကြရအောင်။

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

ဖိုင်ထဲမှာ rook-ceph/values.yaml မတူညီသော ဆက်တင်များစွာကို သင်တွေ့နိုင်သည်။ အရေးကြီးဆုံးအချက်မှာ အေးဂျင့်များအတွက် သည်းခံခွင့်လွှတ်မှုနှင့် ရှာဖွေမှုကို သတ်မှတ်ရန်ဖြစ်သည်။ အာသဝေါတရား/သည်းခံခြင်းယန္တရားတွင် မည်သည့်အရာအတွက် အသုံးပြုနိုင်ကြောင်း အသေးစိတ်ဖော်ပြထားပါသည်။ ဤဆောင်းပါးတွင်.

တိုတိုပြောရရင်၊ client application pods တွေကို data storage disks တွေလို တူညီတဲ့ node တွေမှာ မထားစေချင်ပါဘူး။ အကြောင်းပြချက်မှာ ရိုးရှင်းသည်- ဤနည်းဖြင့် Rook အေးဂျင့်များ၏ အလုပ်သည် အက်ပ်လီကေးရှင်းကို မထိခိုက်စေပါ။

ဒါဆို ဖိုင်ကိုဖွင့်လိုက်ပါ။ rook-ceph/values.yaml သင်အကြိုက်ဆုံးတည်းဖြတ်သူနှင့်အတူ အဆုံးတွင် အောက်ပါဘလောက်ကို ထည့်ပါ။

discover:
  toleration: NoExecute
  tolerationKey: node-role/storage
agent:
  toleration: NoExecute
  tolerationKey: node-role/storage
  mountSecurityMode: Any

ဒေတာသိုလှောင်မှုအတွက် သီးသန့်ခွဲထားသော node တစ်ခုစီအတွက် သက်ဆိုင်ရာ ညစ်ညမ်းမှုကို ထည့်ပါ-

$ 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"

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

တစ်ချိန်တည်းမှာပင်၊ client အပလီကေးရှင်းပါရှိသော pods များသည် Ceph အတွက် သီးသန့်ထားသော node များပေါ်တွင် အကျုံးမဝင်ကြောင်း စစ်ဆေးကြည့်ကြပါစို့။

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

ထို့အပြင်၊ နောက်ထပ်အစိတ်အပိုင်းများကို အလိုရှိသောအတိုင်း ပြင်ဆင်သတ်မှတ်နိုင်သည်။ ၎င်းတို့နှင့်ပတ်သက်သော အသေးစိတ်အချက်အလက်များကို အောက်တွင်ဖော်ပြထားပါသည်။ စာရွက်စာတမ်း. စီမံခန့်ခွဲရန်အတွက်၊ ကျွန်ုပ်တို့သည် ဒက်ရှ်ဘုတ်နှင့် ကိရိယာပုံးကို ထည့်သွင်းရန် ပြင်းပြင်းထန်ထန် အကြံပြုထားသည်။

Rook နှင့် ချိတ်- Rook သည် အရာအားလုံးအတွက် လုံလောက်ပါသလား။

သင်တွေ့မြင်ရသည့်အတိုင်း Rook ၏တိုးတက်မှုသည် အပြည့်အ၀ရှိနေပါသည်။ သို့သော် Ceph ၏ manual configuration ကို လုံးလုံးလျားလျား စွန့်လွှတ်ရန် ခွင့်မပြုသော ပြဿနာများ ရှိပါသေးသည်။

• Rook Driver မရှိပါ။ မရဘူး ကျွန်ုပ်တို့ကို စောင့်ကြည့်ခြင်းမှ ကင်းလွတ်စေမည့် တပ်ဆင်ထားသော လုပ်ကွက်များအသုံးပြုမှုအပေါ် ပို့ကုန်မက်ထရစ်များ။
• Flexvolume နှင့် CSI ဘယ်လိုလဲမသိဘူး။ Volume များ၏ အရွယ်အစားကို ပြောင်းလဲခြင်း (တူညီသော RBD နှင့် ဆန့်ကျင်ဘက်) ထို့ကြောင့် Rook သည် အသုံးဝင်သော (နှင့် တစ်ခါတစ်ရံတွင် အလွန်လိုအပ်သော) တူးလ်တစ်ခုမှ ဆုံးရှုံးသွားပါသည်။
• Rook သည် ပုံမှန် Ceph လောက် မပျော့ပြောင်းသေးပါ။ အကယ်၍ ကျွန်ုပ်တို့သည် SSD တွင် သိမ်းဆည်းရန် CephFS မက်တာဒေတာအတွက် ရေကူးကန်ကို ပြင်ဆင်သတ်မှတ်လိုပါက၊ HDD တွင် သိမ်းဆည်းထားရမည့် ဒေတာများကို CRUSH မြေပုံများတွင် လူကိုယ်တိုင် စာရင်းသွင်းရန် လိုအပ်ပါသည်။
• rook-ceph-operator သည် တည်ငြိမ်သည်ဟု ယူဆသော်လည်း၊ Ceph ကို ဗားရှင်း 13 မှ 14 သို့ အဆင့်မြှင့်တင်သည့်အခါတွင် ပြဿနာအချို့ရှိပါသည်။

တွေ့ရှိချက်များ

"ယခု Rook သည် ပြင်ပကမ္ဘာမှ အပေါင်များဖြင့် ပိတ်ထားသော်လည်း တစ်နေ့နေ့တွင် သူမသည် ဂိမ်းတွင် အဆုံးအဖြတ်အခန်းကဏ္ဍမှ ပါဝင်လာမည်ဟု ကျွန်ုပ်တို့ ယုံကြည်ပါသည်။" (ဤဆောင်းပါးအတွက် အထူးတီထွင်ထားသော ကိုးကားချက်)

Rook ပရောဂျက်သည် ကျွန်ုပ်တို့၏ နှလုံးသားများကို သံသယဝင်စေခဲ့သည် - [၎င်း၏ ကောင်းကျိုးဆိုးကျိုးများနှင့်အတူ] ၎င်းသည် သင့်အာရုံစူးစိုက်မှုကို သေချာပေါက် ထိုက်တန်သည်ဟု ကျွန်ုပ်တို့ယုံကြည်ပါသည်။

ကျွန်ုပ်တို့၏အနာဂတ်အစီအစဉ်များသည် rook-ceph အတွက် module တစ်ခုပြုလုပ်ရန် အကျုံးဝင်ပါသည်။ addon-အော်ပရေတာကျွန်ုပ်တို့၏မြောက်မြားစွာသော Kubernetes အစုအဝေးများတွင် ၎င်းကိုအသုံးပြုခြင်းက ပိုမိုရိုးရှင်းပြီး ပိုမိုအဆင်ပြေစေမည်ဖြစ်သည်။

PS

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «Rook - Kubernetes အတွက် "ကိုယ်တိုင်ဝန်ဆောင်မှု" ဒေတာဂိုဒေါင်";
• «Ceph ကိုအခြေခံ၍ Kubernetes တွင် စီမံဆောင်ရွက်ပေးခြင်းဖြင့် အမြဲမပြတ်သိုလှောင်မှုကို ဖန်တီးခြင်း။";
• «ဒေတာဘေ့စ်များနှင့် Kubernetes (ပြန်လည်သုံးသပ်ခြင်းနှင့် ဗီဒီယိုအစီရင်ခံစာ)";
• «shell-operator ကို မိတ်ဆက်ပေးခြင်း- Kubernetes အတွက် အော်ပရေတာများ ဖန်တီးခြင်းသည် ပိုမိုလွယ်ကူလာပါသည်။";
• «Kubernetes အတွက် အော်ပရေတာများ- နိုင်ငံပိုင်အပလီကေးရှင်းများကို မည်သို့လုပ်ဆောင်ရမည်နည်း။"။

source: www.habr.com