Deployment

This repository contains the files used for the presentation of the project.

Note

This part of the setup, not necessary to use NodeFitter but useful to replicate what was demonstrated during the project presentation, uses Helm to install some components. To install Helm, run the following commands:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-4
chmod +x get_helm.sh
./get_helm.sh

All commands should be run from the root deployment directory of the submission repository

Important

If the various Helm commands are run where the Kubernetes control plane is located, installation may fail due to the control plane being tainted. It is possible to untaint the node by running

kubectl taint nodes <control-plane-node-name> node-role.kubernetes.io/control-plane:NoSchedule-

Important

Contrary to the installation of Kubernetes with minikube, the standard installation of kubeadm does not include any dynamic provisioner for PersistentVolumes, therefore, PersistentVolumes should be manually configured or it is possible to install a local dynamic provisioner like rancher local-path-provisioner. To install the mentioned provisioner via Helm, run:

kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

The Helm values under the helmCharts folder, as well as the PersistentVolumeClaim of Grafana, (see the monitoring.yml file), consider the mentioned provider as already installed.

Setup custom metrics for HPA

• Add the Prometheus Community Kubernetes Helm Charts with:

  helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
  helm repo update

• Install the kube-prometheus-stack without unnecessary component and set the namespace to monitoring

  helm install prometheus prometheus-community/kube-prometheus-stack --namespace monitoring --create-namespace -f ./helmCharts/prometheusChart.yaml

• Install the prometheus-adapter, necessary to make possible the retrieval of measurements by kubernetes:

  helm install prometheus-adapter prometheus-community/prometheus-adapter --namespace monitoring -f ./helmCharts/prometheusAdapterChart.yaml 

Setup logs collection

• Add the Grafana Community Helm Charts:

  helm repo add grafana-community https://grafana-community.github.io/helm-charts
  helm repo update

• Install loki to centralize logs:

  helm install loki grafana-community/loki -f ./helmCharts/lokiChart.yaml -n monitoring

• Add the Fluent Helm Charts with:

   helm repo add fluent https://fluent.github.io/helm-charts
  helm repo update

• Install fluent-bit (daemonset) to collect logs from the various nodes:

  helm upgrade --install fluent-bit fluent/fluent-bit -n monitoring -f ./helmCharts/fluentBitChart.yaml

Setup Grafana

Connection setup

Once logged into Grafana (default username is admin, default password is admin), go to the Connections section in the side menu, then select Data sources. Add:

• loki: leave all defaults, insert http://loki.monitoring:3100 as Connection address
• prometheus: leave all defaults, insert http://prometheus-kube-prometheus-prometheus.monitoring:9090 as Connection address

A copy of the connection information can be found in the grafana folder of this repository.

Dashboard setup

Once logged into Grafana (default username is admin, default password is admin), go to the Dashboards section in the side menu and import the dashboard available in the grafana folder of this repository.

Configure Secrets

Note

In case the username of the user created is modified, please remember to adapt the sql init file accordingly.

This project uses Kubernetes' secrets feature to pass sensitive information to the pods' environment such as database credentials.

Inside the secrets directory, create 2 files: app.env and mariadb.env. Example files are provided, modify them with the real credentials and save them without the .example extension. Ensure the values in the connection string in app.env match the ones given to the database:

DB_DSN=<MARIADB_USER>:<MARIADB_PASSWORD>@tcp(mariadb.backend:3306)/<MARIADB_DATABASE>

Deploy the Application

Finally, deploy the test application with the provided script:

./run.sh

If all goes well, the script will:

• Create the namespaces for the pods
• Create a ConfigMap for the database initialization
• Create the secrets from the secrets/app.env and secrets/mariadb.env files
• Apply the app, mariadb and monitoring manifests from the k8s/ directory

Note

Since this deployment is meant as a way to showcase the autoscaler application, the script has been equipped with a function to tear down the parts of the deployment it created upon being stopped

Use the Sample Application

The sample application that has just been deployed consists of an http server with 3 routes:

• / -> retrieves a random number from the DB and updates it with a new random number. Generates HPA metrics for both pods.
• /bypassCounter -> contacts the DB in a way where only the latter generates metrics for HPA.
• /pingo -> returns a response from the server, generating HPA metrics for the application only (and yes, it is misspelled, it's been an inside joke during development).

You can test this with a tool like curl after getting the service IP from Kubernetes:

kubectl get service -n frontend
curl <service_address>:8080/<route>

Use this application to generate traffic and cause Kubernetes to deploy more replicas of the two services. Once individual nodes are scheduled with enough pods, causing them to no longer have enough resources, the autoscaler application will read the metrics and it should be able to deploy more nodes.