云原生Kubernetes部署会：用Helm Chart替代Docker Compose的惊魂7分钟

标签: Kubernetes, Helm, Docker, 云原生, 部署

会议室里，面试官和三位评委坐在长桌一侧，而我作为候选人站在白板前，手心已经开始冒汗。大屏幕上显示着一个倒计时：7:00。

"李工程师，"首席面试官推了推眼镜，"我们公司正在将所有服务迁移到Kubernetes。这是我们目前使用的Docker Compose文件，请你在7分钟内将它转换成Helm Chart结构，并解释关键决策。计时开始。"

倒计时启动，屏幕上出现了一个包含前端、后端和数据库的Docker Compose文件：

version: '3'
services:
  frontend:
    image: company/frontend:1.2.3
    ports:
      - "80:80"
    environment:
      - API_URL=http://backend:8080
    depends_on:
      - backend
  
  backend:
    image: company/backend:2.1.0
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=postgres
      - DB_USER=app
      - DB_PASSWORD=secretpassword
    depends_on:
      - postgres
  
  postgres:
    image: postgres:13
    volumes:
      - pg-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=app
      - POSTGRES_PASSWORD=secretpassword

volumes:
  pg-data:

第1分钟：规划结构

我深吸一口气，迅速在白板上画出Helm Chart的基本结构：

myapp/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml
    configmap.yaml
    secret.yaml
    pvc.yaml

"我首先会创建一个名为'myapp'的Chart，包含三个主要组件：frontend、backend和database。"

第2-3分钟：编写Chart.yaml和values.yaml

我快速写下Chart.yaml的内容：

apiVersion: v2
name: myapp
description: A Helm chart for our application
type: application
version: 0.1.0
appVersion: 1.0.0

"面试官，我现在要创建values.yaml文件，这将包含所有可配置参数，使Chart更加灵活——"

面试官打断道："假设这是生产环境，你会如何处理敏感信息如数据库密码？"

我没有慌张："对于敏感信息，我会使用Kubernetes Secrets。在values.yaml中，我们可以提供一个选项让用户决定是使用现有Secret还是创建新Secret。在生产环境中，我推荐使用外部密钥管理系统如HashiCorp Vault或AWS Secrets Manager，通过注入器将密钥注入Pod。"

我继续在白板上写下values.yaml：

frontend:
  image:
    repository: company/frontend
    tag: 1.2.3
  service:
    type: ClusterIP
    port: 80

backend:
  image:
    repository: company/backend
    tag: 2.1.0
  service:
    type: ClusterIP
    port: 8080

postgres:
  enabled: true  # 可以设为false使用外部数据库
  image:
    repository: postgres
    tag: 13
  persistence:
    enabled: true
    size: 10Gi
  
# 生产环境下，这里只提供引用，实际密码应存储在外部
secrets:
  postgres:
    existingSecret: ""  # 如果为空，则创建新Secret
    username: app
    password: ""  # 生产环境应为空

第4-5分钟：创建Deployment和Service模板

时间过半，我开始快速编写核心模板文件。

# frontend-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-frontend
spec:
  replicas: {{ .Values.frontend.replicas | default 1 }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}-frontend
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-frontend
    spec:
      containers:
      - name: frontend
        image: {{ .Values.frontend.image.repository }}:{{ .Values.frontend.image.tag }}
        ports:
        - containerPort: 80
        env:
        - name: API_URL
          value: "http://{{ .Release.Name }}-backend:{{ .Values.backend.service.port }}"

一位评委突然问道："你如何确保部署顺序正确？在Docker Compose中有depends_on，但Kubernetes中呢？"

我边写边回答："Kubernetes没有直接等同于depends_on的机制，但我们可以使用几种方法：

使用Helm hooks如pre-install和post-install
实现就绪探针(readiness probes)确保服务真正可用
在应用层实现重试逻辑

对于这个例子，我会为后端服务添加就绪探针，确保它在接收流量前已连接到数据库。"

第6分钟：数据库和存储

时间所剩无几，我快速写下PostgreSQL相关模板：

# postgres-pvc.yaml
{{- if and .Values.postgres.enabled .Values.postgres.persistence.enabled }}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ .Release.Name }}-postgres
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: {{ .Values.postgres.persistence.size }}
{{- end }}

# postgres-secret.yaml
{{- if and .Values.postgres.enabled (not .Values.secrets.postgres.existingSecret) }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-postgres
type: Opaque
data:
  username: {{ .Values.secrets.postgres.username | b64enc }}
  password: {{ .Values.secrets.postgres.password | b64enc }}
{{- end }}

最后一位评委发问："你如何处理Compose文件中的volume挂载？"

我回答："在Kubernetes中，我们使用PersistentVolumeClaim来请求存储。我刚刚创建了一个PVC模板，它会根据values.yaml中的配置请求适当的存储空间。PostgreSQL容器将挂载这个PVC到/var/lib/postgresql/data目录。"