This article describes how to quickly set up a K8s system. To continue deploying our applications using K8S, we need to understand some of the basic components and concepts in K8S.
What is Kubernetes
Kubernetes is a container orchestration management system based on Google’s internal Brog system that uses declarative configurations (in the form of YAML files) to automatically manage containerized applications, including deployment, scaling, load balancing, rollback, and so on.
Features provided by Kubernetes:
- Automatic publishing and scaling: You can define the containers you want to deploy through a declarative configuration file, and Kubernetes will automatically deploy the containers to achieve the desired results; The group of containers can be rapidly scaled up or down automatically by specifying the number of copies or by setting the number of containers to be increased or decreased based on resource load (such as CPU or memory usage)
- Rolling upgrade and grayscale release: using the strategy of gradual replacement to achieve rolling upgrade, using Kubernetes can also easily manage the system’s grayscale release
- Service discovery and load balancing: Kubernetes exposes container access through DNS name or IP address, and implements load distribution and load balancing within the same container group
- Storage orchestration: Kubernetes can automatically mount specified storage systems, such as Local storage/ NFS/cloud storage, etc
- Fault recovery: Kubernetes automatically restarts containers that have stopped and replaces containers that do not meet the health check
- Key and configuration management: Kubernetes can store and manage sensitive information, such as Docker Registry login credentials, passwords, SSH keys, etc
Kubernetes architecture
Let’s start with a Kubernetes architecture diagram
Kubernetes is a distributed system, similar to most distributed systems, consisting of master nodes and worker nodes.
master node
The control node is the commander, who is responsible for issuing orders. Some management services run on it to manage and control the whole system, including
- Apiserver: As the external interface of the whole system, it provides a set of Restful apis for clients to call. Any resource request/call operation is carried out through the interface provided by Kube-Apiserver. Management tools such as Kubectl and Kubernetes Dashboard use Apiserver to manage clusters
- Kube-scheduler: Resource scheduler, which nodes to assign container groups to
- Kube – controller – manager: The management controller, the background thread that handles routine tasks in the cluster, Including node controller (listens for node downtime events and responds accordingly), endpoint-controller (refreshes association information between Service and container group), replication-Controller (maintains a specified number of container group copies), and Service Account & Token controller (responsible for creating default Service Accounts and API Access tokens for the new namespace)
- Etcd: data store, all configuration information of storage cluster
- Coredns: Enables container group access within a cluster by service name
worker node
A work node is a concrete soldier that also runs services to perform tasks assigned by the commander, including
- Kubelet: an agent that performs operations on the working node. It is responsible for container lifecycle management, periodic container health checks, and container running status reports
- Kube-proxy: a simple network access proxy with load balancing capabilities that allocates requests for access to a service to a specific container on the work node (kube-proxy also runs on the master node)
- Docker Daemon: This is easy to understand. All services and container groups need to be run as Docker containers (Kubernetes is not limited to Docker, it supports any container engine that implements the Kubernetes container engine interface, such as Containerd and rktlet).
In addition, there is a network communication component kube-Flannel that runs on both master and worker nodes. These service components typically run in the kube-system namespace, as shown in the figure
Basic concepts of Kubernetes
Let’s look at the second picture
The functional components are described above. Kubernetes operates on pods, services, replication-controllers, and other auxiliary objects around them
Pod
A Pod is the smallest basic unit of Kubernetes to create or deploy. A Pod encapsulates one or more application containers, storage resources, a separate network IP, and policy options that govern how the container operates. Each container in a Pod shares a network namespace (including IP and port), and containers in a Pod can communicate with each other using localhost. A Pod can specify a set of shared storage Volumes. All containers in the Pod can access the shared Volumes. Volumes are used for data persistence to prevent container restarts from losing data.
Volume
Kubernetes uses Volume to solve the problem of lost container restart data in PODS and data sharing between multiple containers in PODS. Kubernetes supports the following Volume types:
- EmptyDir: When a Pod is assigned to a Node, an emptyDir will be created and the Volume will remain as long as the Pod is running on the Node. When a Pod is removed from a Node (for any reason), emptyDir is also deleted and the stored data is permanently deleted, but deleting the container does not affect emptyDir
- HostPath: hostPath allows you to mount file systems from Node to Pod. If Pod needs to use files on Node, hostPath can be used
- NFS: indicates the shared directory provided by the NFS network file system
ReplicationController
ReplicationController ensures that the configured number of Pod copies is running at all times. It is recommended that Deployment with ReplicaSet (next generation ReplicationController) be used to set up the replica management mechanism.
ReplicaSet
ReplicaSet is the next generation of ReplicationController. The only difference between ReplicaSet and ReplicationController is that it supports the new collection-based selectors, while ReplicationController only supports equality-based selectors.
Deployment
Deployment provides declarative definitions for Pod and ReplicaSet that describe what you want the target state to be, and the Deployment Controller will help you change the actual status of Pod and ReplicaSet to the desired target state.
Service
A Service can be thought of as an external access interface for a set of PODS that provide the same Service. Kubernetes provides two types of Service:
- NodePort: External nodes can access a Pod using Node IP and NodePort
- ClusterIP: Exposes services using the internal IP address of the cluster. The service can be accessed only within the cluster. This is the default ServiceType
Label
A Label is a pair of keys/values that can be attached to a variety of resource objects, such as Node, Pod, and Service. A resource object can define any number of labels. Resources with certain labels can be selected through the Label selector.
PV & PVC
PersistentVolume (PV) provides users with a storage abstraction that is set up by administrators and is part of a cluster. Just as a node is a resource in a cluster, a PV is a resource in a cluster. PV is a Volume plug-in like Volume, but has a Pod independent lifecycle.
PersistentVolumeClaim (PVC) is a user-stored request. It is similar to Pod. Pod consumes node resources, and PVC consumes PV resources. Pods can request specific levels of resources (CPU and memory). PVCS can request storage resources of a specific size and access mode (for example, they can be mounted in read/write or read-only mode).
Secret
Secret solves the storage problem of sensitive data such as passwords, tokens and keys. There are three types of Secret:
- Service Account: used to access Kubernetes API by Kubernetes is automatically created, and will automatically be mounted to the Pod/run/secrets/Kubernetes. IO/serviceaccount directory
- Opaque: Secret in Base64 encoding format, used to store passwords and keys
- Kubernetes. IO/dockerconfigjson: used to store docker registry authentication information
ConfigMap
ConfigMap is used to hold configuration data for key/value pairs, which can be used in Pods, or used to store configuration data for system components like controllers. ConfigMap can easily handle strings that do not contain sensitive information (use Secret for sensitive information).
Namespace
A Namespace is similar to a virtual cluster in Kubernetes, so that different groups can share the resources of the entire cluster and manage them separately. For example, if the development tests share a Kubernetes cluster, we can deploy the development environment services to the namespace of Dev and the test environment to the namespace of test.
Ingress
Provides external access to cluster services, including domain name binding access and routing for services based on Nginx and Traefik versions. Grayscale publishing of services can also be implemented based on Ingress.
conclusion
In this paper, the basic components and concepts involved in Kubernetes are sorted out, and the basic composition has a general understanding and impression. The next chapter will start from a practice to realize a CI/CD process based on Gitlab+Jenkins+K8s, so as to have a deep understanding and learning of each component involved.
Related reading:
- Kubernetes Notes (1) : Deploy a K8s environment in 10 minutes
Author: Yuge Welcome to pay attention to the author’s wechat public number: Halfway Yuge, learn and grow together