מפעיל ב-Kubernetes לניהול אשכולות מסדי נתונים. ולדיסלב קלימנקו (Altinity, 2019)

הדו"ח מוקדש לנושאים פרקטיים של פיתוח מפעיל ב-Kubernetes, עיצוב הארכיטקטורה שלו ועקרונות ההפעלה הבסיסיים שלו.

בחלק הראשון של הדו"ח נשקול:

• מהו מפעיל ב- Kubernetes ולמה הוא נחוץ;
• איך בדיוק המפעיל מפשט את הניהול של מערכות מורכבות;
• מה המפעיל יכול ומה לא יכול לעשות.

לאחר מכן, נעבור לדיון במבנה הפנימי של המפעיל. בואו נסתכל על הארכיטקטורה והתפעול של המפעיל צעד אחר צעד. בואו נסתכל על זה בפירוט:

• אינטראקציה בין המפעיל לבין Kubernetes;
• אילו פונקציות המפעיל לוקח על עצמו ואילו פונקציות הוא מאציל ל-Kubernetes.

בואו נסתכל על ניהול רסיסים והעתקים של מסדי נתונים ב-Kubernetes.
לאחר מכן, נדון בבעיות אחסון נתונים:

• כיצד לעבוד עם אחסון מתמשך מנקודת מבטו של המפעיל;
• המלכודות של שימוש באחסון מקומי.

בחלק האחרון של הדו"ח נשקול דוגמאות מעשיות ליישום מפעיל קליקהאוס מאמזון או Google Cloud Service. הדוח מבוסס על דוגמה של ניסיון בפיתוח ותפעול של מפעיל עבור ClickHouse.

וידאו:

שמי ולדיסלב קלימנקו. היום רציתי לדבר על הניסיון שלנו בפיתוח ותפעול אופרטור, וזהו אופרטור מיוחד לניהול אשכולות מסדי נתונים. לדוגמה ClickHouse-מפעיל לניהול אשכול ClickHouse.

למה יש לנו הזדמנות לדבר על המפעיל ועל ClickHouse?

• אנו תומכים ומפתחים את ClickHouse.
• כרגע אנחנו מנסים לאט לאט לתרום את תרומתנו לפיתוח ClickHouse. ואנחנו במקום השני אחרי Yandex מבחינת נפח השינויים שבוצעו ב-ClickHouse.
• אנו מנסים ליצור פרויקטים נוספים עבור המערכת האקולוגית של ClickHouse.

אני רוצה לספר לכם על אחד מהפרויקטים האלה. מדובר ב-ClickHouse-מפעיל עבור Kubernetes.

בדוח שלי ברצוני לגעת בשני נושאים:

• הנושא הראשון הוא כיצד פועל מפעיל ניהול מסדי הנתונים של ClickHouse ב-Kubernetes.
• הנושא השני הוא איך כל מפעיל עובד, כלומר איך הוא מקיים אינטראקציה עם Kubernetes.

עם זאת, שתי השאלות הללו יצטלבו לאורך הדו"ח שלי.

מי יעניין להקשיב למה שאני מנסה לספר?

• זה יעניין ביותר את מי שמפעיל מפעילים.
• או למי שרוצה לעשות משלהם כדי להבין איך זה עובד פנימי, איך המפעיל מקיים אינטראקציה עם Kubernetes, ואילו מלכודות עשויות להופיע.

כדי להבין בצורה הטובה ביותר במה נדון היום, כדאי לדעת איך Kubernetes עובדת ולבצע הדרכה בסיסית בענן.

מה זה קליקהאוס? זהו מסד נתונים עמודי עם תכונות ספציפיות לעיבוד מקוון של שאילתות אנליטיות. וזה קוד פתוח לחלוטין.

וחשוב לנו לדעת רק שני דברים. אתה צריך לדעת שזה מסד נתונים, אז מה שאני אגיד לך יהיה ישים כמעט לכל מסד נתונים. והעובדה שה-ClickHouse DBMS מקנה מידה טובה מאוד, נותנת מדרגיות כמעט ליניארית. ולכן, מצב האשכול הוא מצב טבעי עבור ClickHouse. ואנחנו הכי מעוניינים לדון כיצד לשרת את אשכול ClickHouse ב-Kubernetes.

למה הוא נחוץ שם? למה אנחנו לא יכולים להמשיך להפעיל אותו בעצמנו? והתשובות בחלקן טכניות ובחלקן ארגוניות.

• בפועל, אנו נתקלים יותר ויותר במצב שבו בחברות גדולות כמעט כל הרכיבים נמצאים כבר ב-Kubernetes. מאגרי מידע נשארים בחוץ.
• והשאלה נשאלת יותר ויותר: "האם אפשר לשים את זה בפנים?" לכן, חברות גדולות מנסות להשיג איחוד מקסימלי של ההנהלה כדי להיות מסוגל לנהל במהירות את מחסני הנתונים שלהן.
• וזה עוזר במיוחד אם אתה צריך את ההזדמנות המקסימלית לחזור על אותו דבר במקום חדש, כלומר ניידות מקסימלית.

כמה זה קל או קשה? זה כמובן יכול להיעשות ביד. אבל זה לא כל כך פשוט, כי יש לנו את המורכבות הנוספת של ניהול Kubernetes עצמו, אבל באותו הזמן הפרטים של ClickHouse מונחים על גבי. ומתקבלת צבירה כזו.

ובסך הכל זה נותן סט די גדול של טכנולוגיות, שהופך די קשה לניהול, כי Kubernetes מביאה את הבעיות היומיומיות שלה לפעולה, ו-ClickHouse מביאה את הבעיות שלה לפעולה היומיומית. במיוחד אם יש לנו כמה קליקהאוסים, ואנחנו צריכים כל הזמן לעשות איתם משהו.

עם תצורה דינמית, ל-ClickHouse יש מספר גדול למדי של בעיות שיוצרות עומס קבוע על DevOps:

• כשאנחנו רוצים לשנות משהו ב-ClickHouse, למשל, להוסיף עותק או רסיס, אז אנחנו צריכים לנהל את התצורה.
• לאחר מכן שנה את סכימת הנתונים, כי ל-ClickHouse יש שיטת ריסוק ספציפית. שם אתה צריך לפרוס את דיאגרמת הנתונים, לפרוס את התצורות.
• אתה צריך להגדיר ניטור.
• איסוף יומנים לרסיסים חדשים, להעתקים חדשים.
• לדאוג לשיקום.
• ותתחיל מחדש.

אלו משימות שגרתיות שהייתי מאוד רוצה להקל על השימוש בהן.

Kubernetes עצמו עוזר היטב בתפעול, אבל בדברי מערכת בסיסיים.

Kubernetes טובה בהקלה ואוטומציה של דברים כמו:

• התאוששות.
• איתחול.
• ניהול מערכת אחסון.

זה טוב, זה הכיוון הנכון, אבל הוא לגמרי לא יודע איך להפעיל אשכול מסד נתונים.

אנחנו רוצים יותר, אנחנו רוצים שכל מסד הנתונים יעבוד ב-Kubernetes.

הייתי רוצה לקבל משהו כמו כפתור אדום קסם גדול שאתה לוחץ עליו ומקבץ עם משימות יומיומיות שצריכות להיפתר נפרס ומתוחזק לאורך כל מחזור החיים שלו. אשכול ClickHouse ב-Kubernetes.

וניסינו ליצור פתרון שיעזור להקל על העבודה. זהו מפעיל ClickHouse עבור Kubernetes מבית Altinity.

מפעיל הוא תוכנית שהמשימה העיקרית שלה היא לנהל תוכניות אחרות, כלומר הוא מנהל.

והוא מכיל דפוסי התנהגות. אתה יכול לקרוא לזה ידע מקודד על תחום הנושא.

והמשימה העיקרית שלו היא להקל על החיים של DevOps ולצמצם את ניהול המיקרו, כך שהוא (DevOps) כבר יחשוב במונחים ברמה גבוהה, כלומר, כדי שהוא (DevOps) לא יעסוק בניהול מיקרו, כדי שלא יגדיר תצורה כל הפרטים באופן ידני.

ורק המפעיל הוא עוזר רובוטי שעוסק במיקרו משימות ועוזר ל-DevOps.

למה צריך מפעיל? הוא מתפקד טוב במיוחד בשני תחומים:

• כאשר למומחה העוסק בקליקהאוס אין מספיק ניסיון, אבל כבר צריך להפעיל את קליקהאוס, המפעיל מקל על הפעולה ומאפשר להפעיל אשכול קליקהאוס בתצורה מורכבת למדי, מבלי להיכנס יותר מדי לפרטים כיצד הכל עובד בְּתוֹך. אתה פשוט נותן לו משימות ברמה גבוהה, וזה עובד.
• והמשימה השנייה שבה הוא מתפקד בצורה הטובה ביותר היא כאשר יש צורך לבצע אוטומציה של מספר רב של משימות טיפוסיות. מסיר משימות מיקרו ממנהלי מערכת.

זה נחוץ ביותר או לאלו שרק מתחילים את דרכם, או לאלה שצריכים לעשות הרבה אוטומציה.

במה שונה הגישה מבוססת המפעיל ממערכות אחרות? יש הלם. זה גם עוזר להתקין את ClickHouse; אתה יכול לצייר תרשימי הגה, שאפילו יתקין אשכול ClickHouse שלם. מה אם כן ההבדל בין המפעיל לאותו, למשל, Helm?

ההבדל המהותי העיקרי הוא שהלם הוא ניהול חבילות והמפעיל הולך צעד קדימה. זוהי תמיכה לכל מחזור החיים. זו לא רק התקנה, אלו משימות יומיומיות הכוללות קנה מידה, פיצול, כלומר כל מה שצריך לעשות במהלך מחזור החיים (אם צריך, אז גם מחיקה) - כל זה נקבע על ידי המפעיל. הוא מנסה להפוך ולתחזק את כל מחזור חיי התוכנה. זהו ההבדל המהותי שלה מפתרונות אחרים המוצגים.

זה היה החלק המבוא, בואו נמשיך הלאה.

איך בונים את המפעיל שלנו? אנו מנסים לגשת לנושא כדי לנהל את אשכול ClickHouse כמשאב יחיד.

כאן יש לנו נתוני קלט בצד שמאל של התמונה. זהו YAML עם מפרט אשכול, המועבר ל-Kubernetes בצורה הקלאסית דרך kubectl. שם המפעיל שלנו מרים אותו ועושה את הקסם שלו. ובפלט אנו מקבלים את הסכימה הבאה. זהו יישום של ClickHouse ב-Kubernetes.

ואז נסתכל לאט לאט איך בדיוק עובד המפעיל, אילו משימות טיפוסיות ניתן לפתור. נשקול רק משימות טיפוסיות מכיוון שיש לנו זמן מוגבל. ולא כל מה שהמפעיל יכול להחליט ידון.

בואו נתחיל מהתרגול. הפרויקט שלנו הוא קוד פתוח לחלוטין, כך שתוכלו לראות איך הוא עובד ב-GitHub. ואתה יכול להמשיך מהשיקולים שאם אתה רק רוצה להפעיל אותו, אז אתה יכול להתחיל עם מדריך ההתחלה המהירה.

אם אתה רוצה להבין בפירוט, אז אנחנו מנסים לשמור על התיעוד בצורה פחות או יותר הגונה.

נתחיל בבעיה מעשית. המשימה הראשונה, שבה כולנו רוצים להתחיל, היא להפעיל את הדוגמה הראשונה איכשהו. איך אני יכול להפעיל את ClickHouse באמצעות המפעיל, גם אם אני לא ממש יודע איך זה עובד? אנחנו כותבים מניפסט, כי... כל תקשורת עם k8s היא תקשורת דרך מניפסטים.

זה מניפסט כל כך מורכב. מה שהדגשנו באדום הוא מה שאנחנו צריכים להתמקד בו. אנו מבקשים מהמפעיל ליצור אשכול בשם הדגמה.

אלו הן דוגמאות בסיסיות לעת עתה. אחסון עדיין לא תואר, אך נחזור לאחסון מעט מאוחר יותר. לעת עתה, נתבונן בדינמיקה של התפתחות האשכול.

יצרנו את המניפסט הזה. אנחנו מאכילים אותו למפעיל שלנו. הוא עבד, הוא עשה קסמים.

אנחנו מסתכלים על הקונסולה. שלושה מרכיבים מעניינים: Pod, שני שירותים ו-StatefulSet.

המפעיל עבד, ואנחנו יכולים לראות מה בדיוק הוא יצר.

הוא יוצר משהו כזה. יש לנו StatefulSet, Pod, ConfigMap לכל העתק, ConfigMap לכל האשכול. שירותים נדרשים כנקודות כניסה לאשכול.

השירותים הם שירות מאזן העומס המרכזי וניתן להשתמש בהם גם עבור כל העתק, עבור כל רסיס.

האשכול הבסיסי שלנו נראה בערך כך. זה מצומת אחד בודד.

בוא נלך רחוק יותר ונסבך את הדברים. אנחנו צריכים לגרוס את האשכול.

המשימות שלנו גדלות, הדינמיקה מתחילה. אנחנו רוצים להוסיף רסיס. אנחנו עוקבים אחר ההתפתחות. אנחנו משנים את המפרט שלנו. אנחנו מציינים שאנחנו רוצים שני רסיסים.

זהו אותו קובץ שמתפתח באופן דינמי עם צמיחת המערכת. אחסון לא, אחסון נדון בהמשך, זה נושא נפרד.

אנחנו מאכילים את המפעיל של YAML ונראה מה קורה.

המפעיל חשב ויצר את הישויות הבאות. יש לנו כבר שני Pods, שלושה שירותים ופתאום 2 StatefulSets. למה 2 StatefulSets?

בתרשים זה היה ככה - זה המצב ההתחלתי שלנו, כשהיה לנו תרמיל אחד.

זה הפך להיות ככה. עד כה הכל פשוט, הוא שוכפל.

ולמה הפכו לשני StatefulSets? כאן עלינו לסטות ולדון בשאלה כיצד מנוהלים Pods ב- Kubernetes.

יש אובייקט בשם StatefulSet שמאפשר ליצור סט של Pods מתבנית. גורם המפתח כאן הוא תבנית. ואתה יכול להפעיל Pods רבים באמצעות תבנית אחת ב-StatefulSet אחד. ומשפט המפתח כאן הוא "תרמילים רבים לתבנית אחת".

והיה פיתוי גדול ליצור את כל האשכול, לארוז אותו לתוך StatefulSet אחד. זה יעבוד, אין שום בעיה עם זה. אבל יש הסתייגות אחת. אם אנחנו רוצים להרכיב אשכול הטרוגני, כלומר מכמה גרסאות של ClickHouse, אז מתחילות לעלות שאלות. כן, StatefulSet יכול לבצע עדכון מתגלגל, ושם אתה יכול להוציא גרסה חדשה, להסביר שאתה צריך לנסות לא יותר מכל כך הרבה צמתים בו זמנית.

אבל אם ניקח את המשימה ונאמר שאנחנו רוצים ליצור אשכול הטרוגני לחלוטין ואנחנו לא רוצים לעבור מהגרסה הישנה לחדשה באמצעות עדכון מתגלגל, אלא אנחנו פשוט רוצים ליצור אשכול הטרוגני הן מבחינת של גרסאות שונות של ClickHouse ומבחינת אחסון שונה. אנחנו רוצים, למשל, ליצור כמה העתקים על דיסקים נפרדים, על איטיים, באופן כללי, לבנות אשכול הטרוגני לחלוטין. ובשל העובדה ש-StatefulSet מייצרת פתרון סטנדרטי מתבנית אחת, אין דרך לעשות זאת.

לאחר מחשבה, הוחלט שנעשה כך. יש לנו כל העתק ב-StatefulSet משלו. יש כמה חסרונות לפתרון הזה, אבל בפועל הכל מובלע לחלוטין על ידי המפעיל. ויש הרבה יתרונות. אנחנו יכולים לבנות את האשכול המדויק שאנחנו רוצים, למשל, אחד הטרוגני לחלוטין. לכן, באשכול שבו יש לנו שני רסיסים עם העתק אחד, יהיו לנו 2 StatefulSets ו-2 Pods בדיוק בגלל שבחרנו בגישה הזו מהסיבות שצוינו לעיל כדי להיות מסוגלים לבנות אשכול הטרוגני.

נחזור לבעיות מעשיות. באשכול שלנו אנחנו צריכים להגדיר משתמשים, כלומר. אתה צריך לבצע הגדרות מסוימות של ClickHouse ב-Kubernetes. המפעיל מספק את כל האפשרויות לכך.

אנחנו יכולים לכתוב מה שאנחנו רוצים ישירות ב-YAML. כל אפשרויות התצורה ממפות ישירות מ-YAML זה לתצורות ClickHouse, אשר מופצות לאחר מכן ברחבי האשכול.

אתה יכול לכתוב את זה ככה. זה למשל. ניתן להצפין את הסיסמה. לחלוטין כל אפשרויות התצורה של ClickHouse נתמכות. הנה רק דוגמה.

תצורת האשכול מופצת כ-ConfigMap. בפועל, עדכון ה-ConfigMap אינו מתרחש באופן מיידי, כך שאם האשכול גדול, תהליך דחיפת התצורה לוקח זמן מה. אבל כל זה מאוד נוח לשימוש.

בואו נסבך את המשימה. האשכול מתפתח. אנחנו רוצים לשכפל נתונים. כלומר, יש לנו כבר שני רסיסים, העתק אחד כל אחד, והמשתמשים מוגדרים. אנחנו גדלים ורוצים לעשות שכפול.

מה אנחנו צריכים לשכפול?

אנחנו צריכים ZooKeeper. ב-ClickHouse, השכפול נבנה באמצעות ZooKeeper. יש צורך ב-ZooKeeper כדי שלעתקים שונים של ClickHouse יהיה הסכמה לגבי אילו בלוקי נתונים נמצאים על איזה ClickHouse.

כל אחד יכול להשתמש ב-ZooKeeper. אם לארגון יש ZooKeeper חיצוני, ניתן להשתמש בו. אם לא, אתה יכול להתקין אותו מהמאגר שלנו. יש מתקין שמקל על כל העניין הזה.

ותרשים האינטראקציה של המערכת כולה מתברר כך. יש לנו Kubernetes כפלטפורמה. זה מפעיל את המפעיל ClickHouse. דמיינתי את ZooKeeper כאן. והמפעיל מקיים אינטראקציה גם עם ClickHouse וגם עם ZooKeeper. כלומר, תוצאות אינטראקציה.

וכל זה נחוץ ל-ClickHouse כדי לשכפל בהצלחה נתונים ב-k8s.

הבה נסתכל כעת על המשימה עצמה, כיצד ייראה המניפסט לשכפול.

אנו מוסיפים שני חלקים למניפסט שלנו. הראשון הוא היכן ניתן להשיג ZooKeeper, שיכול להיות בתוך Kubernetes או חיצוני. זה רק תיאור. ואנחנו מזמינים העתקים. הָהֵן. אנחנו רוצים שני העתקים. בסך הכל, אמורים להיות לנו 4 פודים במוצא. אנחנו זוכרים לגבי אחסון, זה יחזור קצת מאוחר יותר. אחסון הוא סיפור נפרד.

זה היה ככה.

זה הופך להיות ככה. מתווספים העתקים. הרביעי לא התאים, אנחנו מאמינים שיכולים להיות רבים מהם שם. ו-ZooKeeper מתווסף בצד. התוכניות הופכות מורכבות יותר.

וזה הזמן להוסיף את המשימה הבאה. נוסיף אחסון מתמשך.

עבור אחסון מתמשך יש לנו אפשרויות שונות.

אם אנחנו פועלים בספק ענן, למשל, באמצעות אמזון, גוגל, אז יש פיתוי גדול להשתמש באחסון בענן. זה מאוד נוח, זה טוב.

ויש אפשרות שניה. זה מיועד לאחסון מקומי, כאשר יש לנו דיסקים מקומיים בכל צומת. אפשרות זו הרבה יותר קשה ליישום, אך יחד עם זאת היא פרודוקטיבית יותר.

בוא נראה מה יש לנו לגבי אחסון בענן.

יש יתרונות. זה מאוד קל להגדיר. אנחנו פשוט מזמינים מספק הענן בבקשה לתת לנו אחסון של קיבולת כזו או אחרת, של מחלקה כזו ואחרת. השיעורים נקבעים על ידי ספקים באופן עצמאי.

ויש חיסרון. עבור חלק, זהו חיסרון לא קריטי. כמובן, יהיו כמה בעיות ביצועים. זה מאוד נוח לשימוש ואמין, אבל יש כמה חסרונות ביצועים פוטנציאליים.

ובגלל ClickHouse מתמקדת במיוחד בפריון, אפשר אפילו לומר שהיא סוחטת את כל מה שהיא יכולה, וזו הסיבה שלקוחות רבים מנסים לסחוט את הפרודוקטיביות המקסימלית.

וכדי להפיק ממנו את המרב, אנו זקוקים לאחסון מקומי.

Kubernetes מספקת שלוש הפשטות לשימוש באחסון מקומי ב- Kubernetes. זֶה:

• EmptyDir
• HostPath.
• מקומי

הבה נבחן כיצד הם שונים וכיצד הם דומים.

ראשית, בכל שלוש הגישות יש לנו אחסון - אלו דיסקים מקומיים הממוקמים באותו צומת k8s פיזי. אבל יש ביניהם כמה הבדלים.

נתחיל עם הפשוט ביותר, כלומר ריק דיר. מה זה בפועל? במפרט שלנו, אנו מבקשים ממערכת הקונטיינריזציה (לרוב Docker) לספק לנו גישה לתיקיה בדיסק המקומי.

בפועל, Docker יוצר תיקייה זמנית איפשהו לאורך הנתיבים שלה וקורא לה hash ארוך. ומספק ממשק לגישה אליו.

איך זה יעבוד מבחינת ביצועים? זה יעבוד במהירות דיסק מקומית, כלומר. זוהי גישה מלאה לבורג שלך.

אבל למקרה הזה יש חסרון. מתמיד הוא די מפוקפק בעניין הזה. בפעם הראשונה ש-Docker זז עם מכולות, Persistent אובד. אם Kubernetes רוצה להעביר את הפוד הזה לדיסק אחר מסיבה כלשהי, הנתונים יאבדו.

גישה זו טובה לבדיקות, כי היא כבר מציגה מהירות נורמלית, אבל למשהו רציני אפשרות זו אינה מתאימה.

לכן יש גישה שנייה. זה hostPath. אם תסתכל על השקף הקודם וזו, תוכל לראות רק הבדל אחד. התיקיה שלנו עברה מ-Docker ישירות לצומת Kubernetes. כאן זה קצת יותר פשוט. אנו מציינים ישירות את הנתיב במערכת הקבצים המקומית שבה נרצה לאחסן את הנתונים שלנו.

לשיטה זו יש יתרונות. זה כבר ממש Persistent, וגם קלאסי. יהיו לנו נתונים על הדיסק בכתובת כלשהי.

יש גם חסרונות. זו המורכבות של הניהול. ייתכן שה-Kubernetes שלנו ירצו להעביר את הפוד לצומת פיזי אחר. וכאן נכנסת לתמונה DevOps. הוא חייב להסביר נכון לכל המערכת שאפשר להעביר את התרמילים האלה רק לאותם צמתים שעליהם מותקן לך משהו לאורך השבילים האלה, ולא יותר מצמת אחד בכל פעם. זה די קשה.

במיוחד למטרות אלו, יצרנו תבניות במפעיל שלנו על מנת להסתיר את כל המורכבות הזו. ואתה יכול פשוט לומר: "אני רוצה שיהיה לי מופע אחד של ClickHouse לכל צומת פיזי ולאורך נתיב כזה ואחר".

אבל אנחנו לא היחידים שצריכים את הצורך הזה, אז גם האדונים מ-Kubernetes עצמה מבינים שאנשים רוצים לקבל גישה לדיסקים פיזיים, אז הם מספקים שכבה שלישית.

זה נקרא מקומי. אין כמעט הבדל מהשקופית הקודמת. רק לפני כן היה צורך לאשר ידנית שאיננו יכולים להעביר את התרמילים הללו מצומת לצומת, מכיוון שהם חייבים להיות מחוברים לאורך נתיב כלשהו לדיסק פיזי מקומי, אך כעת כל הידע הזה מובלע ב-Kubernetes עצמו. ומסתבר שזה הרבה יותר קל להגדיר.

נחזור לבעיה המעשית שלנו. נחזור לתבנית YAML. כאן יש לנו אחסון אמיתי. חזרנו לזה. קבענו את תבנית VolumeClaim הקלאסית כמו ב-k8s. ואנחנו מתארים איזה סוג של אחסון אנחנו רוצים.

לאחר מכן, k8s יבקש אחסון. יקצה לנו אותו ב-StatefulSet. ובסופו של דבר הוא יעמוד לרשות קליקהאוס.

הייתה לנו את התוכנית הזו. האחסון המתמשך שלנו היה אדום, מה שנראה היה רמז שצריך לעשות זאת.

והוא הופך לירוק. כעת ערכת האשכול של ClickHouse on k8s הושלמה לחלוטין. יש לנו רסיסים, העתקים, ZooKeeper, יש לנו Persistent אמיתי, שמיושם בצורה כזו או אחרת. התוכנית כבר פועלת במלואה.

אנחנו ממשיכים לחיות. האשכול שלנו מתפתח. ואלכסיי מנסה, ומשחרר גרסה חדשה של ClickHouse.

מתעוררת משימה מעשית - לבדוק את הגרסה החדשה של ClickHouse באשכול שלנו. ובאופן טבעי, אתה לא רוצה לגלגל את הכל; אתה רוצה לשים גרסה חדשה בהעתק אחד איפשהו בפינה הרחוקה, ואולי לא גרסה חדשה אחת, אלא שתיים בבת אחת, כי הן יוצאות לעתים קרובות.

מה אנחנו יכולים להגיד על זה?

כאן יש לנו בדיוק הזדמנות כזו. אלו תבניות פוד. אתה יכול לכתוב שהמפעיל שלנו לגמרי מאפשר לך לבנות אשכול הטרוגני. הָהֵן. להגדיר, החל מכל העתקים בחבורה, וכלה בכל העתק אישי, איזו גרסה אנחנו רוצים את ClickHouse, איזו גרסה אנחנו רוצים אחסון. אנחנו יכולים להגדיר את האשכול באופן מלא עם התצורה שאנחנו צריכים.

בואו ניכנס קצת יותר עמוק פנימה. לפני זה, דיברנו על האופן שבו ClickHouse-operator עובד ביחס לפרטים הספציפיים של ClickHouse.

עכשיו אני רוצה לומר כמה מילים על איך כל מפעיל עובד באופן כללי, כמו גם איך הוא מתקשר עם K8s.

בואו נסתכל תחילה על אינטראקציה עם ה-K8s. מה קורה כשאנחנו מיישמים kubectl? האובייקטים שלנו מופיעים ב-etcd דרך ה-API.

לדוגמה, אובייקטים בסיסיים של Kubernetes: pod, StatefulSet, service וכן הלאה למטה ברשימה.

יחד עם זאת, שום דבר פיזי עדיין לא קורה. חפצים אלה חייבים להתממש באשכול.

לשם כך, מופיע בקר. הבקר הוא רכיב k8s מיוחד שיכול לממש את התיאורים הללו. הוא יודע איך ומה לעשות פיזית. הוא יודע להפעיל קונטיינרים, מה צריך להגדיר שם כדי שהשרת יעבוד.

וזה מממש את החפצים שלנו ב-K8s.

אבל אנחנו רוצים לפעול לא רק עם פודים ו-StatefulSets, אנחנו רוצים ליצור ClickHouseInstallation, כלומר אובייקט מסוג ClickHouse, כדי לפעול איתו כמכלול אחד. בינתיים אין אפשרות כזו.

אבל ל-K8s יש את הדבר הנחמד הבא. אנחנו רוצים שיהיה לנו מקום כמו הישות המורכבת הזו שבה האשכול שלנו יורכב מ-pods ו-StatefulSet.

ומה צריך לעשות בשביל זה? ראשית, הגדרת משאבים מותאמת אישית נכנסת לתמונה. מה זה? זהו תיאור עבור K8s, שיהיה לך עוד סוג נתונים אחד, שאנו רוצים להוסיף משאב מותאם אישית לפוד, StatefulSet, שיהיה מורכב בפנים. זהו תיאור של מבנה הנתונים.

אנחנו גם שולחים אותו לשם באמצעות kubectl applily. Kubernetes קיבל את זה בשמחה.

ועכשיו באחסון שלנו, לאובייקט ב-etcd יש הזדמנות להקליט משאב מותאם אישית בשם ClickHouseInstallation.

אבל בינתיים שום דבר לא יקרה יותר. כלומר, אם כעת ניצור את קובץ ה-YAML שהסתכלנו עליו המתאר רסיסים והעתקים ונאמר "kubectl application", אז Kubernetes יקבל את זה, יכניס אותו ל-etcd ויגיד: "מצוין, אבל אני לא יודע מה לעשות עם זה. אני לא יודע איך לתחזק את ClickHouse Installation."

בהתאם לכך, אנו זקוקים למישהו שיעזור ל-Kubernetes לשרת את סוג הנתונים החדש. בצד שמאל יש לנו בקר Kubernetes מקורי שעובד עם סוגי נתונים מקוריים. ובצד ימין צריך שיהיה לנו בקר מותאם אישית שיכול לעבוד עם סוגי נתונים מותאמים אישית.

ובאופן אחר זה נקרא מפעיל. כללתי את זה כאן במיוחד בתור Kubernetes, כי זה יכול להתבצע גם מחוץ ל-K8s. לרוב, כמובן, כל המפעילים מבוצעים ב-Kubernetes, אבל שום דבר לא מונע ממנו לעמוד בחוץ, אז כאן הוא מועבר במיוחד החוצה.

ובתורו, הבקר המותאם אישית, הידוע גם כמפעיל, מקיים אינטראקציה עם Kubernetes באמצעות ה-API. זה כבר יודע איך לקיים אינטראקציה עם ה-API. והוא כבר יודע איך לממש את המעגל המורכב שאנחנו רוצים לעשות ממשאב מותאם אישית. זה בדיוק מה שהמפעיל עושה.

איך המפעיל עובד? בוא נסתכל בצד ימין כדי לראות איך הוא עושה את זה. בואו לגלות איך המפעיל מממש את כל זה וכיצד מתרחשת אינטראקציה נוספת עם K8s.

מפעיל הוא תוכנית. היא מכוונת לאירועים. המפעיל נרשם לאירועים באמצעות ה-API של Kubernetes. לממשק ה-API של Kubernetes יש נקודות כניסה שבהן אתה יכול להירשם לאירועים. ואם משהו משתנה ב-K8s, אז Kubernetes שולח אירועים לכולם, כלומר. מי שנרשם לנקודת API זו יקבל הודעות.

המפעיל מנוי לאירועים וחייב לבצע תגובה כלשהי. המשימה שלו היא להגיב לאירועים המתהווים.

אירועים נוצרים על ידי עדכונים מסוימים. מגיע קובץ YAML שלנו עם תיאור של ClickHouse Installation. הוא הלך ל-etcd דרך kubectl application. אירוע הופעל שם, וכתוצאה מכך אירוע זה הגיע ל-ClickHouse-מפעיל. המפעיל קיבל את התיאור הזה. והוא חייב לעשות משהו. אם הגיע עדכון לאובייקט ClickHouseInstallation, עליך לעדכן את האשכול. ומשימתו של המפעיל היא לעדכן את האשכול.

מה הוא עושה? ראשית, עלינו לגבש תוכנית פעולה למה שנעשה עם העדכון הזה. עדכונים יכולים להיות קטנים מאוד, כלומר. קטן בביצוע YAML, אבל יכול לגרור שינויים גדולים מאוד באשכול. לכן, המפעיל יוצר תוכנית, ואז הוא דבק בה.

על פי תוכנית זו, הוא מתחיל לבשל את המבנה הזה בפנים כדי לממש תרמילים, שירותים, כלומר. לעשות את המשימה העיקרית שלו. כך בונים אשכול ClickHouse ב-Kubernetes.

עכשיו בואו ניגע בדבר כל כך מעניין. מדובר בחלוקת אחריות בין Kubernetes למפעיל, כלומר. מה Kubernetes עושה, מה המפעיל עושה, וכיצד הם מקיימים אינטראקציה זה עם זה.

Kubernetes אחראי על דברים מערכתיים, כלומר. עבור קבוצה בסיסית של אובייקטים שניתן לפרש כ-system-scope. Kubernetes יודע להפעיל פודים, איך להפעיל מחדש קונטיינרים, איך להעלות נפחים, איך לעבוד עם ConfigMap, כלומר. כל מה שאפשר לקרוא לו מערכת.

המפעילים פועלים בתחומים. כל מפעיל מיועד לתחום הנושא שלו. עשינו את זה עבור ClickHouse.

והמפעיל מקיים אינטראקציה בדיוק מבחינת תחום הנושא, כמו הוספת העתק, יצירת דיאגרמה, הגדרת ניטור. זה מביא לחלוקה.

בואו נסתכל על דוגמה מעשית לאופן שבו חלוקת אחריות זו מתרחשת כאשר אנו מבצעים את פעולת ההוספה העתק.

המפעיל מקבל משימה - להוסיף העתק. מה עושה המפעיל? המפעיל יחשב שצריך ליצור StatefulSet חדש, שבו יש לתאר תבניות כאלה ואחרות, טענת נפח.

הוא הכין הכל ומעביר ל-K8s. הוא אומר שהוא צריך ConfigMap, StatefulSet, Volume. Kubernetes עובד. הוא מממש את היחידות הבסיסיות איתן הוא פועל.

ואז מפעיל ClickHouse נכנס שוב לתמונה. יש לו כבר תרמיל פיזי עליו הוא כבר יכול לעשות משהו. ו-ClickHouse-operator שוב עובד במונחים של תחום. הָהֵן. ספציפית ClickHouse, על מנת לכלול העתק באשכול, עליך, ראשית, להגדיר את סכימת הנתונים שקיימת באשכול זה. ושנית, העתק זה חייב להיכלל בניטור כך שניתן יהיה לאתר אותו בבירור. המפעיל כבר מגדיר זאת.

ורק אחרי זה ClickHouse עצמו נכנס לתמונה, כלומר. עוד ישות ברמה גבוהה יותר. זה כבר מסד נתונים. יש לו מופע משלו, עותק מוגדר נוסף שמוכן להצטרף לאשכול.

מסתבר ששרשרת ביצוע וחלוקת אחריות בעת הוספת העתק היא ארוכה למדי.

אנו ממשיכים במשימות המעשיות שלנו. אם כבר יש לך אשכול, אתה יכול להעביר את התצורה.

הפכנו את זה כך שתוכלו להדביק דרך xml קיים, ש-ClickHouse מבינה.

אתה יכול לכוונן את ClickHouse. רק פריסה אזורית זה מה שדיברתי עליו כשהסברתי את hostPath, אחסון מקומי. כך עושים פריסה אזורית בצורה נכונה.

המשימה המעשית הבאה היא ניטור.

אם האשכול שלנו משתנה, אז אנחנו צריכים להגדיר מעת לעת ניטור.

הבה נתבונן בתרשים. כבר הסתכלנו כאן על החצים הירוקים. עכשיו בואו נסתכל על החצים האדומים. כך אנחנו רוצים לפקח על האשכול שלנו. כיצד מדדים מאשכול ClickHouse מגיעים ל-Prometheus, ולאחר מכן ל-Grafana.

מה הקושי במעקב? למה זה מוצג כאיזשהו הישג? הקושי טמון בדינמיקה. כשיש לנו אשכול אחד והוא סטטי אז אנחנו יכולים להגדיר ניטור פעם אחת ולא לטרוח יותר.

אבל אם יש לנו הרבה אשכולות, או שמשהו משתנה כל הזמן, אז התהליך הוא דינמי. וכל הזמן להגדיר מחדש את הניטור הוא בזבוז של משאבים וזמן, כלומר. אפילו רק עצלות. זה צריך להיות אוטומטי. הקושי טמון בדינמיקה של התהליך. והמפעיל ממכן את זה טוב מאוד.

איך התפתח האשכול שלנו? בהתחלה הוא היה כזה.

ואז הוא היה כזה.

בסוף הוא נהיה כזה.

והניטור נעשה באופן אוטומטי על ידי המפעיל. נקודת כניסה יחידה.

ובדיוק ביציאה אנחנו מסתכלים על לוח המחוונים של Grafana כדי לראות איך החיים של האשכול שלנו רותחים בפנים.

אגב, לוח המחוונים של Grafana מופץ גם עם המפעיל שלנו ישירות בקוד המקור. אתה יכול להתחבר ולהשתמש. DevOps שלנו נתן לי את צילום המסך הזה.

לאן נרצה ללכת הלאה? זֶה:

• פיתוח אוטומציה של בדיקות. המשימה העיקרית היא בדיקה אוטומטית של גרסאות חדשות.
• אנחנו גם מאוד רוצים להפוך את האינטגרציה לאוטומטית עם ZooKeeper. ויש תוכניות להשתלב עם ZooKeeper-operator. הָהֵן. נכתב מפעיל עבור ZooKeeper והגיוני ששני המפעילים מתחילים להשתלב כדי לבנות פתרון נוח יותר.
• אנחנו רוצים לעשות סימנים חיוניים מורכבים יותר.
• הדגשתי בירוק שאנחנו מתקרבים להורשה של תבניות - DONE, כלומר עם הגרסה הבאה של המפעיל כבר תהיה לנו ירושה של תבניות. זהו כלי רב עוצמה המאפשר לבנות תצורות מורכבות מחתיכות.
• ואנחנו רוצים אוטומציה של משימות מורכבות. העיקרי שבהם הוא Re-sharding.

בואו ניקח כמה תוצאות ביניים.

מה אנחנו מקבלים כתוצאה מכך? והאם כדאי לעשות או לא? האם בכלל יש צורך לנסות לגרור את בסיס הנתונים לתוך Kubernetes ולהשתמש באופרטור בכלל ובאופרטור Alitnity בפרט?

בפלט אנו מקבלים:

• פישוט משמעותי ואוטומציה של תצורה, פריסה ותחזוקה.
• ניטור מובנה באופן מיידי.
• ותבניות מוכנות לשימוש עבור מצבים מורכבים. פעולה כמו הוספת עותק לא צריכה להיעשות באופן ידני. המפעיל עושה זאת.

נותרה רק שאלה אחרונה. יש לנו כבר מסד נתונים ב-Kubernetes, וירטואליזציה. מה לגבי הביצועים של פתרון כזה, במיוחד מכיוון ש-ClickHouse מותאם לביצועים?

התשובה היא שהכל בסדר! אני לא אפרט, זה הנושא של דו"ח נפרד.

אבל יש פרויקט כזה כמו TSBS. מה המשימה העיקרית שלו? זהו מבחן ביצועי מסד נתונים. זהו ניסיון להשוות בין חם לחום, רך לרך.

איך הוא עובד? נוצר מערך נתונים אחד. אז קבוצת נתונים זו מופעלת על מסדי נתונים שונים באמצעות אותה קבוצת בדיקות. וכל מסד נתונים פותר בעיה אחת בצורה שהוא יודע איך. ואז אתה יכול להשוות את התוצאות.

זה כבר תומך בחבורה גדולה של מסדי נתונים. זיהיתי שלושה עיקריים. זֶה:

• TimescaleDB.
• InfluxDB.
• קליקהאוס.

בוצעה השוואה גם לפתרון דומה אחר. השוואה עם RedShift. ההשוואה נעשתה באמזון. ClickHouse גם מקדימה בהרבה את כולם בעניין הזה.

אילו מסקנות אפשר להסיק ממה שאמרתי?

• DB ב-Kubernetes אפשרי. כנראה כל דבר אפשרי, אבל בסך הכל נראה שזה אפשרי. ClickHouse ב-Kubernetes בהחלט אפשרי בעזרת המפעיל שלנו.
• המפעיל עוזר לבצע אוטומציה של תהליכים ובאמת מקל על החיים.
• הביצועים נורמליים.
• ונראה לנו שאפשר וצריך להשתמש בזה.

קוד פתוח - הצטרפו אלינו!

כפי שכבר אמרתי, המפעיל הוא מוצר קוד פתוח לחלוטין, אז זה יהיה טוב מאוד אם המספר המקסימלי של אנשים ישתמש בו. הצטרף אלינו! אנחנו מחכים לכולכם!

תודה לכולכם!

שאלות

תודה על הדיווח! שמי אנטון. אני מ-SEMrush. אני תוהה מה קורה עם רישום. אנחנו שומעים על ניטור, אבל שום דבר על רישום, אם אנחנו מדברים על האשכול כולו. לדוגמה, העלינו אשכול על חומרה. ואנחנו משתמשים ברישום מרכזי, אוספים אותם לערימה משותפת באמצעים סטנדרטיים. ומשם אנחנו מקבלים את הנתונים שמעניינים אותנו.

שאלה טובה, כלומר כניסה לרשימת מטלות. המפעיל שלנו עדיין לא עושה זאת אוטומטית. הוא עדיין מתפתח, הפרויקט עדיין די צעיר. אנו מבינים את הצורך ברישום. זה גם נושא חשוב מאוד. וזה כנראה לא פחות חשוב מהניטור. אבל הראשון ברשימה ליישום היה ניטור. תהיה רישום. באופן טבעי, אנו מנסים להפוך את כל ההיבטים של חיי האשכול לאוטומטיים. לכן, התשובה היא שכרגע המפעיל, לצערנו, לא יודע איך לעשות זאת, אבל זה בתוכניות, אנחנו נעשה את זה. אם אתה רוצה להצטרף, בבקשה למשוך בקשה.

שלום! תודה על הדיווח! יש לי שאלה סטנדרטית הקשורה לנפחים מתמידים. כאשר אנו יוצרים תצורה עם האופרטור הזה, איך האופרטור קובע באיזה צומת יש לנו דיסק או תיקיה מסויימים? אנחנו חייבים קודם כל להסביר לו בבקשה למקם את ה-ClickHouse שלנו על הצמתים האלה שיש להם דיסק?

למיטב הבנתי, השאלה הזו היא המשך של אחסון מקומי, במיוחד החלק של hostPath שלו. זה כמו להסביר לכל המערכת שצריך להפעיל את הפוד על צומת כזה ואחר, שאליו יש לנו דיסק מחובר פיזית, שמותקן לאורך נתיב כזה ואחר. זה קטע שלם שנגעתי בו בצורה מאוד שטחית כי התשובה שם די גדולה.

בקצרה זה נראה כך. כמובן, אנחנו צריכים לספק את הכרכים האלה. כרגע, אין הפרשה דינמית באחסון מקומי, אז DevOps חייב לחתוך את הדיסקים עצמם, אמצעי האחסון הללו. והם חייבים להסביר את ההקצאה של Kubernetes שיהיו לך נפחים מתמידים של מחלקה כזו ואחרת, שממוקמים על צמתים כאלה ואחרים. לאחר מכן תצטרכו להסביר ל-Kubernetes שתרמילים שדורשים מחלקת אחסון מקומית כזו או אחרת צריכים להיות מופנים רק לצמתים כאלה ואחרים באמצעות תוויות. למטרות אלו, למפעיל יש את היכולת להקצות סוג כלשהו של תווית ואחת לכל מופע מארח. ומסתבר שהפודים ינותבו על ידי Kubernetes לרוץ רק על צמתים שעומדים בדרישות, התוויות, במילים פשוטות. מנהלי מערכת מקצים תוויות ודיסקים להקצאה באופן ידני. ואז זה מתרחב.

וזו האפשרות השלישית, מקומית, שעוזרת לעשות את זה קצת יותר קל. כפי שכבר הדגשתי, מדובר בעבודה קפדנית על כוונון, שעוזרת בסופו של דבר להשיג ביצועים מקסימליים.

יש לי שאלה שנייה שקשורה לזה. Kubernetes תוכנן בצורה כזו שלא משנה לנו אם נאבד צומת או לא. מה עלינו לעשות במקרה זה אם איבדנו את הצומת שבו תלוי הרסיס שלנו?

כן, Kubernetes התמקם בתחילה שהיחסים שלנו עם התרמילים שלנו הם כמו בקר, אבל כאן איתנו כל דיסק הופך למשהו כמו חיית מחמד. יש בעיה כזו שאנחנו לא יכולים פשוט לזרוק אותם. והפיתוח של Kubernetes הולך לכיוון שאי אפשר להתייחס אליו באופן פילוסופי, כאילו היה זה משאב מושלך לחלוטין.

עכשיו לשאלה מעשית. מה לעשות אם איבדת את הצומת שעליו היה הדיסק? כאן הבעיה נפתרת ברמה גבוהה יותר. במקרה של ClickHouse, יש לנו העתקים שעובדים ברמה גבוהה יותר, כלומר. ברמת קליקהאוס.

מהי הנטייה המתקבלת? DevOps אחראית להבטיח שהנתונים לא יאבדו. עליו להגדיר את השכפול בצורה נכונה ועליו לוודא שהרפליקציה פועלת. העתק ברמת ClickHouse חייב להיות בעל נתונים משוכפלים. זו לא המשימה שהמפעיל פותר. ולא הבעיה שקוברנטס בעצמה פותרת. זה ברמת ClickHouse.

מה לעשות אם צומת הברזל שלך נופל? ומסתבר שתצטרך להתקין אחד שני, לספק את הדיסק עליו כראוי ולהדביק תוויות. ואחרי זה, הוא יעמוד בדרישות ש- Kubernetes יכול להשיק עליו פוד מופע. Kubernetes תשיק אותו. מספר התרמילים שלך אינו מספיק כדי לעמוד במספר שצוין. זה יעבור את המחזור שהראיתי. וברמה הגבוהה ביותר, ClickHouse תבין שהכנסנו רפליקה, היא עדיין ריקה וצריך להתחיל להעביר אליה נתונים. הָהֵן. תהליך זה עדיין אינו אוטומטי היטב.

תודה על הדיווח! כשקורים כל מיני דברים מגעילים, המפעיל קורס ומתחיל מחדש, ובאותו רגע מגיעים אירועים, אתה איכשהו מתמודד עם זה?

מה קורה אם המפעיל קורס ומופעל מחדש, נכון?

כן. ובאותו רגע הגיעו אירועים.

המשימה של מה לעשות במקרה זה מתחלקת בחלקה בין המפעיל לבין Kubernetes. ל-Kubernetes יש את היכולת להפעיל מחדש אירוע שהתרחש. הוא משחזר. ומשימתו של המפעיל היא לוודא שכאשר יומן האירועים מושמע עליו, האירועים הללו הם חסרי כוח. וכדי שההתרחשות החוזרת של אותו אירוע לא תשבור את המערכת שלנו. והמפעיל שלנו מתמודד עם המשימה הזו.

שלום! תודה על הדיווח! דמיטרי זביאלוב, חברה סמדובה. האם יש תוכניות להוסיף למפעיל את היכולת להגדיר עם פרוקסי? הייתי מעוניין באיזון אחר מלבד הסטנדרטי, כדי שיהיה חכם ויבין ש-ClickHouse באמת שם.

אתה מדבר על אינגרס?

כן, החלף את Ingress בהפרוקסי. בהפרוקסי ניתן לציין את הטופולוגיה של האשכול היכן שיש לו העתקים.

עוד לא חשבנו על זה. אם אתה צריך את זה ויכול להסביר למה זה נחוץ, אז אפשר יהיה ליישם את זה, במיוחד אם אתה רוצה להשתתף. נשמח לשקול את האופציה. התשובה הקצרה היא לא, כרגע אין לנו פונקציונליות כזו. תודה על הטיפ, נבדוק את הנושא. ואם תסביר גם את מקרה השימוש ומדוע הוא נחוץ בפועל, למשל, תיצור בעיות ב-GitHub, אז זה יהיה נהדר.

כבר.

בסדר גמור. אנו פתוחים לכל הצעה. והפרוקסי מתווסף לרשימת המשימות. רשימת המטלות הולכת וגדלה, עדיין לא מתכווצת. אבל זה טוב, זה אומר שהמוצר מבוקש.

מקור: www.habr.com