Spawning Kubernetes Clusters in CI for Integration and E2E tests

Making sure your application works correctly is an important step before deploying changes or merging a Pull Request. You want to be sure that incoming changes are not going to introduce any regressions and negatively effect any part of the system. This is usually done by writing and running Integration and E2E tests. In order to make sure you have a clean testing environment to prevent possible errors, and to make it easier to test all incoming changes, running Integration and E2E tests in CI is recommended.

GSoC Journey: Week 2 — Getting started with Kubernetes & KubeCon

In the previous post, I was talking about weeks 1 and 3 of the GSoC Community Bonding period. I mentioned going to KubeCon on week 2 and that I’ll write a dedicated post covering it. It could be overdue at this point, but here it is! This is maybe not related to my GSoC journey at all, but it impacted it a lot, taught me a lot about Kubernetes, and is a very valuable experience.

GSoC Journey: Weeks 1 & 3 — Community Bonding

On Monday, April 23rd, I got accepted as a Google Summer of Code student, to work with Cloud Native Computing Foundation. Over the next four months, I’ll be working on the Kubernetes project, implementing a new API server for handling etcd storage for aggregated API servers. I’ll not go too deep into the project details, but if you’re interested to learn more about what I’m working on, you can check:

Debugging Kubernetes (using GoLand IDE)

Many of us got used to the fmt.Printf debugging. It’s an okay way to print a variable if you suspect it’s wrong. However, while this can work on the smaller project, this is almost impossible for big projects, whose structs have numerous fields, and the logic is spanned across many files and packages. One of those projects is Kubernetes. When I was getting around the project in order to prepare my proposal for Google Summer of Code, one of my tasks were to debug why CRD creation age is set to <invalid>.