I had a discussion with a colleague today and we w...
# rke2
b
I had a discussion with a colleague today and we were not able to answer a simple kubelet question: How many (and which) verbosity level are supported by kubelet? There is nothing about that in the RKE2 documentation. Also the k8s docs are happily not providing a value. If you google for it or ask any LLMs, results are in between 4 and 10. Probably 9 (0-8) is correct, but where is this documented? Any hints?
c
why are you searching RKE2 docs for Kubernetes stuff?
Also, there is not really an upper limit. The question would just be, what is the maximum level used by the code.
b
I would expect this information in the product documentation. But there is not even a link to the k8s docs for e.g. kubelet-args.
c
You’re a Kubernetes admin and you don’t know where to find kubernetes docs?
b
You don't call this the answer to my question, do you? It simply says "level".
c
here are the verbosities of log messages present int the kubernetes source code. Took me 10 seconds to answer this question against a checked out version of the source code.
Copy code
brandond@dev01:~/go/src/github.com/kubernetes/kubernetes$ grep -rhEo '\.V\([0-9]+\)' pkg/ staging/ | sort | uniq -c
    125 .V(1)
     39 .V(10)
      1 .V(11)
    488 .V(2)
    368 .V(3)
   1195 .V(4)
    555 .V(5)
    118 .V(6)
     53 .V(7)
     21 .V(8)
      5 .V(9)
      2 .V(99)
you can set it to any level. You’ll see all messages logged at that lever or lower. That is generally how log verbosity works, regardless of logging framework or project.
b
I know how log verbosities are working. Do you really expect end users to grep through source code?
c
what is the maximum SUPPORTED? Anything up to max integer value. But as that shows you won’t see anything new above level 99
if you want to know what levels the code uses then yes you need to look at the code. Its just an integer so the code can use any integer value for its messages.
See also https://kubernetes.io/docs/concepts/cluster-administration/system-logs/#log-verbosity-level
The
-v
flag controls log verbosity. Increasing the value increases the number of logged events. Decreasing the value decreases the number of logged events. Increasing verbosity settings logs increasingly less severe events. A verbosity setting of 0 logs only critical events.
as the docs say, higher numbers get you more logs. Why did you need to know what the maximum possible value is?
b
I went there today already a couple of times. And you also expect your users (and customers) to find this information themselves by grepping through your code? The next question would be: What kind of information is the particular product log showing with which particular verbosity.
One user was asking me about some events he was missing in the kubelet log. I was not able to tell him what verbosity level to try. He tried 8 (obviously not max, as stated here https://www.suse.com/support/kb/doc/?id=000021568 ). So you expect me to tell him to just try any arbitrary number below 99? Really?
c
this is not “our” code. RKE2 is a Kubernetes distribution. We build and package code from many different projects and handle integrating the components. For questions about Kubernetes, you should be looking to Kubernetes docs and the Kubernetes project maintainers. We only document things that are specific to RKE2.
If you are “missing” a message in the logs, and want to turn up the log level to see it, you would need to know the log level associated with that specific message, yes.
If I wanted to find that out I’d search for the “missing” log string in the source code. There is no document that lists EVERY possible log message and its verbosity. That is why we use open source code.
b
Maybe this attitude really makes a difference. It might not be your code, but it's your product. If I check your competition (Redhat), they have at least a basic description about the possible values. They also rely on upstream, but take the documentation of their product seriously.
c
🤷 If you have a support contract, raise an issue with your account manager and they can get someone from the SUSE docs team on it. I’m an engineer and you’re on the free community support slack. I’m not going to spend time writing docs for other projects - I have enough of my own code to document.
if you don’t have a support contract then you should contribute something back and open a docs PR to add whatever you think is missing.
b
I don't blame you personally. I even thank you for your answers and won't open a support call. I guess your support colleagues would "appreciate" such support requests and hopefully throw things at the docs department.
c
The support folks do have access to add or modify those suse KBs. Engineers do not. All we maintain is the main rke2 and k3s docs sites and as I said - only have resources to cover things that are specific to the product.
So if you opened a ticket with them they would possibly be able to address some of your notes on that KB doc.
b
You are one company, Suse, aren't you? (rhetorical question) There would be no need for those "SUSE" KBs if the RKE2 docs would cover these topics (It's not just this issue, it's nearly all k8s specific KBs.) No offense to you. I just notice a pattern.
Thanks anyway for your help! I appreciate it.
c
We’re one company yes. But like any large company, we have multiple teams and organizations. Support org handles KBs based on customer requests, engineering handles docs for things that we maintain.
FYI if you are a partner supporting our products there should be a Partner slack. Community user slack is probably not the best place for this discussion if you have an existing relationship.