Develop Intelligence - Kubernetes
Develop Intelligence - Kubernetes
Introduction to Kubernetes
• Why Orchestration
• What is Kubernetes
• Why Kubernetes
• Important features of Kubernetes
• Kubernetes Architecture
• Overview of Kubernetes Objects
Introduction to Kubernetes
Why Orchestration
Containerization has brought a lot of flexibility for developers in terms of managing the deployment of the
applications. However, the more granular the application is, the more components it consists of and hence
requires some sort of management for those.
One still needs to take care of scheduling the deployment of a certain number of containers to a specific node,
managing networking between the containers, following the resource allocation, moving them around as they
grow and much more.
Nearly all applications nowadays need to have answers for things like
• Replication of components
• Auto-scaling
• Load balancing
• Rolling updates
• Logging across components
• Monitoring and health checking
• Service discovery
• Authentication
The process of organizing multiple containers and managing them as needed is known as container
orchestration.
Swarm, ECS, Kubernetes, Mosospehere
What is Kubernetes?
Kubernetes, is a container orchestration technology used to orchestrate the deployment and management of
hundreds and thousands of containers in clustered environment. It could be thought of as the operating system for
cloud-native applications, it is the platform that applications run on, just as desktop applications run on MacOS,
Windows, or Linux.
Develop Intelligence – Kubernetes Introduction
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 Kub ernetes.
• The name Kubernetes originates from Greek, meaning helmsman (who steers ship or boat) or pilot, and is
the root of governor and cybernetic (theory or study of communication and control). K8s is an abbreviation
derived by replacing the 8 letters “ubernete” with “8”.
• It is a platform designed to completely manage the life cycle of containerized applications and services
using methods that provide predictability, scalability, and high availability.
• It orchestrates computing, networking, and storage infrastructure on behalf of user workloads.
• It is easier to deploy, scale, and manage applications.
History
• 2003 – Started at Google as The Borg System to manage Google Search. They needed a sane way to manage
their large-scale container clusters! But it was still very primitive compared to what we have today. It
becomes big and rather messy, with many different languages and concepts due to it’s organic growth.
• 2013 –Docker hits the scene and really revolutionizes computing by providing build tools, image
distribution, and runtimes. This makes containers user friendly and adoption of containers explodes.
• 2014 – 3 Google engineers decide to build a next generation orchestrator that takes many lessons learned
into account, built for public clouds, and open sourced. They build Kubernetes. Microsoft, Red Hat, IBM,
and Docker join in.
• 2015 – Cloud Native Computing Foundation is created by Google and the Linux Foundation. More
companies join in. Kubernetes 1.0 is released, followed by more major upgrades that year. KubeCon is
launched.
• 2016 – K8S goes mainstream. Many supporting products are introduced including Minikube, kops, Helm.
Rapid releases of big features. More companies join in and the community of passionate people explodes.
• 2017 to now – Kubernetes becomes the dominant orchestration system and de-facto standard for Docker
microservices. K8S now has fully managed services by all major cloud providers. Handsome and tal ented
instructors travel the country preaching K8S.
Kubernetes is:
• a container platform.
• a microservices platform.
• a portable cloud platform.
Why Kubernetes?
• Kubernetes is Open Source.
• Great momentum in terms of activities & contribution at its Open Source Project.
Develop Intelligence – Kubernetes Introduction
• Decades of experience running at Google.
• Support of multiple OS and infrastructure software vendors.
• Rate at which features are being released.
• Modern tooling, have CLI and management REST API support.
• Production readiness (Many Online Games including Pokemon Go scale due to Kubernetes)
• Number of features available.
Kubernetes Architecture
A cluster is a group of nodes. They can be physical servers or virtual machines that have the Kubernetes platform
installed.
Components in Kubernetes are divided into
1. Master Components
2. Worker / Node Components
Develop Intelligence – Kubernetes Introduction
Kubernetes Master:
A single master host will manage the cluster and run several core Kubernetes services.
They are responsible for providing global decisions about the cluster like scheduling and detecting and responding
to cluster events eg: starting up a new pod when a replication controllers replica field is unsatisfied.
Note that the loss of the master node does not mean that your cluster is down! No management will happen
until the master is back up, but it is not a gateway for traffic to your services.
1. Kubelet: This is the main contact point for each node and is responsible for communication with the master
component to receive commands and work. The Kubelet takes a set of PodSpecs (YAML or JSON object that
Develop Intelligence – Kubernetes Introduction
describes the Pod) that are provided through ApiServer and ensures that the containers described in those
PodSpecs are running and healthy.
2. Container Runtime: The container runtime on each node is the component that runs the containers defined in
the workloads submitted to the cluster. This can be docker or anything equivalent to it.
3. Kubernetes Proxy Service: This is a proxy service which runs on each node and helps in making services
available to the end users/clients. It a pod that maintains network connections/routing. It is capable of
performing primitive load balancing. The kube-proxy handles network communications inside or outside the
cluster.
4. cAdvisor: Container advisor is a resource monitoring agent and provides information on resource usage and
performance characteristics of the running containers. It collects, aggregates, processes, and exports
information about running containers.
Kubernetes Objects
• Kubernetes Pods
• Replication Controllers and Replication sets
• Deployments
• Services
• Stateful Sets
• Daemon Sets
• Jobs and Cron Jobs
• Volumes and Persistent Volumes
• ConfigMaps and Secrets
Kubectl (Utility):
Is the CLI: command line interface for running commands against the Kubernetes cluster
Kubectl <operation> <object> <resource name> <optional flags>
Kubernetes Pods
• A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object
model that you create or deploy. A Pod represents a running process on your cluster.
• Each Pod has one or more application containers (such as Docker) and includes shared storage (volumes), IP
address and information about how to run them.
• Multi container Pods: The sidecar pattern is an example of multiple containers in a single pod.
o With a sidecar, you run a second container in a pod whose job is to take action and support the
primary container.
Develop Intelligence – Kubernetes Introduction
o Querying a pod returns a data structure that contains information about containers and its
metadata.
o Logging is a good example, where a sidecar container sends logs from the primary container to a
centralized logging system.
• Each Pod is meant to run a single instance of a given application. If you want to scale your applicati on
horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. Replicated
Pods are usually created and managed as a group by an abstraction called a Replication Controller.
• Pods aren’t intended to be treated as durable entities. They won’t survive scheduling failures, node failures,
or other evictions, such as due to lack of resources, or in the case of node maintenance.
• Characteristics of a Pod
o All the containers for a Pod will be run on a same Node.
o Any container running within a Pod will share the Node's network with any other container in the same
Pod.
o When a Pod is scale out, all the containers within it are scaled as a group.
o All containers in the Pod can access the shared volumes, allowing those containers to share data.
o A Pod has an explicit lifecycle and will always remain in a node in which it was started.
o Pods don’t have a managed lifecycle, if they die, they will not be recreated.
Pod Networking
• Each Pod is assigned a unique IP address.
• Containers inside a Pod can communicate with one another using localhost.
• All the nodes in a Kubernetes cluster are expected to be connected to each other and share a private
cluster-wide network.
Replication Controller
• Kubernetes encourages Desired State deployment.
• Controllers are responsible for managing the pod lifecycle. It is responsible for making sure that the specified
number of pod replicas are running at any point of time. They take care of Node failure.
• It is a best practice to use the replication controller to manage the pod life cycle rather than creating a pod
again and again.
Replica Set
• It is associated with a Pod and indicates how many instances of that Pod should be running within the cluster.
• It can be considered as a replacement of a replication controller. The key difference between the replica set
and the replication controller is, the replication controller only supports name equality-based selector
Develop Intelligence – Kubernetes Introduction
whereas the replica set supports set-based selector, a type of selection that enables a set of pods to be
grouped so that the entire set is available for an operation defined in the ReplicaSet controller.
• The recommendation is to use replica sets along with higher-level controllers such as deployment.
Limitation of Replica Set is you can't change the Pod template - we cannot change the container image.
Deployments
• The deployment controller wraps around and extends the ReplicaSet controller.
• The Deployment instructs Kubernetes on how to create and update instances of your application. Once
you've created a Deployment, the Kubernetes master schedules mentioned application instances onto
individual Nodes in the cluster.
• Once the application instances are created, a Kubernetes Deployment Controller continuously monitors
those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller
replaces it. This provides a self-healing mechanism to address machine failure or maintenance.
• Deployments are upgraded and higher version of replication controller. They manage the deployment of
replica sets which is also an upgraded version of the replication controller. They have the capability to
update the replica set and are also capable of rolling back to the previous version.
• It is possible to create an individual pod without using a deployment controller, but the pod will lack the
mechanism needed to recreate itself without any manual intervention. That makes the process
unsustainable.
Service
• Services enable communication between various components within and outside of the application.
• Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service.
Services allow your applications to receive traffic.
• It provides an abstraction through to your Pods agnostics of the specific instances that are running.
• Discovery and routing among dependent Pods (such as the frontend and backend components in an
application) is handled by Services. Basically, service enables loose coupling between Microservice in our
application.
Ingresses
An ingress is a layer 7 HTTP load balancer. Ingresses are Kubernetes resources that expose one or more services to
the outside world. An ingress provides externally visible URLs to services and load-balance traffic with SSL
termination. This resource is useful in scenarios where rolling out such services is not possible or is expensive.
Ingresses can also be used to define network routes between namespaces and pods in conjunction with network
policies. They are managed using ingress controllers, which can limit requests, redirect URLs, and control access.
Develop Intelligence – Kubernetes Introduction
Stateful sets
• StatefulSets were designed to solve the problems associated with data loss when pods crash.
• The StatefulSets object also has a unique and stable hostname that can be queried through DNS. Pods get a
consistent naming scheme that is ordered. For example, pod-0, pod-1, pod-2, etc.
• Works like a deployment, but provides guarantees about the order and uniqueness of pods .
• Stateful sets can be configured to mount a persistent storage volume. So even if a pod crashes, data is
preserved on persistent data storage.
• Useful when you have a group of servers that work together and need to know each others’ names ahead of
time. For example, ElasticSearch cluster.
Daemon sets
• A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods
are added to them.
• As nodes are removed from the cluster, those Pods are garbage collected.
• Deleting a DaemonSet will clean up the Pods it created.
• Useful for system level resources such as monitoring, logging, etc.
• This is how the master pods on the worker nodes run, such as the kube-proxy and kubelet.
Jobs
Jobs are a Kubernetes resources that create one or more pods and ensure that they run until they succeed. Jobs
are ideal for tasks that run and achieve a goal, and then stop.
As pods successfully complete, the Job tracks the successful completions. When a specified number of successful
completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created.
Cron Jobs
One CronJob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule,
written in Cron format.