Home
This project focuses on optimizing the performance and enabling elastic scalability for the SockShop application based on different workload scenarios. The primary objective is to identify performance bottlenecks, refactor the application to improve performance, and establish mechanisms for dynamic workload management.
SockShop is a sample e-commerce application that serves as a reference implementation for microservices architecture and cloud-native development. It provides an interactive platform for users to browse and purchase various types of socks. SockShop showcases best practices for building scalable, resilient, and containerized applications while demonstrating the use of different technologies and frameworks.
Here is an overview of how the application is built and how different microservices interact with each other:
Navigate to the microservices-demo/deploy/kubernetes folder from the terminal and run
kubectl apply -f complete-demo.yaml
This will start all the services.
To set up WeaveScope with Kubernetes, follow this guide. Run the following command to deploy the Scope app:
kubectl apply -f https://github.com/weaveworks/scope/releases/download/v1.13.2/k8s-scope.yaml
Make WeaveScope is accessible from the browser. This command establishes a network tunnel between the local port 4040 and a specific pod in the weave namespace of the Kubernetes cluster. The pod is selected based on the label weave-scope-component=app. Once the command is executed, any traffic sent to the local port 4040 will be forwarded to the specified pod, allowing you to access services or resources running in that pod through your local machine.
kubectl port-forward -n weave "$(kubectl get -n weave pod --selector=weave-scope-component=app -o jsonpath='{.items..metadata.name}')" 4040
WeaveScope is now available at http://localhost:4040.
This is what the WeaveScope interface looks like. It shows the interactions between the services and can also measure CPU and memory usage.
As you can see, there is also a Prometheus node, which is connected to all services and scrapes metrics. These are then transferred to Grafana.
For the deployment of Prometheus and Grafana with Kubernetes, refer to this documentation.
Once Grafana is set up and the command kubectl apply -f 23-grafana-import-dash-batch.yaml is executed, 4 dashboards are imported in Grafana. This is what one of them looks like:
The Kubernetes Metrics Server can be deployed as an additional pod that monitors the rest of the pods by scraping their kubelets. The metrics server is also an important source of system information, because it used by the k8s Horizontal Pod Autoscaler (HPA). The HPA bases its decision to scale up or down on the monitoring the Metrics Server provides.
To spin up the Metrics Server, simply follow this guide.
When the Metrics Server is active, it gathers data from the pods:
After the Metrics Server is set up, the data it generates can be displayed in Kubernetes Dashboard - a web-based graphical user interface (GUI) that provides a visual representation of a Kubernetes cluster. It allows users to manage, monitor, and troubleshoot their applications and resources running on a Kubernetes cluster through an intuitive web interface. It's important to note that this UI can only be used with an actively running Metrics Server. Otherwise, Dashboard cannot receive the metrics.
For setting up the Kubernetes Dashboard, refer to this guide.
For running the load test with Locust, take a look at this guide. The command simply needs to be run from the cnae-sockshop/load-test folder. This is what the output looks like:
One of the errors we encountered said Error: POST /orders: HTTPError(406 Client Error: Not Acceptable for url: /orders).
This refers to an error that occurs, when trying to place the order to the /orders endpoint. We encountered the error, while repetitively running the load test with the standard SockShop credentials, meaning from one account. This kept adding items to the cart. SockShop has a built-in max limit of the order's value and that is $100. So make sure you clear your cart of all the items, before running the test again. However, the current version of the load test creates a new user each run, so you shouldn't encounter this error.