Whether you're a system administrator, a developer, or any other DevOps or Site Reliability Engineering (SRE) professional, you know that staying ahead in cloud-native computing is crucial. One way to keep your competitive edge in the technology game is to embrace the benefits of eBPF (Extended Berkeley Packet Filter). On top of advances in security and networking, eBPF-based tools are particularly impacting the observability landscape.

No one wants to get an alert in the middle of the night. No one wants their Slack flooded to the point of opting out from channels. And indeed, no one wants an urgent alert to be ignored, spiraling into an outage. Getting the right alert to the right person through the right channel — with the goal of initiating immediate action — is the last mile of observability.

Imagine a symphony where every musician plays their part flawlessly, but without a conductor to guide the orchestra, the result is just a discordant mess. Now apply that image to the modern IT landscape, where development and operations teams work with remarkable autonomy, each expertly playing their part. Agile methodologies and DevOps practices have empowered teams to build and manage their services independently, resulting in an environment that accelerates innovation and development.

With the recent integration between SUSE and StackState, SUSE customers will benefit from the enhanced observability StackState offers for their applications running on SUSE’s diverse Kubernetes distributions. As businesses increasingly rely on Kubernetes, ensuring the stability and performance of applications becomes of great importance.

This is the final article of a three-part series. To start at the beginning, read Part 1: Benefiting from multi-cluster setups requires familiarity with common variations and Part 2: Exploring the facets of a multi-cluster observability strategy. As companies scale software production, they lean on Kubernetes as a crucial container orchestration platform for managing, deploying and ensuring software availability.

This is the second of a three-part blog series. Prior to reading this, be sure to check out Part 1, Benefiting from multi-cluster setups requires familiarity with common variations. In your Kubernetes journey, it's highly likely that you'll encounter the need to manage multiple clusters simultaneously.

In the world of modern Kubernetes, things have come a long way from the days of a single cluster handling one app. Now, it's common to see setups that span multiple clusters across different clouds. Initially, managing those clusters was a complicated operation with many moving parts. Using tools such as SUSE Rancher, RedHat OpenShift or AWS EKS, made managing multiple clusters somewhat easier.

For many developers and engineers, Kubernetes is the de facto choice for container orchestration. That’s primarily because of its efficiency in handling and scaling container workloads. However, the complexity of managing nodes in a Kubernetes cluster can cause recurring headaches for even the most experienced and skilled IT teams. This is where `kubectl cordon` comes into play.

As software engineers, we all know that troubleshooting often involves sifting through heaps of data points — scanning metrics, reading logs, checking resource status and analyzing events. We manually connect the dots, and if we're experienced enough, we might spot an issue that's about to become a problem. At StackState, we've faced these same challenges.

If you work with Kubernetes, you know that any number of issues can pose a serious threat to the stability and security of your deployments. One that's subtly damaging is configuration drift, which occurs when the actual state of how your system is set up — its configuration — strays from the way you defined. Configuration drift in Kubernetes can happen when people make changes manually, systems aren't synchronized properly or monitoring falls short.