🥇Rook නැද්ද Rook - ඒක තමයි ප්‍රශ්නය

මෙම මස මුලදී, මැයි 3 වන දින, "Kubernetes හි බෙදා හරින ලද දත්ත ගබඩා කිරීම සඳහා කළමනාකරණ පද්ධතියක්" පිළිබඳ ප්රධාන නිකුතුවක් නිවේදනය කරන ලදී - Rook 1.0.0. අපි දැනටමත් වසරකට වැඩි කාලයක් ප්රකාශයට පත් කරන ලදී Rook පිළිබඳ පොදු දළ විශ්ලේෂණය. ඊට පස්සේ එයාගේ අත්දැකීම් ගැන කතා කරන්න කිව්වා ප්රායෝගිකව භාවිතා කරන්න - සහ දැන්, ව්‍යාපෘතියේ ඉතිහාසයේ එවැනි වැදගත් සන්ධිස්ථානයක් සඳහා නියමිත වේලාවට, අපගේ සමුච්චිත හැඟීම් බෙදා ගැනීමට අපි සතුටු වෙමු.

කොටින්ම Rook කියන්නේ සෙට් එකක් ක්රියාකරුවන් Ceph, EdgeFS, Minio, Cassandra, CockroachDB වැනි දත්ත ගබඩා කිරීමේ විසඳුම් යෙදවීම, කළමනාකරණය, ස්වයංක්‍රීයව ප්‍රතිසාධනය කිරීම සම්පූර්ණයෙන් පාලනය කරන Kubernetes සඳහා.

මේ මොහොතේ වඩාත්ම සංවර්ධිත (සහ එකම එක в ස්ථාවර අදියර) විසඳුම වේ rook-ceph-operator.

අදහස් දැක්වීම්: Ceph සම්බන්ධ Rook 1.0.0 නිකුතුවේ සැලකිය යුතු වෙනස්කම් අතර, Ceph Nautilus සඳහා සහය දැක්වීම සහ CephFS හෝ RGW බාල්දි සඳහා NFS භාවිතා කිරීමේ හැකියාව අපට සටහන් කළ හැක. අනෙක් අය අතර කැපී පෙනෙන දෙය නම් බීටා මට්ටමට EdgeFS සහාය පරිණත වීමයි.

එබැවින්, මෙම ලිපියෙන් අපි:

Kubernetes පොකුරක් තුළ Ceph යෙදවීමට Rook භාවිතා කිරීමේදී අප දකින වාසි මොනවාද යන ප්‍රශ්නයට පිළිතුරු දෙමු;
නිෂ්පාදනයේදී රූක් භාවිතා කිරීම පිළිබඳ අපගේ අත්දැකීම් සහ හැඟීම් අපි බෙදා ගන්නෙමු;
අපි රූක්ට “ඔව්!” කියන්න හේතුව සහ ඔහු සඳහා අපගේ සැලසුම් ගැන අපි ඔබට කියමු.

අපි සාමාන්‍ය සංකල්ප සහ න්‍යායෙන් පටන් ගනිමු.

"මට එක Rook එකක වාසියක් තියෙනවා!" (නොදන්නා චෙස් ක්‍රීඩකයා)

Rook හි එක් ප්‍රධාන වාසියක් වන්නේ දත්ත ගබඩා සමඟ අන්තර්ක්‍රියා සිදු කරනු ලබන්නේ 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 ගොනුවක් හරහා සම්පත් “ඇණවුම්” කරන අතර, ඒ සඳහා ක්‍රියාකරු අවශ්‍ය විධාන ක්‍රියාත්මක කරන අතර අපට තවදුරටත් වැඩ කළ හැකි “එතරම් සැබෑ නොවන” රහසක් අපට ලබා දෙයි. (පහත බලන්න). ඉහත ලැයිස්තුගත කර ඇති විචල්‍ය වලින්, විධානය සහ රහස් නම සම්පාදනය කෙරේ.

මේ මොන වගේ කණ්ඩායමක්ද? වස්තු ගබඩා කිරීම සඳහා පරිශීලකයෙකු නිර්මාණය කරන විට, පොඩ් එක තුළ ඇති 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-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 }}

මෙම කාර්යයේ ලැයිස්තුගත කර ඇති සියලුම ක්‍රියා Kubernetes රාමුව තුළ සිදු කරන ලදී. YAML ගොනු වල විස්තර කර ඇති ව්‍යුහයන් Git ගබඩාවක ගබඩා කර බොහෝ වාරයක් නැවත භාවිතා කරයි. DevOps ඉංජිනේරුවන්ට සහ සමස්තයක් ලෙස CI/CD ක්‍රියාවලිය සඳහා මෙය විශාල ප්ලස් එකක් ලෙස අපි දකිමු.

Rook සහ Rados ගැන සතුටුයි

Ceph + RBD සංයෝජනය භාවිතා කිරීමෙන් කරල් වලට පරිමාවන් සවි කිරීම සඳහා යම් සීමාවන් පනවා ඇත.

විශේෂයෙන්ම, ප්‍රකාශිත යෙදුම් ක්‍රියාත්මක වීමට නම්, Ceph වෙත පිවිසීමේ රහසක් නාම අවකාශයේ අඩංගු විය යුතුය. ඔබට ඔවුන්ගේ නාම අවකාශයේ පරිසරයන් 2-3ක් තිබේ නම් කමක් නැත: ඔබට ගොස් රහස අතින් පිටපත් කළ හැක. නමුත් එක් එක් විශේෂාංගය සඳහා සංවර්ධකයින් සඳහා තමන්ගේම නාම අවකාශයක් සහිත වෙනම පරිසරයක් නිර්මාණය කරන්නේ නම් කුමක් කළ යුතුද?

අපි මෙම ගැටළුව අප විසින්ම භාවිතා කර විසඳා ගත්තෙමු shell-operator, නව නාම අවකාශ වෙත රහස් ස්වයංක්‍රීයව පිටපත් කරන ලදී (එවැනි කොක්කක උදාහරණයක් විස්තර කෙරේ මේ ලිපිය කියවන්න).

#! /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 (තවමත් බීටා අවධියේ ඇත) එබැවින් රහස් අවශ්‍ය නොවේ.

Rook ස්වයංක්‍රීයව බොහෝ ගැටලු විසඳයි, එය නව ව්‍යාපෘති සඳහා එය භාවිතා කිරීමට අපව දිරිමත් කරයි.

රූක් වටලෑම

රූක් සහ සීෆ් යොදවා ප්‍රායෝගික කොටස සම්පූර්ණ කරමු එවිට අපට අපගේම අත්හදා බැලීම් කළ හැකිය. මෙම අපරාජිත කුළුණට පහර දීම පහසු කිරීම සඳහා, සංවර්ධකයින් හෙල්ම් පැකේජයක් සකස් කර ඇත. අපි එය බාගත කරමු:

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

ගොනුවේ rook-ceph/values.yaml ඔබට විවිධ සැකසුම් සොයා ගත හැක. වැදගත්ම දෙය නම් නියෝජිතයින් සහ සෙවීම සඳහා ඉවසීම නියම කිරීමයි. අපවිත්‍ර/ඉවසීමේ යාන්ත්‍රණය භාවිතා කළ හැක්කේ කුමක් සඳහාද යන්න අපි විස්තරාත්මකව විස්තර කළෙමු මේ ලිපිය කියවන්න.

කෙටියෙන් කිවහොත්, අපට සේවාදායක යෙදුම් පොඩ් දත්ත ගබඩා තැටි මෙන් එකම නෝඩ් මත පිහිටා තිබීම අවශ්‍ය නොවේ. හේතුව සරලයි: මේ ආකාරයෙන් Rook නියෝජිතයින්ගේ කාර්යය යෙදුමට බලපාන්නේ නැත.

ඉතින්, ගොනුව විවෘත කරන්න 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

තවද, අතිරේක සංරචක අවශ්ය පරිදි වින්යාසගත කළ හැක. ඔවුන් පිළිබඳ වැඩි විස්තර එහි දක්වා ඇත ලියකියවිලි. පරිපාලනය සඳහා, උපකරණ පුවරුව සහ මෙවලම් පෙට්ටිය ස්ථාපනය කිරීම අපි තරයේ නිර්දේශ කරමු.

Rook සහ කොකු: Rook සියල්ල සඳහා ප්රමාණවත්ද?

ඔබට පෙනෙන පරිදි, රූක්ගේ සංවර්ධනය වේගවත් වෙමින් පවතී. නමුත් Ceph හි අතින් වින්‍යාසය සම්පූර්ණයෙන්ම අත්හැරීමට අපට ඉඩ නොදෙන ගැටළු තවමත් පවතී:

Rook Driver නැත බැහැ සවිකර ඇති කුට්ටි භාවිතය පිළිබඳ ප්‍රමිතික අපනයනය කිරීම, එය අපට අධීක්ෂණය අහිමි කරයි.
Flexvolume සහ CSI කොහොමද දන්නේ නැහැ වෙළුම්වල ප්‍රමාණය වෙනස් කරන්න (එකම RBD වලට ප්‍රතිවිරුද්ධව), එබැවින් Rook හට ප්‍රයෝජනවත් (සහ සමහර විට විවේචනාත්මකව අවශ්‍ය වේ!) මෙවලමක් අහිමි වේ.
Rook තවමත් සාමාන්‍ය Ceph තරම් නම්‍යශීලී නොවේ. අපට CephFS පාර-දත්ත SSD මත ගබඩා කිරීම සඳහා සංචිතය වින්‍යාස කිරීමට අවශ්‍ය නම් සහ දත්තම HDD මත ගබඩා කිරීමට නම්, අපට CRUSH සිතියම් තුළ වෙනම උපාංග කණ්ඩායම් ලියාපදිංචි කිරීමට අවශ්‍ය වනු ඇත.
Rook-ceph-operator ස්ථායී ලෙස සලකනු ලැබුවද, Ceph 13 සිට 14 දක්වා යාවත්කාලීන කිරීමේදී ගැටළු කිහිපයක් තිබේ.

සොයා ගැනීම්

“මේ වන විට රූක් උකස් විසින් බාහිර ලෝකයෙන් වසා දමා ඇත, නමුත් යම් දිනෙක ඇය ක්‍රීඩාවේ තීරණාත්මක කාර්යභාරයක් ඉටු කරනු ඇතැයි අපි විශ්වාස කරමු!” (මෙම ලිපිය සඳහා විශේෂයෙන් නිර්මාණය කරන ලද උපුටා දැක්වීම)

රූක් ව්‍යාපෘතිය නිසැකවම අපගේ හදවත් දිනා ඇත - [එහි සියලු වාසි සහ අවාසි සමඟ] එය අනිවාර්යයෙන්ම ඔබේ අවධානයට ලක්විය යුතු බව අපි විශ්වාස කරමු.

අපගේ අනාගත සැලසුම් rook-ceph සඳහා මොඩියුලයක් බවට පත් කරයි addon-operator, එය අපගේ බොහෝ Kubernetes පොකුරු තුළ එහි භාවිතය වඩාත් සරල සහ පහසු කරනු ඇත.

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

මූලාශ්රය: www.habr.com

Rook කිරීමට හෝ Rook කිරීමට - එය ප්රශ්නයයි

"මට එක Rook එකක වාසියක් තියෙනවා!" (නොදන්නා චෙස් ක්‍රීඩකයා)

Rook සහ Rados ගැන සතුටුයි

රූක් වටලෑම

Rook සහ කොකු: Rook සියල්ල සඳහා ප්රමාණවත්ද?

සොයා ගැනීම්

ප්රාදේශීය සභා

අදහස් එක් කරන්න

Rook කිරීමට හෝ Rook කිරීමට - එය ප්රශ්නයයි

"මට එක Rook එකක වාසියක් තියෙනවා!" (නොදන්නා චෙස් ක්‍රීඩකයා)

Rook සහ Rados ගැන සතුටුයි

රූක් වටලෑම

Rook සහ කොකු: Rook සියල්ල සඳහා ප්රමාණවත්ද?

සොයා ගැනීම්

ප්රාදේශීය සභා

අදහස් එක් කරන්න ඊ-මේල් මගින් පිලිතුරු දෙන්න අවලංගු

අදහස් එක් කරන්න