Послуги з роботи з хмарою Microsoft Azure

AKS-кластер не піднімається після оновлення: наш досвід з Azure

Ми часто стикаємося з ситуацією: після нічного оновлення AKS-кластер у хмарних сервісах Azure перестає відповідати — FailedNodeOSUpgrade, ноди в статусі NotReady, подів evicted. Причина — автоматичний node image upgrade без урахування PodDisruptionBudgets. Ми спеціалізуємося на хмарних сервісах Azure — від міграції до оптимізації існуючих рішень. За понад 7 років роботи з Azure ми виробили перевірену схему: прив'язуємо autoUpgradeProfile.upgradeChannel та nodeOSUpgradeChannel до maintenanceConfigurationId з виділеним вікном у неробочий час. Це виключає breakage під час пікового навантаження. Один клієнт після впровадження знизив MTTR з 4 годин до 15 хвилин — тепер його інженери сплять спокійно, а витрати на простої скоротилися на $1500 щомісяця.

Чому варто використовувати Key Vault CSI замість Kubernetes Secrets?

Зберігати credentials в Kubernetes Secrets — небезпечна практика. Secret лежить в etcd в base64 (не зашифрований за замовчуванням) і доступний будь-кому, хто має get/list на Secrets в namespace. Azure Key Vault CSI Driver вирішує проблему кардинально: секрети живуть в Key Vault, монтуються в Pod як файли або env-змінні, доступ контролюється через Azure RBAC. Схема роботи:

1. AKS отримує Managed Identity або Workload Identity.
2. Identity призначається роль Key Vault Secrets User на цільовий Key Vault.
3. CSI провайдер монтує секрети при запуску пода через 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 монтує SecretProviderClass як CSI volume — файли з'являються в /mnt/secrets-store/. Додатково CSI може синхронізувати їх в Kubernetes Secret для env-змінних, але це опціонально. Azure Workload Identity (заміна Pod Identity v1) дає ще більш гранулярний контроль: різні ServiceAccount отримують різні Azure AD токени з різними правами в Key Vault — без managed identity на нодах. В одному проекті ми перевели 60 microservices з plain Secrets на Key Vault CSI за тиждень: витоки даних припинилися, а витрати на Key Vault зросли незначно — близько $50 на місяць. Розкажіть нам про ваші проблеми з безпекою — ми підберемо схему Key Vault CSI під ваш кластер.

Як налаштувати Azure DevOps Pipelines для AKS?

Azure DevOps Pipelines глибоко інтегровані з AKS, ACR, Azure App Service. YAML-пайплайн нижче — база для CI/CD з ручним підтвердженням деплою (approvals).

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)' 

environment: 'production' з approvals — деплой вимагає ручного підтвердження від approver-групи. Історія деплоїв та відкати доступні через Azure DevOps Environments UI. Якщо кластер знаходиться в private VNet, використовуємо self-hosted агенти: запускаємо їх як Pod в тому ж AKS або як VM в VNet — це дає доступ до Azure SQL без public endpoint. Такий підхід скорочує час деплою в 2 рази порівняно із зовнішніми агентами.

Azure Functions: serverless для .NET-екосистеми

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 через pre-warmed instances, але коштує фіксовану суму незалежно від навантаження. Для production HTTP API з постійним трафіком Container Apps або App Service часто вигідніші за співвідношенням ціна/продуктивність. Наприклад, один клієнт з 50 000 запитів/годину перейшов з Premium Plan на Container Apps і заощадив 35% бюджету — що склало $2000 щомісяця. Ми проводимо порівняльний аналіз і даємо рекомендацію під ваш профіль. Якщо ваш проєкт потребує serverless — отримайте консультацію інженера.

Cosmos DB: проектування Partition Key та моніторинг RU

Cosmos DB — мультимодельна NoSQL база з гарантіями: latency <10 ms на запис та читання в 99-му перцентилі, SLA 99.999% при multi-region write. API-сумісність: NoSQL (рідний), MongoDB, Cassandra, Gremlin (графи), Table Storage. Міграція з MongoDB — мінімальні зміни в коді, але модель billing та consistency гарантії відрізняються.

Partition key — найважливіше рішення при проектуванні. Поганий partition key (наприклад, country з 5 значеннями при мільйонах документів) створює «гарячі» партиції — всі запити йдуть на одну фізичну партицію, RU ліміт вичерпується швидко. Хороший partition key — userId або tenantId з високою кардинальністю, рівномірним розподілом запитів. Request Units (RU) — абстрактна одиниця. Одне читання документа 1KB — 1 RU. Запис — 5 RU. SELECT * по великій партиції — сотні RU. Моніторинг через x-ms-request-charge у відповідях API або Azure Monitor metrics. Без моніторингу RU неочікувано отримуєте 429 Too Many Requests в production.

Основні причини помилок 429 та їх усунення

Помилки 429 з'являються через нерівномірний розподіл запитів при поганому partition key, перевищення виділених RU/s або відсутність autoscale. Ми рекомендуємо autoscale з буфером 30% від середнього споживання. В одному кейсі ми збільшили пропускну здатність з 400 до 80 000 RU/s за рахунок зміни partition key з deviceType на deviceId — помилки зникли, а вартість зросла всього на 12%.

Що входить в роботу з оптимізації Azure

Досвід компанії

Маємо понад 7 років роботи з Microsoft Azure, реалізували більше 50 проектів міграції та оптимізації Azure-інфраструктури. Сертифікація: Azure Solutions Architect Expert, DevOps Engineer Expert.

Типові терміни та вартість

Вартість розраховується індивідуально після аудиту вашої інфраструктури. Для точної оцінки зв'яжіться з нами — ми надішлемо чек-лист даних для першого зрізу.

Отримайте консультацію інженера — розберемо поточну архітектуру, знайдемо вузькі місця, запропонуємо оптимізацію з прогнозом економії до 30% витрат на Azure. Пишіть у Telegram або форму зворотного зв'язку. Якщо ваш кластер вже відчуває проблеми з autoscaling або 429 помилками, не зволікайте — зв'яжіться зараз.