Are you looking to maximize system performance? Could the speed and efficiency of all your apps use a boost? If you already use the Kubernetes open-source system for container-orchestration, it’s worth it to take the time to dig in and get acquainted with the cluster. How you might ask? Well it’s time to review and study your logs.
Later on, when you are faced with a major monitoring or debugging situation, that in-depth knowledge will be of immense help in bolstering system stability and tuning up important apps. But, here’s the twist: Kubernetes logs are quite different from traditional ones.
Kubernetes the Smart Way
To get started, review the basic concepts of traditional logging. On those systems, you write app logs directly to specific files, which then have two potential routes. You can view these on individual servers or simply store them in a central location for later use. Later use typically means either long-term storage or analysis.
But that paradigm doesn’t work in a Kubernetes environment because there are too many pods and their life-spans are very limited. There are Kubelets on every one of the many nodes, which means you can easily send all your output files to either stderr or stdout. The Kubelets collect and augment the output logs, which have already been segmented, into one file. Within each container, all those files are separately managed and kept under a 10 mb size ceiling.
What about Best Practices?
Like so many other systems, Kubernetes has its upsides and downsides. Of course, its high levels of efficiency and admirable performance are a direct result of the system’s incredible number of components. Ironically, this high level of sophistication and complexity means that everyday logging chores, like monitoring and retention, can be a challenge. Access in Kubernetes is usually a simple task.
The hurdle in Kubernetes logging is related to forwarding and maintenance. That’s why centralized logging is an essential part of the puzzle. You’ll also have to choose, and stick with, a retention system that takes into account your amount of available space. Most Kubernetes users prefer to review at least once per day as a way of preventing problems.
Two Types
One simple aspect of Kubernetes is its use of just two distinct types, component and node. Any that a node generates is, obviously, a node log. All others are component logs. The latter have a lot of sources, but usually emanate from containers, Kubernetes services, pods and Kubernetes components. In essence, it’s easiest to remember the key point: any not generated by a node is, by default, a component log.
Viewing with Kubectl
If you don’t want to deal with all the individual nodes, simply use the kubectl log. That way, you’ll be able to look at all the log files for all the nodes. What’s more, you can do this task in real time. There is more to it than this, but for a general understanding of how Kubernetes systems handle log viewing, that’s the key point to keep in mind.
