如果将投放系统迁移到云原生环境，如何设计容器化部署和K8s资源管理策略？

1) 【一句话结论】：将投放系统拆分为微服务，通过Docker容器化封装，结合Kubernetes的Deployment、Service、HPA等资源对象，实现资源按需分配、弹性伸缩和高可用，同时通过网络策略、健康检查等确保系统稳定。

2) 【原理/概念讲解】：
老师解释：容器化是轻量级、可移植的运行环境，Docker是典型代表，类比“集装箱”——每个容器包含应用及其依赖，隔离但共享宿主机内核，便于快速部署。K8s核心组件：

• Pod：K8s可调度基本单位，包含1个或多个容器（如投放系统的请求处理容器）。
• Deployment：管理Pod的控制器，负责创建、更新Pod副本，确保服务可用。
• Service：抽象Pod集合，提供稳定访问入口（如ClusterIP、NodePort），隐藏Pod动态变化。
• Ingress：入口网关，处理外部流量路由（如通过域名访问服务）。
• 资源配额：限制Pod CPU/内存使用，防止资源争抢（如请求处理容器请求100m CPU，限制500m）。
• HPA（Horizontal Pod Autoscaler）：根据CPU使用率等指标自动调整Pod副本数，实现弹性伸缩（如CPU利用率70%时扩容）。
• 健康检查：Liveness（检测服务是否存活，不健康则重启）、Readiness（检测服务是否可访问，不健康则从Service中剔除）。

3) 【对比与适用场景】：

对比维度	传统部署（物理机/虚拟机）	K8s容器化部署
定义	部署在物理服务器或虚拟机上的传统应用，通过操作系统隔离	基于容器技术的微服务部署，通过K8s集群管理
特性	资源固定，部署周期长，扩展性差	资源按需分配，快速部署，弹性伸缩
使用场景	需要强隔离、资源固定、扩展性要求低的传统系统	需要快速迭代、高可用、弹性伸缩的微服务系统
注意点	需手动配置资源，扩展困难，故障恢复慢	需配置资源配额、健康检查，网络策略配置复杂

4) 【示例】：
给出投放系统请求处理服务的Deployment配置（伪代码）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ad-request-handler
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ad-request-handler
  template:
    metadata:
      labels:
        app: ad-request-handler
    spec:
      containers:
      - name: ad-request-handler
        image: 360/ad-request-handler:1.0.0
        resources:
          requests:
            cpu: "100m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "1Gi"
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: ad-request-handler-svc
spec:
  selector:
    app: ad-request-handler
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP
---
# HPA示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ad-request-handler-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ad-request-handler
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

5) 【面试口播版答案】：
各位面试官好，关于投放系统迁移到云原生环境，我的设计思路是：首先将系统拆分为微服务（如请求处理、计算、存储等），每个服务用Docker容器封装，然后通过Kubernetes的Deployment管理服务副本，Service提供稳定访问入口，结合HPA根据CPU使用率自动扩缩容，同时配置资源配额防止资源争抢，健康检查确保服务可用。具体来说，比如请求处理服务，通过Deployment部署3个副本，每个容器请求100m CPU和256Mi内存，限制500m CPU和1Gi内存，HPA根据CPU利用率70%自动调整副本数，健康检查定期检测服务健康状态。这样既能保证系统高可用，又能弹性应对流量变化。

6) 【追问清单】：

• 问：如何处理状态fulfilled的服务（如数据库、缓存）？
  回答要点：为状态fulfilled服务配置持久化存储（如PersistentVolume/PersistentVolumeClaim），通过StatefulSet管理，确保数据不丢失和顺序性。
• 问：如何处理多区域部署？
  回答要点：使用K8s多区域集群（跨可用区部署），配置跨区域服务发现（如DNS联邦），结合Ingress控制器实现区域间流量路由，提升高可用性。
• 问：如何处理网络问题（如服务间通信延迟）？
  回答要点：配置网络策略（NetworkPolicy）限制访问，使用Service Mesh（如Istio）实现流量控制、故障恢复和可观察性，减少网络问题影响。
• 问：资源配额设置不合理会导致什么问题？
  回答要点：若配额过低，服务可能因资源不足被OOMKilled；若过高，会导致资源浪费和成本增加，影响其他服务。

7) 【常见坑/雷区】：

• 忽略状态fulfilled服务的持久化存储，导致数据丢失。
• 资源配额设置不合理，导致服务资源不足或浪费。
• 网络策略配置错误，导致服务间通信中断。
• 自动扩缩容阈值设置不当，导致频繁扩缩容或响应延迟。
• 忽略健康检查配置，导致不健康Pod仍提供服务，影响系统稳定性。