Kwa Rook au sio kwa Rook - hilo ndilo swali

Kwa Rook au sio kwa Rook - hilo ndilo swali

Mwanzoni mwa mwezi huu, Mei 3, toleo kubwa la "mfumo wa usimamizi wa uhifadhi wa data uliosambazwa huko Kubernetes" ulitangazwa - Rook 1.0.0. Zaidi ya mwaka mmoja uliopita sisi tayari iliyochapishwa Muhtasari wa jumla wa Rook. Kisha tuliulizwa kuzungumza juu ya uzoefu wake kutumia katika mazoezi - na sasa, kwa wakati unaofaa kwa hatua muhimu kama hii katika historia ya mradi, tunafurahi kushiriki hisia zetu zilizokusanywa.

Kwa kifupi, Rook ni seti waendeshaji kwa Kubernetes, ambayo inachukua udhibiti kamili wa uwekaji, usimamizi, uokoaji kiotomatiki wa suluhisho za kuhifadhi data kama vile Ceph, EdgeFS, Minio, Cassandra, CockroachDB.

Kwa sasa iliyoendelea zaidi (na wa pekee Π² imara hatua) suluhisho ni rook-ceph-operator.

Kumbuka: Miongoni mwa mabadiliko makubwa katika toleo la Rook 1.0.0 linalohusiana na Ceph, tunaweza kutambua msaada kwa Ceph Nautilus na uwezo wa kutumia NFS kwa CephFS au ndoo za RGW. Kinachojitokeza kati ya zingine ni kukomaa kwa usaidizi wa EdgeFS hadi kiwango cha beta.

Kwa hiyo, katika makala hii sisi:

  • Hebu tujibu swali kuhusu faida gani tunaona katika kutumia Rook kupeleka Ceph katika kundi la Kubernetes;
  • Tutashiriki uzoefu wetu na maonyesho ya kutumia Rook katika uzalishaji;
  • Hebu tuambie kwa nini tunasema β€œNdiyo!” kwa Rook, na kuhusu mipango yetu kwa ajili yake.

Wacha tuanze na dhana na nadharia ya jumla.

"Nina faida ya Rook mmoja!" (mchezaji chess asiyejulikana)

Kwa Rook au sio kwa Rook - hilo ndilo swali

Moja ya faida kuu za Rook ni kwamba mwingiliano na duka za data hufanywa kupitia mifumo ya Kubernetes. Hii inamaanisha kuwa hauitaji tena kunakili amri ili kusanidi Ceph kutoka kwa laha hadi koni.

Je! unataka kupeleka CephFS kwenye nguzo? Andika tu faili ya YAML!
- Nini? Je! unataka pia kupeleka duka la kitu na S3 API? Andika tu faili ya pili ya YAML!

Rook imeundwa kulingana na sheria zote za operator wa kawaida. Kuingiliana naye hutokea kwa kutumia CRD (Ufafanuzi wa Rasilimali Maalum), ambamo tunaelezea sifa za vyombo vya Ceph tunavyohitaji (kwa kuwa huu ndio utekelezaji pekee thabiti, kwa chaguo-msingi kifungu hiki kitazungumza juu ya Ceph, isipokuwa imeelezwa waziwazi). Kwa mujibu wa vigezo maalum, operator atafanya moja kwa moja amri zinazohitajika kwa usanidi.

Wacha tuangalie maalum kwa kutumia mfano wa kuunda Duka la Kitu, au tuseme - 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 }}

Vigezo vilivyoonyeshwa kwenye uorodheshaji ni vya kawaida kabisa na havihitaji maoni, lakini inafaa kulipa kipaumbele maalum kwa zile zilizotengwa kwa anuwai za templeti.

Mpango wa jumla wa kazi unatokana na ukweli kwamba "tunaagiza" rasilimali kupitia faili ya YAML, ambayo opereta hutekeleza amri zinazohitajika na huturudishia siri "isiyo ya kweli" ambayo tunaweza kufanya kazi nayo zaidi. (tazama hapa chini). Na kutoka kwa vigezo vilivyoorodheshwa hapo juu, amri na jina la siri litaundwa.

Hii ni timu ya aina gani? Wakati wa kuunda mtumiaji kwa uhifadhi wa kitu, opereta wa Rook ndani ya ganda atafanya yafuatayo:

radosgw-admin user create --uid="rook-user" --display-name="{{ .Values.s3.username }}"

Matokeo ya kutekeleza amri hii itakuwa muundo wa JSON:

{
    "user_id": "rook-user",
    "display_name": "{{ .Values.s3.username }}",
    "keys": [
        {
           "user": "rook-user",
           "access_key": "NRWGT19TWMYOB1YDBV1Y",
           "secret_key": "gr1VEGIV7rxcP3xvXDFCo4UDwwl2YoNrmtRlIAty"
        }
    ],
    ...
}

Keys - ni programu gani za siku zijazo zitahitaji kufikia hifadhi ya kitu kupitia API ya S3. Opereta wa Rook huwachagua kwa fadhili na kuziweka katika nafasi ya jina lake kwa njia ya siri iliyo na jina rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

Ili kutumia data kutoka kwa siri hii, ongeza tu kwenye kontena kama anuwai za mazingira. Kama mfano, nitatoa kiolezo cha Ayubu, ambacho tunatengeneza ndoo kiotomatiki kwa kila mazingira ya mtumiaji:

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

Vitendo vyote vilivyoorodheshwa katika Ayubu hii vilifanywa ndani ya mfumo wa Kubernetes. Miundo iliyofafanuliwa katika faili za YAML huhifadhiwa kwenye hazina ya Git na kutumika tena mara nyingi. Tunaona hii kama faida kubwa kwa wahandisi wa DevOps na mchakato wa CI/CD kwa ujumla.

Furahia na Rook na Rados

Kutumia mchanganyiko wa Ceph + RBD huweka vizuizi fulani juu ya uwekaji wa ujazo kwenye maganda.

Hasa, nafasi ya majina lazima iwe na siri ya kufikia Ceph ili programu za hali ya juu zifanye kazi. Ni sawa ikiwa una mazingira 2-3 katika nafasi zao za majina: unaweza kwenda na kunakili siri wewe mwenyewe. Lakini vipi ikiwa kwa kila kipengele mazingira tofauti na nafasi yake ya majina yameundwa kwa watengenezaji?

Tulitatua shida hii wenyewe kwa kutumia shell-operator, ambayo ilinakili siri kiotomatiki kwa nafasi mpya za majina (mfano wa ndoano kama hiyo imeelezewa ndani Makala hii).

#! /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

Walakini, wakati wa kutumia Rook shida hii haipo. Mchakato wa kuweka hutokea kwa kutumia madereva yake kulingana na Sauti ya Flex au CSI (bado katika hatua ya beta) na kwa hivyo hauhitaji siri.

Rook hutatua matatizo mengi kiatomati, ambayo hutuhimiza kuitumia katika miradi mipya.

Kuzingirwa kwa Rook

Wacha tukamilishe sehemu ya vitendo kwa kupeleka Rook na Ceph ili tuweze kufanya majaribio yetu wenyewe. Ili kurahisisha kuvamia mnara huu usioweza kuingizwa, watengenezaji wameandaa kifurushi cha Helm. Hebu tuipakue:

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

Katika faili rook-ceph/values.yaml unaweza kupata mipangilio mingi tofauti. Jambo muhimu zaidi ni kutaja uvumilivu kwa mawakala na utafutaji. Tulielezea kwa undani ni nini utaratibu wa kuchafua/kuvumilia unaweza kutumika Makala hii.

Kwa kifupi, hatutaki ganda la programu ya mteja liwe kwenye nodi sawa na diski za kuhifadhi data. Sababu ni rahisi: kwa njia hii kazi ya mawakala wa Rook haitaathiri programu yenyewe.

Kwa hiyo, fungua faili rook-ceph/values.yaml na mhariri wako unaopenda na ongeza kizuizi kifuatacho mwishoni:

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

Kwa kila nodi iliyohifadhiwa kwa uhifadhi wa data, ongeza doa inayolingana:

$ kubectl taint node ${NODE_NAME} node-role/storage="":NoExecute

Kisha sakinisha chati ya Helm na amri:

$ helm install --namespace ${ROOK_NAMESPACE} ./rook-ceph

Sasa unahitaji kuunda nguzo na kutaja eneo 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"

Kuangalia hali ya Ceph - tarajia kuona 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

Wakati huo huo, wacha tuangalie ikiwa maganda yaliyo na programu ya mteja hayaishii kwenye nodi zilizohifadhiwa kwa Ceph:

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

Zaidi ya hayo, vipengele vya ziada vinaweza kusanidiwa kama unavyotaka. Maelezo zaidi juu yao yameonyeshwa katika nyaraka. Kwa utawala, tunapendekeza sana kusakinisha dashibodi na kisanduku cha zana.

Rook na ndoano: Je, Rook inatosha kwa kila kitu?

Kama unaweza kuona, maendeleo ya Rook yanaendelea kikamilifu. Lakini bado kuna shida ambazo hazituruhusu kuachana kabisa na usanidi wa mwongozo wa Ceph:

  • Hakuna Dereva wa Rook haiwezi metrics ya kuuza nje juu ya matumizi ya vitalu vyema, ambayo inatunyima ufuatiliaji.
  • Flexvolume na CSI sijui jinsi gani badilisha saizi ya juzuu (kinyume na RBD sawa), kwa hivyo Rook ananyimwa zana muhimu (na wakati mwingine inahitajika sana!).
  • Rook bado hawezi kunyumbulika kama Ceph wa kawaida. Ikiwa tunataka kusanidi bwawa la metadata ya CephFS kuhifadhiwa kwenye SSD, na data yenyewe kuhifadhiwa kwenye HDD, tutahitaji kusajili vikundi tofauti vya vifaa katika ramani za CRUSH wenyewe.
  • Licha ya ukweli kwamba rook-ceph-operator inachukuliwa kuwa thabiti, kwa sasa kuna shida kadhaa wakati wa kusasisha Ceph kutoka toleo la 13 hadi 14.

Matokeo

"Kwa sasa Rook amefungiwa kutoka kwa ulimwengu wa nje na pawns, lakini tunaamini kwamba siku moja atachukua jukumu muhimu katika mchezo huo!" (nukuu iliyoundwa mahsusi kwa nakala hii)

Mradi wa Rook bila shaka umeshinda mioyo yetu - tunaamini kwamba [pamoja na faida na hasara zake zote] bila shaka unastahili kuzingatiwa.

Mipango yetu ya siku za usoni inakaribia kutengeneza rook-ceph kuwa moduli ya kiendeshaji cha kuongeza, ambayo itafanya matumizi yake katika vikundi vyetu vingi vya Kubernetes kuwa rahisi na rahisi zaidi.

PS

Soma pia kwenye blogi yetu:

Chanzo: mapenzi.com

Kuongeza maoni