At the end of last year I wrote about some basic methods for debugging networking issues inside a Kubernetes Cluster. In that article we very briefly mentioned a then-alpha feature (with a complicated sounding name) called Ephemeral Debug Containers first introduced back in Kubernetes v1.16. This looks to be the real future of debugging in Kubernetes and as of v1.20 it’s finally in beta. This great feature really strengthens a . . .
Last year I wrote about automating Elastic Kubernetes Service role configuration (direct modification of the aws-auth ConfigMap) using Terraform, and a somewhat clunky method of injecting ARN data by looking it up from a secret management service (in this case Hashicorp Vault). Whilst the solution works well it comes with a serious built in issue when we want to provision a new deployment from scratch, namely the need to import . . .
In the days of cloud we’re often called on to integrate a lot of technologies together (as the somewhat messy title of this post suggests). One of the more recent systems I’ve encountered is Istio, popular Kubernetes Service Mesh, which in EKS tends to rely on an Elastic Load Balancer of one flavour or another as the point of access to it’s Gateway. In this post we’ll look at how . . .
Since my first tentative steps in to Kubernetes it’s been an interesting journey. For the most part I suspect the most common way to interact with Kubernetes is to use a managed platform through one of the main public cloud players (that’s certainly been my experience), but it doesn’t do a lot to understand the nuts and bolts of the platform. I’d been meaning to try and get stuck in . . .
If, like me, you’ve come from a traditional sysadmin background then Kubernetes can be daunting to say the least, this doesn’t get much easier when it comes to trying to get to grips with how to debug networking issues. Kubernetes networking is VAST and supports a number of complex implementations that vary between the major Kubernetes-as-a-Service platforms (GKE, EKS, AKS) as well as many other options. The broad strokes are . . .
In a previous post we looked at the basics of working with multiple instances of Terraform providers, however as usual, Kubernetes presents some slight variations on this theme due to it’s varied options for authentication. In this post we’re looking at how to handle authentication for multiple Kubernetes clusters in Terraform. Provider Aliases Underpinning all concepts of working with multiple instances of a provider is the concept of working with . . .
One of the lesser known functions of Terraform is the ability to operate multiple instances of the same provider within the same configuration. The uses of this are various though as it’s not always needed it’s one of those things that doesn’t always leap out. It’s pretty easy to get to grips with so this is a short post to take a look at how to get started. Providers – . . .
Recently I’ve spent a good amount of time looking at options for managing Kubernetes Secrets with Vault. Hashicorp being a great supporter of the Cloud Native philosophy, it’s little surprise to find that they provide a multitude of options to integrate with Kubernetes and provide extensive documentation here. for my needs I found that the suggested configurations were either unsuitable or required a degree of over-engineering so I’m going to . . .
UPDATED 11/2020: Have a look at a different method for this configuration better suited to CI/CD. In a previous post we looked at how to use Terraform provision and authenticate with Clusters using AWS’ Elastic Kubernetes Service (EKS) using the somewhat unique authentication method of it’s webhook token method leveraging aws-iam-authenticator. Once we get past that point however we still have another permission hurdle to overcome, specifically how we handle . . .
NOTE: The sample code used here is hosted in my GitHub here. Recently I’ve been getting my hands dirtier and dirtier with Kubernetes but there’s some interesting oddities that only occur in Elastic Kubernetes Service (EKS), the AWS PaaS Kubernetes platform, especially when it comes to how you can authenticate. As Kubernetes is strongly driven by a declarative (and by extension Infrastructure as Code) philosophy, it makes perfect sense that . . .