שירותי Microsoft Azure Cloud

אשכול AKS לא מתחיל לאחר שדרוג: הניסיון שלנו עם Azure

לעתים קרובות אנו נתקלים במצב: לאחר שדרוג אשכול AKS לילי בשירותי הענן של Azure, האשכול מפסיק להגיב — FailedNodeOSUpgrade, צמתים במצב NotReady, ו-pods מפונים. הסיבה היא שדרוג תמונת צומת אוטומטי ללא התחשבות ב-PodDisruptionBudgets. במשך למעלה מ-7 שנות עבודה עם Azure, פיתחנו תוכנית מוכחת: קישור autoUpgradeProfile.upgradeChannel ו-nodeOSUpgradeChannel ל-maintenanceConfigurationId עם חלון ייעודי בשעות לא פעילות. זה מבטל תקלות בעומס שיא. לקוח אחד לאחר היישום הפחית את ה-MTTR מ-4 שעות ל-15 דקות — כעת המהנדסים שלהם ישנים בשקט.

למה להשתמש ב-Key Vault CSI במקום Kubernetes Secrets?

אחסון אישורים ב-Kubernetes Secrets הוא נוהג מסוכן. ה-Secret נמצא ב-etcd ב-base64 (לא מוצפן כברירת מחדל) ונגיש לכל מי שיש לו get/list על Secrets ב-namespace. Azure Key Vault CSI Driver פותר זאת מהיסוד: סודות חיים ב-Key Vault, מורכבים לתוך Pods כקבצים או משתני סביבה, והגישה נשלטת דרך Azure RBAC. זרימת העבודה:

1. AKS מקבל Managed Identity או Workload Identity.
2. ל-Identity מוקצה תפקיד Key Vault Secrets User על Key Vault היעד.
3. ספק ה-CSI מרכיב סודות בעת הפעלת ה-pod דרך SecretProviderClass.

apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: azure-kvname spec: provider: azure parameters: usePodIdentity: "false" useVMManagedIdentity: "true" userAssignedIdentityID: "" keyvaultName: "company-prod-kv" objects: | array: - | objectName: db-connection-string objectType: secret objectVersion: "" tenantId: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 

ה-Pod מרכיב את apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: azure-kvname spec: provider: azure parameters: usePodIdentity: "false" useVMManagedIdentity: "true" userAssignedIdentityID: "" keyvaultName: "company-prod-kv" objects: | array: - | objectName: db-connection-string objectType: secret objectVersion: "" tenantId: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" כ-volume מסוג CSI — קבצים מופיעים ב-SecretProviderClass. בנוסף, ה-CSI יכול לסנכרן אותם לתוך Kubernetes Secret עבור משתני סביבה, אך זה אופציונלי. Azure Workload Identity (תחליף ל-Pod Identity v1) מספק שליטה גרעינית עוד יותר: ServiceAccounts שונים מקבלים אסימוני Azure AD שונים עם הרשאות שונות ב-Key Vault — ללא managed identity על צמתים. בפרויקט אחד, העברנו 60 מיקרוסרביסים מ-Secrets רגילים ל-Key Vault CSI בשבוע: דליפות נתונים נפסקו, ועלות Key Vault עלתה רק בסכום מזערי.

איך להגדיר Azure DevOps Pipelines עבור AKS?

Azure DevOps Pipelines משולבות עמוק עם AKS, ACR ו-Azure App Service. ה-YAML pipeline שלהלן הוא בסיס ל-CI/CD עם אישור פריסה ידני.

trigger: branches: include: - main pool: vmImage: 'ubuntu-latest' stages: - stage: Build jobs: - job: BuildAndPush steps: - task: Docker@2 inputs: containerRegistry: 'acr-service-connection' repository: 'company/api' command: 'buildAndPush' tags: | $(Build.BuildId) latest - stage: Deploy dependsOn: Build environment: 'production' jobs: - deployment: DeployToAKS strategy: runOnce: deploy: steps: - task: KubernetesManifest@1 inputs: action: 'deploy' kubernetesServiceConnection: 'aks-prod-connection' manifests: 'k8s/production/*.yaml' containers: 'company.azurecr.io/company/api:$(Build.BuildId)' 

/mnt/secrets-store/ עם אישורים — פריסה דורשת אישור ידני מקבוצת מאשרים. היסטוריית פריסות וגלגולים לאחור זמינים דרך ממשק Azure DevOps Environments. אם האשכול נמצא ב-VNet פרטי, השתמשו בסוכנים עצמיים (self-hosted agents): הריצו אותם כ-Pod באותו AKS או כ-VM ב-VNet — זה נותן גישה ל-Azure SQL ללא נקודת קצה ציבורית. גישה זו מפחיתה את זמן הפריסה פי 2 בהשוואה לסוכנים חיצוניים.

איך לנצל את Azure Functions עבור .NET Serverless?

Azure Functions הוא מחשוב serverless עם אינטגרציה עמוקה לשירותי Azure. טריגרים: HTTP, Service Bus, Event Hub, Blob Storage, Timer (cron), Cosmos DB change feed. Durable Functions מרחיבות את היכולות לאורכסטרציות עם מצב (stateful). תבנית Fan-out/Fan-in: האורכסטרטור מפעיל N משימות מקבילות ואוסף תוצאות.

[FunctionName("Orchestrator")] public static async Task<List<string>> RunOrchestrator( [OrchestrationTrigger] IDurableOrchestrationContext context) { var tasks = new List<Task<string>>(); foreach (var item in items) tasks.Add(context.CallActivityAsync<string>("ProcessItem", item)); return new List<string>(await Task.WhenAll(tasks)); } 

Cold start ב-.NET הוא בעיה עבור טריגרי HTTP עם SLA. Premium Plan מבטל cold start דרך מופעים מחוממים מראש, אך עולה סכום קבוע ללא קשר לעומס. עבור API ייצוריים עם תעבורה קבועה, Container Apps או App Service לרוב חסכוניים יותר. לדוגמה, לקוח אחד עם 50,000 בקשות/שעה עבר מ-Premium Plan ל-Container Apps וחסך 35% מהתקציב. אנו מבצעים ניתוח השוואתי ומספקים המלצות מותאמות לפרופיל שלכם.

איך לתכנן Partition Key ולנטר RU ב-Cosmos DB?

Cosmos DB הוא מסד נתונים NoSQL רב-מודלי עם הבטחות: זמן אחזור <10 ms לכתיבה וקריאה באחוזון ה-99, SLA של 99.999% לכתיבה רב-אזורית (תיעוד Azure Cosmos DB). תאימות API: NoSQL (ילידי), MongoDB, Cassandra, Gremlin (גרפים), Table Storage. הגירה מ-MongoDB דורשת שינויי קוד מינימליים, אך מודל החיוב והבטחות העקביות שונים.

Partition key הוא החלטת התכנון החשובה ביותר. Partition key גרוע (למשל, trigger: branches: include: - main pool: vmImage: 'ubuntu-latest' stages: - stage: Build jobs: - job: BuildAndPush steps: - task: Docker@2 inputs: containerRegistry: 'acr-service-connection' repository: 'company/api' command: 'buildAndPush' tags: | $(Build.BuildId) latest - stage: Deploy dependsOn: Build environment: 'production' jobs: - deployment: DeployToAKS strategy: runOnce: deploy: steps: - task: KubernetesManifest@1 inputs: action: 'deploy' kubernetesServiceConnection: 'aks-prod-connection' manifests: 'k8s/production/*.yaml' containers: 'company.azurecr.io/company/api:$(Build.BuildId)' עם 5 ערכים עבור מיליוני מסמכים) יוצר מחיצות 'חמות' — כל הבקשות פוגעות במחיצה פיזית אחת, ומגבלת ה-RU נגמרת במהירות. Partition key טוב הוא environment: 'production' או [FunctionName("Orchestrator")] public static async Task<List<string>> RunOrchestrator( [OrchestrationTrigger] IDurableOrchestrationContext context) { var tasks = new List<Task<string>>(); foreach (var item in items) tasks.Add(context.CallActivityAsync<string>("ProcessItem", item)); return new List<string>(await Task.WhenAll(tasks)); } עם קרדינליות גבוהה וחלוקת בקשות אחידה. Request Units (RU) היא יחידה מופשטת. קריאה אחת של מסמך 1KB = 1 RU. כתיבה אחת = 5 RU. country על פני מחיצה גדולה = מאות RU. נטר באמצעות userId בתגובות API או מדדי Azure Monitor. ללא ניטור RU, תקבלו במפתיע tenantId בייצור.

למה מתרחשים 429 Too Many Requests ב-Cosmos DB?

סיבות עיקריות: חלוקת בקשות לא אחידה עקב partition key גרוע. חריגה מ-RU/s שהוקצו בזמן עומס שיא. חוסר autoscaling או סף שגוי.

אנו ממליצים להשתמש ב-autoscale עם חיץ של 30% מעל הצריכה הממוצעת. במקרה אחד, הגדלנו throughput מ-400 ל-80,000 RU/s על ידי שינוי partition key מ-SELECT * ל-x-ms-request-charge — שגיאות 429 נעלמו, והעלות עלתה רק ב-12% עקב עומס אחיד.

מה כלול בעבודת אופטימיזציית Azure?

ניסיון החברה

• מעל 7 שנות עבודה עם Microsoft Azure.
• יותר מ-50 פרויקטי הגירה ואופטימיזציה לתשתית Azure.
• הסמכות: Azure Solutions Architect Expert, DevOps Engineer Expert.

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

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

הזמינו ביקורת שירותי ענן Azure

קבלו ייעוץ ממהנדס — נסקור את הארכיטקטורה הנוכחית שלכם, נמצא צווארי בקבוק, ונציע אופטימיזציה עם תחזית חיסכון של עד 30% בעלויות על Azure. צרו קשר דרך Telegram או טופס המשוב. אם האשכול שלכם כבר חווה בעיות autoscaling או שגיאות 429, אל תדחו — פנו עכשיו.