Article directory
Evolution of application deployment methods
In terms of the way to deploy applications, it has mainly gone through three eras: traditional deployment -> virtualization deployment -> containerization deployment
-
Traditional deployment: In the early days of the Internet, applications were deployed directly on physical machines.
Advantages: Simple, no other technology required
Disadvantages: Resource usage boundaries cannot be defined for applications, it is difficult to allocate computing resources reasonably, and it is easy to influence between programs
-
Virtualization deployment: Multiple virtual machines can be run on one physical machine, and each virtual machine is an independent environment.
Advantages: Program environments do not affect each other, providing a certain degree of security
Disadvantages: Adding an operating system and wasting some resources
-
Containerized deployment: similar to virtualization, but with a shared operating system
advantage:
It can ensure that each container has its own file system, CPU, memory, process space, etc.
The resources required to run the application are packaged in containers and decoupled from the underlying infrastructure
Containerized applications can be deployed across cloud service providers and Linux operating system distributions
Container orchestration issues
If a container fails and stops, how can I start another container immediately to replace the stopped container?
When the number of concurrent visits increases, how to horizontally expand the number of containers?
- Swarm: Docker’s own container orchestration tool, suitable for small and medium-sized projects
- Mesos: Apache's tool for unified resource management and control. It needs to be used in conjunction with Marathon. It is earlier than docker and supports the control of 50,000+ nodes.
- Kubernetes: Google’s open source container orchestration tool
Introduction to k8s
Kubernetes is a new leading solution for distributed architecture based on container technology. It is Google's secret weapon that has been kept strictly confidential for more than ten years - an open source version of the Borg system. The first version was released in September 2014 and in 2015 The first official version was released in July.
The essence of kubernetes is a set of server clusters, which can run specific programs on each node of the cluster to manage the containers in the nodes. The purpose is to realize the automation of resource management, and mainly provides the following main functions:
- Self-healing : Once a container crashes, a new container can be quickly started in about 1 second
- Auto-scaling : The number of running containers in the cluster can be automatically adjusted as needed.
- Service discovery : A service can find the services it depends on through automatic discovery
- Load balancing : If a service starts multiple containers, the load balancing of requests can be automatically realized
- Version rollback : If you find a problem with the newly released program version, you can immediately roll back to the original version.
- Storage orchestration : Storage volumes can be automatically created according to the needs of the container itself
k8s components
master node
The control plane of the cluster is responsible for the decision-making (management) of the cluster.
- ApiServer : The only entrance for resource operations, receives commands entered by users, and provides mechanisms such as authentication, authorization, API registration and discovery.
- Scheduler : Responsible for cluster resource scheduling and scheduling Pods to corresponding node nodes according to the predetermined scheduling policy.
- ControllerManager : Responsible for maintaining the status of the cluster, such as program deployment arrangements, fault detection, automatic expansion, rolling updates, etc.
- Etcd : Responsible for storing information about various resource objects in the cluster
nodenode
The data plane of the cluster is responsible for providing the operating environment (work) for the container.
- Kubelet : Responsible for maintaining the life cycle of the container, that is, creating, updating, and destroying the container by controlling docker
- KubeProxy : Responsible for providing service discovery and load balancing within the cluster
- Docker : Responsible for various operations of containers on nodes
add-ons
- kube-dns: Responsible for providing DNS services for the entire cluster
- Ingress Controller: Provides external network entrance for services
- Prometheus: Provides resource monitoring
- Dashboard: Provides GUI
- Federation: Provides clusters across availability zones
- Fluentd-elasticsearch: Provides cluster log collection, storage and query
call flow between components
Take deploying an nginx as an example to illustrate
-
First of all, make it clear: once k8s is started, both master and node will store their own data in the etcd database.
-
An installation request for an nginx service will first be sent to the apiserver component of the master node.
-
The apiserver component calls the scheduler component to determine which node the service will be installed on.
At this time, it will read the node information from etcd, then select according to a certain algorithm, and notify the apiserver of the result)
-
apiserver calls controller-manager to schedule node nodes to install nginx services
-
After kubelet receives the instruction, it will notify docker, and then docker will start the nginx pod.
pod: the smallest operating unit of k8s, the container must run in the pod
-
At this point, an nginx service has run successfully.
Architecture diagram
Core idea
Classification of services (stateless & stateful)
-
Stateless -> does not rely on local server environment
-
Representative services: nginx, Apache
-
Advantages: Transparent to the client, no dependencies, and can efficiently achieve expansion and migration
-
Disadvantages: cannot store data, requires additional data service support
-
-
Stateful -> relies on local server environment and requires data migration
- Representative services: MySQL, Redis
- Advantages: Data can be stored independently to achieve data management
- Disadvantages: In a cluster environment, it is complicated to implement master-slave, data synchronization, backup, and horizontal expansion.
Terminology
-
Resources and objects : Resources are configured through resource lists; resources are approximately equal to classes
-
Object specification and status : The status attribute is maintained by k8s itself. k8s will manage the corresponding object through a series of controllers so that the actual state of the object coincides with the expected state (spec) as much as possible.
-
Resource classification : cluster-level resources -> namespace-level resources -> metadata-level resources
-
Metadata types: Horizontal Pod Autoscaler (HPA), PodTemplate, LimitRange
Horizontal Pod Autoscaler (HPA): Pod automatic expansion: Pods can be automatically expanded/shrunk based on CPU usage or custom metrics.
Pod Template is the definition of Pod, but is included in other Kubernetes objects (such as Deployment, StatefulSet, DaemonSet and other controllers). The controller creates Pods through Pod Template information.
LimitRange: You can set a global unified limit on the configuration of Request and Limits in the cluster, which is equivalent to setting resource usage limits for Pods within a certain range (a certain namespace) in batches.
-
Cluster level: Namespace namespace, Node node resources, ClusterRoles declaration authority group, ClusterRoleBinding bind to the cluster level
-
Namespaces:
-
Workload Pod
Pod (container group) is the smallest deployable unit in Kubernetes. A Pod (container group) contains an application container (or multiple containers in some cases), storage resources, a unique network IP address, and some options that determine how the container should run. A Pod container group represents an independent application running instance in Kubernetes, which may consist of a single container or several tightly coupled containers.
Only one container runs in a Pod. "one-container-per-pod" is the most common usage in Kubernetes. At this point, you can think of the Pod container group as the wrapper of the container, and Kubernetes manages the container through the Pod instead of directly managing the container.
-
replicas
First introduce the concept of "copy" - a Pod can be copied into multiple copies, and each copy can be called a "copy". These "copies" except some descriptive information (pod name, uid, etc.) Except for the same, other information is the same, such as the containers inside the Pod, the number of containers, the applications running in the containers, etc., and these copies provide the same functions.
A Pod's "controller" usually contains a property called "replicas". The "replicas" attribute specifies the number of replicas of a specific Pod. When the number of Pods in the current cluster is inconsistent with the value specified by this attribute, k8s will adopt some strategies to make the current status meet the configuration requirements.
-
controller
When a Pod is created, the Pod will be scheduled to run on a node in the cluster. The Pod will remain running on that node until the process terminates, the Pod object is deleted, the Pod is evicted due to insufficient node resources, or the node fails. . Pods do not heal themselves. When a node fails, or the operation of scheduling Pods fails, Pods should be deleted. In this way, simply using Pod to deploy applications is unstable and unsafe.
Kubernetes uses a more advanced resource object "controller" to manage Pods. The controller can create and manage multiple Pods for you, manage replicas and online, and provide self-healing capabilities within the cluster. For example, if a node fails, the controller can schedule the same stand-in on a different node to automatically replace the Pod.
-
Applies to stateless services
-
ReplicationController（RC）
RC can guarantee the number of copies of a Pod running at any time and ensure that the Pod is always available. If the actual number of Pods is more than the specified number, the excess ones will be terminated. If the actual number is less than the specified number, some new Pods will be started. When a Pod fails, is deleted, or hangs up, RC will automatically create a new Pod to ensure a copy. quantity, so even if there is only one Pod, we should use RC to manage our Pods. It can be said that through ReplicationController, Kubernetes achieves high availability of Pods.
Has been replaced by RS~~
-
ReplicaSet (RS): only supports expansion and reduction
Label (label) is a key-value pair attached to Kubernetes objects (such as Pods), used to distinguish objects (such as Pod, Service). label is intended to be used to specify identifying properties of objects that are meaningful and relevant to the user, but do not have direct semantic meaning to the core system. Labels can be used to organize and select subsets of objects. Labels can be attached to objects at creation time and can be added and modified at any time. Like namespace, you can use label to obtain certain types of objects, but label can be used together with selector to limit conditions with expressions to achieve more precise and flexible resource search.
Label and selector cooperate to realize the "association" of objects. "Pod Controller" is associated with Pod - "Pod Controller" depends on Pod. You can set label for Pod, and then set the corresponding "Controller" selector, which realizes the association of objects.
-
Deployment : further encapsulates RS
The Deployment controller will help you change the actual state of the Pod and Replica Set to your target state. You can define a completely new Deployment, or create a new one to replace the old Deployment.
-
Create Replica Set/Pod
-
Rolling upgrade/rollback -> The upgraded RS1 will be retained for rollback
-
Smooth expansion and contraction
-
Pause and resume Deployment
Upgrade rollback is automatic -> pause and resume can be used
-
-
-
StatefulSet : suitable for stateful services
The DNS format of each Pod in StatefulSet is statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster.local
- serviceName is the name of the Headless Service
- 0…N-1 is the sequence number of the Pod, starting from 0 to N-1
- statefulSetName is the name of StatefulSet
- namespace is the namespace where the service is located. Headless Service and StatefulSet must be in the same namespace.
- .cluster.local 为 Cluster Domain
-
Features
- Stable persistent storage
- stable network sign
- Orderly deployment and orderly expansion
- Orderly shrink, orderly deletion
-
composition
-
Headless Service
Used to define network flags (DNS domain)
Domain Name Server: Domain name service, binding mapping relationship between domain name and IP
Service name => Access path (domain name) => ip
-
volumeClaimTemplate
Used to create PersistentVolumes
-
-
DaemonSet daemon process
DaemonSet ensures that a container copy is running on each Node and is often used to deploy some cluster logging, monitoring or other system management applications. Typical applications include:
- Log collection, such as fluentd, logstash, etc.
- System monitoring, such as Prometheus Node Exporter, collectd, New Relic agent, Ganglia gmond, etc.
- System programs, such as kube-proxy, kube-dns, glusterd, ceph, etc.
-
Task/scheduled task
-
JOB
A one-time task, the Pod is destroyed after the operation is completed, and the new container will not be restarted.
-
CronJob
CronJob adds timing function based on Job.
-
-
-
-
service discovery
-
Service (cluster internal communication, lateral traffic (east-west traffic))
"Service" is abbreviated as "svc". Pod cannot be directly provided for external network access, but should use service. Service is to expose Pod to provide services. Service is the real "service", and its Chinese name is "service".
It can be said that Service is an abstraction of an application service, which defines a logical collection of Pods and a strategy for accessing this Pod collection. The Service proxy Pod collection appears as an access portal to the outside world. Requests to access this portal will be forwarded to the containers in the backend Pod through load balancing.
-
Ingress (vertical traffic (north-south traffic))
Ingress can provide the ability to access the Service from the external network. A certain request address can be mapped and routed to a specific service.
Ingress needs to be used together with the ingress controller to work. Ingress is just a collection of routing rules. It is the Ingress Controller that truly implements the routing function. The ingress controller, like other k8s components, also runs in the Pod.
-
-
storage
-
Volume
Data volumes share data used by containers in Pods. Used to store persistent data, such as database data.
-
CSI
The Container Storage Interface is an industry standard interface specification jointly developed by community members from Kubernetes, Mesos, Docker and other communities, aiming to expose any storage system to containerized applications.
The CSI specification defines a minimum set of operations and deployment recommendations for storage providers to implement a CSI-compliant Volume Plugin. The main focus of the CSI specification is to declare the interfaces that the Volume Plugin must implement.
-
-
Special type configuration
-
ConfigMap
Used to store configurations, it is similar to Secret, except that ConfigMap stores plain text data, while Secret stores cipher text.
-
Secret
Secret solves the configuration problem of sensitive data such as passwords, tokens, and keys without exposing these sensitive data to images or Pod Specs. Secret can be used as a Volume or environment variable.
There are three types of Secrets:
- Service Account: used to access the Kubernetes API, automatically created by Kubernetes, and automatically mounted to the /run/secrets/kubernetes.io/serviceaccount directory of the Pod;
- Opaque: Secret in base64 encoding format, used to store passwords, keys, etc.;
- kubernetes.io/dockerconfigjson: used to store authentication information for private docker registry.
-
DownwardAPI (share pod information within the container)
The difference between downwardAPI and other modes is that it is not used to store container data or exchange data between the container and the host. Instead, it allows the container in the pod to directly obtain some information about the pod object itself. .
downwardAPI provides two ways to inject pod information into the container:
Environment variables: used for a single variable, which can directly inject pod information and container information into the container
Volume mounting: Generate pod information into a file and mount it directly into the container.
-
-
Permissions
-
Role
Role is a set of permissions. For example, Role can include listing Pod permissions and listing Deployment permissions. Role is used to authenticate resources in a Namespace.
-
RoleBinding
RoleBinding: Bind the Subject to the Role. RoleBinding makes the rules effective within the namespace.
-
-
-