There are many Building Blocks in Kubernetes, such as Object Model, POD, RS, Deployment, namespace and so on, which are very important in Kubernetes.
Kubernetes Object Model
Kubernetes has a very comprehensive object model through which kubernetes clusters can represent different persistent wholes, such as:
- Which node are we running which containerized application on?
- Application resource consumption
- Apply different policies
For each object, we declare the desired state with the spec field, and Kubernetes records and manages the actual state of the object through the Status field. Then kubernetes’ Controller Manager will find a way to make the actual state of the object the same as our declared expected state.
Examples of kubernetes are Pods, Deployments, ReplicaSets, etc.
If we want to create an object, we need to supply the spec field to the API Server, which describes the expected state along with some basic information, such as the name. The API request to create the object must have the spec field and other details, and must be in JSON format. Typically, we provide a declaration of an object in yamL format, which Kubectl converts to JSON format and passes to the API Server.
Here is an example of a Deployment object:
apiVersion: apps/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: Labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: -containerport: 80Copy the codeA commercial breaks in:
Apps
The core workloads API, which is composed of the DaemonSet, Deployment, ReplicaSet, and StatefulSet kinds, has been promoted to GA stability in the apps/v1 group version. As such, the apps/v1beta2 group version is deprecated, and all new code should use the kinds in the apps/v1 group version.
Next, the apiVersion specifies the endpoint of the API we are calling; With the Kind field, we specify the type of object we want to create; With metadata, we attach basic information to objects, such as names; You can see that there are two fields of spec (spec and spec.template.spec). By spec, we define our expected state for deployment. In our case, we want to make sure that, at all times, Each has at least three pods running. In spec.template.spec, we define the state of each pod we want to run, so that’s why there are two specs.
Once the object is created, Kubernetes directly adds a status field to the object as follows:
70B197CF-63EA-401C-B029-AFC9F9271D91
Pods
Pod is the simplest and smallest object in Kubernetes. It is a unit of Kubernetes deployment and represents a single instance of the application. A Pod is a logical collection of one or more containers that have the following characteristics:
- Scheduling together on the same host
- Share the same Network namespace
- Mount the same External storage (Volumes)
38D8B067-9AD2-4CE0-85C5-70C3D5538FB0
Pods are not a persistent thing, they may suddenly collapse and have no ability to repair themselves, that’s why we use them together with controllers, so that we can control Pod replicas, fault tolerance, self-repair, etc. Well-known examples include Deployments, ReplicaSets, etc. We do this by attaching the Pod definition (Specification) to another object (template.spec).
Labels
Labels are key-value pairs that can be attached to a Kubernetes object, such as Pod. Labels are used to organize and select objects that meet the criteria. Label does not provide uniqueness.
5594660A-4922-497F-9BB6-69CDE96238B3
From this image, we can see that we are using two labels: app and env. We can give our POD different values based on our requirements.
Label Selectors
With Label Selectors, we can select a range of objects. Kubernetes supports two Selector types:
Equality-Based Selectors
As the name implies, this selector passes either == or! For example, if we select an object with env==dev, we will find all objects with env label and dev.
Set-Based Selectors
This selector supports filtering through a series of values, such as in, notin, and exist.
Example: env in (dev, qa)
9DCAECB6-54CF-4789-94B8-4332BABE4B53
Replication Controllers
A ReplicationController (RC) is part of the Controller Manager on a master node. It is used to ensure that the replicas of each pod reach the expected value. Otherwise, kill or create a pod. It has since been replaced by ReplicaSet (RS).
Replica Sets
Replica Set is the next generation Replication Controller, which has the advantage of supporting both equality and Set based selector (RC only supports equality-based selector). That’s the only difference right now.
Rs can be used alone, but usually in conjunction with Deployment. Deployment automatically creates RS to manage the following pods.
Deployment
Deployment provides declarative updates to POD and RS. DeploymentController is part of Controller Manager on Master Nodes and acts like Controller Manager elsewhere — ensuring that the current state is the same as expected.
In the following example, our Deployment creates one RS A, then rs A creates three pods, and in each pod, there is A container running nginx:1.7.9 images.
1A74F83F-00D9-4954-9737-D6C1BBAE3EF3
Next, in the next deployment, we changed the POD template to upgrade nginx from 1.7.9 to 1.9.1. Since we upgraded the expected state, deployment creates a new RS B, a process called Deployment rollout:
D9667D97-B328-4C19-AA9F-FD9E7CDEDD65
When RS B is created, Deployment starts pointing to it:
652F4886-8F15-4C27-9DDF-8C1DA7D1DF11
On top of rs, deployment provides many features such as recording, through which we can rollback to the original state if an update is wrong or a bug occurs in the updated application.
Namespaces
If we have an infinite number of users and we want to group them into different teams or projects, we can use namespace to divide the Kubernetes cluster into several smaller clusters. All resources/ Objects created in a namespace are unique and do not cross namespaces.
In general, K8S has two default namespaces: kube-system and default. Kube-system is used to store components of the Kubernetes system. Default is used to store objects belonging to other namespaces. We connect to the default namespace by default. Kube-public is a special namespace that can be read by all users. It is used in special cases such as initializing a cluster.
We can Quotas resources per namespace by using Resource Quotas.
One last commercial:
C8E9D1AC-E8F8-4544-8DB0-F4EAA6905F56
