公有云服务架构与运维（基于阿里云）（微课版）教案15容器弹性伸缩与微服务治理、Serverless容器与CICD流水线

教师备课纸教师备课纸课题容器弹性伸缩与微服务治理课型理实一体授课班级授课时数2教学目标1.知识目标：•了解Kubernetes弹性伸缩机制：HPA（基于CPU/内存）和VPA（垂直伸缩）。•理解服务发现是微服务架构通信的基础。2.技能目标：•能为已部署的Deployment配置HPA（水平Pod自动伸缩）策略。•能使用压测工具模拟高负载，验证Pod的自动扩容与缩容效果。•能为Ingress配置基于路径（Path）的流量转发规则，实现多服务路由。3.素质目标：•深化对云原生应用“自愈”与“弹性”特性的理解。•初步建立微服务架构下流量管理的意识。教学重点•HPA策略的创建与配置（基于CPU指标）。•使用压测工具验证HPA的自动扩缩容效果。教学难点•理解HPA的工作原理及其对应用无状态性的要求。•编写和应用包含多路径规则的IngressYAML文件。学情分析学生已掌握基本的容器部署，但对“弹性”和“微服务治理”等进阶概念较为陌生。压测环节可能因工具不熟而受阻。教学需提供简单易用的压测命令，并强调应用必须是无状态的才能使用HPA。教学效果•学生成功为WordPressDeployment配置了HPA策略（CPU>50%时扩容）。•学生通过hey或ab工具对应用进行压测，观察到Pod数量从1个自动增加到3个。•学生配置了Ingress规则，能将/blog路径的请求转发到WordPress服务。教后记通过实时压测观察Pod数量动态变化，给学生留下了深刻印象，有效诠释了“弹性”的价值。主要问题是部分学生未在Deployment中预先设置CPUrequests，导致HPA无法工作。下次实训前需增加一个检查清单，确保所有前置条件都已满足。一、情境导入与任务驱动（10分钟）场景设问：我们的容器化WordPress很酷，但如果突然有大量用户访问，单个Pod会不会被压垮？能否像ECS一样自动加机器？引出容器弹性：Kubernetes提供了更细粒度的弹性能力——HPA（HorizontalPodAutoscaler），它能根据CPU、内存等指标，自动增减Pod的数量！明确任务：今天我们将让我们的WordPress应用具备“自我调节”的能力，并学习如何用Ingress管理更复杂的流量。二、核心概念精讲（20分钟）弹性伸缩机制：HPA(水平Pod伸缩)：最常用。通过增加或减少Pod副本数来应对负载变化。要求应用是无状态的。VPA(垂直Pod伸缩)：较少用。通过调整单个Pod的CPU/内存请求量来应对负载，通常需要重启Pod。微服务治理基础-服务发现：在K8s中，每个Service都有一个固定的DNS名称（如wordpress-service.default.svc.cluster.local）。其他服务只需通过这个名称即可访问，无需关心后端Pod的具体IP，实现了解耦。Ingress高级路由：除了基于域名的路由，Ingress还支持基于URL路径的路由（Path-basedRouting），例如：/blog→WordPressS/api→APIService三、技能实训（50分钟）任务：让我的应用学会“自我调节”配置HPA（20分钟）：前提：确保WordPressDeployment中的Pod已设置resources.requests.cpu（如100m）。创建HPA（使用命令行）：kubectlautoscaledeploymentwordpress-deployment\--cpu-percent=50\--min=1\--max=3#或通过YAML文件定义更复杂的指标查看HPA状态：kubectlgethpa压测与验证（15分钟）：安装压测工具（在CloudShell或一台ECS上）：#安装hey(Go语言压测工具)wgethttps://.../hey_linux_amd64-Ohey&&chmod+xhey执行压测：./hey-z2m-c20http://<INGRESS-EXTERNAL-IP>/#-z2m:持续2分钟,-c20:20个并发实时监控：#新开一个终端，持续观察Pod数量变化watchkubectlgetpods#应能看到Pod数量从1逐渐增加到3配置Ingress路径路由（15分钟）：修改IngressYAML：在rules下添加paths。yamlspec:rules:-http:paths:-path:/blogpathType:Prefixbackend:service:name:wordpress-serviceport:number:80应用更新：kubectlapply-fupdated-ingress.yamlkubectlgetingress验证：访问http://<INGRESS-IP>/blog，应能正常打开WordPress。四、总结评价与拓展延伸（10分钟）成果验收：检查学生是否成功创建HPA，并能通过kubectlgethpa看到当前指标。验证在压测期间，学生集群中的Pod数量是否按预期增加。检查Ingress配置，确认路径路由规则是否生效。知识梳理：HPA=Pod的自动空调：根据负载自动增减实例数。服务发现=微服务的通讯录：通过名字找服务，不靠IP。Ingress路由=智能交通灯：把不同路径的车流（请求）引向不同目的地。作业布置：思考题：HPA是基于Pod的平均CPU使用率。如果我们的应用是I/O密集型（如文件处理），CPU可能不高但磁盘I/O很高，HPA会触发扩容吗？为什么？课程总结：回顾整个学期所学，从单台ECS到高可用架构，再到云原生容器化，思考云计算技术演进的核心驱动力是什么？课题Serverless容器与CI/CD流水线课型理实一体授课班级授课时数2教学目标1.知识目标：•了解Serverless容器（ECI）的核心价值：无需管理服务器，按需运行容器。•理解虚拟节点（VirtualKubelet）如何将ECI无缝接入ACK集群。•掌握DevOps和CI/CD的基本流程与核心价值。2.技能目标：•能通过YAML文件在ACK集群中部署一个由ECI承载的Pod应用。•能使用阿里云云效Flow创建一个简单的CI/CD流水线，实现代码提交后自动构建镜像并部署到ECI。3.素质目标：•体验“无服务器”（Serverless）的极致运维简化模式。•培养自动化、持续交付的现代软件工程思维。教学重点•通过虚拟节点在ACK中部署ECI应用。•使用云效Flow配置从代码到部署的自动化流水线。教学难点•理解ECI与传统ECS承载的Pod在调度和计费上的区别。•配置云效Flow流水线中的构建、推送、部署各阶段任务。学情分析学生已熟悉容器和K8s，但对Serverless和CI/CD概念较为抽象。云效Flow界面操作步骤较多，容易出错。教学需提供清晰的流水线配置截图和分步指南，并强调ECI“免运维、秒级弹性”的特点。教学效果 •学生成功在ACK集群中部署了一个Nginx应用，其Pod由ECI承载（通过/eci=true标签指定）。•学生创建了云效Flow流水线，当向代码仓库推送新代码后，能自动完成镜像构建、推送到ACR，并更新ECI上的应用。教后记Serverless和CI/CD给学生带来了极大的震撼，让他们看到了云技术的未来方向。实训环节中，云效Flow的配置步骤是主要难点，部分学生因YAML模板未更新标签而失败。下次可提供一个完整的、可直接导入的流水线模板，进一步降低操作复杂度，让学生更聚焦于理念的理解。一、情境导入与任务驱动（10分钟）痛点升级：我们用HPA实现了弹性，但依然需要预先规划和管理Worker节点池。有没有一种方式，可以完全不用关心服务器，只关注代码和容器？引出Serverless与CI/CD：ECI(弹性容器实例)：真正的“无服务器”容器，秒级启动，按实际运行时间计费。云效Flow：阿里云的CI/CD工具，能将“代码提交”到“线上部署”的全过程自动化。明确任务：今天我们将体验最前沿的Serverless容器，并亲手搭建一条自动化发布流水线！二、核心概念精讲（20分钟）Serverless容器(ECI)：核心价值：零服务器管理、极致弹性（秒级）、按量付费（精确到秒）。工作方式：通过虚拟节点（VirtualKubelet）接入ACK集群。调度器将带有特定标签（如/eci:"true"）的Pod调度到ECI上运行。DevOps与CI/CD：CI(持续集成)：开发人员频繁地（每天多次）将代码集成到主干，并自动进行构建和测试。CD(持续交付/部署)：将经过验证的代码自动部署到生产或预发环境。核心价值：加速交付、提升质量、降低风险。三、技能实训（50分钟）任务：打造我的自动化Serverless应用部署ECI应用（20分钟）：前提：确保ACK集群已安装ack-virtual-node组件（可在控制台“组件管理”中一键安装）。准备YAML：教师提供eci-nginx.yaml模板。yamlapiVersion:v1kind:Podmetadata:name:nginx-ecilabels:/eci:"true"#关键！指定调度到ECIspec:containers:-name:nginximage:nginx:latestrestartPolicy:Never部署与验证：kubectlapply-feci-nginx.yamlkubectlgetpods-owide#观察NODE列，应显示为virtual-kubelet开头的虚拟节点构建CI/CD流水线（30分钟）：准备工作：在Codeup（阿里云代码托管）创建一个简单的HTML项目仓库。在ACR创建一个镜像仓库（如my-app）。创建云效Flow流水线：源码阶段：选择刚创建的Codeup仓库。构建阶段：构建工具：DockerDockerfile路径：Dockerfile镜像仓库：选择ACR中的my-app仓库，标签设为${FLOW_COMMIT_ID}。部署阶段：部署方式：Kubernetes集群：选择自己的ACK集群。命名空间：default更新策略：RollingUpdate关键：在YAML模板中，确保Pod模板包含/eci:"true"标签。运行与验证：手动运行一次流水线，观察各阶段是否成功。向代码仓库推送一次新提交，验证流水线是否被自动触发。四、总结评价与拓展延伸（10分钟）成果验收：