1. Relations btw Docker and K8S

Docker is a cross-age virtualization technology. It defined a new level of virtualization above virtual machine, which is faster and easier.

Docker describe its faked enviroment as a container. When business gets bigger and bigger, we will need a tool to manage a larger number of containers, handle its creation and destruction(the container’s life cycle may be dependent on each other), rolling update and other activities. So K8S filled the blank.

K8S is as well known as an open-source system for automating deployment, scaling, and management of containerized applications. As described, K8S is able to create docker containers and help to manage them in an easier way.

2. How does K8S work?

Everything in K8S is decribed as an K8S resource, described by an yaml file. It always follow the same pattern:

• The apiVersion, which indicates the Kubernetes API that parses this object
• The kind indicating what sort of object this is
• Some metadata applying things like names to your objects
• The spec specifying all the parameters and configurations of your object, means what we expect the kubernetes resource to be.

For example, the following describe an Pod resource with the name Tomcat.

// my-tomcat.yaml

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
	 namespace: default
spec:
   containers:
   - name: Tomcat
     image: tomcat: 8.0
     ports:
       containerPort: 7500
     imagePullPolicy: Always

Deploy a kubernetes resource is quite easy. When a kubernetes cluster is launched, some built-in components will also be launched and held. One of them is kube-api-server, which exposes some RESTful apis to create/update/delete kubernetes resource.

You can either call the api or use other encapsulated tools such as kubectl to talk to an K8S cluster(indeed kubectl will call api as well).

kubectl apply -f ./my-tomcat.yaml

3. What happend after creating an resource

Creating an K8S resource doesn’t mean to actually create a physically exsiting object, instead it insert a record in etcd(another built-in k8s component, a cluster-level key-value database).

Data in etcd are listened and handled other long-run kubernetes component, including controller manager, which handle real creation/destruction and other activities of built-in resources.

The controller manager read the my-tomcat.yaml schema content, and locate the resource(namespace/name), and it will take actions conditionally:

• if the record exists, the resource doesn’t exist
  • create the resource
• if the record exists, the resource exsits
  • compare resource state with record spec
  • take actions to move the resource toward its expected state
• if the record doesn’t exist, the resource exists
  • remove the resource