描述一次使用Kubernetes部署微服务的经验，请说明遇到的挑战（如资源调度、服务发现）以及解决方案，并举例说明如何通过K8s的配置（如Deployment、Service、Ingress）实现高可用。
信步科技研发难度：中等
答案
1) 【一句话结论】：通过Kubernetes的Deployment（资源限制+HPA动态扩缩容）、Service（云环境LoadBalancer实现外部负载均衡）和Ingress（统一外部路由）组合，解决了资源调度与高可用问题，确保微服务在流量波动下保持99.9%可用（基于实际监控数据支撑）。
2) 【原理/概念讲解】：老师口吻解释核心组件：
- Deployment：K8s中管理Pod副本的控制器，负责自动创建、更新和删除Pod，支持滚动更新，保证应用可用。核心是通过资源请求/限制避免Pod被系统驱逐，并支持HPA动态调整副本数。
- Service（LoadBalancer类型）：抽象服务，提供外部负载均衡。在云环境中（如AWS），自动创建外部负载均衡器（如ALB），为Pod提供稳定的外部IP，实现流量分发，确保高可用外部访问。
- Ingress：处理外部流量路由的控制器，支持路径、主机等规则。通过Ingress控制器（如Nginx）统一管理外部入口，根据配置的路径/主机将流量路由到后端服务，实现多服务统一入口。
3) 【对比与适用场景】：
| 组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Deployment | 管理Pod副本的控制器 | 支持滚动更新、回滚、暂停更新；可配置资源请求/限制 | 部署和更新应用，保持可用 | 需定义资源限制，避免Pod被驱逐；与HPA结合实现动态扩缩容 |
| Service（ClusterIP） | 内部服务发现 | 仅K8s内部访问，ClusterIP | 内部服务间通信 | 仅内部可用，无外部IP |
| Service（NodePort） | 外部端口映射 | 预留NodePort（30000-32767） | 需外部直接访问，简单场景 | 需手动配置端口，安全风险，负载均衡能力弱 |
| Service（LoadBalancer） | 云环境外部负载均衡 | 自动创建外部IP（如AWS ALB） | 需高可用外部访问 | 云环境专属，需付费，依赖云服务 |
| Ingress | 外部路由控制器 | 路径、主机、TLS等规则 | 多服务统一入口，外部访问 | 需Ingress控制器（如Nginx），配置路径映射 |
4) 【示例】：以电商订单服务为例，包含资源限制、HPA、Service、Ingress配置：
- Deployment（资源限制+HPA）：
apiVersion: apps/v1 kind: Deployment metadata: name: order-deployment spec: replicas: 3 selector: matchLabels: app: order template: metadata: labels: app: order spec: containers: - name: order image: order-service:1.0 ports: - containerPort: 8080 resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi" - apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: order-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: order-deployment minReplicas: 3 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU使用率>70%时扩容 - Service（LoadBalancer）：
apiVersion: v1 kind: Service metadata: name: order-service spec: selector: app: order ports: - protocol: TCP port: 8080 targetPort: 8080 type: LoadBalancer # 云环境自动创建外部IP（如AWS ALB） - Ingress（统一路由）：
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: order-ingress spec: rules: - host: order.example.com http: paths: - path: / pathType: Prefix backend: service: name: order-service port: number: 8080
5) 【面试口播版答案】：之前在公司负责一个电商订单微服务，用K8s部署。首先，用Deployment定义了3个副本，每个Pod的CPU请求100m，限制500m，内存128Mi到512Mi，这样资源调度时能避免被系统驱逐。服务发现用Service的LoadBalancer，云环境自动创建外部IP（比如AWS的ALB），所有请求通过ALB负载均衡到后端Pod。然后Ingress配置域名order.example.com，路径/，通过Nginx Ingress控制器。当流量从1万QPS涨到5万时，HPA检测到CPU使用率超过70%，自动把副本数从3扩到5，解决流量高峰问题。之前遇到流量高峰时Pod内存不足被驱逐，后来通过调整HPA的CPU阈值，并结合垂直Pod Autoscaler处理内存不足，确保服务保持99.9%可用，没有中断（基于实际监控数据，比如CPU使用率曲线显示扩容后稳定在60%以下，流量恢复后自动缩容，资源成本增加约15%，但服务可用性提升显著）。
6) 【追问清单】：
- 问：HPA的CPU阈值70%是如何确定的？最小/最大副本数设置依据是什么？
答：CPU阈值70%是基于历史流量数据，当CPU使用率超过70%时，说明资源不足，需要扩容。最小副本数3是基础可用性，最大10是考虑资源成本和性能，结合业务峰值流量（5万QPS）计算得出。 - 问：Service的LoadBalancer和NodePort有什么区别？为什么选择LoadBalancer？
答：LoadBalancer在云环境自动创建外部IP（如AWS ALB），提供高可用外部负载均衡；NodePort需要手动配置端口（30000-32767），负载均衡能力弱。我们选择LoadBalancer因为需要高可用外部访问，且流量较大。 - 问：如何处理内存不足导致的Pod驱逐？具体方案是什么？
答：除了HPA动态扩容CPU，还配置了垂直Pod Autoscaler（VPA），根据实际内存使用率动态调整Pod的内存限制，避免内存不足被驱逐。比如VPA将内存限制从512Mi调整到768Mi，当内存使用率超过80%时自动扩容。 - 问：Ingress的高可用如何实现？比如多个Ingress控制器实例？
答：通过部署多个Nginx Ingress Controller实例（如3个副本），并配置LVS或HAProxy作为负载均衡器，实现流量分发，避免单点故障。同时，Ingress资源本身支持多个控制器，提高可用性。 - 问：资源成本方面，扩容后增加了多少资源？是否考虑了成本与性能的平衡？
答：扩容后CPU资源增加约15%（从3副本到5副本），内存资源增加约20%，成本增加约12%。通过监控流量变化，仅在高峰期扩容，非高峰期缩容，平衡了成本与性能。
7) 【常见坑/雷区】：
- 雷区1：Service类型设置为ClusterIP但需要外部访问，导致无法通过外部IP访问，应改为LoadBalancer。
- 雷区2：HPA配置不当，比如CPU阈值设置过高（如90%），导致扩容延迟，流量高峰时服务不可用，应合理设置阈值（如70%）。
- 雷区3：Ingress路径匹配错误，比如路径为/时，实际请求路径为/api，导致流量无法到达服务，需正确配置pathType和路径。
- 雷区4：未配置资源请求/限制，导致Pod被系统驱逐，影响服务可用性。
- 雷区5：未考虑内存调度，导致流量高峰时内存不足被驱逐，应结合HPA和VPA处理内存问题。