שירותי Google Cloud Platform

GCP: GKE, Cloud Run, Cloud SQL, BigQuery

בפרקטיקה שלנו, לקוח אחד על GKE Autopilot קיבל התראה: pod disruption budget violation — הפריסה (deployment) נסוגה לאחור מכיוון ש-Autopilot התחיל לפנות צמתים (nodes) כדי לבנות מחדש עבור תצורה חדשה, ו-PodDisruptionBudget עם maxUnavailable: 0 חסמו את התהליך. זו לא תקלה של Autopilot — זו התנהגות נורמלית עם PDB שהוגדר בצורה לא נכונה. במשך חמש שנות עבודה עם Google Cloud Platform, למדנו לצפות תרחישים כאלה ולהגדיר קלאסטרים כך שפריסות יתבצעו בצורה חלקה. המהנדסים המוסמכים שלנו העבירו למעלה מ-50 פרויקטים על GCP ומבטיחים שביקורת (audit) תזהה לפחות 20% חיסכון בעלויות, או שנספק תוכנית אופטימיזציה מפורטת ללא תשלום. אם אתם צריכים לתכנן או לבצע אופטימיזציה של תשתית סוהר — הזמינו ביקורת. נעריך את הפרויקט שלכם ונציע פתרונות.

מה GKE Autopilot משנה בפועל?

GKE Autopilot על Google Cloud Platform הוא מצב שבו Google מנהלת את הצמתים באופן מלא. אין node pools, אין ניהול קיבולת, אין kubectl cordon. Pods מתארים משאבים — Autopilot מבטיח אותם. (למידע נוסף על Kubernetes — פלטפורמה לתיאום קונטיינרים — ראו תיעוד Kubernetes.)

מה זה אומר בפועל: requests ו-limits חייבים להיות מוגדרים עבור כל קונטיינר ללא יוצא מן הכלל. ב-GKE סטנדרטי אפשר להיות עצלנים ולוותר על requests — ה-pods עדיין ירוצו. ב-Autopilot — לא. בקשה מינימלית: cpu: 250m, memory: 512Mi. החיוב מתבצע לפי requests, לא לפי שימוש בפועל.

Autopilot מטיל אוטומטית הגבלות securityContext. קונטיינרים לא יכולים לרוץ עם privileged: true או להרכיב hostPath. עבור כלים כמו Falco או Datadog Agent זו בעיה — הם זקוקים ל-DaemonSets עם הרשאות. ב-Autopilot הם פשוט לא עובדים. GKE סטנדרטי גמיש יותר כאן.

הבחירה בין Autopilot ל-Standard: Autopilot נוח לצוותים ללא מהנדס פלטפורמה ייעודי — פחות עומס תפעולי, אין תיקוני צמתים, bin-packing אוטומטי. Standard נדרש כאשר נדרשות תצורות צמתים מותאמות אישית, עומסי GPU, או system daemonsets ספציפיים.

למה Workload Identity הוא חובה עבור GKE?

בעיה קלאסית של GCP — מפתחות Service Account JSON בתוך Kubernetes Secrets. נוצר מפתח, מוכנס ל-kubectl create secret generic sa-key --from-file=key.json, ולעולם לא מוגדר rotation. המפתח חי שנים, ונגיש לכל מי שיכול לקרוא Secrets ב-namespace. Workload Identity פותר זאת בצורה נכונה: מבטל מפתחות ארוכי טווח ומפחית את הסיכון לדליפת אישורים פי 5 בהשוואה למפתחות JSON (לפי תיעוד Google Cloud).

כדי להגדיר Workload Identity, יש לבצע שלושה שלבים:

1. קשירת ה-Kubernetes ServiceAccount ל-GCP Service Account דרך מדיניות IAM:

   gcloud iam service-accounts add-iam-policy-binding \ [email protected] \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:project.svc.id.goog[namespace/ksa-name]" 

2. הוספת הערה (annotation) ל-ServiceAccount:

   apiVersion: v1 kind: ServiceAccount metadata: name: ksa-name annotations: iam.gke.io/gcp-service-account: [email protected] 

3. הרצת pod עם KSA זה — אסימוני GCP Service Account נמסרים דרך שרת ה-metadata. אין מפתחות JSON, rotation אוטומטי. ב-Autopilot, Workload Identity הוא חובה.

מתי לבחור ב-Cloud Run עבור Serverless?

Cloud Run על GCP מריץ קונטיינרים ללא ניהול תשתית. ההבדל מ-Lambda — קונטיינר מלא, כל runtime, עד 32 GB RAM ו-8 vCPU. קנה מידה מאפס לאלפי מופעים מקבילים. Cloud Run בנוי על Kubernetes ו-Knative.

Cloud Run מתאים עבור: APIs עם תעבורה לא צפויה, מטפלי webhook, משימות רקע דרך טריגרים של Pub/Sub, סביבות preview לבדיקות PR. בעיית ה-cold start נפתרת עם gcloud iam service-accounts add-iam-policy-binding \ [email protected] \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:project.svc.id.goog[namespace/ksa-name]" — מופע אחד תמיד חם, לא מחויב בזמן סרק (רק עבור RAM בסרק). עבור APIs רגישים לשהייה עם SLA < 200ms זה חובה — זמן התגובה יורד פי 3–5 בהשוואה ל-cold start.

Cloud Run Jobs — עבור משימות אצווה. מופעל לפי לוח זמנים דרך Cloud Scheduler, מעבד משימות במקביל באמצעות apiVersion: v1 kind: ServiceAccount metadata: name: ksa-name annotations: iam.gke.io/gcp-service-account: [email protected] ו-min-instances: 1, משלמים רק על זמן הביצוע.

איך להגדיר Cloud SQL לסביבת Production?

Cloud SQL על Google Cloud Platform תומך ב-PostgreSQL, MySQL, SQL Server. תצורת HA דרך standby replica באזור אחר — failover אוטומטי, כ-60 שניות. Connection pooling הוא קריטי עבור Cloud Run ו-Cloud Functions. Cloud SQL Auth Proxy — sidecar או קונטיינר נפרד שיוצר חיבור מאובטח דרך IAM, ללא פתיחת פורטים או ניהול אישורי SSL ידני. עבור Cloud Run על GCP: Auth Proxy רץ כ-sidecar (task-count ב-cloud run deploy), והאפליקציה מתחברת ל-parallelism.

# Cloud Run service YAML с Auth Proxy sidecar containers: - name: app image: gcr.io/project/app:latest env: - name: DB_HOST value: "127.0.0.1" - name: cloud-sql-proxy image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.11 args: - "--structured-logs" - "--port=5432" - "project:region:instance-name" 

Read Replicas ב-Cloud SQL — עבור עומסים כבדים של קריאה. קידום (promotion) במקרה של קפיצות פתאומיות בקריאות, אנליטיקה על נתוני production ללא עומס על ה-master. Replica חוצה אזורים — עבור תרחישי DR.

איך Cloud SQL Auth Proxy עובד?

Cloud SQL Auth Proxy על GCP משתמש ב-IAM כדי לאמת ולהצפין חיבורים. הוא רץ כקונטיינר sidecar בתוך אותו pod (עבור Cloud Run) או על VM. ה-proxy פותח פורט TCP מקומי ומעביר תעבורה למופע Cloud SQL דרך מנהרה מאובטחת. אין צורך בלבנות IPs או לנהל אישורי SSL — ה-proxy מטפל בכל האבטחה אוטומטית. עבור אפליקציות המשתמשות ב-private IP, ה-proxy יכול להתחבר דרך רשת VPC ללא חשיפה לאינטרנט.

BigQuery: אנליטיקה ללא ניהול תשתית

BigQuery על GCP — מחסן אנליטי serverless. שאילתות על טרה-בייטים של נתונים מסתיימות בשניות. חיוב: $5 לכל טרה-בייט של נתונים מעובדים (או תעריף קבוע דרך capacity reservations). הטעות העיקרית של מתחילים היא --dependency על טבלאות גדולות. BigQuery הוא אחסון עמודי (columnar): localhost:5432 סורק את כל העמודות, # Cloud Run service YAML с Auth Proxy sidecar containers: - name: app image: gcr.io/project/app:latest env: - name: DB_HOST value: "127.0.0.1" - name: cloud-sql-proxy image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.11 args: - "--structured-logs" - "--port=5432" - "project:region:instance-name" — רק שלוש. הפרש העלות הוא משמעותי — שאילתה נכונה חוסכת עד 80% מהתקציב.

לקוח אחד הפחית את עלויות BigQuery מ-$5,000 ל-$1,200 בחודש לאחר יישום partitioning ו-clustering.

Partitioning על עמודת זמן (SELECT *, SELECT *) — חובה עבור טבלאות אירועים. שאילתה עם SELECT id, name, created_at סורקת רק partition אחד, לא את כל ההיסטוריה. Clustering על עמודות בשימוש תדיר ב-WHERE/JOIN — הפחתה נוספת בנפח הסריקה. BigQuery ML מאפשר אימון מודלים ישירות ב-SQL — רגרסיה לוגיסטית, k-means, חיזוי סדרות עתיות — ללא ייצוא נתונים.

תהליך היישום

אנו עוקבים אחר תהליך מובנה עבור כל התקשרות עם GCP:

1. ביקורת תשתית – ניתוח התצורה הנוכחית (IAM, רשתות, עלויות, CI/CD, ניטור). מדידת הוצאות הבסיס וזיהוי ניצחונות מהירים.
2. תכנון פתרון – הפקת HLD/LLD עם החלטות ארכיטקטוניות (Autopilot לעומת Standard, Workload Identity, Cloud Run לעומת GKE, אסטרטגיית partitioning).
3. יישום – פריסה באמצעות IaC (Terraform, Cloud Deployment Manager), הגדרת pipelines של CI/CD (GitLab CI, GitHub Actions, Cloud Build), הקמת ניטור (Cloud Monitoring, Grafana).
4. בדיקות ואימות – בדיקות עומס, chaos engineering (סימולציה של כשלי צמתים, הפרות PDB), סריקת אבטחה, אימות תחזית עלויות.
5. מסירה והדרכה – מסירת runbook, סדנת צוות (2 מפגשים), תמיכה של שבועיים לאחר היישום.

מה השירות כולל

• ביקורת תשתית GCP נוכחית: IAM, רשתות, עלויות, זיהוי חיסכון של עד 40%.
• תיעוד ארכיטקטוני (HLD/LLD).
• פריסת קלאסטרים של GKE עם Workload Identity, Autoscaling, NetworkPolicies.
• הגדרת Cloud Run + Cloud SQL Auth Proxy.
• אופטימיזציה של BigQuery: partitioning, clustering, materialized views — הפחתת עלויות שאילתות פי 5–20.
• Pipelines של CI/CD (GitLab CI, GitHub Actions, Cloud Build).
• ניטור והתראות (Cloud Monitoring, Grafana).
• הדרכת צוות (סדנת GCP).
• תמיכה לאחר היישום (שבועיים).

לוחות זמנים אופייניים

העלות מחושבת באופן אישי לאחר ביקורת התשתית הנוכחית והדרישות. אם אתם נתקלים בבעיות PDB דומות ב-Autopilot או רוצים לקצץ בהוצאות GCP ב-20% או יותר, צרו קשר לקבלת הערכת ביקורת תשתית GCP. הזמינו ייעוץ וקבלו תוכנית אופטימיזציה מפורטת עבור סביבת Google Cloud Platform שלכם עם חיסכון צפוי של עד 40%.