በዚህ ወር መጀመሪያ ላይ በሜይ 3 "በኩበርኔትስ ውስጥ ለተሰራጨ የውሂብ ማከማቻ አስተዳደር ስርዓት" ዋና መለቀቅ ተገለጸ -
በአጭሩ ሩክ ስብስብ ነው።
በአሁኑ ጊዜ በጣም የዳበረው (እና
አመለከተከሴፍ ጋር በተዛመደ በRook 1.0.0 ልቀት ላይ ከተደረጉት ጉልህ ለውጦች መካከል፣ ለሴፍ ናውቲለስ ድጋፍ እና NFSን ለሴፍኤፍኤስ ወይም RGW ባልዲዎች የመጠቀም ችሎታን ልብ ማለት እንችላለን። ከሌሎች መካከል ጎልቶ የሚታየው የ EdgeFS ድጋፍ ወደ ቅድመ-ይሁንታ ደረጃ መብሰል ነው።
ስለዚህ, በዚህ ጽሑፍ ውስጥ እኛ:
- ሩክን ተጠቅመን ሴፍ በኩበርኔትስ ክላስተር ውስጥ ለማሰማራት ምን አይነት ጥቅማጥቅሞች እንደምናያቸው ለሚለው ጥያቄ መልስ እንስጥ።
- ሩክን በምርት ውስጥ ስለመጠቀም ያለንን ልምድ እና ግንዛቤ እናካፍላለን፤
- ለምን ለሩክ “አዎ!” እንደምንል እና ለእሱ ያለንን እቅድ እንንገራችሁ።
በአጠቃላይ ጽንሰ-ሐሳቦች እና ጽንሰ-ሐሳቦች እንጀምር.
"የአንድ ሮክ ጥቅም አለኝ!" (ያልታወቀ የቼዝ ተጫዋች)
የሩክ ዋነኛ ጥቅሞች አንዱ ከመረጃ ማከማቻዎች ጋር መስተጋብር የሚከናወነው በኩበርኔትስ ዘዴዎች ነው. ይህ ማለት ከአሁን በኋላ Cephን ከሉህ ወደ ኮንሶል ለማዋቀር ትእዛዞቹን መቅዳት አያስፈልግዎትም ማለት ነው።
- CephFSን በክላስተር ውስጥ ማሰማራት ይፈልጋሉ? የ YAML ፋይል ብቻ ይጻፉ!
- ምንድን? እንዲሁም የነገር ማከማቻን ከS3 API ጋር ማሰማራት ይፈልጋሉ? ልክ ሁለተኛ YAML ፋይል ጻፍ!
ሩክ በተለመደው ኦፕሬተር በሁሉም ደንቦች መሰረት ይፈጠራል. ከእሱ ጋር መስተጋብር የሚከናወነው በመጠቀም ነው
የነገር መደብርን የመፍጠር ምሳሌን በመጠቀም ልዩነቱን እንይ፣ ወይም ይልቁንስ - 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 ማከማቻ ውስጥ ተከማችተው ብዙ ጊዜ እንደገና ጥቅም ላይ ይውላሉ። ይህንን ለዴቭኦፕስ መሐንዲሶች እና ለሲአይ/ሲዲ አጠቃላይ ሂደት እንደ ትልቅ ፕላስ እናያለን።
ከሮክ እና ራዶስ ጋር ደስተኛ
የCep + RBD ጥምርን በመጠቀም ጥራዞችን ወደ ፖድ በመጫን ላይ የተወሰኑ ገደቦችን ያስገድዳል።
በተለይም የስቴት አፕሊኬሽኖች እንዲሰሩ የስም ቦታው ሴፍ ለመድረስ ሚስጥር መያዝ አለበት። በስማቸው ውስጥ 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 ሲጠቀሙ ይህ ችግር በቀላሉ የለም። የመጫን ሂደቱ በራሱ አሽከርካሪዎች በመጠቀም ይከሰታል
ሩክ ብዙ ችግሮችን በራስ ሰር ይፈታል፣ ይህም በአዲስ ፕሮጀክቶች ውስጥ እንድንጠቀምበት ያበረታታናል።
የሩክ ከበባ
የራሳችንን ሙከራዎች እንድናደርግ ሩክ እና ሴፍ በማሰማራት የተግባር ክፍሉን እናጠናቀቅ። ይህን የማይበገር ግንብ ለማውረር ቀላል ለማድረግ ገንቢዎቹ የሄልም ጥቅል አዘጋጅተዋል። እናውርደው፡-
$ 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 ገበታውን በትእዛዙ ይጫኑ፡-
$ 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
በተጨማሪ, ተጨማሪ አካላት እንደፈለጉ ሊዋቀሩ ይችላሉ. ስለእነሱ ተጨማሪ ዝርዝሮች በ ውስጥ ተገልጸዋል
ሮክ እና መንጠቆዎች፡ ሩክ ለሁሉም ነገር በቂ ነው?
እንደምታዩት የሮክ እድገት በከፍተኛ ደረጃ ላይ ነው። ግን አሁንም የሴፍ በእጅ ማዋቀርን ሙሉ በሙሉ ለመተው የማይፈቅዱ ችግሮች አሉ-
- ሮክ ሹፌር የለም።
አለመቻል ወደ ውጭ የሚላኩ መለኪያዎች በተሰቀሉ ብሎኮች አጠቃቀም ላይ ፣ ይህም ክትትልን ያሳጣናል። - Flexvolume እና CSI
እንዴት እንደሆነ አላውቅም የጥራዞችን መጠን ይቀይሩ (ከተመሳሳይ RBD በተቃራኒ) ፣ ስለዚህ ሩክ ጠቃሚ (እና አንዳንድ ጊዜ በጣም አስፈላጊ ነው!) መሣሪያ ተነፍጎታል። - ሩክ አሁንም እንደ መደበኛ ሴፍ ተለዋዋጭ አይደለም። ገንዳውን ለሴፍኤፍኤስ ሜታዳታ በኤስኤስዲ ላይ እንዲከማች እና ውሂቡ ራሱ በኤችዲዲ ላይ እንዲከማች ማዋቀር ከፈለግን በ CRUSH ካርታዎች ውስጥ የተለያዩ የመሳሪያዎችን ቡድን በእጅ መመዝገብ አለብን።
- ምንም እንኳን ሩክ-ሴፍ-ኦፕሬተር የተረጋጋ ነው ተብሎ ቢታሰብም፣ በአሁኑ ጊዜ ሴፍ ከስሪት 13 ወደ 14 ሲያሻሽል አንዳንድ ችግሮች አሉ።
ግኝቶች
"በአሁኑ ጊዜ ሩክ ከውጪው አለም በፓውንቶች ተዘግታለች ነገርግን አንድ ቀን በጨዋታው ውስጥ ወሳኝ ሚና እንደምትጫወት እናምናለን!" (ጥቅስ በተለይ ለዚህ ጽሑፍ የተፈጠረ)
የሮክ ፕሮጄክት ያለምንም ጥርጥር ልባችንን አሸንፏል - [ከሁሉም ጥቅሞቹ እና ጉዳቶች ጋር] በእርግጠኝነት ለእርስዎ ትኩረት ሊሰጠው እንደሚገባ እናምናለን።
የወደፊት እቅዶቻችን rook-cephን ሞጁል ለማድረግ ይሞቃሉ
PS
በብሎጋችን ላይ ያንብቡ፡-
- «
Rook - "የራስ አገልግሎት" የውሂብ መጋዘን ለ Kubernetes "; - «
በሴፍ ላይ በመመስረት በ Kubernetes ውስጥ አቅርቦት ጋር የማያቋርጥ ማከማቻ መፍጠር "; - «
የውሂብ ጎታዎች እና ኩበርኔትስ (የግምገማ እና የቪዲዮ ዘገባ) "; - «
ሼል-ኦፕሬተርን ማስተዋወቅ፡ ለኩበርኔትስ ኦፕሬተሮችን መፍጠር ቀላል ሆነ "; - «
ኦፕሬተሮች ለ Kubernetes: ሁኔታዊ መተግበሪያዎችን እንዴት ማሄድ እንደሚቻል ».
ምንጭ: hab.com