Kubernetes in 15 minutes

Rob “@zehicle” HirschfeldCEO/Founder, RackN

http://robhirschfeld.com

RackN leads in physical IT ops automationWe deploy multiple container workloads

Including Kubernetes, Docker Swarm, Mesophere, StackEngine and CloudFoundry

First, a Kubernetes Analogy

If building an application with containers is like making a house of cards

Then Kubernetes is like a robot that you can tell to build a layer at a time from the cards of your choice.

http://robotclipart.com/1024/3d-clipart-of-a-striped-silver-and-white-aomaru-robot-holding-a-joker-playing-card-by-leo-blanchette-314.jpg

Containers are lighter, faster VMs

That's not enough to explain the “container craze”

● Code Portabilty: developer environments can be cloned to each other or into production

● Light Weight: devs can run multi-tier app on laptop● Better Performance: less overhead, faster start-up

It's not all sunshine & rainbows: security is unproven, networking and storage are behind and it's still mostly about Linux

Workflow, not Containers vs VMs

VMs, once the backbone of “cloud computing”, have encourage application automation (DevOps) and decomposition (micro services) approach to flourish.

These changes increase portability and decrease lock-in especially since Linux is so widely adopted for cloud workloads.

It's really about workflow and tooling not environment

Google proved containers work at massive scale with highly automated tooling. The tooling accelerates app life-cycle.

Why now? This transformation was already happening at the platform layer (CloudFoundry, Heruko, etc) but Docker made it more accessible to Developers.

Application Decomposition

The 90s “service oriented architecture” is now called “micro-services”

Aka: the 90s called and they want their SOA back.

Fundamentally, all applications are composed of lots of individual parts.

Ideally, these parts are “loosely coupled.”

Decomposition simply means repackaging the loosely coupled parts into descrete units so they can be managed individually and accessed over network connections.

A Big, Automated Lifecycle

All the King's Horses and all the King's Men...

Once we've decomposed our application, now we have a lot of little parts floating around!

Coordinating all those parts is Orchestation.

If Done right, applications easier to deploy & maintain.

The platform manages:– Dependencies between components

– Order of operation for deployment

– Scale up and down of resources

– Tune and optimize performance

What is Kubernetes (aka K8s)

● Describes how components are connected● Deploys/maintains component instances● Relies on

– containers to package runnable application bits

– “meta data” files to describe relationships (YAML)

– correctly configured platform, storage and networks

● Key Ecosystems– Advanced orchestrators and tools to run k8s

– Trusted providers of containers

It's not.

PaaS is specialized version of container orchestration.

PaaS' key benefit is being opinionated

A clear pattern & structure makes it easier for developers to learn and use the platform.

Kubernetes is not opinionated, it's very flexible.

Most enterprises will want to consume it through add-on management tools.

Different than Platform (PaaS)?

Why is this hard?

1) Apps have to be (re)written for the platform

2) Lots of Confusion

1) Architecture patterns are still evolving

2) Container market is very competitive

3) Competing non-Containerized approaches

3) Unclear how to solve networking, storage & security

4) Need tools to “fire break” failures

5) Distributed systems are notoriously tricky

Why is this worth investment?

Sigificant gains in speed and performance

• Better application development life-cycle. Winning developers often means winning the data center.

• Larger developer communities (less skills)• Mortals can built & maintain scale operations• More portability between systems• Better use of infrastructure (density, on metal)

Adjacencies?

Fancy word for “additional services”

The unique part of an application is small.

The standard stuff is done in standard ways by services that should to “just work” and “just scale”

There is money in the supporting services that run these applications like data storage, networking and analysis.

Container orchestration is just part of a larger system of services that are required.

Adjacencies are essential and persistent.

Are we there yet?

It is possible that we have a “silver bullet” to allow mortals to create distributed systems

This is still early days in the evolution cycle

Google's success with Kubernetes assumes a lot of hidden disciplines and operational behaviors that may be hard to replicate.

The ecosystem is very noisy with a lot of investment. That speeds evolution at the price of added user confusion.

But yes, this is a long-term change in IT.

Demo...

Kubernetes Meta Data

apiVersion: v1kind: ReplicationControllermetadata: name: redis-master labels: name: redis-masterspec: replicas: 1 selector: name: redis-master template: metadata: labels: name: redis-master spec: containers: - name: master image: redis ports: - containerPort: 6379

Kubernetes Command Line

[root@demohost ~]# vi example.yml

[root@demohost ~]# kubectl create -f example.yml

replicationcontrollers/redis-master

[root@demohost ~]# kubectl get rc

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS

redis-master master redis name=redis-master 1

[root@demohost ~]# kubectl get pods

NAME READY REASON RESTARTS AGE

redis-master-t94pf 0/1 Pending 0 17s