Kubernetes 部署策略

使用 Kubernetes 部署应用程序因其众多好处而变得越来越流行。Kubernetes 可以轻松管理容器化应用程序，为应用程序部署、扩展和管理提供平台。借助 Kubernetes，应用程序可以在不同的环境中快速、一致地部署，包括本地和云平台。

在使用 Kubernetes 部署应用程序时，我们中的许多人都会对使用哪种部署类型有疑问——滚动、蓝绿、金丝雀等。在本文中，我们将讨论这些部署类型（金丝雀、滚动和蓝绿）、它们的工作原理以及您应该选择哪一种。

介绍

Kubernetes 是目前最流行的容器编排工具之一。它可以让开发人员和运维人员快速、可靠地部署、扩展和管理应用程序。在本文中，我们将讨论 Kubernetes 部署策略，这些策略可以帮助您在 Kubernetes 环境中成功部署应用程序。

滚动更新策略

滚动更新是一种逐步部署新版本的策略，以确保应用程序在更新过程中不会出现任何中断。在 Kubernetes 中，您可以使用滚动更新策略来部署新版本的应用程序。这种策略可以让您逐步将新版本应用程序的 Pod 替换为旧版本的 Pod，直到所有 Pod 都被替换为止。这种方法可以确保应用程序在更新过程中始终处于可用状态，同时最大程度地减少了停机时间。

Kubernetes 滚动部署是一种以受控和渐进的方式更新和部署新版本软件的策略。Kubernetes 不是一次部署所有更新，而是逐步推出更改，从而降低停机风险，并允许在发生错误时轻松回滚。滚动部署涉及使用软件更新版本的软件创建新的副本集，同时逐步缩减旧副本集。这允许在旧版本仍在运行时部署新版本，确保服务不会中断。完全部署新版本后，将删除旧副本集，并完成部署。Kubernetes 滚动部署对于确保复杂分布式系统的高可用性和可靠性至关重要。

下面是 Kubernetes 中滚动部署 YAML 文件的示例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:v1
        ports:
        - containerPort: 8080

在此示例中，我们将部署一个 Kubernetes 部署，该部署将创建应用程序的三个副本。部署使用选择器根据标签应用程序查找要管理的相应容器：myapp。

策略部分指定了 Kubernetes 应该用来更新部署的策略。在本例中，我们使用的是滚动更新策略。这意味着 Kubernetes 将通过用新副本替换旧副本来逐步更新部署。

“最大浪涌”和“最大不可用”字段控制滚动更新过程。maxSurge 确定在所需副本数之上可以创建的最大副本数，maxUnavailable 确定更新期间可以不可用的最大副本数。

模板部分指定部署创建的容器的配置。在本例中，我们在每个 Pod 中运行一个容器，该容器由容器字段指定。使用的容器映像是 myapp：v1，这是我们应用程序的第一个版本。

若要更新部署，我们将创建一个新的部署 YAML 文件，该文件指定应用程序的新版本，例如 myapp：v2。然后，我们将更新原始部署以指向新的 YAML 文件。

一旦更新开始，Kubernetes 将逐渐用新副本替换旧副本，直到所有副本都运行新版本。滚动更新过程允许在对用户中断最小的情况下执行更新，因为它始终确保在推出新版本时至少运行旧版本的一个副本。

金丝雀部署策略

金丝雀部署是一种逐步部署新版本的策略，以确保新版本的应用程序可以正常运行。在 Kubernetes 中，您可以使用金丝雀部署策略来部署新版本的应用程序。这种策略可以让您将新版本的应用程序的一小部分 Pod 替换为旧版本的 Pod，以确保新版本的应用程序可以正常运行。如果新版本的应用程序出现了问题，您可以立即停止部署，并将流量全部切换回旧版本的应用程序。如果一切正常，您可以继续部署新版本的应用程序。

Kubernetes 金丝雀部署是一种在将更新发布到整个系统之前向一小部分用户或服务器推出新功能或更改的技术。这是通过使用软件更新版本的软件创建新的副本集，同时保持原始副本集运行来完成的。然后，一小部分流量将路由到新的副本集，而大部分流量继续由原始副本集提供服务。这允许在实时环境中测试新版本，同时将影响整个系统的问题风险降至最低。如果在 Canary 部署期间检测到问题，则可以将其快速回滚到原始副本集。Canary 部署是一种有价值的工具，允许在将更改发布到整个系统之前对更改进行受控测试，从而最大限度地降低风险并确保复杂分布式系统中的高可用性。

下面是 Kubernetes 中金丝雀部署 YAML 文件的示例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:v1
        ports:
        - containerPort: 8080
      readinessProbe:
        httpGet:
          path: /
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 5
      livenessProbe:
        httpGet:
          path: /
          port: 8080
        initialDelaySeconds: 10
        periodSeconds: 10

在此示例中，我们将部署一个 Kubernetes 部署，该部署将创建应用程序的三个副本。部署使用选择器根据标签应用程序查找要管理的相应容器：myapp。

模板部分指定部署创建的容器的配置。在本例中，我们在每个 Pod 中运行一个容器，该容器由容器字段指定。使用的容器映像是 myapp：v1，这是我们应用程序的第一个版本。

我们还向容器添加了两个探测器来检查其运行状况。readyinessProbe 检查容器是否已准备好接收流量，livenessProbe 检查容器是否仍在运行。如果这些探测中的任何一个失败，Pod 将重新启动。

若要执行金丝雀部署，我们将创建第二个部署 YAML 文件，该文件指定应用程序的新版本，例如 myapp：v2。然后，我们将更新原始部署以设置金丝雀测试，方法是将新版本的副本扩展到 1，同时将旧版本的副本保持在 2。

新版本运行后，我们可以对其进行测试以确保其正常运行。如果一切正常，我们可以更新原始部署以纵向扩展新版本的副本，并逐步缩减旧版本的副本。

这将导致一小部分流量逐渐从旧版本转移到新版本，直到所有流量都转到新版本。如果新版本出现任何问题，我们可以通过反转该过程快速回滚到旧版本。

金丝雀部署策略

蓝绿 Kubernetes 部署策略是一种发布新版本应用程序以最大限度地减少停机时间和风险的技术。它涉及运行两个相同的环境，一个用作活动生产环境（蓝色），另一个用作新的候选版本（绿色）。新版本候选版本在与生产环境切换之前经过全面测试，允许平稳过渡，没有任何停机时间或错误。

下面是一个在 Kubernetes 上进行蓝绿部署的 YAML 文件示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
        - name: my-app
          image: myregistry/my-app:blue
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

在此示例中，我们为名为“my-app”的应用程序定义了一个具有两个副本的部署。部署具有“app： my-app”标签选择器，它将匹配将流量路由到部署的相应服务。

第一个模板定义应用程序的“蓝色”版本。它使用标签“版本：蓝色”进行定义，以便轻松识别当前生产中的版本。此版本的容器映像是从 Docker 注册表“myregistry/my-app：blue”中提取的。 当新版本准备就绪时，将添加一个带有标签“版本：绿色”的新模板。此新模板将具有包含新版本应用程序的更新容器映像。创建此新模板并准备好发布后，可以更新 Kubernetes 服务以将流量路由到新的“绿色”部署。

这种蓝绿部署策略可确保新版本的应用程序在发布之前可以对其进行全面测试，而不会停机或错误。

你应该选择哪一个？

Kubernetes 部署策略的选择取决于所部署的应用程序或服务的特定需求和要求。

在将新功能或更新部署到用户或服务器的子集以在实时环境中对其进行测试时，通常使用 canary 部署策略，并且通常用于需要频繁更新的应用程序。此策略允许在对生产环境影响最小的情况下测试新功能，并有助于在问题影响整个系统之前识别问题。

部署策略非常适合在部署期间需要零停机时间的应用程序。它涉及逐步推出应用程序的新版本，同时确保旧版本仍在运行，从而降低停机风险，并允许在出现问题时轻松回滚。

blue-green 部署策略对于可以接受停机时间但必须最小化的应用程序非常有用。它涉及运行两个相同的环境，一个用作活动生产环境，另一个用作新的候选版本。新版本候选版本在与生产环境切换之前经过测试，允许平稳过渡，没有任何停机时间或错误。

总之，部署策略的选择取决于所部署的应用程序或服务的特定需求和要求。Canary 部署非常适合频繁更新和测试，滚动部署非常适合零停机部署，蓝绿部署非常适合最大限度地减少部署期间的停机时间。