A history of how the microservice evolved into what it is today. A further dive into the building blocks of the most dominant technology in this space - kubernetes!
2. Agenda
• Expectation
• Story/Evolution
• Container
• Container Orchestration/Kubernetes
• Building Blocks of Kubernetes
• How to interact with kube?
• Useful Resources
• What’s Next
• QnA
3. Expectation
• No multitasking (Read: No Device)
• You can jump in anytime for a question or wait till the end
• No prior Kubernetes/container knowledge required
• At the end of this session..
• You should be able to understand what kube is
5. Hardware
Operating System
Hardware
Host OS
Hypervisor
APP1
APP2
APP3
Guest
OS
Guest
OS
Guest
OS
bin/lib bin/lib bin/lib
APP1
APP1
APP1
Hardware
Operating System
Docker Engine
Container
1
Container
2
Container
3
bin/lib bin/lib bin/lib
APP1
APP1
APP1
• Monolithic App
• Standalone OS on dedicated HW
• Since the beginning of time, I mean..
• (Personally 2011)
• App runs in virtual machines
• Ties up resources/dedicated
• Still tightly coupled, since VM is essentially a
standalone OS in a shared HW
• Old idea (70s) but evolved into current state
in late 90s
• Docker engine works as an
intermediary for the resources to be
consumed by container
• Docker released in 2013, but didn’t
get any momentum till 2015
• Around the same time we’ve started
taking about decoupling our
monolithic app
6. Container
• Offers a logical packaging mechanism where application can be abstracted away
from the host environment they run in
• Provides isolated environment for each application/service
• Shares the same OS kernel
• Lightweight, incredibly faster to load, compare to a VM or conventional OS on
dedicated HW
• And, significantly resource savvy
• Doesn’t tie up resource as opposed to a VM
• Can run heterogenous OS on top of each other and vice versa
7. Container(ize)
It’s all nice and good, but how do we containerize a monolithic app?
Install docker
Write a Dockerfile
docker build –f Dockerfile –t <image_name> .
docker run <image_name>
8. FROM node:4-onbuild
RUN mkdir /app
COPY . /app/
WORKDIR /app
RUN npm install
EXPOSE 8234
CMD [ "npm", "start" ]
Container(ize)
What is Dockerfile?
“A Dockerfile is a text document that contains all the commands a user could call on the
command line to assemble an image.”
9. Container Orchestration
Lucky if you have one application, few containers, deployed once and forget forever.
But how about this?
[Image Source: https://giphy.com/]
10. Container Orchestration
Orchestration tool manages the lifecycle of a container. This involves:
• Provisioning and deployment
• Redundancy and availability
• Resource allocation and management of the hosts
• Service discovery, exposure
• Loadbalancing, monitoring
• Application config
11. Container Orchestration
• There are few container orchestration tools out there.
• For instance, docker swarm, rancher and Kubernetes
• There have been lots of debates over the years as which platform is the best
• Different people approached it from different perspectives
• Overall, the industry prefers Kubernetes to other tools due to its capability
• There’s a steep learning curve involved, but once you get the hang of it, it’s really fun
13. Blocks: Cluster & Nodes
Kubernetes has the concept of cluster that appears as a single entity.
• It is essentially set of nodes having roles like master and worker
• Nodes can be both virtual and physical machines
• Master manages the scheduling and deployment of container/pod across nodes
• Set of services that master node runs is called control plane
• Master communicates with rest of the nodes through Kube API
• Scheduler deploy pod/container based on the available resource and policy
constraints defined
14. Blocks: kubelet
• kubelet is the agent that runs in every node
• It manages the state of the node
• This includes starting, stopping and maintaining the hosted
containers/pods
• kubelet receives the relevant info from Kube API server
15. Blocks: pod
• pod is the most basic unit/abstraction that
Kubernetes deals with
• Assigned with unique IP within the cluster
• All that’s required it to define the desired
state of a pod using a YAML file
• Once applied, Kubernetes takes care of the
rest
16. Blocks: namespace and service
• namespace is the logical grouping of objects that belong to a particular
app or group of apps
• When you are dealing with hundreds and thousands of objects it makes
sense to categories them under a group
• service is the access point to the application and/or underlying
container/pod
• It enables loose coupling of pods
• It can be ClusterIP, NodePort and LoadBalancer or an external
name.
18. Blocks : deployment & replicaset
• deployment is a YAML object that defines the pod and
• Number of expected replicas that’s also known as ReplicaSet
• ReplicaSet ensures the the number of pods are maintained regardless
• For example, if a node dies, it’ll have the pods deployed in a different host
• Note: we are still using ReplicationController
19. How to interact with kube?
Kubernetes CLI, referred as kubectl
• Well, that sounds fine, but how do we set up kubectl?
• Fortunately, we have a confluence page with the instructions
• Note: ~/.kube/config file
• We define kube API endpoints and relevant secrets/ca data
• When you have all set up correctly then the fun begins