In the last article, we focus on the components in the work nodes. In this one, we'll switch our focus to the
userand the component in
From user's perspective, the model is quite simple:
Statehe wants the system to be in, and then it is k8s's job to achieve that.
Resouces and Operationto the k8s using the
REST API, which is served by the
API serverinside of the master node, the request will be put into a
etcd). According to the type of resource, different
Controllerswill be delegated to do the job.
Operationsavailable depend on the
Resourcetype, but most the case, it means
CRUD. For create operation, there is a
Specificationdefine the attribute of the resource wanted to be created.
Here are two examples:
- create a
Pod, according to a
- create a
Deploymentcalled mypetstore, according to ta
- update the mypetstore deployment with a new container image.
Resource(also called Object) has three pieces of information: Spec, Status and Metadata, and those are saved in the
Specis specified by the user for resource creation and update; it is desired state of the resource.
Statusis updated by the k8s system and queried by the user; it is the actual state of the resource.
Metadatais partly specified by the user and can be updated by the k8s system; it is the label of the resource.
The class diagram looks like this:
Let's see how what really happens when you typing
kubectl create -f deployment/spec.yaml:
k8s cluster is managed and accessed from predefined API.
kubectlis a client of the API, it converts the shell command to the REST call, as shown in above sequence diagram.
You can build your own tools using those APIs to add functionality that are currently not available. Since API is versioned and stable, it makes sure your tool are portable.
Portability and extensibility are the most important benefits k8s brings. In another word, k8s is awesome not only because it does awesome things itself but enables you and others build awesome things on top of it.
Controlleris to make sure the actual state of the
objectmatches the desired state.
The idea of matching the actual state to the desired state is the driving philosophy of k8s's design. It doesn't sound quite novel given most declarative tools follow the same idea. For example, both Terraform and Ansible are declarative. The things k8s is different is it keep monitoring the system status and make sure the desired status is always kept. And that means all the goodness of availability and scalability are built-in in k8s.
The desired state is defined using a Spec, and that is the stuff user will interact with. It is k8s's job to do whatever you requested.
The most common specs are:
Deploymentsfor stateless persistent apps (e.g. http servers)
StatefulSetsfor stateful persistent apps (e.g. databases)
Jobsfor run-to-completion apps (e.g. batch jobs).
Let's take a close look at the Deployments Spec.
Below is the deployment spec that can be used to create a deployment of nginx server with
3replicas, each of which use nginx:1.7.9 as the container image and application will listen on 80 port.
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
This should be simple to understand. Compared with a simple Pod/Container specification,it has an extra
kindis set as
Deploymentso that a right Controller will be able to pick it up.
Lots of specs will have a nested
PodSpec, as shown below, since at the end of the day, k8s is a Pod/Container management system.
For a complete reference of the field available for deployment spec, you can check here.
In this article, we looked at the components of Master node and the overall operation Model of k8s: drive and maintainer the actual state of the system to be same as the desired state as specified by the user through various object specification. In particular, we took a close look at most used deployment spec.