Ga naar inhoud

AKS-platform: deployment

Deze pagina beschrijft hoe de oplossing wordt gedeployd: de Terraform-indeling, de pipelines, de configuratiebestanden, de rollen van de pipeline identity en de volgorde van een eerste deployment. De pipelines worden gedraaid door het platformteam (XMMS in het managed model, je eigen team bij zelfbeheer, zie Beheermodellen).

Referentieontwerp, jouw deployment kan afwijken

Namen van pipelines, inputs en omgevingen zijn die van de referentierepository. Je platform kan dezelfde Terraform vanuit een andere pipeline draaien.

Terraform-indeling

terraform/
  environments/
    azure/            # root for AKS in Azure
      config/         # <environment>.tfvars and backend-<environment>.hcl
    azure-local/      # root for AKS on Azure Local, with scripts/bootstrap-aks-arc.ps1
  modules/
    azure/            # composition per layer for Azure
    azure-local/      # composition per layer for Azure Local
    network/ identity/ secrets/ cluster-baseline/ security-policy/   # building blocks
  pagerduty/          # on-call setup, separate root and state
Onderdeel Waarde
Terraform-versie 1.5 of hoger (~> 1.5 in de pipeline)
Providers azurerm 4.x, azuread 3.x (de Azure-root voegt een azurerm-provider met alias toe voor de hub subscription)
State Azure Storage, één backendbestand en state key per platform en omgeving
Werkmap terraform/environments/<platform>/
Variabelen -var-file=config/<environment>.tfvars

Handmatig draaien, vanuit de werkmap:

terraform init -backend-config=config/backend-<environment>.hcl
terraform plan -var-file=config/<environment>.tfvars -out=tfplan
terraform apply tfplan

Pipelines

Pipeline Platform Inputs
Terraform Platform Pipeline (GitHub Actions) azure en azure-local platform, environment (nonprod, prod, nonprod-integrated, prod-integrated), action, target_module, vars_ref
Terraform platform pipeline (Azure DevOps) azure en azure-local; de bronnen beschrijven hem als gebruikt voor Azure Local platform, environment (nonprod, prod), action, target_module
Terraform PagerDuty pipeline (GitHub Actions) On-call-inrichting environment, action
AKS non-production start en stop (GitHub Actions) Kostenbesparing action (gepland en handmatig)
Load test (GitHub Actions) Non-productie Snelheden, duur, failure trigger (Load testing)

Acties

Actie Effect
plan Alleen een Terraform plan
apply Plan, daarna apply
destroy-plan, destroy De vernietiging plannen, of vernietigen
bootstrap Alleen Azure Local: het cluster en MetalLB aanmaken
bootstrap-and-apply Alleen Azure Local: bootstrap, daarna plan en apply
bootstrap-and-plan Alleen Azure Local, Azure DevOps-pipeline: bootstrap, daarna plan

Doellayers

target_module is all voor normaal gebruik. Een enkele layer (networking, identity, security-policy, cluster-baseline, secrets) gebruikt Terraform -target en is alleen bedoeld voor de bootstrap of gecontroleerd herstel. De pipeline waarschuwt als je het gebruikt. De GitHub-pipeline voegt cicd-aks-rbac toe, die alleen de role assignments van de pipeline op het cluster target.

Wat een run doet

  1. Bepaalt de GitHub Environment uit platform en omgeving. De -integrated-omgevingen hergebruiken de GitHub Environments van de standalone clusters; er worden geen nieuwe environments aangemaakt.
  2. Leest de authenticatiewaarden (auth.conf) en, voor Azure Local, de bootstrapwaarden (bootstrap.conf) van die omgeving uit een aparte private variabelenrepository, met een GitHub App-token.
  3. Meldt zich aan bij Azure met GitHub OIDC (geen client secret) en zet de Terraform-variabelen ARM_*.
  4. Draait terraform fmt -check, init, validate, en daarna plan of apply voor de gekozen layer.
  5. Draait op Azure Local eerst de bootstrap als de actie daarom vraagt, en geeft cluster_id en oidc_issuer_url aan Terraform door via een gegenereerde config/ci.auto.tfvars.

Per platform en omgeving draait er één run tegelijk (een concurrency group). Goedkeuringen voor productie worden afgedwongen met de beschermingsregels van de GitHub Environment, of met approval gates op de Azure DevOps-environment.

Het storage account voor de Terraform-state van de hub-integrated omgeving staat in de subscription van de standalone clusters, terwijl de resources in de spoke subscription worden aangemaakt. Het backendbestand pint daarom de state-subscription.

Rollen van de pipeline identity

De identity van de Azure-pipeline heeft, om het volledige platform te deployen, het volgende nodig:

Rol Scope Doel
Contributor Subscription De resources aanmaken en beheren
Resource Policy Contributor Subscription Azure Policy assignments aanmaken
Role Based Access Control Administrator Subscription, met een voorwaarde Role assignments voor de managed identities aanmaken
Storage Blob Data Contributor Storage account van de state De state lezen en schrijven
Graph-permissie Group.ReadWrite.All (admin consent) of de Entra-rol Groups Administrator Tenant Entra ID-groepen aanmaken en beheren

Beperk de rol Role Based Access Control Administrator met de voorwaarde "allow user to only assign selected roles to selected principals", en sta alleen toe: Managed Identity Operator (cluster identity naar kubelet identity), Network Contributor (cluster identity op het VNet en de subnets), Private DNS Zone Contributor (cluster identity op DNS-zones), AcrPull (kubelet identity op de registry).

Meer rollen in de code

De code wijst ook Key Vault Secrets User toe aan workload identities en Azure Kubernetes Service RBAC Admin aan pipeline identities. Voeg deze rollen toe aan de voorwaarde als de pipeline identity die assignments aanmaakt. In de hub-integrated modus heeft de identity ook toegang nodig in de spoke subscription (Netwerk).

Eerste deployment van een omgeving

  1. Maak het configuratiebestand en het backendbestand voor de omgeving klaar, en de vereisten (Vereisten).
  2. Draai plan met target_module = all en review het.
  3. Draai apply. De layers worden in volgorde van afhankelijkheid toegepast: eerst networking en identity, daarna security policy, cluster baseline en secrets.
  4. Lees de URL van de OIDC issuer van het cluster, zet oidc_issuer_url in de configuratie en pas opnieuw toe. Pas dan worden de workload identities en hun federated credentials aangemaakt.
  5. Stel de Entra ID-groepslidmaatschappen in, en laat GitOps daarna namespaces, RBAC, policies en platformservices toepassen.

Draai voor Azure Local eerst de bootstrap (AKS op Azure Local).

Bekend probleem: Graph API

Een probleem met de Microsoft Graph API laat terraform apply met target all mislukken als role assignments op het cluster wijzigen (een probleem in de provider azuread dat op een fix wachtte). De workaround is de role assignments van de pipeline te wijzigen via het target cicd-aks-rbac. De role assignments voor de pipeline staan daarom buiten de identitymodule.

On-call-inrichting (PagerDuty)

Een aparte Terraform-root terraform/pagerduty heeft een eigen state en pipeline. Per omgeving maakt die aan:

Resource Instelling
Team en lidmaatschappen Gebruikers uit de configuratie, met een rol
Schedule Wekelijkse rotatie in de tijdzone Amsterdam, beperkt tot kantoordagen en -uren
Escalation policy Eén schedule, escalatievertraging 30 minuten, twee keer herhaald
Service Maakt alerts en incidenten aan, auto-resolve na 4 uur, acknowledgement-timeout 30 minuten, urgentie naar severity binnen de supporturen en laag erbuiten
Alert grouping Intelligent grouping
Service dependency De service ondersteunt een business service van de provider
Integratie Events API v2-integratie voor Prometheus Alertmanager

De uren, escalatiestappen en wie on call is, worden afgesproken in je contract of je interne on-call-proces. De waarden in de code zijn de standaardwaarden.