Blog

Intro

Hi there! Flask is great for building APIs quickly. But turning your local project into a publicly accessible web service involves a few extra steps that aren’t always obvious.

In this guide, I’ll show you how to deploy a Flask API using Gunicorn as the WSGI server, Supervisor to manage the process, and Nginx as a reverse proxy.

Overview

- Flask: The Python microframework we’ll use to build the API.

- Gunicorn: A Python WSGI HTTP server for running Flask in production.

- Supervisor: A process control system to ensure the Gunicorn server stays alive.

- Nginx: A reverse proxy to handle client requests and route them to Gunicorn.

Flask API Deployment Flow

The diagram below illustrates the flow of a request and response when using Flask, Gunicorn, Supervisor, and Nginx.

When a user sends an HTTP request, it first reaches the Nginx reverse proxy. Nginx forwards the request to Gunicorn, which serves the Flask application via the WSGI protocol. Supervisor ensures that Gunicorn keeps running and automatically restarts it if needed. The response follows the same path back to the user.

Requirements

Before starting, make sure you have the following installed on your system:

- Python 3 and Virtualenv

Check if Python is installed:

$ python3 --version

Python 3.10.14

If not installed, install it:

Ubuntu/Debian:

$ sudo apt update
$ sudo apt install python3 python3-venv -y

CentOS/RHEL:

$ sudo yum install python3 python3-venv -y

Homebrew (macOS):

$ brew install python

- Nginx

Ubuntu/Debian:

$ sudo apt install nginx -y

CentOS/RHEL:

$ sudo yum install nginx -y

Homebrew (macOS):

$ brew install nginx

After installation, check if Nginx is running:

$ sudo systemctl status nginx

If it’s not running, start and enable it:

$ sudo systemctl start nginx
$ sudo systemctl enable nginx

• Supervisor

Ubuntu/Debian:

$ sudo apt update
$ sudo apt install supervisor -y

CentOS/RHEL:

$ sudo yum install supervisor -y

Homebrew (macOS):

$ brew install supervisor

After installation, check if Supervisor is running:

$ sudo systemctl status supervisor

If it’s not running, start and enable it:

$ sudo systemctl start supervisor
$ sudo systemctl enable supervisor

Setting Up the Flask Project

First, create a project directory and set up a virtual environment:

$ mkdir flask-api && cd flask-api

$ python3 -m venv venv
$ source venv/bin/activate

With the virtual environment activated, install Flask and Gunicorn:

$ pip install flask gunicorn

You can verify the installation:

$ flask --version
$ gunicorn --version

Next, you need to create a file called app.py inside your project directory. You can use any text editor you prefer, such as nano, vim, or others:

$ vim app.py

from flask import Flask

app = Flask(__name__)

@app.route("/api/hello")
def hello():
    return {"message": "Hello from Flask API!"}

Then, try to run your Flask app using Gunicorn command:

$ gunicorn app:app

[2025-04-30 20:37:49 +0700] [1085004] [INFO] Starting gunicorn 23.0.0
[2025-04-30 20:37:49 +0700] [1085004] [INFO] Listening at: http://127.0.0.1:8000 (1085004)
[2025-04-30 20:37:49 +0700] [1085004] [INFO] Using worker: sync
[2025-04-30 20:37:49 +0700] [1085005] [INFO] Booting worker with pid: 1085005
[2025-04-30 20:38:58 +0700] [1085004] [INFO] Handling signal: winch

To try your app, just open another terminal session or window. You can use a tool like curl:

$ curl http://127.0.0.1:8000/api/hello

{"message":"Hello from Flask API!"}

Running with Multiple Workers

You can run Gunicorn with multiple worker processes using the -w option. For example, to run your app with 3 workers:

$ gunicorn -w 3 app:app

[2025-04-30 20:49:13 +0700] [1085759] [INFO] Starting gunicorn 23.0.0
[2025-04-30 20:49:13 +0700] [1085759] [INFO] Listening at: http://127.0.0.1:8000 (1085759)
[2025-04-30 20:49:13 +0700] [1085759] [INFO] Using worker: sync
[2025-04-30 20:49:13 +0700] [1085760] [INFO] Booting worker with pid: 1085759
[2025-04-30 20:49:13 +0700] [1085761] [INFO] Booting worker with pid: 1085760
[2025-04-30 20:49:13 +0700] [1085762] [INFO] Booting worker with pid: 1085761

To confirm that Gunicorn is running with multiple workers, you can use tools like top or htop.

Install htop (optional but nicer to read):

$ sudo apt install htop -y

Then run:

$ htop

To bind it to a different port (e.g., 8081) and listen on all interfaces:

$ gunicorn -b 0.0.0.0:8081 app:app

[2025-04-30 21:14:29 +0700] [1085847] [INFO] Starting gunicorn 23.0.0
[2025-04-30 21:14:29 +0700] [1085847] [INFO] Listening at: http://0.0.0.0:8081 (1085847)
[2025-04-30 21:14:29 +0700] [1085847] [INFO] Using worker: sync
[2025-04-30 21:14:29 +0700] [1085848] [INFO] Booting worker with pid: 1085848

Adding Supervisor and Nginx Configuration

Supervisor Setup

To make sure Gunicorn runs in the background and restarts automatically if it crashes, you’ll want to use Supervisor. Here’s how to set it up:

Create a configuration file for your app:

$ sudo vim /etc/supervisor/conf.d/flask-api.conf

Insert this configuration (adjust paths as needed):

[program:flask-api]
directory=/home/youruser/flask-api
command=/home/youruser/flask-api/venv/bin/gunicorn -w 3 -b 127.0.0.1:8000 app:app
autostart=true
autorestart=true
user=www-data
stdout_logfile=/var/log/flask-api.out.log
stderr_logfile=/var/log/flask-api.err.log
environment=PATH="/home/youruser/flask-api/venv/bin"

directory=/home/youruser/flask-api → The working directory where your Flask project is located.

command=/home/youruser/flask-api/venv/bin/gunicorn -w 3 -b 127.0.0.1:8000 app

→ Runs the Gunicorn server with 3 workers, binding to localhost on port 8000.

autostart=true → Automatically starts the app when Supervisor starts (e.g., on boot).

autorestart=true → Restarts the app automatically if it crashes.

user=www-data → Runs the process as the www-data user (you can change this to your own user if needed).

stdout_logfile=/var/log/api/flask-api.out.log → File where standard output (including errors) is logged.

stderr_logfile=/var/log/api/flask-api.err.log → (Optional if using redirect_stderr) File for capturing standard error output.

environment=PATH=”…” → Ensures Supervisor uses the correct Python virtual environment for Gunicorn.

Then reload Supervisor to pick up the new config:

$ sudo supervisorctl reread
$ sudo supervisorctl update
$ sudo supervisorctl status

If the API is not running, check the logs:

$ cat /var/log/flask-api.out.log
$ cat /var/log/flask-api.err.log

Or use Supervisor’s built-in log viewer:

$ tail -f flask-api

==> Press Ctrl-C to exit <==

Nginx Configuration

Now that Gunicorn is running your Flask app on port 8000, you’ll want Nginx to act as a reverse proxy.

Create a new Nginx config file:

$ sudo vim /etc/nginx/sites-available/flask-api

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable the site and test:

$ sudo ln -s /etc/nginx/sites-available/flask-api /etc/nginx/sites-enabled
$ sudo nginx -t
$ sudo systemctl restart nginx

Finally, ff everything is set up correctly, you should now be able to access your Flask API at http://YOUR_SERVER_IP/api/hello if you’re using a public server or VPS.

Optional: Project Structure & Requirements

To easily reinstall dependencies later:

$ pip freeze > requirements.txt

However, it’s better to specify only the packages you need manually:

$ sudo vim requirements.txt

flask
gunicorn

To install all requirements, just run pip install:

$ pip install -r requirements.txt

Your project structure should look like this:

flask-api/
├── app.py
├── venv/
└── requirements.txt

Common Issues

Here are a few quick troubleshooting tips:

502 Bad Gateway: Usually means Gunicorn isn’t running or the Nginx config has the wrong port.

Supervisor status shows STOPPED: Check your config file paths and the logs: sudo tail -f /var/log/flask-api.err.log

Permission errors: Ensure all paths used by Supervisor and Gunicorn are accessible by the appropriate user.

Conclusion

In this guide, we deployed a Flask API using Gunicorn as the WSGI server, Supervisor to keep the app running reliably, and Nginx as a reverse proxy to handle incoming requests. With this setup, your Flask app is ready to serve real traffic efficiently and automatically recover from crashes. Thanks for reading — and good luck with your deployment! 🚀

Project Reference:

• Rahul Nayak: Deploy flask app with nginx using gunicorn and supervisor

Intro

Hi! In this post, I’ll show you how to deploy a Go API using Supervisor to manage the process and Nginx as a web server to serve it.

Before we dive into the deployment steps, let’s briefly discuss why we’re using Supervisor and Nginx.

- Supervisor is a process control system that helps manage and monitor applications running in the background. It ensures that your Go API stays up and automatically restarts it if it crashes. See the full documentation

- Nginx is a high-performance web server that can also function as a reverse proxy, making it ideal for serving our Go API to the internet. See the full documentation

🤔 Why Choose Supervisor Over Other Options?

You might wonder why we use Supervisor instead of alternatives like Systemd, PM2, or containerized solutions like Docker. Here’s a quick comparison:

When Should You Use Supervisor?

Use Supervisor when you want a non-containerized way to manage a Go service, with features like auto-restart and log management, without dealing with systemd’s complexity or Docker’s extra overhead.

Setup and Run a Simple Go API

Requirements

Before starting, make sure you have the following installed on your system:

- Go

$ go version

go version go1.24.0 linux/amd64

If not installed, download it from the official site.

- Supervisor

• Ubuntu/Debian

  $ sudo apt update
  $ sudo apt install supervisor -y

• CentOS/RHEL

  $ sudo yum install supervisor -y

• Homebrew (macOS)

  $ brew install supervisor

  After installation, check if Supervisor is running:

  $ sudo systemctl status supervisor

  If it’s not running, start and enable it:

  $ sudo systemctl start supervisor
  $ sudo systemctl enable supervisor

- Nginx

• Ubuntu/Debian

  $ sudo apt install nginx -y

• CentOS/RHEL

  $ sudo yum install nginx -y

• Homebrew (macOS)

  $ brew install nginx

  After installation, check if Nginx is running:

  $ sudo systemctl status nginx

  If it’s not running, start and enable it:

  $ sudo systemctl start nginx
  $ sudo systemctl enable nginx

Initialize a New Go Project

First, create a new directory for the project and initialize a Go module:

$ cd /var/www/
$ mkdir go-api && cd go-api

$ go mod init example.com/go-api

This command creates a Go module named example.com/go-api, which helps manage dependencies.

Create a Simple API

Now, create a new file main.go and add the following code:

$ vim main.go

package main

import (
        "fmt"
        "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "text/plain")
        fmt.Fprintln(w, "Simple Go API")
}

func main() {
        http.HandleFunc("/", handler)
        fmt.Println("Server started at :8080")
        http.ListenAndServe(":8080", nil)
}

Compile and run the Go server:

$ go run main.go

If successful, you should see this message in the terminal:

Server started at :8080

Now test the API using curl:

$ curl localhost:8080


Simple Go API

Create a Simple API with ASCII Text Response (Optional)

First, install the go-figure package:

$ go get github.com/common-nighthawk/go-figure

Now, modify main.go to generate an ASCII text response dynamically:

package main

import (
  "fmt"
  "net/http"

  "github.com/common-nighthawk/go-figure"
)

func handler(w http.ResponseWriter, r *http.Request) {
  w.Header().Set("Content-Type", "text/plain")
  asciiArt := figure.NewFigure("Simple Go API", "", true).String()
  fmt.Fprintln(w, asciiArt)
}

func main() {
  http.HandleFunc("/", handler)
  fmt.Println("Server started at :8080")
  http.ListenAndServe(":8080", nil)
}

$ curl localhost:8080

  ____    _                       _             ____                _      ____    ___
 / ___|  (_)  _ __ ___    _ __   | |   ___     / ___|   ___        / \    |  _ \  |_ _|
 \___ \  | | | '_ ` _ \  | '_ \  | |  / _ \   | |  _   / _ \      / _ \   | |_) |  | |
  ___) | | | | | | | | | | |_) | | | |  __/   | |_| | | (_) |    / ___ \  |  __/   | |
 |____/  |_| |_| |_| |_| | .__/  |_|  \___|    \____|  \___/    /_/   \_\ |_|     |___|
                         |_|

Running the API as a Background Service with Supervisor

Create a Supervisor Configuration for the Go API

Create a new Supervisor config file:

$ sudo vim /etc/supervisor/conf.d/go-api.conf

Add the following configuration:

[program:go-api]
process_name=%(program_name)s_%(process_num)02d
directory=/var/www/go-api
command=bash -c 'cd /var/www/go-api && ./main'
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stderr_logfile=/var/log/go-api.err.log
stdout_logfile=/var/log/go-api.out.log

Explanation:

directory=/var/www/go-api → The working directory of the Go API.

command=bash -c 'cd /var/www/go-api && ./main' → Runs the API.

autostart=true → Starts automatically on system boot.

autorestart=true → Restarts if the process crashes.

user=www-data → Runs as the www-data user (adjust as needed).

redirect_stderr=true → Redirects error logs to stdout.

stdout_logfile=/var/log/api/go-api.out.log → Standard output log file.

stderr_logfile=/var/log/api/go-api.err.log → Error log file.

Now, we need build the Go API:

$ go build -o main .

Ensure the directory and binary have the correct permissions:

$ sudo chown -R www-data:www-data /var/www/go-api
$ sudo chmod 775 /var/www/go-api/main

Apply the Supervisor Configuration

Reload Supervisor and start the service:

$ sudo supervisorctl reread
$ sudo supervisorctl update
$ sudo supervisorctl start go-api:*

Check the service status:

$ sudo supervisorctl avail
go-api:go-api_00                 in use    auto      999:999

$ sudo supervisorctl status go-api:*

go-api:go-api_00                 RUNNING   pid 198867, uptime 0:01:52

Check Logs and Debugging

If the API is not running, check the logs:

$ cat /var/log/go-api.out.log
$ cat /var/log/go-api.err.log

Or use Supervisor’s built-in log viewer:

$ sudo supervisorctl tail -f go-api:go-api_00

==> Press Ctrl-C to exit <==
Server started at :8080

Setting Up Nginx as a Reverse Proxy for the API

Create a new configuration file:

$ sudo vim /etc/nginx/sites-available/go-api

server {
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
    }

    error_log /var/log/nginx/go-api_error.log;
    access_log /var/log/nginx/go-api_access.log;
}

Create a symbolic link to enable the site:

$ sudo ln -s /etc/nginx/sites-available/go-api /etc/nginx/sites-enabled/

Test the configuration:

$ nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If the test is successful, restart Nginx:

$ sudo systemctl restart nginx

Now, you can access your Go API using:

• Localhost (if running locally)

curl http://localhost

  ____    _                       _             ____                _      ____    ___
 / ___|  (_)  _ __ ___    _ __   | |   ___     / ___|   ___        / \    |  _ \  |_ _|
 \___ \  | | | '_ ` _ \  | '_ \  | |  / _ \   | |  _   / _ \      / _ \   | |_) |  | |
  ___) | | | | | | | | | | |_) | | | |  __/   | |_| | | (_) |    / ___ \  |  __/   | |
 |____/  |_| |_| |_| |_| | .__/  |_|  \___|    \____|  \___/    /_/   \_\ |_|     |___|
                         |_|

• Server’s Public IP (if running on a VPS or remote server)

curl http://YOUR_SERVER_IP

Note: If you want to access your Go API using a custom domain instead of an IP address, you need to purchase a domain, configure its DNS to point to your server’s IP, and update your Nginx configuration accordingly. For better security, it’s recommended to set up HTTPS using Let’s Encrypt.

Conclusion

In this guide, we deployed a Go API using Supervisor to manage the process ensuring automatic restarts and efficient request handling also Nginx as a reverse proxy. Thank you for reading, and good luck with your deployment! 🚀

Let’s start again. Now we will do some practices.

In this part of the Kubernetes series, we will explore how to create a Kubernetes cluster in different environments. Whether you’re running Kubernetes locally or in the cloud, understanding how to set up a cluster is fundamental to deploying and managing containerized applications efficiently.

We will cover three different ways to create a Kubernetes cluster:

- Kind (Kubernetes in Docker) - A lightweight way to run Kubernetes clusters locally for testing and development.

- K3D (K3S in Docker) - A more lightweight Kubernetes distribution, optimized for local development and CI/CD workflows.

- EKS (Amazon Elastic Kubernetes Service) - A managed Kubernetes service provided by AWS for running Kubernetes workloads in the cloud.

Each approach has its own use cases, advantages, and trade-offs. Let’s dive into each one and see how to set up a cluster.

Setting Up a Kubernetes Cluster with Kind

Kind (Kubernetes in Docker) is one of the simplest ways to spin up a Kubernetes cluster for local development and testing. It runs Kubernetes clusters inside Docker containers and is widely used for CI/CD and development workflows.

Prerequisites

- Docker installed on your machine. (installation guide)

- KIND CLI installed. (installation guide)

- Kubectl CLI installed. (installation guide)

Create a Cluster with Kind

- Create a new Kind cluster:

$  kind create cluster --name kind-cluster

Creating cluster "kind-cluster" ...
 ✓ Ensuring node image (kindest/node:v1.31.0) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind-cluster"
You can now use your cluster with:

kubectl cluster-info --context kind-kind-cluster

Thanks for using kind! 😊

• Check the cluster:

$   kubectl cluster-info --context kind-kind-cluster

Kubernetes control plane is running at https://127.0.0.1:43417
CoreDNS is running at https://127.0.0.1:43417/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

- List available nodes:

$ kubectl get nodes

NAME                         STATUS   ROLES           AGE   VERSION
kind-cluster-control-plane   Ready    control-plane   75s   v1.31.0

Create Simple Deployment

- Use the kubectl create deployment command to define and start a deployment:

$  kubectl create deployment nginx --image=nginx

deployment.apps/nginx created

- Check deployment status using kubectl get deployment command:

$ kubectl get deployment

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   0/1     1            0           29s

- Expose the deployment:

$ kubectl expose deployment nginx --port=80 --type=LoadBalancer

service/nginx exposed

- Verify the Pod status and then try to access Nginx using your browser:

$ kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE
nginx-676b6c5bbc-wd87x   1/1     Running   0          12m

- Delete the cluster when no longer needed

$  kind delete cluster --name kind-cluster

Deleting cluster "kind-cluster" ...
Deleted nodes: ["kind-cluster-control-plane"]

Setting Up a Kubernetes Cluster with K3D

K3D is a tool that allows you to run lightweight Kubernetes clusters using K3S inside Docker. It is a great choice for fast, local Kubernetes development.

Prerequisites

- Docker installed on your machine. (installation guide)

- K3D CLI installed. (installation guide)

- Kubectl CLI installed. (installation guide)

Create a Cluster with K3D

- Create a new K3D cluster:

$ k3d cluster create my-k3d-cluster

INFO[0000] Prep: Network
INFO[0000] Created network 'k3d-my-k3d-cluster'
INFO[0000] Created image volume k3d-my-k3d-cluster-images
INFO[0000] Starting new tools node...
INFO[0000] Starting node 'k3d-my-k3d-cluster-tools'
INFO[0001] Creating node 'k3d-my-k3d-cluster-server-0'
INFO[0001] Creating LoadBalancer 'k3d-my-k3d-cluster-serverlb'
INFO[0001] Using the k3d-tools node to gather environment information
INFO[0001] HostIP: using network gateway 172.20.0.1 address
INFO[0001] Starting cluster 'my-k3d-cluster'
INFO[0001] Starting servers...
INFO[0001] Starting node 'k3d-my-k3d-cluster-server-0'
INFO[0008] All agents already running.
INFO[0008] Starting helpers...
INFO[0008] Starting node 'k3d-my-k3d-cluster-serverlb'
INFO[0016] Injecting records for hostAliases (incl. host.k3d.internal) and for 2 network members into CoreDNS configma
p...
INFO[0018] Cluster 'my-k3d-cluster' created successfully!
INFO[0018] You can now use it like this:
kubectl cluster-info

- Check the cluster status:

$ kubectl cluster-info

Kubernetes control plane is running at https://0.0.0.0:46503
CoreDNS is running at https://0.0.0.0:46503/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://0.0.0.0:46503/api/v1/namespaces/kube-system/services/https:metrics-server:https/p
roxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

- List available nodes:

$ kubectl get nodes

NAME                          STATUS   ROLES                  AGE     VERSION
k3d-my-k3d-cluster-server-0   Ready    control-plane,master   2m33s   v1.30.4+k3s1

Create Simple Deployment

- Use the kubectl create deployment command to define and start a deployment:

$ kubectl create deployment httpd --image=httpd

- Check deployment status using kubectl get deployment command:

$ kubectl get deployment

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
httpd   0/1     1            0           45s

- Verify the Pod status:

$  kubectl get pods

NAME                     READY   STATUS    RESTARTS   AGE
httpd-56f946b8c8-84ww8   1/1     Running   0          9m11s

- Expose the deployment:

$ kubectl expose deployment httpd --port=80 --type=LoadBalancer

- Try to access using browser:

- Delete the cluster when no longer needed:

$ k3d cluster delete my-k3d-cluster

INFO[0000] Deleting cluster 'my-k3d-cluster'
INFO[0001] Deleting cluster network 'k3d-my-k3d-cluster'
INFO[0001] Deleting 1 attached volumes...
INFO[0001] Removing cluster details from default kubeconfig...
INFO[0001] Removing standalone kubeconfig file (if there is one)...
INFO[0001] Successfully deleted cluster my-k3d-cluster!

Setting Up a Kubernetes Cluster on AWS EKS

Amazon Elastic Kubernetes Service (EKS) is a fully managed Kubernetes service on AWS, designed for running production workloads.

Prerequisites

- AWS CLI installed and configured. (installation guide)

- EKSCTL CLI installed. (installation guide)

- Kubectl CLI installed. (installation guide)

Create a cluster on EKS

To create a Kubernetes cluster in AWS, you can use the AWS Console (dashboard) or the eksctl CLI. For this guide, we will use eksctl.

We will provisions an EKS cluster with two t4g.small nodes in the us-east-1 region, making it ready for running Kubernetes workloads.

$ eksctl create cluster  \
--name cluster-1  \
--region us-east-1 \
--node-type t4g.small \
--nodes 2 \
--nodegroup-name node-group-1

2025-02-01 19:52:35 [ℹ]  eksctl version 0.202.0
2025-02-01 19:52:35 [ℹ]  using region us-east-1
2025-02-01 19:52:37 [ℹ]  setting availability zones to [us-east-1c us-east-1f]

...

2025-02-01 20:02:04 [ℹ]  creating addon
2025-02-01 20:02:04 [ℹ]  successfully created addon
2025-02-01 20:02:05 [ℹ]  creating addon
2025-02-01 20:02:06 [ℹ]  successfully created addon
2025-02-01 20:02:07 [ℹ]  creating addon
2025-02-01 20:02:07 [ℹ]  successfully created addon
"us-east-1" region is ready

- Access AWS console, navigate to the EKS service and you can see the cluster is successfully created.

- List available nodes:

kubectl get nodes
NAME                             STATUS   ROLES    AGE   VERSION
ip-192-168-xx-yy.ec2.internal   Ready    <none>   17m   v1.30.8-eks-aeac579
ip-192-168-xx-yy.ec2.internal   Ready    <none>   17m   v1.30.8-eks-aeac57

Create Simple Deployment

- Use the kubectl create deployment command to define and start a deployment:

$ kubectl create deployment nginx --image=nginx

deployment.apps/nginx create

- Check deployment status using kubectl get deployment command:

$  kubectl get deployment

NAME     READY   UP-TO-DATE   AVAILABLE   AGE
nginx    1/1     1            1           23s

- Verify the Pod status:

$ kubectl get pods

NAME                     READY   STATUS         RESTARTS   AGE
nginx-bf5d5cf98-9dld5    1/1     Running        0          43s

- Expose the service:

$ kubectl expose deployment nginx --type=LoadBalancer --port=80 --name=nginx-service

- Try to access using the browser:

- Delete the cluster when no longer needed:

$  eksctl delete cluster --name cluster-1 --region us-east-1

2025-02-01 20:51:59 [ℹ]  deleting EKS cluster "cluster-1"
2025-02-01 20:52:02 [ℹ]  will drain 0 unmanaged nodegroup(s) in cluster "cluster-1"
2025-02-01 20:52:02 [ℹ]  starting parallel draining, max in-flight of 1
2025-02-01 20:52:04 [ℹ]  deleted 0 Fargate profile(s)
2025-02-01 20:52:13 [✔]  kubeconfig has been updated
2025-02-01 20:52:13 [ℹ]  cleaning up AWS load balancers created by Kubernetes objects of Kind Service or Ingress
2025-02-01 20:52:56 [ℹ]
...

2025-02-01 21:02:00 [ℹ]  waiting for CloudFormation stack "eksctl-cluster-1-nodegroup-node-group-1"
2025-02-01 21:02:01 [ℹ]  will delete stack "eksctl-cluster-1-cluster"
2025-02-01 21:02:04 [✔]  all cluster resources were deleted

Conclusion

Setting up a Kubernetes cluster is the first step in running containerized applications at scale. In this guide, we’ve explored three different ways to create a Kubernetes cluster and do a simple deployment: using Kind and K3D for local development and using EKS for cloud-based deployments. Each method has its own advantages depending on your use case.

Thanks for reading this post. Stay tuned!

References:

- KUBERNETES UNTUK PEMULA. https://github.com/ngoprek-kubernetes/buku-kubernetes-pemula.

- How do I install AWS EKS CLI (eksctl)?. https://learn.arm.com/install-guides/eksctl

Let’s start again. Now I’m going to talk about Controllers in Kubernetes. In Kubernetes, a Controller is like a cluster’s brain, constantly working to ensure the system maintains its desired state. By monitoring objects such as Pods, Deployments, or DaemonSets, Controllers automate tasks and handle changes dynamically. Understanding Controllers is key to grasping how Kubernetes orchestrates and manages workloads seamlessly.

Common Kubernetes Controllers

Here are some of the most commonly used Controllers in Kubernetes:

1. Deployment

Deployments manage updates to Pods and ReplicaSets declaratively by transitioning the current state to the desired state step-by-step. They can create new ReplicaSets, adopt existing resources, or remove old Deployments.

Common uses for Deployments include:

a. Releasing a ReplicaSet and monitoring its status.

b. Updating Pod specifications to declare a new desired state.

c. Scaling up to handle increased load.

d. Rolling back to a previous version if the current state is unstable.

e. Cleaning up unused ReplicaSets.

2. ReplicaSet

ReplicaSets (RS) function as controllers in Kubernetes, responsible for maintaining a consistent number of running Pods for a specific workload. Acting as the mechanism behind the scenes, the ReplicaSet controller continuously monitors the state of the Pods and ensures the desired replica count is maintained. If a Pod crashes, is evicted, or fails for any reason, the ReplicaSet controller swiftly creates new Pods to restore the desired state, ensuring resilience and uninterrupted service.

In practical use, ReplicaSets are not typically managed directly by users. Instead, they are controlled through Deployments, which leverage the ReplicaSet controller while providing additional features such as rolling updates, rollbacks, and declarative workload management. This abstraction allows users to benefit from the reliability and scalability of ReplicaSet controllers without dealing with their complexities directly.

3. DaemonSet

DaemonSet (DS) ensures that every or specific nodes in a cluster run a copy of a particular Pod. When a new node is added, DaemonSet automatically creates a Pod on that node. Conversely, when a node is removed, the associated Pod is deleted by the garbage collector. Deleting the DaemonSet removes all Pods it created.

Common uses of DaemonSet:

1. Running storage daemons across nodes, such as Glusterd or Ceph.

2. Running log collection daemons across nodes, such as Fluentd or LogStash.

3. Running node monitoring daemons, such as Prometheus Node Exporter, Flowmill, or New Relic Agent.

DaemonSet is ideal for tasks that require processes to run on every node, such as log collection, monitoring, or providing local volumes.

4. StatefulSet

A StatefulSet is a Kubernetes controller used for managing stateful applications. Unlike Deployments, which focus on stateless workloads, StatefulSet is designed for applications that require persistent identity and stable storage. It ensures that each Pod it manages has a unique, stable network identity and maintains a strict order during creation, scaling, or deletion.

Key Features of StatefulSet:

1. Stable Network Identity: Each Pod gets a unique and persistent DNS name (e.g., pod-0, pod-1), which remains consistent even after rescheduling.

2. Ordered Pod Deployment and Scaling: Pods are created and scaled in a sequential order. For example, pod-0 must be created before pod-1, and the same applies during deletion.

3. Persistent Storage: StatefulSet works closely with PersistentVolumeClaim (PVC). Each Pod gets a dedicated PersistentVolume that remains intact even after the Pod is deleted or rescheduled.

Common Use Cases:

1. Databases like MySQL, PostgreSQL, and MongoDB, where stable storage and network identity are critical.

2. Distributed Systems like Cassandra, Kafka, or ZooKeeper, where maintaining order and state is essential.

3. Caching Systems like Redis, requiring predictable storage and replication across nodes.

5. Job

A Job is a Kubernetes controller designed to manage tasks that run to completion. Unlike Deployments or StatefulSets, which manage long-running or stateful applications, Jobs are used for short-lived workloads that need to be executed only once or a specific number of times.

Key Features of a Job:

1. Ensures Completion: A Job creates one or more Pods to perform a task and ensures that the task is completed successfully. If a Pod fails, the Job controller automatically creates a replacement until the task succeeds.

2. Parallelism: Jobs support parallel execution, allowing multiple Pods to run concurrently, controlled by the parallelism and completions parameters.

3. Retries: Jobs retry failed Pods until the task is successful or a specified backoff limit is reached.

Common Use Cases:

- Batch Processing: Data transformation, ETL pipelines, or video encoding.

- Database Operations: Running migrations, backups, or clean-up scripts.

- One-Time Tasks: Performing diagnostics, generating reports, or initializing configurations.

Thank you for reading this post.😀

References:

- KUBERNETES UNTUK PEMULA. https://github.com/ngoprek-kubernetes/buku-kubernetes-pemula.

- Kubernetes Documentation: Jobs. https://kubernetes.io/docs/concepts/workloads/controllers/job.

- Kubernetes Controllers. https://www.uffizzi.com/kubernetes-multi-tenancy/kubernetes-controllers.

- Kubernetes: DaemonSet. https://opstree.com/blog/2021/12/07/kubernetes-daemonset.

- Kubernetes StatefulSet vs Kubernetes Deployment. https://devtron.ai/blog/deployment-vs-statefulset.

Let’s start again. Now I’m going to talk about objects in Kubernetes. In Kubernetes, an object represents a record of intent, where you declare what you want the cluster to do. The Kubernetes control plane works continuously to ensure that the current state of your system matches the desired state described by these objects.

Common Kubernetes Objects

Here are some of the most commonly used objects in Kubernetes:

1. Pod

A Pod is a group of one or more containers that share storage, networking, and a defined runtime configuration. Containers within a pod are scheduled and deployed together, operating in the same execution context.

A pod acts as a logical host for tightly connected containers, enabling seamless communication via localhost and standard IPC mechanisms like SystemV semaphores or POSIX shared memory. Containers in different pods, however, have unique IP addresses and communicate using pod IPs, ensuring clear isolation while supporting inter-pod networking.

Like containers in an application, pods are considered relatively ephemeral entities. Their lifecycle involves creation, assignment of a unique UID, scheduling to a node, and remaining there until they are stopped, restarted, or deleted. You can see the pod life cycle from the image below.

If a node fails, all pods on that node are marked for deletion after a specific timeout. A pod with a unique ID will not be rescheduled to a new node; instead, it will be replaced by a new pod with a different ID.

2. Service

A Service in Kubernetes is an abstraction that defines a logical set of Pods and the policies for accessing them, often referred to as microservices. You can see the service balancing traffic across multiple pods in the image below.

For example, imagine a backend that provides image-processing functionality with three replicas. These replicas are identical, so the frontend doesn’t need to know which backend instance it uses. Even if the backend Pods change over time, the frontend doesn’t need to manage or track the list of current backends.

A Service decouples this complexity by providing a stable interface, allowing clients to interact with Pods without worrying about their lifecycle or specific details.

For applications running on Kubernetes, the platform provides a simple API endpoint that is continuously updated to reflect the current state of the Pods within a service.

For non-native applications, Kubernetes offers a virtual IP-based bridge that routes traffic to the backend Pods of the service. This ensures seamless integration and reliable access, regardless of changes in the underlying Pods.

3. Volume

A Kubernetes Volume provides a way for containers to access storage beyond their ephemeral lifecycle. Unlike a container’s local filesystem, which is destroyed when the container stops, a volume ensures data persists as long as the Pod using it exists. Kubernetes supports multiple volume types, such as emptyDir, hostPath, configMap, secret, and network-based storage like NFS or cloud provider-specific volumes.

Volumes can be shared among containers within the same Pod, enabling them to collaborate on data. However, when a Pod is deleted, the associated volume typically goes with it—unless you’re using Persistent Volumes (PV).

Persistent Volumes (PV) and Persistent Volume Claims (PVC)

A PV is a piece of storage provisioned in the cluster, either statically or dynamically. It is an abstract representation of storage resources like disks, network storage, or cloud storage, and exists independently of any specific Pod.

A PVC is a request for storage by a Pod. Users specify the required size, access modes (e.g., ReadWriteOnce, ReadOnlyMany), and storage class in the PVC. The cluster automatically binds the PVC to a suitable PV, providing the requested storage.

There are two methods to provide Persistent Volumes (PV)

1. Static

- The cluster administrator manually creates PVs by defining them in YAML manifests. - These PVs are available for binding with any PVC that matches their configuration.

2. Dynamic

- Kubernetes automatically provisions PVs based on the PVCs submitted by users.

- The cluster uses a StorageClass to determine the storage backend and provision the appropriate PV.

- This method simplifies administration by eliminating the need for pre-created PVs.

4. Namespace

A namespace in Kubernetes is a way to divide a cluster into virtual sub-clusters, providing logical isolation between resources. It is useful for organizing resources in environments with multiple teams, projects, or stages (e.g., development, staging, production).

By default, Kubernetes provides namespaces like default, kube-system, and kube-public. Users can create custom namespaces to segregate workloads and manage resource quotas, access controls, and policies independently for each namespace.

Namespaces are ideal for multi-tenant environments or to avoid naming collisions in large clusters. However, they don’t provide hard security boundaries and are primarily a tool for organizational purposes.

References:

- KUBERNETES UNTUK PEMULA. https://github.com/ngoprek-kubernetes/buku-kubernetes-pemula.

- Kubernetes Objects Guide. https://phoenixnap.com/kb/kubernetes-objects.