This past month I prepared a talk titled Introduction to the Google Container Engine for the GDG DevFest in Karlsruhe. While doing so I thought it would be a good idea to write up all my ideas, no matter whether they ended up in the presentation or not. So here you go, a primer on Google Container Engine, Containers and Kubernetes.
First off, what is the Google Compute Engine (GCE)? It’s the public cloud from Google which offers modular cloud-based services like App Engine or Compute Engine. It’s comparable to other public cloud providers such as Amazon’s Amazon Web Services and Microsoft’s Azure.
The Google Container Engine (GKE) then is a service of Google’s public cloud platform which allows you to simply setup a Kubernetes cluster without worrying about the real setup on the VM’s. You can also use the Google Container Registry which is a simple storage for your Docker images, so that you can keep your images closer to the cluster and don’t need to use the Docker Hub. Kubernetes is hosted on CoreOS which runs on Google Compute instances (VMs).
1. It’s simple to set up
So why should I use the GKE instead of hosting it on my own? The first thing is you don’t have to worry about the setup of your cluster. Just type: gcloud container cluster create cluster-name and the GCE will create the cluster for you
2. It’s comfortable to use
Furthermore you can use all the nice features of the GCE such as firewalls, VPNs and so on, which means you can easily use Persistent Disks in your Docker images. This allows you to handle stateful services like a MySQL database (I don’t want to start a discussion about whether you should put a database in a container or not, so just accept this example or ignore it).Basically you crate the Persistent Disk and attach it to one or more Pods (a Pod is a collection of one or more Docker containers). Now when your Pod gets rescheduled the data is still there which is pretty nice. If you wanted to do the same on-premise you’d need to use a cluster file system like Ceph, GlusterFS or Quobyte, which require a lengthy setup themselves.
3. It’s (mostly) open source
The third reason I think the GKE is great is that it is build on open source components, so basically you can rebuild all the things on your own and in the end you would be talking to your on-premise Kubernetes using nearly the same configuration. So you can set up your cluster in GKE and later migrate the whole thing onto your own hardware if you want to. Also GCE (and some other public cloud providers) allow you to define “external load balancers” which are real load balancers on the cloud platform. These load balancers get their own public IP and can route your requests to your Pods inside your cluster (which isn’t accessible from the outside by default).
Since Kubernetes 1.1.1 auto-scaling of Replication Controllers is in Beta state and available for use on your cluster. This theoretically allows GKE to scale on different levels: On the first level you can monitor the cluster as a whole and when you notice that you need more resources you can easily add new nodes to your Kuberntes cluster, which are also setup by Google. You are also able to scale on the service level (service meaning a functional service not the service of Kubernetes). E.g. When you have hit peak load you can dynamically add more resources to the specific services and when your resources in your cluster reach their limit you just add a new node. When peak load is over your cluster can dynamically shrink again—this allows you to only pay more if you have high traffic.
So in conclusion when you like using Kubernetes or at least thought about tinkering with it you should definitely give GKE a try. It’s really amazing how fast you can start using Kubernetes without worrying about the setup process. To boil it down to one sentence: With GCE you get the fun part of Kubernertes without the hassle of setting it up.
You can find my slides and examples on github.
Get in touch