Real-World Docker Series: Introduction to Kubernetes and Container Orchestration

What is Kubernetes?

• Offers container orchestration
• Clustered Service/Platform
• Platform for running containers (micro-services)
• Offers application horizontal scaling
• Automation

Some products that run on Kubernetes include:

1. Openshift Enterprise
2. Atomic Enterprise Platform

Kubernetes Cluster Components:

Kubernetes is comprised of several components that make up the overall service.  We'll run through them so that you can understand what each service provides to the clustered infrastructure.

1. Flannel (flanneld)
• Overlay network
• Provides private isolated backend container network
• Runs on each kubernetes node and anywhere that you run the kube-proxy service
2. etcd
• Distributed key-value store
• Manages flannels network configuration across container hosts/kubernetes cluster nodes and other information about the cluster
• Typically runs on kubernetes master
3. kube-apiserver
• Manages all data for kubernetes api objects (pods, services, replication controllers, authentication, etc)
• Provides REST operations and interactions between all other kubernetes components
• Runs on kubernetes master
4. kube-controller-manager
• Handles replication processes and interacts with etcd to ensure desired state
• Involved in scaling of applications
• Runs on kubernetes master
5. kube-scheduler
• Distributes workloads to cluster nodes
• Runs on kubernetes master
6. kube-proxy
• Makes applications/services available outside of cluster
• Provides service network where container workloads are accessible from
• Forwards external requests to appropriate containers in the backend
• Acts similarly to a  software/virtual switch
• Typically runs on kubernetes master or a dedicated “jump” proxy server
• Routes from a switch to a node running kube-proxy are required to access the service network.  The kube-proxy acts as a gateway in this instance.
• Runs on all kubernetes nodes to ensure communication between service network and backend network
7. docker
• Container engine
• Runs on each kubernetes node
8. kubelet
• Communicates with the master server
• Receives workload manifests from the master and maintains state of the node's workloads
• Runs on each kubernetes node

Kubernetes Application Components:

When deploying an application on top of kubernetes, there are several bits and pieces to put together like building blocks.  Your containers should be made up of a single service/micro-service that provides a piece of functionality to the overall application.  Historically, an application would be deployed onto a server where many services were running simultaneously.  In kubernetes, you should build your applications in a modular fashion where each process/service is a container.  

For example, a web server would run maybe httpd, a small database service (mysql/mariadb/percona/postgresql), and maybe some other small scripts to run backups and do daily tasks (cron.)  In the container world, we would be running three containers to accomplish the above example.  We'd have a httpd container, a database container, and a cron container.  The httpd and cron containers would probably be attached to the same storage to be able to manipulate data from the httpd container as required, and the cron container may even have a database client to be able to connect and manipulate the database container's data.

Another thing to consider is how your application can be scaled.  Typically the easiest way to do this is to scale out the application's front-end to be able to handle large loads of traffic.  You can also build a distributed database by taking advantage of replication and scale the database containers horizontally.

The application's containers are one aspect of kubernetes application design, but there's also the actual kubernetes components that put the whole application together and allow it to function.  

Here are the most common components used and a brief explanation of what they do:

1. Pod
• Typically contains a single running container, but can run more than one container to build applications
• Gets assigned a private (non-routable) IP address for communication within the kubernetes cluster
• Wraps around a container
• Cannot be scaled
2. Replication Controller
• Defines a pod spec
• Runs X number of exactly the same pods (i.e. replicas)
• Ensures X number of pods are always running in the cluster based on what you define
• Used in horizontally scaling your applications
• A pod defined by a replication controller will respawn if killed
• Good idea to always use replication controllers, even if you only want a single pod running due to the fact that if that pod dies, it will respawn it.
3. Service
• Exposes a pod or multiple pods from a replication controller to the kubernetes service network effectively exposing the service to the outside world on a single unique IP address and specific port.
• This is how consumers of your application access the application
• Uses a label from within the replication controller's spec (selector) to dynamically keep track of all the pods (endpoints) available to serve
• Effectively acts as a load balancer
4. Volumes/Persistent Storage
• Like we've talked about in the past with our posts on docker, containers need a way to persist data.  Persistent volumes can be of many types, such as, NFS, git repository, kubernetes node local storage, gluster, AWS, etc
• There's three parts to how the volumes get used:
1. Persistent volume is defined
2. A Persistent volume claim is defined which binds to the persistent volume
3. A replication controller/pod defines its mountpoints and volumes by calling the persistent volume claim and tying everything together
• Many pods can attach to the same backing persistent volumes
• If running selinux, you can append the :z and :Z options on your replication controller's/pod's mountpoint specs to work around access issues until some selinux issues are worked out
5. Namespaces
• An area to run kubernetes components
• Good way to decouple departments/projects running work-loads simultaneously on a kubernetes cluster
• Can be used to limit/allocate resources such as CPU, network bandwidth, disk IO, etc
• Helps limit impact on the overall available kubernetes node resources by restricting utilization with careful planning by a cluster administrator
• Can also limit what a cluster user can see and access by making use of role-based access controls

I'll leave you with this pretty topology map from my kubernetes lab.  You can see many of the components we talked about in this post: