Skip to content
Kubernetes פרטי

Private Kubernetes Deployment for Autonomous Reliability Infrastructure

Run Zof execution-compatible agents in customer-managed Kubernetes clusters. Control plane and execution plane stay separable; Zof does not claim to install a full Kubernetes platform for you.

אשכולות מנוהלים בידי הלקוח

הפרדה בין מישור בקרה למישור הרצה

דפוסי בידוד namespace

תואם למודלים היברידיים ולמובלעות

מדוע אורקסטרציה פרטית

מדוע ארגונים נדרשים לאורקסטרציה פרטית

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

  • -סטנדרטים קיימים של אשכולות וצינורות GitOps
  • -בעלות צוות הפלטפורמה על nodes ועל הרשת
  • -הצורך לשמור עומסי עבודה רגישים מחוץ להרצת SaaS רב-דיירים
  • -סביבות מפוקחות עם בידוד ברמת namespace
אשכולות לקוח

הרצת תשתית הרצה באשכולות מנוהלים בידי הלקוח

ניתן לפרוס סוכני הרצה כעומסי עבודה באשכולות שאתם מפעילים. תכנון ואישורים יכולים לרוץ במישורי בקרה בענן, בענן פרטי או on-prem בהתאם למדיניות.

  • -סוכנים מתוזמנים כמו שירותים פנימיים אחרים
  • -תואם ל-CNI ולמנועי המדיניות של הלקוח
  • -אין דרישה לגישה נכנסת לאשכול
  • -תמיכה בצי רב-אשכולות לאורך זמן
הפרדת מישורים

הפרדה בין מישור הבקרה למישור ההרצה

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

הרצה ב-Kubernetes פרטי

סוכנים תואמי-הרצה באשכולות בניהול הלקוח, ולא התקנת פלטפורמה מלאה.

מישור בקרה (של הלקוח או של Zof)אשכול Kubernetes של הלקוחמישור בקרהחתימהNamespaceסוכן הרצהעומסי עבודהסודותפריטים (Artifacts)גבול הטלמטריה
  • -גבול ברור לסקירת אבטחה
  • -נתוני runtime רגישים נשארים ב-namespaces של ההרצה
  • -ממשקי ה-API של מישור הבקרה אינם מריצים בדיקות מול יישומים מוגנים באופן ישיר
  • -חלוקות היברידיות נפוצות בהשקות ארגוניות
סוכני K8s

סוכני הרצה של Kubernetes

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

  • -פריסה באמצעות manifests או operators מאושרים בידי הלקוח
  • -כיבוד מגבלות משאבים ומדיניות אבטחת pods
  • -זהות runner ורשימות היתר עבור מארחי הרצה
  • -השקות מדורגות לכל namespace או אשכול
גבולות

גבולות הרצה מאובטחים

namespaces, מדיניות רשת ו-service accounts מבודדים את ההרצה מעומסי עבודה שאינם קשורים. סודות מותקנים (mounted) בזמן ההרצה ואינם מאוחסנים ב-Zof Cloud.

  • -RBAC בהיקף namespace
  • -שילוב עם מנהלי סודות חיצוניים במקומות שבהם נתמך
  • -התאמה אופציונלית ל-service mesh
  • -ביקורת על אירועי מחזור חיים של הסוכן
בדיקות פנימיות

בדיקת יישומים פנימיים בלבד

אימות מיקרו-שירותים, ממשקי API פנימיים וממשקי ניהול הנגישים מרשתות האשכול מבלי לחשוף אותם לאינטרנט הציבורי.

  • -בדיקות שירות-לשירות בתוך האשכול
  • -ingress בלבד במקומות שבהם המדיניות מתירה
  • -שילוב עם edge runners עבור מערכות מורשת מחוץ לאשכול
  • -מיקוד מודע-graph מצמצם רעש
בידוד

בידוד namespace

צוותים ממפים יחידות עסקיות או סביבות ל-namespaces עם מדיניות, שמירת נתונים ומצבי ראיות נפרדים.

  • -הפרדה בין dev / staging / prod
  • -מכסות ומגבלות מקביליות לכל צוות
  • -מאגרי ראיות בהיקף namespace
  • -זרימות קידום בין namespaces
סודות

טיפול בסודות

אישורי גישה מתווכים בזמן ההרצה באמצעות PAM או שילובי סודות של האשכול. סודות ארוכי-חיים אינם מועתקים ל-SaaS חיצוני כברירת מחדל.

  • -מועדפים tokens קצרי-חיים
  • -דפוסים תואמי-PAM
  • -ללא שמירת סודות במישור התכנון ללא אישור
  • -רוטציה בהתאם לתקנים שלכם
פריטי Artifact

ניתוב artifacts

artifacts ובאנדלים של בדיקות נשארים באחסון בשליטת הלקוח, אלא אם תגדירו egress מסונן או מטא-נתונים.

ארכיטקטורת הרצה היברידית

תזמור בענן עם צי הרצה מקומי מבוזר.

ענן / ענן פרטימערך ההרצה של הלקוחבקרהבינהמריץ VPCמריץ קצהנקודת קצהמריץ on-prem
  • -תואם-S3, NFS, או volumes בתוך האשכול
  • -מדיניות שמירת נתונים לכל namespace
  • -checksum וחתימה עבור באנדלים
  • -קידום אופציונלי לקטלוג ראיות מרכזי
טלמטריה

גבולות טלמטריה

מדדים ויומנים מהסוכנים יכולים להישאר ב-stacks של observability בתוך האשכול. לוחות מחוונים מרכזיים עשויים לקבל סיכומי מטא-נתונים בלבד.

  • -דפוסים תואמי-OpenTelemetry במקומות שבהם נתמך
  • -השחרה לפני ייצוא חוצה-גבולות
  • -מזהי קורלציה לצורכי ביקורת
  • -ללא חובת ייצוא מלא של יומנים
ממשל

ממשל ארגוני

חתימת קפסולות, אישור אנושי ושערי תיקון חלים באופן אחיד בין אם ההרצה מתבצעת על VMs, bare metal או Kubernetes.

  • -גרסת מדיניות מקובעת להרצות
  • -שרשראות אישור עבור מסלולי ייצור
  • -שילוב עם רשומות שינוי של ITSM
  • -ייצוא עבור GRC וביקורת פנימית
דפוסים היברידיים

דפוסי ארכיטקטורה היברידיים

הרצה ב-Kubernetes לרוב מתקיימת לצד VPC runners, אתרי edge וסוכני endpoint תחת מישור בקרה אחד.

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

שאלות על פריסת on-prem

שאלות נפוצות מצוותי תשתית ואבטחה.

לא. ההרצה משתמשת ב-runners שנפרסו בידי הלקוח בתוך הרשת שלכם. Zof אינה דורשת גישה נכנסת לסגמנטים מוגנים.
Next step

שוחחו על פריסה מאובטחת עם Zof

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

01Zof Console

משטח אחד למצב, לתפעול ולמה שדורש תשומת לב בהמשך.

הבית המאומת שצוותי הנדסה, QA ו-SRE פותחים מדי יום: מצב האיכות, הרצות פעילות, כיסוי לפי מודול, ומה דורש תשומת לב בהמשך.

מדדי ביצוע תפעוליים

  • הרצות
  • כיסוי
  • סיכון

חיים בכל סביבה שאליה אתם משחררים.

עמוד שדרה של העבודה

  • מפרטים
  • בדיקות
  • לוחות זמנים

מהמפרט ועד לרגרסיה מתוזמנת.

מסגרות הגנה

  • RBAC
  • SSO
  • ביקורת

כל פעולה ניתנת לייחוס לאדם מזוהה בשמו.

LIVE/console
מרכז הפיקוד הראשי של Zof AI המציג 12 הרצות ב-94% הצלחה, 3 בעיות קריטיות פתוחות, 84% כיסוי, ארבעה פסי מעקב מודולים, צינור המפרטים, לוחות הזמנים הקרובים ופעולות מומלצות הבאות, עם סרגל צד של הרצות פעילות.
Home view · Checkout Service · Staging · captured live from the product.
  • 01 · RUNS · 24H

    94% pass

    12 runs across staging

  • 02 · COVERAGE

    84%

    Across four modules

  • 03 · ACTIVE RUNS

    3 running

    Live on this branch

  • 04 · NEXT ACTIONS

    Recommended

    Triage gaps, new spec

פריסת Kubernetes פרטית לאמינות אוטונומית | Zof AI