https://rancher.com/ logo
#k3s
Title
# k3s
a

adamant-kite-43734

09/26/2022, 5:30 AM
This message was deleted.
c

creamy-pencil-82913

09/26/2022, 5:45 AM
I have honestly never seen that happen. Unless there is something wrong with the database, K3s should be able to run for years before you get anywhere near hitting sqlite’s maximum integer value for the ID field. You could try doing
ALTER TABLE kine CHANGE id id BIGINT NOT NULL AUTO_INCREMENT
but this hasn’t been tested, obviously should not be done while the database is in use, and may take a while to run. Would you mind opening an issue in the K3s repo describing your environment? I’d like to understand what might have caused this.
l

limited-potato-16824

09/26/2022, 5:49 AM
This cluster have been up and running for 18 months and have ~200 nodes. I was thinking of changing id to BIGINT but realized that this might break stuff. I'll create a issue in the k3s repo
c

creamy-pencil-82913

09/26/2022, 5:52 AM
Hmm. 200 nodes is definitely on the larger side for a k3s cluster. More important is going to be the churn rate on cluster resources though, which will depend on what you have deployed to it and how much it actually stores in kubernetes vs just being orchestrated by it. What version of K3s are you currently on?
l

limited-potato-16824

09/26/2022, 5:57 AM
We are still on v1.22.12+k3s1
Deployments to the cluster is done with Rancher Fleet, and we do deployments several times per day. Fleet deployments do create a lot of secrets that is stored in the database, we have set a history limit to 2 for all Fleet deployments.
We have other deployments as well, where the largest one have 409 clients so I guess will will run into this issue there as well.
@creamy-pencil-82913 if we try to change the int for id, we would need to change the other int's as well in the table right? I'm not very savvy with SQL
FYI, we dropped the indexes and did a alter table and now using bigint
102 Views