操作

如何在 Kubernetes 中执行各种 Neo4j 系统操作

日志记录

通常存储为 neo4j.log 文件的 Neo4j 日志是 Kubernetes 中的 pod 日志。因此，它们不会直接写入磁盘文件，但可以通过执行 kubectl logs podname 命令访问。

debug.log 文件是一个写入 pod 内部磁盘的常规文件。从 4.1.0-4 版本及以后，默认日志路径已更改为将日志放置在持久存储上。它们通常位于容器内的 /data/logs 路径下，并设置为 Neo4j 中 dbms.directories.logs 配置参数指定的路径。

同样的位置适用于其他 Neo4j 日志文件，例如 security.log 和 query.log。

内存管理

该 chart 遵循操作手册中内存配置部分所述的相同内存配置设置。

默认方法

Neo4j-helm 的行为与常规的 Neo4j 产品相同。未设置显式的堆内存或页面缓存。内存根据 JVM 可分配的情况动态增长。

推荐方法

您可以使用设置 dbms.memory.use_memrec=true，这将运行 neo4j-admin memrec 并使用其推荐值。此 use_memrec 设置是 helm chart 的一个选项，它不是 Neo4j 的配置选项。

非常重要的是，您在启动时也必须指定足够的 CPU 和内存资源以支持推荐值。如果推荐的内存量高于 Kubernetes 的请求/限制，将导致 pod 崩溃、“unscheduleable”错误和其他问题。

自定义显式设置

您可以设置以下任何设置。helm chart 接受这些设置，与 neo4j.conf 文件中使用的名称一致。

  • dbms.memory.heap.initial_size

  • dbms.memory.heap.max_size

  • dbms.memory.pagecache.size

  • dbms.memory.transaction.memory_allocation

  • dbms.memory.transaction.max_size

  • dbms.memory.transaction.global_max_size

它们的含义、格式和默认值与操作手册中找到的相同。有关如何为您的数据库设置这些设置，请参阅“将自定义配置作为 ConfigMap 传递”部分。

要查看此自定义配置用于单实例的示例，请参阅独立自定义内存配置部署场景。

监控

此 chart 支持 Neo4j 操作手册中描述的相同监控配置设置。这些设置已从上表中省略，因为它们已在操作手册中记录，但这里有三个快速示例

  • 要发布 prometheus 指标，请使用 --set metrics.prometheus.enabled=true,metrics.prometheus.endpoint=0.0.0.0:2004

  • 要发布 graphite 指标，请使用 --set metrics.graphite.enabled=true,metrics.graphite.server=localhost:2003,metrics.graphite.interval=3s

  • 要调整 CSV 指标（默认启用），请使用 metrics.csv.enabled 和 metrics.csv.interval。

  • 要禁用 JMX 指标（默认启用），请使用 metrics.jmx.enabled=false。

数据持久性

最重要的数据保存在附加到每个核心集群成员的 /data 卷中。这些卷在 Kubernetes 中映射到 PersistentVolumeClaims (PVC)，并且在您运行 helm uninstall mygraph 时不会被删除。

建议您研究持久卷声明的 storageClass 选项，并选择低延迟的 SSD 磁盘以获得 Neo4j 的最佳性能。您需要选择的 storageClass 名称会因不同的 Kubernetes 分发版而异。

重要：PVC 会在 Neo4j 安装之间保留数据。如果您以名称“mygraph”部署一个集群，稍后将其卸载，然后再次以相同的名称重新安装，则新实例将继承来自现有 PVC 的所有旧数据。这包括用户名、密码、角色等内容。

为了进一步提高数据的持久性，建议进行定期备份。

其他存储

该 helm chart 支持为核心和读副本集设置 additionalVolumes 和 additionalVolumeMounts 值。这些可用于在容器内部设置任意额外的挂载驱动器。如何精确指定取决于用户，因为它取决于您是想使用现有 PVC、挂载 configmap 还是其他设置。此功能旨在提供存储灵活性，以注入文件，例如 apoc.conf、初始化脚本或导入目录。

但不支持使用额外的卷和挂载，要使用此功能，您必须非常熟悉 Kubernetes 中的文件系统基础知识和 Neo4j 目录配置。

Fabric

在 Neo4j 4.0+ 中，fabric 是一项可以通过在 neo4j.conf 中进行常规配置来启用的功能。手册中引用的所有 fabric 配置都可以通过本文档中描述的自定义 ConfigMaps 完成。

简单用法

这里有一个此方法的简单示例。

在 kubernetes 中使用 Neo4j Fabric 归结为像正常一样配置产品，但采用“docker 样式”。在 neo4j 操作手册中，它可能会告诉您设置 fabric.database.name=myfabric，而在 kubernetes 中则为 NEO4J_fabric_database_name: myfabric，依此类推。

所以这相当简单。但这只是故事的一半。另一半是，fabric 部署拓扑是什么？

Fabric 拓扑

Fabric 支持一些非常复杂的设置。如果您有一个单个 DBMS，您可以通过纯配置来实现，并且它会起作用。如果您有多个 DBMS，那么幕后的工作方式是通过账户/角色协调以及集群之间的 bolt 连接。

这反过来意味着您需要设置网络路由，以便集群 A 可以与集群 B 通信（参考上面链接的图表）。这主要是 kubernetes 网络方面的设置，不算太奇特，但这需要仔细规划。

当架构变得庞大/复杂时，情况就变得复杂了。假设您使用 fabric 来存储一个巨大“客户图谱”的分片。美国客户的分片存在于一个地理区域，而欧盟客户的分片存在于另一个地理区域。您可以使用 fabric 查询这两个分片，并在所有地理区域上获得“客户图谱”的逻辑视图。然而，要在 kubernetes 中实现这一点，意味着需要在两个不同的地理区域中拥有 kubernetes 节点池，并且几乎肯定需要 2 个不同的 neo4j 集群。要在它们之间启用 bolt 连接（允许 fabric 工作），则需要专门针对 kubernetes 进行更高级的网络设置。但对于作为产品的 neo4j 来说，这都是一样的。我能连接到远程源的 neo4j/bolt 吗？可以？那么它应该没问题。

Fabric 工作原理 Fabric 需要 3 件事才能工作

  1. 在所有参与 fabric 查询的数据库上具有相同用户/角色（例如 neo4j/admin）

  2. 能够连接到所有参与 fabric 查询的集群成员的 bolt 连接

  3. 一些配置。

自定义 configmaps（本节中讨论）涵盖了第 3 条。您的安全配置（无论您选择什么）涵盖了第 1 条，并且不是 kubernetes 特定的。而第 2 条取决于您的部署拓扑，kubernetes 网络可能会或可能不会介入。在最简单的单个 DBMS 配置中，我认为它可以开箱即用。

自定义 Neo4j 配置

由于 neo4j-helm 将 Neo4j 作为 docker 容器运行，请确保您理解Neo4j Docker 配置参考中关于环境变量命名以及环境变量如何转化为配置的内容。

使用 ConfigMaps

Neo4j 集群 pod 分为两组：核心（cores）和副本（replicas）。这些 pod 可以通过 ConfigMaps 进行配置，ConfigMaps 包含环境变量。这些环境变量又根据 Neo4j 环境变量配置用作底层 Neo4j Docker 容器的配置设置。

因此，您可以通过创建自己的 Kubernetes configmap 并按如下方式使用它来设置任何自定义 Neo4j 配置

--set core.configMap=myConfigMapName --set readReplica.configMap=myReplicaConfigMap
某些网络特定设置的配置仍在容器启动时完成，并且这一小部分变量仍可能被 helm chart 覆盖，特别是容器的通告地址和主机名。

使用 Secrets

您还可以在核心集或读副本集中指定 envFrom，以便使用任意数量的附加 config maps 和 secrets 来注入附加配置，这些配置在其他配置层之后最后应用。

以下是实现此目标的 values 文件示例

core:
    standalone: true
    envFrom:
        - secretRef:
            name: my-secret-config

my-secret-config 中的所有键和值都将作为环境变量注入。以这种方式使用注入到配置中的 kubernetes secrets 是指定密码的好选择。

扩缩容

以下部分描述了关于在运行时更改集群大小以处理更多请求的注意事项。扩缩容仅适用于因果集群，独立实例无法以这种方式进行扩缩容。

规划

在对运行在 kubernetes 上的数据库进行扩缩容之前，请务必深入查阅 Neo4j 集群架构文档，并特别注意仔细选择是添加核心节点还是读副本。此外，此规划过程应注意包含 kubernetes 层的详细信息以及节点池所在位置。例如，如果所有 kubernetes 节点都位于同一区域，添加额外的核心节点以增加冗余来保护数据可能无法提供额外的保证。

对于许多用户和用例，仔细规划初始数据库大小比后期尝试快速扩缩集群更可取。

当向 neo4j 集群添加新节点时，节点加入集群后需要从集群中的其他节点复制现有数据。因此，这可能会在剩余节点向新成员复制数据时造成临时的更高负载。对于非常大的数据库，这可能在重负载下导致临时不可用。我们建议在设置可扩缩的 Neo4j 实例时，您配置 pod 在启动前从最近的备份集恢复。本仓库提供了如何恢复的说明。这样，新 pod 在进入集群之前大部分数据已赶上，并且“赶上”过程在所花费的时间和对集群其余部分造成的负载方面都是最小的。

由于任何数据库都具有数据密集型特性，因此强烈建议在扩缩容前仔细规划。每个新节点还需要分配存储空间；因此，在对数据库进行扩缩容时，kubernetes 集群将创建新的持久卷声明和 GCE 卷。

由于 Neo4j 在单节点模式下 (dbms.mode=SINGLE) 的配置不同，如果部署最初设置为 1 个 coreServer，则不应对其进行扩缩容。这将导致多个独立的数据库，而不是一个集群。

执行 (手动扩缩容)

Neo4j-Helm 包括一个用于核心节点的 StatefulSet 和一个用于副本的 Deployment。在配置中，即使您选择零副本，您也会看到一个成员数为零的 Deployment。

对数据库进行扩缩容是扩缩其中一个元素的事情。

根据您的数据库大小和集群中其他成员的繁忙程度，新成员连接到集群并执行追赶操作后，集群拓扑可能需要相当长的时间才能显示新成员的存在。新节点追赶完成后，您可以执行 cypher 查询 CALL dbms.cluster.overview(); 来验证新节点是否正常运行。

执行 (自动扩缩容)

该 helm chart 提供了为读副本提供HorizontalPodAutoscaler 的设置，该 autoscaler 可以根据底层 pod 的 CPU 利用率自动扩缩容。有关此功能的用法，请参阅上面支持设置中记录的 readReplica.autoscaling.* 设置。

有关其工作原理和涉及内容的更多详细信息，请查阅kubernetes 关于 HorizontalPodAutoscalers 的文档。

自动扩缩容仅适用于读副本。目前，我们完全不建议对集群的核心成员进行自动扩缩容，核心成员的扩缩容应仅限于特殊操作，例如滚动升级，这部分内容已另行记录。

警告和提示

扩缩容的 pod 从其 statefulset 继承配置。对于 neo4j，这意味着已配置的存储大小、硬件限制和密码等项目适用于扩容的成员。

如果缩容，不要缩减到少于三个核心节点；这是保证正常运行且具有数据冗余的集群所需的最低数量。有关更多信息，请查阅 neo4j 集群文档。Neo4j-Helm 使用 PVC，因此如果您扩容然后稍后缩容，这可能会导致底层 PVC 成为孤儿，您可能需要在以后手动删除它。

反亲和性规则

对于生产环境部署，建议使用反亲和性规则，即有意将 pod 部署分散到不同的 Kubernetes 工作节点上。这能改善 Neo4j 的故障特性。如果 Kubernetes 无意中将所有 3 个核心 Neo4j pod 部署到单个工作节点上，并且该工作节点 VM 发生故障，则整个集群将宕机。因此，建议使用反亲和性规则来“分散部署”。

部署场景目录中提供了如何配置此项并附有文档参考的示例。

Service account 注解

helm chart 设置允许为核心和副本服务使用的 service account 添加注解。这使得 Kubernetes service account 可以绑定到云 IAM 角色，从而提高安全性。有关更多详细信息，请参阅 [AWS](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html) 和 [GCP](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) 的文档。

© . All rights reserved.