Operations | Monitoring | ITSM | DevOps | Cloud

Kubernetes is the defacto solution for production-ready container orchestration in 2019. Organizations of any size are able to take advantage of Kubernetes’ quick setup, feature-rich API, and growing community to deliver value quickly and at scale. Since Kubernetes is central to many infrastructures, properly monitoring your Kubernetes clusters is critical. In this post, we will go over how Blue Matador monitors each piece of your Kubernetes cluster automatically.

Today we are excited to announce the general availability of Rancher 2.3, the latest version of our flagship product. Rancher, already the industry’s most widely adopted Kubernetes management platform, adds major new features with v2.3.

Container technology is transforming the face of business and application development. 70% of on-premises workloads today are running on the Windows Server operating system and enterprise customers are looking to modernize these workloads and make use of containers. We have introduced support for Windows Containers in Windows Server 2016 and graduated support for Windows Server worker nodes in Kubernetes 1.14 clusters. With Windows Server 2019 we have expanded support in Kubernetes 1.16.

With over 58K stars on GitHub and over 2,200 contributors across the globe, Kubernetes is the de facto standard for container orchestration. While solving some of the key challenges involved in running distributed microservices, it has also introduced some new ones. Not surprisingly, when asked, engineers list monitoring as one of the main obstacles for adopting Kubernetes. After all, monitoring distributed environments has never been easy and Kubernetes adds additional complexity.

Now that we understand what machine data is available to us, how do we get to this data? The good news is that Kubernetes makes most of this data readily available, you just need the right tool to gather and view it. The solution we will discuss here heavily utilizes open source tools for collection and data enrichment because of their deep integrations and overwhelming community support.

Over my last two posts (part 1 and part 2), I have investigated user authentication in Kubernetes and how to create a single sign-on experience within the Kubernetes ecosystem. So far I have explained how Open ID Connect (OIDC) works, how to get started with OIDC and how to perform a login from the command line. The final piece of this puzzle is the Kubernetes dashboard, often used by our engineers alongside kubectl.

Researchers at Netflix and Google recently reported a vulnerability in the HTTP/2 protocol that enables adversaries to execute a DOS attack by legitimate use of the protocol. These types of attacks are very difficult to detect and mitigate because the traffic is valid HTTP/2 traffic. While HTTP/2 is a relatively new protocol it should be noted that even after several years of hardening we still see vulnerabilities for the TCP protocol like the recently reported SACK vulnerability.

ELK and Kubernetes are used in the same sentence usually in the context of describing a monitoring stack. ELK integrates natively with Kubernetes and is a popular open-source solution for collecting, storing and analyzing Kubernetes telemetry data. However, ELK and Kubernetes are increasingly being used in another context — that of a method for deploying and managing the former.