一、Cloud Foundry
使用Scaling an Application Using App Autoscaler插件,基于资源使用情况触发简单扩缩容
CPU、内存、Http带宽、延时等
监控这些资源的使用情况决定扩缩容策略:实例是增加还是减少
Instance Limits 限制实例数量范围,定义伸缩上下限
Add a Scaling Rule 定义伸缩规则
还可以定义生效时间范围规则等等
0.扩缩容机制
手动扩缩容:通过 cf scale 命令调整应用实例数。
自动扩缩容:依赖第三方工具或插件(如 App Autoscaler),可根据 CPU 使用率、内存占用等指标进行扩缩容。
二、K8S
1.常规扩缩容
- HPA:横向扩缩容,复制pod,增加数量
- VPA:纵向扩缩容,增大pod的资源
- cronHPA:定时扩缩容
- cluster-autoscaler:集群底层服务器扩缩容
主要基于CPU和内存阈值,自动增加+减少pod数量
2.Istio+Knative 边车Serverless扩缩容
Istio 和 Knative 是 Kubernetes 上流行的两个开源项目,用于构建和运行云原生应用。两者结合可为应用提供服务网格、流量管理、服务自动扩缩容等能力,是 Serverless 架构和微服务架构的最佳搭档。
Istio 是一个开源的服务网格实现,用于连接、管理和保护 Kubernetes 上的微服务。其主要功能包括:
核心组件
- Envoy Proxy:每个服务旁部署的边车代理,负责服务间通信、流量管理和安全。
- Pilot:管理流量规则和服务发现。
- Telemetry:收集遥测数据和执行策略控制。
- Citadel:提供服务间安全通信(mTLS 证书管理)。
功能亮点
- 流量管理:支持请求路由、流量分配、A/B 测试、蓝绿部署、金丝雀发布等。
- 安全性:提供服务间 mTLS 加密、访问控制、身份认证等。
- 监控与可观测性:集成 Prometheus、Grafana、Jaeger,提供详细的指标和分布式追踪。
- 弹性特性:自动重试、熔断器、超时机制。
使用场景
- 微服务之间的安全通信
- 流量细粒度控制
- 自动化服务监控
Knative 是基于 Kubernetes 的开源平台,旨在提供构建 Serverless 应用的能力。它将复杂的 Kubernetes 操作简化为易用的接口,专注于无服务器(Serverless)工作负载的自动扩展、事件驱动和部署。
核心组件
- Knative Serving专注于无状态服务的部署和管理。
- 支持零到多实例的自动扩展(scale-to-zero)。
- 提供请求路由、自动修复和流量拆分。
- 支持基于流量权重的金丝雀部署和 A/B 测试。
Knative Eventing
- 提供事件驱动的架构支持。
- 能够将事件源与 Knative 服务连接起来。
- 支持多种事件源(Kafka、HTTP、Google Cloud Pub/Sub 等)。
功能亮点
- 快速启动和按需扩展:根据负载自动调整实例数量,零流量时可缩减至 0。
- 事件驱动架构:轻松实现事件触发的无服务器应用。
- 开发者友好:屏蔽底层Kubernetes 细节,只需定义简单的 YAML 即可部署。
使用场景
- 基于 HTTP 的无状态服务
- 事件驱动的任务处理
- 零配置的 Serverless 部署
Knative 的核心依赖 Istio 提供的服务网格能力来管理流量、监控和安全。在 Knative 中,Istio 扮演了底层流量管理和安全通信的角色。
典型应用场景
事件驱动的 Serverless 应用
利用 Knative Eventing 捕获 Kafka 或云事件,将事件路由到 Knative 服务。
使用 Istio 提供的流量管理和安全机制。
金丝雀部署
Knative 配置多版本服务。
Istio 分配流量(如 90% 流量到 v1,10% 流量到 v2)。
弹性缩放
Knative 实现零到多实例扩展,结合 Istio 自动监控和负载均衡。
0.扩缩容机制
手动扩缩容:
使用 kubectl scale 命令调整 Deployment 或 StatefulSet 的副本数。
自动扩缩容:
HPA(Horizontal Pod Autoscaler):基于 CPU、内存或自定义指标(通过 Prometheus Adapter 等)实现水平扩展。
VPA(Vertical Pod Autoscaler):动态调整容器的资源请求与限制。
Cluster Autoscaler:自动调整节点数量以支持 Pod 的需求。
Service Mesh
Service Mesh 是一种用于管理微服务通信的架构模式,提供了一层基础设施,用于处理服务间的网络流量。它主要解决了分布式微服务架构中常见的通信问题,如服务发现、负载均衡、认证授权、流量控制和可观测性。
核心特性
- 服务间通信的抽象层
将通信逻辑从应用代码中抽离出来。
通过透明代理(sidecar)实现请求拦截和处理。 - 零信任安全模型
支持 mTLS(双向 TLS)加密,确保服务间通信安全。
提供认证和授权控制。 - 流量控制
支持 A/B 测试、金丝雀发布、蓝绿部署等。
提供动态路由、故障注入和超时重试。 - 可观测性
提供分布式追踪、日志和监控指标。
集成工具如 Prometheus、Grafana、Jaeger。 - 弹性特性
实现断路器、限流、重试和负载均衡。
Istio是最流行的 Service Mesh,功能强大,生态完善
Service Mesh 与 Istio/Knative 的关系
- Service Mesh 是基础架构
Service Mesh 为微服务提供通用的通信管理层。
Istio 是 Service Mesh 的具体实现之一。 - Knative 使用 Service Mesh
Knative 依赖 Service Mesh(如 Istio)来实现流量路由和监控功能。
Knative 专注于 Serverless 场景,而 Service Mesh 提供底层支持。
三、Mesos+Marathon
Autoscale controller观察每个App的使用情况,根据预定义的规则,通过Marathon的API来实现 scale up/down,来实现扩缩容策略
https://github.com/d2iq-archive/marathon-lb-autoscale
创建autoscale应用
关联Marathon和HAProxy
{"id": "marathon-lb-autoscale","args":["--marathon", "http://leader.mesos:8080","--haproxy", "http://marathon-lb.marathon.mesos:9090","--apps", "nginx_10000","--target-rps","100"##添加下面的Specific options参数,制定对应的扩缩容规则],"cpus": 0.1,"mem": 16.0,"instances": 1,"container": {"type": "DOCKER","docker": {"image": "mesosphere/marathon-lb-autoscale","network": "HOST","forcePullImage": false}}
}
Specific options:--marathon URL URL for Marathon--haproxy [URLs] Comma separate list of URLs for HAProxy. If this is a Mesos-DNS A-record, all backends will be polled.--interval Float Number of seconds (N) between update intervals (Default: 60)--samples Integer Number of samples to average (Default: 10)--cooldown Integer Number of additional intervals to wait after making a scale change (Default: 5)--target-rps Integer Target number of requests per second per app instance (Default: 1000)--apps [APPS] Comma separated list of <app>_<service port> pairs to monitor--marathonCredentials [MarathonCredentials]Colon separated string of <username>:<password>--haproxyCredentials [HAProxyCredentials]Colon separated string of <username>:<password>--threshold-percent Float Scaling will occur when the target RPS differs from the current RPS by at least this amount (Default: 0.5)--threshold-instances IntegerScaling will occur when the target number of instances differs from the actual number by at least this amount (Default: 3)--max-instances Integer Maximum number of instances an app may be scaled to (Default: a huge number)--min-instances Integer Minimum number of instances an app must have (Default: 1)
0.扩缩容机制
手动扩缩容:通过 Marathon Web UI 或 API 调整应用实例数。
自动扩缩容:需要集成第三方工具(如 Chronos、Prometheus 或其他外部脚本)实现。
四、总结
- Cloud Foundry:适合以开发为中心的小型团队或快速构建和部署应用的场景。
- Kubernetes:适合云原生应用、需要复杂扩缩容策略、或需要支持多种资源管理的场景。
- Mesos Marathon:适合大规模批量任务、数据密集型计算场景,但生态支持较弱。