Container Orchestration

Pinnam Kalyan
Sai Ram
Shobhit Khandelwal
Subhadip Sinha
Introduction
• An abstraction that simplifies tasks of building, deploying and maintaining
scalable distributed systems in the cloud

2
Key Features / Capabilities
• Provisioning and deployment
• Configuration and scheduling
• Scaling
• Networking
• Load balancing
• Self healing
• Container availability 
• Storage requirements

3
Benefits
• Container lifecycle management
• Operationalized efficiency across the organization
• Higher levels of utilization
• Improved governance and security controls

4
Cattle

5
Cattle Orchestration
•Cattle was the first orchestration framework available when Rancher started its
beta.
•Cattle should feel very familiar to anyone familiar with Docker.
•It is based on Docker commands and leverages docker-compose to define
application blueprints.
•Application deployments are organized into stacks.
•Each stack is a made up of services, which are primarily a docker image, along
with scaling information, health checks, service discovery links, and a host of
other configurables.

6
Setting Up
•Environment
•Registry
•Adding a host
•Adding a stack
•Adding a service

7
Services
•Load balancers
•Health checks
•Creating private catalogs

8
Amazon ECS

9
Container Orchestration using AWS
• Manage containers in AWS ECS (Elastic container service)

10
Container Orchestration using AWS
• AWS ECS ARCHITECHTURE

11
Container Orchestration using AWS
• AWS ECS : How it works?

12
Container
•
Orchestration
Demo: ECS using Fargate
using AWS
• Demo: ECS using EC2

13
Container
•
Orchestration
Difference between ECS vs EC2
using AWS

14
Kubernetes

15
Kubernetes High level overview

16
Components
• K8s dashboard
• K8s Cli
• Kubelet
• Kube-proxy
• Master

17
Kube-let
• Containers are not only isolated from each other and they are also isolated
from the underlying host system
• The final arbiter of what pods can and cannot run on a given node, not the
schedulers or DaemonSets
• Without this Kubernetes is just REST API backed by key-value store 

18
Kube-Proxy
• Every node implements Kube-proxy which provides the virtual IP address for
the clients to access the dynamic set of pods. 
• Abstraction layer for the group of pods in the node under a common access
policy, for example, load balancer.
• This provides a highly available load balancing solution with low-performance
overhead

19
Master
• API Server
• All the components in the cluster communicate through this. It exposes the kubernetes API
• Scheduler
• The scheduler is responsible for assigning applications or kubernetes objects to the worker node.
It is responsible for placing the pods on the nodes based on the resource requirements
• Controller-manager
• Maintains the cluster such as node failures, maintaining the correct amount of pods
• Etcd
• Key value store that stores the cluster configuration. If you want to back up the cluster, all you
need to save is this key value distributed store

20
Sample Pod yaml file
apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name # POD_NAME
  labels:
    application: backend # LABEL_KEY: LABEL_VALUE
spec:
  containers: # list of containers running in one Pod
    - name: main-container # CONTAINER_NAME
      image: my-backend # IMAGE_NAME
      tag: v1 # IMAGE_TAG
      ports:
      - containerPort: 8080 # CONTAINER_PORT_NUMBER - port to expose on the Pod's IP address
      env: # ENV – environment variable
      - name: NODE_ENV # ENV_NAME
        value: prod # ENV_VALUE
      imagePullPolicy: IfNotPresent # options: Always, Never, IfNotPresent;  21
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-deployment-name # DEPLOYMENT_NAME
  labels:
    # we pass selector, to easy list specific Deployments:
    # kubectl get deployment --selector=KEY_DEPLOYMENT_SELECTOR
    application: backend # KEY_DEPLOYMENT_SELECTOR: VALUE_DEPLOYMENT_SELECTOR
    resource: deployment
spec:
  replicas: 3 # NUMBER_OF_REPLICAS (number of Pods)
  selector:
    matchLabels:
      # thanks to this selector, we specify, which Pods belong to this Deployment
      application: backend # KEY_POD_SELECTOR: VALUE_POD_SELECTOR 
  template: # here the Pod specification starts (look at the example-pod.yaml) 
    metadata:
      labels:
        # all Pods will get this label
        # so Deployment will easily find all his Pods
        application: backend # KEY_POD_SELECTOR: VALUE_POD_SELECTOR 
    spec:
      containers:
      - name: main-container # CONTAINER_NAME
        image: my-backend # IMAGE_NAME
        tag: v1 # TAG
        ports:
        - containerPort: 8080 # CONTAINER_PORT_NUMBER

22
K8s VS Docker Swarm
K8s Docker Swarm

·
Applications can be deployed as services (or micro-
Application · Application can be deployed using a combination of pods, services) in a Swarm cluster
deployments, and services YAML files can be used to specify a multi-container. Docker
Compose YAML can deploy the app

Installation · Complicated · Easy with YAML files

Logging and · Elasticsearch/Kibana (ELK) logs of the container, · Supported for only monitoring with the third-party
monitoring Heapster/Grafana/ Influx for monitoring the container applications
Sysdig cloud integration Docker Swarm has an open API, makes it easier to connect
with plenty of apps

· All in one framework for distributed systems

Scalability
A complex system as it offers a unified set of APIs guarantees · Docker Swarm can deploy containers faster
Fast reaction times to scale on demand
the cluster state

· All pods are distributed among nodes and this provides
High availability high availability by tolerating application failure
Load-balancing services detect unhealthy pods and remove
them
· Provides high availability as services can be replicated in
Swarm nodes
Swarm manager nodes are responsible for the whole cluster
and manage the resources of worker nodes
23
Q&A

Thank You !