Master
The cluster controller node is responsible for managing and controlling the entire cluster and executing commands. It runs the following four key processes.
(1) Kubernetes API Service (Kube-Apiservice) : a key Service process that provides Http Rest interface. It is the only operation entrance of CRUD of all resources in K8s and also the entrance process of cluster control.
(2) Kubernetes Controller Manager (kube-controller-manager) : Kubernetes Controller Manager (kube-controller-Manager) Controller Monitors the health status of containers. Controller Manager monitors the health status of controllers.
(3) Kubernetes Scheduler (KuBE-Scheduler) : pre-selection is performed to select which nodes meet the requirements and then select the best Node. The process responsible for resource scheduling (Pod scheduling).
(4) ETCD Server: saves the data of all resource objects. Etcd quickly notifies Kubernetes components when data changes.
Node
Workload nodes. Each Node is assigned workload by the Master (Docker container). When a Node is down, the workload on the Node is automatically transferred by the Master to other nodes. Each Node runs the following set of processes.
(1) Kubelet: Responsible for Pod container creation, start and stop tasks, and work closely with Master to achieve the basic functions of cluster management.
(2) KuBE-Proxy: an important component to realize the communication and load balancing mechanism of K8s Service.
(3) Docker Enginer: Docker engine, responsible for the creation and management of the local container.
Nodes can be added dynamically to the cluster at run time, and by default Kubelet registers itself with the Master. It regularly reports its own information, such as Docker version, CPU, memory, which Pod to run, etc. In this way, the Master can be familiar with Node information and implement an efficient and balanced resource scheduling policy. If the Node information is not reported within a specified period, the Master determines that the Node is disconnected and loads are transferred.
~ You can run the following command to view nodes in the cluster
kubectl get nodes
Copy the code
Kubectl describe nodes/ node namesCopy the code
Pod
Multiple service containers in a Pod share the IP address and Volume of the Pause container, simplifying the communication between service containers and solving the file sharing problem.
K8s assigns a unique IP address to each Pod, referred to as Pod IP. The container inside Pod can share IP, and the virtual layer 2 network technology is used to realize TCP/IP communication between any two PODS in the cluster.
Each Pod can set a quota of computing resources on the server that it can use. Currently, there are two types of computing resources that can be set a quota: CPU and memory. The unit of CPU resources is the number of cpus, which is an absolute value rather than a relative value.
In K8S, the minimum unit is usually 1/1000 of the CPU quota, expressed in m, and the Memory quota is also an absolute value, the number of bytes of Memory per hour.
In K8s, you need to set the following two parameters to limit the quota of a computing resource:
Requests: Minimum number of Requests that must be met.
Limits: The container cannot be breached. When a container attempts to be breached, it is killed and then restarted.
For example, when declaring a Pod or Service, you can set it in spec
spec:
container:
- name: db
image: mysql
imagePullPolixy: IfNotPresent
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Copy the code
You can use the following command to view the details of the resource
Kubectl describe Resource type Resource nameCopy the codeSuch as:
kubectl describe nodes cnode-1
Copy the code
Label
Label information, kv key-value pairs, can be attached to various resource objects, such as Node, Pod, Service, RC, etc. A resource object can define multiple labels. A Label can be added to multiple resources, usually at the time of resource definition, or dynamically added or deleted after the object is created.
Resource objects with certain labels can be queried and filtered by Label Selector. There are currently two types of Label Selector expressions, equal-based and set-based.
For example: name = redis
env ! = dev
name in (a,b)
name not in (a,b)
When multiple implementation complex choices are required, they can be separated by commas to indicate the relationship between And.
Use scenario of Label Selector:
(1) Kube-Controller filters the number of Pod copies to be monitored through the Label Selector defined on RC, so as to realize the automatic monitoring process that the number of Pod copies always meets the expected setting.
(2) Kube-proxy selects the corresponding Pod through the Label Selector of Service, and automatically establishes the request forwarding routing table from each Service to the object Pod, so as to realize the intelligent load balancing mechanism of Service.
(3) Kube-schedule implements Pod directional scheduling through Label and NodeSelector, a Label scheduling policy, in Pod definition file.
Replication Controller
RC defines an expected scenario that states that the number of pods meets an expected value at any given time. The definition of RC consists of the following parts:
(1) The expected number of copies of Pod
(2) Label Selector used to filter the target Pod
(3) When the number of Pod copies is smaller than the expected number, create enough pods using the Pod template used to create new pods
For example, you want a Redis to hold 3 instances
apiVersion: v1
kind: ReplicationController
metadata:
name: redis
labels:
name: redis
spec:
replicas: 3
selector:
name: redis
template:
metadata:
name: redis
labels:
name: redis
spec:
containers:
- name: redis
image: redis
imagePullPolicy: IfNotPresent
ports:
- containerPort: 6379
Copy the codeThe Master periodically checks the number of surviving target PODS in the system based on RC and ensures that the number of Pod instances is exactly the number that RC expects.
You can run the following command to dynamically change the replica value in the RC to expand or shrink the cluster.
kubectl scale rc rc-name --replicas=4
Copy the codeFeatures and functions:
(1) The Pod creation process and the number of copies can be automatically controlled by defining RC.
(2) Include the completed Pod definition template in RC
(3) RC realizes automatic control of Pod copy through Label Selector mechanism.
(4) By changing the number of Pod copies in RC, the Pod can be expanded or reduced.
(5) Achieve Pod rolling upgrade function by changing the image version in RC.
Deployment
Common Pod controllers are as follows:
Controller name role Deployment declarative update controller, used to publish stateless application ReplicaSet controller, used to scale up Pod replicas or cut StatefulSet stateful ReplicaSet, used to publish stateful application DaemonSet controller
Run a copy on each Node in the K8s cluster,
For applications such as publishing monitoring and log collection classes
Job Runs one-time Job CronJob Runs periodic Job
Deploymen is implemented internally using Replica Set, the next generation RC that supports the use of collection-based Label Selector, which is the only difference from Replication Controller.
Usage Scenarios:
(1) Create a Deplayment to generate the corresponding Replica Set and complete the Replica creation process
(2) Check the state of Deplayment to see whether the deployment action is complete
(3) Update Deplayment to create new pods
(4) If the current Deplayment is unstable, roll back to an earlier version.
(5) Suspend or resume a Deplayment.
(6) Expand Deployment to cope with high load.
(7) Clear the old ReplicaSets that are no longer needed.
The declared API for Deployment is Extensions/V1Betal, and other uses are no different from RC
apiVersion: extensions/v1betas
Copy the codeStatefulSet
Many services are stateful, especially some middleware clusters, such as MySQL cluster, MongoDB cluster, Akka cluster, ZooKeeper cluster, etc. These application clusters all have the following similarities:
(1) Each node has a fixed identity ID, through which members in the cluster can discover and communicate with each other.
(2) The scale of the cluster is relatively fixed and cannot be changed at will.
(3) Each node in a cluster is stateful, usually persisting data to permanent storage.
(4) If the disk is damaged, a node in the cluster cannot run properly and the cluster power is damaged
If you use RC or Deployment, you will find that the first point cannot be met because the Pod name is randomly generated and not fixed, and then another name, IP, and so on after a restart.
StatefulSet solves the above problems:
(1) Each Pod in StatefulSet has a stable, unique network identity that can be used to discover other members of the cluster. Assuming the StatefulSet name is kafka, the first Pod is kafka-0, the second is kafka-1, and so on.
(2) The start and stop sequence of the Pod copy controlled by StatefulSet is controlled. When the NTH Pod is operated, the first N-1 Pod is already running and ready.
(3) Pod in StatefulSet adopts stable persistent storage volume, which is realized through PV or PVC. When Pod is deleted, the storage volume related to StatefulSet will not be deleted by default (to ensure data security).
In addition to being used bundled with PV volumes to store Pod state data, StatefulSet is also used with Headless Services, which Headless Service it belongs to is declared in each StatefulSet definition. The key difference between a Headless Service and a common Service is that it does not have a Cluster IP address. If the DNS domain name of a Headless Service is resolved, the Endpoint list of all the PODS corresponding to the Service is returned. StatefulSet creates a DNS domain name for each Pod instance controlled by StatefulSet on top of the Headless Service. This domain name is in the following format:
${podname}.${handless service name}
Copy the codeFor example, a three-node StatefulSet cluster for Kafka has a Headless Service named Kafka and a StatefulSet named Kafka. The DNS names of the three pods in StatefulSet are kafka-0. Kafka, kafka-1. Kafka, and kafka-3.
Job
Different from other Pod controllers, the container controlled by a Job is run only once. When all Pod copies are finished, the Job is run. The Job copies cannot be restarted automatically.
In addition, k8S provides cronJobs to solve the problem that certain tasks need to be executed periodically and repeatedly.
Horizontal Pod Autoscaler
Pod horizontal automatic expansion, by tracking and analyzing the load changes of all the target PODS controlled by RC, to determine whether to adjust the number of target Pod copies.
HPA can be used as a measure of Pod load in two ways:
(1) CPUUtilizationPercentage
Arithmetic mean, the one-minute average of the CPU utilization of all copies of the target Pod, is the current CPU usage divided by Requests. If it exceeds a custom ratio, such as 80%, dynamic capacity expansion is required
For example, declare one HPA to expand the Deployment name test to a maximum of 10 when the CPU utilization reaches 90%
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: test
namespace: default
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
kind: Deployment
name: test
targetCPUUtilizationPercentage: 90
Copy the codeYou can also run the following command to create an HPA
kubectl autoscale deployment app-name --cpu-percent=90 --min=1 --max=1
Copy the code(2) Application custom metrics, such as TPS or QPS (Requests per second)
Service
A Service in K8s defines an access address of a Service, through which the front-end application can access a cluster instance composed of Pod copies behind it. The connection between a Service and a cluster of Pod copies behind it is realized by Label Selector.
You can view details about the service by running the following command
kubelet get svc service-name -o yaml
Copy the codeSuch as:
The Service supports multiple endpoints. In this case, each Endpoint needs to define a name distinction, for example:
apiVersion: v1
kind: Service
metadata:
name: tomcat-test
spec:
selector:
name: tomcat-test
ports:
- port: 8080
name: service-port1
- port: 8081
name: service-port2
Copy the code(1) Service discovery mechanism of K8S
The Service in K8S has a unique Cluster IP and a unique name. It is introduced into the DNS system by means of add-on value-added package, and the Service name is taken as the domain name. The program can directly use the Service name to establish communication connections.
(2) External systems access Service
Three kinds of IP:
1. Node IP: IP address of a Node
The IP address of the physical network adapter of the Node, the actual physical network, and the Node outside the K8s cluster must communicate with each other through the Node IP address when accessing the cluster.
2. Pod IP: IP address of a Pod
Docker Engine assigns a virtual layer 2 network based on the IP address segment of the docker0 bridge.
3. Cluster IP: IP address of the Service
It only works on the Service object, and K8S manages and assigns IP addresses. Cannot be pinged. Only a Service Port can be combined to form a specific communication Port. A single Cluster IP address does not support TCP/IP communication.
If you need nodes outside the cluster to access the cluster, the solution is to use NodePort, for example:
apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
type: NodePort
selector:
name: tomcat
ports:
- port: 8080
nodePort: 30001
Copy the codeIn the above example, specify spec.type as NodePort, and then specify NodePort in ports, which is the host port number.
If NodePort is not specified, K8S automatically allocates an available port.
NodePort is implemented by enabling a CORRESPONDING TCP listening port on each Node in the K8S cluster for services that need external access. External systems only need the IP address of any Node + the port of a specific NodePort to access services.
Volume
Volume is a shared directory in Pod that can be accessed by multiple containers. K8s Volume is defined on Pod and then mounted to a specific file directory by multiple containers of Pod. The Pod life cycle is the same as that of the container. Data in the Volume is not lost when the container terminates or restarts. Multiple types of volumes are supported, such as GlusterFS file systems.
Use:
Declare a Volume on Pod, reference the Volume in Pod, and Mount it to a directory in Pod. For example, add a Volume named datavol and Mount it to /mydata-data.
spec:
volumes:
- name: datavol
emptyDir: {}
containers:
- name: test-volume
image: tomcat
volumeMounts:
- mountPath: /mydata-data
name: datavol
Copy the codeK8s offers a wealth of volume types:
(1) emptyDir
When Pod is assigned to Node, the initial content is empty, there is no need to specify the corresponding directory file on the host, K8S automatically allocates, when Pod is removed from Node, emptyDir data will be permanently deleted.
USES:
1. Temporary space
2. The temporary save directory of CheckPoint during a long task
3. A directory that one container needs to fetch data from another container (shared directory)
volumes:
- name: emptyDir
emptyDir: {}
Copy the code(2) hostPath
Mount a file or directory on a host to a Pod for the following purposes:
1. Logs generated by the container need to be saved permanently
2. When the container application needs to access the internal data structure of the Docker engine on the host, it can define hostPath as the /var/lib/docker directory of the host so that the internal application of the container can directly access the Docker file system.
Note:
1. Pods with the same configuration on different Nodes may have different directories and files on the host, resulting in inconsistent access results for directories and files on the Volume.
2. If resource quota management is used, K8s cannot manage the resources used by hostPath on the host.
volumes:
- name: hostpath hostpath: path: “/path”
(3) the gcePersistentDisk
The Persistent Disk (PD) provided by Google Public Cloud is used to store Volume data. The content on PD is permanently saved. When Pod is deleted, PD is unmounted but not deleted, and a permanent Disk needs to be created first. To use gcePersistentDisk.
Restrictions:
Node requires a GCE vm
These VMS need to exist in the same GCE project and zone as the PD.
A PD can be created using the gcloud command
gcloud compute disks create --size=500GB --zone=us-centrall-a my-data-disk
Copy the codevolumes:
- name: gcePersistentDiskTest
gcePersistentDisk:
pdName: my-data-disk
fsType: ext4
Copy the code(4) awsElasticBlockStore
To store data using the EBS Volume provided by Amazon Public Cloud, you need to create an EBS Volume first
Restrictions:
The Node Node requires an AWS EC2 instance
AWS EC2 instances need to exist in the same region and availability-zone as EBS Volumes
EBS supports only one Volume for a single EC2 instance
volumes:
- name: awsElasticBlockStoreTest
awsElasticBlockStore:
volumeId: aws://<availability-zone>/<volume-id>
fsType: ext4
Copy the code(5) the NFS
If the shared directory provided by the NFS network file system is used to store data, an NFS Server must be deployed in the system
volumes:
- name: nfs
nfs:
server: NFS Server Address
path: "/"
Copy the codePersistent Volume
Persistent Volume(PV) and its associated Persistent Volume Claim (PVC) are a piece of network storage connected to a “network disk” on a virtual machine. Network storage is a kind of physical resource independent of computing resource.
PV is a block of storage corresponding to a network storage in a K8s cluster. It is similar to Volume but has the following differences:
(1) PV can only be network storage, does not belong to any Node, but can be accessed on any Node.
(2) PV is not defined on Pod, but is defined independently of Pod.
(3) PV currently has only several types: GCE Persistent Disks, NFS, RBD, iSCSCI, AWS ElasticBlockStore, GlusterFS
For example, define an NFS PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: pvtest
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
nfs:
server: NFS address
path: /path
Copy the codeThe focus is on PV accessModes, which currently have the following types:
(1) ReadWriteOnce: Indicates the read and write permission and can be mounted only by a single Node
(2) ReadOnlyMany: read-only permission to be mounted by multiple nodes
(3) ReadWriteMany: indicates the read and write permission to be mounted by multiple nodes
If a Pod wants to Claim a CONDITIONAL PV, it first needs to define a Persistent Volume Claim (PVC) object
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
Copy the codeYou can then reference the above PVC in the Volume definition of the Pod
volumes:
- name: pvtest
persistentVolumeClaim:
claimName: myclaim
Copy the codePV has the following states:
(1) Available: Available
(2) Bound: already Bound to a PVC
Released: The corresponding PVC has been deleted, but the resource has not yet been recycled by the cluster
(4) Failed: PV automatic reclamation fails.
Namespace
Resource objects in a cluster can be allocated to different namespaces to form logically different projects, groups, or user groups. In this way, different groups can share resources in the entire cluster and be managed separately.
After the K8S cluster starts, a Namespace named default is created. You can run the following command to view the Namespace name
Kubectl get namespace or kubectl get NSCopy the codeIf a Namespace is not specified during the resource definition, the Pod, Service, and RC created by the user will be created in the Namespace of default.
Definition of Namespace:
apiVersion: v1
kind: Namespace
metadata:
name: my-ns
Copy the codeDefine Pod in this Namespace
apiVersion: v1
kind: Pod
metadata:
name: my-pod
namespace: my-ns
labels:
name: my-pod
spec:
containers:
- name: my-pod
image: imageName
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
Copy the codeUsing Kubectl get Pods is a Pod that can only see the default Namespace. If you want to see resources of other namespaces, you need to specify a Namespace.
Kubectl get Pods --namespace=my-ns or kubectl get Pods -n my-nsCopy the codeWhen a Namespace is created for different tenants to implement resource isolation, the Namespace can limit the resources that tenants can occupy, such as CPU usage and memory usage, based on k8S resource quota management.
Annotation
It is defined in the form of key/value key-value pairs, similar to Label, except that Label has strict naming rules, defines metadata of resource objects and is used for Label Selector, while Annotation is additional information arbitrarily defined for external tools to find. K8s marks up some special information about the resource object in this way.
The following information is recorded using annotations:
(1) Build information, release information, Docker image information, such as time stamp, release ID number, image hash value, Docker Registry address, etc
(2) Log database, monitoring database, analysis database and other resource database information
(3) Program debugging tool information, such as tool name, version number, etc
(4) Contact information of the team, such as telephone number, person in charge information, etc.
ConfigMap
The Docker container provides two ways to modify parameters in the configuration file at run time.
(1) Pass parameters through the container’s environment variables at runtime;
(2) Use Docker Volume to map configuration files outside the container to the container.
In most cases, the second method is used, but this method requires the creation of a configuration file on the host for mapping. In distributed cases, modifying a configuration file on multiple servers is quite troublesome.
V can also be the path of a file, such as username= ABC. These configuration items can be used as one item in the Map. The entire Map data can be persisted in Kubernetes Etcd database. Apis are then provided to facilitate CRUD manipulation of the data by kubernetes-related components or customers.
K8s provides a mechanism to convert ConfigMap stored in ETCD into a configuration file in the target Pod through Volume mapping, which is automatically mapped regardless of which server the target Pod is scheduled to run on. Further, if key-value data in ConfigMap is modified, the “configuration file” mapped to Pod is automatically updated accordingly.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
I’m Liusy, a programmer who likes to work out.
Welcome to pay attention to wechat public number [Liusy01], exchange Java technology and fitness, get more dry goods, get Java advanced dry goods, get the latest factory interview materials, become a Java god together.
Here we go. Keep an eye on it.