We continue the topic of deploying an AWS Elastic Kubernetes Service cluster using Terraform. In the first part, we prepared an AWS VPC. In this part, we’ll deploy the EKS cluster itself, and will configure AIM for it, and in the next parts, we’ll install Karpenter and the rest of the controllers. All the parts:… Read More »
So, now that we’ve been reminded a bit about Terraform’s data types and loops, it’s time to start building something real. The first thing we will deploy with Terraform is the AWS Elastic Kubernetes Service cluster and all the resources associated with it because now it is done with AWS CDK, and in addition to… Read More »
Following the series of posts about preparing to use Terraform on a project. So, in the first part, we thought about how to organize the preparation of the backend for the project, that is, to perform its bootstrap, and a bit – how to manage the Dev/Prod environments in general, see Terraform: Getting started and… Read More »
We are preparing to transfer infrastructure management from AWS CDK to Terraform. I’ve already wrote about planning it in the Terraform: planning a new project with Dev/Prod environments post, but there I didn’t wrote about one very important option – creating a lock for state files. State file locking is used to avoid situations where… Read More »
We continue to develop our monitoring stack. See the first part – VictoriaMetrics: creating a Kubernetes monitoring stack with its own Helm chart. What do we want to do next: give access to developers so that they can set Silence for alerts themselves in Alertmanager to avoid spamming Slack, see Prometheus: Alertmanager Web UI alerts Silence.… Read More »
On all my previous projects where Kubernetes was, for its WorkerNodes scaling I’ve used the Cluster Autoscaler (CAS) because actually there were no other options before. In general, CAS worked well, but in November 2020 AWS released its own solution for scaling nodes in EKS – the Karpenter, and if at first time reviews were… Read More »
Kubernetes allows very flexible control over how its Pods will be located on servers, i.e. WorkerNodes. This can be useful if you need to run a pod on a specific node configuration, for example – a WorkerNode must have a GPU, or an SSD instead of an HDD. Another example is when you need to… Read More »
To improve the performance of Grafana Loki, it is necessary to install several almost identical instances of Memcached, see Grafana Loki: performance optimization with Recording Rules, caching, and parallel queries. The monitoring stack itself is deployed from one Helm chart, which dependencies – Promtail, Loki, etc – are added through the dependency field of the… Read More »
So, we have Loki installed from the chart in simple-scale mode, see Grafana Loki: architecture and running in Kubernetes with AWS S3 storage and boltdb-shipper. Loki is runnings on an AWS Elastic Kubernetes Service cluster, installed with Loki Helm chart, AWS S3 is used as a long-term store, and BoltDB Shipper is used to work… Read More »
Traffic in AWS is generally quite an interesting and sometimes complicated thing, I once wrote about it in the AWS: Cost optimization – services expenses overview and traffic costs in AWS. Now, it’s time to return to this topic again. So, what’s the problem: in AWS Cost Explorer, I’ve noticed that we have an increase… Read More »