在Kubernetes集群中部署一个高可用服务，请说明如何配置服务发现、健康检查、自动扩缩容（HPA）以及如何实现无状态服务的高可用。

新凯来软件开发工程师难度：中等

答案

1) 【一句话结论】在Kubernetes中部署高可用服务，需通过Deployment管理无状态服务实例，结合Service实现服务发现，配置Liveness/Readiness探针保障健康，并使用HPA根据CPU等指标自动扩缩容，确保服务故障时能快速恢复且负载均衡。

2) 【原理/概念讲解】
服务发现：Kubernetes通过Service（如ClusterIP类型）为Pod提供稳定的网络标识，客户端通过Service名称解析到后端Pod的ClusterIP和端口，实现服务间通信（类比：公司的“部门电话总机”，客户端通过总机号码找到所有员工的电话，无需关心具体办公室）。
健康检查：通过Liveness和Readiness探针监控Pod状态。Liveness探针用于检测Pod是否应被重启（如内部死循环），若失败则K8s重启Pod；Readiness探针用于检测Pod是否准备好接收流量（如初始化完成），若失败则从Service端点移除（类比：“健康打卡”，Liveness是“是否需要叫醒（重启）”，Readiness是“是否可以接电话（接收流量）”）。
自动扩缩容（HPA）：基于指标（如CPU使用率）自动调整Deployment的副本数，负载增加时扩容提升吞吐量，负载减少时缩容节省资源（类比：“自动招聘”，根据业务繁忙程度增减员工数量）。
无状态服务：不依赖共享状态或配置，所有实例可独立运行，通过Deployment管理多个副本，一个实例故障不影响其他实例，客户端通过Service负载均衡到健康实例。

3) 【对比与适用场景】
健康检查探针对比：

探针类型	定义	特性	使用场景
Liveness	检测Pod是否应被重启	若失败，K8s重启Pod	防止Pod因内部错误（如死循环）导致服务不可用
Readiness	检测Pod是否准备好接收流量	若失败，从Service端点移除	确保流量只发送到健康实例，避免发送到未初始化完成的服务实例

HPA与手动扩容对比：

方式	定义	特性	适用场景
手动扩容	管理员手动调整Deployment副本数	需人工干预，响应慢	负载变化慢，或需要人工决策的场景
HPA	自动根据指标（如CPU）调整副本数	自动化，响应快，节省资源	负载波动大，需要快速适应的场景（如电商促销、直播）

4) 【示例】（以Nginx Web服务为例，YAML配置）：

Deployment（管理Pod副本）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.21
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /healthz
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

Service（服务发现）：

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP  # 内部服务发现，或NodePort/LoadBalancer（外部访问）

HPA（自动扩缩容）：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # CPU使用率超过70%时扩容

5) 【面试口播版答案】
在Kubernetes中部署高可用服务，核心是通过Deployment管理无状态服务实例，结合Service实现服务发现，配置Liveness/Readiness探针保障健康，并使用HPA根据CPU等指标自动扩缩容。具体来说，首先创建一个Deployment，定义多个Pod副本（如3个），每个Pod包含Liveness和Readiness探针（通过HTTP请求检查/healthz和/ready路径），确保只有健康实例接收流量。然后创建Service（如ClusterIP类型），客户端通过Service名称访问后端Pod。接着配置HPA，根据CPU使用率自动调整Deployment的副本数，当负载增加时增加副本提升吞吐量，负载减少时减少副本节省资源。这样，即使某个Pod故障，其他副本仍能提供服务，且负载会自动均衡，实现高可用。

6) 【追问清单】

问：为什么选择ClusterIP类型的Service？是否可以用NodePort或LoadBalancer？
回答要点：ClusterIP是默认类型，适合内部服务发现，无需额外配置负载均衡器；NodePort需要在每个Node上开放端口，适合需要从外部访问的场景；LoadBalancer需要云服务商的负载均衡器，成本较高，通常用于生产环境。
问：HPA的指标除了CPU，还可以用哪些？比如请求队列长度？
回答要点：HPA支持多种指标，如请求队列长度（用于高延迟场景，队列长度超过阈值时扩容）、自定义指标（如自定义监控指标），根据业务需求选择合适的指标。
问：无状态服务是否需要持久化存储？为什么？
回答要点：无状态服务不依赖共享状态，因此不需要持久化存储（如StatefulSet用于有状态服务，需要持久化存储）。如果业务需要状态，应使用StatefulSet，但题目中是无状态服务，所以不需要。
问：健康检查的Liveness和Readiness探针路径如何配置？比如是否需要访问应用内部路径？
回答要点：Liveness探针用于检测Pod是否应被重启，通常访问应用的健康检查路径（如/healthz），返回200表示健康；Readiness探针用于检测是否准备好接收流量，同样访问应用的健康检查路径，返回200表示准备就绪，否则表示未准备好。
问：如果HPA的指标设置不合理，比如目标CPU利用率设为50%，但实际负载很低，会导致什么问题？
回答要点：如果目标利用率过低，HPA会过早扩容，导致资源浪费；如果过高，可能扩容不及时，导致服务响应变慢。需要根据实际业务负载调整指标阈值，确保资源利用率合理。

7) 【常见坑/雷区】

健康检查探针配置错误：比如Liveness探针返回200但实际Pod已死循环，导致K8s无法检测到故障，应确保探针路径能正确反映Pod的健康状态。
HPA指标选择不当：比如用CPU利用率但业务是I/O密集型，导致扩容效果不佳，应选择与业务负载匹配的指标（如I/O等待时间、请求队列长度）。
Service类型选择错误：比如用ClusterIP但需要外部访问，导致无法从外部访问服务，应根据需求选择合适的Service类型（如NodePort或LoadBalancer）。
无状态服务误用持久化存储：比如为无状态服务配置持久化存储，导致资源浪费，应避免为无状态服务使用StatefulSet或持久化存储。
健康检查超时时间设置不合理：比如Liveness探针超时时间太短，导致正常Pod被误判为故障，应根据应用启动时间调整超时时间，避免频繁重启。