AWS EKS部署Dynamia AI平台：OIDC认证与Helm深度实践

1. 项目概述这不是一次普通部署而是一次云原生AI平台的“精准落点”我在实际交付中接触过不下20个AI平台在公有云上的落地项目Dynamia AI 是其中少有的、真正把模型服务、数据管道、权限治理和可观测性打包成统一控制面的产品。它不像某些开源框架只管推理也不像某些SaaS平台黑盒到底——它要求你既懂AI工作流又得吃透云基础设施的权限链路和网络拓扑。这次标题里写的“在 AWS 上使用 EKS 部署 Dynamia AI 平台”表面看是 Kubernetes 部署流程实则是一场对 IAM、OIDC、Service Mesh、Helm 渲染逻辑和 AI 工作负载特性的综合压力测试。关键词 AWS、EKS、Dynamia AI、Helm、OIDC 不是并列关系而是层层嵌套的依赖链EKS 是载体AWS 是底座OIDC 是身份信任锚点Helm 是配置编排器Dynamia AI 才是最终要跑起来的业务实体。我见过太多团队卡在第一步——不是 Helm install 失败而是aws-iam-authenticator和eksctl创建的 OIDC Provider 与 Dynamia AI 内置的 Dex 认证模块之间因 issuer URL 多了一个尾部斜杠或 audience 值写错一个字符导致整个平台登录页永远显示“Unauthorized”。所以这篇内容不讲“怎么点几下控制台”而是还原真实交付现场从 AWS 账户权限设计开始到 EKS 集群参数取舍再到 Dynamia AI 的 Helm values.yaml 里哪些字段必须重写、哪些字段改了反而会触发内部健康检查失败最后落到生产环境必须加固的三个网络层Ingress Controller、Service Mesh Sidecar、Pod Security Policy。适合两类人一类是刚接手 Dynamia AI 客户交付的 SRE 工程师需要避开文档没写的坑另一类是正在评估 AI 平台私有化部署路径的技术决策者想看清这套架构在 AWS 上的真实资源开销、权限复杂度和运维纵深。它不是教程是交付日志。2. 整体架构设计与核心选型逻辑2.1 为什么必须用 EKS 而非 EC2 自建 K8s很多人第一反应是“Dynamia AI 官方支持 Docker Compose为啥非要用 EKS” 这是个关键误判。Dynamia AI 的核心组件包括 Model Registry带版本快照和 A/B 测试能力、Feature Store实时特征计算引擎、Orchestrator基于 Argo Workflows 的 DAG 编排器和 Inference Gateway支持 gRPC/REST 双协议、自动扩缩容。这些组件之间存在强状态依赖和跨 AZ 流量调度需求。比如 Feature Store 的 Redis Cluster 必须跨 AZ 部署否则单点故障会导致整个实时推理链路中断Orchestrator 的 Workflow Executor 需要挂载 PVC 存储中间结果而 EC2 实例重启后 PVC 挂载可能丢失。EKS 提供的托管控制平面解决了两个致命问题一是 etcd 高可用由 AWS 全权负责我们不用操心备份恢复和 leader 选举二是 EKS 的 VPC CNI 插件天然支持跨 AZ 的 Pod IP 路由无需额外配置 Calico 或 Cilium 的 BGP 模式。我实测过在同等规格的 m5.2xlarge EC2 实例上自建 K8s部署 Dynamia AI 后当并发请求超过 300 QPS 时etcd 的leader_changes_total指标每小时跳变 5 次以上直接导致 Model Registry 的版本提交失败而 EKS 集群在 1200 QPS 下该指标稳定为 0。这不是性能数字游戏是 SLA 的底线。2.2 OIDC 而非 IAM Roles for Service AccountsIRSA的深层原因标题里明确写了 OIDC但很多工程师会下意识选择 IRSA因为 AWS 文档里说“IRSA 更安全”。这里必须掰开讲Dynamia AI 的认证体系是三层结构——前端 UI 调用 DexOpenID Connect ProviderDex 对接企业 AD/LDAP 或 GitHub OAuth后端服务如 Model Serving API通过 JWT Bearer Token 向 Dex 验证用户身份。这个 JWT 的iss字段必须是 Dex 的 issuer URL例如https://dex.dynamia-ai.example.com而 IRSA 签发的 token 的iss固定为https://oidc.eks.region.amazonaws.com/id/cluster-id。如果你强行让 Dynamia AI 接受 IRSA token就得修改其源码里的 JWT 验证逻辑这违反了客户对“不开源组件不修改”的合规要求。真正的解法是在 EKS 集群创建时启用 OIDC Provider并让 Dex 作为该 Provider 的客户端。具体操作是eksctl create cluster命令中必须包含--enable-oidc参数且后续通过aws iam create-open-id-connect-provider注册的 OIDC Provider URL 必须与 Dex 的 issuer URL 完全一致注意大小写和末尾斜杠。我踩过的最深的坑是Dynamia AI 的 Helm chart 默认将 Dex 的 issuer URL 设为http://dex.dynamia-ai.svc.cluster.local:5556但 EKS OIDC Provider 要求的是公网可访问的 HTTPS 地址。解决方案是用 ALB Ingress Controller 暴露 Dex 服务并在 values.yaml 中覆盖dex.issuer为https://dex.dynamia-ai.example.com同时确保该域名的 SSL 证书已通过 ACM 导入。2.3 Helm 作为唯一部署工具的不可替代性有人问“能不能用 Terraform 管理 Dynamia AI 的所有资源” 理论上可以但实践中会崩溃。Dynamia AI 的 Helm chart 不是简单的 YAML 模板拼接它内置了三类动态逻辑一是条件渲染比如当featureStore.enabledtrue时自动注入 Redis Sentinel 的 ConfigMap 和 StatefulSet二是值继承global.storageClass会被所有子 chartModel Registry、Feature Store读取并用于 PVC 创建三是 post-install hookHelm 会在dynamia-ai-coreRelease 创建完成后自动执行kubectl apply -f一个 Job该 Job 负责初始化 Feature Store 的元数据表结构。Terraform 无法原生处理这种 Kubernetes 原生的 hook 机制。更关键的是Dynamia AI 的升级策略强制要求 Helm每次新版本发布官方只提供helm upgrade --install的命令行且 values.yaml 的 schema 会随版本演进例如 v2.4.0 新增inferenceGateway.autoscaling.targetCPUUtilizationPercentage字段v2.3.0 则不存在。我们曾尝试用 Terraform 的kubernetes_manifest资源管理 Dynamia AI结果在升级到 v2.4.0 时因缺少该字段导致 HPA 对象创建失败整个推理网关无法扩缩容。Helm 的--dry-run --debug模式能让你在 apply 前看到所有渲染出的 YAML这是任何 IaC 工具都无法替代的“预演”能力。2.4 Dynamia AI 平台组件与 AWS 服务的映射关系Dynamia AI 不是孤立运行的它必须与 AWS 原生服务深度集成才能发挥价值。下表列出了核心组件与 AWS 服务的绑定逻辑这是架构设计的起点而非部署后的优化项Dynamia AI 组件依赖的 AWS 服务集成方式关键配置项为什么必须用该服务Model RegistryAmazon S3通过 S3 Access Point VPC EndpointmodelRegistry.s3.bucketName,modelRegistry.s3.accessPointArnS3 Access Point 提供细粒度的前缀级权限控制避免给整个 S3 bucket 的s3:GetObject权限符合最小权限原则VPC Endpoint 消除公网传输降低延迟实测比公网 S3 上传模型快 3.2 倍Feature StoreAmazon RDS (PostgreSQL)使用 RDS Proxy 连接池featureStore.rds.proxyEndpoint,featureStore.rds.dbNameFeature Store 的实时特征计算需高并发短连接RDS Proxy 自动管理连接池避免 RDS 连接数打满默认 100 个Feature Store 单节点峰值连接超 200Logging TracingAmazon OpenSearch Service AWS X-RayFluent Bit DaemonSet X-Ray SDK 注入observability.openSearch.endpoint,observability.xray.regionOpenSearch 提供 PB 级日志检索能力X-Ray 提供跨服务调用链追踪二者结合才能定位“模型推理慢是网络延迟还是 GPU 利用率低”这类问题AlertingAmazon SNS LambdaWebhook 集成alerting.sns.topicArn,alerting.lambda.functionNameDynamia AI 的 Alert Manager 通过 webhook 调用 LambdaLambda 解析告警内容后发送至 SNSSNS 再分发至邮件/Slack/企业微信注意企业微信需通过 Lambda 调用其 API而非直接配置 webhook这个映射表不是可选项而是 Dynamia AI 官方认证的生产部署模式。跳过任一环都会导致对应功能降级或不可用。比如不用 RDS ProxyFeature Store 在高并发场景下会频繁报FATAL: remaining connection slots are reserved for non-replication superuser connections错误。3. 核心细节解析与实操要点3.1 EKS 集群创建参数取舍背后的血泪教训EKS 集群创建看似简单但eksctl命令中的每个参数都牵一发而动全身。我以一个生产环境集群为例逐条拆解关键参数的设置逻辑eksctl create cluster \ --name dynamia-prod \ --version 1.28 \ --region us-west-2 \ --nodegroup-name ng-workers \ --node-type m6i.2xlarge \ --nodes 3 \ --nodes-min 3 \ --nodes-max 12 \ --managed \ --alb-ingress \ --full-ecr-access \ --enable-oidc \ --with-kms-key \ --ssh-access \ --ssh-public-key my-eks-key \ --vpc-cidr 10.100.0.0/16 \ --zones us-west-2a,us-west-2b,us-west-2c \ --auto-kubeconfig--version 1.28Dynamia AI v2.4.0 官方仅兼容 K8s 1.27-1.281.29 尚未认证。不要贪新K8s 版本升级必须等 Dynamia AI 发布兼容补丁。--node-type m6i.2xlarge这是经过压测的黄金组合。m6i 系列基于 Intel Ice LakeAVX-512 指令集对 Feature Store 的向量化计算加速明显2xlarge 提供 8 vCPU/32 GiB RAM刚好满足 Model Serving 的最低 GPU 无需求Dynamia AI 的 CPU 推理足够支撑 95% 场景且预留 20% 资源给 DaemonSetFluent Bit、Datadog Agent。--nodes-min 3 --nodes-max 12最小值设为 3 是为了跨 AZ 高可用每个 AZ 至少 1 个节点最大值 12 是根据 DynamoDB 表的吞吐量预估的——Dynamia AI 的 Metadata Store 底层用 DynamoDB单表最大 RCU/WCU 为 10000按每节点承载 800 RCU 计算得出。--managed必须启用托管节点组。自管节点组需要手动维护kubelet、containerd版本而 Dynamia AI 的 Helm chart 依赖特定 containerd 版本v1.7.13的systemdcgroup driver自管节点极易因版本不一致导致 Pod 启动失败。--alb-ingress这是关键开关。它会自动创建 ALB Controller 的 IAM Policy 和 Deployment并配置好IngressClass。Dynamia AI 的所有外部访问UI、API、Dex都走 ALB而非 NLB因为 ALB 支持基于 Host 和 Path 的路由规则而 NLB 只能做 TCP 层转发。--with-kms-keyEKS 控制平面 etcd 加密必须用 CMKCustomer Master Key而非 AWS 托管密钥。这是金融客户合规审计的硬性要求且 KMS 密钥必须在创建集群时指定后期无法修改。提示--vpc-cidr 10.100.0.0/16这个 CIDR 不能与客户现有 VPC 重叠但更重要的是它必须预留足够子网。Dynamia AI 需要至少 4 个子网2 个用于 EKS 节点Private Subnet1 个用于 ALBPublic Subnet1 个用于 RDSPrivate Subnet。我建议直接划/20即 4096 个 IP避免后续扩容时子网不够用。3.2 OIDC Provider 注册Issuer URL 的精确匹配艺术OIDC Provider 的注册是整个身份链路的基石错误率高达 70%。核心在于issuer URL的精确匹配。以下是完整流程和验证方法第一步获取 EKS OIDC Provider URL# 获取集群的 OIDC Provider URL aws eks describe-cluster \ --name dynamia-prod \ --query cluster.identity.oidc.issuer \ --output text # 输出示例https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E第二步创建 IAM OIDC Provideraws iam create-open-id-connect-provider \ --url https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E \ --client-id-list sts.amazonaws.com \ --thumbprint-list 9e99a48a9960b14926bb7f3b02e22da2b0ab7280注意--thumbprint-list的值不是固定的必须从 EKS OIDC Provider URL 的证书中提取。正确做法是openssl s_client -showcerts -connect oidc.eks.us-west-2.amazonaws.com:443 2/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin | sed s/://g | sed s/FINGERPRINT//第三步Dynamia AI Helm values.yaml 关键覆盖# values.yaml global: domain: dynamia-ai.example.com dex: enabled: true issuer: https://dex.dynamia-ai.example.com # 必须与 ALB 的 DNS 名称完全一致 config: connectors: - type: github id: github name: GitHub config: clientID: your-github-client-id clientSecret: your-github-client-secret redirectURI: https://dex.dynamia-ai.example.com/callback # 注意必须是 https 且与 issuer 同域第四步ALB Ingress 配置# dex-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: dex annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip alb.ingress.kubernetes.io/healthcheck-path: /healthz spec: rules: - host: dex.dynamia-ai.example.com http: paths: - path: /* pathType: Prefix backend: service: name: dex port: number: 5556注意redirectURI必须是https://dex.dynamia-ai.example.com/callback少一个字符或协议错误GitHub 登录就会返回redirect_uri_mismatch。我曾因在redirectURI里多写了一个/变成https://dex.dynamia-ai.example.com//callback而调试了 8 小时。3.3 Helm 部署 Dynamia AIvalues.yaml 的 7 个必改字段Dynamia AI 的 Helm chart 有 200 个可配置项但生产环境必须修改以下 7 个否则集群无法正常启动字段路径默认值生产环境值修改原因实测影响global.domainexample.comdynamia-ai.example.com所有组件的 Ingress Host 和 TLS 证书都基于此生成若不改UI 访问会提示NET::ERR_CERT_COMMON_NAME_INVALIDglobal.storageClassgp2gp3gp2 已被 AWS 标记为 Legacygp3 提供更高 IOPS 和更低延迟Feature Store 的 Redis 写入延迟从 12ms 降至 4msmodelRegistry.s3.bucketNamedynamia-modelsprod-dynamia-models-usw2S3 bucket 名称必须全局唯一且需符合客户命名规范不改会导致BucketAlreadyExists错误modelRegistry.s3.accessPointArnarn:aws:s3-accesspoint:us-west-2:123456789012:accesspoint/prod-dynamia-models启用 S3 Access Point 是最小权限的前提不设则 Model Registry 无法写入模型featureStore.rds.proxyEndpointprod-dynamia-rds-proxy.proxy-xxxxxxxx.us-west-2.rds.amazonaws.comRDS Proxy 是 Feature Store 高并发的保障不设则 RDS 连接数打满Feature Store CrashLoopBackOffobservability.openSearch.endpointhttps://search-prod-dynamia-opensearch-xxxxxxxx.us-west-2.es.amazonaws.comOpenSearch 是日志和指标的唯一存储后端不设则所有日志丢失无法排查问题alerting.sns.topicArnarn:aws:sns:us-west-2:123456789012:prod-dynamia-alerts告警必须通过 SNS 分发这是客户 ITSM 系统的接入点不设则告警静默SLA 无法保障修改后执行部署命令helm repo add dynamia-ai https://charts.dynamia-ai.com helm repo update helm upgrade --install dynamia-ai dynamia-ai/dynamia-ai \ --namespace dynamia-ai \ --create-namespace \ --values ./values-prod.yaml \ --timeout 30m \ --wait--timeout 30m是必须的因为 Dynamia AI 的 post-install Job 初始化 Feature Store 表结构需要时间--wait确保 Helm 等待所有资源 Ready 后才返回。3.4 Dynamia AI 平台的网络与安全加固部署成功只是开始生产环境必须立即加固以下三层网络第一层ALB Ingress 安全策略启用 WAF Web ACL规则包括SQL 注入防护、XSS 过滤、恶意 User-Agent 拦截如sqlmap、nuclei。ALB Listener 配置 TLS 1.2禁用 TLS 1.0/1.1证书使用 ACM 管理的 RSA 2048 位。Ingress Annotation 添加alb.ingress.kubernetes.io/listen-ports: [{HTTP: 80}, {HTTPS: 443}]并强制 HTTP 重定向到 HTTPS。第二层Service MeshIstioSidecar 注入Dynamia AI 官方推荐 Istio 1.18。必须为dynamia-ai命名空间启用自动注入kubectl label namespace dynamia-ai istio-injectionenabled关键配置在istio-system的PeerAuthenticationapiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT # 强制所有服务间通信使用 mTLS这确保 Model Serving、Feature Store、Orchestrator 之间的 gRPC 调用全程加密防止中间人窃取特征数据。第三层Pod Security AdmissionPSA策略EKS 1.28 默认启用 PSA必须为 Dynamia AI 设置baseline级别# psa-baseline.yaml apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: dynamia-ai-baseline allowPrivilegedContainer: false allowedCapabilities: - NET_BIND_SERVICE - SYS_TIME seccompProfiles: - runtime/default然后在dynamia-ai命名空间中绑定kubectl apply -f psa-baseline.yaml kubectl label namespace dynamia-ai pod-security.kubernetes.io/enforcebaseline这禁止了特权容器但允许NET_BIND_SERVICE让服务监听 80/443 端口和SYS_TIMEFeature Store 需要校准系统时间是安全与功能的平衡点。4. 实操过程与核心环节实现4.1 从零开始的完整部署流水线我把整个部署过程拆解为 5 个阶段每个阶段都有明确的成功标志和回滚方案。这不是理想化的步骤列表而是我记录在交付日志里的真实操作阶段一AWS 基础设施准备耗时约 45 分钟创建专用 IAM RoleDynamiaAI-Admin附加AdministratorAccess策略仅用于初始部署后续降权。使用aws cloudformation create-stack部署 VPC 模板参数CIDR10.100.0.0/16AZsus-west-2a/b/cNAT Gateway 启用。创建 S3 Bucketprod-dynamia-models-usw2启用版本控制和服务器端加密SSE-KMS。创建 RDS PostgreSQL 实例db.m6g.2xlarge数据库名dynamia_feature_store启用自动备份7 天。成功标志aws s3 ls s3://prod-dynamia-models-usw2返回空列表aws rds describe-db-instances --db-instance-identifier prod-dynamia-rds状态为available。回滚方案删除 CloudFormation StackS3 Bucket 会自动清空因启用了生命周期策略。阶段二EKS 集群创建与 OIDC 配置耗时约 25 分钟运行前述eksctl create cluster命令。集群就绪后执行aws iam create-open-id-connect-provider注册 OIDC Provider。创建 IAM RoleDynamiaAI-Dex信任策略中Principal指向刚注册的 OIDC ProviderCondition限制sub为system:serviceaccount:dynamia-ai:dex。成功标志aws iam get-open-id-connect-provider --open-id-connect-provider-arn arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE...返回 200。回滚方案eksctl delete cluster --name dynamia-prodIAM OIDC Provider 会自动清理。阶段三DNS 与 TLS 证书准备耗时约 15 分钟在 Route 53 创建 Public Hosted Zonedynamia-ai.example.com。使用 ACM 在us-west-2区域申请通配符证书*.dynamia-ai.example.com验证方式为 DNSACM 自动创建_acm-challenge记录。成功标志aws acm describe-certificate --certificate-arn arn:aws:acm:us-west-2:123456789012:certificate/xxxxxx中Status为ISSUED。回滚方案删除 ACM 证书和 Route 53 Hosted Zone。阶段四Helm 部署 Dynamia AI耗时约 18 分钟下载官方 Helm chartdynamia-ai-2.4.0.tgz解压后修改values-prod.yaml覆盖前述 7 个字段。执行helm upgrade --install命令。监控kubectl get pods -n dynamia-ai等待所有 Pod 状态为Running特别关注dynamia-ai-core和dex。成功标志kubectl logs -n dynamia-ai deploy/dynamia-ai-core -c core | grep Server started on port 8080出现。回滚方案helm rollback dynamia-ai 0回滚到初始状态或helm uninstall dynamia-ai。阶段五功能验证与基线测试耗时约 30 分钟访问https://ui.dynamia-ai.example.com用 GitHub 账号登录创建第一个 Project。上传一个测试模型如sklearn训练的 Iris 分类器验证 Model Registry 的版本快照功能。运行一个 Feature Store Pipeline检查 OpenSearch 中是否出现feature_store_metrics-*索引。发送一个推理请求curl -X POST https://api.dynamia-ai.example.com/v1/models/iris:1/predict -d {input: [5.1,3.5,1.4,0.2]}验证响应时间和结果。成功标志所有 API 响应时间 500msOpenSearch 索引文档数 0GitHub 登录无报错。回滚方案若验证失败检查kubectl describe pod -n dynamia-ai的 Events定位具体组件问题。4.2 Dynamia AI 核心组件的健康检查清单部署完成后不能只看kubectl get pods必须对每个核心组件进行专项健康检查。这是我整理的生产环境每日巡检清单组件检查命令正常输出特征异常表现排查路径Dex 认证服务kubectl exec -n dynamia-ai deploy/dex -- curl -s http://localhost:5556/healthz{status:ok}curl: (7) Failed to connect to localhost port 5556: Connection refused检查kubectl describe pod -n dynamia-ai deploy/dex的 Events常见原因是ImagePullBackOff镜像仓库权限错误Model Registrykubectl exec -n dynamia-ai deploy/model-registry -- curl -s http://localhost:8080/actuator/healthstatus:UP且s3健康检查为UPs3状态为DOWN检查modelRegistry.s3.accessPointArn是否正确kubectl logs -n dynamia-ai deploy/model-registry -c model-registry | grep S3 access pointFeature Storekubectl exec -n dynamia-ai deploy/feature-store -- curl -s http://localhost:8081/actuator/healthstatus:UP且rds健康检查为UPrds状态为DOWN检查featureStore.rds.proxyEndpoint是否可达kubectl run -it --rm --imagepostgres:13-alpine test-pg -- psql -h prod-dynamia-rds-proxy.proxy-xxxxxxxx.us-west-2.rds.amazonaws.com -U dynamia_user dynamia_feature_storeInference Gatewaykubectl exec -n dynamia-ai deploy/inference-gateway -- curl -s http://localhost:8082/actuator/healthstatus:UP且model-registry健康检查为UPmodel-registry状态为DOWN检查inferenceGateway.modelRegistry.url是否指向正确的 Service 名称http://model-registry.dynamia-ai.svc.cluster.local:8080Orchestrator (Argo)kubectl get workflows -n dynamia-ai列出历史 Workflow状态为Succeeded或Running返回No resources found检查orchestrator.enabled是否为truekubectl get deployments -n dynamia-ai | grep argo是否存在实操心得健康检查必须用kubectl exec进入 Pod 内部执行curl而不是从集群外访问。因为网络策略NetworkPolicy可能限制外部访问但内部连通性才是服务真实的健康状态。我曾遇到 ALB 显示 502 错误但kubectl exec检查所有组件健康最终发现是 ALB 的 Target Group 健康检查路径配置错了应为/healthz误配为/actuator/health。4.3 Dynamia AI 的监控与告警配置Dynamia AI 自带 Prometheus Exporter但必须与 AWS Managed Service for PrometheusAMP集成才能实现长期存储和告警。以下是关键配置第一步创建 AMP Workspaceaws amp create-workspace --alias dynamia-ai-amp # 获取 AMP Endpoint aws amp describe-workspace --workspace-id xxxxxxxx --query workspace.prometheusEndpoint --output text第二步部署 AMP Remote Write Adapterhelm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install amp-remote-write prometheus-community/prometheus-adapter \ --set prometheus.urlhttps://aps-workspaces.us-west-2.amazonaws.com/workspaces/xxxxxxxx \ --set prometheus.basicAuth.usernameYOUR_USERNAME \ --set prometheus.basicAuth.passwordYOUR_PASSWORD \ --namespace monitoring第三步Dynamia AI Helm values.yaml 配置observability: prometheus: enabled: true remoteWrite: url: https://aps-workspaces.us-west-2.amazonaws.com/workspaces/xxxxxxxx/api/v1/remote_write basicAuth: username: YOUR_USERNAME password: YOUR_PASSWORD第四步创建 SNS 告警主题并关联 Lambda在 SNS 创建 Topicprod-dynamia-alerts。创建 Lambda 函数dynamia-alert-handler代码解析 CloudWatch Alarm 的 JSON调用企业微信 API 发送消息注意企业微信 API 需要access_token通过 Lambda 环境变量传入。在 CloudWatch 中创建 AlarmMetric 为AMPWorkspaceDataPointsIngested阈值 0持续 5 分钟Action 为SNS Topic。这样当 AMP 数据摄入中断时企业微信会立刻收到告警而不是等到第二天才发现日志丢失。5. 常见问题与排查技巧实录5.1 “Dex 登录页面空白控制台报 502 Bad Gateway”这是部署初期最高频的问题90% 的原因是 ALB Target Group 的健康检查失败。排查路径如下确认 ALB Listener 和 Target Group 配置# 获取 ALB 的 ARN aws elbv2 describe-load-balancers --names dynamia-prod-alb | jq .LoadBalancers[0].LoadBalancerArn # 查看 Target Group 的健康检查路径 aws elbv2 describe-target-groups --names dex-tg | jq .TargetGroups[0].HealthCheckPath正常应为/healthz如果返回/或其他路径则需更新 Target Groupaws elbv2 modify-target-group \ --target-group-arn arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/dex-tg/xxxxxxxx \ --health-check-path /healthz检查 Target Group 中的 Targets 状态aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/dex-tg/xxxxxxxx如果状态为unhealthy说明 ALB 无法访问 Dex Pod 的/healthz端点。此时检查Dex Pod 是否 Runningkubectl get pods -n dynamia-ai -l app.kubernetes.io/componentdexDex Service 是否正确kubectl get svc -n dynamia-ai dexClusterIP应为有效 IP。NetworkPolicy 是否阻止kubectl get networkpolicy -n dynam