Kubernetes ביי DomClick: ווי צו שלאָפן פּיספאַלי אָנפירונג אַ קנויל פון 1000 מיקראָ באַדינונגס

מייַן נאָמען איז וויקטאָר יאַגאָפאַראָוו, און איך דעוועלאָפּ די Kubernetes פּלאַטפאָרמע ביי DomClick ווי אַ טעכניש אַנטוויקלונג פאַרוואַלטער אין די אָפּס (אָפּעראַציע) מאַנשאַפֿט. איך וואָלט ווי צו רעדן וועגן די סטרוקטור פון אונדזער דעוו <-> אָפּס פּראַסעסאַז, די פֿעיִקייטן פון אַפּערייטינג איינער פון די גרעסטן ק8ס קלאַסטערז אין רוסלאַנד, ווי געזונט ווי די DevOps / SRE פּראַקטיסיז וואָס אונדזער מאַנשאַפֿט אַפּלייז.

אָפּס מאַנשאַפֿט

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

אַלעמען האט פאַרשידענע קאַמפּאַטינסיז: נעטוואָרקס, דבאַ, ELK סטאַק ספּעשאַלאַסץ, קובערנעטעס אַדמיניסטראַטאָרס / דעוועלאָפּערס, מאָניטאָרינג, ווירטואַליזאַטיאָן, ייַזנוואַרג ספּעשאַלאַסץ, עטק. איין זאַך יונייץ אַלעמען - אַלעמען קענען פאַרבייַטן קיין פון אונדז צו עטלעכע מאָס: למשל, באַקענען נייַ נאָודז אין די ק8ס קנויל, דערהייַנטיקן PostgreSQL, שרייַבן אַ CI / CD + Ansible רערנ - ליניע, אָטאַמייט עפּעס אין Python/Bash/Go, פאַרבינדן ייַזנוואַרג צו דאַטאַ צענטער. שטאַרק קאַמפּאַטינסיז אין קיין געגנט טאָן ניט פאַרמייַדן איר פון טשאַנגינג דיין ריכטונג פון טעטיקייט און אָנהייבן צו פֿאַרבעסערן אין עטלעכע אנדערע געגנט. פֿאַר בייַשפּיל, איך זיך איינגעשריבן אַ פירמע ווי אַ PostgreSQL מומכע, און איצט מיין הויפּט געגנט פון פֿאַראַנטוואָרטלעכקייט איז Kubernetes קלאַסטערז. אין די מאַנשאַפֿט, קיין הייך איז באַגריסן און די געפיל פון ליווערידזש איז זייער דעוועלאָפּעד.

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

מאַנשאַפֿט מכשירים

די מכשירים מאַנשאַפֿט פיעסעס אַ באַטייטיק ראָלע אין אָטאַמיישאַן. זייער הויפּט אַרבעט איז צו שאַפֿן באַקוועם גראַפיקאַל און CLI מכשירים פֿאַר דעוועלאָפּערס. צום ביישפּיל, אונדזער ינערלעך אַנטוויקלונג קאָנפער אַלאַוז איר צו ממש ראָולינג אַ אַפּלאַקיישאַן צו Kubernetes מיט בלויז אַ ביסל מויז קליקס, קאַנפיגיער די רעסורסן, קיז פון וואָלט, עטק. ביז אַהער, עס איז געווען Jenkins + Helm 2, אָבער איך האָבן צו אַנטוויקלען מיין אייגענע געצייַג צו עלימינירן קאָפּיע-פּאַסטע און ברענגען יונאַפאָרמאַטי צו די ווייכווארג לייפסייקאַל.

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

DevOps

ווי פֿאַר DevOps, מיר זען עס ווי דאָס:

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

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

דעוועלאָפּערס רעקאָמענדירן אַדמיניסטראַטאָרס אויב זיי דאַרפֿן הילף צו שרייבן אַן אַדמיניסטראַטאָר מיקראָסערוויס (למשל, גיין באַקענד + HTML5), און אַדמיניסטראַטאָרס רעקאָמענדירן דעוועלאָפּערס וועגן ינפראַסטראַקטשער ישוז אָדער ישוז שייַכות צו ק8ס.

דורך דעם וועג, מיר טאָן ניט האָבן אַ מאַנאַליט, נאָר מיקראָ באַדינונגס. זייער נומער ביז איצט פלאַקטשוייץ צווישן 900 און 1000 אין די פּראָד ק8ס קנויל, אויב געמאסטן דורך נומער דיפּלוימאַנץ. די נומער פון פּאָדס פלאַקטשוייץ צווישן 1700 און 2000. עס זענען דערווייַל וועגן 2000 פּאָדס אין די פּראָד קנויל.

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

ריסאָרס פאַרוואַלטונג

מאָניטאָרינג

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

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

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

מאַנשאַפֿט רעסורסן אין די קובע

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

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

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

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

ריקוועס און לימאַץ

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

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

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

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

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

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

און דאָ זענען די פּאָדס וואָס זאָל צאַמען זייער אַפּעטיט:

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

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

מעטאַדאַלאַדזשיז

אין די פירמע ווי עס איז איצט מאָדערן, מיר אַדכיר צו DevOps- און SRE- פּראַקטישנער ווען אַ פירמע האט 1000 מיקראָ באַדינונגס, וועגן 350 דעוועלאָפּערס און 15 אַדמיניסטראַטאָרס פֿאַר די גאנצע ינפראַסטראַקטשער, איר מוזן "זיין מאָדערן": הינטער אַלע די "באַסוואָרדז" עס איז אַ דרינגלעך נויט צו אָטאַמייט אַלץ און אַלעמען, און אַדמיניסטראַטאָרס זאָל נישט זיין אַ באַטאַלנעק אין פּראַסעסאַז.

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

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

איך האב נישט געצויגן גראַפס פֿאַר אַ חודש. דאָס איז מיסטאָמע אַ גוט צייכן: עס מיטל אַז רובֿ פון די "ווילן" האָבן שוין איינגעזען. עס געטראפן אַז בעשאַס די וואָך איך וואָלט ציען עטלעכע נייַ גראַפיק בייַ מינדסטער אַמאָל אַ טאָג.

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

ימפּלאַמענטיישאַן סערוויס מעש איז נאָר אַרום די ווינקל און זאָל מאַכן לעבן פיל גרינגער פֿאַר אַלעמען, קאָלעגעס פון מכשירים זענען שוין נאָענט צו ימפּלאַמענינג די אַבסטראַקט "יסטיאָ פון אַ געזונט מענטש": די לעבן ציקל פון יעדער HTTP(s) בעטן וועט זיין קענטיק אין מאָניטאָרינג, און עס וועט שטענדיק זיין מעגלעך צו פֿאַרשטיין "אין וואָס בינע אַלץ צעבראכן" בעשאַס ינטער-דינסט (און ניט בלויז) ינטעראַקשאַן. אַבאָנירן צו נייַעס פֿון די DomClick כאַב. =)

Kubernetes ינפראַסטראַקטשער שטיצן

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

דער פּראָצעס פֿאַר אַפּדייטינג אַלע ק8ס קלאַסטערז קוקט ווי דאָס:

• נעמען קובעספּרייַ פֿון Southbridge, טשעק מיט אונדזער פאָדעם, Merjim.
• מיר ראָולינג די דערהייַנטיקן צו דרוק- "קוב".
• מיר ראָולד די דערהייַנטיקן איין נאָדע אין אַ צייט (אין Ansible דאָס איז "סיריאַל: 1") אין דעוו- "קוב".
• מיר דערהייַנטיקן שטעכן מוצאי שבת איין נאָדע אין אַ צייט.

עס זענען פּלאַנז צו פאַרבייַטן עס אין דער צוקונפֿט קובעספּרייַ פֿאַר עפּעס פאַסטער און גיין צו kubeadm.

אין גאַנץ מיר האָבן דריי "קובעס": דרוק, דעוו און פּראָד. מיר פּלאַנירן צו קאַטער אן אנדער איינער (הייס סטאַנדביי) פּראָד-"קוב" אין די רגע דאַטן צענטער. דרוק и דעוו לעבן אין "ווירטואַל מאשינען" (oVirt פֿאַר דרוק און VMWare וואָלקן פֿאַר דעוו). שטעכן- "קובע" לעבן אויף "נאַקעט מעטאַל": דאָס זענען יידעניקאַל נאָודז מיט 32 קפּו פֿעדעם, 64-128 גיגאבייט פון זכּרון און 300 גיגאבייט SSD RAID 10 - עס זענען 50 פון זיי אין גאַנץ. דריי "דין" נאָודז זענען דעדאַקייטאַד צו "מאַסטערס" שטעכן- "קובאַ": 16 גיגאבייט פון זכּרון, 12 קפּו פֿעדעם.

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

פֿאַר סי / קאָמפּאַקטדיסק "קוביק" און אנדערע ינפראַסטראַקטשער קאַמפּאָונאַנץ מיר נוצן אַ באַזונדער גיט סערווער, העלם 3 (עס איז געווען אַ גאַנץ ווייטיקדיק יבערגאַנג פון העלם 2, אָבער מיר זענען זייער צופרידן מיט די אָפּציעס. אַטאָמישע), Jenkins, Ansible און Docker. מיר ליבע שטריך צווייגן און דיפּלוימאַנט צו פאַרשידענע ינווייראַנמאַנץ פֿון איין ריפּאַזאַטאָרי.

סאָף

דאָס איז, אין אַלגעמיין, ווי דער DevOps פּראָצעס קוקט ווי DomClick פֿון דער פּערספּעקטיוו פון אַן אָפּעראַטיאָנס ינזשעניר. דער אַרטיקל איז געווען ווייניקער טעכניש ווי איך דערוואַרט: דעריבער, נאָכגיין די DomClick נייַעס אויף Habré: עס וועט זיין מער "כאַרדקאָר" אַרטיקלען וועגן Kubernetes און מער.

מקור: www.habr.com