A short and high level presentation about what and why is there Kubernetes

what-and-why-is-there-kubernetes.md

What and Why is there Kubernetes?

What?

• 
  • source: https://kubernetes.io/
• In order to better understand, let's continue with a story of "Why?"

Why?

• Short and simplified interpretation of the history
  • 
    • source: https://www.pinterest.com/pin/146507794100439642/
• Not so long ago...
  • It was pretty common to have these large monolithic applications
    • 
      • source: https://odino.org/on-monoliths-service-oriented-architectures-and-microservices/
  • Maybe just a Java jar that contained the service and its dependencies?
    • 
  • And this would be deployed by SSH-ing into the Production virtual machine?
    • source: https://developpaper.com/two-ways-to-create-ssh-server-aliases-in-linux-system/
  • Creating environments would be a lot of manual work
    • True, configuration management and infra-as-code tools appeared
    • 
      • source: https://www.getfilecloud.com/blog/2014/08/top-8-configuration-management-tools-for-sys-admins/
    • But the problem was not completely solved
  • Local development environments would be quite different from stage and production environments
    • ...if there even were so many environments
    • Remember this?
      • source: https://medium.com/nona-web/the-curious-case-of-nuxt-error-reference-error-geoip2-is-not-defined-b808284b024b
    • "And then Docker was created"
• And then Docker was created
  • 
    • source: https://opensource.com/resources/what-docker
  • Now you can ship your dev machine
    • 
      • source: https://www.reddit.com/r/ProgrammerHumor/comments/cw58z7/it_works_on_my_machine/
    • But... "Sometime in this timeline, microservices became a thing"
• Sometime in this timeline, microservices became a thing
  • 
    • source: https://microservices.io/
  • 
    • source: https://nordicapis.com/should-you-start-with-a-monolith-or-microservices/
  • So everyone started splitting their monoliths
    • 
      • source: https://ykode.id/building-microservices-within-bounded-context-be459acba199
  • Which meant that instead of having to deploy 1 or 2 Docker container you had to deploy TENS of them
    • 
      • source juggler: http://www.circusberzercus.co.uk/elfic-the-juggler/
      • source docker logo: https://www.subpng.com/png-6rhdhk/download.html
  • What about scaling them differently?
    • 
      • source: https://en.wiktionary.org/wiki/scales
  • Enter Kubernetes!
    • 
      • source: https://logos-download.com/32692-kubernetes-logo-download.html
    • So what is Kubernetes? "What? continued"

What? continued

• Let's have a look at this again
  • 
• I see Kubernetes being composed of logical 2 components
  • Master and Workers
    • 
  • An imperfect analogy
    • Master <-> our brain
    • Workers <-> the other parts of our body that our brain controls
    • 
  • The Master includes (besides other components)
    • The API server - most of the communication with the cluster and between its components happens through the API
    • etcd - a key value database where the state of the cluster is kept (the cluster "memory")
    • 
  • Zooming on a Worker (which is basically a VM) - a cluster can have several workers
    • There are several Kubernetes processes
    • And a number of pods which each contain 1 or more Docker containers
    • The services deployed on the cluster run in these containers
    • 
• When we deploy a service, we tell Kubernetes what is the end state we want (how many instances of the service, how should it be exposed outside the cluster etc.)
  • 
• And if it has the resources available, it will make it happen
  • Kubernetes will try to spread the instances (pods) along its worker nodes
  • Or if it doesn't have enough nodes with available resources, it might put all instances (pods) on the same node
  • 
• One more thing... namespaces
  • Pods, services, many Kubernetes resources are organised in namespaces across nodes
  • Namespaces provide isolation between the resources in the cluster
  • You can assign roles to users and give them access to do specific actions on specific namespaces
  • 
  • In reality, pods might look more like this when it comes to namespace distribution across nodes
  • 
    • (rectangles are pods of different sizes, colours represent the namespace they are part of)

THE END

• 

I think the mistake we made was to be too dependent and tightly coupled to the environment. Is it really worth it?

Other big mistake was leaving the trees, but that’s another story ;)

Many microservices setups I see today are too tightly coupled. Not making things better in my view when they are done this way. Just moving the pain further.

I referred to the problems we solved with docker on your historical outline.

Ah, sorry, I assumed you were talking about the microservices part.

In what way were we too dependent on the environment? And what would've been the alternative?

Well docker was a hit because it addressed that problem, as you state yourself. So we evidently had a problem with tight coupling to a complex “environment “.

I’m thinking about how we ended up here. Longer term perspective. Why have things gotten so complicated? Or haven’t they? Maybe we solved the “environment” problem in the wrong way, and then things just continued in a tangential direction.

It’s a complicated story to go into specifics, but it was a architectural smell to depend on a complex environment. Are as decoupled as we should be today on K8s? Maybe? But did we need all this machinery to solve our essential problems?