Golang应用K8s滚动升级指南

## Golang应用K8s滚动升级实战教程：零停机平滑过渡 本文深入探讨了如何在Kubernetes环境中实现Golang应用的零停机滚动升级，确保服务连续性与用户体验。**核心在于**：Golang应用需具备优雅停机能力，能够处理现有请求并拒绝新请求，配合Kubernetes的readiness探针保证流量只路由到就绪的Pod。**文章将详细讲解**如何配置liveness探针、terminationGracePeriodSeconds，以及合理设置滚动更新策略（maxSurge和maxUnavailable），**并通过实例演示**如何从Go应用本身出发，结合K8s的强大编排能力，实现真正的滚动升级。掌握这些关键点，你就能在不中断服务的前提下，平滑地将旧版本替换为新版本，为用户提供稳定可靠的服务。

Golang应用在Kubernetes中实现零停机滚动升级的关键在于：应用需支持优雅停机以处理现有请求并拒绝新请求，结合Kubernetes的readiness探针确保流量不被路由到未就绪或即将终止的Pod，同时合理配置liveness探针、terminationGracePeriodSeconds及滚动更新策略（maxSurge和maxUnavailable），保障升级过程中服务连续性与资源可用性。

Golang应用在Kubernetes中实现滚动升级，核心在于利用Kubernetes Deployment对象的内置能力，配合Go应用自身的优雅停机机制和健康检查。这能确保在不中断服务的前提下，平滑地将旧版本替换为新版本。

解决方案

在我看来，要让一个Golang应用在Kubernetes里实现真正意义上的滚动升级，我们不光要依赖K8s强大的编排能力，更要从Go应用本身做起，让它“懂事”一点，知道什么时候该体面地退出。下面我将通过一个具体的示例来演示这个过程。

1. 准备一个支持优雅停机的Golang应用

这是基础，也是很多Go开发者容易忽视的一点。一个“野蛮”退出的Go应用，即使K8s再努力，也可能在升级时丢掉请求。

main.go (v1.0.0版本):

package main

import (
    "context"
    "fmt"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"
)

const appVersion = "v1.0.0" // 应用版本号，升级时会改为v1.0.1

// handler 处理普通请求
func handler(w http.ResponseWriter, r *http.Request) {
    log.Printf("Received request from %s on path %s. Version: %s", r.RemoteAddr, r.URL.Path, appVersion)
    time.Sleep(1 * time.Second) // 模拟一些工作负载
    fmt.Fprintf(w, "Hello from Golang App! Version: %s\n", appVersion)
}

// healthzHandler 用于健康检查
func healthzHandler(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    fmt.Fprintf(w, "OK\n")
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", handler)
    mux.HandleFunc("/healthz", healthzHandler) // 暴露健康检查接口

    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }

    server := &http.Server{
        Addr:    ":" + port,
        Handler: mux,
    }

    // 创建一个通道，用于监听操作系统信号
    quit := make(chan os.Signal, 1)
    // 监听 SIGINT (Ctrl+C) 和 SIGTERM (Kubernetes发送的终止信号)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)

    // 在一个goroutine中启动HTTP服务器
    go func() {
        log.Printf("Starting server version %s on :%s", appVersion, port)
        if err := server.ListenAndServe(); err != nil && err != http.ErrServerClosed {
            log.Fatalf("Server failed to start: %v", err)
        }
    }()

    // 阻塞主goroutine，直到接收到退出信号
    <-quit
    log.Println("Shutting down server...")

    // 创建一个带超时的上下文，用于控制服务器优雅停机的时间
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) // 10秒超时
    defer cancel()

    // 优雅停机
    if err := server.Shutdown(ctx); err != nil {
        log.Fatalf("Server shutdown failed: %v", err)
    }

    log.Println("Server gracefully stopped.")
}

Dockerfile:

# 使用多阶段构建，减小最终镜像大小
FROM golang:1.22-alpine AS builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download # 下载依赖

COPY . .

# 编译Go应用，禁用CGO，交叉编译为Linux可执行文件
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .

# 第二阶段：构建最终的运行镜像
FROM alpine:latest

WORKDIR /root/

# 从构建阶段复制编译好的可执行文件
COPY --from=builder /app/main .

EXPOSE 8080 # 暴露应用端口

CMD ["./main"] # 启动应用

2. Kubernetes Deployment 和 Service 配置

go-app.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-app-deployment
  labels:
    app: go-app
spec:
  replicas: 3 # 期望的Pod副本数量
  selector:
    matchLabels:
      app: go-app
  strategy:
    type: RollingUpdate # 声明使用滚动更新策略
    rollingUpdate:
      maxSurge: 25% # 允许在升级过程中，新Pod的数量可以比期望多25% (1个)
      maxUnavailable: 1 # 允许在升级过程中，最多有1个Pod不可用
  template:
    metadata:
      labels:
        app: go-app
    spec:
      containers:
      - name: go-app
        image: your-docker-repo/go-app:v1.0.0 # 替换为你的Docker镜像地址
        ports:
        - containerPort: 8080
        # Readiness Probe: 决定Pod是否准备好接收流量
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5 # 容器启动后等待5秒开始探测
          periodSeconds: 5     # 每5秒探测一次
          failureThreshold: 3  # 连续3次失败则认为不就绪
        # Liveness Probe: 决定Pod是否存活，如果失败则重启Pod
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15 # 容器启动后等待15秒开始探测
          periodSeconds: 10     # 每10秒探测一次
          failureThreshold: 3   # 连续3次失败则认为不健康
        env:
        - name: PORT
          value: "8080"
      # terminationGracePeriodSeconds: 30 # 默认是30秒，显式指定以增强可读性。
                                        # 告诉K8s在强制终止Pod之前，给应用多少时间来优雅停机。
---
apiVersion: v1
kind: Service
metadata:
  name: go-app-service
  labels:
    app: go-app
spec:
  selector:
    app: go-app
  ports:
    - protocol: TCP
      port: 80 # Service暴露的端口
      targetPort: 8080 # Pod内部容器监听的端口
  type: LoadBalancer # 或者 ClusterIP，根据需求选择

3. 部署初始版本

• 构建Docker镜像并推送到仓库： docker build -t your-docker-repo/go-app:v1.0.0 .docker push your-docker-repo/go-app:v1.0.0
• 应用Kubernetes配置： kubectl apply -f go-app.yaml

4. 执行滚动升级

• 修改Go应用代码：将 appVersion 改为 "v1.0.1"。
• 构建新版本镜像： docker build -t your-docker-repo/go-app:v1.0.1 .docker push your-docker-repo/go-app:v1.0.1
• 更新Deployment YAML：将 image 字段从 your-docker-repo/go-app:v1.0.0 修改为 your-docker-repo/go-app:v1.0.1。
• 应用更新： kubectl apply -f go-app.yaml

此时，Kubernetes会按照 RollingUpdate 策略，逐步替换旧版本的Pod。你可以通过 kubectl get pods -w 和 kubectl describe deployment go-app-deployment 来观察升级过程。

Golang应用在Kubernetes中实现零停机升级的关键是什么？

说实话，要做到真正的“零停机”，这背后需要Go应用和Kubernetes的紧密配合，缺一不可。在我看来，有几个核心点是必须抓住的：

1. Go应用的优雅停机（Graceful Shutdown）：这是基石。当Kubernetes决定终止一个旧Pod时，它会发送一个 SIGTERM 信号。你的Go应用必须能够捕获这个信号，然后：

   • 停止接受新请求：比如，停止监听端口，或者更新内部状态，告诉负载均衡器它即将关闭。
   • 处理完现有请求：给正在处理的请求留出足够的时间完成。这就是 http.Server.Shutdown() 的作用，它会关闭监听器，但允许现有连接在超时前完成。
   • 释放资源：关闭数据库连接、文件句柄等。 如果没有优雅停机，旧Pod可能会在处理请求到一半时被强制杀死，导致客户端收到错误。

2. Kubernetes的健康检查（Readiness and Liveness Probes）：

   • Readiness Probe（就绪探针）：这个太重要了。它告诉Kubernetes你的Pod是否准备好接收流量。新Pod启动后，可能需要一些时间来初始化、加载配置，甚至预热缓存。在它真正准备好之前，就绪探针应该失败。只有当探针成功后，Kubernetes才会将这个新Pod添加到Service的Endpoint列表中，开始接收流量。旧Pod在收到 SIGTERM 后，也应该让其就绪探针失败，这样负载均衡器就会停止向它发送新请求。
   • Liveness Probe（存活探针）：它判断你的应用是否还“活着”。如果Go应用因为某种原因（比如死锁、内存泄漏）不再响应，存活探针会失败，Kubernetes会重启这个Pod。这虽然不直接关系到滚动升级的平滑性，但它确保了Pod在整个生命周期中的健康。

3. terminationGracePeriodSeconds：这是Pod级别的一个配置，默认是30秒。它告诉Kubernetes，在发送 SIGTERM 信号后，最长等待多久才强制杀死Pod（发送 SIGKILL）。你的Go应用优雅停机逻辑的超时时间应该小于或等于这个值，给应用留足处理现有请求的时间。

4. preStop Hook（可选但推荐）：有时候，你可能希望在 SIGTERM 信号发送之前，或者在 SIGTERM 信号之后，执行一些额外的清理工作。preStop hook就是为此而生。比如，你可以在 preStop hook中加入一个 sleep 命令，给Service的负载均衡器一个额外的缓冲时间来停止向该Pod发送请求，确保所有流量都已排空。虽然Go应用的优雅停机已经很强大，但这个hook能提供额外的保障。

这些点结合起来，才能构成一个健壮的零停机升级方案。

Kubernetes滚动升级策略（maxSurge与maxUnavailable）如何影响Golang应用的可用性？

maxSurge 和 maxUnavailable 是Kubernetes滚动更新策略的核心参数，它们直接决定了升级的速度、风险以及应用在升级期间的整体可用性。理解它们对Go应用的影响，可以帮助我们更好地权衡升级效率与服务稳定性。

• maxSurge (最大浪涌)：

  • 定义：指定在升级过程中，可以比期望的副本数多出多少个Pod。它可以是绝对值（如 1），也可以是百分比（如 25%）。
  • 对Go应用可用性的影响：
    • 提高可用性：当 maxSurge 大于0时，Kubernetes会在终止旧Pod之前，先启动新的Pod。这意味着在某个时刻，集群中运行的Pod总数会超过 replicas 定义的数量。对于Go应用来说，这能确保有足够的新Pod在旧Pod被终止前就绪并开始接收流量，从而提高了升级期间的整体服务容量和可用性。
    • 资源消耗：当然，这意味着在升级期间，你的集群会暂时消耗更多的计算资源。对于资源紧张的集群，这需要谨慎设置。
  • 示例：如果 replicas: 3 且 maxSurge: 25%，那么Kubernetes会先启动1个新Pod（25% of 3 rounded up is 1），此时总共有4个Pod。当这个新Pod就绪后，才会开始终止旧Pod。

• maxUnavailable (最大不可用)：

  • 定义：指定在升级过程中，最多可以有多少个Pod处于不可用状态。同样可以是绝对值或百分比。
  • 对Go应用可用性的影响：
    • 控制风险：它直接限制了升级期间服务的降级程度。如果 maxUnavailable 设置为0，意味着在任何时候都不能有Pod不可

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。