10-Kubernetes与云原生面试题

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

架构：

                Internet
                    │
            ┌───────────────┐
            │  Ingress LB    │
            │  (1.2.3.4)     │
            └───────┬────────┘
                    │
        ┌───────────┼───────────┐
        │           │           │
┌────────────┐ ┌─────────┐ ┌───────────┐
│Ingress Ctrl │ │Ingress   │ │Ingress     │
│  (Node1)    │ │Ctrl(Node2)│ │Ctrl(Node3) │
└───────┬─────┘ └──┬───────┘ └─┬──────────┘
        │          │            │
        └──────────┼────────────┘
                   │
        ┌────────────────────┐
        │  nginx-service      │
        │  (ClusterIP)        │
        └──────────┬──────────┘
                   │
        ┌──────────┼──────────┐
        │          │          │
    ┌──────┐  ┌──────┐  ┌──────┐
    │Pod A  │  │Pod B  │  │Pod C  │
    └───────┘  └───────┘  └───────┘

访问流程：
1. DNS解析：www.example.com -> 1.2.3.4
2. 客户端 -> Ingress LB (1.2.3.4)
3. Ingress LB -> Ingress Controller (任一Node)
4. Ingress Controller解析Host、Path，转发到nginx-service
5. nginx-service -> Pod

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: nginx
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'Container started' > /tmp/started"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

钩子说明：

1. PostStart钩子
   - 容器启动后立即执行
   - 不保证在容器ENTRYPOINT之前执行
   - 如果钩子失败，容器会被杀死并重启

   使用场景：
   - 初始化配置
   - 通知外部系统（容器已启动）
   - 预热应用

2. PreStop钩子
   - 容器终止前执行
   - 阻塞式，钩子执行完成后才发送SIGTERM
   - 有超时时间（terminationGracePeriodSeconds，默认30秒）

   使用场景：
   - 优雅关闭（graceful shutdown）
   - 保存状态
   - 通知外部系统（容器即将停止）

完整终止流程：
1. Pod删除请求
2. Pod状态变为Terminating
3. 执行PreStop钩子（如果有）
4. 发送SIGTERM信号给容器主进程
5. 等待terminationGracePeriodSeconds（默认30秒）
6. 如果容器仍在运行，发送SIGKILL强制杀死

apiVersion: v1
kind: Pod
metadata:
  name: restart-demo
spec:
  restartPolicy: Always  # Always / OnFailure / Never
  containers:
  - name: nginx
    image: nginx

重启策略：

1. Always（默认）
   - 容器退出后总是重启
   - 适用：Deployment、StatefulSet、DaemonSet

   示例：
   容器退出码=0 -> 重启
   容器退出码=1 -> 重启

2. OnFailure
   - 容器失败时（退出码非0）重启
   - 适用：Job

   示例：
   容器退出码=0 -> 不重启
   容器退出码=1 -> 重启

3. Never
   - 容器退出后不重启
   - 适用：一次性任务

   示例：
   容器退出码=0 -> 不重启
   容器退出码=1 -> 不重启

重启间隔（Backoff）：
- 第1次重启：立即
- 第2次重启：10秒后
- 第3次重启：20秒后
- 第4次重启：40秒后
- 最大间隔：5分钟

示例：
Pod状态：
NAME    READY   STATUS             RESTARTS   AGE
nginx   0/1     CrashLoopBackOff   5          5m

apiVersion: v1
kind: Pod
metadata:
  name: exec-probe
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5  # 容器启动后5秒开始探测
      periodSeconds: 5        # 每5秒探测一次
      timeoutSeconds: 1       # 探测超时1秒
      successThreshold: 1     # 连续1次成功视为成功
      failureThreshold: 3     # 连续3次失败视为失败

工作原理：
1. kubelet在容器内执行命令：cat /tmp/healthy
2. 如果命令退出码=0，探测成功
3. 如果命令退出码!=0，探测失败
4. 连续3次失败，重启容器

使用场景：
- 检查文件是否存在
- 检查进程是否存在
- 自定义健康检查脚本

apiVersion: v1
kind: Pod
metadata:
  name: http-probe
spec:
  containers:
  - name: web
    image: myapp:v1
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz      # 健康检查端点
        port: 8080          # 端口
        httpHeaders:        # 自定义HTTP头（可选）
        - name: Custom-Header
          value: Awesome
        scheme: HTTP        # HTTP或HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 3
      successThreshold: 1
      failureThreshold: 3

工作原理：
1. kubelet发送HTTP GET请求：GET http://Pod_IP:8080/healthz
2. 如果响应码 200 <= status < 400，探测成功
3. 否则，探测失败

应用端实现（Go示例）：
func healthzHandler(w http.ResponseWriter, r *http.Request) {
    // 检查数据库连接
    if err := db.Ping(); err != nil {
        w.WriteHeader(http.StatusServiceUnavailable)
        w.Write([]byte("Database unavailable"))
        return
    }

    // 检查缓存连接
    if err := redis.Ping(); err != nil {
        w.WriteHeader(http.StatusServiceUnavailable)
        w.Write([]byte("Redis unavailable"))
        return
    }

    // 所有检查通过
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("OK"))
}

http.HandleFunc("/healthz", healthzHandler)
http.ListenAndServe(":8080", nil)

使用场景：
- Web应用健康检查
- 微服务健康检查
- 依赖服务检查（数据库、缓存等）

apiVersion: v1
kind: Pod
metadata:
  name: tcp-probe
spec:
  containers:
  - name: mysql
    image: mysql:5.7
    ports:
    - containerPort: 3306
    livenessProbe:
      tcpSocket:
        port: 3306
      initialDelaySeconds: 15
      periodSeconds: 10
      timeoutSeconds: 3
      failureThreshold: 3

工作原理：
1. kubelet尝试连接Pod的3306端口
2. 如果连接成功，探测成功
3. 如果连接失败，探测失败

使用场景：
- 数据库健康检查
- TCP服务健康检查
- 不支持HTTP的服务

livenessProbe:
  exec:
    command: ["/bin/sh", "-c", "check.sh"]
  initialDelaySeconds: 30  # 容器启动后等待30秒开始探测（避免应用启动慢）
  periodSeconds: 10        # 每10秒探测一次
  timeoutSeconds: 5        # 探测超时5秒（超过5秒视为失败）
  successThreshold: 1      # 连续1次成功视为成功（仅Liveness/Startup有效，Readiness固定1）
  failureThreshold: 3      # 连续3次失败视为失败

参数选择建议：

1. initialDelaySeconds:
   - 设置为应用启动时间 + 5秒缓冲
   - 太小：应用未启动完成就探测，导致频繁重启
   - 太大：应用启动失败无法及时发现

2. periodSeconds:
   - Liveness: 10-30秒（不宜太频繁）
   - Readiness: 5-10秒（可以频繁一些）

3. timeoutSeconds:
   - 根据应用响应时间设置
   - 网络较慢时可适当增大

4. failureThreshold:
   - Liveness: 3-5次（避免偶尔的网络抖动导致重启）
   - Readiness: 1-3次（快速摘除异常Pod）

apiVersion: v1
kind: Pod
metadata:
  name: probe-demo
spec:
  containers:
  - name: app
    image: myapp:v1
    ports:
    - containerPort: 8080

    # Startup Probe（启动探针）
    # 作用：检测应用是否启动完成
    # 适用：启动慢的应用（如Java应用）
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 0
      periodSeconds: 10
      failureThreshold: 30  # 最多等待300秒（30*10）Startup Probe成功后，才会执行Liveness和Readiness Probe

    # Liveness Probe（存活探针）
    # 作用：检测容器是否存活（是否需要重启）
    # 失败：重启容器
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 10
      failureThreshold: 3

    # Readiness Probe（就绪探针）
    # 作用：检测容器是否准备好接受流量
    # 失败：从Service的Endpoints中移除
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 1

工作流程：

T0: 容器启动

T0-T1: Startup Probe探测
  - 如果成功，进入下一阶段
  - 如果失败超过30次（300秒），重启容器

T1: Startup Probe成功

T1-T2: Liveness和Readiness Probe开始探测
  - Liveness失败 -> 重启容器
  - Readiness失败 -> 从Endpoints移除，不重启

示例场景：

场景1：应用启动慢（Java应用需要60秒启动）
  问题：如果只配置Liveness（initialDelaySeconds=30），启动未完成就探测，导致重启循环
  解决：配置Startup Probe（failureThreshold=30，最多等待300秒）

场景2：应用依赖外部服务（数据库）
  问题：数据库临时不可用，不应该重启容器
  解决：
    - Liveness: 检查应用进程是否存活（不检查数据库）
    - Readiness: 检查数据库连接（数据库不可用时摘除Pod，恢复后自动加入）

场景3：应用滚动更新
  问题：新版本Pod启动后立即接收流量，可能尚未准备好
  解决：配置Readiness Probe，只有Probe成功后才加入Endpoints

# 推荐配置（Web应用）

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:v1

    # Startup Probe：检测应用是否启动完成
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 10
      failureThreshold: 30  # 最多等待5分钟

    # Liveness Probe：检测进程是否存活（简单检查）
    livenessProbe:
      httpGet:
        path: /healthz  # 轻量级检查（不检查依赖）
        port: 8080
      periodSeconds: 10
      failureThreshold: 3
      timeoutSeconds: 5

    # Readiness Probe：检测是否准备好接受流量（完整检查）
    readinessProbe:
      httpGet:
        path: /ready  # 完整检查（包括依赖服务）
        port: 8080
      periodSeconds: 5
      failureThreshold: 1
      timeoutSeconds: 3

应用端实现：

// /healthz：轻量级检查（Liveness）
func healthzHandler(w http.ResponseWriter, r *http.Request) {
    // 只检查进程是否存活
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("OK"))
}

// /ready：完整检查（Readiness）
func readyHandler(w http.ResponseWriter, r *http.Request) {
    // 检查数据库
    if err := db.Ping(); err != nil {
        http.Error(w, "Database unavailable", http.StatusServiceUnavailable)
        return
    }

    // 检查Redis
    if err := redis.Ping(); err != nil {
        http.Error(w, "Redis unavailable", http.StatusServiceUnavailable)
        return
    }

    // 检查依赖服务
    if !isDownstreamServiceHealthy() {
        http.Error(w, "Downstream service unavailable", http.StatusServiceUnavailable)
        return
    }

    w.WriteHeader(http.StatusOK)
    w.Write([]byte("Ready"))
}

# 给Node打标签
kubectl label nodes node1 disktype=ssd

# Pod配置
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  nodeSelector:
    disktype: ssd  # 只调度到有此标签的Node
  containers:
  - name: nginx
    image: nginx

优点：简单
缺点：不够灵活（只支持精确匹配）

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      # 硬亲和性（必须满足）
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
            - nvme

      # 软亲和性（优先满足）
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: zone
            operator: In
            values:
            - zone1

  containers:
  - name: nginx
    image: nginx

操作符：
- In: 标签值在列表中
- NotIn: 标签值不在列表中
- Exists: 标签存在
- DoesNotExist: 标签不存在
- Gt: 标签值大于（数值比较）
- Lt: 标签值小于（数值比较）

示例：
# 调度到SSD或NVMe磁盘的Node，优先zone1

Node1: disktype=ssd, zone=zone1 → 符合硬亲和性，符合软亲和性，分数最高
Node2: disktype=ssd, zone=zone2 → 符合硬亲和性，不符合软亲和性，分数较低
Node3: disktype=hdd, zone=zone1 → 不符合硬亲和性，排除

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  affinity:
    # Pod亲和性（靠近某些Pod）
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - cache
        topologyKey: kubernetes.io/hostname  # 同一Node

    # Pod反亲和性（远离某些Pod）
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - web
          topologyKey: kubernetes.io/hostname  # 避免同一Node

  containers:
  - name: web
    image: nginx

示例场景：

场景1：Web应用靠近Cache（亲和性）
  topologyKey: kubernetes.io/hostname → 调度到运行Cache Pod的Node

场景2：多个Web Pod分散部署（反亲和性）
  topologyKey: kubernetes.io/hostname → 避免多个Web Pod在同一Node

topologyKey说明：
- kubernetes.io/hostname: Node级别（同一Node）
- topology.kubernetes.io/zone: 可用区级别（同一可用区）
- topology.kubernetes.io/region: 区域级别（同一区域）

# 给Node打污点（阻止Pod调度）
kubectl taint nodes node1 key=value:NoSchedule

# Pod容忍污点
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

  containers:
  - name: nginx
    image: nginx

污点效果（Effect）：
1. NoSchedule: 不调度新Pod（已有Pod不受影响）
2. PreferNoSchedule: 尽量不调度（软限制）
3. NoExecute: 不调度新Pod，且驱逐已有Pod

示例：

# 专用Node（仅特定Pod可调度）
kubectl taint nodes gpu-node1 dedicated=gpu:NoSchedule

# GPU Pod配置容忍
tolerations:
- key: "dedicated"
  operator: "Equal"
  value: "gpu"
  effect: "NoSchedule"

# Node维护（驱逐所有Pod）
kubectl taint nodes node1 maintenance=true:NoExecute

# Pod配置容忍（维护期间不驱逐）
tolerations:
- key: "maintenance"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 3600  # 容忍3600秒后驱逐

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: myapp:v1
    resources:
      requests:      # 请求资源（调度依据）
        cpu: "250m"      # 0.25核
        memory: "512Mi"  # 512MB
      limits:        # 限制资源（运行时限制）
        cpu: "500m"      # 0.5核
        memory: "1Gi"    # 1GB

资源说明：

1. CPU:
   - 单位：m（millicore），1000m = 1核
   - 例如：250m = 0.25核 = 25%的CPU
   - requests: 保证的CPU时间
   - limits: 最大CPU时间（超过会被限流，不会被杀死）

2. Memory:
   - 单位：Ki、Mi、Gi、Ti 或 K、M、G、T
   - requests: 保证的内存
   - limits: 最大内存（超过会被OOMKilled）

调度影响：
Scheduler只看requests（不看limits）

Node资源：CPU=4核，Memory=8Gi

已调度Pod：
  Pod1: requests(CPU=1, Memory=2Gi)
  Pod2: requests(CPU=1, Memory=2Gi)

剩余资源：CPU=2核，Memory=4Gi

新Pod: requests(CPU=1, Memory=3Gi) → 可以调度
新Pod: requests(CPU=3, Memory=1Gi) → 无法调度（CPU不足）

1. Guaranteed（保证级别）
   条件：
   - 所有容器都设置了requests和limits
   - requests = limits

   示例：
   resources:
     requests:
       cpu: "1"
       memory: "1Gi"
     limits:
       cpu: "1"
       memory: "1Gi"

   特点：
   - 优先级最高
   - 资源不足时最后被驱逐
   - 适用：关键业务

2. Burstable（突发级别）
   条件：
   - 至少一个容器设置了requests或limits
   - requests < limits 或只设置其中一个

   示例：
   resources:
     requests:
       cpu: "250m"
       memory: "512Mi"
     limits:
       cpu: "500m"
       memory: "1Gi"

   特点：
   - 优先级中等
   - 资源不足时第二批被驱逐（按内存使用率排序）
   - 适用：一般业务

3. BestEffort（尽力而为）
   条件：
   - 所有容器都未设置requests和limits

   示例：
   resources: {}  # 不设置

   特点：
   - 优先级最低
   - 资源不足时第一批被驱逐
   - 适用：临时任务、测试环境

驱逐顺序（资源不足时）：
BestEffort → Burstable（内存使用率高） → Guaranteed