Kubernetes Learning Notes - Part 5 - Horizontal Scaling and Rolling Upgrade

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:

Kubernetes Learning Notes - Part 4 - Service Bootstrapping with Init Containers

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.

Kubernetes Learning Notes - Part 3 - Service Discovery

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:

Kubernetes Learning Notes - Part 2 - Deploying Stateful Services

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.

Kubernetes Learning Notes - Part 1 - Deployment

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.

Kubernetes Learning Notes - Introduction

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.