Differences between revisions 3 and 4
Revision 3 as of 2017-04-27 15:30:19
Size: 5437
Editor: Ted Herman
Revision 4 as of 2017-04-27 15:31:18
Size: 5531
Editor: Ted Herman
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

''This page has several inaccurate statements for the sake of a simplified introduction.''


This page has several inaccurate statements for the sake of a simplified introduction.

Recall that many applications which live in The Virtual World of Clouds run in virtualized environments. A recent trend in this area is to modularize applications into isolated, specialized subsystems and then connect these subsystems together to make a service. To the outside world, it can look like this service is running on a single computer, but in fact it is a cluster of subsystems.

Each subsystem can have its own support team of developers and choose its own programming languages, software packages and runtimes. Keeping track of all the language versions and software versions is laborious. People like to bundle all the supporting language and software into images, and containers are helpful for this. Docker images, for example, are an example technology to maintain and deploy applications which have been containerized.

The question remains, how can one connect up and run a containerized application? Here are things we would like to have:

  • automatic placement of container images onto clusters of servers.
  • a way to configure networking so that subsystems (of containers) find each other (typically through IP addresses, ports, and service discovery).
  • controlling mechanisms that watch for crashed nodes, crashed applications, and other errors -- then automatically restart using other healthy hardware.
  • policy algorithms that efficiently use hardware, put containers on platforms to effectively use resources (without waste).
  • mapping of requests from the outside world to running containerized applications to minimize latency, which improves service to customers.

Thus, what's needed is a way to orchestrate lots of containers. To make things scalable, sometimes there can be many running copies of the same containers (or even sets of containers). Such replication can help with fault tolerance. Also, this replication can be a way to scale up: a batch of incoming customer requests might be processed in parallel on different containers (which are replicas).

Docker Swarm is one example technique to orchestrate containers; other examples are Apache Mesos, AWS ECS, and Kubernetes. This page will look at Kubernetes.


Kubernetes is open-source software for container deployment. Kubernetes has management functions, to set up and configure containers on clusters, and also runtime functions that support container needs and connecting outside requests to applications running on the containers.

can be thought of as one computer in a cluster. Kubernetes needs to have a configuration file describing the node's LAN interfaces, memory size, disks, and processors.

is a logical unit of resources which is a subset of what a node has. A node can be logically partitioned into multiple pods. The term "host" is sometimes a synonym of pod (there is formally a difference, but for this introduction we are less formal).

is a bundled, specific application. Multiple containers fit into a pod. The idea here is to put related applications into the same pod so that communication between them is fast and efficient. For example, one container might have a database server, another container a web server. When put together in the same pod, the web server can request data from the database server right there.

Virtual Networking

One part of Kubernetes is dedicated to emulation of networking: this is needed between containers in a pod, and possibly between hosts in a node. In addition, there needs to be real networking in the cluster (between nodes) and network connections to the outside. There is a thorough description in the official documentation, though the description depends on lots of background (knowing jargon and networking concepts) to understand.


Kubernetes needs to schedule pods into nodes. Each container should have a description of its resource needs (memory, processing, disk) and thus each pod needs the sum of resources of its containers. Taking this into account, placing pods into nodes (which also have known capacities) resembles a problem of combinatorial optimization: it's often called "bin packing" scheduling.

Management and Services

Kubernetes provides worker node services, implemented through two software entities, Kubelet and Kube-proxy which run on each managed node. Kubelet manages containers, images, volumes; Kube-proxy is a network proxy (see Proxy server) from pods to the outside; Kube-proxy can schedule how requests are mapped to specific pods (e.g.round-robin scheduling). At the cluster level, Kubernetes also has servers to diagnose and plan the larger picture. Component servers are:

  • API Server (the part that is visible to the outside world)
  • Controller/manager - to ensure that pods are adequately replicated (much like the way Hadoop ensure that chunks are replicated in HDFS), and that pods are up and running
  • Scheduler - as described above for Kubelet, but on a cluster-wide basis
  • etcd - a (key,value) store which is distributed/replicated, based on a consensus mechanism for consistency (see Raft (computer science)). The software for etcd is used more widely than just in Kubernetes, notably in Container Linux by CoreOS.

Kubernetes (last edited 2017-04-27 15:31:18 by Ted Herman)