Rook ਜਾਂ ਨਹੀਂ Rook, ਇਹ ਸਵਾਲ ਹੈ

ਇਸ ਮਹੀਨੇ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, 3 ਮਈ ਨੂੰ, "ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਵੰਡੇ ਗਏ ਡੇਟਾ ਸਟੋਰੇਜ ਲਈ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ" ਦੀ ਇੱਕ ਵੱਡੀ ਰਿਲੀਜ਼ ਦਾ ਐਲਾਨ ਕੀਤਾ ਗਿਆ ਸੀ - ਰੂਕ 1.0.0. ਇੱਕ ਸਾਲ ਤੋਂ ਵੱਧ ਪਹਿਲਾਂ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਕਾਸ਼ਿਤ Rook ਦੀ ਆਮ ਸੰਖੇਪ ਜਾਣਕਾਰੀ. ਫਿਰ ਸਾਨੂੰ ਉਸਦੇ ਅਨੁਭਵ ਬਾਰੇ ਗੱਲ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਅਭਿਆਸ ਵਿੱਚ ਵਰਤੋ — ਅਤੇ ਹੁਣ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ ਅਜਿਹੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਮੀਲ ਪੱਥਰ ਦੇ ਸਮੇਂ ਵਿੱਚ, ਅਸੀਂ ਆਪਣੇ ਸੰਚਿਤ ਪ੍ਰਭਾਵ ਸਾਂਝੇ ਕਰਨ ਵਿੱਚ ਖੁਸ਼ ਹਾਂ।

ਸੰਖੇਪ ਵਿੱਚ, Rook ਇੱਕ ਸੈੱਟ ਹੈ ਆਪਰੇਟਰ ਕੁਬਰਨੇਟਸ ਲਈ, ਜੋ ਕਿ Ceph, EdgeFS, Minio, Cassandra, CockroachDB ਵਰਗੇ ਡੇਟਾ ਸਟੋਰੇਜ ਹੱਲਾਂ ਦੀ ਤੈਨਾਤੀ, ਪ੍ਰਬੰਧਨ, ਆਟੋਮੈਟਿਕ ਰਿਕਵਰੀ ਦਾ ਪੂਰਾ ਨਿਯੰਤਰਣ ਲੈਂਦੇ ਹਨ।

ਇਸ ਸਮੇਂ ਸਭ ਤੋਂ ਵਿਕਸਤ (ਅਤੇ ਸਿਰਫ ਇੱਕ в ਸਥਿਰ ਪੜਾਅ) ਦਾ ਹੱਲ ਹੈ rook-ceph-operator.

ਟਿੱਪਣੀ: Ceph ਨਾਲ ਸਬੰਧਤ Rook 1.0.0 ਰੀਲੀਜ਼ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਵਿੱਚੋਂ, ਅਸੀਂ Ceph Nautilus ਲਈ ਸਮਰਥਨ ਅਤੇ CephFS ਜਾਂ RGW ਬਾਲਟੀਆਂ ਲਈ NFS ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਨੋਟ ਕਰ ਸਕਦੇ ਹਾਂ। ਬੀਟਾ ਪੱਧਰ ਤੱਕ EdgeFS ਸਮਰਥਨ ਦੀ ਪਰਿਪੱਕਤਾ ਦੂਜਿਆਂ ਵਿੱਚ ਕੀ ਹੈ।

ਇਸ ਲਈ, ਇਸ ਲੇਖ ਵਿਚ ਅਸੀਂ:

• ਆਓ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਈਏ ਕਿ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਸੇਫ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਰੂਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਅਸੀਂ ਕਿਹੜੇ ਫਾਇਦੇ ਦੇਖਦੇ ਹਾਂ;
• ਅਸੀਂ ਉਤਪਾਦਨ ਵਿੱਚ ਰੂਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਆਪਣੇ ਅਨੁਭਵ ਅਤੇ ਪ੍ਰਭਾਵਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਾਂਗੇ;
• ਆਓ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਰੁਕ ਨੂੰ “ਹਾਂ!” ਕਿਉਂ ਕਹਿੰਦੇ ਹਾਂ, ਅਤੇ ਉਸ ਲਈ ਸਾਡੀਆਂ ਯੋਜਨਾਵਾਂ ਬਾਰੇ।

ਆਉ ਆਮ ਧਾਰਨਾਵਾਂ ਅਤੇ ਸਿਧਾਂਤ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ।

"ਮੈਨੂੰ ਇੱਕ ਰੂਕ ਦਾ ਫਾਇਦਾ ਹੈ!" (ਅਣਜਾਣ ਸ਼ਤਰੰਜ ਖਿਡਾਰੀ)

ਰੂਕ ਦੇ ਮੁੱਖ ਫਾਇਦਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਡੇਟਾ ਸਟੋਰਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕੁਬਰਨੇਟਸ ਵਿਧੀ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਹੁਣ ਸ਼ੀਟ ਤੋਂ ਕਨਸੋਲ ਵਿੱਚ Ceph ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਕਮਾਂਡਾਂ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

- ਕੀ ਤੁਸੀਂ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ CephFS ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ? ਬਸ ਇੱਕ YAML ਫਾਈਲ ਲਿਖੋ!
- ਕੀ? ਕੀ ਤੁਸੀਂ S3 API ਦੇ ਨਾਲ ਇੱਕ ਆਬਜੈਕਟ ਸਟੋਰ ਨੂੰ ਵੀ ਤੈਨਾਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ? ਬੱਸ ਇੱਕ ਦੂਜੀ YAML ਫਾਈਲ ਲਿਖੋ!

ਰੂਕ ਇੱਕ ਆਮ ਓਪਰੇਟਰ ਦੇ ਸਾਰੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਸ ਨਾਲ ਗੱਲਬਾਤ ਹੁੰਦੀ ਹੈ CRD (ਕਸਟਮ ਸਰੋਤ ਪਰਿਭਾਸ਼ਾਵਾਂ), ਜਿਸ ਵਿੱਚ ਅਸੀਂ 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 ਫਾਈਲ ਰਾਹੀਂ ਸਰੋਤਾਂ ਨੂੰ "ਆਰਡਰ" ਕਰਦੇ ਹਾਂ, ਜਿਸ ਲਈ ਆਪਰੇਟਰ ਜ਼ਰੂਰੀ ਕਮਾਂਡਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਸਾਨੂੰ ਇੱਕ "ਅਸਲ ਨਹੀਂ" ਗੁਪਤ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਅਸੀਂ ਅੱਗੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਾਂ। (ਨੀਚੇ ਦੇਖੋ). ਅਤੇ ਉੱਪਰ ਦਿੱਤੇ ਵੇਰੀਏਬਲ ਤੋਂ, ਕਮਾਂਡ ਅਤੇ ਗੁਪਤ ਨਾਮ ਨੂੰ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਵੇਗਾ।

ਇਹ ਕਿਹੋ ਜਿਹੀ ਟੀਮ ਹੈ? ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਲਈ ਉਪਭੋਗਤਾ ਬਣਾਉਣ ਵੇਲੇ, ਪੌਡ ਦੇ ਅੰਦਰ ਰੂਕ ਆਪਰੇਟਰ ਹੇਠ ਲਿਖੇ ਕੰਮ ਕਰੇਗਾ:

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 ਪ੍ਰਕਿਰਿਆ ਲਈ ਇੱਕ ਵਿਸ਼ਾਲ ਪਲੱਸ ਵਜੋਂ ਦੇਖਦੇ ਹਾਂ।

Rook ਅਤੇ Rados ਨਾਲ ਖੁਸ਼

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 ਦੀ ਘੇਰਾਬੰਦੀ

ਆਉ ਅਸੀਂ ਰੂਕ ਅਤੇ ਸੇਫ ਨੂੰ ਤੈਨਾਤ ਕਰਕੇ ਵਿਹਾਰਕ ਭਾਗ ਨੂੰ ਪੂਰਾ ਕਰੀਏ ਤਾਂ ਜੋ ਅਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਪ੍ਰਯੋਗ ਕਰ ਸਕੀਏ। ਇਸ ਅਦੁੱਤੀ ਟਾਵਰ ਨੂੰ ਤੂਫਾਨ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ, ਡਿਵੈਲਪਰਾਂ ਨੇ ਹੈਲਮ ਪੈਕੇਜ ਤਿਆਰ ਕੀਤਾ ਹੈ। ਆਓ ਇਸਨੂੰ ਡਾਉਨਲੋਡ ਕਰੀਏ:

$ 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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਾਧੂ ਭਾਗਾਂ ਨੂੰ ਲੋੜ ਅਨੁਸਾਰ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਹਨਾਂ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਨ ਦਸਤਾਵੇਜ਼. ਪ੍ਰਸ਼ਾਸਨ ਲਈ, ਅਸੀਂ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਟੂਲਬਾਕਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ।

ਰੂਕ ਅਤੇ ਹੁੱਕਸ: ਕੀ ਰੂਕ ਹਰ ਚੀਜ਼ ਲਈ ਕਾਫ਼ੀ ਹੈ?

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਰੂਕ ਦਾ ਵਿਕਾਸ ਪੂਰੇ ਜ਼ੋਰਾਂ 'ਤੇ ਹੈ. ਪਰ ਅਜੇ ਵੀ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜੋ ਸਾਨੂੰ ਸੇਫ ਦੀ ਮੈਨੂਅਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡਣ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੀਆਂ:

• ਕੋਈ ਰੁੱਕ ਡਰਾਈਵਰ ਨਹੀਂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਮਾਊਂਟ ਕੀਤੇ ਬਲਾਕਾਂ ਦੀ ਵਰਤੋਂ 'ਤੇ ਨਿਰਯਾਤ ਮੈਟ੍ਰਿਕਸ, ਜੋ ਸਾਨੂੰ ਨਿਗਰਾਨੀ ਤੋਂ ਵਾਂਝੇ ਰੱਖਦਾ ਹੈ।
• Flexvolume ਅਤੇ CSI ਪਤਾ ਨਹੀਂ ਕਿਵੇਂ ਵਾਲੀਅਮ ਦਾ ਆਕਾਰ ਬਦਲੋ (ਇੱਕੋ RBD ਦੇ ਉਲਟ), ਇਸਲਈ Rook ਇੱਕ ਉਪਯੋਗੀ (ਅਤੇ ਕਈ ਵਾਰ ਗੰਭੀਰ ਤੌਰ 'ਤੇ ਲੋੜੀਂਦੇ!) ਟੂਲ ਤੋਂ ਵਾਂਝਾ ਹੈ।
• ਰੂਕ ਅਜੇ ਵੀ ਨਿਯਮਤ ਸੇਫ ਜਿੰਨਾ ਲਚਕਦਾਰ ਨਹੀਂ ਹੈ. ਜੇਕਰ ਅਸੀਂ CephFS ਮੈਟਾਡੇਟਾ ਨੂੰ SSD 'ਤੇ ਸਟੋਰ ਕਰਨ ਲਈ ਪੂਲ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਤੇ ਡਾਟਾ ਖੁਦ HDD 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਹੈ, ਤਾਂ ਸਾਨੂੰ CRUSH ਨਕਸ਼ਿਆਂ ਵਿੱਚ ਡਿਵਾਈਸਾਂ ਦੇ ਵੱਖਰੇ ਸਮੂਹਾਂ ਨੂੰ ਹੱਥੀਂ ਰਜਿਸਟਰ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
• ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ rook-ceph-operator ਨੂੰ ਸਥਿਰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਵਰਤਮਾਨ ਵਿੱਚ Ceph ਨੂੰ ਵਰਜਨ 13 ਤੋਂ 14 ਤੱਕ ਅੱਪਗਰੇਡ ਕਰਨ ਵੇਲੇ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਹਨ।

ਸਿੱਟਾ

"ਇਸ ਸਮੇਂ ਰੂਕ ਨੂੰ ਬਾਹਰੀ ਦੁਨੀਆ ਤੋਂ ਬੰਦਿਆਂ ਦੁਆਰਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਪਰ ਸਾਨੂੰ ਵਿਸ਼ਵਾਸ ਹੈ ਕਿ ਇੱਕ ਦਿਨ ਉਹ ਖੇਡ ਵਿੱਚ ਨਿਰਣਾਇਕ ਭੂਮਿਕਾ ਨਿਭਾਏਗੀ!" (ਇਸ ਲੇਖ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਖੋਜ ਕੀਤੀ ਗਈ ਹਵਾਲਾ)

ਰੂਕ ਪ੍ਰੋਜੈਕਟ ਨੇ ਬਿਨਾਂ ਸ਼ੱਕ ਸਾਡੇ ਦਿਲ ਜਿੱਤ ਲਏ ਹਨ - ਅਸੀਂ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹਾਂ ਕਿ [ਇਸਦੇ ਸਾਰੇ ਚੰਗੇ ਅਤੇ ਨੁਕਸਾਨ ਦੇ ਨਾਲ] ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਧਿਆਨ ਦਾ ਹੱਕਦਾਰ ਹੈ।

ਸਾਡੀਆਂ ਭਵਿੱਖ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਰੂਕ-ਸੇਫ ਨੂੰ ਇੱਕ ਮੋਡੀਊਲ ਬਣਾਉਣ ਲਈ ਉਬਾਲਦੀਆਂ ਹਨ addon-operator, ਜੋ ਸਾਡੇ ਕਈ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਨੂੰ ਹੋਰ ਵੀ ਸਰਲ ਅਤੇ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਬਣਾਵੇਗਾ।

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਰੂਕ ਕੁਬਰਨੇਟਸ ਲਈ ਇੱਕ "ਸਵੈ-ਸੇਵਾ" ਡੇਟਾ ਸਟੋਰ ਹੈ";
• «Ceph 'ਤੇ ਆਧਾਰਿਤ Kubernetes ਵਿੱਚ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਦੇ ਨਾਲ ਇੱਕ ਸਥਾਈ ਸਟੋਰੇਜ ਬਣਾਓ";
• «ਡਾਟਾਬੇਸ ਅਤੇ ਕੁਬਰਨੇਟਸ (ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• «ਸ਼ੈੱਲ-ਓਪਰੇਟਰ ਪੇਸ਼ ਕਰਨਾ: ਕੁਬਰਨੇਟਸ ਲਈ ਆਪਰੇਟਰ ਬਣਾਉਣਾ ਹੁਣੇ ਆਸਾਨ ਹੋ ਗਿਆ ਹੈ";
• «ਕੁਬਰਨੇਟਸ ਲਈ ਆਪਰੇਟਰ: ਸਟੇਟਫੁੱਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ".

ਸਰੋਤ: www.habr.com