הווירטואליזציה של חומרת מציעה רשימה של יתרונות כגון הרחבתיות, אבטחה, בידוד, ועוד, על ידי שימוש בהיפרווייזורים לשיתוף חומרה פיזית עם מכונות וירטואליות (VMs). כיום, מכונות וירטואליות אינן הצורה היחידה של וירטואליזציה, מאחר וגם קונטיינרים הפכו לפופולריים למדי. בעוד שמכונות וירטואליות חולקות חומרה פיזית של מכונות התומכות, קונטיינרים חולקים את ליבת המערכת התומכת. קונטיינרים אינם מכונות וירטואליות קלות, אלא חבילות יישומים בסטנדרטים המבוצעות שמשמשות להעברת יישומים, כולל יישומים שפותחו באמצעות ארכיטקטורת תוכנה מבוססת שירותים קטנים, וכוללות את כל הרכיבים הנדרשים להפעלת היישומים.
מנוע Docker הוא הפלטפורמה הפופולרית ביותר להפעלת קונטיינרים. Kubernetes הוא מונח שתוכל לשמוע עליו בתדירות מתוך הספירה של קונטיינריזציה ומחשוב ענן. אך מה טוב יותר – Docker או Kubernetes? זו נושא פופולרי לדיון, אך לפרסם את זה בצורה זו אינו נכון מבחינה טכנית. לדוגמה, אי אפשר לשאול: "מה טוב יותר – חם או כחול?"
מהו Docker?
Docker הוא יישום עצמאי מקור פתוח הפועל כמנוע המשמש להפעלת יישומים בקונטיינרים. הוא מותקן על מערכת ההפעלה שלך (OS), רצוי על Linux, אך יכול להיות מותקן גם על Windows ו־macOS, שבתורו רץ על מכונה פיזית או וירטואלית.
יישום שרץ בתוך תכולת יישום מבודד משאר המערכת ומתוך תכולות נוספות, אך יוצר את התחושה שהוא רץ בהתקנת מערכת נפרדת של מערכת ההפעלה שלו. ניתן להפעיל מספר תכולות של Docker במקביל על מערכת ההפעלה היחידה; ניתן לנהל את התכולות האלו עם Docker, ו-Docker יכול לרוץ בלעדיו Kubernetes. אם יש לך מספר מארחים להפעלת תכולות, ניהולם באופן ידני יכול להיות מורכב, ובדרך כלל עדיף לבחור כלי ניהול מרכזי או פתרון לאורכסטרציה.
Docker Compose הוא כלי יסודי לאורכסטרצית תכולות המשמש להפעלת יישומי Docker מרובי תכולות. ניתן להגדיר קובץ הגדרת YAML (yml) יחיד של Docker Compose להגדרת יישומי מרובי תכולות במקום להגדיר ידנית קבצי Dockerfile נפרדים לכל תכולה. לאחר הגדרת קובץ ה-YAML היחיד, ניתן להפעיל את כל התכולות הנדרשות עם פקודה יחידה בקונסולת ה-Linux שלך. שימוש ב-Docker Compose הוא אחת מהדרכים לאורכסטרצית תכולות ה-Docker שלך, אך ישנה אלטרנטיבה חזקה ל-Docker Compose שנקראת Kubernetes.
מהו Kubernetes?
Kubernetes הוא פתרון אורכסטרציה לתכולות מקור פתוח המשמש לניהול תוכנות ושירותים בתוך תכולות עם רמת אוטומציה גבוהה.
Kubernetes הוא פרויקט של Google המיועד לאוטומציה של ההתקנה, ההתרחבות והזמינות של יישומים שרצים בתוך תכולות. ניתן להגדיל את מספר המארחים שרצים תכולות עד 11 או יותר מארחים. בנוסף, ניתן ליצור אשכול של תכולות Docker עם Kubernetes כדי להבטיח זמינות גבוהה ואיזון מעמסה.
המארחים שמשמשים באשכול נקראים צמתים. סוג הארכיטקטורה של Kubernetes הוא של מאסטר-עבד – האשכול מורכב מצמתי מאסטר וצמתי עבודה. מספר הצמתים המומלץ ביותר לפי Kubernetes הוא ארבעה. ועל אף שניתן לבנות אשכול עם מחשב אחד, כדי להפעיל את כל הדוגמאות והבדיקות נדרשים לך לפחות ארבעה צמתים. אשכול Kubernetes שמטפל בתעבודת הייצור צריך להכיל לפחות שלושה צמתים עבודה. שימוש בשני צמתי מאסטר מגן על האשכול שלך מפני כשל בצמת מאסטר אחד. אפשר להשתמש ביותר משני צמתי מאסטר אם נדרש.
- צמתי מאסטר משמשים לניהול מצב של האשכול, הכולל קבלת בקשות מלקוחות, קידוד פעולות עם תכולית, הרצת לופים של בקרה, וכו '. עליך להריץ עותק של מסד הנתונים etcd שמאכסן את כל הנתונים של האשכול על כל צומת מאסטר. הצומת מאסטר מריץ אוסף של שלושת התהליכים: kube-apiserver, kube-controller-manager, ו־kube-scheduler.
- צמתי עבודה משמשים לביצוע עומסי עבודה של יישומים על ידי הרצת תכולות. שני התהליכים של Kubernetes רצים על הצומת שאינה מאסטר: kubelet (לתקשורת עם צמתי המאסטר) ו־kube-proxy (להשקת שירותי רשת של Kubernetes על כל צומת).
- קונטרולר שיבוץ משנה הוא רכיב המשמש לוודא ששמות כפולים של קונטיינרים, שמספרם צויין, תמיד רצים בכל רגע נתון. לכן, ניתן לוודא שהקונטיינרים תמיד זמינים כאשר נדרשים.
מסופרים CLI ו-API משמשים לתקשורת בין שירותים כאשר משתמשים ב־Kubernetes. ישנם גם מונחים ספציפיים המשמשים לשינוי שמות של אובייקטים ומשאבי ה-API ה־RESTful אשר הם רכיבים באשכול הנבנה ב־Kubernetes. - קוביה היא יחידת זמן בסיסית ב־Kubernetes. זו קבוצת משאבים שבה מרבים קונטיינרים מסוימים לעבוד. קונטיינרים ששייכים לקוביה יכולים לרוץ על אותו המארח ולהשתמש באותו משאב ובאותו רשת מקומית. קונטיינרים בקוביה מבודדים אך יכולים לתקשר זה עם זה בקלות רבה. לכן, קוביות משמשות בדרך כלל ב־Kubernetes, אך אם משתמשים ביישום עצמאי של Docker, רק מאגרי קונטיינרים זמינים.
- שירות הוא קבוצת קונטיינרים שעובדים יחד ומספקים, לדוגמה, פעולת אפליקציה מרובת טיירות. Kubernetes תומך בשם דינמי ובאיזור השוויין של קוביות באמצעות הקפצה. שיטה זו מבטיחה חיבור שקוף בין שירותים לפי השם, ומאפשרת לך לעקוב אחר המצב הנוכחי שלהם.
- תוויות הם זוגות מפתח/ערך המקושרים לקוביות ולאובייקטים או לשירותים אחרים, בנוסף לאפשרות לקיבוץ ולהקצאת משימות להם בקלות.
- מרחבי שמות הוא שיטה המאפשרת לחלק באופן לוגי את האשכול המאוחד של Kubernetes למספר אשכולות וירטואליים. כל אשכול וירטואלי יכול לקיים בתוך סביבה וירטואלית המוגבלת על ידי קבוצות משאבים מבלי להשפיע על אשכולות וירטואליים אחרים.
Kubernetes ניתן לשימוש עם Docker, אף על פי ש-Docker אינו הפלטפורמה להכנת תוכן היחידה בה ניתן להשתמש עם Kubernetes. Kubernetes יכול גם לעבוד בשיתוף עם תוכניות קונטיינרים של Windows, תוכניות קונטיינרים של Linux, rkt, וכו '. K8s הוא השם של Kubernetes שניתן למצוא בעיתונות טכנית לעיתים קרובות.
השוואת Kubernetes נגד Docker: רשתות
בואו נבחן את אפשרויות הרשת עבור כל פתרון.
Docker מספק שלוש מצבי רשת עבור תקשורת רשת בין קונטיינרים.
ממסגרת. מצב זה משמש כברירת המחדל, יוצר מסגרת שלישית רמה-3 וירטואלית. שם הרשת במחשב המארח שלך הוא docker0 לרשת זו. Docker יוצר אוטומטית מסגרת רשת שלישית ומגדיר כללי מסקרדה עבור ממשק הרשת החיצוני, באמצעות עקרון הטביעה בכתובות רשת (NAT), שמאפשר לקונטיינרים לתקשר זה עם זה ולהתחבר לרשתות חיצוניות. ניתן להגדיר הפנייה של פורטים עבור ממשק הרשת של מחשב המארח אם תרצה להתחבר לקונטיינר ממחשבים אחרים ומרשתות חיצוניות. לכן, על ידי התחברות לפורט המתאים של מחשב המארח, אתה מועבר לפורט הנדרש של קונטיינר Docker. ניתן ליצור יותר מממשק רשת אחד עבור קונטיינר Docker אם תהיה צורך.
מארח. במצב זה, מנהל רשת מארח מבטיח שמיכל לא מבודד ממארח Docker. המיכל משתף את מערכת הרשת של המארח, ושם המארח של המיכל הוא זהה לשם המארח של מערכת ההפעלה של המארח. אם אתה מפעיל מיכל בו יש מאזין ליפתחת TCP בפורט 8080, היישום של המיכל זמין בפורט TCP 8080 של כתובת ה-IP של המכונה המארחת. מנהל רשת המארח זמין רק עבור מכונות Linux.
ללא. לא מוגדרות כתובות IP עבור ממשק הרשת של המיכל הנתון, חוץ מכתובת 127.0.0.1 עבור ממשק הלולאה הפנימית. אין גישה לרשתות חיצוניות אם מצב הרשת ללא מוגדר.
רשת מרובה מארחים עבור מיכלי Docker. אם מיכלים פועלים על מארחים שונים, הם יכולים לתקשר זה עם זה לאחר שאתה מגדיר את הרשת העטיפה. שירות חנות מפתח-ערך תקין (קונסול, Etcd, או ZooKeeper) חייב להיות מוגדר כדי ליצור רשתות כאלה.
Kubernetes. אם אתה משתמש במיכלים עצמאיים של Docker, כל מיכל ניתן להתייחס אליו כיחידה בסיסית שמתקשרת דרך הממשק הרשת המתאים. אם אתה משתמש ב-Kubernetes, קפוסולות הם היחידות הבסיסיות של אשכול המיכלים. לכל קפוסולה יש כתובת IP ייחודית והיא מורכבת לפחות ממיכל אחד. קפוסולה יכולה להיות מורכבת ממספר מיכלים המשמשים למשימות קשורות. מיכלים באותה קפוסולה לא יכולים לפתוח את אותו הפורט בו זמן אחד. הגבלה זו משמשת משום שקפוסולה המורכבת ממספר מיכלים עדיין יש כתובת IP יחידה.
בנוסף, Kubernetes יוצרת container עצום מיוחד עבור כל Pod. ה-container המיוחד הזה מיועד לספק ממשק רשת (לתקשורת פנימית וחיצונית) ל-containerים אחרים, ובדרך כלל הוא במצב השהיה (במצב שינה). ה-containerים של השהיה מתעוררים כאשר Kubernetes שולחת אות סיגנל "SIGTERM".
Flannel בדרך כלל משמש כבד רשת לחיבור בין containerים ב-Kubernetes באמצעות עקרונות של עטיפת רשת. העטיפה של הרשת מאפשרת לך להריץ containerים ולתקשר אותם דרך הרשת הלוגית שונה בין מארחים פיזיים שונים באשכול (שמתייחסים אליהם כמארחים). סטור הערכים / המפתח etcd משמש לשמירה על התמפילים בין כתובות ה-IP האמיתיות המוקצות ל-containerים על ידי המארחים עליהם רצים ה-containerים, ובין כתובות ה-IP ברשת העטיפה.
ניתן לאינטגרציה של הרשתות ב-Kubernetes עם VMware NSX-T על ידי השימוש בתוסף ה-NSX Container. אינטגרציה זו מאפשרת לך להשתמש בטופולוגית רשת מרובי-שוכנים שאינה זמינה "מתוך הקופסה" ב-Kubernetes.
המודל של הרשתות ב-Kubernetes מספק את התכונות הבאות:
- כל ה-containerים יכולים לתקשר עם כל ה-containerים האחרים בתוך אשכול ללא NAT.
- כל הצמתי אשכול יכולים לתקשר עם כל ה-containerים בתוך אשכול ללא NAT. להפך, כל ה-containerים יכולים לתקשר עם כל הצמתי אשכול.
- ה-containerים רואים את כתובות ה-IP שלהם וכתובות ה-IP האלה נראות לרכיבים אחרים של Kubernetes.
הכניסה היא אובייקט API של Kubernetes שמשמש לניהול גישה לשירותים בקרבת הענן מבחוץ (בעיקר HTTP ו-HTTPS). באפשרותך להגדיר את הכניסה כך שתבצע גישה חיצונית לשירותים בקונטיינרים, לטעינת משקל, סיום SSL ואירוח וירטואלי על בסיס שמות. להפעלת כללי הכניסה יש להציב בקר הכניסות על גבי הצומת הראשית.
מקרי שימוש
שימוש ב-Docker כתוכנה עצמאית הוא יעיל לפיתוח אפליקציות, שכן מפתחים יכולים להריץ את האפליקציות שלהם בסביבות מבודדות. בנוסף, נבדקים יכולים גם להשתמש ב-Docker כדי להריץ אפליקציות בסביבות חול. אם ברצונך להשתמש ב-Docker כדי להריץ מספר גבוה של קונטיינרים בסביבת הייצור עשויה להיות לך נתקלויות בדרך. לדוגמה, קונטיינרים מסוימים עשויים להידרדר בקלות או לנפול. באפשרותך לאתחל מחדש את הקונטיינר באופן ידני על המכונה הרלוונטית, אך ניהול ידני עשוי לקחת הרבה מזמנך ואנרגיך.
קוברנטיס מאפשרת לך לפתור את הבעיות הללו על ידי ספקת תכונות מרכזיות כמו זמינות גבוהה, טעינת משקל, כלי אורקסטרציה של קונטיינרים, וכו'. כתוצאה, קוברנטיס היא הכי מתאימה לסביבות הייצור הטעונות ביותר עם מספר גבוה של קונטיינרים של Docker. הפרטת קוברנטיס קשה יותר מהתקנת אפליקצית Docker עצמאית, ולכן קוברנטיס לא תמיד משמשת לפיתוח ולבדיקות.
קוברנטיס נגד Docker Swarm
Docker Swarm הוא כלי סטיותי לקיבוץ של Docker שיכול להפוך את אוסף מארחי Docker למארח וירטואלי יחיד. Docker Swarm משולב באופן מלא עם מנוע Docker ומאפשר לך להשתמש ב- API ובתהליכי רשת סטנדרטיים; הוא מיועד לפרסום, לניהול ולהרחבת תוכניות Docker.
Swarm הוא אשכול של מארחי Docker הנקראים צמתים. בואו נשקול את הרכיבים העיקריים הבאים של אשכול כאשר אתה משתמש ב- Docker Swarm לפני שנשווה את פרסום האשכול עם Kubernetes ו- Docker Swarm:
צמתי מנהל משמשים לביצוע אורכסטרציה של שליטה, ניהול אשכול והפצת משימות.
צמתי עובד משמשים להרצת תוכניות שבהן משובצות משימות על ידי צמתי מנהל. כל צומת ניתן להגדרה כצומת מנהל, צומת עובד, או שניהם כך שיש ניתן לבצע פעולות צמתי מנהל וצמתי עובד. יש לשים לב שצמתי עובד מריצים שירותי Swarm.
שירותים. שירות של Docker Swarm מגדיר את המצב האופטימלי הנדרש לכל שירות בתוך תוךניות משובצות. שירות שולט בפרמטרים כגון מספר הרפליקות, משאבי הרשת הזמינים עבורו, היציאות שיש להופיע נגישות מרשתות חיצוניות, וכו '. הגדרת השירות, כמו גם הגדרת הרשת, ניתן לשנות ולהחיל על תוךניות משובצות מבלי שנדרש לאתחל את השירות עם התוךניות ידנית.
משימות. משימה היא כלוב בו מורץ מכול אחד בודד. משימות הן חלקי שירותי Swarm.
לכן, Docker Swarm וְ Kubernetes הם שני פלטפורמות שונות המשמשות למטרות דומות. עכשיו זה הזמן להשוות ביניהם בסט מתאים של קטגוריות.
הפצת אשכול
Docker Swarm. API סטנדרטי של Docker מאפשר לך להפיץ אשכול עם Swarm על ידי שימוש ב-CLI (ממשק שורת פקודה) סטנדרטי של Docker המקל על ההפצה, במיוחד כאשר משמשים לראשונה. קלות ההפצה של Swarm בהשוואה ל-Kubernetes משיגה גם באמצעות היכולת של מאסטר Docker יחיד להחליט כיצד להפיץ שירותים. לא נעשה שימוש ב-Pods ב-Docker Swarm.
Kubernetes מחייבת אותך להשתמש בפקודות מסוימות השונות מהפקודות הסטנדרטיות של Docker. מסופקות API מסוימות ב-Kubernetes, שפירושה שגם אם אתה מכיר פקודות לניהול Docker, עשויים להיות עליך ללמוד להשתמש בסט נוסף של כלים להפצת Kubernetes. עליך להגדיר את הצומתים באופן ידני באשכול Kubernetes – עליך לבחור את צומת המאסטר, להגדיר את הבקר, מתזמן, וכו'
קידמה
Docker Swarm. בזכות ה-API הפשוט שסופק על ידי Docker, ניתן להפיץ תכולות ולעדכן שירות באשכולים גדולים וקטנים במהירות. ממשק שורת הפקודה (CLI) פשוט מאוד וקל להבנה. כתוצאה, Swarm נחשבת לפתרון יותר קידמתי בהשוואה עם Kubernetes.
קוברנטיס מספק API מאוחדים ביחס ותכונות שמספקות לעתים תהליך התקנה איטי יותר. יש שלושה סוגים של רכיבים שיש להגדיר: Pod, Deploy, ו- Service. בנוגע לגודל אוטומטי, קוברנטיס היא הבחירה המועדפת בשל יכולתה לנתח עומסי שרתים וגם לספק את ההזדמנות להתרחבות וצמצום אוטומטיים בהתאם לדרישות הנתונות. קוברנטיס היא הבחירה האופטימלית לרשתות מבוזרות גדולות ולמערכות מורכבות.
זמינות גבוהה
שני אפשרויות הפתרון כל אחת כוללות מנגנוני שכפול שירות וריבוי, ובשני המקרים המערכת נסמכת עצמית ואינה דורשת הגדרה ידנית אחרי שחולפת קריסת צומת והפוך לאשף שוב.
Docker Swarm. צמידי המנהל עוסקים במשאבי צמידי העובד ובכל האשף כולו. צמיד האשף נכחים בשיכפול של שירותים.
קוברנטיס. צמידי לא בריאים זוהים על ידי שירותי יישוב עומס של קוברנטיס, והם מוסרים מהאשף. כל ה-Pods מופצים בין הצמידים, ומספקים זמינות גבוהה, אם צומת שבה מופעלת יישום בהקפא נופלת.
איזון עומס
Docker Swarm. איזון עומס הוא תכונה מובנית וניתן לבצעו באופן אוטומטי באמצעות הרשת הפנימית של צמיד. כל הבקשות לאשף מופצות ומופנות אל צמידי האשף; כל צומת יכולה להתחבר לכל התכולה. אלמנט DNS משמש את צמיד דוקר להפצת הבקשות הנכנסות לשמות השירות.
קוברנטס. מדיניות המוגדרת ב־Pods משמשת לאיזון משאבים ב־Kubernetes. במקרה זה, יש להגדיר קונטיינרי Pods כשירותות. עליך להגדיר את הגדרות האיזון בעצמך, בעוד ש־Ingress ניתן להשתמש בו לאיזון משאבים.
יצירה והפעלת קונטיינרים
Docker Swarm. רוב הפקודות הזמינות עבור Docker CLI ניתן להשתמש בהן כאשר משמשים את Docker Swarm, בזכות ה־API התקני של Docker Swarm. Docker Compose מגדיר עבודה עם כרכים ורשתות בשימוש, בנוסף להגדרת אילו קונטיינרים חייבים להיקבץ יחד. ניתן להגדיר את מספר השולפים באמצעות Docker Compose עבור Docker Swarm.
קוברנטס. לקוברנטס יש API עצמאי, לקוח ונדרשים קבצי YAML להגדרה. זהו אחד ההבדלים המרכזיים, מאחר ש־Docker Compose ו־Docker CLI אינם יכולים לשמש להצגת קונטיינרים במקרה זה. ב־Kubernetes, המערכת להגדרת שירותים עוקבת אחר עקרון פעולה דומה לזה של Docker Compose, אך היא מורכבת יותר. הפונקציונליות של Docker Compose מתבצעת באמצעות Pods, Deployments ו־Services ב־Kubernetes, תוך שימוש בכל שכבה למטרה מסוימת. Pods אחראיים על אינטראקציה של קונטיינרים, בעוד Deployments אחראים על זמינות גבוהה ורשתות עבור צומת יחיד בקבוצה (דומה ל־Docker Compose עבור אפליקציה סטנדלון של Docker ללא Swarm), ו־Kubernetes services אחראיים על הגדרת התפעול של השירות בתוך הקבוצה, אי־ספיקת רכיבים, וכו'
רשתות
Docker Swarm. יש רשת פנימית ברירת מחדל לתקשורת בין הקונטיינרים בתוך אשכול, שבה ניתן להוסיף רשתות נוספות כרצונך. הרשתות מוגנות באמצעות תעודות TLS המיוצרות אוטומטית. ניתן גם ליצור תעודות ידנית עבור הצפנת תעבורת נתונים של הקונטיינרים.
Kubernetes. דגם הרשת של Kubernetes שונה די מאוד ומיושם באמצעות תוספות, אחת מהן היא Flannel, האפשרות הפופולרית ביותר. הגרעין המשובץ עובד עם פודים יחד והאינטראקציה יכולה להיות מוגבלת במדיניות. יש רשת פנימית שניהלת על ידי שירות ה-etcd. הצפנת TLS זמינה גם כן, אך יש להגדירה ידנית. דגם הרשת של Kubernetes מניח הגדרת שתי CIDRs, שמכונות גם "סופרנטינג"
ניטור
Docker Swarm. אין כלים מובנים לניטור ויומן, אך ניתן להגדיר ידנית כלים לניטור מצד שלישי. ניתן להשתמש ב- ELK או Reimann למטרה זו.
Kubernetes. Kubernetes מספק כלים מובנים לניטור ויומן. אפשר להשתמש ב- Elasticsearch וב- Kibana (ELK) לניטור של מצב האשכול כולו, כש- Heapster, Grafana ו- Influx נתמכים לניטור של שירותי הקונטיינרים.
ממשק משתמש גרפי (GUI)
Docker Swarm. ניתן להפעיל את ממשק המשתמש הגרפי עם כלים צד שלישי כגון Portainer.io שמספק ממשק אינטרנטי נוח למשתמש. כאלטרנטיבה, ניתן להשתמש במהדורת הארגון של Docker שמספקת ממשק גרפי לניהול אשכול.
קוברנטיס. הממשק הגרפי שמספק קוברנטיס הוא לוח בקרה אמין שניתן לגשת אליו דרך ממשק אינטרנטי שבאמצעותו ניתן לשלוט בקלות באשכול שלך. הממשק הגרפי יכול להיות כלי ערך מאוד עבור משתמשים עם ניסיון מינימלי בניהול קוברנטיס עם ה-CLI.
מסקנה
ה-Swarm של Docker הוא פתרון טבעי של Docker שמשתמש בעיקר ב-API וב-CLI של Docker. לעומת זאת, קוברנטיס הוא פרויקט של Google שמשמש לפרסום אשכול בו פועלים תקופות.
שני ה-Swarm של Docker וקוברנטיס מספקים זמינות גבוהה, איזון עומס, רשתות עטיפה ותכונות סקלביליות. ה-Swarm של Docker הוא הקל מביניהם להפעלה, מאחר ורוב הקונפיגורציה שלו ממוכנת באופן אוטומטי, והוא מצריך מעט משאבי חומרה. אך פונקציונליות מוגבלת על ידי API של Docker, וכלי ניטיביים למעקב חסרים.
קוברנטיס, לעומת זאת, הוא פתרון מודולרי עם רמת גמישות גבוהה שנתמך על ידי רוב היחידות העסקיות הגדולות למספר שנים. כלי מובנים למעקב אחר שירותים ולכל האשכול זמינים עבור קוברנטיס, אך הפרסום והקונפיגורציה קשים יותר, מה שהופך את המשאב הזה לפתרון מוגבל יותר. קוברנטיס אינו תואם את CLI ואת Docker Compose של Docker. שימוש בקוברנטיס מועדף בסביבות גדולות בהן מופעלות יישומי רבי-תכלית עמוסים מאוד.