גיין? באַש! טרעפן די שאָל אָפּעראַטאָר (אָפּשאַצונג און ווידעא באַריכט פון KubeCon EU'2020)

דעם יאָר, די הויפּט אייראפעישער Kubernetes זיצונג - KubeCon + CloudNativeCon Europe 2020 - איז געווען ווירטואַל. אָבער, אַזאַ אַ ענדערונג אין פֿאָרמאַט האט נישט פאַרמייַדן אונדז פון דעליווערינג אונדזער לאַנג-פּלאַננעד באַריכט "גיין? באַש! טרעפן די שעל-אָפּעראַטאָר" דעדאַקייטאַד צו אונדזער עפֿן מקור פּרויעקט שאָל-אָפּעראַטאָר.

דער אַרטיקל, ינספּייערד דורך די שמועס, גיט אַ צוגאַנג צו סימפּלאַפייינג דעם פּראָצעס פון קריייטינג אָפּערייטערז פֿאַר Kubernetes און ווייַזן ווי איר קענען מאַכן דיין אייגענע מיט מינימאַל מי מיט אַ שאָל אָפּעראַטאָר.

ינטראָדוסינג ווידעא פון דעם באַריכט (~ 23 מינוט אין ענגליש, נאָוטיסאַבלי מער ינפאָרמאַטיוו ווי דער אַרטיקל) און די הויפּט עקסטראַקט פון עס אין טעקסט פאָרעם. גיי!

אין פלאַנט מיר קעסיידער אַפּטאַמייז און אָטאַמייז אַלץ. הייַנט מיר וועלן רעדן וועגן אן אנדער יקסייטינג באַגריף. טרעפן: וואָלקן-געבוירן שאָל סקריפּטינג!

אָבער, לאָמיר אָנהייבן מיט דעם קאָנטעקסט אין וואָס אַלע דעם כאַפּאַנז: Kubernetes.

Kubernetes API און קאַנטראָולערז

די אַפּי אין Kubernetes קענען זיין רעפּריזענטיד ווי אַ מין פון טעקע סערווער מיט דירעקטעריז פֿאַר יעדער טיפּ פון כייפעץ. אַבדזשעקץ (רעסורסן) אויף דעם סערווער זענען רעפּריזענטיד דורך YAML טעקעס. אין אַדישאַן, דער סערווער האט אַ יקערדיק API וואָס אַלאַוז איר צו טאָן דריי טינגז:

• צו באַקומען מיטל לויט זיין מין און נאָמען;
• טוישן מיטל (אין דעם פאַל, די סערווער סטאָרז בלויז "ריכטיג" אַבדזשעקץ - אַלע ינקערעקטלי געשאפן אָדער בדעה פֿאַר אנדערע דירעקטעריז זענען אַוועקגענומען);
• שפּור פֿאַר די מיטל (אין דעם פאַל, דער באַניצער גלייך נעמט זיין קראַנט / דערהייַנטיקט ווערסיע).

אזוי, Kubernetes אַקערז ווי אַ מין פון טעקע סערווער (פֿאַר YAML מאַניפעסץ) מיט דריי יקערדיק מעטהאָדס (יאָ, אַקטשאַוואַלי עס זענען אנדערע, אָבער מיר וועלן לאָזן זיי פֿאַר איצט).

די פּראָבלעם איז אַז דער סערווער קענען בלויז קראָם אינפֿאָרמאַציע. צו מאַכן עס אַרבעט איר דאַרפֿן קאָנטראָללער - דער צווייט מערסט וויכטיק און פונדאַמענטאַל באַגריף אין דער וועלט פון קובערנעטעס.

עס זענען צוויי הויפּט טייפּס פון קאַנטראָולערז. דער ערשטער נעמט אינפֿאָרמאַציע פון ​​Kubernetes, פּראַסעסאַז עס לויט נעסטעד לאָגיק און קערט עס צו K8s. דער צווייטער נעמט אינפֿאָרמאַציע פֿון Kubernetes, אָבער, ניט ענלעך דער ערשטער טיפּ, ענדערונגען די שטאַט פון עטלעכע פונדרויסנדיק רעסורסן.

לאָמיר נעמען אַ נעענטער קוק אין דעם פּראָצעס פון קריייטינג אַ דיפּלוימאַנט אין Kubernetes:

• דיפּלוימאַנט קאָנטראָללער (אַרייַנגערעכנט אין kube-controller-manager) באקומט אינפֿאָרמאַציע וועגן דיפּלוימאַנט און קריייץ אַ רעפּליקע סעט.
• ReplicaSet קריייץ צוויי רעפּלאַקאַז (צוויי פּאָדס) באזירט אויף דעם אינפֿאָרמאַציע, אָבער די פּאָדס זענען נישט סקעדזשולד נאָך.
• די סקעדזשולער סקעדזשולז פּאָדס און מוסיף נאָדע אינפֿאָרמאַציע צו זייער יאַמלס.
• קובעלעץ מאַכן ענדערונגען צו אַ פונדרויסנדיק מיטל (זאָגן דאָקער).

דערנאָך די גאנצע סיקוואַנס איז ריפּיטיד אין פאַרקערט סדר: די קובעלעט טשעק די קאַנטיינערז, קאַלקיאַלייץ די פּאָד ס סטאַטוס און סענדז עס צוריק. די רעפּליקעסעט קאָנטראָללער נעמט די סטאַטוס און דערהייַנטיקט די שטאַט פון די רעפּליקע שטעלן. דער זעלביקער זאַך כאַפּאַנז מיט די דיפּלוימאַנט קאָנטראָללער און דער באַניצער לעסאָף באַקומען די דערהייַנטיקט (קראַנט) סטאַטוס.

שאָל-אָפּעראַטאָר

עס טורנס אויס אַז Kubernetes איז באזירט אויף די שלאָס אַרבעט פון פאַרשידן קאַנטראָולערז (קובערנעטעס אָפּערייטערז זענען אויך קאַנטראָולערז). די קשיא ערייזאַז, ווי צו שאַפֿן דיין אייגענע אָפּעראַטאָר מיט מינימאַל מי? און דאָ דער איינער וואָס מיר דעוועלאָפּעד קומט צו ראַטעווען שאָל-אָפּעראַטאָר. עס אַלאַוז סיסטעם אַדמיניסטראַטאָרס צו שאַפֿן זייער אייגענע סטייטמאַנץ ניצן באַקאַנט מעטהאָדס.

פּשוט בייַשפּיל: קאַפּיינג סיקריץ

זאל ס קוק בייַ אַ פּשוט בייַשפּיל.

זאל ס זאָגן מיר האָבן אַ קובערנעטעס קנויל. עס האט אַ נאָמען פּלאַץ default מיט עטלעכע סוד mysecret. אין דערצו, עס זענען אנדערע נאַמעספּאַסעס אין דעם קנויל. עטלעכע פון ​​זיי האָבן אַ ספּעציפיש פירמע אַטאַטשט צו זיי. אונדזער ציל איז צו נאָכמאַכן סעקרעט אין נאָמען ספּייסאַז מיט אַ פירמע.

די אַרבעט איז קאָמפּליצירט דורך די פאַקט אַז נייַ נאָמען ספּייסאַז קען דערשייַנען אין דעם קנויל, און עטלעכע פון ​​זיי קען האָבן דעם פירמע. אויף די אנדערע האַנט, ווען די פירמע איז אויסגעמעקט, סוד זאָל אויך זיין אויסגעמעקט. אין אַדישאַן צו דעם, דער סוד זיך קענען אויך טוישן: אין דעם פאַל, די נייַ סוד מוזן זיין קאַפּיד צו אַלע נאָמען ספּייסאַז מיט לאַבעלס. אויב סעקרעט איז אַקסאַדענאַלי אויסגעמעקט אין קיין נאָמען, אונדזער אָפּעראַטאָר זאָל ומקערן עס מיד.

איצט אַז די אַרבעט איז פארמולירט, עס איז צייט צו אָנהייבן ימפּלאַמענינג עס מיט די שאָל אָפּעראַטאָר. אבער ערשטער עס איז ווערט צו זאָגן אַ ביסל ווערטער וועגן די שאָל-אָפּעראַטאָר זיך.

ווי שאָל-אָפּעראַטאָר אַרבעט

ווי אנדערע ווערקלאָודז אין Kubernetes, די שאָל אָפּעראַטאָר לויפט אין זיין אייגענע פּאָד. אין דעם פּאָד אין די וועגווייַזער /hooks עקסעקוטאַבלע טעקעס זענען סטאָרד. די קענען זיין סקריפּס אין Bash, Python, Ruby, עטק. מיר רופן אַזאַ עקסעקוטאַבלע טעקעס כוקס (כוקס).

שעל-אָפּעראַטאָר אַבאָנירן צו Kubernetes events און לויפט די כוקס אין ענטפער צו די געשעענישן וואָס מיר דאַרפֿן.

ווי קען דער שאָל-אָפּעראַטאָר וויסן וואָס קרוק צו לויפן און ווען? די פונט איז אַז יעדער קרוק האט צוויי סטאַגעס. בעשאַס סטאַרטאַפּ, די שאָל אָפּעראַטאָר לויפט אַלע כוקס מיט אַ אַרגומענט --config דאָס איז די קאַנפיגיעריישאַן בינע. און נאָך עס, כוקס זענען לאָנטשט אין דער נאָרמאַל וועג - אין ענטפער צו די געשעענישן צו וואָס זיי זענען אַטאַטשט. אין די לעצטע פאַל, די קרוק נעמט די ביינדינג קאָנטעקסט (ביינדינג קאָנטעקסט) - דאַטן אין JSON פֿאָרמאַט, וואָס מיר וועלן רעדן וועגן אין מער דעטאַל אונטן.

מאַכן אַן אָפּעראַטאָר אין באַש

איצט מיר זענען גרייט פֿאַר ימפּלאַמענטיישאַן. צו טאָן דאָס, מיר דאַרפֿן צו שרייַבן צוויי פאַנגקשאַנז (דורך וועג, מיר רעקאָמענדירן ביבליאָטעק shell_lib, וואס מאכט שטארק פארפעסטיקט שרייבן האקן אין באש):

• דער ערשטער איז דארף פֿאַר די קאַנפיגיעריישאַן בינע - עס דיספּלייז די ביינדינג קאָנטעקסט;
• די רגע כּולל די הויפּט לאָגיק פון די קרוק.

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

דער ווייַטער שריט איז צו באַשליסן וואָס אַבדזשעקץ מיר דאַרפֿן. אין אונדזער פאַל, מיר דאַרפֿן צו שפּור:

• מקור סוד פֿאַר ענדערונגען;
• אַלע נאָמען ספּייסאַז אין דעם קנויל, אַזוי אַז איר וויסן וואָס אָנעס האָבן אַ פירמע אַטאַטשט צו זיי;
• ציל סיקריץ צו ענשור אַז זיי זענען אַלע אין סינק מיט די מקור סוד.

אַבאָנירן צו דער סוד מקור

ביינדינג קאַנפיגיעריישאַן פֿאַר עס איז גאַנץ פּשוט. מיר אָנווייַזן אַז מיר זענען אינטערעסירט אין סוד מיט דעם נאָמען mysecret אין נאָמען פּלאַץ default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

ווי אַ רעזולטאַט, דער קרוק וועט זיין טריגערד ווען דער מקור סוד ענדערונגען (src_secret) און באַקומען די פאלגענדע ביינדינג קאָנטעקסט:

ווי איר קענען זען, עס כּולל די נאָמען און די גאנצע כייפעץ.

בעכעסקעם שפּור פון נאָמען ספּייסאַז

איצט איר דאַרפֿן צו אַבאָנירן צו נאָמען ספּייסאַז. צו טאָן דאָס, מיר ספּעציפיצירן די פאלגענדע ביינדינג קאַנפיגיעריישאַן:

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

ווי איר קענען זען, אַ נייַ פעלד איז ארויס אין די קאַנפיגיעריישאַן מיט דעם נאָמען jqFilter. ווי זיין נאָמען סאַגדזשעס, jqFilter פילטערס אויס אַלע ומנייטיק אינפֿאָרמאַציע און קריייץ אַ נייַע JSON כייפעץ מיט די פעלדער וואָס זענען פון אינטערעס צו אונדז. א קרוק מיט אַ ענלעך קאַנפיגיעריישאַן וועט באַקומען די פאלגענדע ביינדינג קאָנטעקסט:

עס כּולל אַ פּלאַץ filterResults פֿאַר יעדער נאַמעספּאַסע אין דעם קנויל. בוליאַן בייַטעוודיק hasLabel ינדיקייץ צי אַ פירמע איז אַטאַטשט צו אַ געגעבן נאָמען פּלאַץ. סעלעקטאָר keepFullObjectsInMemory: false ינדיקייץ אַז עס איז ניט דאַרפֿן צו האַלטן גאַנץ אַבדזשעקץ אין זכּרון.

טראַקינג ציל סיקריץ

מיר אַבאָנירן צו אַלע סעקרעץ וואָס האָבן אַן אַנאָטאַציע ספּעסיפיעד managed-secret: "yes" (דאָס זענען אונדזער ציל dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

אין דעם פאַל jqFilter פילטערס אויס אַלע אינפֿאָרמאַציע אַחוץ די נאַמעספּאַסע און פּאַראַמעטער resourceVersion. די לעצטע פּאַראַמעטער איז דורכגעגאנגען צו די אַנאָטאַציע ווען קריייטינג דעם סוד: עס אַלאַוז איר צו פאַרגלייַכן ווערסיעס פון סיקריץ און האַלטן זיי דערהייַנטיקט.

א קרוק קאַנפיגיערד דעם וועג וועט, ווען עקסאַקיוטאַד, באַקומען די דריי ביינדינג קאַנטעקסץ דיסקרייבד אויבן. זיי קענען זיין געדאַנק פון ווי אַ מין פון מאָמענטבילד (מאָמענטבילד) קנויל.

באַזירט אויף אַלע דעם אינפֿאָרמאַציע, אַ יקערדיק אַלגערידאַם קענען זיין דעוועלאָפּעד. עס יטערייץ איבער אַלע נאָמען ספּייסאַז און:

• צי hasLabel ענינים true פֿאַר דעם קראַנט נאָמען פּלאַץ:
  • קאַמפּערז די גלאבאלע סוד מיט די היגע:
    • אויב זיי זענען די זעלבע, עס טוט גאָרנישט;
    • אויב זיי אַנדערש - עקסאַקיוץ kubectl replace אָדער create;
• צי hasLabel ענינים false פֿאַר דעם קראַנט נאָמען פּלאַץ:
  • מאכט זיכער אַז סעקרעט איז נישט אין די געגעבן נאָמען:
    • אויב די היגע סוד איז פאָרשטעלן, ויסמעקן עס ניצן kubectl delete;
    • אויב די היגע סוד איז נישט דיטעקטאַד, עס טוט גאָרנישט.

ימפּלאַמענטיישאַן פון די אַלגערידאַם אין באַש איר קענען אראפקאפיע אין אונדזער ריפּאַזאַטאָריז מיט ביישפילן.

אַזוי מיר זענען ביכולת צו שאַפֿן אַ פּשוט קובערנעטעס קאָנטראָללער מיט 35 שורות פון YAML קאַנפיגיעריישאַן און וועגן דער זעלביקער סומע פון ​​​​באַש קאָד! די אַרבעט פון די שאָל אָפּעראַטאָר איז צו פאַרבינדן זיי צוזאַמען.

אָבער, קאַפּיינג סיקריץ איז נישט דער בלויז געגנט פון אַפּלאַקיישאַן פון די נוצן. דאָ זענען אַ ביסל מער ביישפילן צו ווייַזן וואָס ער איז טויגעוודיק פון.

בייַשפּיל 1: מאַכן ענדערונגען צו ConfigMap

זאל ס קוק אין אַ דיפּלוימאַנט קאַנסיסטינג פון דריי פּאָדס. פּאָדס נוצן ConfigMap צו קראָם עטלעכע קאַנפיגיעריישאַן. ווען די פּאָדס זענען לאָנטשט, ConfigMap איז געווען אין אַ זיכער שטאַט (לאָמיר רופן עס וו.1). אַקקאָרדינגלי, אַלע פּאָדס נוצן דעם באַזונדער ווערסיע פון ​​​​ConfigMap.

איצט לאָזן אונדז יבערנעמען אַז די קאָנפיגמאַפּ האט געביטן (וו.2). אָבער, די פּאָדס וועלן נוצן די פריערדיקע ווערסיע פון ​​​​ConfigMap (v.1):

ווי קען איך באַקומען זיי צו באַשטימען צו די נייַע קאָנפיגמאַפּ (וו.2)? דער ענטפער איז פּשוט: נוצן אַ מוסטער. לאָמיר לייגן אַ טשעקסום אַנאָטאַציע צו די אָפּטיילונג template דיפּלוימאַנט קאַנפיגיעריישאַנז:

ווי אַ רעזולטאַט, דעם טשעקסום וועט זיין רעגיסטרירט אין אַלע פּאָדס, און עס וועט זיין די זעלבע ווי די דיפּלוימאַנט. איצט איר נאָר דאַרפֿן צו דערהייַנטיקן די אַנאָטאַציע ווען די ConfigMap ענדערונגען. און דער שאָל-אָפּעראַטאָר קומט אין האַנטיק אין דעם פאַל. כל איר דאַרפֿן צו טאָן איז פּראָגראַם אַ פאַרטשעפּען וואָס וועט אַבאָנירן צו די ConfigMap און דערהייַנטיקן די טשעקקסום.

אויב דער באַניצער מאכט ענדערונגען צו די ConfigMap, דער שאָל אָפּעראַטאָר וועט באַמערקן זיי און ריקאַלקיאַלייט די טשעקסום. נאָך וואָס די מאַגיש פון קובערנעטעס וועט קומען אין שפּיל: דער אָרקעסטראַטאָר וועט טייטן די פּאָד, מאַכן אַ נייַ איינער, וואַרטן פֿאַר עס צו ווערן Ready, און מאַך אויף צו דער ווייַטער איינער. ווי אַ רעזולטאַט, דיפּלוימאַנט וועט סינגקראַנייז און באַשטימען צו די נייַע ווערסיע פון ​​​​ConfigMap.

בייַשפּיל 2: ארבעטן מיט מנהג ריסאָרס דעפינישאַנז

ווי איר וויסן, Kubernetes אַלאַוז איר צו שאַפֿן מנהג טייפּס פון אַבדזשעקץ. פֿאַר בייַשפּיל, איר קענען מאַכן אַ מין MysqlDatabase. זאל ס זאָגן דעם טיפּ האט צוויי מעטאַדאַטאַ פּאַראַמעטערס: name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

מיר האָבן אַ קובערנעטעס קנויל מיט פאַרשידענע נאַמעספּאַסעס אין וואָס מיר קענען שאַפֿן MySQL דאַטאַבייסיז. אין דעם פאַל, שאָל-אָפּעראַטאָר קענען זיין געוויינט צו שפּור רעסורסן MysqlDatabase, קאַנעקטינג זיי צו די MySQL סערווער און סינגקראַנייז די געבעטן און באמערקט שטאַטן פון דעם קנויל.

בייַשפּיל 3: קנויל נעטוואָרק מאָניטאָרינג

ווי איר וויסן, ניצן פּינג איז די סימפּלאַסט וועג צו מאָניטאָר אַ נעץ. אין דעם בייַשפּיל מיר וועלן ווייַזן ווי צו ינסטרומענט אַזאַ מאָניטאָרינג ניצן שאָל-אָפּעראַטאָר.

ערשטער פון אַלע, איר דאַרפֿן צו אַבאָנירן צו נאָודז. דער שאָל אָפּעראַטאָר דאַרף די נאָמען און IP אַדרעס פון יעדער נאָדע. מיט זייער הילף, ער וועט פּינג די נאָודז.

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

פּאַראַמעטער executeHookOnEvent: [] פּריווענץ די קרוק פון פליסנדיק אין ענטפער צו קיין געשעעניש (דאָס איז, אין ענטפער צו טשאַנגינג, אַדינג, דיליטינג נאָודז). אָבער, ער וועט לויפן (און דערהייַנטיקן די רשימה פון נאָודז) סקעדזשולד - יעדער מינוט, ווי פּריסקרייבד דורך די פעלד schedule.

איצט די קשיא ערייזאַז, ווי פּונקט טאָן מיר וויסן וועגן פּראָבלעמס ווי פּאַקאַט אָנווער? לאָמיר נעמען אַ קוק אין די קאָד:

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

מיר יטערייט די רשימה פון נאָודז, באַקומען זייער נעמען און IP אַדרעסעס, פּינג זיי און שיקן די רעזולטאַטן צו פּראָמעטהעוס. שעל-אָפּעראַטאָר קענען אַרויספירן מעטריקס צו פּראָמעטהעוס, שפּאָרן זיי צו אַ טעקע ליגן לויט די וועג ספּעסיפיעד אין די סוויווע בייַטעוודיק $METRICS_PATH.

אַזוי איר קענען מאַכן אַן אָפּעראַטאָר פֿאַר פּשוט נעץ מאָניטאָרינג אין אַ קנויל.

ריי מעקאַניזאַם

דער אַרטיקל וואָלט זיין דערענדיקט אָן דיסקרייבינג אן אנדער וויכטיק מעקאַניזאַם געבויט אין די שאָל אָפּעראַטאָר. ימאַדזשאַן אַז עס עקסאַקיוץ אַ מין פון פאַרטשעפּען אין ענטפער צו אַ געשעעניש אין דעם קנויל.

• וואָס כאַפּאַנז אויב אין דער זעלביקער צייַט אין די קנויל כאַפּאַנז נאך איינס געשעעניש?
• וועט שאָל-אָפּעראַטאָר לויפן אן אנדער בייַשפּיל פון די קרוק?
• וואָס אויב, זאָגן, פינף געשעענישן פּאַסירן אין דעם קנויל אין אַמאָל?
• וועט דער שאָל-אָפּעראַטאָר זיי פּראַסעסט פּאַראַלעל?
• וואָס וועגן קאַנסומד רעסורסן אַזאַ ווי זכּרון און קפּו?

צומ גליק, שאָל אָפּעראַטאָר האט אַ געבויט-אין ריי מעקאַניזאַם. אַלע געשעענישן זענען קייווד און פּראַסעסט סאַקווענטשאַלי.

לאמיר דאס אילוסטרירן מיט ביישפילן. לאמיר זאגן אז מיר האבן צוויי האקן. דער ערשטער געשעעניש גייט צו דער ערשטער קרוק. אַמאָל די פּראַסעסינג איז גאַנץ, די ריי גייט פאָרויס. די ווייַטער דרייַ געשעענישן זענען רידערעקטיד צו די רגע פאַרטשעפּען - זיי זענען אַוועקגענומען פון די ריי און אריין אין עס אין אַ "בינטל". דאס איז קרוק נעמט אַ פּלאַץ פון געשעענישן - אָדער, מער גענוי, אַ מענגע פון ​​ביינדינג קאַנטעקסץ.

אויך די געשעענישן קענען זיין קאַמביינד אין איין גרויס. דער פּאַראַמעטער איז פאַראַנטוואָרטלעך פֿאַר דעם group אין די ביינדינג קאַנפיגיעריישאַן.

איר קענען מאַכן קיין נומער פון קיוז / כוקס און זייער פאַרשידן קאַמבאַניישאַנז. פֿאַר בייַשפּיל, איין ריי קענען אַרבעטן מיט צוויי כוקס, אָדער וויצע ווערסאַ.

כל איר דאַרפֿן צו טאָן איז קאַנפיגיער די פעלד אַקאָרדינגלי queue אין די ביינדינג קאַנפיגיעריישאַן. אויב אַ ריי נאָמען איז נישט ספּעסיפיעד, דער קרוק לויפט אויף די פעליקייַט ריי (default). דעם ריי מעקאַניזאַם אַלאַוז איר צו גאָר סאָלווע אַלע ריסאָרס פאַרוואַלטונג פּראָבלעמס ווען איר אַרבעט מיט כוקס.

סאָף

מיר דערקלערט וואָס אַ שאָל אָפּעראַטאָר איז, געוויזן ווי עס קענען זיין געוויינט צו געשווינד און עפערטלאַסלי שאַפֿן Kubernetes אָפּערייטערז, און געגעבן עטלעכע ביישפילן פון זיין נוצן.

דיטיילד אינפֿאָרמאַציע וועגן די שאָל אָפּעראַטאָר, ווי געזונט ווי אַ שנעל טוטאָריאַל ווי צו נוצן עס, איז בנימצא אין די קאָראַספּאַנדינג ריפּאַזאַטאָריז אויף GitHub. צי ניט קווענקלען צו קאָנטאַקט אונדז מיט פֿראגן: איר קענען דיסקוטירן זיי אין אַ ספּעציעלע טעלעגראַם גרופּע (אין רוסיש) אָדער אין דעם פאָרום (אין ענגליש).

און אויב איר לייקט עס, מיר זענען שטענדיק צופרידן צו זען נייַע ישוז / פּר / שטערן אויף גיטהוב, ווו איר קענען געפֿינען אנדערע טשיקאַווע פראיעקטן. צווישן זיי עס איז ווערט כיילייטינג אַדדאָן-אָפּעראַטאָר, וואָס איז דער גרויסער ברודער פון שאָל-אָפּעראַטאָר. די נוצן ניצט העלם טשאַרץ צו ינסטאַלירן אַד-אָנס, קענען צושטעלן דערהייַנטיקונגען און מאָניטאָר פאַרשידן טשאַרט פּאַראַמעטערס / וואַלועס, קאָנטראָל די ינסטאַלירונג פּראָצעס פון טשאַרץ און אויך מאָדיפיצירן זיי אין ענטפער צו געשעענישן אין דעם קנויל.

ווידיאס און סליידז

ווידעא פֿון דער פאָרשטעלונג (~23 מינוט):

פּרעזענטירונג פון דער באַריכט:

פּס

לייענען אויך אויף אונדזער בלאָג:

• «גרינג שאַפונג פון Kubernetes אָפּערייטערז מיט שאָל-אָפּעראַטאָר: פּראָגרעס פון די פּרויעקט איבער די יאָר";
• «ינטראָודוסינג שאָל אָפּעראַטאָר: קריייטינג אָפּערייטערז פֿאַר Kubernetes איז פּונקט גרינגער";
• «איז עס גרינג און באַקוועם צו צוגרייטן אַ קובערנעטעס קנויל? אַנאַונסינג אַדדאָן-אָפּעראַטאָר";
• «יקספּאַנדינג און קאַמפּלאַמענטינג Kubernetes" (רעצענזיע און ווידעא באַריכט).

מקור: www.habr.com