What's a replica set?
We have talked about what a pod is in the previous article, simply put a pod is the basic unit of direct operation of k8s.
For those who don't know, refer to the previous article:
k8s real combat 1 ---- first acquaintance (/jilodream/p/18245222)
k8s hands-on 2 ---- pod basics (/jilodream/p/18284282)
k8s Practical 3 ---- tags (/jilodream/p/18293278 )
If just have pod, basically can meet our common development learning, but this and we directly use docker container difference is not very big, to know k8s to do is to provide a complete set of management and deployment system, if only is to operate a few pod, it is a little too big.
So we have to learn some higher order resources to be able to utilize the various capabilities provided by k8s. For example ReplicaSet ReplicaSet, Deployment Deployment etc.
Today we are going to learn and use the ReplicaSet.
replica U.S. [ˈreplɪkə] copy; imitation.
ReplcaSet literally means a collection of replicas, which we generally translate as a replica set.
Typically, for high availability, we create multiple instances of each microservice, the
In order to facilitate management, each instance usually corresponds to a container, (anti-theft connection: this article was first published from /jilodream/ ) each container often corresponds to a pod, multiple instances actually corresponds to multiple pods. based on this, k8s defines a more advanced resource called ReplicaSet, in order to manage the collection of pods (replica set).
Let's say we want to create 3 replica sets of kuard services, how should we create them via replica sets?
As with defining a pod directly, we can define a yaml template through which we declare the characteristics of the replica set we want to define
Below:
1 apiVersion: apps/v1 2 kind: ReplicaSet 3 metadata: 4 name: kuardrs 5 spec: 6 replicas: 2 7 selector: 8 matchLabels: 9 appRs: kuardrs 10 template: 11 metadata: 12 labels: 13 appRs: kuardrs 14 version: "2" 15 spec: 16 containers: 17 - ports: 18 - containerPort: 80 19 name: kuardpod1 20 image: "/library/kuard-amd64:blue"
This is a standard ReplicaSet template.
As with the pod template, let's look at the meaning of each key in turn:
firstlyapiVersion Indicates the currently selected version
kind represents the type, and our type is ReplicaSet, which is the replica set
metadata denotes metadata, where we define the name of the newly created replica set as: kuardrs
spec denotes a characteristic, where we define some information about the internal characteristics of the replica set:
Indicates the number of copies in the replica set
Labels that indicate a copy set match are also called label selectors. This needs to be talked about in detail. In the previous section, we already know what a label is, it can be understood as a series of kv values defined to the top side of the resource, we can use the label to match and filter resources.
The replica set we created and the pod, or the future Deployment and the replica set, are loosely coupled and not directly dependent on each other. In other words, after creating a replica set, you can add or delete pods as you like, and the replica set itself will not be affected. But the replica set will be labeled to sense whether the currently managed pods meet its requirements.
When it finds more matching pods, it tries to delete them, and when it finds fewer matching pods than it requires, it tries to add new pods, so it is not apt to say that a replica set is a collection of pods, but more accurately, a replica set is a higher dimensional resource used to define and standardize the collection of pods.
And when we usually find that a certain pod is running with some problems, and we don't want to delete the pod directly, and we don't want the production environment to continue to hold a problematic pod, we can just modify the label of the pod, and take the pod out of the scope of replica set management, and strip it out. Then we can do further research around the problematic pod.
And these pods are stateless for the replica set, replacing anyone, as long as they meet the label matching requirements of the replica set. It's like this one below:
In this example, the resource matched by the selector is the conforming tag:appRs: kuardrs Note that the matching is done here with matchLabels.
is the template definition of the pod, where we have nodes for pod metadata as well as pod characteristics, respectively.
We define the two tags to be held by the pod in the pod's metadata node (anti-theft link: this article was first published from /jilodream/ ):
appRs: kuardrs
version: "2"
The spec characteristics node of the pod defines the image, name, port, etc. of the container in the pod.
template in the definition of pod and the previous declaration of pod is basically similar, interested students must read the previous article, here will not be too much elaboration.
In a nutshell the defined pod, which contains information about containers, labels, etc., and the replica set we've settled on specify information about the labels to be filtered, and the two are very loosely connected through the labels.
After defining the yaml file for the replica set, let's look at the general operation of the replica set
Creating a Replica Set
The kubectl apply -f file is the replica set declaration file
The execution effect is as follows:
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl apply -f
/kuardrs created
View copy set
kubectl get replicaset , noting that replicaset can also be replicasets/rs (which will not be repeated below).
The execution effect is as follows. The replica set checked here is the replica set just created:
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl get replicaset
NAME DESIRED CURRENT READY AGE
kuardrs 2 2 2 57s
View copy set details
k describe replicasets xxx xxx is the replica set name
The execution effect is as follows:
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl describe replicaset kuardrs Name: kuardrs Namespace: default Selector: appRs=kuardrs Labels: <none> Annotations: <none> Replicas: 2 current / 2 desired Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: appRs=kuardrs version=2 Containers: kuardpod1: Image: /library/kuard-amd64:blue Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 3m30s replicaset-controller Created pod: kuardrs-q8ghw Normal SuccessfulCreate 3m30s replicaset-controller Created pod: kuardrs-wd29m
We can see the various attributes and templates of the replica set definition in the details. As well as some relevant information about the associated out pod.
Sometimes we also need to baseThe pod found it in reverse.Which copy set does it belong to?In this case, you can use the yaml file in the pod to find the set of replicas you have created.
It can be seen under the key ownerReferences as follows:
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl get pod
NAME READY STATUS RESTARTS AGE
kuardrs-q8ghw 1/1 Running 0 4m23s
kuardrs-wd29m 1/1 Running 0 4m23s
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl get pod kuardrs-q8ghw -o yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
/containerID: 619b5de35bedd683352ce58bab8e6efd03e79fa4495a8ae89bae85f93ac7ed3f
/podIP: 192.168.240.165/32
/podIPs: 192.168.240.165/32
creationTimestamp: "2024-12-10T07:13:15Z"
generateName: kuardrs-
labels:
appRs: kuardrs
version: "2"
name: kuardrs-q8ghw
namespace: default
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: kuardrs
uid: 8a91c42a-864a-4172-8653-373210a59eaa
resourceVersion: "28299737"
uid: 587be9bd-2d0a-402b-a3a4-72edbc3170db
spec:
containers:
- image: /library/kuard-amd64:blue
imagePullPolicy: IfNotPresent
....an omission....
If weWant to adjust the number of copies or other attributes
We can do this through the
(1) k edit rs xxx , xxx is the name of the copy set
(2) k apply -f , the file is a declaration file for the replica set
(3) k scale rs xxx --replicas=number of new replicas , xxx is the replica set name
We directly show the effect of the last (anti-theft connection: this article was first published from /jilodream/ ) execution:
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl get pod
NAME READY STATUS RESTARTS AGE
kuardrs-q8ghw 1/1 Running 0 9m19s
kuardrs-wd29m 1/1 Running 0 9m19s
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl scale rs kuardrs --replicas=3
/kuardrs scaled
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl get pod
NAME READY STATUS RESTARTS AGE
kuardrs-lhgtc 1/1 Running 0 8s
kuardrs-q8ghw 1/1 Running 0 10m
kuardrs-wd29m 1/1 Running 0 10m
Deleting a replica set
k delete rs xxx , xxx is the name of the replica set
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl get rs
NAME DESIRED CURRENT READY AGE
kuardrs 3 3 3 29m
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl delete rs kuardrs
"kuardrs" deleted
[root@iZ2ze3bpa0o5cw6gp42ry2Z learnRs]# kubectl get rs
No resources found in default namespace.