TrueNAS Scale之应用异常修复

背景

今早起来TrueNAS Scale(TNS）服务异常了，一脸懵逼？！

事件是这样的：

我在NUC11之上PVE下安装了个TrueNas Scale来体验一下，整体感受还不错，简单直观没有花哨功能。于是最近正在考虑将个人网盘从原本QNAP的Qsync迁移到Truenas下nextcloud中（当然在qnap下也可以nextcloud但是实测性能有些问题）。

现在我完全放弃了这个想法，让子弹再飞一会，可以先在qnap下玩基于容器的nextcloud。不过遇到问题咱不能逃避是吧？那么以下是定位和修复过程的记录，希望给遇到类似问题的人一个参考。

错误现象

定位和修复过程

查看k3s日志

显然k3s没起来，再次重启service k3s start也报错，通过journalctl -xe的日志可看到：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
░░ The job identifier is 3124.
Jul 10 10:54:57 truenas k3s[7142]: time="2022-07-10T10:54:57+08:00" level=info msg="Starting k3s v1.23.5+k3s-937d546a-dirty (937d546a)"
Jul 10 10:54:57 truenas k3s[7142]: time="2022-07-10T10:54:57+08:00" level=info msg="Configuring sqlite3 database connection pooling: maxIdleConns=2, maxOpenConns=0, connMaxLifetime=0s"
Jul 10 10:54:57 truenas k3s[7142]: time="2022-07-10T10:54:57+08:00" level=info msg="Configuring database table schema and indexes, this may take a moment..."
Jul 10 10:54:57 truenas k3s[7142]: time="2022-07-10T10:54:57+08:00" level=info msg="Database tables and indexes are up to date"
Jul 10 10:54:57 truenas k3s[7142]: time="2022-07-10T10:54:57+08:00" level=info msg="Kine available at unix://kine.sock"
Jul 10 10:54:57 truenas k3s[7142]: time="2022-07-10T10:54:57+08:00" level=fatal msg="starting kubernetes: preparing server: failed to normalize token; must be in format K10<CA-HASH>::<USERNAME>:<PASSWORD> or <PASSWORD>"
Jul 10 10:54:57 truenas systemd[1]: k3s.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit k3s.service has exited.

主要错误描述：

1
Jul 10 10:54:57 truenas k3s[7142]: time="2022-07-10T10:54:57+08:00" level=fatal msg="starting kubernetes: preparing server: failed to normalize token; must be in format K10<CA-HASH>::<USERNAME>:<PASSWORD> or <PASSWORD>"

查看token

既然报token有问题，查看k3s配置的token，它和社区版本的k3s默认安装位置不一样。你可以通过如下命令查找：

1
find / -type f -name "token"

我的位置在：/mnt/ZHITAI/ix-applications/k3s/server/token，发现内容为空，或许这就是异常根源。注意同目录下有node-token文件，是它链接到token文件，是同一个玩意。

尝试替换token

随便拷贝了一个token过去，看是否有变化： K10c22f9d333f7325xxxxxxxxxxxxxxx::server:home-k3s-cluster

再重启k3s，继续有如下报错（略有不同但符合预期）: Jul 10 11:25:01 truenas k3s[32209]: time="2022-07-10T11:25:01+08:00" level=fatal msg="starting kubernetes: preparing server: bootstrap data already found and encrypted with different token"

那么，如何得到这个集群的原来的token？ 分析node-token的构成，网上有这篇文章（# k3s原理分析丨如何搞定k3s node注册失败问题）

查看服务器passwd

所幸我们server下的配置没全丢失。

1
2
3
root@truenas[/mnt/ZHITAI/ix-applications/k3s/server]# cat cred/passwd
68c121cba712e3c2a42393013ff9379a,node,node,k3s:agent
68c121cba712e3c2a42393013ff9379a,server,server,k3s:server

可看到服务器passwd是68c121cba712e3c2a42393013ff9379a，我们用它修改token的最后一段。

修改node-token

将token修改为： K10c22f9d333f7325xxxxxxxxxxxxxxx::server:==68c121cba712e3c2a42393013ff9379a==

重启k3s

1
service k3s start

仍然报错？(在写这篇文章时尝试重现，在这一步又直接成功了，如果你还报错继续往下看。)

service配置

修改k3s服务的启动参数，添加上我们指定的token(password)？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
root@truenas[.../ZHITAI/ix-applications/k3s/server/db]# cat /lib/systemd/system/k3s.service
[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=notify
KillMode=process
Delegate=yes
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
TimeoutStartSec=0
Restart=always
RestartSec=5s
ExecStartPre=-/sbin/modprobe br_netfilter
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/k3s \
    server \
        '--flannel-backend=none' \
        '--disable=traefik,metrics-server,local-storage' \
        '--disable-kube-proxy' \
        '--disable-network-policy' \
        '--disable-cloud-controller' \
        '--node-name=ix-truenas' \
        '--token=68c121cba712e3c2a42393013ff9379a' \ #加上这一行，指定启动的token
        '--docker' \

注意在==ExecStart==内添加一行参数，再systemctl daemon-reload。然后再重启，终于没报错了。注意可以再次cat token看一下，前面的一串所谓的CAHash已经被自动修复了。

这时通过k3s kubectl get pod -A 看到有不少Pod一直起不来或重启中，不管了，重启一下truenas系统。

重启过后

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
root@truenas[~]# k get po -w -A
NAMESPACE      NAME                                  READY   STATUS    RESTARTS        AGE
ix-qb          qb-qbittorent-58f649b6c5-2s5dl        1/1     Running   1 (90m ago)     7d
kube-system    openebs-zfs-controller-0              5/5     Running   5 (90m ago)     7d11h
kube-system    openebs-zfs-node-nkpzx                2/2     Running   12 (114s ago)   7d11h
kube-system    coredns-d76bd69b-5j7w9                1/1     Running   0               11m
ix-nextcloud   nextcloud-postgres-566895fbf5-xcqsn   1/1     Running   0               12m
ix-nextcloud   nextcloud-56497dfb66-tr4x8            1/1     Running   1 (90m ago)     4d11h
ix-netdata     netdata-786b756c77-qlfqb              1/1     Running   1 (90m ago)     3d12h
ix-plex        plex-5fddb99dd9-2gqhg                 1/1     Running   2 (106s ago)    7d

一切回归正常了。

事后

在此过程浏览TNS的论坛等地方，发现大家对于在TrueNAS Scale中选择k3s作为默认的应用管理是有探讨的，确实有时它太复杂了容易出错，在TNS中使用standalone模式而非集群下，引入的复杂性又没有获得多少好处，我同样觉得有待商榷。用docker/docker-compose它不香嘛？这不，我的k3s node又出问题了？！！！