Gaurav Singh

Kubernetes and Application Development

Blog Post created by Gaurav Singh on Jul 30, 2017

HI

My name is Gaurav Singh. I am Senior Product Manager for UCP<Gaurav.singh@hds.com>. In this Blog post, I want to talk about various features of kubernetes that makes kubernetes favorable platform for application deployment and development.

 

Kubernetes website, “Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.” Kubernetes was built by Google based on their experience running containers in production using an internal cluster management system called Borg(sometimes referred to as Omega). The example of architecture for Kubernetes on UCP (Redhat Openshift) is shown below:

 

kub.png

 

Application Definition

Applications can be deployed using a combination of pods, deployments, and services. A pod is a group of co-located containers and is the atomic unit of a deployment. A deployment can have replicas across multiple nodes. A service is the “external face” of container workloads and integrates with DNS to round-robin incoming requests.

 

Application Scalability Constructs

Each application tier is defined as a pod and can be scaled when managed by a deployment, which is specified declaratively, e.g., in YAML. The scaling can be manual or automated. Pods are most useful for running co-located and co-administered helper applications, like log and checkpoint backup agents, proxies and adapters, though they can also be used to run vertically integrated application stacks such as LAMP (Apache, MySQL, PHP) or ELK/Elastic (Elasticsearch, Logstash, Kibana).

 

High Availability

Deployments allow pods to be distributed among nodes to provide HA, thereby tolerating infrastructure or application failures. Load-balanced services detect unhealthy pods and remove them. High availability of Kubernetes is supported. Multiple master nodes and worker nodes can be load balanced for requests from kubectl and clients. etcd can be clustered and API Servers can be replicated.

 

Load Balancing

Pods are exposed through a service, which can be used as a load-balancer within the cluster. Typically, an ingress resource is used for load balancing.

 

Auto-scaling for the Application

Auto-scaling using a simple number-of-pods target is defined declaratively using deployments. Auto-scaling using resource metrics is also supported. Resource metrics range from CPU and memory utilization to requests or packets-per-second, and even custom metrics.

 

Rolling Application Upgrades and Rollback

A deployment supports both “rolling-update” and “recreate” strategies. Rolling updates can specify maximum number of pods.

 

Health Checks

Health checks are of two kinds: liveness (is app responsive) and readiness (is app responsive, but busy preparing and not yet able to serve).

 

Storage

Two storage APIs:
The first
provides abstractions for individual storage backends . The second provides an abstraction for a storage resource request , which can be fulfilled with different storage backends.
Hitachi Storage Plug-in for containers releasing on October 2017 will provide persistent volume with block support.

 

 

Networking

The networking model is a flat network, enabling all pods to communicate with one another. Network policies specify how pods communicate with each other. The flat network is typically implemented as an overlay. The model requires two CIDRs: one from which pods get an IP address, the other for services.

 

Service Discovery

Services can be found using environment variables or DNS. Kubelet adds a set of environment variables when a pod is run. Kubelet supports simple {SVCNAME_SERVICE_HOST} and {SVCNAME_SERVICE_PORT} variables, as well as Docker links compatible variables. DNS Server is available as an addon. For each Kubernetes service, the DNS Server creates a set of DNS records. With DNS enabled in the entire cluster, pods will be able to use service names that automatically resolve.

 

Performance and Scalability

With the release of 1.6, Kubernetes scales to 5,000-node clusters. Multiple clusters can be used to scale beyond this limit.

 

This post has been inspired by content on Kubernetes.io and platform9.com

Outcomes