这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

基于 Kubernetes 的子群集

Eon 模式使用子群集进行工作负载隔离和扩展。Vertica 操作器提供了工具以将外部客户端通信定向到特定子群集，以及在不停止数据库的情况下自动扩展。

自定义资源定义 (CRD) 提供参数，允许您针对特定工作负载微调每个子群集。例如，您可以增加子群集 size 设置以增加吞吐量，或调整资源请求和限制以管理计算能力。当您创建自定义资源实例时，操作器将每个子群集部署为 StatefulSet。每个 StatefulSet 都有一个服务对象，它允许外部客户端连接到特定子群集。

Kubernetes 使用子群集名称来派生子群集 StatefulSet、服务对象和 pod 的名称。这种命名约定将子群集对象紧密耦合在一起，以帮助 Kubernetes 有效地管理群集。如果要重命名子群集，则必须将其从 CRD 中删除并重新定义，以便操作器可以使用派生名称创建新对象。

外部客户端连接

外部客户端可以将特定的子群集作为目标，这些子群集在经过微调之后可以处理外部客户端的工作负载。每个子群集都有一个用来处理外部连接的服务对象。要将多个子群集作为单个服务对象的目标，请在自定义资源 (CR) 中为每个子群集分配相同的 spec.subclusters.serviceName 值。有关实施的详细信息，请参阅创建自定义资源。

操作器执行运行状况监控，检查 Vertica 守护程序是否在每个 pod 上运行。如果是，则操作器允许服务对象将流量路由到 pod。

默认情况下，服务对象从自定义资源名称和关联的子群集派生其名称，并使用 customResourceName-subclusterName 格式。使用 subclusters[i].serviceName CR 参数 覆盖默认命名格式并使用 metadata.name-serviceName 格式。

Vertica 支持以下服务对象类型：

  • ClusterIP：默认服务类型。此服务提供内部负载均衡，并设置仅可从子群集内部访问的稳定 IP 和端口。

  • NodePort：提供外部客户端访问。您可以为子群集中的每个主机节点指定一个端口号，以便为客户端连接打开。

  • LoadBalancer：使用云提供商负载均衡器根据需要创建 NodePort 和 ClusterIP 服务。有关实施的详细信息，请参阅 Kubernetes 文档 和云提供商文档。

有关配置的详细信息，请参阅创建自定义资源。

管理内部和外部工作负载

Vertica StatefulSet 与外部服务对象相关联。所有外部客户端请求都通过此服务对象发送，并在群集中的 pod 之间进行负载均衡。

导入和导出

在 Kubernetes 之外的群集之间导入和导出数据要求您公开具有 NodePort 或 LoadBalancer 服务类型的服务并正确配置网络。

1 - 扩展子群集

操作器使您能够自动扩展子群集的数量以及每个子群集的 pod 数量。这使您可以根据工作负载的即时需求来利用或节省资源。

以下部分说明如何为新工作负载扩展资源。有关为现有工作负载扩展资源的详细信息，请参阅 VerticaAutoscaler 自定义资源。

先决条件

扩展子群集的数量

调整自定义资源中的子群集数量，以针对短期运行的仪表板查询微调资源。例如，增加子群集的数量以提高吞吐量。有关详细信息，请参阅使用子群集提高查询吞吐量。

  1. 使用 kubectl edit 打开默认文本编辑器并更新指定的自定义资源的 YAML 文件。以下命令打开名为 vdb 的自定义资源进行编辑：

    $ kubectl edit vdb

  2. 在自定义资源的 spec 部分中，找到 subclusters 子部分。从 isPrimary 字段开始定义新的子群集。

    isPrimary 字段接受一个布尔值，以指定子群集是主群集还是辅助群集。用于自定义资源中已经有一个主子群集，因此输入 false：

    spec:
...
  subclusters:
  ...
  - isPrimary: false

  3. 按照创建自定义资源中的步骤完成子群集定义。以下已完成的示例为仪表板查询添加了一个辅助子群集：

    spec:
...
  subclusters:
  - isPrimary: true
    name: primary-subcluster
  ...
  - isPrimary: false
    name: dashboard
    nodePort: 32001
    resources:
      limits:
        cpu: 32
        memory: 96Gi
      requests:
        cpu: 32
        memory: 96Gi
    serviceType: NodePort
    size: 3

  4. 保存并关闭自定义资源文件。成功更新文件后，您会收到类似如下的消息：

    verticadb.vertica.com/vertica-db 已编辑 (verticadb.vertica.com/vertica-db edited)

  5. 使用 kubectl wait 命令监控新 pod 何时准备就绪：

    $ kubectl wait --for=condition=Ready pod --selector app.kubernetes.io/name=vertica-db --timeout 180s
pod/vdb-dashboard-0 condition met
pod/vdb-dashboard-1 condition met
pod/vdb-dashboard-2 condition met

扩展子群集中的 pod

对于长时间运行的分析查询，增加子群集的 pod 计数。请参阅使用 Elastic Crunch Scaling 提高查询性能。

  1. 使用 kubectl edit 打开默认文本编辑器并更新指定的自定义资源的 YAML 文件。以下命令打开名为 vdb 的自定义资源进行编辑：

    $ kubectl edit vertica-db

  2. 将 subclusters.size 值更新为 6：

    spec:
...
  subclusters:
  ...
  - isPrimary: false
    ...
    size: 6

    分片会自动重新平衡。

  3. 保存并关闭自定义资源文件。成功更新文件后，您会收到类似如下的消息：

    verticadb.vertica.com/vertica-db 已编辑 (verticadb.vertica.com/vertica-db edited)

  4. 使用 kubectl wait 命令监控新 pod 何时准备就绪：

    $ kubectl wait --for=condition=Ready pod --selector app.kubernetes.io/name=vertica-db --timeout 180s
pod/vdb-subcluster1-3 condition met
pod/vdb-subcluster1-4 condition met
pod/vdb-subcluster1-5 condition met

移除子群集

当不再需要子群集或为了保留资源时，移除子群集。

  1. 使用 kubectl edit 打开默认文本编辑器并更新指定的自定义资源的 YAML 文件。以下命令打开名为 vdb 的自定义资源进行编辑：

    $ kubectl edit vertica-db

  2. 在 spec 下嵌套的 subclusters 子部分中，找到要删除的子群集。删除子群集数组中代表要删除的子群集的元素。每个元素由连字符 (-) 标识。

  3. 删除子群集并保存后，您会收到类似如下的消息：

    verticadb.vertica.com/vertica-db 已编辑 (verticadb.vertica.com/vertica-db edited)

2 - VerticaAutoscaler 自定义资源

VerticaAutoscaler 自定义资源 (CR) 是一个 HorizontalPodAutoscaler，它使用以下策略之一自动扩展现有子群集的资源：

  • 运行时间较短的仪表板查询的子群集扩展。

  • 用于运行时间较长的分析查询的 Pod 扩展。

VerticaAutoscaler CR 使用资源或自定义指标进行扩展。Vertica 按工作负载管理子群集，这有助于您确定最佳指标以触发扩展事件。为了保持数据完整性，除非与 pod 的所有连接都已耗尽且会话已关闭，否则运算符不会缩减规模。

有关确定 VerticaAutoscaler 何时扩展的算法的详细信息，请参阅 Kubernetes 文档。

此外，VerticaAutoscaler 提供了一个 webhook 来验证状态更改。默认情况下，此 webhook 已启用。您可以使用 webhook.enableHelm 图表参数配置此 webhook。

参数

示例

此部分中的示例使用以下 VerticaDB 自定义资源。每个示例都使用 CPU 来触发扩展：

apiVersion: vertica.com/v1beta1
kind: VerticaDB
metadata:
  name: dbname
spec:
  communal:
    path: "path/to/communal-storage"
    endpoint: "path/to/communal-endpoint"
    credentialSecret: credentials-secret
  subclusters:
    - name: primary1
      size: 3
      isPrimary: true
      serviceName: primary1
      resources:
        limits:
          cpu: "8"
        requests:
          cpu: "4"

先决条件

  • 为触发扩展的指标设置一个值。例如，如果要按 CPU 利用率进行扩展，则必须设置 CPU 限制和请求。

子群集扩展

自动调整自定义资源中的子群集数量，以针对运行时间较短的仪表板查询优化资源。例如，增加子群集的数量以提高吞吐量。有关详细信息，请参阅使用子群集提高查询吞吐量。

所有子群集共享相同的服务对象，因此无需更改外部服务对象。新子群集中的 Pod 由现有服务对象进行负载均衡。

以下示例创建了一个 VerticaAutoscaler 自定义资源，当 VerticaDB 使用 50% 的节点可用 CPU 时，该资源将按子群集进行扩展：

  1. 在 YAML 格式的清单中定义 VerticaAutoscaler 自定义资源：

    apiVersion: vertica.com/v1beta1
kind: VerticaAutoscaler
metadata:
  name: autoscaler-name
spec:
  verticaDBName: dbname
  scalingGranularity: Subcluster
  serviceName: primary1

  2. 使用 kubectl autoscale 命令创建 VerticaAutoscaler：

    $ kubectl autoscale verticaautoscaler autoscaler-name --cpu-percent=50 --min=3 --max=12

    上一命令创建了一个 HorizontalPodAutoscaler 对象：

    • 将目标 CPU 利用率设置为 50%。

    • 扩展到一个子群集中至少有三个 pod，四个子群集中至少有 12 个 pod。

Pod 扩展

对于长时间运行的分析查询，增加子群集的 pod 计数。有关 Vertica 和分析查询的其他信息，请参阅使用 Elastic Crunch Scaling 提高查询性能。

在 Eon 模式数据库中扩展 pod 时，必须考虑对数据库分片的影响。有关详细信息，请参阅分片和订阅。

以下示例创建了一个 VerticaAutoscaler 自定义资源，当 VerticaDB 占用 50% 的节点可用 CPU 时，该资源将按 pod 进行扩展：

  1. 在 YAML 格式的清单中定义 VerticaAutoScaler 自定义资源：

    apiVersion: vertica.com/v1beta1
kind: VerticaAutoscaler
metadata:
  name: autoscaler-name
spec:
  verticaDBName: dbname
  scalingGranularity: Pod
  serviceName: primary1

  2. 使用 kubectl autoscale 命令创建 autoscaler 实例：

    $ kubectl autoscale verticaautoscaler autoscaler-name --cpu-percent=50 --min=3 --max=12

    上一命令创建了一个 HorizontalPodAutoscaler 对象：

    • 将目标 CPU 利用率设置为 50%。

    • 扩展到一个子群集中至少有三个 pod，四个子群集中至少有 12 个 pod。

事件监控

要查看 VerticaAutoscaler 对象，请使用 kubectl describe hpa 命令：

$ kubectl describe hpa autoscaler-name
Name:                                                  as
Namespace:                                             vertica
Labels:                                                <none>
Annotations:                                           <none>
CreationTimestamp:                                     Tue, 12 Apr 2022 15:11:28 -0300
Reference:                                             VerticaAutoscaler/as
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  0% (9m) / 50%
Min replicas:                                          3
Max replicas:                                          12
VerticaAutoscaler pods:                                3 current / 3 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range

当发生扩展事件时，您可以查看 admintools 命令来扩展群集。使用 kubectl 查看 StatefulSets：

$ kubectl get statefulsets
NAME                                                   READY   AGE
db-name-as-instance-name-0                             0/3     71s
db-name-primary1                                       3/3     39m

使用 kubectl describe 查看正在执行的命令：

$ kubectl describe vdb dbname | tail
  Upgrade Status:
Events:
  Type    Reason                   Age   From                Message
  ----    ------                   ----  ----                -------
  Normal  ReviveDBStart            41m   verticadb-operator  Calling 'admintools -t revive_db'
  Normal  ReviveDBSucceeded        40m   verticadb-operator  Successfully revived database. It took 25.255683916s
  Normal  ClusterRestartStarted    40m   verticadb-operator  Calling 'admintools -t start_db' to restart the cluster
  Normal  ClusterRestartSucceeded  39m   verticadb-operator  Successfully called 'admintools -t start_db' and it took 44.713787718s
  Normal  SubclusterAdded          10s   verticadb-operator  Added new subcluster 'as-0'
  Normal  AddNodeStart             9s    verticadb-operator  Calling 'admintools -t db_add_node' for pod(s) 'db-name-as-instance-name-0-0, db-name-as-instance-name-0-1, db-name-as-instance-name-0-2'