שיטות מומלצות לניטור רשת ב-GKE

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

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

הוראות מפורטות לפתרון בעיות ונהלי אבחון זמינים במאמר פתרון בעיות שקשורות לניטור רשת.

היתרונות של ניראות הרשת ב-GKE

הטמעה של אסטרטגיית יכולת צפייה ב-GKE מספקת את היתרונות המרכזיים הבאים:

  • הפחתת הזמן הממוצע עד לפתרון (MTTR): בעזרת מדדים מבוססי eBPF ויומני זרימה של Hubble, אפשר לבודד באופן מיידי אנומליות ברשת. התובנות האלה מאפשרות להבחין בין כשלים ברמת האפליקציה, חסימות של Kubernetes NetworkPolicy ונטישות של חומת אש ב-VPC, וכך לקצר את מחזורי הניפוי מפרק זמן של שעות לפרק זמן של דקות.
  • מכשור ברמת הליבה ללא sidecars: ב-GKE Dataplane V2 מופעלת לוגיקה של יכולת צפייה ישירות בליבת Linux של המארח באמצעות eBPF. כך לא צריך פרוקסי מסוג sidecar שדורש הרבה משאבים או שינויים בקוד ברמת האפליקציה, וזה מבטיח עומס מינימלי ושמירה על ביצועי האפליקציה.
  • ביקורת רציפה על התאימות לאבטחה: רישום ביומן של NetworkPolicy יוצר יומני ביקורת מפורטים לכל ניסיון חיבור (החלטות של ALLOW או DENY). היומנים האלה מספקים תיעוד חסין מפני שינויים של התנועה באשכול, שחיוני כדי לעמוד בדרישות של מסגרות רגולטוריות (כמו PCI-DSS,‏ SOC 2 ו-HIPAA).
  • אימות פרואקטיבי של נתיבים: שילוב עם בדיקות קישוריות מאפשר לדמות נתיבי רשת ולהעריך באופן סטטי את מדיניות הרשת של GKE לפני פריסת עומסי העבודה, וכך למנוע סטיות בהגדרות ובעיות בקישוריות בשלב הפריסה.
  • אופטימיזציה של משאבים ועלויות: מעקב מפורט אחרי זרימת הנתונים חושף חוסר יעילות כמו ניצול מוגזם של יציאות Cloud NAT, עליות חדות בהעברת נתונים בין אזורים ודפוסי פתרון DNS שלא נשמרו במטמון. כך אפשר לתכנן את הקיבולת ולנהל את העלויות בצורה מושכלת.

ארכיטקטורת ניראות הרשת ב-GKE

‫GKE Dataplane V2 מציע חבילת כלים רב-שכבתית למעקב אחרי פעולות, שנועדה לשלבים שונים של פעילות. בטבלה הבאה מפורטים הרכיבים העיקריים ותרחישי השימוש המומלצים שלהם:

רכיב ניראות תרחיש ראשי לדוגמה זמינות שמירת נתונים תקורה של ביצועים אותות טלמטריה מרכזיים
מדדים של GKE Dataplane V2 ניטור התקינות בכל המערכת, ניתוח מגמות והתראות. GKE Dataplane V2 בלבד שמירת טלמטריה היסטורית (Cloud Monitoring והשירות המנוהל של Google Cloud ל-Prometheus שומרים מדדים ויומנים למשך 30 ימים או יותר) זניח (צבירת נתונים ברמת הליבה) מונים של מנות ושל בייטים, מספר האיפוסים של TCP ושיעורי הנטישה של החיבורים (pod_flow_drop_count).
יומנים של NetworkPolicy ביקורת על מדיניות האבטחה, ניתוח היסטורי של חיבורים ותאימות. ‫GKE Dataplane V2 בלבד (לNetworkLoggingהגדרת משאב בהתאמה אישית) ניתן להגדרה (Cloud Logging) נמוך (ייצוא יומן עם מאגר זמני) מטא-נתונים של החיבור (תוויות של מקור ויעד, כתובות IP, יציאות) ופסיקות מדיניות (ALLOW או DENY).
ממשק המשתמש ו-CLI של Hubble ניתוח אינטראקטיבי של תנועת הנתונים בזמן אמת וניפוי באגים ברמת החבילה בזמן אמת. GKE Dataplane V2 בלבד זמני (מאגר זמני מקומי של הצומת) נמוכה (הפעלה דינמית) מעקב אחר זרימה בזמן אמת, סיבות מפורטות להפסקת הזרימה (למשל, נדחתה על ידי מדיניות או שהטבלה של conntrack הגיעה לקיבולת המקסימלית).
מדדי DNS של GKE מעקב אחרי ביצועי פענוח DNS, יעילות המטמון וחביון בשרתים במעלה הזרם. כל האשכולות Long-term (Cloud Monitoring) זניח מספר בקשות DNS, יחס הפגיעה במטמון והחמצה, זמן האחזור של העברה במעלה הזרם ודחיות של מגבלות מקבילות.
בדיקות קישוריות אימות נתיבים לפני הפריסה וביקורת על הגדרות סטטיות. כל האשכולות לא רלוונטי (סימולציה על פי דרישה) אין (סימולציה סטטית) נתיב ניתוב מנות בהדמיה, כולל הערכה של NetworkPolicy בהדמיה.
VPC Flow Logs ביקורת על תעבורת נתונים בין צמתים ותעבורת נתונים חיצונית, פורנזיקה דיגיטלית של אבטחה וניתוח עלויות. כל האשכולות ניתן להגדרה (Cloud Logging או BigQuery) ללא (תדירות דגימה שניתן להגדרה) פרטי חיבור של 5-tuple, בייטים וחבילות שנשלחו, מטא-נתונים של GKE (מרחב שמות, עומס עבודה, שירות) ו-RTT (עבור TCP).
Flow Analyzer ניתוח ויזואלי של תעבורה ב-VPC, זיהוי של הגורמים העיקריים לתעבורה וניתוח של עלויות בין אזורים בלי לכתוב שאילתות SQL. כל האשכולות בהתאם לשמירת הנתונים בדלי של Observability Analytics ללא (ממשק משתמש לניתוח) נפח התנועה והחביון המצטברים שמקובצים לפי עומס עבודה או שירות ב-GKE.

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

מודל מנטלי של יכולת התבוננות ב-GKE ולולאת תעדוף

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

בחירת מקור הטלמטריה הנכון

אם יש כמה מקורות טלמטריה, צריך לבחור את הכלי שמתאים למשימה התפעולית הנוכחית:

מקור טלמטריה תשובות אידיאלי ל Google Cloud יעד
מדדים של GKE Dataplane V2 מה קורה ובאיזה היקף? מרכזי בקרה, התראות ותכנון קיבולת. Cloud Monitoring‏ (prometheus.googleapis.com)
יומנים של NetworkPolicy למה חיבור נחסם ב-GKE? ביקורות אבטחה וניתוח שורש הבעיה במדיניות האבטחה. Cloud Logging (policy-action יומן)
VPC Flow Logs מה קרה לתנועה הזו אחרי שהיא יצאה מה-Pod? ניתוח היסטורי של תנועת הגולשים בין עומסי עבודה, עלויות של העברת נתונים בין אזורים ושיוך של נטישות ברמת ה-VPC. Cloud Logging ו-Observability Analytics (vpc_flows יומן)
ממשק המשתמש ו-CLI של Hubble מה עובר בצומת כרגע? ניפוי באגים בזמן אמת, חלופה ל-tcpdump ואירועים פעילים. מאגר זמני של נתונים (Hubble CLI)
בדיקות קישוריות האם התנועה יכולה לעבור בהצלחה? בדיקה פעילה של מישור הנתונים וניתוח נתיבים: אימות של הנגישות וזיהוי של נקודות השמטה מדויקות בחומות אש של VPC, במסלולים ובצמתים של GKE. Network Intelligence Center (סימולציה)

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

אפשר להשתמש בתהליך העבודה הזה שניתן לחזור עליו כדי לתעדף כל אירוע שקשור לרישות ב-GKE:

  1. זיהוי אנומליה: זיהוי הבעיה באמצעות התראות של Cloud Monitoring (לדוגמה, עליות פתאומיות באיפוסים של TCP, דחיות של מגבלות מקבילות של DNS או נפילות של מנות).
  2. בידוד השכבה: מריצים את בדיקת הבסיס של מכונה וירטואלית ב-GCE (ראו טריאז' לזמן אחזור ברמת הצומת ובצווארי בקבוק של CNI) כדי לקבוע אם החסימה היא בתוך אשכול GKE (CNI,‏ NetworkPolicy, ‏ IP masquerade) או מחוץ לו ב-VPC (כללי חומת אש, ניתוב, Cloud NAT).
  3. בדיקת שורש הבעיה: ביצוע ניתוח מפורט של התהליך:
    • במקרה של אירועים פעילים: משתמשים ב-Hubble CLI ‏ (hubble observe) כדי להזרים נתונים של זרימות בזמן אמת ולזהות את הסיבות להפסקת הזרימה.
    • לבעיות היסטוריות או לבעיות שמתרחשות לסירוגין: מריצים שאילתה ביומנים של NetworkPolicy או ביומני זרימה של VPC ב-Cloud Logging.
  4. אימות התיקון: מריצים בדיקת קישוריות מדומה כדי לוודא שהנתיב מותר באופן סטטי, ואז בודקים את לוח הבקרה של המדדים כדי לוודא ששיעור הנטישה חזר לאפס.

התראות וניטור יזום של הרשת

כדי לשמור על זמינות גבוהה, אדמינים של הפלטפורמה צריכים להגדיר מדיניות התראות ב-Cloud Monitoring כדי לזהות ירידה בביצועים של הרשת לפני שהיא משפיעה על עומסי העבודה.

התראה על עליות חדות באובדן מנות

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

  • שאילתת Prometheus‏ (PromQL):

    sum(rate(pod_flow_egress_flows_count{verdict="DROPPED"}[5m])) by (source) > 10

  • הפעולה המומלצת: כדאי לעיין במאמר אבחון של אובדן מנות וחסימות של NetworkPolicy כדי לבודד את הסיבה הספציפית לאובדן המנות ב-GKE NetworkPolicy או ב-eBPF.

התראה על ניצול מלא של קיבולת ה-DNS

כש-CoreDNS או NodeLocal DNSCache מגיעים למגבלת השאילתות המקבילות שלהם, חיפושי DNS הבאים נדחים, מה שמוביל לפסק זמן לסירוגין באפליקציה.

  • שאילתת Prometheus‏ (PromQL):

    sum by (cluster_name) (rate(kubernetes_io_networking_dns_kubedns_max_concurrent_rejected_request_count[5m])) > 0

  • פעולה מומלצת: הגדלת מספר העותקים של kube-dns או הטמעה של NodeLocal DNSCache כדי לחלק את עומס הרזולוציה. שלבים מפורטים אפשר למצוא במאמר בנושא אבחון של כשלים בפענוח DNS.

התראה על עליות פתאומיות באיפוס TCP

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

  • Monitoring Query Language (MQL):

    fetch prometheus_target
| metric 'prometheus.googleapis.com/hubble_tcp_flags_total/counter'
| filter (metric.flag == 'RST')
| align rate(1m)
| every 1m
| group_by [metric.source, metric.destination], sum(val())
| condition val() > 50

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

אימות אוטומטי של נתיבים ב-CI/CD

אפשר לשלב בדיקות קישוריות בצינורות פריסה כדי לאמת נתיבי רשת באופן סטטי לפני ניתוב תנועת הייצור. משתמשים ב-CLI של gcloud כדי לוודא שעומסי עבודה חדשים שפרסתם יכולים להגיע לתלות חיצונית (כמו מסדי נתונים וממשקי API) בלי חסימות של מדיניות.

  • דוגמה לפקודה:

    gcloud network-management connectivity-tests create test-prod-db-egress \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/my-app-pod \
    --destination-ip-address=10.240.0.100 \
    --protocol=TCP \
    --destination-port=5432

הפעלת ניתוח נתונים של יכולת התצפית לצורך ניתוח חזותי של תהליכים

כדי להפעיל ניתוח חזותי של תעבורת VPC ללא SQL, צריך לשדרג את קטגוריית היומנים של GKE (בדרך כלל קטגוריית _Default) לשימוש ב-Observability Analytics. כך אדמינים של הפלטפורמה יכולים להשתמש ב-Flow Analyzer כדי לבדוק את פילוח התנועה ואת העלויות של העברת הנתונים. מידע נוסף מופיע במאמר ניתוח העלויות והביצועים של תנועת הגולשים באשכול באמצעות Flow Analyzer.

אוטומציה של Terraform: יכולת צפייה כקוד

כדי להטמיע את ארכיטקטורת ניראות (observability) זו באופן עקבי ולהימנע משגיאות בהגדרה ידנית, פורסים את פייפליין הטלמטריה באמצעות הגדרת Terraform הבאה (נדרש פלאגין שמתממשק עם שירותים חיצוניים google-beta):

# Configure the VPC Subnet with VPC Flow Logs enabled and all metadata included
resource "google_compute_subnetwork" "gke_subnet" {
  name          = "gke-subnet"
  ip_cidr_range = "10.0.0.0/20"
  region        = "us-central1"
  network       = google_compute_network.custom.id

  # Enable VPC Flow Logs. flow_sampling is the secondary sampling rate, which
  # applies to flow log entries after they are generated. The primary packet
  # sampling rate is dynamic and isn't configurable.
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5 # Default rate; satisfies the LIGHT org policy tier
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# Configure GKE Cluster with Dataplane V2, Intranode Visibility, and Hubble
resource "google_container_cluster" "primary" {
  provider   = google-beta
  name       = "gke-observability-cluster"
  location   = "us-central1"
  network    = google_compute_network.custom.id
  subnetwork = google_compute_subnetwork.gke_subnet.id

  # Enable Dataplane V2 (Required for all advanced telemetry)
  datapath_provider = "ADVANCED_DATAPATH"

  # Enable Intranode Visibility (ensures local node pod-to-pod traffic hits the VPC)
  enable_intranode_visibility = true

  # Enable Managed Service for Prometheus (GMP)
  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus {
      enabled = true
    }

    # Enable Dataplane V2 Flow Observability (Hubble Relay and metric exposure)
    advanced_datapath_observability_config {
      enable_metrics = true
      enable_relay   = true
    }
  }
}

# Upgrade the Default log bucket to use Log Analytics (required for Flow Analyzer)
resource "google_logging_project_bucket_config" "default_analytics" {
  project          = var.project_id
  location         = "global"
  bucket_id        = "_Default"
  enable_analytics = true
}

# Define a baseline static path validation test (Pod to external internet gateway)
resource "google_network_management_connectivity_test" "pod_to_internet" {
  name = "pod-to-internet-egress"
  source {
    gke_pod = "projects/${var.project_id}/locations/us-central1/clusters/${google_container_cluster.primary.name}/k8s/namespaces/prod/pods/my-app-pod"
  }
  destination {
    ip_address = "8.8.8.8"
    port       = 443
  }
  protocol = "TCP"
}

אופטימיזציה של עלויות והפחתת רעשים

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

השבתת יומני חיבורים מורשים

כברירת מחדל, הרישום ביומן של NetworkPolicy מתעד גם חיבורים שאושרו וגם חיבורים שנדחו. החיבורים המותרים מהווים את רוב נפח היומן (לרוב 99% או יותר מהתנועה). אפשר לעדכן את ההגדרה של NetworkLogging האשכול כדי לתעד רק חיבורים שנדחו (drops), וכך להפחית באופן משמעותי את עלויות הרישום ביומן:

  1. שומרים את קובץ המניפסט הבא בשם network-logging-config.yaml:

    apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: false # Disable logging for allowed traffic
      delegate: false
    deny:
      log: true  # Keep logging for blocked traffic (critical for security/triage)
      delegate: false

  2. מחילים את ההגדרה:

    kubectl apply -f network-logging-config.yaml

העברת הרשאת רישום באמצעות הערות

כדי לשלוט בעלויות בצורה מדויקת, אפשר להגדיר את delegate: true במשאב המותאם אישית NetworkLogging כדי להעביר את הרישום ביומן לביאורים. ההגדרה הזו מבטיחה את הדברים הבאים:

  • תנועה מותרת מתועדת רק אם ל-NetworkPolicy התואם יש את ההערה policy.network.gke.io/enable-logging: "true".
  • תנועה שנדחתה נרשמת ביומן רק לאובייקטים מסוג Pod במרחבי שמות עם ההערה policy.network.gke.io/enable-deny-logging: "true".

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

שינוי תדירות הדגימה של VPC Flow Logs

בהגדרות של Terraform (או במסוף Google Cloud ), מורידים את שיעור הדגימה המשני רק ברשתות משנה שבהן נדרשים נפח תנועה ועלויות מצטברות, ולא רשומות של זרימות נתונים בודדות. מכיוון ש-VPC Flow Logs מעריך את סך התעבורה מתוך חבילות נתונים שנדגמו, אפשר להשתמש בספירת הבייטים והחבילות לניתוח עלויות בשיעורים נמוכים יותר. לא מגדירים את התעריף flow_sampling מתחת ל-0.1, התעריף המינימלי שעומד בדרישות של רמת ESSENTIAL במדיניות הארגון constraints/compute.requireVpcFlowLogs:

resource "google_compute_subnetwork" "gke_subnet" {
  # ... other subnet configs ...
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.1 # ESSENTIAL tier: volume and cost analysis, not per-flow troubleshooting
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

בטבלה הבאה מפורטים שיעורי הדגימה המשניים והרמות התואמות של מדיניות הארגון constraints/compute.requireVpcFlowLogs:

תדירות דגימה משנית רמת מדיניות הארגון מתי כדאי להשתמש בזה
1.0 COMPREHENSIVE אשכולות עם דרישה קבועה לניתוח פורנזי או לביקורת אבטחה לכל זרימה. חשוב לבחור את הקצב הזה כשמגדירים את רשת המשנה, כי אם מעלים את הקצב אחרי תקרית, לא ניתן לשחזר זרימות שלא נלכדו.
0.5 (ברירת מחדל) LIGHT רשתות משנה שמגבות אשכולות שפותרים בעיות בהם. זהו התעריף שמוגדר כברירת מחדל והיעד הבסיסי המומלץ.
0.1 ESSENTIAL רשתות משנה שבהן אתם צריכים נתונים מצטברים של נפח התנועה והעלות, ולא נתונים של זרימות נפרדות.

החלת החרגות ב-Cloud Logging

להחריג יומנים עם רעשי רקע או יומנים לא רלוונטיים (כמו kube-system תנועה פנימית) ישירות ברמת יעד (sink) של Cloud Logging. מוסיפים מסנן החרגה ל_Default sink כדי להשליך מטא-נתונים פנימיים או יומני מערכת של Pod:

resource.type="gce_subnetwork" AND
log_name:"projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND
jsonPayload.src_gke_details.pod.pod_namespace="kube-system"

שיטות מומלצות וטיפים לתפעול

כשפורסים את צינור הטלמטריה של האשכול ומנהלים אותו, חשוב להביא בחשבון את ההנחיות התפעוליות הבאות:

  • הפעלה של תכונת הניטור של תעבורת הנתונים ב-GKE Dataplane V2 לפי דרישה: ניטור תעבורת הנתונים (hubble-relay) עלול להוסיף עומס קל. בסביבות ייצור, אפשר להפעיל את התכונה הזו במהלך סשנים של ניפוי באגים ואז להשבית אותה כדי לצמצם את צריכת המשאבים בצמתים:

    gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2-flow-observability \
    --location=LOCATION

  • הפעלת האפשרות 'חשיפה בתוך הצומת': כברירת מחדל, התנועה בין שני אובייקטים של Pod באותו צומת לא יוצאת מהצומת, ולכן היא לא מוצגת ביומני הזרימה של VPC. האפשרות Intranode Visibility מופעלת כברירת מחדל באשכולות Autopilot ומושבתת כברירת מחדל באשכולות Standard, כולל אשכולות Standard שמשתמשים ב-GKE Dataplane V2. הפעלת התכונה Intranode Visibility יוצרת לולאה לתעבורה הזו דרך ה-VPC, ועוזרת להבטיח שכללי חומת האש של ה-VPC ויומני תעבורת הנתונים יחולו באופן עקבי.

  • הסבר על אופן הפעולה של פתרון VIP של שירות: אחרי שכתובת IP וירטואלית (VIP) של שירות Kubernetes נפתרת לכתובת IP של Pod בקצה העורפי, מדדים של שכבת התעבורה (OSI Layer 4) סופרים אותה כתנועה מ-Pod ל-Pod. כדי לעקוב אחרי כתובת ה-VIP של השירות שהייתה היעד המקורי, מסתמכים על זרימות בזמן אמת של Hubble CLI במהלך לחיצת היד של החיבור.

  • התאמה בין חותמות הזמן של המדדים והיומנים: כשחוקרים אירוע, צריך ליצור קורלציה בין העלייה החדה במדדים של Cloud Monitoring לבין חלון הזמן המדויק כשמבצעים שאילתות ביומנים ב-Cloud Logging או ב-Hubble CLI, כדי לוודא שמנתחים את אותו אירוע.

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