This repository serves as the project for the Kubernetes course by the Facultad de Ingeniería UdelaR. Within this project, you'll find a web application developed with React that performs real-time calculations of the Fibonacci sequence based on user input.
The application is divided into two primary components: a frontend built as a React application and a backend powered by an Express server. The backend includes a specialized worker module that handles the computation of the Fibonacci sequence and stores the results in a Redis database. Moreover, the Express server utilizes a PostgreSQL database to store the historical input values.
The frontend communicates with the backend API, enabling users to access both the current Fibonacci sequence values and the historical input data.
The primary objective of this project is to containerize the application using Docker and deploy it using Kubernetes.
This project employs a 3-layer architecture, consisting of the following layers:
-
Front-end: This layer is represented by the React app, which serves as the user interface for interacting with the application.
-
Back-end: The logic layer is composed of the Express server and the Worker, which handle the application's data processing, and computation of the Fibonacci sequence.
-
Storage: The data layer encompasses both the PostgreSQL and Redis databases, where historical input values and computed Fibonacci sequence values are stored, respectively.
-
Nginx Web Server: This component routes incoming traffic to various services based on the request type. When accessing the frontend, Nginx directs the request to the React server, and when accessing the backend API, it sends the request to the Express server.
-
React App (Client): The frontend of the application, responsible for user interaction.
-
Express Server: This server acts as the API layer for the React app, handling requests and responses.
-
PostgreSQL Database: This database stores historical input values.
-
Redis Database: This database stores the computed Fibonacci sequence values and serves as a queue for the worker to process.
-
Worker: This component monitors the next Redis index value and calculates the Fibonacci sequence. Once computed, it stores the results back in Redis.
The Kubernetes architecture relies on pods to encapsulate the application containers, promoting scalability and ease of administration. The primary k8 objects utilized are Deployments and Services configured as Cluster IPs.
Deployment objects enable the scaling of client, service, and worker pods as needed. Services, on the other hand, are employed to enable internal network connectivity among the pods. In addition, a Persistent Volume Claim (PVC) is employed for database storage.
Furthermore, the Nginx Ingress Controller serves as the primary gateway for external traffic entering the Kubernetes cluster. It efficiently handles load balancing and routing, simplifying external access to the cluster's services. This controller also incorporates a default backend for health checks.
-
Ingress Nginx Controller - v1.8.2
-
Redis - v7.2.2
-
Postgres - v10.1
The Ingress Nginx Controller is configured based on the documentation available at: Ingress Nginx Quick Start Guide
- This documentation provides instructions on deploying and configuring the Ingress Nginx Controller within a Kubernetes environment.
- Install the Helm Chart:
$ helm install webapp-release-v1 webapp/
- Install the Ingress Nginx Controller
$ helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx --create-namespace
or
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
- Access the application in your web browser using the following URL:
http://localhost
Build the Docker images:
$ docker build -t <name>/worker:<version> ./worker
$ docker build -t <name>/client:<version> ./client
$ docker build -t <name>/server:<version> ./server
Replace <name>
with your Docker image repository name and <version>
with the desired version or tag for your images.
Push the Docker images to your repository:
$ docker push <name>/client:<version>
$ docker push <name>/worker:<version>
$ docker push <name>/server:<version>
To deploy the application on a Kubernetes cluster using kubectl
:
Apply the Kubernetes configurations in the "k8" folder to create the necessary resources:
$ kubectl apply -f k8
Check the status of the deployed pods:
$ kubectl get pods
Check the services to ensure they are up and running:
$ kubectl get services
Verify the deployments:
$ kubectl get deployments
Check the Persistent Volume (PV) and Persistent Volume Claim (PVC):
$ kubectl get pv
$ kubectl get pvc
To access the application in your web browser, use the following URL:
http://localhost
- "context deadline exceeded" error when deploying the Ingress Nginx Controller:
- Try redeploying the Ingress Nginx Service using the following command:
kubectl apply -f ingress-service.yaml
- Try redeploying the Ingress Nginx Controller using the following command:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
- Try increasing the timeout value in the Ingress Nginx Controller deployment configuration file.
- Try redeploying the Ingress Nginx Service using the following command:
- kubectl version: v1.28.2
- helm version: v3.13.0
To install the Chart with the release name my-release
:
$ helm install my-release webapp/
The comand deploys the web app on the Kubernetes cluster with the default configuration.
To deploy the Ingress Nginx Controller using Helm:
$ helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx --create-namespace
or if you prefer to use a YAML manifest:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
To list the releases:
$ helm list --all-namespaces
To get the status of a release:
$ helm status <release>
To upgrade the release with a modified configuration, save the new values.yaml file and run the following command:
$ helm upgrade my-release webapp/ --values webapp/values.yaml
To uninstall the Chart with the release name my-release
:
$ helm uninstall my-release --keep-history # keep history for rollback purposes
The following table lists the configurable parameters of the Web App chart and their default values.
Parameter | Description | Default |
---|---|---|
Name |
Dynamic Helm Release Naming for Kubernetes Deployments | |
namespace |
Custom Kubernetes Namespace Configuration for Application Deployment | default |
client.replicaCount |
Client Deployment Pods Number Configuration | 3 |
client.image.repository |
Client Docker Image name | enzofali/multi-client |
client.image.tag |
Client Docker Image version | v1 |
server.replicaCount |
Server Deployment Pods Number Configuration | 3 |
server.image.repository |
Server Docker Image name | enzofali/multi-server |
server.image.tag |
Server Docker Image version | v1 |
worker.replicaCount |
Worker Deployment Pods Number Configuration | 5 |
worker.image.repository |
Worker Docker Image name | enzofali/multi-worker |
worker.image.tag |
Worker Docker Image version | v1 |
postgres.replicaCount |
Postgres Deployment Pods Number Configuration | 1 |
postgres.image.repository |
Postgres Docker Image name | postgres |
postgres.image.tag |
Postgres Docker Image version | 10.1 |
redis.replicaCount |
Redis Deployment Pods Number Configuration | 1 |
redis.image.repository |
Redis Docker Image name | redis |
redis.image.tag |
Redis Docker Image version | 7.2.2 |
pvc.accessModes |
Persistent Volume Claims Storage Access Mode Configuration | ReadWriteOnce |
pvc.storageSize |
Persistent Volume Claims Storage Size Configuration | 1Gi |
service.type |
Service Type Configuration for Internal Networking | ClusterIP |