Kubernetes is an orchestrator for technologies that comply with its APIs, and the name is often used as shorthand for a wider ecosystem rather than a single mechanism. A cluster groups nodes and containerized workloads, but effective observability must account for the application, its containers, the cluster, and the supporting processes around them. section 1.5.1 section 4.7
For monitoring containerized applications, Kubernetes expertise can remain focused: understand enough orchestration to capture events and interpret their context. Application code generally need not know how Kubernetes moves containers within a cluster unless it is implementing a Kubernetes controller. Prepared distributions and managed services may already include monitoring settings, so their configuration and visibility boundaries determine what can be observed. section 1.5.1 section 4.7.4
Kubernetes observability separates several event sources and responsibilities:
- Application logs commonly go to standard output and standard error, with the container runtime responsible for handling them. Logging drivers provide alternative handling paths, but behavior differs among implementations. section 4.7.1
- Cluster-level events include Pod evictions and node starts or stops. Kubernetes does not prescribe one collection solution; logging agents can run beside workloads or on every node through a DaemonSet. section 4.7.1
- Component health includes container engines, orchestration processes, and connectivity. Failures in etcd, kubelet, or related processes can affect an application's ability to locate and connect to another container. section 4.1
- Transient containers and continuously changing Pods require monitoring that can confirm both individual behavior and expected cluster-wide operation. section 4.1
Kubernetes is not operationally uniform. Its ecosystem can include etcd, container managers such as Docker and CRI-O, runtimes such as runc and crun, and networking implementations such as Calico and flannel. Even components that follow OCI or CNI interfaces can behave differently. OpenShift, Tanzu, K3s, Minikube, and cloud-managed offerings add opinionated configuration choices; hosted services can also abstract or restrict access to management and compute nodes. section 4.7.4 section 1.5.1
Deploying Fluent Bit in a managed cluster
Connect Fluent Bit according to the cloud service's visibility model. Fully managed nodes may limit node-level monitoring, while captured events can still be enriched with the Kubernetes filter. Where node monitoring is needed, Helm charts and Fluent Operator provide starting points for automating deployment; ConfigMaps can hold Fluent Bit configuration and make changes part of Kubernetes package management. section 11.3.2 section 4.11
Configuration can be embedded in a container image, overridden through container settings such as CMD or mount points, injected with ConfigMaps, packaged through Helm charts, or governed through operators. Operators add configuration complexity but can enforce valid values and use selectors to choose applicable configurations. These choices connect collection design to deployment control, change management, and the particular runtime or service being monitored. section 4.11
