Before learning the practice of k8s-cluster, you must first learn several important concepts of Kubermetes, which are the cornerstones of the Kubermetes cluster.
1. [Cluster]
Cluster is a collection of computing, storage, and network resources. Kubernetes uses these resources to run various container-based applications.
2.【Master】
Master is the brain of Cluster, and its main responsibility is scheduling, that is, deciding where to run the application. The Master runs the Linux operating system, which can be a physical machine or a virtual machine. In order to achieve high availability, multiple Masters can be run.
3.【Node】
Node's responsibility is to run container applications. The Node is managed by the Master, and the Node is responsible for monitoring and reporting the status of the container, and at the same time managing the life cycle of the container according to the requirements of the Master. Node runs on the Linux operating system and can be a physical machine or a virtual machine.
In the k8s interactive tutorial, the Cluster we created has only one host host01, which is both Master and Node, as shown in the figure below.
[K8s official website interactive tutorial] = " https://kubernetes.io/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/
Teminal
Kubernetes Bootcamp Terminal
$
$ minikube start
* minikube v1.8.1 on Ubuntu 18.04
* Using the none driver based on user configuration
* Running on localhost (CPUs=2, Memory=2460MB, Disk=145651MB) ...
* OS release is Ubuntu 18.04.4 LTS
* Preparing Kubernetes v1.17.3 on Docker 19.03.6 ...
- kubelet.resolv-conf=/run/systemd/resolve/resolv.conf
* Launching Kubernetes ...
* Enabling addons: default-storageclass, storage-provisioner
* Configuring local host environment ...
* Waiting for cluster to come online ...
* Done! kubectl is now configured to use "minikube"
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
minikube Ready master 27s v1.17.3
$ hostname
minikube4. 【Pod】
Pod is the smallest unit of work in Kubernetes. Each Pod contains one or more containers. The containers in the Pod will be scheduled to run on a Node by the Master as a whole.
4.1 [Kubemntes introduced Pod mainly for the following two purposes]:
(1) Manageability.
Some containers are born to be closely connected and work together. Pod provides a higher level of abstraction than containers, encapsulating them into a deployment unit. Kubemetes uses Pod as the smallest unit to schedule, expand, share resources, and manage life cycle.
(2) Communication and resource sharing.
All containers in the Pod use the same network namespace, that is, the same IP address and Port space. They can communicate directly with localhost. Similarly, these containers can share storage. When Kubemetes mounts a volume to a Pod, it essentially mounts the volume to each container in the Pod.
4.2 [Pod can be used in two ways]:
(1) Run a single container.
One-container-per-Pod is the most common model of Kubemetes. In this case, a single container is simply encapsulated into a Pod. Even if there is only one container, Kubemetes manages Pods instead of directly managing containers.
(2) Run multiple containers.
The question is: Which containers should be placed in a Pod?
The answer is: these containers must be very closely connected, and they need to share resources directly.
[Example 1]: As shown in the figure below, Pod contains two containers: one is File Puller and the other is Web Server.
- File Puller will periodically pull the latest files from the external Content Manager and store them in the shared volume. The Web Server reads the file from the volume and responds to the request of the Consumer.
- These two containers work closely together, and together they provide the Consumer with the latest data: at the same time they also share data through the volume, so it is appropriate to put them in a Pod.
[Example 2] Counter-example: Do I need to put the Nginx mounted application and PostgreSQL in a Pod?
- Nginx-mounted applications (such as: asp.net core api) read data from PostgreSQL. They need to cooperate, but they don't need to be deployed together, started together, and stopped together in a Pod. At the same time, they exchange data through Npgsql, not directly sharing storage, so it is more appropriate to put them in their respective Pods.
5.【Controller】
Kubernetes usually does not create Pods directly, but manages Pods through the Controller. The Controller defines the deployment characteristics of the Pod, such as how many replicas there are and what kind of Node it runs on. In order to meet different business scenarios, Kubernetes provides a variety of Cotollers, including Deployment, ReplicaSet, DaemonSet, StatefuleSet, Job, etc. We will discuss them one by one.
(1) Deployment is the most commonly used Cotoller. For example, in online tutorials, applications are deployed by creating Deployment. The Deployment can manage multiple copies of the Pod and ensure that the Pod is running in the desired state.
(2) ReplicaSet realizes the management of multiple copies of Pod. ReplicaSet is automatically created when using Deployment, which means that Deployment manages multiple copies of Pod through ReplicaSet. We usually don't need to use ReplicaSet directly.
(3) DaemonSet is used in scenarios where each Node can run at most one Pod copy. As its name suggests, DaemonSet is usually used to run daemons.
(4) StatefuleSet can guarantee that each copy of Pod has the same name throughout its life cycle, while other Contollers do not provide this function. When a Pod fails and needs to be deleted and restarted, the name of the Pod will change, and StatefuleSet will ensure that the copy is started, updated, or deleted in a fixed order.
(5) Job is used for applications that are deleted at the end of running, while Pods in other Cntoller usually run continuously for a long time.
6. 【Service】
Deployment can deploy multiple replicas. Each Pod has its own IP. How can the outside world access these replicas? Do you
pass the Pod’s IP?
Knowing that Pods are likely to be destroyed and restarted frequently, and their IPs will change. IP access is not realistic.
The answer is Service.
- Kubermeles Service defines the way for the outside world to access a specific set of Pods. Service has its own IP and port, and Service provides load balancing for Pod.
- Kubemes runs the container (Pod) and accesses the container (Pod) by Cntoller and Servce respectively.
7.【Namespace】
If there are multiple users or project groups using the same Kubemetes Custer how to separate the Cotollerod and other resources they created? The
answer is Namespace.
- Namespce can logically divide a physical Claster into multiple virtual Custers. Each Cluster is a Namespce, and the resources in different Namespaces are completely isolated.
- Kubemnetes creates four Namespaces by default, as shown below:
$ kubectl get namespace
NAME STATUS AGE
default Active 44m
kube-node-lease Active 44m
kube-public Active 44m
kube-system Active 44m- default: If not specified when creating a resource, it will be placed in this Namespace.
- kube-system: The system resources created by Kubemetes will be placed in this Namespace.
Proficiency in understanding and mastering the above basic concepts is very helpful in the practice of cluster deployment. I hope that the combing of the above basic concepts can help useful friends.