I’ve been thinking of moving my Kubernetes lab into the cloud, but with cloud resource usage being scrutinized by the IT department, running them 24x7 the way I’m used to is a no-go. I need a setup that meets the following requirements: Simple to create and tear down Applications must be pre-deployed when the cluster is up, as close to “just the way I left it there last night” as possible cost $0 when the setup has been switched off I eventually settled on the idea of an ephemeral Kubernetes lab environment using Infrastructure as Code (IaC) and GitOps practices, which I will cover in this post.

Intro So in my last post I showed how you could create databases on Kubernetes. There are many reasons to do this. Equally, there are reasons not to do this, but for highly distributed deployments it does make sense. This post is going to focus on the storage components of running a database on Kubernetes. Why do I need persistent storage Persistent storage as the name implies allows you to store your data between container restarts.

In this post, we will be looking at how Istio handles end user authentication/authorization based on JSON Web Tokens (JWT). JWT is commonly used in OAuth2.0 flows to specify the resources a client has access to, but there are a couple of things to verify before the client is given access: Is the JWT issued by the right party Is the client who they claim to be The logic for the checks above are usually coded into the application.

Intro Recently, I’ve been working with a customer who wants to provide databases on their Kubernetes cluster. Ever since Microsoft’s SQL Server was released on Linux some years ago, I’ve been fascinated with it. I decided to give it a go recently on Kubernetes, and get it all working. This is part one, where I deploy SQL server without persistent storage. In part two, I will discuss using persistent storage.

There are times when applications deployed in Kubernetes need to communicate with external services that requires mTLS authentication, where the applications have to present client certificates signed by a common root/intermediate CA when accessing the service. This can lead to unpleasant scenarios where application owners have to keep track of certificates for each of their applications applications written in different language/libraries have different ways of implementing mTLS connections As an application owner, I would prefer to just deal with plain ol' HTTP on port 80, and not have to modify the application to handle HTTPS or mTLS.