עומס עבודה ואשכול GKE ברמת ייצור שמתאימה לארגונים

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

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

  • עומס עבודה של GKE בייצור ברמה ארגונית (תצוגה מקדימה): פריסה של תרשים helm שכולל את ההגדרה של אפליקציית אינטרנט חסרת מצב עם זמינות גבוהה. עומס העבודה מוגדר לשיפור האבטחה, האמינות והמשכיות של השירות.

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

דוגמה הצורך העסקי הטמעה
פלטפורמת מסחר גלובלית מוסד פיננסי צריך פלטפורמת מסחר עם זמן אחזור נמוך, שמופצת באופן גלובלי, עם זמן פעולה מקסימלי, אבטחה מחמירה ותאימות שניתן לבדוק כדי לטפל בעסקאות בתדירות גבוהה. כדי להבטיח זמן טעינה קצר במיוחד וחוסן (resilience), כדאי להשתמש באשכולות מרובי אזורים שמפוזרים גלובלית עם רשת מתקדמת. אפשר ליישם מדיניות רשת חזקה, הגדרות של אשכולות פרטיים ותכונות אבטחה מתקדמות להגנה על נתונים ולעמידה בדרישות הרגולטוריות.
פלטפורמת SaaS עם כמה דיירים ספק של תוכנה כשירות (SaaS) צריך לארח פלטפורמה ניתנת להרחבה, מאובטחת ומותאמת לעלויות עבור אלפי לקוחות עסקיים. הפלטפורמה צריכה לספק בידוד קפדני של דיירים, הקצאה דינמית של משאבים ואספקה רציפה של תכונות חדשות ללא השבתה. שימוש באשכולות מרובי-דיירים עם בידוד חזק של מרחבי שמות, פילוח רשת וניהול מכסות כדי להבטיח שיתוף הוגן של משאבים ואבטחה בין דיירים.
הסקת מסקנות בזמן אמת לפעולות קריטיות ארגון צריך לפרוס מודלים של AI/ML להסקת מסקנות בזמן אמת באפליקציות לזיהוי הונאות שהן קריטיות לפעילות העסקית. הארגון דורש חביון נמוך במיוחד, תפוקה גבוהה ויכולת הסתגלות מהירה לגרסאות חדשות של מודלים עם יכולת מלאה לביקורת. הגדרת אשכולות עם מאגרי צמתים ייעודיים להסקת מסקנות מ-AI. חשוב לוודא שיש קישוריות לרשת עם זמן אחזור נמוך ולהפעיל ניתוב יעיל של תעבורה לנקודות קצה של הסקת מסקנות.

ארכיטקטורה

בתמונה הבאה מוצגים הרכיבים והחיבורים בתבנית:

אוסף של צמתים שמחובר למאגר צמתים באזור העיצוב

בטבלה הבאה מתוארות הגדרות הרכיבים בתבנית הזו:

  • אשכול GKE Standard: אשכול שבו פועל עומס העבודה.

    בטבלה הבאה מפורטת הגדרת האשכול בתבנית הזו:

    הגדרות אישיות מטרה
    location: us-central1 התכונה מבטיחה את מיקום הנתונים ועמידה בדרישות בתוך גבול גיאוגרפי. הגדרה של מספר אזורים בתוך האזור מספקת זמינות גבוהה.
    network: projects/PROJECT_ID/global/networks/enterprise-vpc מציין VPC קיים, שבדרך כלל מיועד לפילוח רשת וקישוריות.
    subnetwork: projects/PROJECT_ID/regions/us-central1/subnetworks/gke-subnet מציינת תת-רשת לאשכול ב-VPC, שבדרך כלל מתוכננת עם הקצאת IP מתאימה ובידוד רשת.
    master_authorized_networks_config: [{"cidr_block": "10.0.0.0/8", "display_name": "Internal Network"}] מגבילה את הגישה לנקודת הקצה של מישור הבקרה לבלוקים ספציפיים ואמינים של כתובות IP CIDR. כך נמנעת גישה לא מורשית לממשקי API לניהול אשכולות.
    private_cluster_config.enable_private_endpoint: true ההגדרה הזו מבטיחה שאפשר לגשת למישור הבקרה רק באמצעות כתובות IP פנימיות ב-VPC או ברשתות מורשות. כך משפרים את האבטחה כי לא חושפים את המידע לציבור.
    private_cluster_config.enable_private_nodes: true התכונה הזו מוודאת שלכל צומתי העובדים יש רק כתובות IP פרטיות, כך שהם מבודדים מהאינטרנט הציבורי ושטח הפנים להתקפה מצטמצם.
    release_channel: STABLE עדכונים צפויים שנבדקו היטב שומרים על היציבות בסביבת ייצור.
    network_policy.enabled: true היא מאפשרת את מדיניות הרשת של Kubernetes, שמספקת בקרה על תקשורת בין קבוצות Pod לצורך אבטחה משופרת ומיקרו-פילוח.
    binary_authorization: true אכיפת מדיניות פריסה, כדי לוודא שרק קובצי אימג' מהימנים וחתומים של קונטיינרים יכולים לפעול באשכול.
    database_encryption: {"state": "ENCRYPTED_WITH_CMEK", "key_name": "projects/PROJECT_ID/locations/us-central1/keyRings/gke-keyring/cryptoKeys/gke-etcd-key"} מפתחות הצפנה בניהול הלקוח (CMEK) מצפינים את מסד הנתונים, מספקים אבטחת נתונים ועוזרים לעמוד בדרישות התאימות.
    workload_identity_config: {"enabled": true} מאפשר לחשבונות שירות של Kubernetes לפעול כ Google Cloud חשבונות שירות, וכך מאפשר גישה מפורטת ומאובטחת למשאבים באמצעות IAM.
    הערכים של logging_config ו-monitoring_config הם {"component_config": {"enable_components": ["SYSTEM_COMPONENTS", "WORKLOADS"]}} השירות משולב עם Cloud Logging ו-Cloud Monitoring, כדי להבטיח ניראות מקיפה, ביקורת והתראות לעומסי עבודה בסביבת הייצור.
    maintenance_policy: {"daily_maintenance_window": {"start_time": "03:00"}, "recurring_window": {"start_time": "00:00", "end_time": "04:00", "recurrence": "FREQ=WEEKLY;BYDAY=SAT,SUN"}} חלונות תחזוקה מאפשרים לקבוע מתי GKE יבצע שדרוגים אוטומטיים, כדי למזער את ההפרעה לאפליקציות קריטיות.
    enable_shielded_nodes: true צומתי GKE מוגנים מספקים אמצעי אבטחה כמו הפעלה מאובטחת ומעקב תקינות כדי להגן מפני Rootkit ותוכנות זדוניות ברמת האתחול.
    gateway_api_config: {"channel": "CHANNEL_STANDARD"} ניהול תנועה מתקדם לניתוב מורכב, איזון עומסים וניהול API באפליקציות ארגוניות.
    security_posture_config: {"mode": "ENTERPRISE", "vulnerability_mode": "VULNERABILITY_ENTERPRISE"} ניהול מתקדם של מצב האבטחה, כולל סריקת פגיעויות ואכיפת מדיניות.
  • מאגר צמתים של GKE: קבוצה של צמתים של עובדים שמריצים את הקונטיינרים של האפליקציה.

    בטבלה הבאה מתוארות ההגדרות של מאגר הצמתים בתבנית הזו:

    הגדרות אישיות מטרה
    location: us-central1. מציינים את האזור שבו נוצר מאגר הצמתים הזה. בדומה למיקום של האשכול, ההגדרה הזו מבטיחה שמשאבי מאגר הצמתים יהיו באזור גיאוגרפי יחיד.
    autoscaling: {"max_node_count":3, "min_node_count":1}. הגדרת התכונה 'שינוי גודל אוטומטי של אשכולות' למאגר הצמתים הזה. כך מוודאים שבמאגר הצמתים תמיד יהיה לפחות צומת אחד, ומגדירים את המגבלה העליונה לשלושה צמתים כדי לשלוט בעלויות ובצריכת המשאבים.
    node_config: {"machine_type":"e2-medium", "oauth_scopes":["https://www.googleapis.com/auth/cloud-platform"], "shielded_instance_config":{"enable_secure_boot":true}}. הגדרות של קבוצות לצמתים במאגר הזה. סוג המכונה הוא איזון בין מעבד לזיכרון שמתאים לעומסי עבודה לשימוש כללי. הגדרה של הגישה שניתנת לחשבון השירות. האפשרות הזו מפעילה את האתחול המאובטח במכונות וירטואליות מוגנות, ועוזרת להגן מפני תוכנות זדוניות ברמת האתחול.

הגדרת תרשים Helm

בטבלה הבאה מפורטים ההגדרות של תרשימי ה-Helm, שהותאמו לפריסה ולשינוי גודל של אפליקציית אינטרנט בסיסית ב-GKE.

הגדרות אישיות מטרה
replicaCount: 3 יוצר שלוש רפליקות ראשוניות כדי להגדיר רמה ראשונית של יתירות וזמינות גבוהה בסיסית לאפליקציה.
image.repository: gcr.io/google-samples/hello-app משתמש בתמונה של שרת אינטרנט בסיסי של Docker כ-placeholder.
resources.requests: {"cpu": "100m", "memory": "128Mi"} מציין את הכמות המינימלית של המעבד והזיכרון שמוקצים לכל פוד, כדי להבטיח שהמשאבים יהיו זמינים ושהתזמון יהיה יעיל.
resources.limits: {"cpu": "250m", "memory": "256Mi"} מציינת את הכמות המקסימלית של CPU וזיכרון שמוקצים לכל פוד, כדי למנוע מונופוליזציה של משאבים על ידי פוד יחיד.
networkPolicy.enabled: true מפעיל את כללי המדיניות של רשת Kubernetes עבור האפליקציה, שמאפשרים להגדיר כללים לגבי האופן שבו קבוצות Pod מתקשרות זו עם זו ועם נקודות קצה אחרות ברשת, ולאכוף פילוח ובידוד של הרשת.
service: {"type": "ClusterIP", "port": 80} הגדרת השירות לגישה פנימית באשכול ביציאת HTTP רגילה.
pdb: {"enabled": true, "minAvailable": 1} ההגדרה מאפשרת להגדיר תקציב לשיבוש Pod כדי להבטיח שלפחות רפליקה אחת יישאר זמין במהלך שיבושים רצוניים, וכך לשמור על זמינות גבוהה.

יצירת אפליקציית אינטרנט

אפשר להשתמש בתבניות Enterprise-grade production GKE cluster and workload כדי לפרוס את אפליקציית האינטרנט.

פריסת התשתית של האתר

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

  1. משכפלים ופורסים את תבנית אשכול GKE לייצור ברמת Enterprise כאפליקציה.

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

  2. מגדירים את הרכיבים. למידע נוסף, קראו את המאמרים הבאים:

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

  4. בחלונית פרטי האפליקציה, לוחצים על הכרטיסייה פלט.

  5. מזהים את cluster_id של האפליקציה. תצטרכו להשתמש במידע הזה כשפורסים את תרשים ה-Helm.

פריסת עומס העבודה באינטרנט

משתמשים בתבנית Enterprise-grade production GKE workload כדי לפרוס את עומס העבודה של האינטרנט באשכול שיצרתם. תפרסו תרשים helm שכולל את הגדרות עומס העבודה שלכם באינטרנט.

  1. בדף Google catalog (קטלוג Google), בתבנית Enterprise-grade production GKE workload (עומס עבודה ב-GKE ברמת ייצור ארגונית), לוחצים על Create new application (יצירת אפליקציה חדשה).

  2. בשדה שם, מזינים שם ייחודי לאפליקציה.

  3. בקטע GKE Deployment Target (יעד הפריסה של GKE), מבצעים את הפעולות הבאות:

    1. ברשימה Project list, בוחרים את הפרויקט שבו פרסתם את אשכול GKE מהאפליקציה Enterprise-grade production GKE cluster.

    2. ברשימה אזור, בוחרים את האזור שבו פרסתם את אשכול GKE.

    3. ברשימה Clusters (אשכולות), בוחרים את אשכול GKE שנפרס.

    4. ברשימה Namespace, מזינים את מרחב השמות של עומס העבודה. אם לא שיניתם את השם, מזינים default.

    5. לוחצים על יצירת אפליקציה.

    האפליקציה נוצרת ומוצגים קובצי ההגדרות.

  4. בחלונית Helm chart:

    1. בודקים את פרטי ההגדרה.

    2. אופציונלי: אפשר להתאים אישית את ההגדרה לפי הצרכים הייחודיים שלכם.

    3. כדי לפרוס את תרשים ה-Helm לאשכול, לוחצים על Deploy (פריסה).

      הוראות מפורטות מופיעות במאמר פריסת אפליקציות.

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

המאמרים הבאים