Услуги по работе с облаком Microsoft Azure

AKS-кластер не поднимается после обновления: наш опыт с Azure

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

Почему стоит использовать 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 выросли всего на $15/месяц.

Как настроить 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% бюджета. Мы проводим сравнительный анализ и даём рекомендацию под ваш profile.

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

Cosmos DB — мультимодельная NoSQL база с гарантиями: latency <10 ms на запись и чтение в 99-м перцентиле, SLA 99.999% при multi-region write (Azure Cosmos DB documentation). 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 Too Many Requests в Cosmos DB?

Основные причины:

• Неравномерное распределение запросов из-за плохого partition key.
• Превышение выделенных RU/s при пиковой нагрузке.
• Отсутствие автоматического масштабирования (autoscale) или неправильный threshold.

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

Что входит в работу по оптимизации Azure

Опыт компании

• Более 7 лет работы с Microsoft Azure.
• Свыше 50 проектов миграции и оптимизации Azure-инфраструктуры.
• Сертификация: Azure Solutions Architect Expert, DevOps Engineer Expert.

Типичные сроки и стоимость

Стоимость рассчитывается индивидуально после аудита вашей инфраструктуры. Для точной оценки свяжитесь с нами — мы пришлём чек-лист данных для первого среза.

Закажите аудит облачных сервисов Azure

Получите консультацию инженера — разберём текущую архитектуру, найдём узкие места, предложим оптимизацию с прогнозом экономии до 30% затрат на Azure. Пишите в Telegram или форму обратной связи. Если ваш кластер уже испытывает проблемы с autoscaling или 429 ошибками, не тяните — свяжитесь сейчас.