NebulaGraph 在 K8s 平台上的手动部署中出现的问题

  • nebula 版本:2.0.0
  • 部署方式:k8s
  • 是否为线上版本:Y
  • 问题的具体描述
    因为是自研 kubernetes 管理平台,权限管理比较严格,不能创建CRD资源,故手动部署。
    参考 nebula-operator 部署的配置 分别部署了 metad,graphd 和 storaged
    出现了如下的问题
  1. Metad 服务配置 meta_server_addrs 参数后,Raft选举失败
    不管是单个 Metad pod 还是多个 只要配置了 meta_server_addrs 参数,Raft选举就会失败

附上 nebula-metad.INFO 日志

E0618 06:39:29.761852    50 RaftPart.cpp:1143] [Port: 9560, Space: 0, Part: 0] Receive response about askForVote from "nebula-metad-0":9560, error code is -9
E0618 06:39:31.712163    47 RaftPart.cpp:1143] [Port: 9560, Space: 0, Part: 0] Receive response about askForVote from "nebula-metad-1":9560, error code is -9
  1. Metad 使用与原生 k8s 中 nebula-operator 生成的启动参数会失败
      command:
        - /bin/bash
        - '-ecx'
        - >-
          exec /usr/local/nebula/bin/nebula-metad
          --flagfile=/usr/local/nebula/etc/nebula-metad.conf
          --meta_server_addrs=nebula-metad-0:9559 --local_ip=nebula-metad-0 
          --ws_ip=nebula-metad-0 --minloglevel=1 --v=0 --daemonize=false

metad-stderr.log

terminate called after throwing an instance of 'std::system_error'
  what():  Failed to resolve address for 'nebula-metad-0': Name or service not known (error=-2): Unknown error -2
*** Aborted at 1623999389 (unix time) try "date -d @1623999389" if you are using GNU date ***
PC: @     0x7f93b2c52387 __GI_raise
*** SIGABRT (@0x1) received by PID 1 (TID 0x7f93b3b3f980) from PID 1; stack trace: ***
    @          0x200d391 (unknown)
    @     0x7f93b2ff962f (unknown)
    @     0x7f93b2c52387 __GI_raise
    @     0x7f93b2c53a77 __GI_abort
    @          0x10dc0cb _ZN9__gnu_cxx27__verbose_terminate_handlerEv.cold
    @          0x245f5e5 __cxxabiv1::__terminate()
    @          0x245f630 std::terminate()
    @          0x245f763 __cxa_throw
    @          0x10b7441 (unknown)
    @          0x1eb7582 folly::SocketAddress::getAddrInfo()
    @          0x1eb75a3 folly::SocketAddress::setFromHostPort()
    @          0x19586ee nebula::WebService::start()
    @          0x1114399 initWebService()
    @          0x10dd812 main
    @     0x7f93b2c3e554 __libc_start_main
    @          0x1113a2d (unknown)

如果删除所有 command 内容,使用默认参数运行,没有问题,但是无法伸缩。

1 个赞

嗨,您好,可以提供您的 yaml 文件吗?

applicationName: nebula-metad-0
application:
  metadata:
    creationTimestamp: '2021-06-18T03:15:00Z'
    annotations:
      deployment.kubernetes.io/revision: '20'
    resourceVersion: '84910885'
  replicas: 1
  strategy:
    type: Recreate
  containers:
    - name: metad
      image: 'vesoft/nebula-metad:v2.0.0'
      cpu: '4'
      reqCPU: '4'
      memory: 16Gi
      reqMemory: 16Gi
      volumeMounts:
        - name: data
          mountPath: /usr/local/nebula/data
        - name: config
          mountPath: /usr/local/nebula/etc
        - name: p1p2-log
          mountPath: /usr/local/nebula/logs
      imagePullPolicy: IfNotPresent
    - name: counter
      image: 'busybox:latest'
      args:
        - /bin/sh
        - '-c'
        - tail -n+1 -f /logs/nebula-metad.INFO
      cpu: '1'
      reqCPU: '1'
      memory: 1Gi
      reqMemory: 1Gi
      volumeMounts:
        - name: p1p2-log
          mountPath: /logs
      imagePullPolicy: IfNotPresent
  restartPolicy: Always
  shutdowntime: 30
  nodeSelector:
    project: db
  dnsPolicy: ClusterFirst
  labels:
    project: db
  logDriver: syslog
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: metad-data
    - name: config
      configMap:
        name: nebula-metad
        defaultMode: 420
    - name: p1p2-log
      logAdapter:
        size: 10
        collectionType: gdc
        logType: p1p2

与原生的 yaml 有一些不一样的地方,删除了部分敏感信息
因为日志采集的问题,起了一个 busybox 去打印日志。
不配置启动 command 是可以正常服务的,但是不能伸缩,只能单点。
按文中所给的 command 启动,无论是一个还是多个,Raft都选举失败。

嗯嗯,好的,谢谢

  1. 您的启动参数是?这里面并没有
  2. 我们有使用 Kubernetes 的无头服务,不知道这个你们自研的有没有类似的功能?
  3. 你们的可以根据 applicationName 直接解析吗? 有没有 service 这种的
command:
        - /bin/bash
        - '-ecx'
        - >-
          exec /usr/local/nebula/bin/nebula-metad
          --flagfile=/usr/local/nebula/etc/nebula-metad.conf
          --meta_server_addrs=nebula-metad-0:9559 --minloglevel=1 --v=0
          --daemonize=false

这是问题1使用的启动参数
有的 所有的访问都是通过 headless service去访问的
可以 创建 Application 时会创建同名的 headless service

在同一个 ns 下面的可以 ping nebula-metad-0 是吗?

没问题的 能正常访问 curl nebula-metad-0:19559 能拿到 running 的信息
另外我们的 headleess service 要 pod 中 container 全部启动之后才能访问到,解析也是一样(可能与原生k8s不一致)
Sidecar 可能在 metad 之后才启动,metad启动时可能是解析不到 nebula-metad-0的 这个也许是一部分原因?

是的, 那应该是这个问题。我们的 metad 的 service 会设置 PublishNotReadyAddresses 的。不知道你们有没有类似的?
可能是 meta pod 没有ready 的时候需要访问地址来进行选举; 而没有 ready 的时候又不会提供地址访问;如此糙成了互相依赖。

了解了,我这边先尝试一下 谢谢 :+1:

嗯嗯, 有进展可以再来反馈下,谢谢

除了这个问题,我在 command 中修改启动参数,发现修改 日志等级 v=0 到 v=1 运行的参数仍然还是 v=0
但是修改 Networking 的参数能够生效,比如 ws_h2_port 都是没问题的 这种一般是什么问题?

你将参数 minloglevel 设置为 0 试试

Metad 选举的问题在添加 PublishNotReadyAddresses 之后解决了。但是多个 Metad 服务启动时顺序不一样会出现不同的结果和报错,需要测试看有没有具体的影响。
minloglevel 设置为 0 之后,v 的级别可以修改了。
目前 kubernetes 上能修改的参数与文档中的是一致的吗?还是有什么特殊的限制?

@Sajo

  1. Metad 服务启动时顺序会报错,如果有问题的话,可以提供下日志
  2. kubernetes 中的参数是指 NebulaCluster crd 中的 Config 吗?还是命令行的参数?这两种参数关于路径,端口等的参数不支持改,其他的像日志级别这种调优的参数可以设置。另外,Config 目前暂时不支持更新。

@veezhang
Metad 的报错没有影响,运行没有问题。
参数是指容器中启动时使用的 flag 值,想确定的是文档中给的可配置参数都可以以 flag 的形式进行添加?还是只能配置 Nebula Operator 创建的 ConfigMap 中包含的参数?

@Sajo
都可以的, 命令行优先于配置。
我们自己的 operator 这里是不能改命令行参数的,可以通过 ConfigMap。你们自己的倒是可以用命令行参数。

明白了 感谢 :heart:

不客气 :grin:

2 个赞

该主题在最后一个回复创建后7天后自动关闭。不再允许新的回复。

浙ICP备20010487号