Recently I’ve been having some fun moving my lab and home infrastructure to Kubernetes. I had a feeling that deploying the UniFi Controller was going to be a bit of a painful process but it’s not so bad. Has This Already Been Done? Well, allegedly. The UniFi Controller has long been a Linux application so theoretically there are no real issues in the way. My initial searching led me to . . .
It’s no secret that I love Terraform but it’s not without it’s drawbacks and when operating a platform built around Kubernetes it can be a tall order to introduce and migrate to. In this post I’m going to look at a less well known Infrastructure as Code solution; Crossplane. Whilst it’s creators don’t bill it as an IaC solution it certainly offers the same functionality in a very different way . . .
In Part 1 of this project we covered building the infrastructure that underpins Kubernetes; the Virtual Machines that make up it’s Control and Data Planes, implementing high availability, bootstrapping the core Kubernetes components and considerations for the various networking elements. All of this is great, but after all of that all our cluster doesn’t actually do very much yet. It’s still in a pretty raw state and not ready to . . .
My home lab has been getting a bit long in the tooth recently. These days I work mostly with container platforms and Infrastructure as Code but those are mostly put to work inside the opaque walls of public cloud providers and not on bare metal (I.E. my own physical or virtual servers). When it comes to container platforms, Kubernetes is the one I spend most of my time with. Running . . .
In a previous article we took a look at the very unwieldy integration of the Istio IngressGateway with an AWS Application Load Balancer, however we didn’t look at any Health Check options to monitor the the ALB via it’s Target Group. A dig around the usual forums suggests that this is confusing a lot of people and it threw me the first time I looked. In post we’ll have a . . .
This article was going to be a look at how to configure IAM roles to work with EKS Service Accounts, however that topic is already well documented in the AWS docs right here. Whilst there’s nothing wrong with it in a technical sense, I can’t help find it a little clunky, using the AWS CLI and eksctl to get the job done. I’ve been pretty unattracted to eksctl (though it . . .
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 . . .
Recently I’ve had the experience of reconfiguring the popular Kubernetes Service Mesh Istio (using it’s Gateway ingress model) to work with an AWS Application Load Balancer with a degree of automation and scalability. This is a challenging deployment to say the least and whilst documentation exists to varying degrees for the separate components, it’s scant. I’m less than impressed with the official Istio documentation (though it has gotten way better) . . .
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 previous post we looked at how to build Chartmuseum on Ubuntu Linux with an S3 backend, however out of the box this system presents a number of problems; specifically it isn’t TLS encrypted and the service runs on an unprivileged TCP port. I could see no guides suggesting how to do this, so lets take a look at how to solve this problem by performing by proxying our . . .