在万兴的云服务中，如何使用Kubernetes部署一个视频处理微服务（如视频转码服务），需要考虑服务发现、负载均衡（如Ingress）、自动扩缩容（HPA）、持久化存储（如PV/PVC）等。
答案
1) 【一句话结论】
通过Kubernetes的Deployment（管理Pod）、Service（服务发现与负载均衡）、Ingress（外部请求入口）、HPA（自动扩缩容）及PV/PVC（持久化存储）等组件协同，实现视频处理微服务的自动化部署、服务发现、负载均衡、自动扩缩容及持久化存储。
2) 【原理/概念讲解】
老师口吻解释各核心组件的作用与关系：
- Deployment：作为Pod的模板和副本管理器，像“班级排班表”，控制Pod的数量、更新策略（如滚动更新），确保服务稳定。
- Service：实现服务发现与负载均衡的入口，像“教室座位分配”，让集群内服务能通过IP/端口找到彼此（ClusterIP为内部服务，NodePort/LoadBalancer用于外部访问）。
- Ingress：作为集群的“总入口”，处理外部请求并路由到后端Service，像“学校总大门”，支持路径、主机等规则匹配。
- HPA（Horizontal Pod Autoscaler）：根据资源利用率（如CPU）自动调整Pod副本数，像“自动调整班级人数”，应对负载变化（如CPU利用率超阈值时扩容）。
- PV/PVC：管理持久化存储，像“教室储物柜”，确保视频文件等数据不因Pod重启丢失（PV为存储资源，PVC为Pod的存储请求，绑定后实现数据持久化）。
3) 【对比与适用场景】
以Service类型为例（核心服务发现与负载均衡组件）：
| 服务类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| ClusterIP | 集群内部IP | 仅集群内访问 | 微服务间通信（内部调用） | 需配合Ingress或NodePort暴露外部 |
| NodePort | Node的固定端口 | 集群内+外部访问 | 测试或临时访问（如开发环境） | 端口占用，可能冲突 |
| LoadBalancer | 云服务商的负载均衡器 | 外部访问 | 生产环境（高可用） | 依赖云服务商，成本较高 |
4) 【示例】
以视频转码服务为例，给出最小可运行部署文件（伪代码+关键配置）：
-
Deployment（管理Pod）：
apiVersion: apps/v1 kind: Deployment metadata: name: video-transcoder spec: replicas: 3 selector: matchLabels: app: video-transcoder template: metadata: labels: app: video-transcoder spec: containers: - name: transcoder image: mycompany/video-transcoder:latest ports: - containerPort: 8080 resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi" livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 periodSeconds: 10 -
Service（服务发现与负载均衡）：
apiVersion: v1 kind: Service metadata: name: transcoder-svc spec: selector: app: video-transcoder ports: - protocol: TCP port: 80 targetPort: 8080 type: ClusterIP # 内部服务发现，配合Ingress暴露 -
Ingress（外部请求入口）：
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: transcoder-ingress spec: rules: - host: transcoder.video.example.com http: paths: - path: / pathType: Prefix backend: service: name: transcoder-svc port: number: 80 -
HPA（自动扩缩容）：
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: transcoder-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: video-transcoder minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU利用率超70%时扩容 -
PV/PVC（持久化存储）：
# PersistentVolume（存储资源，假设云服务商提供） apiVersion: v1 kind: PersistentVolume metadata: name: video-pv spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: /data/video-storage # PersistentVolumeClaim（Pod的存储请求） apiVersion: v1 kind: PersistentVolumeClaim metadata: name: video-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi selector: matchLabels: app: video-transcoder
5) 【面试口播版答案】
（约90秒，自然表达）
“在万兴的云服务中部署视频转码微服务，核心是通过Kubernetes的组件协同实现自动化运维。首先，用Deployment定义视频转码容器，设置3个副本和资源限制（CPU/内存），确保服务稳定；然后创建ClusterIP类型的Service，让内部服务能通过IP找到彼此；接着配置Ingress，将外部请求（如域名transcoder.video.example.com）路由到Service，方便用户访问；再设置HPA，根据CPU利用率自动调整副本数，比如当CPU使用率超过70%时增加副本，应对负载高峰；最后用PersistentVolumeClaim绑定PersistentVolume，为视频文件提供持久化存储，避免转码过程中数据丢失。整个过程实现了微服务的自动化部署、服务发现、负载均衡、自动扩缩容及持久化存储，符合云原生架构的要求。”
6) 【追问清单】
-
视频文件很大时如何优化存储？
- 回答：可结合云存储（如S3）与PV/PVC，或增加存储容量，优化PVC的访问模式（如RWOnce适合单机存储）。
-
服务间通信如何处理？
- 回答：通过Service的ClusterIP实现内部通信，或使用ServiceMesh（如Istio）增强通信管理（如流量控制、故障注入）。
-
Ingress被攻击时如何保障安全？
- 回答：配置Ingress的TLS证书（HTTPS加密）、访问控制列表（ACL，限制IP访问），或使用云服务商的Web应用防火墙（WAF）。
-
HPA的指标除了CPU，还可以用哪些？
- 回答：内存利用率、请求延迟（QPS）、自定义指标（如任务队列长度）。
-
部署时如何保证镜像安全？
- 回答：使用镜像扫描工具（如Clair）检测漏洞，配置镜像拉取策略（如PullPolicy: IfNotPresent），或使用私有镜像仓库（如Harbor）。
7) 【常见坑/雷区】
- Service类型选错：用ClusterIP但未配合Ingress导致外部无法访问，生产环境需用LoadBalancer或Ingress。
- HPA指标设置不合理：目标利用率设为90%导致频繁扩缩容，应合理设置（如70%左右）。
- PVC与PV访问模式不匹配：PV是ReadWriteMany但PVC用RWOnce，导致存储不可用，需严格匹配访问模式。
- 镜像拉取策略错误：设为Always拉取导致Pod启动慢，应根据环境选择（如IfNotPresent减少拉取时间）。
- 探针配置不当：Liveness探针超时时间太短，导致健康检查频繁，影响服务可用性，需合理设置超时与间隔。