קוברנטס – אילוף הענן

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

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

‘גמיש’ פירושו שהשירותים שלך סובלים כשלים בתוך התשתית. כישלון עשוי להיות בקר דיסק שרת שאינו יכול לגשת עוד לדיסקים, מה שהופך את הנתונים לבלתי נגישים. או שהכישלון יכול להיות מתג רשת שכבר לא מאפשר לשתי מערכות או יותר לתקשר. בהקשר זה, א “נקודת כשל יחידה” או SPOF הוא כישלון המשפיע לרעה על זמינות השירות. תשתית עמידה היא תשתית ללא SPOFs.

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

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

להבין מה’אפשרי היום, זה’מועיל להסתכל על אופן היישום של פרויקטים טכנולוגיים באופן מסורתי. בימים עברו – כלומר לפני למעלה מעשר שנים – עסקים היו קונים או מחכירים חומרה כדי להריץ את כל רכיבי היישומים שלהם. אפילו אפליקציות פשוטות יחסית, כמו אתר וורדפרס, כוללות מספר רכיבים. במקרה של וורדפרס, יש צורך במסד נתונים של MySQL יחד עם שרת אינטרנט, כגון אפאצ'י, ודרך טיפול בקוד PHP. אז הם’d לבנות שרת, להקים את Apache, PHP ו- MySQL, להתקין את וורדפרס ומחוצה להם’אלך.

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

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

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

עננים מופשטים

חלק מהכוח של קוברנט הוא המופשט שהיא מציעה. ממפתח’בפרספקטיבה, הם מפתחים את היישום לרוץ במכולה של Docker. דוקר לא’לא אכפת לי אם זה’פועל במערכת Windows, Linux או מערכת הפעלה אחרת. אותו מיכל Docker ניתן לקחת מהיזם’MacBook והפעל תחת Kubernetes ללא כל שינוי.

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

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

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

אפקט הסלאשדוט

בעיית המדרגיות קצת יותר מורכבת. תן’אומרים שאתר הוורדפרס שלך מקבל 1,000 מבקרים בחודש. יום אחד, העסק שלך מוזכר ברדיו 4 או טלוויזיה ארוחת בוקר. פתאום אתה מקבל יותר מחודש’שווה למבקרים תוך 20 דקות. אנחנו’שמענו כולם סיפורי אתרים ‘מתרסק’, וזה’זה בדרך כלל מדוע: חוסר מדרגיות.

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

הפיתרון הטוב יותר לבעיית החוסן והמדרגיות היה מחשוב ענן. הגדר מופע או שניים של שרת – השרתים הקטנים שמפעילים את היישומים שלך – בשירותי האינטרנט של אמזון (AWS) או בגוגל ענן, ואם אחד המקרים נכשל מסיבה כלשהי, הוא יופעל מחדש באופן אוטומטי. הגדר קנה מידה אוטומטי כראוי וכאשר מר האמפריס גורם לעומס העבודה במופעי שרת האינטרנט שלך לעלות במהירות, מופיעים מופעי שרת נוספים באופן אוטומטי לחלוק את עומס העבודה. מאוחר יותר, ככל שהריבית מתה, מופיעים אותם מקרים נוספים, ואתה משלם רק עבור מה שאתה משתמש. מושלם… או שזה?

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

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

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

שילוב רציף ופריסה רציפה יכולים לעבוד טוב עם Kubernetes. כאן’היא סקירה של ג'נקינס המשמשת לבניית ופריסה של יישום Java

(זיכוי תמונה: עתיד)

הפוך לקוברנה

Kubernetes (ku-ber-net-eez) הוא כלי התזמור המכולות המוביל כיום והוא הגיע מגוגל. אם מישהו יודע להפעיל תשתיות IT ענקיות, גוגל כן. מקורו של קוברנט הוא בורג, פרויקט פנימי של גוגל’זה עדיין נהג לנהל את רוב גוגל’יישומים כולל מנוע החיפוש שלה, Gmail, מפות גוגל ועוד. בורג היה סוד עד שגוגל פירסמה על כך עיתון ב -2015, אך העיתון הבהיר מאוד כי בורג היה ההשראה העיקרית מאחורי קוברנט..

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

קוברנט עצמה נולדה מגוגל’מתנות‘גוגל’תשתיות לכולם’), ותוכננה להיות גרסה ידידותית יותר של בורג שיכולה להועיל מחוץ לגוגל. זה נתרם לקרן לינוקס בשנת 2015 באמצעות הקמת קרן מחשוב ענן ענן (CNCF).

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

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

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

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

(זיכוי תמונה: עתיד)

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

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

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

כל צומת מפעיל תהליך קובלט שמתקשר עם שרת ה- API ומנהל מכולות – בדרך כלל באמצעות Docker – ו- Kube-Proxy, המטפל בפרוקסי רשת ואיזון עומסים בתוך האשכול..

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

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

מחבר הכל

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

המשימה הראשונה היא להגדיר סיסמה עבור MySQL:

kubectl ליצור mysql-pass סודי גנרי – מאת-מילולי = סיסמא = YOUR_PASSWORD

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

apiVersion: v1kind: PersistentVolumeClaimmetadata: שם: mysql-pv-claimlabels: app: wordpressspec: accessModes: – ReadWriteOnceresources: בקשות: אחסון: 20Gi

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

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

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

סוג: Deploymentmetadata: שם: wordpresslabels: app: wordpressspec: אסטרטגיה: type: Recreate

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

מטא נתונים: שם: wordpresslabels: app: wordpressspec: יציאות: – יציאה: 80selector: app: wordpresstier: frontendtype: LoadBalancer

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

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

(קרדיט תמונה: Ditching)

זה בהכרח היה רק ​​סקירה ברמה גבוהה של Kubernetes, והרבה פרטים ותכונות של המערכת הושמטו. אנחנו’החליקו באמצעות סינון אוטומטי (שני תרמילים וגם הצמתים המרכיבים אשכול), עבודות cron (החל מכולות לפי לוח זמנים), Ingress (איזון עומס HTTP, שכתוב והורדת SSL), RBAC (בקרות גישה מבוססות תפקידים), רשת מדיניות (חומת אש), ועוד ועוד. Kubernetes גמישה וחזקה במיוחד: לכל תשתית IT חדשה היא חייבת להיות מתמודדת רצינית.

משאבים

אם אתה’אינך מכיר את Docker התחל כאן: https://docs.docker.com/get-started.

שם’זה מדריך אינטראקטיבי לפריסה וקנה מידה של אפליקציה כאן: https://kubernetes.io/docs/tutorials/kubernetes-basics.

וראה https://kubernetes.io/docs/setup/scratch כיצד לבנות אשכול.

תוכלו לשחק עם אשכול Kubernetes בחינם בכתובת https://tryk8s.com.

לבסוף, אתה יכול לעקוב אחר מאמר טכני ארוך עם סקירה מצוינת של גוגל’השימוש בבורג וכיצד זה השפיע על עיצוב Kubernetes כאן: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf.

גלה מידע נוסף על מחשוב טייגר.

• אחסון ענן הטוב ביותר לשנת 2019 ברשת: אפשרויות בחינם, בתשלום ועסק