Journey to GSoC, SCoRe Lab, KubeBot & Community Bonding Period

Hey There,

So in my previous blog [link] , I talked about introductory things on GSoC, Open Source, Submitting a Proposal etc. Here I am going to discuss about my journey from first hearing the word GSoC to starting working in it with SCoRe Lab.

I still remember once I was hanging around with my friends in institute’s campus and they were talking about a senior who got selected in GSoC. The name itself caught my attention and I started ‘googling’ about it. I had just started going through cloud computing and kubernetes in particular, was blowing my mind. I have been planning to start open source contribution and GSoC seems like a Golden Ticket to me.

I’ll get so much to learn in such a short period!
I’ll be interacting with amazing developers!!
I’ll be part of open source community!!!
I’ll be developing something entirely new!!!!
GOOGLE!!!!!

and then it struck me… “bhai pehle select to ho ja 😅” (“dude, you gotta get selected first”)

So, I buckled up, and went through as much as resources I can across internet go hit my goal.

So first thing first..

The Timeline!

The entire GSoC has been planned and scheduled in a strict timeline, and yes, it’s very strict, so don’t even think about leaving anything for last minute as there will be NO extensions whatsoever.

The program typically begins in February, Coding begins in June and concludes around September (depending upon the length of your project). The standard coding period is 3-months long project duration.

The timeline for year 2022 can be found through this link.

Google Summer of Code 2022 Timeline | Google Developers

Falling for SCoReLabs 😍

While going through different organizations in accordance to my preferable tech stack, I came across SCoRe Lab. Firstly, to my delight, I found an absolutely amazing project of KubeBot for kubernetes, which I will discuss about in detail later.

SCoRe Lab is opensource research group which covers various aspects of sensor networks, embedded systems, digital forensic, information security, mobile applications, cloud, blockchain and software tools. SCoRe Lab has floated a project on Kubernetes which was aligned to my interest area.
The goal of their research is to generate computing solutions through identifying low cost methodologies and strategies that lead to sustainability.

I started interacting with mentors and members of SCoRe Lab community and I was amazed to see a bot replying to my messages in their dedicated GSoC gitter channel (so cool, right?). After that, I explored their official website where I found a dedicated GSoC Page. SCoRe Lab has whole community channel, dedicated project specific gitter channels, general discussion channel and responsive, welcoming community. In no time I decided to submit 2 proposals in SCoRe Lab only.

Oh yeah, Proposal !!

Recalling the Rock gif above, I have a proposal to make. So I started going through the project details and discussing the vision, scope and tech for the project I was targetting.

Pro tip: Always read previous messages. Sometimes, there might be some questions which haven’t even popped in your mind, might have been asked by someone else.

The first step I take towards solving a problem or doing a task is to first understand the problem statement thoroughly. After I understood the concept of KubeBot and what was expected out of the project, I started going through the code-base at github. I studied and went through different components and tech stack I needed as tool to build kubebot. And after I was convinced and satisfied with the solution I have reached on (discussed later), discussing with mentors and doing my own research on the project, I started building a proposal.

So what I am working on?

So Kubernetes is a great tool for container orchestration. Running Kubernetes in your production environment is getting traction in the Cloud industry. With growing DevOps tools, it is now a tedious and time-consuming task SREs and developers to continuously monitor their remote applications running inside a multicluster Kubernetes environment. Though there are some great tools using which we can monitor Kubernetes tools there is a need for easy deployment setup and an alerting tool that people can use to get alerts when something goes wrong inside their application running in a Kubernetes environment. It is often time-consuming to figure out the root cause of such issues, and most importantly not all alerts and issues are important and do not need human interaction.

High level architecture of Kubernetes, API server will be used to get Metrics, Traces, Events and
Logs

KubeBot is a smart tool that pulls out of box metrics, traces, events and logs collection for applications running inside Kubernetes and reports all the collected data on a single dashboard and push notifications to users for critical ones. A major feature of KubeBot is that after collecting traces, it performs a machine learning based Root-Cause Analysis and sends alerts to the user regarding fixing the issue occuring in the cluster. The collected metrics, traces, events and logs will help to debug the application running inside Kubernetes faster and effectively.

Tech Stack:

1. Golang
2. Kubernetes
3. Prometheus
4. Grafana
5. Fluentbit
6. OpenTelemetry

Prometheus:

To pull the metric data from k8s pods and for monitoring purposes, I would be using Prometheus. Prometheus is a free software application used for event monitoring and alerting. It records real-time metrics in a time series database built using a HTTP pull model, with flexible queries and real-time alerting. In Kubebot, Prometheus will help us export all the metrics to Grafana and OpenTelemetry collector along with alerts to apps like Slack etc. The Prometheus is used to collect all the Metrics from any environment and infrastructure in which user applications are running and is used to send the metrics to the Grafana dashboard. It also provides the support for alert managers and sends the data to alert a manager to notify the user over slack or any of their prefered applications.

Generic flow using Prometheus

In addition to this Prometheus will also be exporting metrics to the OpenTelemetry collector which will help in the training of Kubebot by storing the collected metrics, traces, logs and events to a common data store.

Prometheus pulling metrics from Kubernetes nodes and sending alerts to Slack and webhooks

Grafana

Grafana is multi-platform open-source analytics and interactive visualization web application. It provides charts, graphs, and alerts for the web when connected to supported data sources.

This is what a common Grafana dashboard will look like

Opentelemetry Collector:

The open telemetry will be used to collect filters and do operations on all the collected metrics. It’s a common ingestion point for all the collected telemetry data. The open telemetry collector in kubebot will be responsible for telemetry data filtering and putting all the telemetry data into single storage, the machine learning model will make use of it to train itself and produce better alerts over time

OpenTelemetry Collection pipeline

Overall Architecture of KubeBot:

KubeBot Architecture

The details of my project can be found here:

Google Summer of Code

Community Bonding Period

As results were announced on 20th May 2022, the Community Bonding Period started from 21st May 2022 itself.

My mentors in the project were Pratik Dhanave, Swapnal Shahil and Mehant Kammakomati.

In the community bonding period, I came to know more about different projects, students and mentors of Scorelab via communicating through the common Gitter channel.

In the first few days of community bonding, we were asked to share medium account details where all the contributors will be writing blog of their GSoC journey ❤️

In my first meeting with the mentors, they introduced me to the organization and we discussed many things which included…

• discussed availability of everyone to schedule weekly call
• gitter channel and google space to reach out to mentors if I face any issue or encounter any problem
• pointers on updating daily work done and progress in group
• discussed and took an overview of how to begin coding part
• we planned to start coding part as quickly as possible so that we will avoid any last minute issues that might arise duing 1st evaluation.

So in the upcoming days, we decided to iron out a couple of things as follows and start the coding promptly;

1. I will brush up my coding skills in Golang and go through .yaml file configuration.
2. Understand kubernetes architecure, deployment instricacies and KPI which I will be including.
3. Take an overview of other techstack.
4. Re-evaluate the proposal and make any necessary changes in the workplan/timeline.
5. Start Coding.

That concludes my community bonding period and amazing squence of experience of entering in open source world.

Stay tuned, see you in blogpost of my 1st week of coding.

Adios!

PS:
Connect with me on:
Linkedin: linkedin.com/in/priyanshuraj400/
Github: github.com/priyanshuraj400
Twitter: twitter.com/priyanshuraj400