Kubernetes

Kubernetes is an open-source platform for automating deployment, scaling, and

operations of application containers across clusters of hosts, providing container-
centric infrastructure.

With Kubernetes, you are able to quickly and efficiently respond to customer demand:

Deploy your applications quickly and predictably.

Scale your applications on the fly.

Roll out new features seamlessly.

Limit hardware usage to required resources only.

Portable: public, private, hybrid, multi-cloud

Extensible: modular, pluggable, hookable, composable
Self-healing: auto-placement, auto-restart, auto-replication, auto-scaling

Kubernetes can schedule and run application containers on clusters of physical or virtual
machines. However, Kubernetes also allows developers to cut the cord to physical and virtual
machines, moving from a host-centric infrastructure to a container-centric infrastructure,
which provides the full advantages and benefits inherent to containers. Kubernetes provides
the infrastructure to build a truly container-centric development environment.

What Kubernetes is not

Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. It
preserves user choice where it is important.

Kubernetes:
Does not limit the types of applications supported. It does not dictate application
frameworks (e.g., Wildfly), restrict the set of supported language runtimes (for example,
Java, Python, Ruby), cater to only 12-factor applications, nor
distinguish apps from services. Kubernetes aims to support an extremely diverse variety
of workloads, including stateless, stateful, and data-processing workloads. If an
application can run in a container, it should run great on Kubernetes.
Does not provide middleware (e.g., message buses), data-processing
frameworks (for example, Spark), databases (e.g., mysql), nor cluster storage systems
(e.g., Ceph) as built-in services. Such applications run on Kubernetes.

Does not have a click-to-deploy service marketplace.

Does not deploy source code and does not build your application. Continuous
Integration (CI) workflow is an area where different users and projects have their own
requirements and preferences, so it supports layering CI workflows on Kubernetes but
doesnt dictate how layering should work.

Allows users to choose their logging, monitoring, and alerting systems. (It
provides some integrations as proof of concept.)

Does not provide nor mandate a comprehensive application configuration

language/system (for example, jsonnet).
Does not provide nor adopt any comprehensive machine configuration,
maintenance, management, or self-healing systems.

On the other hand, a number of PaaS systems run on Kubernetes, such

as Openshift, Deis, and Eldarion. You can also roll your own custom PaaS, integrate
with a CI system of your choice, or use only Kubernetes by deploying your container
images on Kubernetes.

Since Kubernetes operates at the application level rather than at the hardware level, it
provides some generally applicable features common to PaaS offerings, such as
deployment, scaling, load balancing, logging, and monitoring. However, Kubernetes is
not monolithic, and these default solutions are optional and pluggable.
Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the
need for orchestration. The technical definition of orchestration is execution of a
defined workflow: first do A, then B, then C. In contrast, Kubernetes is comprised of a
set of independent, composable control processes that continuously drive the current
state towards the provided desired state. It shouldnt matter how you get from A to C.
Centralized control is also not required; the approach is more akin to choreography.
This results in a system that is easier to use and more powerful, robust, resilient, and
extensible.

ARCHITECTURE
Kubernetes Primitives and Key Words
Master

Minion/Node

Pod

Replication Controller

Service

Label

Namespace

Master
Typically consists of:

kube-apiserver

kube-scheduler

kube-controller-manager

etcd

Might contain:

kube-proxy

a network management utility

Minion - Node
Typically consists of:

kubelet
 kube-proxy

cAdvisor

Might contain:

a network management utility

May be referred to by either name.

POD
Single schedulable unit of work

Can not move between machines

Can not span machines

One or more containers

Shared network namespace

Metadata about the container(s)

Env vars configuration for the container

Every pod gets an unique IP

Assigned by the container engine, not kube!

Replication Controller
Consists of

Pod template

Count

Label Selector

Kube will try to keep $count copies of pods matching the label selector running

If too few copies are running the replication controller will start a new pod somewhere in the cluster
Services
How 'stuff' finds pods which could be anywhere

Define:

What port in the container

Labels on pods which should respond to this type of request

Can define:

What the 'internal' IP should be

What the 'external' IP should be

What port the service should listen on

Labels
List of key=value pairs

Attached to all objects

Currently used in 2 main places

Matching pods to replication controllers

Matching pods to services

Objects can be queried from the API server by label

Namespace

Attached to every object

Pods in ns1 will not get service variable from ns2

Users with permission to CRUD objects in ns1 may not have permissions to CRUS object in ns2

The network is not segregated!