Deploying a Flask API to Kubernetes with KIND and Argo CD

After containerizing the Task Management API and working on its CI/CD pipeline, the next stage of my DevOps capstone was learning how to deploy and manage the application using Kubernetes.

For this stage, I used KIND to create a local node Kubernetes cluster and Argo CD to introduce GitOps-based deployment.

I also worked on the monitoring requirements involving Prometheus and Grafana.

Here's an overview of the implementation.

1. Understanding the Architecture

The architecture was designed to run the containerized API on Kubernetes, expose it through a Service, and manage its deployment through Argo CD.

Architecture components

• KIND: Creates a local Kubernetes cluster using Docker containers as nodes.
• Kubernetes: Manages application deployment, scaling, and networking.
• Deployment: Maintains the required number of application replicas.
• Service: Exposes the application.
• ConfigMaps: Store non-sensitive configuration.
• Secrets: Store sensitive configuration.
• Argo CD:Supports GitOps-based deployment and synchronization.
• Prometheus and Grafana:Support metrics collection and visualization.

1. Creating the KIND Cluster

I started by setting up KIND and preparing a multi-node cluster.

The cluster contained:

• One control-plane node.
• Two worker nodes.

I used a KIND configuration file to define the cluster nodes and created the cluster.

After creation, I checked the nodes:

kubectl get nodes

I verified that the nodes were in the Ready state before proceeding.

1. Configuring the Kubernetes Deployment

Next, I created a Kubernetes Deployment for the Task Management API.

The Deployment used the Docker image published to Docker Hub.

I configured:

• The application image.
• Container port 8000.
• Two replicas.
• Rolling update strategy.

The Deployment ensured that Kubernetes maintained the desired number of application replicas.

1. Creating the Kubernetes Service

I created a NodePort Service to expose the application.

The Service mapped port 8000 to NodePort 30080.

This allowed access to the application through the Kubernetes cluster's exposed NodePort.

I also checked the Service endpoints to confirm that traffic could be directed to the application pods.

1. Configuring ConfigMaps and Secrets

I separated application configuration from the container image.

I created a ConfigMap for non-sensitive configuration values and a Kubernetes Secret for sensitive values.

The Deployment was updated to load these values through environment references.

This made configuration management more flexible and avoided hardcoding application settings into the image.

1. Implementing Rolling Updates

I configured the Deployment to use a rolling update strategy.

The strategy allowed Kubernetes to replace application pods gradually rather than terminating all existing pods at once.

I also worked with rollback functionality to understand how to return to a previous Deployment revision when an update causes problems.

1. Installing Argo CD

The next stage was introducing GitOps.

I created an 'argocd' namespace and installed the Argo CD resources in the cluster.

I checked the status of the Argo CD components to verify that the installation was progressing.

Argo CD provides a way to manage Kubernetes application deployments using the desired state defined in Git.

The intended workflow was:

1. Store Kubernetes manifests in Git.
2. Connect the repository to Argo CD.
3. Configure the application to track the repository.
4. Allow Argo CD to synchronize the desired configuration with the cluster.

5. Monitor application synchronization and health.

6. Monitoring with Prometheus and Grafana

The monitoring stage focused on understanding how to observe application and cluster performance.

Prometheus was selected for metrics collection, while Grafana was used for dashboards and visualization.
Prometheus and Grafana were part of the capstone monitoring work. The monitoring and alerting components were the next stage to configure and validate alongside the Kubernetes deployment.

1. Monitoring and Incident Response Goals

The monitoring requirements also covered:

• Building dashboards to visualize metrics.
• Configuring Slack notifications for alerts.
• Simulating incidents.

These activities demonstrate why monitoring is important after an application has been deployed.