Рукпу же жокпу - бул суроо

Ушул айдын башында, 3-майда, "Кубернетесте бөлүштүрүлгөн маалыматтарды сактоону башкаруу тутумунун" негизги релизи жарыяланды - Rook 1.0.0. Бир жылдан ашык убакыт мурун биз жарыяланган Rook жалпы сереп. Андан кийин анын башынан өткөн окуя тууралуу айтып берүүнү суранышты практикада колдонуу — эми, долбоордун тарыхындагы ушундай орчундуу этапка туура келгенде, биз топтогон таасирлерибиз менен бөлүшүүгө кубанычтабыз.

Кыскача айтканда, Rook топтому болуп саналат операторлор Ceph, EdgeFS, Minio, Cassandra, CockroachDB сыяктуу маалыматтарды сактоо чечимдерин жайгаштырууну, башкарууну, автоматтык түрдө калыбына келтирүүнү толук көзөмөлдөгөн Kubernetes үчүн.

Азыркы учурда эң өнүккөн (жана гана в туруктуу этап) чечим болуп саналат rook-ceph-оператор.

пикир: Ceph менен байланышкан Rook 1.0.0 релизиндеги олуттуу өзгөрүүлөрдүн арасында биз Ceph Nautilus колдоосун жана CephFS же RGW чакалары үчүн NFSди колдонуу мүмкүнчүлүгүн белгилей алабыз. Башкалардын арасында өзгөчөлөнүп турган нерсе - EdgeFS колдоосунун бета деңгээлине жетүүсү.

Ошентип, бул макалада биз:

• Келгиле, Kubernetes кластеринде Cephди жайгаштыруу үчүн Рукту колдонууда кандай артыкчылыктарды көрөбүз деген суроого жооп берели;
• Биз өндүрүштө Rook колдонуу тажрыйбасы жана таасирлери менен бөлүшөбүз;
• Келгиле, Рукке эмне үчүн “Ооба!” деп айтканыбызды жана ага карата пландарыбызды айтып берели.

Келгиле, жалпы түшүнүктөр жана теория менен баштайлы.

"Менин бир рооктун артыкчылыгы бар!" (белгисиз шахматчы)

Rook'тун негизги артыкчылыктарынын бири - маалымат дүкөндөрү менен өз ара аракеттенүү Kubernetes механизмдери аркылуу ишке ашат. Бул Cephти конфигурациялоо үчүн буйруктарды барактан консолго көчүрүүнүн кереги жок дегенди билдирет.

— Сиз CephFSди кластерде жайгаштыргыңыз келеби? Жөн гана YAML файлын жазыңыз!
- Эмне? Сиз дагы S3 API менен объект дүкөнүн жайгаштыргыңыз келеби? Жөн эле экинчи YAML файлын жазыңыз!

Rook типтүү оператордун бардык эрежелерине ылайык түзүлгөн. Аны менен өз ара аракеттенүү аркылуу пайда болот CRD (Custom Resource Definitions), анда биз керек болгон 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 оператору аларды боорукердик менен тандап, аты менен сыр түрүндө өзүнүн аттар мейкиндигине коёт. 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 процесси үчүн чоң плюс катары көрөбүз.

Рук жана Радос менен бактылуу

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

Бирок, Rook колдонууда бул маселе жөн эле жок. монтаждоо жараяны негизделген өзүнүн драйверлерин колдонуу менен пайда болот Flexvolume же CSI (дагы бета стадиясында) жана ошондуктан сырларды талап кылбайт.

Rook көптөгөн маселелерди автоматтык түрдө чечет, бул бизди жаңы долбоорлордо колдонууга үндөйт.

Роктун курчоосу

Келгиле, практикалык бөлүгүн Rook and Cephди колдонуу менен бүтүрөлү, ошондо биз өзүбүздүн эксперименттерибизди жасай алабыз. Бул кол жетпес мунарага чабуул жасоону жеңилдетүү үчүн, иштеп чыгуучулар Helm пакетин даярдашкан. Аны жүктөп алалы:

$ 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 диаграммасын буйрук менен орнотуңуз:

$ 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ден айырмаланып), Рук пайдалуу (жана кээде өтө зарыл!) куралдан ажырайт.
• Рук дагы эле кадимки Ceph сыяктуу ийкемдүү эмес. Эгер биз CephFS метаберилиштери үчүн бассейнди SSDде сакталышы үчүн конфигурациялоону кааласак, ал эми маалыматтардын өзү HDDде сакталышы үчүн, CRUSH карталарында түзмөктөрдүн өзүнчө топторун кол менен катташыбыз керек болот.
• Rook-ceph-оператору туруктуу деп эсептелгенине карабастан, учурда Cephти 13-14-версияга көтөрүүдө кээ бир көйгөйлөр бар.

табылгалары

"Учурда Рук сырткы дүйнөдөн пешкалар тарабынан жабылган, бирок биз бир күнү ал оюнда чечүүчү ролду ойнойт деп ишенебиз!" (цитата бул макала үчүн атайын ойлоп табылган)

Rook долбоору, албетте, биздин жүрөгүбүздү багындырды - биз [анын бардык жакшы жана жаман жактары менен] сөзсүз түрдө сиздин көңүлүңүзгө татыктуу деп ишенебиз.

Биздин келечектеги пландарыбыз rook-ceph үчүн модулга айландыруу менен байланыштуу addon-operator, бул биздин көп сандаган Kubernetes кластерлерибизде колдонууну ого бетер жөнөкөй жана ыңгайлуу кылат.

PS

Биздин блогдон дагы окуңуз:

• «Rook - Kubernetes үчүн "өзүн-өзү тейлөө" маалымат кампасы";
• «Ceph негизинде Kubernetes менен камсыздоо менен туруктуу сактагыч түзүү";
• «Берилиштер базалары жана Кубернеталар (карап чыгуу жана видео отчет)";
• «Shell-операторду тааныштыруу: Kubernetes үчүн операторлорду түзүү оңойлоду";
• «Kubernetes үчүн операторлор: мамлекеттик тиркемелерди кантип иштетүү керек«.

Source: www.habr.com