El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Container Apps va resoldre el motor de disponibilitat amb molt poc esforç, i aquesta és la millor notícia de la lliçó anterior. Però a Contoso Airlines hi ha un front diferent: la plataforma d'operacions de vol, dotze microserveis que coordinen assignació de portes, rotació de tripulacions, càrrega de combustible i retards, escrits per tres equips, amb un component que exigeix nodes amb molta memòria i un altre que necessita afinitat entre pods. Aquest sistema demana control fi de la programació, polítiques de xarxa entre serveis i operadors de tercers. Aquí sí, Kubernetes.

Aquesta lliçó ensenya Azure Kubernetes Service amb honestedat: què et dona, què continua sent feina teva, quant costa de debò i en quins casos adoptar-lo és sobreenginyeria. Contoso l'adopta per a operacions de vol, no per a tota la plataforma, i aquesta decisió és la primera lliçó.

Contingut

Quan Kubernetes està justificat i quan no
Conceptes de Kubernetes, l'imprescindible
Què gestiona AKS i què continua sent teu
Crear aks-contoso-operaciones i triar el model de xarxa
Identitat: Entra ID, RBAC i identitat de càrrega de treball
Desplegar l'aplicació amb manifestos i kubectl
Entrada gestionada i certificats
Escalat, sol·licituds i límits
Actualitzacions, interrupcions i manteniment
Emmagatzematge persistent, observabilitat, Helm i cost realista
Errors Comuns i Consells
Exercicis
Conclusió

Quan Kubernetes està justificat i quan no

Senyal	Kubernetes?
Un grapat d'APIs sense estat amb càrrega irregular	No: Container Apps, més barat
Dotze o més serveis amb dependències entre ells	Sí
Necessites operadors, malles de servei o CRD, o maquinari per càrrega (GPU)	Sí
Portabilitat real entre núvols o centre de dades propi	Sí
«És el que es fa servir ara», o ningú no sap operar un clúster	No, i són les dues raons més freqüents

El cost ocult de Kubernetes no és la factura dels nodes, és el temps de l'equip: actualitzacions trimestrals, versions d'API que es retiren, depuració de la xarxa, gestió de certificats. Si ningú no hi dedicarà temps, un clúster envelleix fins a convertir-se en un risc. Contoso l'assumeix només on el retorn ho compensa.

Conceptes de Kubernetes, l'imprescindible

graph TD
  subgraph PC["Pla de control (gestionat per AKS, gratuit)"]
    API[Servidor d API] --- ETCD[(etcd)]
    API --- PROG[Programador] --- CTRL[Controladors]
  end
  subgraph NODOS["Grups de nodes (les teves maquines virtuals, es paguen)"]
    N1["Node 1: pod portes + pod tripulacions"]
    N2["Node 2: pod portes + pod combustible"]
  end
  API --> N1
  API --> N2
  ING[Ingres: operaciones.contosoairlines.example] --> SVC[Servei: portes]
  SVC --> N1
  SVC --> N2

Pla de control: el cervell. El servidor d'API rep totes les ordres, etcd desa l'estat desitjat, el programador decideix a quin node cap cada pod i els controladors corregeixen sense parar la diferència entre el que hi ha i el que hi hauria d'haver. Aquest bucle de reconciliació és la idea central de Kubernetes: tu declares la destinació, el sistema s'encarrega del camí.
Node: una màquina virtual que executa pods, agrupada amb altres en grups de nodes. I pod: la unitat mínima programable, un o més contenidors que comparteixen xarxa i emmagatzematge. És efímer: si mor, no reviu; en neix un altre amb una altra adreça IP.
Desplegament i conjunt de rèpliques: el desplegament declara «vull N rèpliques d'aquest pod amb aquesta imatge»; el conjunt de rèpliques manté el compte i orquestra les actualitzacions progressives.
Servei i ingrés: el servei dona IP i nom DNS estables per davant d'un conjunt canviant de pods —resol que els pods no tinguin adreça fixa—; l'ingrés encamina el trànsit HTTP d'entrada per nom d'amfitrió i ruta, amb TLS, en un sol punt d'entrada per a molts serveis.
Espai de noms: partició lògica del clúster amb quotes i permisos propis; Contoso fa servir operaciones-vuelo, integracion i monitorizacion. I mapa de configuració i secret: configuració i dades sensibles injectades com a variables d'entorn o fitxers. Compte: un secret de Kubernetes només va codificat en base64, no xifrat, i per això Contoso els treu de kv-contoso-pro.

Què gestiona AKS i què continua sent teu

Responsabilitat	AKS	Tu
Pla de control (API, etcd, programador)	Sí, i és gratuït	—
Còpies de seguretat d'etcd	Sí	—
Nodes: màquines virtuals i discos	Aprovisiona	Els pagues
Pedaçat del SO i versió de Kubernetes	Publica imatges i versions	Decidir i llançar l'actualització
Manifestos, límits, polítiques de xarxa, alertes	Integracions	Teu

Digues-ho clar, perquè genera moltes factures sorpresa: el pla de control d'AKS és gratuït al nivell Free; el que es paga són els nodes, que són màquines virtuals normals amb el seu preu de còmput i els seus discos. Un clúster «buit» amb tres nodes costa el mateix que tres màquines virtuals enceses. El nivell Standard hi afegeix un SLA amb cost per hora de clúster, i és el que correspon en producció.

Crear `aks-contoso-operaciones` i triar el model de xarxa

az aks create \
  --resource-group rg-contoso-reservas-pro --name aks-contoso-operaciones \
  --location westeurope --tier standard --kubernetes-version 1.30.4 \
  --nodepool-name sistema --node-count 3 --node-vm-size Standard_D4s_v5 --zones 1 2 3 \
  --enable-cluster-autoscaler --min-count 3 --max-count 6 \
  --network-plugin azure --network-plugin-mode overlay --network-policy cilium \
  --vnet-subnet-id $(az network vnet subnet show -g rg-contoso-red-pro \
      --vnet-name vnet-contoso-pro -n snet-app --query id -o tsv) \
  --enable-aad --enable-azure-rbac --enable-managed-identity \
  --enable-oidc-issuer --enable-workload-identity \
  --attach-acr acrcontosopro --enable-addons monitoring \
  --workspace-resource-id $(az monitor log-analytics workspace show \
      -g rg-contoso-seguridad-pro -n log-contoso-pro --query id -o tsv) \
  --tags entorno=produccion proyecto=contoso-reservas \
         centro-coste=CC-1042 [email protected]

I tot seguit el grup de nodes d'usuari, perquè barrejar càrregues de sistema i d'aplicació al mateix grup és un error clàssic:

az aks nodepool add \
  --resource-group rg-contoso-reservas-pro --cluster-name aks-contoso-operaciones \
  --name aplicaciones --mode User \
  --node-vm-size Standard_D8s_v5 --node-count 2 --zones 1 2 3 \
  --enable-cluster-autoscaler --min-count 2 --max-count 12

Les decisions que hi ha al darrere:

--nodepool-name sistema amb --mode System (implícit a create): allotja CoreDNS, metrics-server i els complements. Si una càrrega d'aplicació desbocada en consumeix la memòria, cau el DNS del clúster sencer. Separa'ls.
--zones 1 2 3 reparteix els nodes entre zones de disponibilitat —sense això, un incident de zona s'emporta el clúster— i --enable-cluster-autoscaler afegeix i treu nodes segons els pods que no hi caben, cosa diferent de l'escalat de pods (apartat 8).
--attach-acr acrcontosopro assigna per tu el rol AcrPull a la identitat de tipus kubelet del clúster; sense ella, els pods fallen amb ImagePullBackOff i l'error és opac. I --enable-workload-identity més --enable-oidc-issuer és la base de l'apartat 5.

Xarxes: kubenet, Azure CNI i CNI Overlay

	kubenet	Azure CNI	Azure CNI Overlay
IP del pod	Xarxa superposada interna	De la subxarxa de la xarxa virtual	Xarxa superposada gestionada
Consum d'IP de la subxarxa	Molt baix	Molt alt	Molt baix
Connectivitat directa al pod	No, amb salts	Sí	No directa
Rendiment i estat	Menor; en retirada	Màxim; vigent	Gairebé com CNI; recomanat

La fallada de disseny més cara a AKS és triar Azure CNI sense fer números: cada node reserva per endavant tantes IP com pods màxims admeti (30 per defecte), així que 20 nodes consumeixen 600 adreces i una /24 s'esgota abans de començar. Contoso fa servir CNI Overlay sobre snet-app (10.20.2.0/24): els nodes prenen IP de la subxarxa, els pods d'un espai superposat, i la subxarxa aguanta el creixement. S'hi afegeix política de xarxa (Cilium) per poder prohibir explícitament que un pod parli amb un altre; sense ella, dins del clúster tot parla amb tot.

Identitat: Entra ID, RBAC i identitat de càrrega de treball

Amb --enable-aad --enable-azure-rbac, qui entra al clúster ho decideix Microsoft Entra ID i què hi pot fer ho decideix RBAC d'Azure, amb els mateixos grups del mòdul 4:

idClus=$(az aks show -g rg-contoso-reservas-pro -n aks-contoso-operaciones --query id -o tsv)

# Infraestructura: administracio completa del cluster
az role assignment create --role "Azure Kubernetes Service RBAC Cluster Admin" \
  --assignee-object-id $(az ad group show -g Contoso-Infraestructura --query id -o tsv) \
  --assignee-principal-type Group --scope $idClus

# Desenvolupament: nomes escriptura dins del SEU espai de noms
az role assignment create --role "Azure Kubernetes Service RBAC Writer" \
  --assignee-object-id $(az ad group show -g Contoso-Desarrollo --query id -o tsv) \
  --assignee-principal-type Group --scope "$idClus/namespaces/operaciones-vuelo"

La identitat de càrrega de treball és la peça que elimina els secrets dins del clúster. Un compte de servei de Kubernetes es federa amb id-contoso-api-pro: el pod rep un testimoni signat per l'emissor OIDC del clúster, el canvia per un testimoni d'Entra ID i accedeix a kv-contoso-pro i a db-reservas amb DefaultAzureCredential, el mateix codi de 04-02, sense cap clau.

# Federar el compte de servei de l espai de noms amb la identitat administrada
az identity federated-credential create \
  --name fed-operaciones --identity-name id-contoso-api-pro \
  --resource-group rg-contoso-seguridad-pro \
  --issuer $(az aks show -g rg-contoso-reservas-pro -n aks-contoso-operaciones \
      --query oidcIssuerProfile.issuerUrl -o tsv) \
  --subject system:serviceaccount:operaciones-vuelo:sa-operaciones \
  --audience api://AzureADTokenExchange

Desplegar l'aplicació amb manifestos i `kubectl`

Abans del desplegament cal el compte de servei sa-operaciones a l'espai de noms operaciones-vuelo, anotat amb azure.workload.identity/client-id apuntant a l'identificador de client d'id-contoso-api-pro. És la contrapart al clúster de la credencial federada anterior.

apiVersion: apps/v1
kind: Deployment
metadata: { name: panel-operaciones, namespace: operaciones-vuelo }
spec:
  replicas: 3
  selector: { matchLabels: { app: panel-operaciones } }
  template:
    metadata:
      labels:
        app: panel-operaciones
        azure.workload.identity/use: "true"   # injecta el testimoni federat
    spec:
      serviceAccountName: sa-operaciones
      containers:
        - name: panel
          image: acrcontosopro.azurecr.io/panel-operaciones:4821
          ports: [ { containerPort: 8080 } ]
          resources:                          # l apartat 8 explica per que
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { cpu: "1000m", memory: "512Mi" }
          readinessProbe: { httpGet: { path: /salud, port: 8080 } }  # llest per a transit
          livenessProbe:  { httpGet: { path: /salud, port: 8080 } }  # viu; si no, reinici
      topologySpreadConstraints:              # reparteix les 3 repliques entre les 3 zones
        - { maxSkew: 1, topologyKey: topology.kubernetes.io/zone,
            whenUnsatisfiable: DoNotSchedule,
            labelSelector: { matchLabels: { app: panel-operaciones } } }
---
apiVersion: v1
kind: Service
metadata: { name: svc-panel-operaciones, namespace: operaciones-vuelo }
spec:
  type: ClusterIP          # intern; l ingres es qui publica
  selector: { app: panel-operaciones }
  ports: [ { port: 80, targetPort: 8080 } ]
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: ing-operaciones, namespace: operaciones-vuelo }
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  rules:
    - host: operaciones.contosoairlines.example
      http:
        paths:
          - { path: /, pathType: Prefix,
              backend: { service: { name: svc-panel-operaciones, port: { number: 80 } } } }
  tls:
    - hosts: [ operaciones.contosoairlines.example ]
      secretName: tls-operaciones      # certificat sincronitzat des de Key Vault

Camp a camp, el que no és evident:

selector.matchLabels del desplegament i labels de la plantilla han de coincidir: és la unió entre el desplegament i els seus pods, i desalinear-los deixa el desplegament sense rèpliques. serviceAccountName més l'etiqueta azure.workload.identity/use són el que activa la federació de l'apartat 5.
La imatge porta l'etiqueta 4821, l'identificador de compilació de la canalització (05-03), mai latest.
readinessProbe davant de livenessProbe: la primera controla si el pod entra al balanceig; la segona si es reinicia. Confondre-les produeix reinicis en cascada sota càrrega. I topologySpreadConstraints obliga a repartir les tres rèpliques entre les tres zones: sense això, el programador les pot col·locar totes tres al mateix node.
type: ClusterIP: el servei no es publica sol. Fer servir LoadBalancer per servei crea una IP pública per cadascun i multiplica cost i superfície exposada.

kubectl essencial: kubectl apply -f manifiestos/ aplica; kubectl get pods -n operaciones-vuelo -o wide llista amb node i IP; kubectl describe pod <nom> dona els esdeveniments, que és on hi ha sempre la causa de la fallada; kubectl logs -f <pod> segueix els registres; kubectl rollout status deploy/panel-operaciones espera el desplegament i kubectl rollout undo el reverteix; kubectl top pods mostra el consum real, imprescindible per ajustar l'apartat 8.

Entrada gestionada i certificats

Instal·lar i mantenir a mà un controlador d'entrada és feina recurrent. El complement d'encaminament d'aplicacions desplega un NGINX gestionat i l'integra amb DNS i Key Vault:

az aks approuting enable -g rg-contoso-reservas-pro -n aks-contoso-operaciones \
  --enable-kv --attach-kv $(az keyvault show -n kv-contoso-pro --query id -o tsv)

Amb això, el certificat d'operaciones.contosoairlines.example viu a kv-contoso-pro, se sincronitza com a secret de Kubernetes i es renova sense intervenció. El certificat no es copia mai a un repositori ni a un manifest.

Escalat, sol·licituds i límits

Tres escaladors que es confonen constantment:

Escalador	Què fa	Senyal
Horitzontal de pods (HPA)	Afegeix o treu rèpliques	CPU, memòria o mètrica personalitzada
Automàtic de clúster	Afegeix o treu nodes	Pods pendents que no hi caben
Nodes virtuals	Programa pods a ACI, sense node	Ràfegues immediates, sense arrencar màquines

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: hpa-panel, namespace: operaciones-vuelo }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: panel-operaciones }
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - { type: Resource,
        resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } } }

Els dos primers escaladors treballen en cadena: l'HPA demana més rèpliques, no hi caben, queden pendents i l'escalador de clúster arrenca nodes. I aquí hi ha el punt clau de tota la lliçó: l'HPA calcula el percentatge d'ús sobre la sol·licitud (requests), i el programador decideix on cap un pod mirant-ne la sol·licitud. Sense requests no hi ha percentatge a calcular ni informació per programar.

Les sol·licituds i els límits són la causa número u de clústers inestables. Sense requests, el programador es pensa que el pod no consumeix res i amuntega pods en un node fins a esgotar-lo. Sense limits de memòria, una fuita en un pod consumeix la memòria del node i el nucli comença a matar processos: cauen pods sans aliens al problema. Amb limits de CPU massa baixos, el pod pateix limitació i la latència es dispara sense que la CPU sembli alta.

La regla pràctica: fixa requests al consum del percentil 50 mesurat amb kubectl top, i limits al voltant del doble. Reforça-ho amb ResourceQuota i LimitRange a l'espai de noms perquè cap manifest sense límits no arribi a aplicar-se.

Actualitzacions, interrupcions i manteniment

Kubernetes publica versions a bon ritme i AKS només en dona suport a unes poques. Actualitzar no és opcional; és una tasca de calendari.

az aks get-upgrades -g rg-contoso-reservas-pro -n aks-contoso-operaciones -o table
az aks upgrade -g rg-contoso-reservas-pro -n aks-contoso-operaciones \
  --kubernetes-version 1.31.1 --control-plane-only          # primer el pla
az aks nodepool upgrade -g rg-contoso-reservas-pro --cluster-name aks-contoso-operaciones \
  -n aplicaciones --kubernetes-version 1.31.1               # despres cada grup

Actualitza sempre el pla de control primer i els grups de nodes després, un a un, i d'una versió menor a la següent, sense salts. Els nodes se substitueixen mitjançant acordonament i buidatge, i aquí entra el pressupost d'interrupció de pods, que impedeix que el buidatge deixi un servei per sota d'un mínim:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: pdb-panel, namespace: operaciones-vuelo }
spec:
  minAvailable: 2                       # el buidatge no deixa mai menys de 2 repliques
  selector: { matchLabels: { app: panel-operaciones } }

Sense ell, un buidatge es pot emportar les tres rèpliques alhora i el tauler d'operacions desapareix durant l'actualització. Completa-ho amb una finestra de manteniment planificat (az aks maintenanceconfiguration add) perquè les actualitzacions automàtiques del sistema operatiu del node no caiguin en hora punta de facturació.

Emmagatzematge, observabilitat, Helm i cost

El disc d'un pod és efímer. Per persistir, es declara una reclamació de volum persistent contra una classe d'emmagatzematge:

Classe	Suport	Accés	Ús a Contoso
`managed-csi` (i `-premium`)	Disc d'Azure	Un sol node	Dades d'un pod únic; la variant Premium per a E/S exigent
`azurefile-csi`	Azure Files (SMB/NFS)	Diversos nodes alhora	Fitxers compartits entre rèpliques

La distinció decisiva és el mode d'accés: un disc d'Azure el munta un sol node, així que no serveix per a tres rèpliques repartides per zones; per a això cal Azure Files. I per defecte la política de reclamació és Delete: en esborrar la reclamació desapareix el disc i les dades. En producció, Retain.

L'observabilitat es resol amb Container Insights, ja habilitat a l'az aks create contra log-contoso-pro: mètriques de nodes i pods, registres de contenidor i del pla de control consultables amb KQL. Com explotar-los és el mòdul 7 (07-01 i 07-02); aquí n'hi ha prou amb deixar-ho activat des del principi, perquè ningú no ho activa a temps quan el clúster ja falla.

Helm, GitOps i cost realista

Helm és el gestor de paquets de Kubernetes: empaqueta un conjunt de manifestos en un chart amb valors parametritzats, de manera que desplegar a desarrollo i a produccion sigui el mateix chart amb un altre fitxer de valors; és als manifestos el que els mòduls de Bicep a les plantilles (05-06). GitOps amb Flux és l'evolució natural: en lloc que la canalització empenyi amb kubectl apply, un agent dins del clúster vigila el repositori contoso-infra i reconcilia el clúster cap al que diu Git; el repositori passa a ser l'única font de veritat i la desviació de configuració es corregeix sola. AKS ho ofereix com a extensió gestionada.

Cost realista. Un clúster de producció com el de Contoso, amb 3 nodes Standard_D4s_v5 de sistema i de 2 a 12 nodes Standard_D8s_v5 d'aplicació, més el nivell Standard, discos, balancejador i ingesta de registres, se situa en l'ordre de diversos milers d'euros al mes, i la ingesta de Log Analytics sorprèn més del que ningú no espera. Com reduir-ho:

Instàncies d'accés puntual (az aks nodepool add --priority Spot --eviction-policy Delete --spot-max-price -1) en un grup dedicat per a càrregues tolerants a interrupcions —lots, proves—: fins a un 80-90 % menys, a canvi d'un desallotjament amb dos minuts d'avís.
Escalar a zero els grups d'usuari amb --min-count 0, i aturar el clúster de desenvolupament amb az aks stop / az aks start: un clúster aturat no factura nodes. Automatitza-ho a la nit i el cap de setmana amb Azure Automation (07-04).
Ajustar les requests al que es consumeix de debò: les sol·licituds inflades obliguen l'escalador a arrencar nodes mig buits. És l'estalvi menys visible i sovint el més gran.

Errors Comuns i Consells

Adoptar AKS sense necessitat: si el cas el cobreix Container Apps, AKS només hi afegeix factura i feina. I desplegar sense requests ni limits, causa número u de clústers inestables; imposa-ho amb LimitRange.
Triar Azure CNI sense calcular les IP. La subxarxa s'esgota i ampliar-la obliga a refer el clúster. Fes servir CNI Overlay.
Barrejar càrregues d'aplicació amb el grup de sistema. Un pod desbocat tomba CoreDNS i amb ell el clúster.
Desar secrets com a Secret de Kubernetes (només base64) o posar un Service de tipus LoadBalancer per microservei (dotze IP públiques). Identitat de càrrega de treball contra kv-contoso-pro, i un sol ingrés amb encaminament per amfitrió.
Deixar el clúster sense actualitzar: les versions surten de suport i l'actualització acumulada esdevé arriscada. Calendari trimestral.
Consell: kubectl describe pod abans que qualsevol altra cosa. El 90 % de les fallades (ImagePullBackOff, CrashLoopBackOff, Pending per manca de recursos) s'expliquen a la seva secció d'esdeveniments. I aplica polítiques de xarxa des del principi: incorporar-les a posteriori en un clúster en producció és dolorós.

Exercicis

Exercici 1. Un microservei d'operacions es queda en estat Pending i l'escalador de clúster no arrenca nodes. El seu manifest demana requests: { cpu: "8000m", memory: "32Gi" } i el grup aplicaciones fa servir Standard_D8s_v5 (8 vCPU, 32 GiB).

Explica per què el pod no es programarà mai i per què l'escalador de clúster no ho arregla afegint nodes.
Dona dues solucions diferents i digues quina triaries.

Exercici 2. Dissenya el clúster de la plataforma «Contoso Millas»: sis microserveis, trànsit de dia i gairebé nul de nit, més un procés nocturn de recàlcul de punts que tolera interrupcions.

Defineix els grups de nodes amb el seu mode, mida, zones i límits de l'escalador.
Justifica l'ús d'instàncies d'accés puntual i els seus riscos, indica les etiquetes obligatòries del projecte secundari i dues mesures d'estalvi addicionals.

Exercici 3. Un pod ha de llegir un secret de kv-contoso-pro i consultar db-reservas.

Enumera els passos per aconseguir-ho sense cap credencial al clúster, i explica quina relació hi ha entre l'emissor OIDC, el compte de servei i id-contoso-api-pro.
Per què és millor que muntar un Secret de Kubernetes amb la cadena de connexió?

Solucions

Solució 1:

Perquè la sol·licitud consumeix tot el node, i el sistema operatiu, el kubelet i els complements del sistema ja en reserven una part: la capacitat assignable d'un Standard_D8s_v5 és inferior a 8 vCPU i 32 GiB, així que cap node d'aquesta mida no té forat. L'escalador només arrenca nodes si el pod cabria en un node nou del grup; com que no hi cap, conclou que afegir nodes és inútil i no fa res. És correcte, tot i que el silenci despisti.
(a) Reduir la sol·licitud al que consumeix de debò, mesurat amb kubectl top —per exemple 4 vCPU i 16 GiB—. (b) Crear un grup de nodes amb màquines més grans, del tipus Standard_E16s_v5, i dirigir-hi el pod amb nodeSelector. Triaria (a) primer, perquè gairebé sempre la sol·licitud està inflada «per si de cas»; (b) només si el mesurament confirma que la càrrega necessita de debò aquesta mida.

Solució 2:

Grup sistema en mode System, 2 nodes Standard_D2s_v5, zones 1-2-3, escalador de 2 a 3. Grup aplicaciones en mode User, Standard_D4s_v5, zones 1-2-3, escalador de 2 a 8 durant el dia. Grup lotes en mode User amb --priority Spot, Standard_D8s_v5, escalador de 0 a 6, amb la seva contaminació corresponent perquè només el procés nocturn s'hi programi.
El recàlcul de punts és idempotent, es pot reprendre i no té usuari esperant: si Azure desallotja un node amb dos minuts d'avís, la feina es reprograma i només es perd temps, a canvi d'un estalvi enorme. El risc real és fer servir instàncies puntuals per a serveis en línia, on el desallotjament es tradueix en errors per a l'usuari; per això el grup està separat i contaminat. Etiquetes: entorno, proyecto=contoso-millas, centro-coste=CC-2077 i propietario. Estalvi addicional: escalar a zero el grup lotes fora de la finestra nocturna i aturar el clúster de desenvolupament amb az aks stop des d'un runbook a la nit i el cap de setmana.

Solució 3:

(a) Crear el clúster amb --enable-oidc-issuer --enable-workload-identity. (b) Crear el compte de servei sa-operaciones a operaciones-vuelo anotat amb l'identificador de client d'id-contoso-api-pro. (c) Crear la credencial federada amb az identity federated-credential create i el subjecte system:serviceaccount:operaciones-vuelo:sa-operaciones. (d) Donar a id-contoso-api-pro el rol Usuari de secrets de Key Vault sobre kv-contoso-pro i crear l'usuari extern a db-reservas. (e) Al pod, serviceAccountName i l'etiqueta azure.workload.identity/use: "true", i al codi DefaultAzureCredential. Quant a la relació: l'emissor OIDC del clúster signa el testimoni del compte de servei i la credencial federada declara davant d'Entra ID que aquell emissor i aquell subjecte concrets poden obtenir testimonis d'id-contoso-api-pro; la confiança és criptogràfica, no una contrasenya compartida.
Perquè un Secret de Kubernetes està codificat en base64, no xifrat: qui el pugui llegir a l'espai de noms, o qui accedeixi a una còpia de seguretat d'etcd, el llegeix en clar. A més s'ha de rotar a mà a tots els clústers. Amb identitat de càrrega de treball no existeix el secret: hi ha testimonis de vida curta emesos i revocables des d'Entra ID, amb traçabilitat als registres d'inici de sessió.

Conclusió

Kubernetes deixa de ser una paraula i passa a ser una eina amb criteri d'ús. Saps quan està justificat i quan és sobreenginyeria, i has vist Contoso adoptar-lo només per a la plataforma d'operacions de vol mentre el motor de disponibilitat es queda tranquil·lament a Container Apps. Manegues els conceptes imprescindibles —pla de control i nodes, pod, desplegament, rèplica, servei, ingrés, espai de noms, mapa de configuració i secret— i entens el bucle de reconciliació que els sosté. Tens clara la frontera de responsabilitats: el pla de control és gratuït, els nodes es paguen, i les actualitzacions, els límits i les polítiques continuen sent teus.

Has creat aks-contoso-operaciones amb grups de sistema i d'usuari separats, zones de disponibilitat, escalador automàtic, CNI Overlay per no esgotar la subxarxa, política de xarxa, integració amb Entra ID i RBAC d'Azure per espai de noms, extracció d'imatges des d'acrcontosopro amb --attach-acr, i identitat de càrrega de treball que dona als pods accés a kv-contoso-pro i db-reservas sense ni un sol secret. Has desplegat amb manifestos explicats camp a camp, publicat amb el complement d'encaminament i certificats de Key Vault, i saps fer servir kubectl per diagnosticar. Domines els tres escaladors i, sobretot, per què l'absència de requests i limits és la causa número u de clústers inestables. Saps actualitzar en l'ordre correcte protegint la disponibilitat amb pressupostos d'interrupció i finestres de manteniment, persistir amb discos davant d'Azure Files segons el mode d'accés, i deixar Container Insights encès des del minut u. I coneixes el camí de maduresa —Helm, GitOps amb Flux— i el cost real amb les seves palanques: instàncies d'accés puntual, grups que escalen a zero, aturar el clúster de desenvolupament i ajustar les sol·licituds.

Contoso té ara dues maneres d'executar codi propi i un dubte raonable: per a moltes tasques, mantenir alguna cosa executant-se és absurd. Generar el PDF d'una targeta d'embarcament ocupa dos segons i passa quan es confirma una reserva; sincronitzar el catàleg de tarifes passa quan canvia un document a cosmos-contoso-tarifas-pro. Per a això no vols un contenidor esperant ni un pod encès, vols que el codi s'executi quan passa alguna cosa i no existeixi la resta del temps. Aquesta és la computació sense servidor, i la lliçó següent, Azure Functions, la porta al detall: desencadenadors i enllaços, plans d'allotjament, les dues funcions reals de Contoso, Durable Functions per orquestrar la facturació en línia i la lliçó dura que ningú no s'estalvia, la idempotència.

Azure Kubernetes Service (AKS)

Contingut

Quan Kubernetes està justificat i quan no

Conceptes de Kubernetes, l'imprescindible

Què gestiona AKS i què continua sent teu

Crear `aks-contoso-operaciones` i triar el model de xarxa

Xarxes: kubenet, Azure CNI i CNI Overlay

Identitat: Entra ID, RBAC i identitat de càrrega de treball

Desplegar l'aplicació amb manifestos i `kubectl`

Entrada gestionada i certificats

Escalat, sol·licituds i límits

Actualitzacions, interrupcions i manteniment

Emmagatzematge, observabilitat, Helm i cost

Helm, GitOps i cost realista

Errors Comuns i Consells

Exercicis

Solucions

Conclusió

Curs d'Azure

Mòdul 1: Introducció a Azure

Mòdul 2: Serveis principals d'Azure

Mòdul 3: Bases de dades d'Azure

Mòdul 4: Seguretat a Azure

Mòdul 5: Azure DevOps

Mòdul 6: Serveis avançats d'Azure

Mòdul 7: Monitoratge i gestió

Mòdul 8: Gestió i optimització de costos

Mòdul 9: Estudis de cas i millors pràctiques

Azure Kubernetes Service (AKS)

Contingut

Quan Kubernetes està justificat i quan no

Conceptes de Kubernetes, l'imprescindible

Què gestiona AKS i què continua sent teu

Crear aks-contoso-operaciones i triar el model de xarxa

Xarxes: kubenet, Azure CNI i CNI Overlay

Identitat: Entra ID, RBAC i identitat de càrrega de treball

Desplegar l'aplicació amb manifestos i kubectl

Entrada gestionada i certificats

Escalat, sol·licituds i límits

Actualitzacions, interrupcions i manteniment

Emmagatzematge, observabilitat, Helm i cost

Helm, GitOps i cost realista

Errors Comuns i Consells

Exercicis

Solucions

Conclusió

Curs d'Azure

Mòdul 1: Introducció a Azure

Mòdul 2: Serveis principals d'Azure

Mòdul 3: Bases de dades d'Azure

Mòdul 4: Seguretat a Azure

Mòdul 5: Azure DevOps

Mòdul 6: Serveis avançats d'Azure

Mòdul 7: Monitoratge i gestió

Mòdul 8: Gestió i optimització de costos

Mòdul 9: Estudis de cas i millors pràctiques

Crear `aks-contoso-operaciones` i triar el model de xarxa

Desplegar l'aplicació amb manifestos i `kubectl`