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 . . .
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 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 . . .
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 . . .
Recently I’ve been looking at how to configure EC2 autoscaling schedules for EKS implementations, specifically delivering these schedule configurations via Terraform. This sounds like it should be rather simple on the surface but after getting the initial configuration to work an issue of idempotency presents itself. In this post I want to look at the issues presented and how to overcome them. Autoscaling Groups and Schedules When an managed EKS . . .
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 at https://github.com/tinfoilcipher/eks-terraform-example 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 . . .