השוואה נכונה של Kubernetes החל, החלפה ותיקון

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

אם חפש בגוגל הביטוי "kubernetes apply vs replace" נמצא תשובה ל-StackOverflow, וזה לא נכון. בעת חיפוש "kubernetes apply vs patch" הקישור הראשון הוא התיעוד עבור kubectl patch, שאינו כולל השוואה apply и patch. מאמר זה יבחן את האפשרויות השונות, כמו גם את השימוש הנכון בכל אחת מהן.

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

Kubernetes CLI

אם אתה כבר עובד עם אשכולות Kubernetes דרך ה-CLI, אתה כבר מכיר apply и edit. קְבוּצָה apply קורא את מפרט המשאב מהקובץ ומבצע "upsert" לאשכול Kubernetes, כלומר. יוצר את המשאב אם הוא לא קיים ומעדכן אותו אם הוא קיים. קְבוּצָה edit קורא משאב דרך ה-API, ואז כותב את מפרט המשאב לקובץ מקומי, שנפתח לאחר מכן בעורך טקסט. לאחר עריכה ושמירת הקובץ, kubectl ישלח את השינויים שבוצעו בחזרה דרך ה-API, שיחיל בקפידה את השינויים הללו על המשאב.

לא כולם יודעים את הפקודות patch и replace. קְבוּצָה patch מאפשר לך לשנות חלק ממפרט משאבים, לספק רק את החלק שהשתנה בשורת הפקודה. קְבוּצָה replace עובד אותו הדבר כמו edit, אבל הכל צריך להיעשות באופן ידני: אתה צריך להוריד את הגרסה הנוכחית של מפרט המשאב, למשל, באמצעות kubectl get -o yaml, ערוך אותו ואז השתמש replace כדי לעדכן משאב לפי מפרט שונה. קְבוּצָה replace לא יפעל אם התרחשו שינויים כלשהם בין קריאה להחלפת המשאב.

ממשק API של Kubernetes

אתה כנראה מכיר את השיטות CoreV1().Pods().Update(), replaceNamespacedService או patch_namespaced_deployment, אם אתה עובד עם אשכולות באמצעות ספריית לקוח עבור Kubernetes API באמצעות שפת תכנות כלשהי. הספרייה מטפלת בשיטות אלו באמצעות בקשות HTTP באמצעות השיטות PUT и PATCH... שבו update и replace שימוש PUTו - patch, לא משנה כמה טריוויאלי זה עשוי להיות, משתמש PATCH.

יש לציין כי kubectl עובד גם עם אשכולות דרך API. במילים אחרות, kubectlהוא מעטפת על גבי ספריית הלקוח לשפת Go, אשר מספקת במידה רבה את היכולת לספק פקודות משנה בצורה קומפקטית וקריא יותר בנוסף ליכולות ה-API הסטנדרטיות. למשל, כפי שאולי כבר שמתם לב, השיטה apply לא הוזכר לעיל בפסקה הקודמת. נכון לעכשיו (מאי 2020, משוער. מְתוּרגְמָן) כל היגיון kubectl apply, כלומר יצירת משאבים לא קיימים ועדכון קיימים, עובדת לחלוטין בצד הקוד kubectl. נעשים מאמצים על העברה לוגית apply לצד ה-API, אבל זה עדיין בגרסת בטא. אכתוב בהרחבה בהמשך.

תיקון כברירת מחדל

עדיף להשתמש patch, אם ברצונך לעדכן את המשאב. כך פועלות שתי ספריות הלקוח על גבי ה-API של Kubernetes ו kubectl (לא מפתיע, מכיוון שזו עטיפה לספריית הלקוח, משוער. מְתוּרגְמָן).

עבודה אסטרטגית

כל הקבוצות kubectl apply, edit и patch להשתמש בשיטה PATCH ב-HTTP בקשות לעדכון משאב קיים. אם אתה מתעמק ביישום פקודות ביתר פירוט, אז כולם משתמשים בגישה תיקון אסטרטגי-מיזוג כדי לעדכן משאבים, למרות הפקודה patch עשוי להשתמש בגישות אחרות (עוד על כך בהמשך). גישת התיקון האסטרטגי-מיזוג מנסה "לתקן" על ידי מיזוג המפרט שסופק עם המפרט הקיים. ליתר דיוק, הוא מנסה לשלב גם אובייקטים וגם מערכים, מה שאומר שהשינויים נוטים להיות תוספים. לדוגמה, הפעלת הפקודה patch עם משתנה סביבה חדש במפרט מיכל הפוד, גורם להוספת משתנה סביבה למשתני הסביבה הקיימים במקום לדרוס אותם. כדי להסיר באמצעות גישה זו, עליך לאלץ את ערך הפרמטר להיות null במפרט שסופק. מי מהקבוצות kubectl האם עדיף להשתמש לעדכון?

אם אתה יוצר ומנהל את המשאבים שלך באמצעות kubectl apply, בעת עדכון עדיף להשתמש תמיד kubectl applyאל kubectl יכול לנהל את התצורה ולעקוב נכון אחר השינויים המבוקשים מאפליקציה לאפליקציה. יתרון תמיד להשתמש apply הוא עוקב אחר מפרט שהוחל בעבר, ומאפשר לו לדעת מתי מאפייני המפרט ורכיבי המערך מוסרים במפורש. זה מאפשר לך להשתמש apply כדי להסיר מאפיינים ורכיבי מערך, בעוד מיזוג אסטרטגי רגיל לא יעבוד. צוותים edit и patch אל תעדכן הערות כי kubectl apply משתמש כדי לעקוב אחר השינויים שלו, כך שכל השינויים שעוקבים אחריהם ונעשים דרך ה-API של Kubernetes, אך מתבצעים באמצעות פקודות edit и patch, בלתי נראה לפקודות הבאות applyכלומר, apply אינו מסיר אותם גם אם הם לא מופיעים במפרט הקלט עבור apply (התיעוד אומר את זה edit и patch לבצע עדכונים להערות בשימוש apply, אבל בפועל - לא).

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

ליישם שיטות עדכון בספריית הלקוח שמתנהגות בדומה לפקודות לעיל kubectl, יש להגדיר בבקשות content-type в application/strategic-merge-patch+json. אם אתה רוצה להסיר מאפיינים במפרט, עליך להגדיר במפורש את הערכים שלהם ל- null באופן דומה kubectl patch. אם אתה צריך להסיר רכיבי מערך, עליך לכלול הנחיות מיזוג במפרט העדכון או להשתמש בגישה אחרת לעדכונים.

גישות אחרות לעדכונים

Kubernetes תומך בשתי גישות עדכון אחרות: תיקון מיזוג JSON и תיקון JSON. גישת ה-JSON Merge Patch לוקחת מפרט Kubernetes חלקי כקלט ותומכת במיזוג אובייקטים בדומה לגישת התיקון האסטרטגי-מיזוג. ההבדל בין השניים הוא שהוא תומך רק בהחלפת מערך, כולל מערך המיכלים במפרט הפוד. משמעות הדבר היא שכאשר אתה משתמש בתיקון מיזוג של JSON, עליך לספק מפרט מלא עבור כל הקונטיינרים למקרה שמאפיין כלשהו של קונטיינר משתנה. אז גישה זו שימושית להסרת אלמנטים ממערך ב-BOM. בשורת הפקודה אתה יכול לבחור JSON merge patch באמצעות kubectl patch --type=merge. בעת עבודה עם ה-API של Kubernetes, עליך להשתמש בשיטת הבקשה PATCH והתקנה content-type в application/merge-patch+json.

גישת התיקון של JSON, במקום לספק מפרט חלקי של משאב, משתמשת באספקת השינויים שברצונך לבצע במשאב כמערך, שבו כל רכיב של המערך מייצג תיאור של השינוי שמתבצע במשאב. גישה זו היא דרך גמישה ועוצמתית יותר לבטא את השינויים המתבצעים, אך במחיר של רישום השינויים המתבצעים בפורמט נפרד שאינו Kubernetes, במקום שליחת מפרט משאבים חלקי. IN kubectl אתה יכול לבחור תיקון JSON באמצעות kubectl patch --type=json. בעת שימוש ב-Kubernetes API, גישה זו פועלת בשיטת הבקשה PATCH והתקנה content-type в application/json-patch+json.

אנחנו צריכים ביטחון - השתמש להחליף

במקרים מסוימים, עליך להיות בטוח שלא יבוצעו שינויים במשאב מרגע הקריאה של המשאב ועד לעדכון שלו. במילים אחרות, עליך לוודא שכל השינויים יהיו אָטוֹמִי. במקרה זה, כדי לעדכן משאבים עליך להשתמש replace. לדוגמה, אם יש לך ConfigMap עם מונה שמתעדכן על ידי מספר מקורות, עליך להיות בטוח ששני מקורות לא מעדכנים את המונה בו זמנית, מה שגורם לאיבוד העדכון. כדי להדגים, דמיינו רצף אירועים באמצעות הגישה patch:

• A ו-B מקבלים את המצב הנוכחי של המשאב מה-API
• כל אחד מעדכן באופן מקומי את המפרט על ידי הגדלת המונה באחד וגם הוספת "A" או "B" בהתאמה להערת "עדכן לפי"
• וזה מעדכן את המשאב קצת יותר מהר
• B מעדכן את המשאב

כתוצאה מכך, עדכון A אבד. ניתוח אחרון patch מנצח, המונה גדל באחד במקום בשניים, והערך של הפתק "מעודכן על ידי" מסתיים ב-"B" ואינו מכיל "A". הבה נשווה את האמור לעיל למה שקורה כאשר נעשים עדכונים באמצעות הגישה replace:

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

במקרה שלעיל, B יצטרך להביא מחדש את המשאב, לבצע שינויים במצב החדש ולנסות שוב replace. זה יגרום להגדלת המונה בשניים ולהערת "מעודכן על ידי" לכלול "AB" בסוף.

הדוגמה לעיל מרמזת כי בעת ביצוע replace המשאב כולו מוחלף לחלוטין. מפרט המשמש עבור replace, אסור להיות חלקי, או בחלקים כמו ב apply, אבל שלם, כולל התוספת resourceVersion לתוך המטא נתונים של המפרט. אם לא הפעלת resourceVersion או שהגרסה שאתה מספק אינה עדכנית, ההחלפה תידחה. אז הגישה הטובה ביותר לשימוש היא replace – קרא את המשאב, עדכן אותו והחלף אותו מיד. באמצעות kubectl, זה עשוי להיראות כך:

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

ראוי לציין ששתי הפקודות הבאות, שיבוצעו ברצף, יבוצעו בהצלחה, שכן deployment.yaml אינו מכיל רכוש .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

נראה כי הדבר סותר את האמור לעיל, כלומר. "מוֹסִיף resourceVersion לתוך המטא-נתונים של המפרט." האם זה לא נכון להגיד את זה? לא, זה לא, כי אם kubectl הודעות שלא ציינת resourceVersion, הוא יקרא אותו מהמשאב ויוסיף אותו למפרט שציינת, ורק אז יבצע אותו replace. מכיוון שזה עלול להיות מסוכן אם אתה מסתמך על אטומיות, הקסם פועל לגמרי בצד kubectl, אין להסתמך עליו בעת שימוש בספריות לקוח שעובדות עם ה-API. במקרה זה תצטרך לקרוא את מפרט המשאב הנוכחי, לעדכן אותו ולאחר מכן לבצע PUT בַּקָשָׁה.

אתה לא יכול לעשות תיקון - אנחנו עושים החלפה

לפעמים אתה צריך לבצע כמה שינויים שלא ניתן לטפל בהם על ידי ה-API. במקרים אלה, תוכל לאלץ החלפה של המשאב על ידי מחיקה ויצירה מחדש שלו. זה נעשה באמצעות kubectl replace --force. הפעלת הפקודה מסירה מיד את המשאבים ולאחר מכן יוצרת אותם מחדש מהמפרט שסופק. אין ב-API מטפל "force replace" וכדי לעשות זאת דרך ה-API יש לבצע שתי פעולות. ראשית עליך למחוק את המשאב על ידי הגדרה עבורו gracePeriodSeconds לאפס (0) ו propagationPolicy ב"רקע" ולאחר מכן צור מחדש את המשאב הזה עם המפרט הרצוי.

אזהרה: גישה זו עלולה להיות מסוכנת ועלולה להוביל למצב לא מוגדר.

החל בצד השרת

כפי שצוין לעיל, מפתחי Kubernetes עובדים על הטמעת ההיגיון apply של kubectl בממשק ה-API של Kubernetes. לוגיקה apply זמין ב-Kubernetes 1.18 דרך kubectl apply --server-side או דרך ה-API באמצעות השיטה PATCH с content-type application/apply-patch+YAML.

הערה: JSON הוא גם YAML חוקי, אז אתה יכול לשלוח את המפרט בתור JSON גם אם content-type רצון application/apply-patch+yaml.

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

תוצאות של

אני מקווה שסקירה קצרה זו של דרכים שונות לעדכון משאבים באשכולות הייתה מועילה לך. טוב לדעת שזה לא רק החל מול החלפה; אפשר לעדכן משאב באמצעות החל, ערוך, תיקון או החלפה. אחרי הכל, באופן עקרוני, לכל גישה יש תחום יישום משלה. עבור שינויים אטומיים, החלפה עדיף; אחרת, עליך להשתמש בתיקון מיזוג אסטרטגי באמצעות החל. לכל הפחות, אני מצפה ממך להבין שאתה לא יכול לסמוך על Google או StackOerflow כשאתה מחפש "kubernetes apply vs replace". לפחות עד שמאמר זה יחליף את התשובה הנוכחית.

מקור: www.habr.com