后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载Cortex 是一个面向大规模机器学习场景的生产级基础设施平台本文围绕仓库中的 docs/overview.md 展开系统讲解其集群的物理与逻辑架构、节点组与弹性伸缩机制、网络与可观测性设计以及集群就绪后如何通过 CLI 或 Python Client 部署四类工作负载。读完本文你将掌握 Cortex 集群从创建到部署的完整链路并理解其中每个关键组件EKS、Cluster Autoscaler、Istio 双网关、FluentBit、Prometheus、Grafana在实际实现中的具体作用。集群整体架构AWS 账户内的专属 EKS 集群Cortex 集群并不是多租户共享的托管服务而是运行在你自己 AWS 账户中的一个专属 EKSKubernetes集群。集群创建时会放置在一个独立的 VPC 中所有计算、网络与监控组件均由 Cortex 的安装脚本在账户内自动拉起。从安装脚本 manager/install.sh 中可以清晰看到集群的搭建顺序create_eks基于 manager/generate_eks.py 生成的 EKS 清单Kubernetes 版本为 1.22通过eksctl create cluster拉起 EKS 控制平面与工作节点setup_namespaces/setup_configmap创建集群命名空间并把client-config、cluster-config、env-vars等 ConfigMap 写入集群供后续组件读取环境与镜像配置setup_ipvs/setup_istio配置 kube-proxy 的 IPVS 模式并安装 Istio 服务网格最后通过apis.yaml.j2模板把 API 网关路由挂载到负载均衡器上setup_*一系列组件autoscalerautoscaler.yaml.j2、cluster-autoscalercluster-autoscaler.yaml.j2、async gateway、fluent-bit、metrics-server、Prometheus、Grafana、GPU/Inferentia 设备插件restart_operator/start_controller_manager启动负责管理全部工作负载生命周期的 Operator 与 Controller Managervalidate_cortex轮询等待两个负载均衡器进入active状态、目标组变为healthy确认集群就绪后才输出端点。值得注意的细节是安装脚本还区分了cluster_up全新创建与cluster_configure扩缩容/更新配置两条路径--configure模式只做节点组调整、网络更新与组件重启而不会重建集群。Worker 节点组EC2 自动扩缩组 多样化实例支持节点组与实例类型Cortex 集群的工作节点由EC2 自动扩缩组Autoscaling Groups组成每个节点组对应一个 ASG。节点组定义在集群配置文件的node_groups字段中每个节点组可独立指定实例类型、最小/最大实例数、优先级等参数。Cortex 支持大多数 EC2 实例类型。在 manager/generate_eks.py 的parse_instance_type中可以看到实例类型会被解析为family、generation、capabilities、size四个维度从而决定节点组配置的差异。同时脚本会为节点注入AmazonEKSWorkerNodePolicy、AmazonEKS_CNI_Policy、AmazonEC2ContainerRegistryReadOnly、ElasticLoadBalancingFullAccess以及 Cortex 自定义 IAM 策略见default_nodegroup中的attachPolicyARNs这些策略来自集群配置中的cortex_policy_arn与可选的iam_policy_arns。GPU 与 Inferentia 硬件支持为了把 GPU 和 AWS Inferentia 加速器暴露给工作负载节点在启动时preBootstrapCommands会加载 IPVS 内核模块并在集群安装阶段部署对应的设备驱动GPU安装脚本中通过 nvidia.yaml 部署 NVIDIA Device Plugin并配套部署 prometheus-dcgm-exporter.yaml 用于收集 GPU 指标Inferentia通过 inferentia.yaml 部署 Neuron Device Plugin 与 Neuron Scheduler。集群配置定义在 pkg/types/clusterconfig/cluster_config.go 中MaxNodeGroups 100单次创建最多新增 200 个节点MaxNodesToAddOnClusterUp配置阶段每次最多新增 100 个MaxNodesToAddOnClusterConfigure这些限制是为了防止节点批量加入时压垮 API Server以及避免超过 AWS 负载均衡器的 500 目标配额。预留实例与 Spot 实例每个节点组都可以通过spot字段选择使用Spot 实例来降低成本同时也可以使用预留实例。为配合 Spot 实例可能被回收的场景Cortex 的四类工作负载都具备自动从故障和 Spot 实例终止中恢复的能力见下文工作负载部分。集群级弹性Kubernetes Cluster Autoscaler节点级的弹性由Kubernetes Cluster Autoscaler负责。它根据工作负载的调度需求自动扩容/缩容对应的节点组。部署清单 cluster-autoscaler.yaml.j2 展示了其关键配置--cloud-provideraws通过 ASG 标签k8s.io/cluster-autoscaler/enabled自动发现节点组node-group-auto-discovery--expanderpriority结合模板中生成的cluster-autoscaler-priority-expanderConfigMap按节点组的priority字段决定扩容时优先选择哪个节点组——Spot 节点组对应cx-ws-name前缀、按需节点组对应cx-wd-name前缀扫描间隔 20 秒、节点供应超时 8 分钟、每分钟最多扩容 50 个节点。除了节点级 AutoscalerCortex 还部署了独立的 Autoscaler 组件autoscaler.yaml.j2它以--prometheus-urlhttp://prometheus.prometheus:9090读取指标负责Pod 级的弹性伸缩如 Realtime 的并发伸缩、Async 的队列长度伸缩与 Cluster Autoscaler 形成Pod 级 节点级两层弹性体系。网络专用 VPC 与双负载均衡器默认 VPC集群安装时默认会为集群创建一个全新的专用 VPC。如果你的 VPC 预算紧张或有既有的网络规划也可以通过集群配置中的subnet_visibility等参数与 VPC Peering 进行网络定制当管理负载均衡器为 internal 类型时安装脚本会提示你需要配置 VPC Peering 才能连接集群。两个职责分离的 AWS 负载均衡器Cortex 创建两个 AWS 负载均衡器来路由流量二者职责严格分离负载均衡器服务对象说明API 负载均衡器你的 API 流量对应 Istio 的ingressgateway-apis服务承载所有已部署工作负载的业务请求Operator 负载均衡器API 管理请求对应 Istio 的ingressgateway-operator服务承载 CLI / Python Client 发往 Cortex 控制面的管理请求deploy、get、logs 等这个设计在 manager/install.sh 的validate_cortex与print_endpoints中可以直接印证脚本分别获取ingressgateway-apis与ingressgateway-operator的loadBalancerhostname打印出operator:与api load balancer:两个端点并分别调用get_api_load_balancer_state.py与get_operator_load_balancer_state.py验证两个负载均衡器都进入active状态。流量安全限制两个负载均衡器的流量都可以按集群配置进行加密与访问限制HTTPS/证书通过ssl_certificate_arn指定 ACM 证书Istio 网关服务以service.beta.kubernetes.io/aws-load-balancer-ssl-cert注解挂载证书。安装脚本的update_networking还处理了一个已知坑更换证书时 AWS NLB 的 HTTPS 监听器可能不更新需要先移除旧注解并删除 https 端口再通过istioctl install重建IP 白名单通过api_load_balancer_cidr_white_list与operator_load_balancer_cidr_white_list限制源 IP 段对应负载均衡器的loadBalancerSourceRanges负载均衡器可见性管理负载均衡器可配置为internal内网进一步提升控制面安全性。可观测性CloudWatch 日志 Prometheus 指标 Grafana 仪表盘日志FluentBit → CloudWatch集群内所有日志通过FluentBit以 DaemonSet 形式每节点一个 Pod采集并推送到一个CloudWatch 日志组。在 manager/manifests/fluent-bit.yaml.j2 中可以看到完整的采集管道输入tail插件读取/var/log/containers/*.log即 Docker 容器标准输出过滤kubernetes过滤器合并 Kubernetes 元数据rewrite_tag把日志重打标签为k8s_container.namespace.pod.container随后通过modify/nest过滤器把message/msg统一为log字段、把嵌套的 Kubernetes labels 提升为cortex.labels并为事件类日志event-exporter容器做额外展平处理输出cloudwatch插件写入log_group_name {{ config[cluster_name] }}的日志组log_stream_prefix kube.auto_create_group true自动创建日志组。同时安装脚本还部署了 event-exporter.yaml把 Kubernetes 事件如驱逐、调度失败也纳入日志体系便于排查 Spot 回收与故障恢复。指标集群内 Prometheus集群内置一套Prometheus用于指标采集这些指标同时服务于可观测性展示和自动扩缩容决策两个目的。Prometheus 生态由 prometheus-operator.yaml、prometheus-kubelet-exporter.yaml、prometheus-node-exporter.yaml、prometheus-kube-state-metrics.yaml 以及 prometheus-statsd-exporter.yaml 等清单组成覆盖节点、Kubernetes 对象与应用多个层级。安装脚本还会通过 prometheus-additional-scrape-configs.yaml.j2 生成额外的抓取配置并存入 Secret供 Autoscaler 读取工作负载指标。可视化GrafanaGrafana用于查看和修改工作负载与实例使用情况的指标仪表盘。安装脚本的setup_grafana会加载按工作负载维度拆分的仪表盘grafana-dashboard-realtime.yaml、grafana-dashboard-async.yaml、grafana-dashboard-batch.yaml、grafana-dashboard-task.yaml以及集群级grafana-dashboard-cluster.yaml和节点级grafana-dashboard-nodes.yaml仪表盘开发模式还可通过环境变量启用控制平面仪表盘grafana-dashboard-control-plane.yaml。集群创建完成后如何部署工作负载集群成功创建后你可以使用CLI 或 Python Client部署不同类型的工作负载。客户端通过AWS 凭证完成对集群的认证CLI 管理请求经 Operator 负载均衡器到达集群控制面。CLI 的核心命令在 docs/clients/cli.md 中有完整说明常用的包括# 创建或更新 API配置文件默认名为 cortex.yaml cortex deploy [CONFIG_FILE] [flags] -e, --env string 环境environment名称 -f, --force 覆盖进行中的 API 更新 -y, --yes 跳过交互式确认 -o, --output string 输出格式pretty|json # 查看 API 或 Job 的信息 cortex get [API_NAME] [JOB_ID] [flags] -w, --watch 每 2 秒重复执行 -v, --verbose 展示额外信息仅 pretty 格式 # 查看 API 详情 cortex describe [API_NAME] [flags] # 查看工作负载日志 cortex logs API_NAME [JOB_ID] [flags]Python 客户端python/client/cortex/client.py提供与 CLI 对等的编程接口同样使用 AWS 凭证认证适合在 Python 脚本或 CI/CD 流水线中调用。原子调度单元与四种工作负载模型Cortex 以一组容器组成的 Pod 作为原子单元伸缩与复制都发生在 Pod 级别。但不同工作负载对 Pod 的编排与伸缩策略完全不同Cortex 因此提供了四种工作负载模型每种都有独立的专属文档Realtime同步响应按在途请求量伸缩Realtime API同步响应请求适合把无状态容器尤其是 ML 模型推理服务部署为可伸缩的微服务。部署时 Cortex 会初始化一个 worker Pod 池并为每个 Pod 附加一个proxy sidecar代理负责接收请求、必要时排队、在业务容器就绪后转发请求在途请求量由各 proxy 汇总发布Autoscaler 据此伸缩副本。关键能力包括避免冷启动、可缩容到零、滚动更新、A/B 测试与金丝雀发布以及从故障和 Spot 实例终止中自动恢复。详见 Realtime 文档。Async异步请求按队列长度伸缩Async API 面向提交后稍后取结果的异步负载如视频、音频、文档处理。部署时 Cortex 创建一条 SQS 队列、一组 Async Gateway worker 和一组 worker Pod每个 Pod 带dequeuer sidecar。请求到达时Async Gateway 把请求载荷存入 S3 → 把请求 ID 入队到 SQS FIFO 队列 → 立即向调用方返回请求 ID。dequeuer 从队列拉取请求 → 从 S3 下载载荷 → POST 给业务容器 → 完成后删除载荷并将响应保存于 S3保留 7 天。调用方通过GET async-api-endpoint/request_id查询状态与结果。worker 池按队列平均消息数伸缩可缩容到 0。详见 Async 文档。Batch分布式批量任务一次至少处理一次Batch API 运行分布式、容错的批处理任务适合把大任务拆给专用 worker 池如对一批图片做推理。提交作业后返回 Job ID 并异步触发 Batch Job先启动enqueuer把作业数据拆成批次推入 SQS FIFO 队列入队完成后初始化指定数量的 worker Pod各带 dequeuer sidecar逐批拉取处理队列清空后作业标记完成、worker 被终止、SQS 队列被删除。期间可通过GET查询 Job 状态与已完成/失败批次等指标。关键保证至少一次执行、失败批次进入死信队列、/on-job-complete钩子、自动恢复。详见 Batch 文档。TaskLambda 式容器执行Task API 提供Lambda 风格的按需容器执行适合通过 HTTP 触发训练等任务也可作为 airflow 等编排器的 task runner。提交 Task 后返回 Task ID 并异步执行Cortex 按 API 规格初始化一个 worker PodPod 运行完成后 Task 标记完成、Pod 被终止通过GET可查询 Task 状态。空闲时缩容到 0。详见 Task 文档。小结从 docs/overview.md 出发并结合仓库源码可以看到 Cortex 的架构是一条自洽的完整链路基础设施层EKS 集群 专用 VPC EC2 自动扩缩组节点池支持 GPU/Inferentia 与 Spot/预留实例降本弹性层Cluster Autoscaler 管节点、Cortex Autoscaler 管 Pod两级伸缩闭环网络层双负载均衡器分离业务流量与控制面管理流量支持 HTTPS 与 IP 白名单可观测层FluentBit→CloudWatch 日志、Prometheus 指标、Grafana 仪表盘应用层以 Pod 为原子单元Realtime/Async/Batch/Task 四种工作负载覆盖同步推理、异步处理、批处理与按需执行四类典型 ML 场景。对于在 AWS 上搭建生产级 ML 平台的工程师本文涉及的 manager/install.sh、manager/generate_eks.py 与manager/manifests/下的各类 J2 模板是理解集群内部实现的最佳起点而 docs/workloads/ 与 docs/clients/cli.md 则提供了日常部署与运维所需的完整命令与配置指引。赞分享后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载相关推荐Total.js集群部署指南多进程架构与负载均衡Total.js集群部署指南多进程架构与负载均衡 Total.js框架提供了强大的集群部署功能能够轻松实现多进程架构和负载均衡。对于需要处理高并发请求的No后端Geex高可用集群部署与负载均衡Geex高可用集群部署与负载均衡 引言为什么企业级应用需要高可用架构 在现代企业应用开发中高可用性High Availability不再是可选项而后端前端代码生成认证鉴权微服务MediaMTX集群部署负载均衡与高可用架构设计MediaMTX集群部署负载均衡与高可用架构设计 MediaMTX原rtsp simple server作为一款高性能实时媒体服务器支持RTSP、RTM音视频后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考