It’s like learning to drive a car. In the beginning, you don’t really want to know what’s under the hood. You first want to learn how to drive it from point A to point B. Only after you learn how to do that do you become interested in how a car makes that possible. After all, knowing what’s under the hood may someday help you get the car moving again after it breaks down and leaves you stranded at the side of the road.
To grasp some context.
- Tightly coupled
- Have to be developed, deployed, and managed as one entity
- Run as single OS processes
- Highly decoupled
- Each component can be developed, deployed, and managed independently
- Each component runs as independent process
With great numbers of components comes great responsibility, Peter...
Before containers went mainstream, we isolate components using Virtual Machine (VM). This way, each components can have their own dependencies satisfied without getting in the way of each other.
The problem with VM is that it takes a lot of hardware resources, therefore not ideal for microservice-based app with large number of services.
How Docker made containers mainstream.
- Runs on own OS
- Runs its own system processes
- Runs on host OS
- Runs as isolated processes in host OS
Docker was the first container system that made containers easily portable across different machines. It simplified the process of packaging up not only the application but also all its libraries and other dependencies, even the whole OS file system, into a simple, portable package that can be used to provision the application to any other machine running Docker.
Run:
docker run busybox echo "Hello World"
Result:
A simple NodeJs app:
const http = require('http');
const os = require('os');
console.log("Kubia server starting...");
var handler = function(request, response) {
console.log("Received request from " + request.connection.remoteAddress);
response.writeHead(200);
response.end("You've hit " + os.hostname() + "\n");
};
var www = http.createServer(handler);
www.listen(8080);
A simple Dockerfile:
FROM node:7
ADD app.js /app.js
ENTRYPOINT ["node", "app.js"]
Build it:
docker build -t kubia .
Check for all the images:
docker images
Run the container image:
docker run --name kubia-container -p 8080:8080 -d kubia
docker ps
Check for all the running containers:
Inspect the container:
docker inspect kubia-container
Get inside the container:
docker exec -it kubia-container bash
ps aux
ps aux | grep app.js
Outside of the container:
Login to Docker Hub (if you haven't already):
docker login
Tag the image and push it:
docker tag kubia qblfrb/kubia
docker push qblfrb/kubia
is Greek for:
- pilot
- helmsman
- governor
Kubernetes is a software system that allows you to easily deploy and manage containerized applications on top of it.
Kubernetes enables you to run your software applications on thousands of computer nodes as if all those nodes were a single, enormous computer.
Kubernetes can be thought of as an operating system for the cluster.
Before we continue, we need to have either a cloud cluster set up or a minikube installed. For this presentation we'll create a cluster in Google Cloud Platform. Here are the steps:
Create the cluster:
gcloud container clusters create kubia --num-nodes 3 --machine-type f1-micro
Verifying everything is ready:
kubectl config get-contexts
kubectl get nodes
kubectl describe node gke-kubia-default-pool-84262666-7rsl
Use `kubectl run` command:
kubectl run kubia --image=qblfrb/kubia --port=8080 --generator=run/v1
See the results:
kubectl get pods
Get the replication controller:
kubectl get replicationcontroller
Expose it:
kubectl expose rc kubia --type=LoadBalancer --name kubia-http
Get the service:
kubectl get services
Test it:
curl 35.185.155.217:8080
A pod is a co-located group of containers and represents the basic building block in Kubernetes. The key thing about pods is that when a pod does contain multiple containers, all of them are always run on a single worker node—it never spans multiple worker nodes.
A ReplicationController is a Kubernetes resource that ensures its pods are always kept running. If the pod disappears for any reason, such as in the event of a node disappearing from the cluster or because the pod was evicted from the node, the ReplicationController notices the missing pod and creates a replacement pod.
A Kubernetes Service is a resource you create to make a single, constant point of entry to a group of pods providing the same service. Each service has an IP address and port that never change while the service exists. Clients can open connections to that IP and port, and those connections are then routed to one of the pods backing that service. This way, clients of a service don’t need to know the location of individual pods providing the service, allowing those pods to be moved around the cluster at any time.