שיטות עבודה מומלצות של Kubernetes. ארגון Kubernetes עם מרחב שמות

שיטות עבודה מומלצות של Kubernetes. יצירת מיכלים קטנים

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

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

ברוב ההפצות של Kubernetes, האשכול יוצא מהקופסה עם מרחב שמות שנקרא "ברירת מחדל". למעשה ישנם שלושה מרחבי שמות שבהם עוסק Kubernetes: ברירת מחדל, kube-system ו-kube-public. נכון לעכשיו, Kube-public אינו נמצא בשימוש לעתים קרובות במיוחד.

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

לכן, עליך ליצור מרחבי שמות מרובים ולהשתמש בהם כדי לפלח את השירותים שלך ליחידות הניתנות לניהול. ניתן ליצור מרחב שמות בפקודה אחת. אם ברצונך ליצור מרחב שמות בשם מבחן, השתמש בפקודה $ kubectl create space test או פשוט צור קובץ YAML והשתמש בו כמו כל משאב אחר של Kubernetes.

אתה יכול להציג את כל מרחבי השמות באמצעות הפקודה $ kubectl getspace.

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

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

הדרך השנייה היא לציין את מרחב השמות בהצהרת YAML.

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

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

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

כדי להחליף את מרחב השמות הפעיל למרחב השמות של הבדיקה, אתה פשוט מפעיל את פקודת הבדיקה $kubens. אם לאחר מכן תפעיל שוב את הפקודה $kubens, תראה שמוקצה כעת מרחב שמות פעיל חדש - test.

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

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

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

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

בדרך כלל, אתה רק צריך את שם השירות וה-DNS יקבע אוטומטית את הכתובת המלאה.

עם זאת, אם אתה צריך לגשת לשירות במרחב שמות אחר, פשוט השתמש בשם השירות בתוספת שם מרחב השמות:

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

אם ברצונך להתחבר למסד הנתונים של השירות במרחב השמות של prod, אתה משתמש ב-database.prod.

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

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

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

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

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

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

בחברות גדולות, מפתחים בדרך כלל לא יודעים מי בדיוק עובד על מה. צוותים מתקשרים באמצעות חוזי שירות או משתמשים בטכנולוגיית רשת שירות, אשר מוסיפה שכבת הפשטה על גבי הרשת, כגון כלי התצורה של Istio. ניסיון להריץ מחסנית שלמה באופן מקומי פשוט לא אפשרי. אני ממליץ בחום להשתמש בפלטפורמת משלוח מתמשך (CD) כמו Spinnaker ב-Kubernetes. אז מגיע שלב שבו כל פקודה בהחלט צריכה מרחב שמות משלה. כל צוות יכול אפילו לבחור מרחבי שמות מרובים עבור סביבת ה-dev וסביבת ה-prod.

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

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

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

שיטות עבודה מומלצות של Kubernetes. אימות חיים של Kubernetes עם מבחני מוכנות וחיוניות

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com