Why Containers:

• enables business to develop and rollout new offerings faster (velocity)

• predictable execution in any linux environment (portable)

• sealed images makes production deployments faster and easier (Reliable)

• Max resource utilisation (efficiency)

• Avoid dependency conflicts (Insolation)

Containers ≠ VM’s

• VM creation is not guaranteed to be scripted/reproducible but container build(Dockerfile) process enforces reproducibility

• An image is a result of running a build process from Dockerfile

• Container is a running instance of container

• We can run multiple container from an image

• Container filesystems is ephemeral , they don’t have state

• Starting and stopping containers

    #starting and stoping containers
    docker run
    docker stop
    docker rm # -f to stop and remove container
  
    #Managing images
    docker images
    docker rmi
    docker build
    docker tag
    docker pull/push
  
    #docker troubleshooting commands
    docker ps #-a to include non running containers
    docker logs
    docker exec
  

• Container Registry

  • Central location to store container images

  • Types:

    • Hosted: Docker Registry, ECR, GCR

    • Self-hosted: Artifactory, Harbor, Quay

    • Images are built on a built host and pushed to a registry

Kubernetes

• Open source cluster management

• Managed by CNCF (Cloud Native Computing foundation) created by google

Cloud native principles

• Container Packaged

• Dynamically managed

• MicroService oriented

Imperative V/S Declarative

Imperative→ Defines actions

Declarative → Defines desire state

Kubernetes is all on declarative state

Kubernetes Concepts

• Pods

• Service

• Deployments

Pods (lowest unit)

• Containers are the part of pods

• a pod may be one or more containers

• pod existence(purpose) is usually because of one particular container

• Assumptions

  • all containers for a pod will run on same node

  • containers with in pod can talk to each other over localhost

  • containers shares volume resources

• Main container(MYSQL Container) is the reason for the pod existence

• So if there any little typo mistake happen’s then we required to rebuild the entire container, to resolve that issue what we have is Sidecar containers

• Sidecar containers helps in

  • Logic could be included in main containers

  • There is separation of concerns, for example above image have 2 containers where Git Sync container is the sidecar. Now Web server is no longer responsible for holding the content instead it just servers it and another container is responsible for keeping the content updated.

REST - API (Kubectl)

• We talk to Kubernetes using API calls

• provides the abstraction layer on top of resource storage (etcd)

• Command line interface for api called kubectl

• calls one or more REST API call for each command line invocation

• it does contains some business logic that not present in api

YAML (Yet Another Markup Language)

• Command line are mostly for read operations

• For write/creating/updating we use yaml (declarative way)

API Resource Object & YAML

###### HEADER ######
apiVersion: v1
kind: Pod #object type
metadata:
    name: mypod1 #unique key for pod
    labels:
        app: blog #key value pair
###### Below are specific to the kind that we are working with ######
spec:
    containers:
        - name: nginx
          image: nginx:1.13.1

Creating resource

• Declarative Approach (Prferred)

  • kubectl apply -f [<file> | <directory> | <url> ] → create/update resource

• Imperative Approach

  • kubectl create

  • kubectl replace

  • kubectl edit

  • kubectl patch

Service

• We don’t get IP address or any thing when pods are created

• Load balancing for pods

• We send the traffic to service then the service will round robin the traffic across the pods

• It uses label to determine the target pods

apiVersion: v1
kind: Service
metadata:
    name: my-blog
    label:
        app: blog

spec:
    selector:
        app: blog #act like query like it runs a query to find what pods are in the system have labels in them like mentioned
    port:
        - protocol: TCP
          port: 80
          targetPort: 80

Pod Creation and Deployment

• What if i have a website that need 20 nginx server ?

  • 20 pod object sent to kubernetes

  • each object is exactly same except the name

• We have higher level construct called Deployment

• Deployment

  • Single object that will create other resources

  • pod spec is nested

  • leverages selectors

apiVersion: app/v1
kind: Deployement
metadata:
    name: my-blog
spec:
    replica: 3 #how may pod need to running
    selector:
        matchLabels:
            app: blog
    template: #template of a pod 
        metadata:
            labels:
                app: blog
        spec:
            containers:
                - name: nginx
                  image: nginx:1.7.1
                  ports:
                    - containerPort: 80

Labels

• Characteristics:

  • map of key/value pairs

  • both organisational and functional

  • indexed and searchable

• Tips:

  • avoid compound label values:

    • app: blog-frontend v/s app: blog / tire: frontend

    • because it will difficult in filtering or adding regex

  • Try to standardise on key/value across the cluster