קונטיינר למסוע: CRI-O הוא כעת ברירת המחדל ב-OpenShift Container Platform 4

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

הפתרון הברור היה להשתמש ב-Red Hat Enterprise Linux CoreOS (גרסה של Red Hat Enterprise Linux) ו-CRI-O כסטנדרט, והנה הסיבה...

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

עכשיו תארו לעצמכם אם ברונל היה צריך לעשות את העבודה הזו עבור 20 דגמי ספינות שונים (גרסאות Kubernetes) ועבור חמישה כוכבי לכת שונים עם זרמי ים ורוחות שונות לחלוטין (ספקי ענן). בנוסף, נדרש שכל הספינות (אשכולות OpenShift), ללא קשר לכוכבי הלכת בהם מתבצע הניווט, מנקודת מבטם של הקברניטים (המפעילים המנהלים את תפעול האשכולות) יתנהגו אותו הדבר. כדי להמשיך את האנלוגיה הימית, לקברניטי הספינות לא אכפת בכלל באיזה סוג של בלוקי חבלול (CRI-O) משתמשים בספינות שלהם - העיקר מבחינתם הוא שהבלוקים האלה חזקים ואמינים.

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

OpenShift 4 נוצר בצורה כזו שתספק את היכולת לעדכן את המערכת בנוחות לאורך כל מחזור החיים של הפלטפורמה (לגרסאות 4.X) עבור כל ספקי מחשוב הענן הגדולים, פלטפורמות וירטואליזציה ואפילו מערכות מטאל חשוף. לשם כך, יש ליצור צמתים על בסיס אלמנטים הניתנים להחלפה. כאשר אשכול דורש גרסה חדשה של Kubernetes, הוא מקבל גם את הגרסה המקבילה של CRI-O ב-CoreOS. מכיוון שגרסת ה-CRI-O קשורה ישירות ל-Kubernetes, הדבר מפשט מאוד את כל התמורות למטרות בדיקה, פתרון בעיות או תמיכה. בנוסף, גישה זו מפחיתה עלויות עבור משתמשי קצה ו-Red Hat.

זוהי דרך חשיבה חדשה ביסודה על אשכולות Kubernetes ומניחה את הבסיס לתכנון כמה תכונות חדשות מאוד שימושיות ומשכנעות. CRI-O (Container Runtime Interface - Open Container Initiative, בקיצור CRI-OCI) התברר כבחירה המוצלחת ביותר ליצירה המונית של צמתים הנחוצים לעבודה עם OpenShift. CRI-O יחליף את מנוע ה-Docker ששימש בעבר, ויציע למשתמשי OpenShift חסכוני, יציב, פשוט ומשעמם – כן, שמעתם נכון – מנוע מיכל משעמם שנוצר במיוחד לעבודה עם Kubernetes.

עולם המכולות הפתוחות

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

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

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

מהנדסים ב-Red Hat ו-Google ראו צורך בשוק במנוע מכולה שיוכל לקבל בקשות של Kubelet על פני פרוטוקול CRI והציגו קונטיינרים התואמים למפרטי ה-OCI שהוזכרו לעיל. כך הופיע OCID. אבל תסלחו לי, האם לא אמרנו שהחומר הזה יוקדש ל-CRI-O? למעשה זה כן, רק עם השחרור גרסה 1.0 שם הפרויקט שונה ל-CRI-O.

תאנה. 1.

חדשנות עם CRI-O ו-CoreOS

עם השקת פלטפורמת OpenShift 4, היא שונתה מנוע מיכל, בשימוש כברירת מחדל בפלטפורמה, ו-Docker הוחלף ב-CRI-O, המציע סביבה חסכונית, יציבה, פשוטה ומשעממת להפעלת קונטיינר שמתפתח במקביל ל-Kubernetes. זה מפשט מאוד את התמיכה והתצורה של אשכול. התצורה של מנוע המכולה והמארח, כמו גם הניהול שלהם, הופכים לאוטומטיים בתוך OpenShift 4.

רגע, איך זה?

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

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

על ידי שימוש ב-Operators בפלטפורמה, OpenShift 4 מביא את הפרדיגמה החדשה הזו (באמצעות הרעיון של סט ומצב בפועל) לניהול של RHEL CoreOS ו-CRI-O. המשימות של הגדרה וניהול גרסאות של מערכת ההפעלה ומנוע המכולה אוטומטיות באמצעות מה שנקרא מפעיל תצורת מכונה (MCO). MCO מפשט מאוד את עבודתו של מנהל האשכול, ובעצם הופך את השלבים האחרונים של ההתקנה לאוטומטיים, כמו גם פעולות לאחר ההתקנה (פעולות יום שני). כל זה הופך את OpenShift 4 לפלטפורמת ענן אמיתית. ניכנס לזה קצת יותר מאוחר.

הפעלת מכולות

למשתמשים הייתה הזדמנות להשתמש במנוע CRI-O בפלטפורמת OpenShift מאז גרסה 3.7 בסטטוס Tech Preview ומגרסה 3.9 בסטטוס Generally Available (נתמך כרגע). בנוסף, Red Hat משתמש באופן מסיבי CRI-O להפעלת עומסי ייצור ב-OpenShift Online מאז גרסה 3.10. כל זה אפשר לצוות העובד על CRI-O לצבור ניסיון רב בשיגור המוני מכולות על אשכולות Kubernetes גדולים. כדי לקבל הבנה בסיסית של האופן שבו Kubernetes משתמש ב-CRI-O, בואו נסתכל על האיור הבא, שמראה כיצד הארכיטקטורה פועלת.

אורז. 2. כיצד פועלים קונטיינרים באשכול Kubernetes

CRI-O מפשט את היצירה של מארחי קונטיינר חדשים על ידי סנכרון של כל הרמה העליונה בעת אתחול צמתים חדשים, ובעת שחרור גרסאות חדשות של פלטפורמת OpenShift. עדכון של הפלטפורמה כולה מאפשר עדכוני טרנזקציות/החזרה לאחור, וגם מונע מבוי סתום בתלות בין ליבת זנב המכולה, מנוע המכולה, הצמתים (Kubelets) והצומת Kubernetes Master. על ידי ניהול מרכזי של כל רכיבי הפלטפורמה, עם בקרה וניהול גרסאות, יש תמיד נתיב ברור ממצב א' למצב ב'. זה מפשט את תהליך העדכון, משפר את האבטחה, משפר את דיווח הביצועים ומסייע להפחית את עלות העדכונים וההתקנות של גרסאות חדשות .

הדגמת כוחם של אלמנטים חלופיים

כפי שהוזכר קודם לכן, השימוש ב-Machine Config Operator לניהול מארח המכולה ומנוע המכולות ב-OpenShift 4 מספק רמה חדשה של אוטומציה שלא הייתה אפשרית בעבר בפלטפורמת Kubernetes. כדי להדגים את התכונות החדשות, נראה כיצד תוכל לבצע שינויים בקובץ crio.conf. כדי להימנע מבלבול בטרמינולוגיה, נסה להתמקד בתוצאות.

ראשית, בואו ניצור מה שנקרא תצורת זמן ריצה של קונטיינר - Container Runtime Config. תחשוב על זה כעל משאב Kubernetes שמייצג את התצורה של CRI-O. במציאות, זוהי גרסה מיוחדת של משהו שנקרא MachineConfig, שהיא כל תצורה שנפרסת למחשב RHEL CoreOS כחלק מאשכול OpenShift.

משאב מותאם אישית זה, הנקרא ContainerRuntimeConfig, נוצר כדי להקל על מנהלי אשכולות להגדיר CRI-O. כלי זה חזק מספיק כדי שניתן יהיה להחיל אותו רק על צמתים מסוימים בהתאם להגדרות MachineConfigPool. תחשוב על זה כעל קבוצה של מכונות שמשרתות את אותה מטרה.

שימו לב לשתי השורות האחרונות שאנו הולכים לשנות בקובץ /etc/crio/crio.conf. שתי שורות אלו דומות מאוד לשורות בקובץ crio.conf, הן:

vi ContainerRuntimeConfig.yaml

מסקנה:

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: set-log-and-pid
spec:
 machineConfigPoolSelector:
   matchLabels:
     debug-crio: config-log-and-pid
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug

עכשיו בואו נדחוף את הקובץ הזה לאשכול Kubernetes ונבדוק שהוא אכן נוצר. שימו לב שהפעולה זהה לחלוטין לכל משאב Kubernetes אחר:

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

מסקנה:

NAME              AGE
set-log-and-pid   22h

לאחר שיצרנו את ContainerRuntimeConfig, עלינו לשנות את אחד מ-MachineConfigPools כדי לאותת ל-Kubernetes שאנו רוצים להחיל את התצורה הזו על קבוצה מסוימת של מכונות באשכול. במקרה זה נשנה את MachineConfigPool עבור הצמתים הראשיים:

oc edit MachineConfigPool/master

מסקנה (למען הבהירות, נותרה המהות העיקרית):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

בשלב זה, MCO מתחיל ליצור קובץ crio.conf חדש עבור האשכול. במקרה זה, ניתן להציג את קובץ התצורה המוגמר במלואו באמצעות ה-API של Kubernetes. זכור, ContainerRuntimeConfig היא רק גרסה מיוחדת של MachineConfig, כך שנוכל לראות את התוצאה על ידי הסתכלות על השורות הרלוונטיות ב-MachineConfigs:

oc get MachineConfigs | grep rendered

מסקנה:

rendered-master-c923f24f01a0e38c77a05acfd631910b                  4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626                  4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62                  4.0.22-201904011459-dirty 2.2.0 16h

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

python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid

מסקנה:

pids_limit = 2048

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

oc get node | grep master

Output:

ip-10-0-135-153.us-east-2.compute.internal   Ready master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Ready master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Ready master 23h v1.12.4+509916ce1

עכשיו בואו נסתכל על הקובץ המותקן. אתה תראה שהקובץ עודכן עם הערכים החדשים עבור הוראות ה-pid ו-debug שציינו במשאב ContainerRuntimeConfig. האלגנטיות עצמה:

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’

מסקנה:

...
pids_limit = 2048
...
log_level = "debug"
...

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

הדוגמה שלמעלה מראה את היכולת לבצע שינויים באשכול OpenShift Container Platform 4 קטן עם שלושה צמתי ייצור או אשכול ייצור ענק עם 3000 צמתים. בכל מקרה, כמות העבודה תהיה זהה - וקטנה מאוד - פשוט תגדיר את קובץ ContainerRuntimeConfig, ותשנה תווית אחת ב-MachineConfigPool. ואתה יכול לעשות זאת עם כל גרסה של OpenShift Container Platform 4.X הפועלת עם Kubernetes לאורך כל מחזור החיים שלה.

לעתים קרובות חברות טכנולוגיה מתפתחות כל כך מהר עד שאיננו מסוגלים להסביר מדוע אנו בוחרים בטכנולוגיות מסוימות עבור הרכיבים הבסיסיים. מנועי מיכל היו היסטורית הרכיב שמשתמשים מקיימים איתו אינטראקציה ישירה. מכיוון שהפופולריות של מכולות החלה באופן טבעי עם הופעת מנועי המכולות, משתמשים מראים בהם עניין לעתים קרובות. זו סיבה נוספת מדוע Red Hat בחרה ב-CRI-O. קונטיינרים מתפתחים עם הדגש כעת על תזמור, וגילינו ש-CRI-O מספק את החוויה הטובה ביותר בעבודה עם OpenShift 4.

מקור: www.habr.com