在AI平台中，采用微服务架构并部署在Kubernetes集群上，请说明如何设计服务高可用（如自动扩缩容、健康检查）、服务间通信（如gRPC、RESTful）、容器镜像安全（如扫描漏洞、签名），并举例说明如何通过K8s资源配额控制资源使用。
工业和信息化部电子第五研究所AI平台工程师（平台研发、模型优化及测评）难度：困难
答案
1) 【一句话结论】
在Kubernetes微服务架构中，通过Deployment+HorizontalPodAutoscaler实现自动扩缩容与高可用，服务间通信采用gRPC（高效）或RESTful（易用），容器镜像通过Trivy等工具扫描漏洞并签名，资源配额通过LimitRanger和Quota控制各服务资源使用，确保系统稳定与资源隔离。
2) 【原理/概念讲解】
- 服务高可用与自动扩缩容：K8s的Deployment管理Pod副本，HorizontalPodAutoscaler（HPA）根据CPU/自定义指标（如QPS）自动调整副本数。健康检查用Liveness Probe（重启故障Pod）和Readiness Probe（服务就绪时加入Service），例如HTTP请求检查API是否响应。
- 服务间通信：gRPC基于HTTP/2，支持双向流、流控，适合高并发；RESTful基于HTTP，简单易用，适合轻量级调用。gRPC通过服务发现（如Consul）或K8s Service实现负载均衡。
- 容器镜像安全：漏洞扫描用Trivy（静态扫描）或Clair（动态扫描），签名用Notary或Sigstore，确保镜像来源可信，防止漏洞引入。
- 资源配额控制：LimitRanger为每个Pod设置资源上限（CPU/内存），Quota为命名空间设置总资源上限，防止资源耗尽，保障系统稳定性。
3) 【对比与适用场景】
| 对比项 | 自动扩缩容（HPA） | 服务间通信（gRPC vs RESTful） | 容器镜像安全（扫描 vs 签名） |
|---|---|---|---|
| 定义 | 根据指标自动调整Pod副本数 | 服务间调用协议 | 镜像漏洞检测与来源验证 |
| 特性 | 动态调整，基于指标 | gRPC高效，RESTful易用 | 扫描漏洞，签名防篡改 |
| 使用场景 | 流量波动大的服务（如推荐系统） | 高并发实时通信（如模型推理） | 生产环境镜像分发，确保安全 |
| 注意点 | 指标选择（CPU/自定义）需合理 | gRPC需客户端/服务端编译，RESTful无此要求 | 扫描频率（如每日），签名链验证 |
4) 【示例】
- HPA配置（自动扩缩容）：
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ai-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ai-service minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - 健康检查（Readiness Probe）：
readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 10 - 镜像扫描（Trivy）：
trivy image docker.io/library/nginx:latest --exit-code 1 --output console - 资源配额（Quota）：
apiVersion: v1 kind: ResourceQuota metadata: name: ai-platform-quota spec: hard: requests.cpu: "100m" requests.memory: "1Gi" limits.cpu: "200m" limits.memory: "2Gi"
5) 【面试口播版答案】
“在K8s微服务架构中，服务高可用通过Deployment结合HorizontalPodAutoscaler实现自动扩缩容，比如根据CPU利用率动态调整Pod副本数，同时配置Liveness和Readiness Probe确保服务健康。服务间通信采用gRPC（高效）或RESTful（易用），gRPC适合高并发模型推理，RESTful适合轻量级调用。容器镜像安全方面，用Trivy扫描漏洞，用Notary签名确保来源可信。资源配额通过LimitRanger限制单个Pod资源，Quota控制命名空间总资源，防止资源耗尽。比如，AI服务部署时，HPA设置最小3副本，最大10副本，CPU利用率70%时扩容，Readiness Probe检查健康端点，镜像扫描通过Trivy确认无高危漏洞，资源配额限制每个PodCPU不超过200m，内存不超过2Gi，命名空间总CPU不超过100m，内存不超过1Gi，确保系统稳定且资源隔离。”
6) 【追问清单】
- 追问1：HPA的指标如何选择？比如是否用自定义指标（如QPS）？
回答：通常根据业务指标，如QPS或模型推理延迟，通过Prometheus采集数据，配置HPA的custom metric source。 - 追问2：gRPC和RESTful在K8s中的负载均衡策略有何不同？
回答：gRPC通过K8s Service的负载均衡（如Round Robin），而RESTful也可用Service，但gRPC支持更细粒度的流控，适合高并发场景。 - 追问3：容器镜像签名的流程是怎样的？如何验证？
回答：使用Sigstore或Notary，签名时包含时间戳和签名者，验证时检查签名链和哈希值，确保镜像未被篡改。 - 追问4：资源配额的粒度如何？比如是否按服务或Pod？
回答：LimitRanger作用于Pod，Quota作用于命名空间，可按服务分组设置配额，避免资源争用。 - 追问5：健康检查失败时，K8s如何处理？
回答：Readiness Probe失败时，Pod从Service中移除，客户端不再调用；Liveness Probe失败则重启Pod。
7) 【常见坑/雷区】
- 健康检查配置错误：Readiness Probe未正确检查服务端点，导致Pod启动后未就绪即加入Service，客户端请求失败。
- 镜像扫描频率不足：仅部署前扫描，未定期检查，新漏洞引入后未及时处理。
- 资源配额设置不当：Quota设置过高导致资源浪费，或过低导致服务无法扩展。
- gRPC服务发现问题：未配置服务发现，导致客户端无法找到服务实例，或负载均衡失效。
- HPA指标选择不当：用CPU利用率但业务对内存敏感，导致扩容后性能下降。