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

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

אם אתה כמו רוב האנשים, כנראה שאתה משתמש במשאבים הפועלים מחוץ לאשכול שלך. אולי אתה משתמש ב-Taleo API כדי לשלוח הודעות טקסט, או לנתח תמונות באמצעות Google Cloud Vision API.

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

דוגמה לשירות חיצוני נפוץ היא מסד נתונים הפועל מחוץ לאשכול Kubernetes. שלא כמו מסדי נתונים בענן כמו Google Cloud Data Store או Google Cloud Spanner, המשתמשים בנקודת קצה אחת לכל גישה, לרוב מסדי הנתונים יש נקודות קצה נפרדות לנסיבות שונות.
שיטות עבודה מומלצות לשימוש במסדי נתונים מסורתיים כגון MySQL ו-MongoDB אומרות בדרך כלל שאתה מתחבר לרכיבים שונים עבור סביבות שונות. אתה יכול לקבל מכונה גדולה עבור נתוני ייצור ומכונה קטנה יותר עבור סביבת הבדיקה. לכל אחד מהם תהיה כתובת IP או שם דומיין משלו, אך סביר להניח שלא תרצו לשנות את הקוד שלכם בעת מעבר מסביבה אחת לאחרת. אז במקום לקוד קשיח של כתובות אלה, אתה יכול להשתמש בגילוי שירות חיצוני מבוסס DNS המובנה של Kubernetes באותו אופן כמו שירותי Kubernetes מקוריים.

נניח שאתה מפעיל מסד נתונים MongoDB ב-Google Compute Engine. אתה תהיה תקוע בעולם ההיברידי הזה עד שתצליח להעביר אותו לאשכול.

למרבה המזל, אתה יכול להשתמש בשירותי Kubernetes סטטיים כדי להקל על חייך. בדוגמה זו, יצרתי שרת MongoDB באמצעות Google Cloud Launcher. מכיוון שהוא נוצר באותה רשת (או Kubernetes cluster VPC), הגישה אליו מתבצעת באמצעות כתובת IP פנימית בעלת ביצועים גבוהים.

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

דוגמא הקוד הבאה מראה שנקודות הקצה קובעות את כתובת ה-IP עבור מסד הנתונים תוך שימוש באותו שם מונגו כמו השירות.

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

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

אם אתה משתמש במסד נתונים המתארח במארח של צד שלישי, סביר להניח שבעלי המארח סיפקו לך URI Uniform Resource Identifier להתחבר אליו. אז אם קיבלת כתובת IP, אתה יכול פשוט להשתמש בשיטה הקודמת. דוגמה זו מראה שיש לי שני מסדי נתונים של MongoDB המתארחים על מארח mLab.

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

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

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

אבל מכיוון שהשם החיצוני משתמש בהעברת CNAME, הוא לא יכול לבצע העברת יציאות. לכן, פתרון זה ישים רק עבור יציאות סטטיות ולא ניתן להשתמש בו עם יציאות דינמיות. אבל mLab Free Tier נותן למשתמש מספר יציאה דינמי כברירת מחדל ולא ניתן לשנות אותו. זה אומר שאתה צריך שורות פקודה שונות של חיבור עבור dev ו-prod. הדבר הרע הוא שזה ידרוש ממך קוד קשיח של מספר היציאה. אז איך גורמים ל-port forwarding לעבוד?

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

דבר אחד שכדאי לזכור הוא ש-IP URIs יכולים להשתנות ללא הודעה מוקדמת, מה שהופך אותם למסוכנים למדי לשימוש בפרוד. באמצעות כתובת IP זו, אתה יכול להתחבר למסד נתונים מרוחק מבלי לציין יציאה. לפיכך, שירות 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