האם קפקא ב-Kubernetes טוב?

שלום רב, הבר!

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

מבוא

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

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

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

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

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

זמן ההשלמה

בואו נדבר על הדבר הבסיסי – סביבת זמן הריצה עצמה

תהליך

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

זיכרון

מתווכים של קפקא אוכלים זיכרון. גודל ערימת ה-JVM מוגבל בדרך כלל ל-4-5 ג'יגה-בייט, אך תזדקק גם לזיכרון מערכת רב מכיוון שקפקא משתמש במטמון העמודים בכבדות רבה. ב-Kubernetes, הגדר מגבלות של משאבי מיכל ובקשות בהתאם.

מחסן נתונים

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

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

רשת

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

תְצוּרָה

מניפסטים קבועים

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

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

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

תרשימי הגה

Helm הוא מנהל חבילות עבור Kubernetes שניתן להשוות למנהלי חבילות מערכת הפעלה כגון yum, apt, Homebrew או Chocolatey. זה מקל על התקנת חבילות תוכנה מוגדרות מראש המתוארות בתרשימים של Helm. טבלת Helm שנבחרה היטב הופכת את המשימה הקשה של איך להגדיר נכון את כל הפרמטרים לשימוש בקפקא ב-Kubernetes לקלה. יש כמה דיאגרמות של קפקא: הרשמי נמצא במצב אינקובטור, יש אחד מ צומת, עוד אחד - מ Bitnami.

אופרטורים

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

В списке מפעילים מדהימים מוזכרים שני מפעילים של קפקא. אחד מהם - סטרימזי. עם Strimzi, קל להפעיל את אשכול קפקא שלך תוך דקות. כמעט ולא נדרשת תצורה, בנוסף, המפעיל עצמו מספק כמה תכונות נחמדות, למשל, הצפנת TLS מנקודה לנקודה בתוך האשכול. Confluent מספק גם מפעיל משלו.

פרודוקטיביות

חשוב לבחון את הביצועים על ידי השוואת מופע קפקא שלך. בדיקות כאלה יעזרו לך למצוא צווארי בקבוק פוטנציאליים לפני שיתרחשו בעיות. למרבה המזל, קפקא כבר מספק שני כלים לבדיקת ביצועים: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. עשה בהם שימוש פעיל. לעיון, אתה יכול לעיין בתוצאות המתוארות ב הפוסט הזה ג'יי קרפס, או להתמקד סקירה זו אמזון MSK מאת סטפן מארק.

פעולות

ניטור

שקיפות במערכת חשובה מאוד - אחרת לא תבינו מה קורה בה. כיום יש ערכת כלים מוצקה המספקת ניטור מבוסס מדדים בסגנון native בענן. שני כלים פופולריים למטרה זו הם פרומתאוס וגרפאנה. פרומתאוס יכול לאסוף מדדים מכל תהליכי Java (Kafka, Zookeeper, Kafka Connect) באמצעות יצואן JMX - בצורה הפשוטה ביותר. אם תוסיף מדדי cAdvisor, תוכל להבין יותר כיצד נעשה שימוש במשאבים ב-Kubernetes.

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

מקור: streamzi.io/docs/master/#kafka_dashboard

זה יהיה נחמד להשלים את כל זה עם ניטור לקוחות (מדדים על צרכנים ויצרנים), כמו גם ניטור חביון (בשביל זה יש לִנְבּוּר) וניטור מקצה לקצה - לשימוש זה קפקא מוניטור.

רישום

רישום הוא עוד משימה קריטית. ודא שכל המיכלים בהתקנת Kafka שלך מחוברים stdout и stderr, וגם להבטיח שאשכול Kubernetes שלך אוסף את כל היומנים לתוך תשתית רישום מרכזית, למשל. Elasticsearch.

בדיקת בריאות

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

הפקת עדכונים

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

שינוי קנה מידה

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

מינהל

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

גיבוי ושחזור

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

מסקנה

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

מקור: www.habr.com