在 Kubernetes 上升级 Vertica

操作员自动执行自定义资源 (CR) 的 Vertica 服务器版本升级。使用 CR 中的 upgradePolicy 设置来确定您的群集在版本升级期间是保持联机还是脱机。

先决条件

在开始之前，请完成以下操作：

制定策略

upgradePolicy CR 参数设置确定操作员如何升级 Vertica 服务器版本。它提供以下选项：

设置协调循环迭代时间

在升级期间，操作员运行协调循环以将对象的实际状态与 CR 中定义的期望状态进行比较。操作员将任何未完成的工作重新排队，协调循环将状态与每次协调迭代之间的设定时间段进行比较。设置 upgradeRequeueTime 参数 以确定每次协调循环迭代之间的时间量。

联机升级期间路由客户端流量

在联机升级期间，操作员首先升级主子群集中的 Vertica 服务器版本，以构成具有新版本的群集。当操作员重新启动主节点时，会将辅助子群集置于只读模式。接下来，操作员一次升级任何一个辅助子群集。在任何子群集的升级过程中，所有客户端连接都被耗尽，流量重新路由到现有子群集或临时子群集。

联机升级需要多个子群集，以便操作员可以在升级时重新路由子群集的客户端流量。默认情况下，操作员使用以下规则选择哪个子群集接收重新路由的流量：

  • 为主子群集重新路由流量时，操作员选择 CR 中定义的第一个辅助子群集。

  • 升级后重新启动第一个辅助子群集时，操作员选择 CR 中定义的第一个已启动的子群集。

  • 如果不存在辅助子群集，则无法执行联机升级。操作员选择 CR 中定义的第一个主子群集并执行脱机升级。

将客户端流量路由到现有子群集

由于子群集容量或许可限制，您可能希望控制哪些子群集处理重新路由的客户端流量。您可以设置 temporarySubclusterRouting.names 参数以指定现有的子群集接收重新路由的流量：

spec:
  ...
  temporarySubclusterRouting:
    names:
      - subcluster-2
      - subcluster-1

在前面的示例中，当另一个 subcluster-1 脱机时，subcluster-2 接受流量。当 subcluster-2 关闭时，subcluster-1 接受它的流量。

将客户端流量路由到临时子群集

要创建在升级过程中存在的临时子群集，请使用 temporarySubclusterRouting.template 参数为临时子群集提供名称和大小：

spec:
  ...
  temporarySubclusterRouting:
    template:
      name: transient
      size: 3

如果选择使用临时子群集进行升级，请确保您拥有必要的资源。

升级 Vertica 服务器版本

设置 upgradePolicy 并选择配置临时子群集路由后，使用 kubectl 命令行工具执行升级并监控其进度。

以下步骤执行联机版本升级：

  1. 设置升级策略以下命令使用 kubectl patch 命令将 upgradePolicy 值设置为 Online：

    $ kubectl patch verticadb cluster-name --type=merge --patch '{"spec": {"upgradePolicy": "Online"}}'

  2. 用 kubectl patch 更新 CR 中的映像值：

    $ kubectl patch verticadb cluster-name --type=merge --patch '{"spec": {"image": "vertica/vertica-k8s:new-version"}}'

  3. 使用 kubectl wait 等待操作员确认新映像并开始升级模式：

    $ kubectl wait --for=condition=ImageChangeInProgress=True vdb/cluster-name –-timeout=180s

  4. 使用 kubectl wait 等待操作员离开升级模式：

    $ kubectl wait --for=condition=ImageChangeInProgress=False vdb/cluster-name –-timeout=800s

查看升级过程

要查看升级过程的当前阶段，请使用 kubectl get 检查 upgradeStatus 状态字段：

$ kubectl get vdb -n namespacedatabase-name -o jsonpath='{.status.upgradeStatus}{"\n"}'
Restarting cluster with new image

要查看整个升级过程，请使用 kubectl describe 列出操作员在升级过程中生成的事件：

$ kubectl describe vdb cluster-name

...
Events:
  Type    Reason                   Age    From                Message
  ----    ------                   ----   ----                -------
  Normal  UpgradeStart             5m10s  verticadb-operator  Vertica server upgrade has started.  New image is 'vertica-k8s:new-version'
  Normal  ClusterShutdownStarted   5m12s  verticadb-operator  Calling 'admintools -t stop_db'
  Normal  ClusterShutdownSucceeded 4m08s  verticadb-operator  Successfully called 'admintools -t stop_db' and it took 56.22132s
  Normal  ClusterRestartStarted    4m25s  verticadb-operator  Calling 'admintools -t start_db' to restart the cluster
  Normal  ClusterRestartSucceeded  25s    verticadb-operator  Successfully called 'admintools -t start_db' and it took 240s
  Normal  UpgradeSucceeded         5s     verticadb-operator  Vertica server upgrade has completed successfully