ילדה על קטנוע. אִיוּר Freepik, לוגו Nomad מ Hashi Corp

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

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

מה אתה רוצה

הצוות שלנו תומך במספר שירותי ניטור וניתוח ביצועים נפוצים: נקודות קצה API עבור מדדים שנכתבו ב-Go, ייצוא Prometheus, מנתחי יומנים כגון Logstash ו גולום, כמו גם מסדי נתונים כגון InfluxDB או Elasticsearch. כל אחד מהשירותים הללו פועל במיכל משלו. אנחנו צריכים מערכת פשוטה כדי לשמור על הכל.

התחלנו עם רשימה של דרישות לתזמור מכולה:

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

בנוסף, הדברים הבאים יהיו נחמדים, אך לא תוספות נדרשות:

• מכונות תיוג על סמך היכולות שלהן (למשל, מכונות תיוג עם דיסקים מהירים לשירותי I/O כבדים).
• יכולת להפעיל שירותים ללא תלות במתזמר (למשל במהלך פיתוח).
• מקום משותף לשיתוף תצורות וסודות.
• נקודת קצה למדדים ויומנים.

למה Kubernetes לא מתאים לנו

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

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

בנוסף, המערכת האקולוגית של Kubernetes מתפתחת במהירות. זה לוקח הרבה זמן ואנרגיה כדי להישאר מעודכן עם שיטות עבודה מומלצות והכלים העדכניים ביותר. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - הרשימה עוד ארוכה. לא כל הכלים האלה נחוצים כשאתה מתחיל, אבל אתה לא יודע מה תצטרך, אז אתה צריך להיות מודע להכל. בגלל זה, עקומת הלמידה די תלולה.

מתי להשתמש ב-Kubernetes

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

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

• מְפוֹרָט ניהול זכויות.
• בקרים מותאמים אישית להוסיף היגיון לאשכול. אלו פשוט תוכנות שמדברות עם ה-API של Kubernetes.
• קנה מידה אוטומטי! Kubernetes יכולה להרחיב שירותים לפי דרישה באמצעות מדדי שירות וללא צורך בהתערבות ידנית.

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

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

סוללות לא כלולות

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

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

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

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

מערכת אקולוגית נוודים של רכיבים מחוברים באופן רופף

החוזק האמיתי של נווד הוא המערכת האקולוגית שלו. הוא משתלב היטב עם מוצרים אחרים - אופציונליים לחלוטין - כגון קוֹנסוּל (חנות מפתח-ערך) או קמרון (עיבוד סודות). בתוך קובץ Nomad ישנם קטעים לחילוץ נתונים משירותים אלה:

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

כאן קראנו את המפתח service/geo-api/log-verbosity מ-Consul ובזמן העבודה אנו חושפים אותו למשתנה סביבתי LOG_LEVEL. אנו מציגים גם את המפתח secret/geo-api-key מ-Vault as API_KEY. פשוט אבל חזק!

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

יש עוד דוגמאות רבות להרחבה:

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

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

אזהרה הוגנת

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

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

תקציר

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

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

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

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

מקור: www.habr.com