Several companies nowadays offer a cloud-native solution that manages Kubernetes applications and services. While these solutions seem easy at first glance, in reality, they still require manual maintenance. As an example, an important decision for any Kubernetes cluster is the number of nodes and the autoscaling rules you define.

Have you always wanted to have different settings between production and staging but never knew how? You can do this with Kustomize! Kustomize is a CLI configuration manager for Kubernetes objects that leverage layering to preserve the base settings of the application. This is done by overlaying the declarative YAML artifacts to override default settings without actually making any changes to the original manifest.

Flux is a CNCF based open source stack of tools. Flux focuses on making it possible to keep Kubernetes clusters and cloud-native applications in sync with external resources and definitions hosted in environments such as GitHub. Implementing tools like FluxCD should enable you to achieve results such as: The results above can bring obvious benefits, and many teams are adopting FluxCD as their tool of choice for GitOps.

Matt and I are out in Los Angeles this week for KubeCon 2021 this week. At the GitOpsCon event Tuesday we were excited to attend this Kubernetes session: GitOps in the Real World: Opportunities for Developer Experience Improvement.

In a previous post, we talked about the increasing adoption of Platform Engineering teams. The post covered topics such as defining Platform Engineering and the roles and responsibilities of the team. When building an internal platform, a clear goal that many teams want to achieve is: Even though this is key to a successful platform team, this responsibility increases complexity, costs, support time, and more. Not to mention that this can be a long, very long journey.

Not to muddy the waters with one more prefix in front of ops, GitOps is a newer DevOps paradigm that slants towards the developer. As the names states, GitOps is focused around Git, the source code management tool. As a developer, leveraging an SCM is one of the quintessential tools of the trade; allowing for collaboration and more importantly saving your hard work off of your machine.

This is the first of many posts highlighting GitOps topics that we’ll be exploring. Within this post, we will explore Helm, a tool used for Kubernetes package management, that also provides templating. Helm provides utilities that assist Kubernetes application deployment. In order to better understand how Helm charts are mapped to Kubernetes manifests, we’ll explain more details below and how to use Helm with and without GitOps.

One of the foundations of GitOps is the usage of Git as the source of truth for the whole system. While most people are familiar with the practice of storing the application source code in version control, GitOps dictates that you should also store all the other parts of your application, such as configuration, kubernetes manifests, db scripts, cluster definitions, etc. But what about secrets? How can you use secrets with GitOps?