Топу или не Топу - то је питање

Почетком овог месеца, 3. маја, најављено је велико издање „система за управљање дистрибуираним складиштењем података у Кубернетесу“ - Роок 1.0.0. Већ пре више од годину дана објављено општи преглед Топа. Затим су нас замолили да причамо о његовом искуству користити у пракси — и сада, баш на време за тако значајну прекретницу у историји пројекта, срећни смо да поделимо наше нагомилане утиске.

Укратко, Роок је сет оператора за Кубернетес, који преузимају потпуну контролу над применом, управљањем и аутоматским опоравком решења за складиштење података као што су Цепх, ЕдгеФС, Минио, Цассандра, ЦоцкроацхДБ.

Тренутно најразвијенији (и једини в стабилан фаза) решење је топ-цеф-оператер.

Приметити: Међу значајним променама у издању Роок 1.0.0 које се односе на Цепх, можемо приметити подршку за Цепх Наутилус и могућност коришћења НФС-а за ЦепхФС или РГВ буцкет. Оно што се истиче међу осталима је сазревање ЕдгеФС подршке до бета нивоа.

Дакле, у овом чланку ми:

• Хајде да одговоримо на питање које предности видимо у коришћењу Роок-а за примену Цепх-а у Кубернетес кластеру;
• Поделићемо наше искуство и утиске о коришћењу Роок-а у производњи;
• Хајде да вам кажемо зашто кажемо „Да!“ Рооку и о нашим плановима за њега.

Почнимо са општим концептима и теоријом.

„Имам предност једног топа!“ (непознати шахиста)

Једна од главних предности Роока је то што се интеракција са складиштима података врши преко Кубернетес механизама. То значи да више не морате да копирате команде да бисте конфигурисали Цепх са листа у конзолу.

— Да ли желите да примените ЦепхФС у кластеру? Само напишите ИАМЛ датотеку!
- Шта? Да ли такође желите да примените складиште објеката са С3 АПИ-јем? Само напишите другу ИАМЛ датотеку!

Роок је креиран по свим правилима типичног оператера. Интеракција са њим се јавља коришћењем ЦРД (прилагођене дефиниције ресурса), у којем описујемо карактеристике Цепх ентитета који су нам потребни (пошто је ово једина стабилна имплементација, овај чланак ће подразумевано говорити о Цепх-у, осим ако није експлицитно другачије наведено). Према наведеним параметрима, оператер ће аутоматски извршити команде неопходне за конфигурацију.

Хајде да погледамо специфичности користећи пример креирања продавнице објеката, тачније - 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 }}

Параметри наведени у листи су прилично стандардни и једва да им треба коментарисати, али вреди обратити посебну пажњу на оне који су додељени променљивим шаблона.

Општа шема рада се своди на то да ресурсе „наручујемо“ преко ИАМЛ датотеке, за коју оператер извршава потребне команде и враћа нам „не баш стварну“ тајну са којом можемо даље да радимо (види доле). А од горе наведених варијабли, команда и тајно име ће бити компајлирани.

Какав је ово тим? Када креирате корисника за складиштење објеката, Роок оператор унутар модула ће урадити следеће:

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

Резултат извршавања ове команде биће ЈСОН структура:

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

Keys - које будуће апликације ће требати да приступе складиштењу објеката преко С3 АПИ-ја. Оператор Роок их љубазно бира и ставља у свој именски простор у облику тајне са именом 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 }}

Све радње наведене у овом Задатку изведене су у оквиру Кубернетес-а. Структуре описане у ИАМЛ датотекама се чувају у Гит спремишту и више пута се користе. Ово видимо као велики плус за ДевОпс инжењере и ЦИ/ЦД процес у целини.

Срећан са Рооком и Радошом

Коришћење комбинације Цепх + РБД намеће одређена ограничења за монтирање волумена на подове.

Конкретно, именски простор мора да садржи тајну за приступ Цепх-у да би функционисале апликације са стањем. У реду је ако имате 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

Међутим, када користите Роок, овај проблем једноставно не постоји. Процес монтирања се одвија коришћењем сопствених драјвера на основу Флекволуме или ЦСИ (још увек у бета фази) и стога не захтева тајне.

Роок аутоматски решава многе проблеме, што нас подстиче да га користимо у новим пројектима.

Опсада топа

Хајде да завршимо практични део тако што ћемо применити Роок и Цепх како бисмо могли да спроводимо сопствене експерименте. Да би олакшали јуриш на ову неосвојиву кулу, програмери су припремили пакет Хелм. Хајде да га преузмемо:

$ 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 install --namespace ${ROOK_NAMESPACE} ./rook-ceph

Сада морате да направите кластер и одредите локацију ОСД:

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

Даље, додатне компоненте се могу конфигурисати по жељи. Више детаља о њима је наведено у документација. За администрацију, топло препоручујемо да инсталирате контролну таблу и кутију са алаткама.

Топ и удица: да ли је топ довољан за све?

Као што видите, развој Роока је у пуном јеку. Али још увек постоје проблеми који нам не дозвољавају да потпуно напустимо ручну конфигурацију Цепх-а:

• Но Роок Дривер не може извоз метрике о употреби монтираних блокова, што нас лишава праћења.
• Флекволуме и ЦСИ не знам како промените величину волумена (за разлику од истог РБД-а), тако да је Роок лишен корисног (и понекад критично потребног!) алата.
• Топ још увек није тако флексибилан као обични Цеф. Ако желимо да конфигуришемо скуп за ЦепхФС метаподатке да се чувају на ССД-у, а сами подаци да се чувају на ХДД-у, мораћемо да региструјемо одвојене групе уређаја у ЦРУСХ мапама ручно.
• Упркос чињеници да се роок-цепх-оператор сматра стабилним, тренутно постоје проблеми приликом надоградње Цепх-а са верзије 13 на 14.

Налази

„Тренутно је топ затворен од спољашњег света пешацима, али верујемо да ће једног дана она играти одлучујућу улогу у игри!“ (цитат измишљен посебно за овај чланак)

Пројекат Роок је несумњиво освојио наша срца - верујемо да [са свим својим предностима и недостацима] дефинитивно заслужује вашу пажњу.

Наши будући планови се своде на то да роок-цепх буде модул за аддон оператор, што ће учинити његову употребу у нашим бројним Кубернетес кластерима још једноставнијим и практичнијим.

ПС

Прочитајте и на нашем блогу:

• «Роок - „самоуслужно“ складиште података за Кубернетес";
• «Креирање трајног складишта са обезбеђивањем у Кубернетесу заснованом на Цепх-у";
• «Базе података и Кубернетес (преглед и видео извештај)";
• «Представљамо схелл-оператор: креирање оператора за Кубернетес је постало лакше";
• «Оператори за Кубернетес: како покренути апликације са стањем'.

Извор: ввв.хабр.цом