במאמרים קודמים הסברנו על הרכיבים השונים בקוברנטיס וביניהם היחידה הקטנה ביותר, הPod. ראינו איך ניתן ליצר אחד ולהריץ בו את האפליקציה. במאמר נדבר על היכולת להריץ מספר קונטיינרים בPod ומתי כדאי לעשות דבר כזה.
כשמדברים על המושג Pod בקוברנטיס, בדרך כלל מותחים קו ישר ל קונטיינר. אבל אם נסתכל בהגדרה של Pod נראה שהוא אבסטרקציה של קונטיינר או מספר קונטיינרים.
לפני שנסביר איך ומתי משתמשים ביותר מ קונטיינר בודד בPod נדבר על מושג יסוד בארכיטקטורה.
צימוד(Coupling)
צימוד – ״מייצג את רמת התלות בין מודולים שונים באותה מערכת.״
מערכת בה יש רמת צימוד גבוהה, ההשפעה של חלק אחד משמעותי ביחס לשני ולרוב שינוי בחלק אחד ידרוש שינוי בחלקים אחרים.
בואו נקביל לרגע את הרכיבים של האפליקציה למפעל להדפסת חולצות, שבו
- עובד אחד מיצר את הדגם
- עובד שני עושה את ההדפסות
- עובד שלישי מתעסק באריזה
- ועובד אחרון מטפל במשלוחים
אם אחד העובדים יפסיק לעבוד יווצר בעיה בתהליך האספקה כי השרשרת תיעצר
מערכת שבה רמת הצימוד נמוכה התלות בין החלקים הוא קטן עד לא קיים. ההשפעה של חלק אחד על השני נמוך ושינוי בחלק אחד לא ידרוש שינוי בחלקים האחרים.
למשל בית ספר שבו יש מגוון של שיעורים אם מורה למקצוע מסוים מפסיק לעבוד כל שאר המערכת יכול להמשיך ולתפקד כרגיל ללא שינוי.
Sidecar
כאשר מתכננים מערכת מבוססת מיקרוסרביסים השאיפה היא שרמת הצימוד תהיה נמוכה ככל הניתן כאשר המטרה העיקרית היא לאפשר את הזמינות הגבוהה ביותר של המערכת, וכך גם עם רכיב מסיום לא יהיה זמין השאר יוכל להמשיך לעבוד (לרוב עם פונקציונליות נמוכה יותר)
אך ישנם מצבים שלרכיב מסוים יש תלות חזקה ברכיב אחר. במצבים כאלה ניתן לפעמים להשתמש בSidecar.
Sidecar מספק את היכולת ליצור Pod שמכיל שני קונטיינרים(או יותר) כאשר אחד הוא הראשי והשאר הם משניים.
היתרון בSidecar הוא ששני הקונטיינרים רצים ביחד. הם יכולים לחלוק שטח אחסון וקוברנטיס מתייחס אליהם כמקשה אחת.
דוגמא קלאסית לSidecar הוא מעביר לוגים – תפקידו לקחת את הלוגים מהאפליקציה ולהעביר אותם אל מקום מרכזי(למשל Elasticsearch ). במצב בו האפליקציה אינה עובדת אין למעביר לוגים שום תפקיד, ולכן הוא מתאים לארכיטקטורה הזאת.
איך זה עובד?
מכיוון ששני הקונטיינרים יושבים באותו Pod, יש אפשרות לשתף את השטח אחסון ביניהם וכך האפליקציה תכתוב לוגים לנתיב שגם נגיש למעביר לוגים.
איך מייצרים אפליקציה עם Sidecar?
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
volumes:
- name: shared-logs
emptyDir: {}
containers:
- name: my-app
image: my-app-image
volumeMounts:
- name: shared-logs
mountPath: /var/log/app
- name: sidecar-log-forwarder
image: bitnami/fluent-bit
volumeMounts:
- name: shared-logs
mountPath: /var/log/app
תהליך-קדם (init-container)
סיבה נוספת לשני קונטיינרים בPod אחד הוא צורך בפעולה לפני תחילת האפליקציה
דוגמאות נפוצות לכך:
- איתחול מאגר מידע
- שימוש בכלים שהם לא צריכים להיות חלק מהאפליקציה
- לחכות למשהו חיצוני שהאפליקציה צריכה כדי להתחיל
איך זה עובד?
לפני שמתחיל התהליך המרכזי עולה קונטיינר עם תהליך קדם-ריצה במצב הזה הסטטוס יהיה Init:N/M כלומר בתהליך קדם מספר N מתוך ה M הקיימים.
ברגע שהתהליך קדם-ריצה יסיים יעלה הקונטיינר עם התהליך המרכזי והסטטוס של ה Pod יהיה Running.
איך מייצרים אפליקציה עם תהליך קדם?
apiVersion: apps/v1
kind: pod
metadata:
name: my-app
spec:
template:
spec:
containers:
- name: my-app
volumeMounts:
- name: plugins
mountPath: /usr/local/bin/plugin
volumes:
- name: plugins
emptyDir: {}
initContainers:
- name: download-plugin
image: alpine:3.9
command: [sh, -c]
args:
- >-
wget -O my-plugin https://github.com/my-plugin-repo/releases/download/v1.1/my-plugin_1.1_linux_amd64 && mv my-plugin /custom-plugins/
volumeMounts:
- mountPath: /custom-plugins
name: plugins
volumeMounts:
- mountPath: /custom-plugins
name: plugins
בדוגמא קודם ירד התוסף שאנחנו צריכים לצורך התהליך הראשי ורק לאחר שהתהליך הסתיים נתחיל את האפליקציה.
לסיכום
במאמר דיברנו על צמידות והיכולת להריץ מספר קונטיינרים בPod בודד.
כעת אנחנו יודעים ש:
כאשר יש רמת צימוד גבוהה נשתמש בSidecar.
כאשר יש צורך שמשהו יקרה לפני שיעלה האפליקציה נשתמש בתהליך קדם.
תודה על הקריאה, ניפגש במאמרים הבאים!