Skip to content

Blog

GitOps Continuous Deployment: FluxCD Advanced CRDs

FluxCD is a powerful ecosystem of GitOps operators that can be enabled on-demand as per the requirement of your environment. It enables you to opt-in for the features you need and to disable the ones you don't.

As the complexity and requirement of your environment grows, so does the need for extra tooling to cover the implementation of the features you need.

FluxCD comes with more than just the support for Kustomization and HelmRelease. With FluxCD, you can also manage your Docker images as new versions get built. You can also get notified of the events that happen on your behalf by the FluxCD operators.

Stick till the end to see how you can take your Kubernetes cluster to the next level using advanced FluxCD CRDs.

cert-manager: All-in-One Kubernetes TLS Certificate Manager

Kubernetes is a great orchestration tool for managing your applications and all its dependencies. However, it comes with an extensible architecture and with an unopinionated approach to many of the day-to-day operational tasks.

One of these tasks is the management of TLS certificates. This includes issuing as well as renewing certificates from a trusted Certificate Authority. This CA may be a public internet-facing application or an internal service that needs encrypted communication between parties.

In this post, we will introduce the industry de-facto tool of choice for managing certificates in Kubernetes: cert-manager. We will walk you through the installation of the operator, configuring the issuer(s), and receiving a TLS certificate as a Kubernetes Secret for the Ingress or Gateway of your application.

Finally, we will create the Gateway CRD and expose an application securely over HTTPS to the internet.

If that gets you excited, hop on and let's get started!

GitHub Actions Dynamic Matrix

GitHub Actions is a powerful CI/CD tool that allows you to automate your software development workflow. It provides a wide range of features and capabilities.

One of the features that I found very useful is the ability to define a matrix strategy for your jobs. This allows you to run the same job with different parameters, such as different versions of a programming language.

However, there are times when you need to define the matrix dynamically based on the output of a previous job. For example, you may want to run a job for each directory if and only if the directory contains a specific file or has changed since the last commit.

In this post, I will show you how to define a dynamic strategy matrix in GitHub Actions using a real-world example.

Kubernetes The Hard Way

You might've solved this challenge way sooner than I attempted it. Still, I always wanted to go through the process as it has many angles and learning the details intrigues me.

This version, however, does not use any cloud provider. Specifically, the things I am using differently from the original challenge are:

  • Vagrant & VirtualBox: For the nodes of the cluster
  • Ansible: For configuring everything until the cluster is ready
  • Cilium: For the network CNI and as a replacement for the kube-proxy

So, here is my story and how I solved the famous "Kubernetes The Hard Way" by the great Kelsey Hightower. Stay tuned if you're interested in the details.

External Secrets and Immutable Target

If you have worked with External Secrets Operator before, then you know how it eases the operation of managing the secrets in the Kubernetes cluster. It supports many backends and is very powerful.

However, there is a nuance. The External Secrets Operator allows you to define an immutable target secret, sealing the secret shut from future changes unless explicitly deleted and recreated, which is perfect if you never want to modify the secret. But, change is the only constant in the world of IT, and you might want to change the secret in the future. This is where immutable can catch you off guard, as it did mine. This is my story and how I solved it.