Sajo
2021 年6 月 18 日 07:57
1
nebula 版本:2.0.0
部署方式:k8s
是否为线上版本:Y
问题的具体描述
因为是自研 kubernetes 管理平台,权限管理比较严格,不能创建CRD资源,故手动部署。
参考 nebula-operator 部署的配置 分别部署了 metad,graphd 和 storaged
出现了如下的问题
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
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 个赞
Sajo
2021 年6 月 18 日 08:31
3
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都选举失败。
Sajo
2021 年6 月 18 日 08:47
6
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 是吗?
Sajo
2021 年6 月 18 日 08:55
8
没问题的 能正常访问 curl nebula-metad-0:19559 能拿到 running 的信息
另外我们的 headleess service 要 pod 中 container 全部启动之后才能访问到,解析也是一样(可能与原生k8s不一致)
Sidecar 可能在 metad 之后才启动,metad启动时可能是解析不到 nebula-metad-0的 这个也许是一部分原因?
是的, 那应该是这个问题。我们的 metad 的 service 会设置 PublishNotReadyAddresses 的。不知道你们有没有类似的?
可能是 meta pod 没有ready 的时候需要访问地址来进行选举; 而没有 ready 的时候又不会提供地址访问;如此糙成了互相依赖。
Sajo
2021 年6 月 18 日 09:17
12
除了这个问题,我在 command 中修改启动参数,发现修改 日志等级 v=0 到 v=1 运行的参数仍然还是 v=0
但是修改 Networking 的参数能够生效,比如 ws_h2_port 都是没问题的 这种一般是什么问题?
Sajo:
minloglevel
你将参数 minloglevel 设置为 0 试试
Sajo
2021 年6 月 21 日 02:43
14
Metad 选举的问题在添加 PublishNotReadyAddresses 之后解决了。但是多个 Metad 服务启动时顺序不一样会出现不同的结果和报错,需要测试看有没有具体的影响。
minloglevel 设置为 0 之后,v 的级别可以修改了。
目前 kubernetes 上能修改的参数与文档中的是一致的吗?还是有什么特殊的限制?
Sajo
2021 年6 月 22 日 06:26
16
@veezhang
Metad 的报错没有影响,运行没有问题。
参数是指容器中启动时使用的 flag 值,想确定的是文档中给的可配置参数都可以以 flag 的形式进行添加?还是只能配置 Nebula Operator 创建的 ConfigMap 中包含的参数?
@Sajo
都可以的, 命令行优先于配置。
我们自己的 operator 这里是不能改命令行参数的,可以通过 ConfigMap。你们自己的倒是可以用命令行参数。
system
关闭
2021 年6 月 29 日 06:37
20
该主题在最后一个回复创建后7天后自动关闭。不再允许新的回复。