eks on Alperen Doc

eks-cluster

Mon, 01 Jan 0001 00:00:00 +0000

EKS Cluster#

An EKS cluster has two halves:

The control plane: the Kubernetes API server, etcd, scheduler, and controllers. AWS runs these for you, patches them, and keeps them highly available. You never SSH into it; you just get an API endpoint and a kubeconfig.
The data plane: the worker nodes (EC2 instances) or Fargate tasks that actually run your pods. These live in your VPC, in the subnets you choose.

For the worker nodes we’ll use a managed node group: AWS creates the EC2 instances from a launch template, joins them to the cluster, and can roll updates for us. (Fargate is the serverless alternative - no nodes to think about, but less control and a different cost model.)

eks-vs-kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

EKS vs Your Own kubeadm Cluster#

If you’ve been through my multi-node kubeadm notes, you’ve done it the hard way: Debian VMs on Proxmox, containerd, kubeadm init/join, Cilium as the CNI, and every package upgrade lands on your desk. That cluster is yours - you know every screw.

EKS is the same Kubernetes API with most of the screws hidden. The point of this note is exactly what to compare: what disappears, what changes, and what stays stubbornly identical.

eks-deploy-app

Mon, 01 Jan 0001 00:00:00 +0000

Deploy App to EKS#

The cluster is up; now we run the PatientPing app on it. Nothing about this part is AWS-specific - it’s plain Kubernetes - but we’ll use AWS to expose the app to the internet at the end.

We need two objects:

A Deployment: tells Kubernetes “keep 2 replicas of the patientping-web container running”.
A Service: gives those pods a stable address. With type: LoadBalancer on EKS, Kubernetes asks AWS to create an Application Load Balancer for us - the same kind we built by hand in the ECS section.

Assignment#

Deploy patientping-web to the patientping-eks cluster and reach it through a load balancer.

eks-connect-s3

Mon, 01 Jan 0001 00:00:00 +0000

Connect S3 to EKS#

The PatientPing app serves a favicon and will store user uploads in S3. Our pods need to call the S3 API - but how do they get AWS credentials?

The lazy way is to bake an access key into the container image or paste it into a Deployment env var. Don’t. Long-lived keys in a pod spec end up in git, in kubectl describe output, and in your terminal history. And giving the worker nodes a broad S3 role is also wrong: any pod on the node (including one you didn’t write) inherits it.

eks-use-rds

Mon, 01 Jan 0001 00:00:00 +0000

Use RDS from EKS#

Our patientping-db Postgres instance is sitting in a private subnet, exactly where it belongs. Now the pods need to reach it. Two things have to be right:

Network path - the RDS security group must allow traffic from the worker nodes on port 5432.
Credentials - the app needs DATABASE_URL, and that password shouldn’t live in the Deployment YAML (anything in a manifest ends up in git and in kubectl get deploy -o yaml).

Kubernetes Secrets are the second half of the answer, and security groups are the first.

eks-node-affinity-taints

Mon, 01 Jan 0001 00:00:00 +0000

Node Affinity and Taints on EKS#

Everything in my taints, affinity and quotas notes works on EKS verbatim. kubectl taint, tolerations, nodeAffinity, topologySpreadConstraints - the API doesn’t know or care that AWS is underneath. What is different is how nodes appear, how they get their labels and taints, and what happens to all of it when the autoscaler is involved.

Kısa hatırlatma: taint node’un kapıdaki tabelası (“her pod giremez”), toleration pod’un geçiş izni, nodeAffinity ise “şu node’a git” talebi. İkisini karıştırmayın - toleration sizi oraya göndermez, sadece engeli kaldırır.

eks-ha-cluster

Mon, 01 Jan 0001 00:00:00 +0000

High Availability on EKS#

In the HA notes for the kubeadm cluster, HA was a project: stacked etcd members, an external etcd option, a keepalived VIP in front of the apiserver, and a failover test where you pull the power on a VM. On EKS, most of that project is already done for you - but “done for you” is not the same as “you have no homework”.

The control plane: AWS’s job#

When you create patientping-eks, AWS runs the control plane across three Availability Zones, with an etcd cluster that tolerates member loss and a regional API endpoint your kubeconfig already points at. There is no VIP to keep alive, no --control-plane-endpoint to design, no etcd quorum to babysit.

eks-spot-instances

Mon, 01 Jan 0001 00:00:00 +0000

Spot Instances on EKS#

You already know spot instances from the EC2 lessons: unused AWS capacity at a ~90% discount, with one small caveat - “at any time I may literally delete your server” with a 2-minute heads-up.

EKS doesn’t change the deal; it just changes how you consume it. Instead of bidding on individual instances, you declare one line in a managed node group and Kubernetes schedules onto the cheap cattle: