Azure APP Service: Kubernetes (AKS)深度指南

作者：基于 Azure Masterclass V2 教程整理 | 适合：云工程师、DevOps、备考 AZ-104/AZ-204

一、为什么需要 AKS？

Azure Container Instances（ACI）解决了"快速运行容器"的问题，但当业务规模扩大，我们需要：

服务发现（Service Discovery）
：让容器自动找到彼此
滚动升级（Rolling Upgrade）
：更新镜像而不中断服务
自动扩缩容（Auto-scaling）
：根据负载动态增减 Pod 数量
持久化存储（Persistent Volume）
：容器重启后数据不丢失
多容器协同
：Pod 内共享网络和存储

Azure Kubernetes Service（AKS） 是 Azure 的托管 Kubernetes 服务，解决了上述所有问题。

ACI 是"一辆车"，AKS 是"一支车队 + 指挥中心"。

二、AKS 核心概念速查

概念	解释
Node（节点）	运行 Pod 的虚拟机（Azure VM）
Node Pool（节点池）	一组具有相同配置的节点（如 Windows 池、Linux 池）
Pod	K8s 最小调度单位，通常是单个容器
Deployment	声明 Pod 的期望状态（副本数、镜像版本）
Service	为 Pod 提供稳定的访问入口（负载均衡）
Ingress	HTTP/HTTPS 路由，通常配合外部负载均衡器
ConfigMap	存储非敏感配置
Secret	存储敏感数据（密码、密钥、证书）
Namespace	逻辑隔离（类似资源组）
ReplicaSet	确保指定数量的 Pod 副本始终运行

三、滚动升级（Rolling Upgrade）

滚动升级是 Kubernetes 的核心能力之一，允许在不影响可用性的前提下更新应用。

工作原理：

新版本 Pod 逐步启动（不超过 maxSurge）
旧版本 Pod 逐步终止（不超过 maxUnavailable）
滚动过程持续直到所有 Pod 更新完毕

# deployment.yaml 示例
apiVersion:apps/v1
kind:Deployment
metadata:
name:my-app
spec:
replicas:5
strategy:
type:RollingUpdate
rollingUpdate:
maxSurge:1# 最多超出预期多少个 Pod
maxUnavailable:0# 最多不可用多少个 Pod（0 = 保持全程可用）
template:
spec:
containers:
-name:my-app
image:myapp:v2# 更新镜像版本即触发滚动升级

回滚（Rollback）：

kubectl rollout undo deployment/my-app          # 回滚到上一版本
kubectl rollout undo deployment/my-app --to-revision=3  # 回滚到指定版本

四、自动扩缩容（Auto-scaling）

AKS 提供三种自动扩缩容机制：

4.1 Horizontal Pod Autoscaler（HPA）

根据 CPU/内存使用率自动调整 Pod 数量：

kubectl autoscale deployment my-app \
  --cpu-percent=70 \
  --min=2 --max=10

# 或通过 YAML 声明
apiVersion:autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:my-app-hpa
spec:
scaleTargetRef:
apiVersion:apps/v1
kind:Deployment
name:my-app
minReplicas:2
maxReplicas:10
metrics:
-type:Resource
resource:
name:cpu
target:
type:Utilization
averageUtilization:70

4.2 KEDA（Kubernetes Event-driven Autoscaling）

KEDA 是 Kubernetes 原生的事件驱动扩缩容器，AKS 内置支持。

与 HPA 不同，KEDA 可以根据任意外部指标触发扩缩容：

触发器	使用场景
Azure Queue Storage	消息队列积压时自动扩容
Prometheus	自定义指标达到阈值时扩容
MySQL / PostgreSQL	数据库连接数过多时扩容
Kafka	消费者 Lag 增大时扩容
HTTP 请求数	特定端点请求激增时扩容

# KEDA 扩缩容配置示例（基于 Azure Queue）
apiVersion:keda.sh/v1alpha1
kind:TriggerAuthentication
metadata:
name:azure-queue-auth
spec:
secretTargetRef:
-parameter:connectionString
name:azure-queue-secret
key:connectionString
---
apiVersion:keda.sh/v1alpha1
kind:ScaledObject
metadata:
name:my-app-scaler
spec:
scaleTargetRef:
name:my-app
minReplicaCount:2
maxReplicaCount:20
triggers:
-type:azure-queue
metadata:
queueName:my-queue
queueLength:"10"
authenticationRef:
name:azure-queue-auth

4.3 Cluster Autoscaler

当 HPA/KEDA 需要更多 Pod 但节点资源不足时，Cluster Autoscaler 自动向 AKS 添加新节点：

# 启用 Cluster Autoscaler（通过 az aks update）
az aks update \
  --resource-group myRG \
  --name myAKS \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

五、服务发现与网络

5.1 ClusterIP（默认）

为 Pod 分配集群内部 IP，仅集群内可访问：

apiVersion:v1
kind:Service
metadata:
name:my-service
spec:
selector:
app:my-app
ports:
-port:80# Service 端口
targetPort:8080# Pod 容器端口
type:ClusterIP

5.2 LoadBalancer

通过 Azure Load Balancer 暴露服务到公网：

type:LoadBalancer# Azure 自动创建 LB 并分配公网 IP

5.3 Ingress Controller

通常使用 NGINX Ingress Controller 处理 HTTP/HTTPS 路由：

apiVersion:networking.k8s.io/v1
kind:Ingress
metadata:
name:my-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target:/
spec:
rules:
-host:myapp.example.com
http:
paths:
-path:/api
pathType:Prefix
backend:
service:
name:my-api-service
port:
number:80

六、GitOps 集成（Flux & Argo CD）

GitOps 是用 Git 仓库作为声明式基础设施和应用配置的唯一真实来源（Single Source of Truth）。

6.1 Azure Arc + GitOps

Azure Arc 可以将非 Azure 集群（如本地或其他云）纳入 Azure 管理，并通过 GitOps 自动化部署：

# 将集群连接到 Azure Arc
az connectedk8s connect \
  --resource-group myRG \
  --name myCluster

# 配置 GitOps
az k8s-configuration create \
  --resource-group myRG \
  --cluster-name myCluster \
  --name my-gitops \
  --operator-instance-name flux \
  --operator-namespace flux-system \
  --repository-url https://github.com/myorg/k8s-config \
  --scope cluster

6.2 Flux 工作原理

Flux 自动监听 Git 仓库变更：

检测到新的 commits 或 tags
自动 kubectl apply 应用配置
确保集群状态与 Git 声明一致

6.3 优势

审计追踪
：所有变更通过 Pull Request，代码审查记录完整
一键回滚
：git revert 即可回滚基础设施变更
幂等性
：声明式配置天然幂等，多次应用结果一致
GitOps 自动化
：减少人工操作，降低错误率

七、存储与持久化

Kubernetes 通过 PersistentVolume（PV） 和 PersistentVolumeClaim（PVC） 抽象存储：

# Azure Disk 作为 PersistentVolume
apiVersion:v1
kind:PersistentVolumeClaim
metadata:
name:my-pvc
spec:
accessModes:
-ReadWriteOnce
storageClassName:managed-premium
resources:
requests:
storage:10Gi
---
apiVersion:apps/v1
kind:Deployment
spec:
template:
spec:
volumes:
-name:my-volume
persistentVolumeClaim:
claimName:my-pvc
containers:
-name:my-app
volumeMounts:
-name:my-volume
mountPath:/data

八、AKS 网络基础

Azure CNI 网络模式

AKS 默认使用 Azure CNI（Container Networking Interface），每个 Pod 获得真实 Azure VNet IP：

Pod 与 VNet 内其他资源直接通信
支持 VNet 安全策略（NSG）
节点数量受 VNet 子网 CIDR 限制

# 创建时指定 CNI 网络
az aks create \
  --resource-group myRG \
  --name myAKS \
  --network-plugin azure \
  --service-cidr 10.0.0.0/16 \
  --dns-service-ip 10.0.0.10 \
  --vnet-subnet-id /subscriptions/xxx/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/aks

九、AKS 成本优化

策略	说明
Spot Node Pool	使用 Azure 闲置容量，成本降低 80%+，适合无状态工作负载
KEDA 按需扩缩	只在需要时运行 Pod，避免资源浪费
Reserved Instances	节点预付费，最高可省 60%
自动缩放到 0	使用 KEDA 可将 Pod 缩容到 0（无流量时）
选择合适 SKU	非计算密集型用 B 系列可突发的 VM

十、核心要点总结

概念	核心价值
HPA	根据 CPU/内存自动扩缩容 Pod
KEDA	事件驱动扩缩（队列、DB 连接、外部指标）
Cluster Autoscaler	节点不足时自动添加节点
Rolling Upgrade	零停机更新镜像版本
GitOps (Flux)	Git 驱动的基础设施自动化
Azure CNI	Pod 获得 VNet 真实 IP
Spot Node	成本降低 80%，适合无状态负载
PVC/PV	容器持久化存储抽象

下期预告：《Azure 容器服务完全指南（三）：Serverless 与 Azure 应用服务》—— DAPR、KEDA、App Service、Logic Apps、Static Web Apps，低代码到无代码的全栈选择。

已关注

关注

重播分享赞

视频详情