הקמת תשתית ענן היברידית
תארו לעצמכם: יש לכם מערכת מדור קודם במרכז נתונים עם עשרות תלותיות חומרה ורישיונות. העברתה לענן היא סיכון של חודשים רבים. אבל אתם רוצים להריץ מיקרוסרביסים חדשים על Kubernetes ב-AWS. הפתרון הוא תשתית היברידית. אנו מגדירים אותה במפתח פתוח כך שהאתר המקומי והענן עובדים כקלאסטר אחד עם רשת משותפת, DNS ו-IAM.
היכן דברים בדרך כלל נשברים
הבעיה הנפוצה ביותר היא חוסר עקביות בכתובות IP. הרשת המקומית חיה ב-10.0.0.0/8, ה-VPC בענן ב-172.16.0.0/12, ובמבט ראשון הכל נראה בסדר. אבל כשמוסיפים Transit Gateway, peering למספר VPCs, ו-VPN ארגוני, CIDRs חופפים מתחילים לבלבל בשקט את הנתב. חבילות נופלות, שירותים הופכים ללא זמינים, ואף צד לא רואה שגיאה ברמה שלו.
נקודת הכאב השנייה היא DNS. בסביבה היברידית, db.internal.company.com מ-pod בענן חייב להיפתר לכתובת ה-IP של מסד נתונים מקומי, ו-api.svc.cluster.local מיישום מקומי חייב להיפתר ל-ClusterIP של שירות Kubernetes. זה נפתר באמצעות Route 53 Resolver עם כללי העברה ל-DNS המקומי, ו-Conditional Forwarder בצד המקומי ל-Route 53. אם לא מגדירים את שני הכיוונים, חצי מהפתרונות ייכשלו עם NXDOMAIN.
אימות הוא גם לא טריוויאלי. יישומי ענן זקוקים לאישורים עבור מערכות מקומיות ולהיפך. IAM Roles for Service Accounts (IRSA) ב-EKS עובד מצוין בתוך AWS, אבל עבור משאבים מקומיים צריך או Vault עם AWS auth backend או סודות דרך AWS Secrets Manager המשוכפלים לקלאסטר עם External Secrets Operator.
Direct Connect או VPN: מה לבחור?
| פרמטר | Direct Connect | Site-to-Site VPN |
|---|---|---|
| רוחב פס | עד 10 Gbps (צבירה עד 100 Gbps) | תלוי בקישור האינטרנט, בדרך כלל עד 1 Gbps |
| השהיה | יציבה, צפויה | משתנה עקב האינטרנט |
| SLA | 99.99% | 99.95% (תלוי בספק) |
| אבטחה | בידוד פיזי, IPSec אופציונלי | IPSec חובה |
| עלות | גבוהה יותר (השכרת פורט, תעבורה) | נמוכה יותר (רק עלות שער VPN) |
| זמן פריסה | 2–4 שבועות (תלוי בספק) | 1–2 ימים |
מקור: תיעוד AWS Direct Connect ו-Site-to-Site VPN
עבור עומסי עבודה בייצור עם השהיה קריטית, Direct Connect אמין עד פי 10 יותר מ-VPN. עבור dev/staging או נפחים נמוכים, VPN מספיק.
כיצד אנו בונים את הרשת ההיברידית
קישוריות רשת היא הדבר הראשון שאנו מתכננים. אנו משתמשים ב-Transit Gateway כ-hub מרכזי. כל ה-VPCs מתחברים אליו, לא דרך peering אחד עם השני. זה ניתן להרחבה: הוסיפו VPC חדש — חברו אותו ל-TGW, והנתיבים לשאר מופיעים אוטומטית.
טופולוגיית רשת לפרויקט בגודל בינוני:
On-Premise (10.10.0.0/16) │ │ Direct Connect / VPN ▼ AWS Transit Gateway ├── Production VPC (10.20.0.0/16) │ ├── Private Subnet (10.20.1.0/24) — EKS nodes │ └── Private Subnet (10.20.2.0/24) — RDS ├── Staging VPC (10.30.0.0/16) └── Shared Services VPC (10.40.0.0/16) ├── Route 53 Resolver Inbound Endpoint └── Route 53 Resolver Outbound Endpoint ניהול תצורה עם Terraform
כל תשתית הרשת היא בקוד. דוגמת Terraform עבור Route 53 Resolver:
resource "aws_route53_resolver_endpoint" "outbound" {
name = "hybrid-outbound-resolver"
direction = "OUTBOUND"
security_group_ids = [aws_security_group.resolver.id]
ip_address {
subnet_id = aws_subnet.shared_services_a.id
}
ip_address {
subnet_id = aws_subnet.shared_services_b.id
}
}
resource "aws_route53_resolver_rule" "onprem" {
domain_name = "internal.company.com"
name = "forward-to-onprem"
rule_type = "FORWARD"
resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id
target_ip {
ip = "10.10.0.53"
port = 53
}
target_ip {
ip = "10.10.0.54"
port = 53
}
}נתיבים בטבלת הנתיבים של Transit Gateway הם גם דקלרטיביים — אין לחיצות ידניות בקונסולה שאיש לא מתעד.
Kubernetes בסביבה היברידית
קלאסטר EKS עם קבוצת צמתים בתתי-רשת פרטיים אין לו גישה ישירה לאינטרנט. כדי למשוך תמונות מ-ECR, צריך VPC Endpoints עבור ECR ו-S3 (שכבות תמונה מאוחסנות ב-S3). לגישה למשאבים מקומיים, משתמשים בנתיבים דרך TGW. CoreDNS בקלאסטר מוגדר דרך ConfigMap עם Corefile:
דוגמת Corefile ל-DNS היברידי
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
forward internal.company.com 10.10.0.53 10.10.0.54
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
כך, pods ב-EKS פותרים את On-Premise (10.10.0.0/16) │ │ Direct Connect / VPN ▼ AWS Transit Gateway ├── Production VPC (10.20.0.0/16) │ ├── Private Subnet (10.20.1.0/24) — EKS nodes │ └── Private Subnet (10.20.2.0/24) — RDS ├── Staging VPC (10.30.0.0/16) └── Shared Services VPC (10.40.0.0/16) ├── Route 53 Resolver Inbound Endpoint └── Route 53 Resolver Outbound Endpoint ישירות ל-DNS המקומי, תוך עקיפת פותרי חיצוניים.
אבטחה והפרדה
Security Groups ב-AWS הם stateful. Network ACLs הם stateless. עבור היברידי, חשוב לאפשר תעבורה בשני הכיוונים ברמת ה-NACL, אחרת תעבורה חוזרת תיחסם. טעות נפוצה: פותחים כלל כניסה ב-SG עבור תת-הרשת המקומית אבל שוכחים את ה-NACL ברמת תת-הרשת, והתעבורה עדיין לא עוברת.
AWS Network Firewall או NGFW מקומי (Palo Alto, Fortinet) לבדיקת תעבורה בין אתרים — הבחירה תלויה בדרישות רגולציה. אם הנתונים הם PCI DSS או בריאותיים, בדיקה היא חובה.
ניטור היברידי
Prometheus עם remote_write ל-AWS Managed Prometheus, exporters מקומיים שולחים מדדים דרך נקודת קצה מאובטחת. Grafana מספק נקודת תצוגה אחת לשני האתרים. ניטור VPN/Direct Connect דרך מדדי CloudWatch resource "aws_route53_resolver_endpoint" "outbound" { name = "hybrid-outbound-resolver" direction = "OUTBOUND" security_group_ids = [aws_security_group.resolver.id] ip_address { subnet_id = aws_subnet.shared_services_a.id } ip_address { subnet_id = aws_subnet.shared_services_b.id } } resource "aws_route53_resolver_rule" "onprem" { domain_name = "internal.company.com" name = "forward-to-onprem" rule_type = "FORWARD" resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id target_ip { ip = "10.10.0.53" port = 53 } target_ip { ip = "10.10.0.54" port = 53 } } ו-apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } forward internal.company.com 10.10.0.53 10.10.0.54 forward . /etc/resolv.conf cache 30 loop reload loadbalance } — התראה על כשל במנהרה מגיעה ל-PagerDuty לפני שהמשתמש מתקשר.
מה העבודה שלנו כוללת (תוצרים)
- ביקורת של תשתית הרשת הנוכחית ותלותיות יישומים (מלאי CIDR, ניתוח דרישות השהיה ותפוקה).
- עיצוב טופולוגיית רשת תוך התחשבות ב-CIDR, השהיה ותפוקה.
- הקמת Direct Connect או VPN, הגדרת Transit Gateway.
- פריסת פתרון DNS (Route 53 Resolver, Conditional Forwarder).
- שילוב IAM (IRSA, Vault, או External Secrets Operator).
- הקמת ניטור והתראות (Prometheus, Grafana, CloudWatch).
- תיעוד מלא של התשתית בקוד (Terraform).
- הדרכת צוות והעברת גישה.
- תמיכה בתקופת האחריות (שבועיים לאחר ההעברה).
עלויות להקמה היברידית טיפוסית: VPN בסיסי מ-$500 לחודש, Direct Connect מ-$2000 לחודש. חיסכון מהשהיה מופחתת ואמינות מוגברת יכול להיות 20–30% בעלויות תפעול.
סיפקנו מעל 30 פרויקטים. צרו קשר לייעוץ: נבחן את הפרויקט שלכם ביומיים ונציע פתרון אופטימלי.
הערכות לוחות זמנים
| היקף | מה כלול | לוח זמנים | עלות משוערת לחודש |
|---|---|---|---|
| היברידי בסיסי | VPN + VPC אחד + העברת DNS | 2–3 שבועות | $500–$1,000 |
| בינוני | Direct Connect + TGW + EKS + Vault | 6–10 שבועות | $2,000–$5,000 |
| ארגוני | רב-אזורי + רגולציה + NGFW + IaC מלא | 3–5 חודשים | $10,000+ |
לפני התחלה, אנו מבצעים ביקורת רשת: מלאי CIDR, ניתוח תלותיות יישומים, דרישות השהיה ותפוקה. התמחור מחושב באופן אישי לאחר הביקורת.