ወደ ሩክ ወይም ላለማድረግ - ጥያቄው ነው።

ወደ ሩክ ወይም ላለማድረግ - ጥያቄው ነው።

በዚህ ወር መጀመሪያ ላይ በሜይ 3 "በኩበርኔትስ ውስጥ ለተሰራጨ የውሂብ ማከማቻ አስተዳደር ስርዓት" ዋና መለቀቅ ተገለጸ - Rook 1.0.0. ከአንድ ዓመት በላይ እኛ ቀድሞውኑ የታተመ የሩክ አጠቃላይ እይታ። ከዚያም ስለ ገጠመኙ እንድንናገር ተጠየቅን። በተግባር መጠቀም - እና አሁን፣ በፕሮጀክቱ ታሪክ ውስጥ እንደዚህ ያለ ጉልህ ምዕራፍ ላይ በደረሰ ጊዜ፣ የተጠራቀሙትን ግንዛቤዎቻችንን በማካፈል ደስተኞች ነን።

በአጭሩ ሩክ ስብስብ ነው። አንቀሳቃሾች ለ Kubernetes, እንደ Ceph, EdgeFS, Minio, Cassandra, CockroachDB የመሳሰሉ የውሂብ ማከማቻ መፍትሄዎችን ማሰማራት, ማስተዳደር, በራስ-ሰር መልሶ ማግኘትን ሙሉ በሙሉ ለሚቆጣጠሩት.

በአሁኑ ጊዜ በጣም የዳበረው ​​(እና ብቻ в የተረጋጋ ደረጃ) መፍትሄው ነው ሮክ-ሴፍ-ኦፕሬተር.

አመለከተከሴፍ ጋር በተዛመደ በRook 1.0.0 ልቀት ላይ ከተደረጉት ጉልህ ለውጦች መካከል፣ ለሴፍ ናውቲለስ ድጋፍ እና NFSን ለሴፍኤፍኤስ ወይም RGW ባልዲዎች የመጠቀም ችሎታን ልብ ማለት እንችላለን። ከሌሎች መካከል ጎልቶ የሚታየው የ EdgeFS ድጋፍ ወደ ቅድመ-ይሁንታ ደረጃ መብሰል ነው።

ስለዚህ, በዚህ ጽሑፍ ውስጥ እኛ:

  • ሩክን ተጠቅመን ሴፍ በኩበርኔትስ ክላስተር ውስጥ ለማሰማራት ምን አይነት ጥቅማጥቅሞች እንደምናያቸው ለሚለው ጥያቄ መልስ እንስጥ።
  • ሩክን በምርት ውስጥ ስለመጠቀም ያለንን ልምድ እና ግንዛቤ እናካፍላለን፤
  • ለምን ለሩክ “አዎ!” እንደምንል እና ለእሱ ያለንን እቅድ እንንገራችሁ።

በአጠቃላይ ጽንሰ-ሐሳቦች እና ጽንሰ-ሐሳቦች እንጀምር.

"የአንድ ሮክ ጥቅም አለኝ!" (ያልታወቀ የቼዝ ተጫዋች)

ወደ ሩክ ወይም ላለማድረግ - ጥያቄው ነው።

የሩክ ዋነኛ ጥቅሞች አንዱ ከመረጃ ማከማቻዎች ጋር መስተጋብር የሚከናወነው በኩበርኔትስ ዘዴዎች ነው. ይህ ማለት ከአሁን በኋላ Cephን ከሉህ ወደ ኮንሶል ለማዋቀር ትእዛዞቹን መቅዳት አያስፈልግዎትም ማለት ነው።

- CephFSን በክላስተር ውስጥ ማሰማራት ይፈልጋሉ? የ YAML ፋይል ብቻ ይጻፉ!
- ምንድን? እንዲሁም የነገር ማከማቻን ከS3 API ጋር ማሰማራት ይፈልጋሉ? ልክ ሁለተኛ YAML ፋይል ጻፍ!

ሩክ በተለመደው ኦፕሬተር በሁሉም ደንቦች መሰረት ይፈጠራል. ከእሱ ጋር መስተጋብር የሚከናወነው በመጠቀም ነው 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 }}

በዚህ ሥራ ውስጥ የተዘረዘሩት ሁሉም ድርጊቶች የተከናወኑት በኩበርኔትስ ማዕቀፍ ውስጥ ነው። በ YAML ፋይሎች ውስጥ የተገለጹት መዋቅሮች በ Git ማከማቻ ውስጥ ተከማችተው ብዙ ጊዜ እንደገና ጥቅም ላይ ይውላሉ። ይህንን ለዴቭኦፕስ መሐንዲሶች እና ለሲአይ/ሲዲ አጠቃላይ ሂደት እንደ ትልቅ ፕላስ እናያለን።

ከሮክ እና ራዶስ ጋር ደስተኛ

የCep + 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 ሲጠቀሙ ይህ ችግር በቀላሉ የለም። የመጫን ሂደቱ በራሱ አሽከርካሪዎች በመጠቀም ይከሰታል Flexvolume ወይም በ CSI (አሁንም በቅድመ-ይሁንታ ደረጃ) እና ስለዚህ ሚስጥሮችን አይፈልግም.

ሩክ ብዙ ችግሮችን በራስ ሰር ይፈታል፣ ይህም በአዲስ ፕሮጀክቶች ውስጥ እንድንጠቀምበት ያበረታታናል።

የሩክ ከበባ

የራሳችንን ሙከራዎች እንድናደርግ ሩክ እና ሴፍ በማሰማራት የተግባር ክፍሉን እናጠናቀቅ። ይህን የማይበገር ግንብ ለማውረር ቀላል ለማድረግ ገንቢዎቹ የሄልም ጥቅል አዘጋጅተዋል። እናውርደው፡-

$ 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 ገበታውን በትእዛዙ ይጫኑ፡-

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

የሴፍ ሁኔታን በመፈተሽ ላይ - ለማየት ይጠብቁ 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

በተጨማሪ, ተጨማሪ አካላት እንደፈለጉ ሊዋቀሩ ይችላሉ. ስለእነሱ ተጨማሪ ዝርዝሮች በ ውስጥ ተገልጸዋል ሰነድ. ለአስተዳደር፣ ዳሽቦርዱን እና የመሳሪያ ሳጥኑን እንዲጭኑ አጥብቀን እንመክራለን።

ሮክ እና መንጠቆዎች፡ ሩክ ለሁሉም ነገር በቂ ነው?

እንደምታዩት የሮክ እድገት በከፍተኛ ደረጃ ላይ ነው። ግን አሁንም የሴፍ በእጅ ማዋቀርን ሙሉ በሙሉ ለመተው የማይፈቅዱ ችግሮች አሉ-

  • ሮክ ሹፌር የለም። አለመቻል ወደ ውጭ የሚላኩ መለኪያዎች በተሰቀሉ ብሎኮች አጠቃቀም ላይ ፣ ይህም ክትትልን ያሳጣናል።
  • Flexvolume እና CSI እንዴት እንደሆነ አላውቅም የጥራዞችን መጠን ይቀይሩ (ከተመሳሳይ RBD በተቃራኒ) ፣ ስለዚህ ሩክ ጠቃሚ (እና አንዳንድ ጊዜ በጣም አስፈላጊ ነው!) መሣሪያ ተነፍጎታል።
  • ሩክ አሁንም እንደ መደበኛ ሴፍ ተለዋዋጭ አይደለም። ገንዳውን ለሴፍኤፍኤስ ሜታዳታ በኤስኤስዲ ላይ እንዲከማች እና ውሂቡ ራሱ በኤችዲዲ ላይ እንዲከማች ማዋቀር ከፈለግን በ CRUSH ካርታዎች ውስጥ የተለያዩ የመሳሪያዎችን ቡድን በእጅ መመዝገብ አለብን።
  • ምንም እንኳን ሩክ-ሴፍ-ኦፕሬተር የተረጋጋ ነው ተብሎ ቢታሰብም፣ በአሁኑ ጊዜ ሴፍ ከስሪት 13 ወደ 14 ሲያሻሽል አንዳንድ ችግሮች አሉ።

ግኝቶች

"በአሁኑ ጊዜ ሩክ ከውጪው አለም በፓውንቶች ተዘግታለች ነገርግን አንድ ቀን በጨዋታው ውስጥ ወሳኝ ሚና እንደምትጫወት እናምናለን!" (ጥቅስ በተለይ ለዚህ ጽሑፍ የተፈጠረ)

የሮክ ፕሮጄክት ያለምንም ጥርጥር ልባችንን አሸንፏል - [ከሁሉም ጥቅሞቹ እና ጉዳቶች ጋር] በእርግጠኝነት ለእርስዎ ትኩረት ሊሰጠው እንደሚገባ እናምናለን።

የወደፊት እቅዶቻችን rook-cephን ሞጁል ለማድረግ ይሞቃሉ addon-operator, ይህም በበርካታ የኩበርኔትስ ስብስቦች ውስጥ አጠቃቀሙን የበለጠ ቀላል እና የበለጠ ምቹ ያደርገዋል.

PS

በብሎጋችን ላይ ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ