操作

如何在 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。

内存管理

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

默认方法

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

推荐方法

您可以使用设置 dbms.memory.use_memrec=true，这将运行 neo4j-admin memrec 并使用其建议。此 use_memrec 设置是 helm 图表的选项，而不是 Neo4j 配置选项。

非常重要的是，您还必须在启动时指定足以支持建议的 CPU 和内存资源。如果推荐的内存量高于 Kubernetes 请求/限制，则会导致 Pod 崩溃、“不可调度”错误和其他问题。

自定义显式设置

您可以设置以下任何设置。helm 图表接受这些设置，镜像 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 传递”部分，了解如何为您的数据库设置这些设置。

要查看此自定义配置在单实例中使用的示例，请参阅 独立自定义内存配置部署方案。

监控

此图表支持 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 图表支持核心和只读副本集的 additionalVolumes 和 additionalVolumeMounts 值。这些可用于在容器内部设置任意额外的挂载驱动器。如何具体指定这一点留给用户决定，因为它取决于您是想使用现有的 PVC、挂载 configmap 还是其他设置。此功能旨在提供存储灵活性以注入文件，例如 apoc.conf、初始化脚本或导入目录。

但是，不支持使用其他卷和挂载，并且为了使用此功能，您必须非常熟悉 Kubernetes 和 Neo4j 目录配置中的文件系统基础知识。

Fabric

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

简单用法

此方法的一个简单的实际示例可以在这里找到。

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

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

Fabric 拓扑

Fabric 启用了一些非常复杂的设置。如果您有一个**单个数据库管理系统**，您可以使用纯配置来完成它，它将起作用。如果您有多个数据库管理系统，那么幕后工作方式是通过帐户/角色协调以及集群之间的 bolt 连接。

反过来意味着您需要设置网络路由位，以便集群 A 可以与集群 B 通信（参考上面链接的图表）。这主要会是 kubernetes 网络方面的东西，没什么稀奇的，但这需要仔细计划。

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

Fabric 的工作原理 Fabric 需要工作的三件事

  1. 一个用户/角色（例如 neo4j/admin），在所有受 fabric 查询影响的数据库上都是相同的

  2. 能够与参与 Fabric 查询的所有集群成员建立 Bolt 连接

  3. 一些配置。

自定义 ConfigMap（本节将对此进行讨论）涵盖了 #3。您的安全配置（无论您选择哪种）将涵盖 #1，并且与 Kubernetes 无关。而 #2 是 Kubernetes 网络可能或可能不会介入的地方，具体取决于您的部署拓扑。在最简单的单一 DBMS 配置中，我认为它将开箱即用。

自定义 Neo4j 配置

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

使用 ConfigMap

Neo4j 集群 Pod 分为两组：核心和副本。这些 Pod 可以使用 ConfigMap 进行配置，ConfigMap 包含环境变量。然后，这些环境变量根据 Neo4j 环境变量配置用作底层 Neo4j Docker 容器的配置设置。

因此，您可以通过创建自己的 Kubernetes ConfigMap 并像这样使用它来设置任何自定义 Neo4j 配置

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

使用 Secrets

您还可以指定核心集或读取副本集中envFrom，以使用任意数量的附加 ConfigMap 和 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 提供了设置，这些设置可用于为读取副本提供水平 Pod 自动缩放器，该缩放器可以根据底层 Pod 的 CPU 利用率自动进行扩展。有关此功能的使用，请参阅上面支持的设置中记录的 readReplica.autoscaling.* 设置。

有关其工作原理和涉及内容的更多详细信息，请查阅Kubernetes 关于水平 Pod 自动缩放器的文档。

自动扩展仅适用于读取副本。目前，我们根本不建议自动扩展集群的核心成员，核心成员扩展应仅限于特殊操作，例如单独记录的滚动升级。

警告和指示

扩展的 Pod 从其 StatefulSet 继承其配置。对于 Neo4j，这意味着配置的存储大小、硬件限制和密码等项目适用于扩展成员。

如果缩减规模，请勿缩减到低于三个核心节点；这是保证具有数据冗余的正常运行集群所需的最低限度。请参阅 Neo4j 集群文档以获取更多信息。Neo4j-Helm 使用 PVC，因此，如果您扩展然后缩减，这可能会使底层 PVC 成为孤儿，您可能需要稍后手动删除它。

反亲和规则

对于产品化安装，建议使用反亲和规则，其中 Pod 部署有意分散在 Kubernetes 工作节点之间。这提高了 Neo4j 的故障特征。如果 Kubernetes 无意中将所有 3 个核心 Neo4j Pod 部署到单个工作节点，并且底层工作节点 VM 发生故障，则整个集群将停止运行。因此，建议使用反亲和规则来“分散部署”。

部署方案目录中提供了有关如何使用文档参考配置此内容的示例。

服务帐户注释

helm chart 设置允许注释核心和副本服务使用的服务帐户。这允许将 Kubernetes 服务帐户绑定到云 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) 的文档。