Thinkings About Public Cloud Kubernetes

Kubernetes as a service? Working in public cloud, you probably hear more and more news about it. Right?

So many choices? What are things we need to be aware of, before I need to suggest one to my project? Here are things I usually examine. Discuss with me, if you’re also interested.

public-kubernetes.png



Apparently Google GKE in the leading role of public kubernetes market. And several key competitors like Amazon EKS, Azure AKS, Digitalocean DKS, or others(you name it).

Which one to choose for my project, if I want to host my workload as containers in public cloud?

The good news is most competitors are providing or will provide similar features like GKE. So they will look more and more similar. That’s why people call it cloud native.

But they may not be the same. Two reasons. It takes time to match up. Besides different player may have different strategies. This would make the game even more interesting!

Comparing to on-prem envs, running in public cloud is different by nature. There are things we need to be aware up-front.

Here are considerations I will seriously look into.

1.1 Basic

  • Invisible kubernetes master nodes
  • Node pools

1.2 Automatic upgrades?

In GKE, here are the default behaviors:

  1. The platform maintain the availablity of k8s master nodes. As customers, we don’t pay for master nodes.
  2. We trigger master nodes upgrade. Or we can even downgrade for minor versions.
  3. We trigger worker nodes upgrade with the batch of node pools.

Some kubernetes services may don’t expose this flexiblity to you. The platform does the upgrade with their schedule.

Why it matters?

  1. From version to version, kubernetes upstream may have breaking changes. Automatic bumping either k8s master version or worker version may not be a good idea, if you want to maintain SLA for your applications.
  2. Maintainance or changes of platform happens in your bussiness hours could be harmful, generally speaking.

1.3 Performance for key operations?

How fast it takes to create a pod? A loadbalancer service? A Volume?

And how fast it takes to delete a service? A namespace?

1.4 Rack-awareness deployment?

Anti-affinity can be applied to both VM and rack level.

Kubernetes services for different regions or different zones? Why it matters?

Thus we can avoid SPOF for not only VMs and racks. Different AZs would be good enough to acheive different racks deployment.

1.5 VM auto healing

What if my worker VMs go down or being hijacked somehow?

GKE owns “VM lifecycle management”. And you manage “Container lifecycle management”

1.6 What scale my deployment would grow?

Platform API may hang

1.7 How much it cost?

Usually computing resource, loadbalancing and network traffic are main factors for our cloud bills.

Use spot instance to save cost?

How big the footprint is? 300MB from GKE worker vms.

1.8 Built-in security benefits?

Docker image security: image sign & image scan.

Network security, instead of carefully manipulating iptables.

1.9 Add-on Features

Catalog/marketplace

Namespace multi-tenancy

Logging & Monitoring: Google stackdriver

Metrics: heapster


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.