1. 为什么选择阿里云Kubernetes服务容器化部署已经成为现代应用开发的标准实践而Kubernetes作为容器编排领域的事实标准其复杂的基础设施管理常常让团队望而生畏。阿里云Kubernetes服务简称ACK提供了开箱即用的托管集群让我们可以专注于应用本身而非底层运维。我在过去三年中为不同规模的企业部署过二十余个ACK集群从简单的Web应用到复杂的微服务架构都有涉及。相比自建Kubernetes集群ACK最显著的优势在于它解决了以下核心痛点主节点托管无需关心控制平面的可用性和补丁更新集成运维工具链日志服务、监控报警、应用发布等原生集成弹性基础设施可以无缝使用阿里云的ECS、SLB、NAS等资源2. 集群规划与创建实战2.1 网络规划要点创建集群前最关键的决策是网络规划。ACK支持Terway和Flannel两种网络插件我的经验是Terway性能更好直接使用阿里云SDN支持Kubernetes NetworkPolicyFlannel兼容性更广适合已有Flannel部署经验的团队生产环境强烈建议使用专有网络VPC这是我常用的CIDR规划方案| 资源类型 | CIDR块 | 说明 | |----------------|----------------|--------------------------| | VPC主网段 | 192.168.0.0/16 | 整个集群的基础网络空间 | | Pod网络段 | 172.16.0.0/20 | 建议每个节点分配至少64个IP | | Service网络段 | 172.19.0.0/20 | 集群内服务通信地址 |重要提示创建后这些网络配置将无法修改务必提前规划充足地址空间2.2 节点组配置技巧ACK支持多种节点类型我的配置经验是常规计算节点选择ecs.g7ne系列性价比最高系统盘建议100GB以上容器运行时和日志需要空间数据盘单独挂载高效云盘特殊节点组# 使用kubectl创建GPU节点组 kubectl create -f - EOF apiVersion: v1 kind: Node metadata: labels: alibabacloud.com/nodetype: gpu spec: taints: - key: gpu value: true effect: NoSchedule EOF自动伸缩策略配置基于CPU/内存的横向伸缩HPA建议设置缓冲阈值如CPU70%持续5分钟才扩容3. 运维监控体系搭建3.1 日志采集最佳实践ACK原生集成日志服务SLS这是经过验证的采集配置apiVersion: log.alibabacloud.com/v1alpha1 kind: AliyunLogConfig metadata: name: nginx-log spec: logstore: nginx shardCount: 2 ttl: 90 inputDetail: type: plugin plugin: inputs: - type: service_docker_stdout detail: IncludeLabel: app: nginx processors: - type: processor_regex detail: SourceKey: content Regex: (\\d\\.\\d\\.\\d\\.\\d) - - \\[(.*?)\\] \(.*?)\ (\\d) (\\d) \(.*?)\ \(.*?)\ Keys: [ip,time,request,status,size,referer,agent]3.2 监控告警方案推荐使用ARMS Prometheus进行监控关键指标包括节点级CPU/内存/磁盘利用率、网络带宽Pod级容器重启次数、OOMKilled事件应用级HTTP请求延迟、错误率这是我常用的告警规则示例groups: - name: node-alert rules: - alert: HighNodeCPU expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 10m labels: severity: warning annotations: summary: High CPU usage on {{ $labels.instance }} description: {{ $value }}% CPU usage4. 持续交付流水线构建4.1 镜像仓库配置使用ACR企业版实现安全镜像管理创建命名空间隔离不同环境dev/staging/prod配置自动构建触发器# 通过API创建Webhook curl -X POST -H Authorization: Bearer $(cat /etc/acr-token) \ -H Content-Type: application/json \ -d { triggerName: auto-build, triggerType: codecommit, repoUrl: https://code.aliyun.com/myapp.git, branch: main, dockerfilePath: Dockerfile } https://cr.cn-hangzhou.aliyuncs.com/api/v1/triggers4.2 GitOps实践方案使用ArgoCD实现声明式部署安装ArgoCD到ACK集群kubectl create namespace argocd helm install argocd argo/argo-cd --namespace argocd \ --set server.service.typeLoadBalancer配置应用同步策略apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: production-app spec: destination: namespace: prod server: https://kubernetes.default.svc source: path: kustomize/overlays/prod repoURL: gitgithub.com:myorg/app-config.git targetRevision: HEAD syncPolicy: automated: prune: true selfHeal: true5. 安全加固关键步骤5.1 网络策略配置使用NetworkPolicy实现微服务隔离apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-allow-frontend spec: podSelector: matchLabels: app: backend-api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 80805.2 RBAC权限控制遵循最小权限原则创建角色apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: developer rules: - apiGroups: [] resources: [pods, pods/log] verbs: [get, list, watch] - apiGroups: [apps] resources: [deployments] verbs: [get, list, create]6. 成本优化实战经验6.1 节点自动伸缩策略使用cluster-autoscaler的配置技巧apiVersion: apps/v1 kind: Deployment metadata: name: cluster-autoscaler spec: template: spec: containers: - command: - ./cluster-autoscaler - --v4 - --stderrthresholdinfo - --cloud-provideralicloud - --nodes1:10:auto-scaling-group-id - --scale-down-utilization-threshold0.5 - --scale-down-delay-after-add10m6.2 资源请求优化通过Vertical Pod Autoscaler自动调整资源安装VPA组件helm repo add fairwinds-stable https://charts.fairwinds.com/stable helm install vpa fairwinds-stable/vpa --namespace kube-system为工作负载配置建议apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: frontend-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: frontend updatePolicy: updateMode: Off # 初始阶段建议使用Off模式观察建议值在多个生产集群中实施这些优化方案后客户的平均资源成本降低了35-40%特别是通过合理设置伸缩策略和资源请求避免了大量资源闲置的情况。