Kubernetes

Introduction In this blog post, I’ll demonstrate two methods for deploying Helm charts stored in an OCI registry using ArgoCD. For this demonstration, I’m using a Kind cluster, but the process is the same regardless of your Kubernetes environment. Before OCI support, Helm charts were typically stored in custom chart repositories (ChartMuseum, Nexus, Artifactory) or in Git repositories. OCI registries have become a popular way to store and distribute Helm charts, providing a standardized approach similar to container images. Helm added experimental support for OCI registries in v3, and it became generally available in Helm 3.8.0. It’s a very convenient solution for organizations already leveraging container registries, as they already have what’s needed for storing their charts. ...

Introduction and motivation Terraform has been the most widely adopted tool for managing cloud infrastructure for a while now, and managing EKS is no exception. The majority of companies I’ve talked to use it. However, I’ve noticed that many are at least exploring alternatives, especially in the context of managing EKS - and there are valid reasons for that. Most of the time when you’re interacting with Kubernetes, you do so declaratively: you define the desired state (resource manifests) and rely on various controllers to update the “world” to match what’s defined. This approach is typically used to manage app configuration, deployments, networking, secrets, and more. However, when it comes to cluster configuration or application dependencies, it quickly falls short, and people resort back to good-old Terraform. Many will continue using Terraform whenever they deal with AWS API and only use Kubernetes for what “originally” belongs there. Some will identify bottlenecks and seek alternatives to improve operational efficiency or solve other problems. ...

Introduction The control plane is a set of components that together form the management layer of Kubernetes. These components manage the cluster’s state, coordinate between nodes, and provide APIs for interacting with the cluster. The security of this API component, known as the API Server, is the focus of today’s post. Ensuring the security of the API Server is critical because it serves as the interface to your cluster. It is used by both users and automation tools to interact with the cluster. Whether it’s kubectl, Helm, ArgoCD, or any other tool, they all communicate with the cluster via the API. Unauthorized access can lead to a complete or partial cluster compromise, data breaches, or service disruptions. ...