రూక్‌కు లేదా రూక్‌కు కాదు - ఇది ప్రశ్న

రూక్‌కు లేదా రూక్‌కు కాదు - ఇది ప్రశ్న

ఈ నెల ప్రారంభంలో, మే 3న, "కుబెర్నెట్స్‌లో పంపిణీ చేయబడిన డేటా నిల్వ కోసం నిర్వహణ వ్యవస్థ" యొక్క ప్రధాన విడుదల ప్రకటించబడింది - రూక్ 1.0.0. మేము ఇప్పటికే ఒక సంవత్సరం కంటే ఎక్కువ ప్రచురించబడింది రూక్ యొక్క సాధారణ అవలోకనం. అప్పుడు మమ్మల్ని అతని అనుభవం గురించి మాట్లాడమని అడిగారు ఆచరణలో ఉపయోగించండి - మరియు ఇప్పుడు, ప్రాజెక్ట్ చరిత్రలో ఇంత ముఖ్యమైన మైలురాయిని పొందే సమయంలో, మా పేరుకుపోయిన ముద్రలను పంచుకోవడానికి మేము సంతోషిస్తున్నాము.

సంక్షిప్తంగా, రూక్ ఒక సెట్ నిర్వాహకులు Ceph, EdgeFS, Minio, Cassandra, CockroachDB వంటి డేటా స్టోరేజ్ సొల్యూషన్‌ల విస్తరణ, నిర్వహణ, ఆటోమేటిక్ రికవరీపై పూర్తి నియంత్రణను తీసుకునే కుబెర్నెట్స్ కోసం.

ప్రస్తుతానికి అత్యంత అభివృద్ధి చెందిన (మరియు ఒకే ఒక в స్థిరమైన దశ) పరిష్కారం రూక్-సెఫ్-ఆపరేటర్.

వ్యాఖ్య: Cephకి సంబంధించిన Rook 1.0.0 విడుదలలో ముఖ్యమైన మార్పులలో, Ceph Nautilusకి మద్దతు మరియు CephFS లేదా RGW బకెట్‌ల కోసం NFSని ఉపయోగించగల సామర్థ్యాన్ని మేము గమనించవచ్చు. బీటా స్థాయికి EdgeFS మద్దతు యొక్క పరిపక్వత ఇతరులలో విశిష్టమైనది.

కాబట్టి, ఈ వ్యాసంలో మేము:

  • కుబెర్నెటీస్ క్లస్టర్‌లో సెఫ్‌ని అమలు చేయడానికి రూక్‌ని ఉపయోగించడంలో మనం ఏ ప్రయోజనాలను చూస్తాము అనే ప్రశ్నకు సమాధానం చూద్దాం;
  • ఉత్పత్తిలో రూక్‌ని ఉపయోగించడం గురించి మేము మా అనుభవాన్ని మరియు ముద్రలను పంచుకుంటాము;
  • మేము రూక్‌కి “అవును!” అని ఎందుకు చెప్పామో మరియు అతని కోసం మా ప్రణాళికల గురించి చెప్పండి.

సాధారణ భావనలు మరియు సిద్ధాంతంతో ప్రారంభిద్దాం.

"నాకు ఒక రూక్ ప్రయోజనం ఉంది!" (తెలియని చెస్ ప్లేయర్)

రూక్‌కు లేదా రూక్‌కు కాదు - ఇది ప్రశ్న

రూక్ యొక్క ప్రధాన ప్రయోజనాల్లో ఒకటి, డేటా స్టోర్‌లతో పరస్పర చర్య కుబెర్నెటెస్ మెకానిజమ్స్ ద్వారా నిర్వహించబడుతుంది. షీట్ నుండి కన్సోల్‌లోకి Cephని కాన్ఫిగర్ చేయడానికి మీరు ఇకపై ఆదేశాలను కాపీ చేయనవసరం లేదని దీని అర్థం.

— మీరు CephFSని క్లస్టర్‌లో అమలు చేయాలనుకుంటున్నారా? కేవలం ఒక YAML ఫైల్ రాయండి!
- ఏమిటి? మీరు S3 APIతో ఆబ్జెక్ట్ స్టోర్‌ని కూడా అమలు చేయాలనుకుంటున్నారా? రెండవ YAML ఫైల్‌ను వ్రాయండి!

సాధారణ ఆపరేటర్ యొక్క అన్ని నియమాల ప్రకారం రూక్ సృష్టించబడుతుంది. ఉపయోగించి అతనితో పరస్పర చర్య జరుగుతుంది CRD (కస్టమ్ రిసోర్స్ నిర్వచనాలు), దీనిలో మనకు అవసరమైన సెఫ్ ఎంటిటీల లక్షణాలను వివరిస్తాము (ఇది స్థిరమైన అమలు మాత్రమే కాబట్టి, డిఫాల్ట్‌గా ఈ కథనం 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 ఫైల్ ద్వారా వనరులను "ఆర్డర్" చేస్తాము, దీని కోసం ఆపరేటర్ అవసరమైన ఆదేశాలను అమలు చేస్తాడు మరియు మేము మరింత పని చేయగల "అంత-నిజమైన" రహస్యాన్ని మాకు అందిస్తుంది. (కింద చూడుము). మరియు పైన జాబితా చేయబడిన వేరియబుల్స్ నుండి, ఆదేశం మరియు రహస్య పేరు సంకలనం చేయబడుతుంది.

ఇది ఎలాంటి జట్టు? వస్తువు నిల్వ కోసం వినియోగదారుని సృష్టిస్తున్నప్పుడు, పాడ్ లోపల ఉన్న రూక్ ఆపరేటర్ ఈ క్రింది వాటిని చేస్తుంది:

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 రిపోజిటరీలో నిల్వ చేయబడతాయి మరియు చాలాసార్లు మళ్లీ ఉపయోగించబడతాయి. మేము 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

అయితే, రూక్ ఉపయోగిస్తున్నప్పుడు ఈ సమస్య ఉండదు. దాని స్వంత డ్రైవర్లను ఉపయోగించి మౌంటు ప్రక్రియ జరుగుతుంది ఫ్లెక్స్వాల్యూమ్ లేదా 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 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

ఇంకా, అదనపు భాగాలను కావలసిన విధంగా కాన్ఫిగర్ చేయవచ్చు. వాటి గురించి మరిన్ని వివరాలు లో సూచించబడ్డాయి డాక్యుమెంటేషన్. పరిపాలన కోసం, డాష్‌బోర్డ్ మరియు టూల్‌బాక్స్‌ని ఇన్‌స్టాల్ చేయాలని మేము గట్టిగా సిఫార్సు చేస్తున్నాము.

రూక్స్ మరియు హుక్స్: అన్నింటికీ రూక్ సరిపోతుందా?

మీరు గమనిస్తే, రూక్ అభివృద్ధి పూర్తి స్వింగ్‌లో ఉంది. కానీ Ceph యొక్క మాన్యువల్ కాన్ఫిగరేషన్‌ను పూర్తిగా వదిలివేయడానికి అనుమతించని సమస్యలు ఇప్పటికీ ఉన్నాయి:

  • రూక్ డ్రైవర్ లేదు కుదరదు మౌంటెడ్ బ్లాక్‌ల వినియోగంపై కొలమానాలను ఎగుమతి చేస్తుంది, ఇది మాకు పర్యవేక్షణను కోల్పోతుంది.
  • Flexvolume మరియు CSI ఎలాగో తెలియదు వాల్యూమ్‌ల పరిమాణాన్ని మార్చండి (అదే RBDకి విరుద్ధంగా), కాబట్టి రూక్ ఒక ఉపయోగకరమైన (మరియు కొన్నిసార్లు క్లిష్టమైన అవసరం!) సాధనాన్ని కోల్పోయాడు.
  • రూక్ ఇప్పటికీ సాధారణ Ceph వలె అనువైనది కాదు. మేము CephFS మెటాడేటా కోసం పూల్‌ను SSDలో నిల్వ చేయడానికి మరియు డేటాను HDDలో నిల్వ చేయడానికి కాన్ఫిగర్ చేయాలనుకుంటే, మేము క్రష్ మ్యాప్‌లలో మాన్యువల్‌గా పరికరాల యొక్క ప్రత్యేక సమూహాలను నమోదు చేయాలి.
  • రూక్-సెఫ్-ఆపరేటర్ స్థిరంగా పరిగణించబడుతున్నప్పటికీ, Cephని వెర్షన్ 13 నుండి 14కి అప్‌గ్రేడ్ చేసేటప్పుడు ప్రస్తుతం కొన్ని సమస్యలు ఉన్నాయి.

కనుగొన్న

"ప్రస్తుతం రూక్ బంటుల ద్వారా బయటి ప్రపంచం నుండి మూసివేయబడింది, కానీ ఏదో ఒక రోజు ఆమె ఆటలో నిర్ణయాత్మక పాత్ర పోషిస్తుందని మేము నమ్ముతున్నాము!" (ఈ వ్యాసం కోసం ప్రత్యేకంగా కనుగొనబడిన కోట్)

రూక్ ప్రాజెక్ట్ నిస్సందేహంగా మా హృదయాలను గెలుచుకుంది - [దాని యొక్క అన్ని లాభాలు మరియు నష్టాలతో] ఇది ఖచ్చితంగా మీ దృష్టికి అర్హమైనది అని మేము నమ్ముతున్నాము.

మా భవిష్యత్తు ప్రణాళికలు రూక్-సెఫ్‌ను మాడ్యూల్‌గా మార్చే విధంగా ఉన్నాయి addon-operator, ఇది మా అనేక కుబెర్నెట్స్ క్లస్టర్‌లలో దాని వినియోగాన్ని మరింత సరళంగా మరియు మరింత సౌకర్యవంతంగా చేస్తుంది.

PS

మా బ్లాగులో కూడా చదవండి:

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి