31/Aug 2017
7 min. read
Through out my career, I have investigated and solved numerous bizarre issues. This one is right up there as being one of the weirdest as well as being one of the most hilarious ones when the truth came out in the end.
At $DAYJOB, we are moving piece by piece our services to Kubernetes. One of such service slated for migration is the Gitlab runners. If you’re not familiar with Gitlab, it’s like Github you can self-host and it boasts a very powerful and flexible CI/CD pipeline.
6/Jun 2017
5 min. read
Some of the promises of Kubernetes are scaling and rolling upgrades. In this blog post, we’re going to try these out for our service to see how easy it is to achieve these operations which are otherwise difficult to do without a container orchestration tool.
Horizontal Scaling When we wrote the manifest for overmind deployment, we specified that we want 3 replicas of pods for this deployment. We can scale up the number of replicas to handle increased traffic by using kubectl scale command:
4/Jun 2017
4 min. read
Up until now, we have deployed the overmind service to the Kubernetes cluster, deployed the backing CouchDB service and wired up the two services through service discovery.
Web services usually have administerial tasks, such as bootstrapping a database. It’s usually a good practice that individual services are responsible for their own data initialization. This is where initContainers come in handy.
Init Containers Init containers run inside the same pod as your main container (such as the container that runs the microservice), just like any other containers.
31/May 2017
4 min. read
In the last two blog posts, we’ve set up our overmind service and the backend CouchDB service. How would the overmind service find out where the CouchDB service is? That’s where Service Discovery comes in.
In Kubernetes there are two ways to do service discovery: environment variables and DNS records.
Environment variables Every Service deployed in Kubernetes automatically gets a set of environment variables accessible to all pods. e.g., if the service name is couchdb, other pods will be getting the environment variables such as the following:
29/May 2017
9 min. read
In the last part of this series, we learned how to do a basic deployment of a stateless service. You may ask what about our CouchDB service? How do we deploy a database which is innately stateful to a Kubernetes cluster. Kubernetes 1.5+ has introduced Stateful Set feature which makes this possible.
Stateful Sets According to the docs, a stateful set provides containers with the following:
stable and unique network identifiers stable persistent storage ordered, graceful deployment and scaling ordered, graceful deletion and termination For deploying CouchDB, we need to deploy a stateful set of CouchDB containers which allows us to attach a persistent storage to the container so our overmind service does not lose its data.
27/May 2017
7 min. read
Welcome to the first part of my Kubernetes learning notes series. In this blog post, I’m going to record my learning experience for deploying the overmind web service to a Kubernetes cluster.
The overmind web service is a simple and contrived microservice for managing zerglings. Don’t worry if you’re not a starcraft fan. The details of the web service doesn’t really matter. The web service has a couple of endpoints, some of which involve talking to a database.
25/May 2017
2 min. read
Parts Part 1 - Basic Deployment Part 2 - Deploy Stateful Services Part 3 - Service Discovery Part 4 - Service Bootstrapping with Init Containers Part 5 - Scaling and Rolling Upgrades Goals At $DAYJOB we’re moving away from our homebrew way of deploying and “orchestrating” docker containers to the promise land of Kubernetes. To solidify my learning, I’m going to practise what I learn by coming up with a hands-on project deploying a simple dockerized microservice with a database backend onto a Kubernetes cluster.