Operations | Monitoring | ITSM | DevOps | Cloud

Kubernetes has fundamentally changed the way we manage our production environments. The ability to quickly bring up infrastructure on demand is a beautiful thing, but along with it brings some complexity, especially when it comes to logging. Logging is always an important part of maintaining a solid running infrastructure, but even more so with Kubernetes. Because Kubernetes clusters are constantly being spun up, spun down, always in flux, making sure logging functions correctly is critical.

In the past I’ve written about how to use informers in Kubernetes for particular resources, but what if you need to be able to receive events for any Kubernetes resource dynamically? Well, there’s a client-go package for that too. At FireHydrant, we recently updated our Kubernetes integration to watch changes for any resource you configure and I wanted to write down how we made it at a high level.

One of the most successful aspects of Kubernetes is how functional the open source community was able to operate. Kubernetes broke itself down in smaller sections called special interest groups, that operate similarly to subsections of the kernel. Each group is responsible for a single domain, and sets their own pace. One of the most important things to a Kubernetes SIG, is the residual SIG calls.

When we started Rancher in 2014, our vision was to enable enterprise IT to procure and utilize computing resources (“cattle”) from any infrastructure provider. We were extremely lucky to be able to leverage wonderful technologies like Kubernetes which made computing resources consistent across all infrastructure providers.

k3sup: From zero to KUBECONFIG in < 1 min K3s is an open-source, lightweight Kubernetes distribution by Rancher that was introduced this year and has gained huge popularity. People not only like the concept behind it, but also the awesome work that the team has done to strip down the heavy Kubernetes distribution to a minimal level. Though k3s started as a POC project for local Kubernetes development, its development has led people to use it even at a production level.

Containers and serverless computing are two of today’s hottest technologies for application deployment. When used the right way, they both help DevOps teams to deploy applications faster and more cost-effectively. Although the features of containers and serverless architectures overlap in some respects, they are not interchangeable technologies. Containers work better for some use cases, while in others, serverless is what you need.

Google Kubernetes Engine (GKE), a service on the Google Cloud Platform (GCP), is a hosted platform for running and orchestrating containerized applications. Similar to Amazon’s Elastic Container Service (ECS), GKE manages Docker containers deployed on a cluster of machines. However, unlike ECS, GKE uses Kubernetes, an increasingly popular open source orchestrator that can deploy, schedule, and scale containers on the fly.

As we’ve rolled out Loki internally at Grafana Labs, we wanted logs beyond just simple applications. Specifically while debugging outages due to config, Kubernetes, or node restarts, we’ve found Kubernetes events to be super useful. The Kubernetes events feature allows you to see all of the changes in a cluster, and you can get a simple overview by just retrieving them: This also captures when nodes go unresponsive and when a pod has been killed along with the reason.