Shulou(Shulou.com)06/03 Report--

Environment introduction host IP address service master192.168.1.21k8snode01192.168.1.22k8snode02192.168.1.23k8s

The experiment based on [https://blog.51cto.com/14320361/2464655]()] continues

ReplicaSet briefly introduces 1. RC:ReplicationController (the older generation of pod controller)

It is used to ensure that the number of copies of Pod objects controlled by it can meet users' expectations, either delete it or create it through templates.

Features: ​ ensures an accurate number of Pod resource objects. ​ ensures that pod is running healthily. ​ elastic expansion

Similarly, it can be created from a resource list in yaml or json format. The spec field is generally nested within the following fields:

​ replicas: the expected number of copies of the Pod object. ​ selector: the template that the current controller matches the Pod tag selector ​ template:pod copy of this copy of the item

Compared with RC, RS supports not only equivalent-based tag selectors, but also set-based tag selectors.

two。 Tags: solve the same type of resource objects, for better management, grouped according to tags. Commonly used tag categories: ​ release (version): stable (stable version), canary (Canary version), beta (test version) ​ environment (environment variables): dev (development), qa (testing), production (production) ​ application (application): ui, as (application software application), pc, sc ​ tier (architecture level): frontend (front end), backend (back end), cache (cache) ​ partition (partition): customerA (customer A), CustomerB (customer B) ​ track (quality control level): daily (daily), weekly (weekly)

The label should be done: see the name and know the meaning.

3. Test (1) write a pod yaml file [root@master ~] # vim label.yaml kind: PodapiVersion: name: labels labels: env: qa tier: frontendspec: containers:-name: myapp image: httpd execute [root@master ~] # kubectl apply-f label.yaml-- record check [root@master ~] # kubectl get pod-- show-labels / / display the resource object through-- show-labels

[root@master ~] # kubectl get po-L env,tier// displays the value corresponding to a key

[root@master ~] # kubectl get po-l env,tier// uses-l to view resources that contain only a tag.

(2) add tag [root@master ~] # kubectl label pod labels app=pc// add tag to pod resource (3) modify tag [root@master ~] # kubectl label pod labels env=dev-- overwrite// modify tag [root@master ~] # kubectl get pod-l tier-- show-labels / / check the tag

(4) write a service yaml file [root@master ~] # vim service.yamlkind: ServiceapiVersion: name: servicespec: type: NodePort selector: env: qa ports:-protocol: TCP port: 90 targetPort: 80 nodePort: 30123 execute [root@master ~] # kubectl apply-f service.yaml to check [root@master ~] # kubectl describe svc

Visit [root@master ~] # curl 127.0.0.1purl 30123

If there are multiple tags, the tag selector selects one of them, and the association can also be successful. Conversely, if there are multiple selectors, the tag must fully meet the criteria for the association to be successful.

4. Tag selector: query filter criteria for tags.

[equality-based based on equivalence] (): "=", "=", "!" the first two are equal, and the last one is not equal.

[based on set relationship (set-based)] (): in, notin, exists. There is a "logical and" relationship between selector lists. When using ln or NotIn operations, its valuas does not force a non-empty string list, while when using Exists or DostNotExist, its values must be empty.

The logic of using tag selectors: the logical relationship between multiple selectors specified at the same time is the and operation. Using a tag selector with a null value means that each resource object will be selected. An empty tag selector cannot select any resources. (1) examples

Write a selector yaml' file [root@master ~] # vim selector.yamlselector: matchLabels: app: nginx mathExpressions:-{key: name,operator: In,values: [zhangsan,lisi]}-{key: age,operator: Exists,values:} selector: the current controller matches Pod's tag selector for this copy matchLabels: specifies the tag selector represented by the key-value pair. The tag selector specified by mathExpressions:: based on the expression. DaemonSet

It is also a pod controller.

RC,RS, deployment, daemonset. It's all pod controllers. StatfukSet,RBAC

1. Use the scene:

If the pod must be run on one or more fixed nodes, and should take precedence over other pod startup. In general, each node is run by default, and only one pod can be run. In this case, the DeamonSet resource object is recommended.

Monitor program; log collector; cluster storage program; [root@master ~] # kubectl get ds-n kube-system / / check DaemonSet2. The difference between DaemonSet and Deployment the replicas of Deployment deployments Pod are distributed across Node, and each Node may run several copies. The difference with DaemonSet is that at most one copy can be run on each Node. 3. Run a web service and run a pod on each node. [root@master ~] # vim daemonset.yamlkind: DaemonSetapiVersion: extensions/v1beta1metadata: name: test-dsspec: template: metadata: labels: name: test-dsspec: containers:-name: test-ds image: httpd execute [root@master ~] # kubectl apply-f daemonset.yaml to check [root@master ~] # kubectl get ds

Summary 1) summarize the characteristics and usage scenarios of RC, RS, Deplyment and DaemonSet controllers. Introduction and usage scenario of Replication Controller (RC)

Replication Controller abbreviated as RC,RC is one of the core concepts in Kubernetes system. To put it simply, RC can guarantee the number of copies of Pod running at any time and ensure that Pod is always available. If the actual number of Pod is more than the specified, then end the excess, if the actual number is less than the specified, start some new Pod, when the Pod fails, is deleted or hung up, RC will automatically create a new Pod to ensure the number of copies, so even if there is only one Pod, we should use RC to manage our Pod.

The main function is to ensure the number of pod: RC is used to manage the number of Pod running normally. A RC can be composed of one or more Pod. After the RC is created, the system will create the number of Pod based on the defined number of copies. During operation, if the number of Pod is less than defined, the stopped or redistributed Pod will be restarted, otherwise the excess will be killed. Make sure the pod is healthy: when the pod is unhealthy, runs wrong, or fails to provide services, RC will also kill the unhealthy pod and recreate the new one. Auto scaling: during peak or trough periods of business, you can use RC to dynamically adjust the number of pod to improve resource utilization. At the same time, configure the corresponding monitoring feature (Hroizontal Pod Autoscaler) to automatically obtain the overall resource usage of the RC associated pod from the monitoring platform, so as to achieve automatic scaling. Rolling upgrade: rolling upgrade is a smooth upgrade way, through the gradual replacement strategy to ensure the stability of the overall system, in the initialization of the upgrade can timely find and solve the problem, to avoid the expansion of the problem. Replication Set (RS)

RC, which is considered to be an "upgraded version". RS is also used to ensure that the number of pod matching label selector is maintained in the desired state.

In fact, the functions of RS and RC are basically the same. the only difference at present is that RC only supports equality-based selector (env=dev or app=nginx), but RS also supports set-based selector (version in (v1, v2)), which is very convenient for complex operation and maintenance management.

Most of the commands on RC in the kubectl command line tool also apply to our RS resource objects. However, we rarely use RS alone, and it is mainly used by Deployment, a higher-level resource object, unless users need custom upgrade features or no need to upgrade Pod at all. In general, we recommend using Deployment instead of Replica Set.

The difference is that

1. RC only supports equation-based selector (env=dev or environment), but RS also supports new, set-based selector (version in (v1.0, v2.0) or env notin (dev, qa)), which is convenient for complex operation and maintenance management.

2. Upgrade mode

RS cannot use kubectlrolling-update for upgrades kubectlrolling-update is specifically for rcRS upgrades deployment or kubectl replace commands the community to introduce this API is intended to replace RC in vl, that is, when the v1 version is abandoned, RC completes its historical mission, and RS takes over its work DaemonSet1. Features:

If the pod must be run on one or more fixed nodes, and should take precedence over other pod startup. In general, each node is run by default, and only one pod can be run. In this case, the DeamonSet resource object is recommended.

A DaemonSet object ensures that the Pod it creates runs a copy on each (or specified) Node in the cluster. If a new Node,DaemonSet is dynamically added to the cluster, the Pod will also be added to run on the newly joined Node. Deleting a DaemonSet also cascades and deletes all the Pod it creates.

two。 Use environment monitor program; log collector; cluster storage program; Deployment1. What is Deployment?

Kubernetes Deployment provides official methods for updating Pod and Replica Set (the next generation Replication Controller). You can only describe the ideal state you expect (expected running state) in the Deployment object, and the Deployment controller transforms the actual state into your desired state for you. For example, if you want to upgrade all webapp:v1.0.9 to webapp:v1.1.0, you just need to create a Deployment,Kubernetes that will automatically upgrade according to Deployment. Now you can use Deployment to create new resources (pod,rs,rc), replace existing resources, and so on.

You only need to describe the desired goal state in Deployment, and Deployment controller will help you change the actual state of Pod and Replica Set to your goal state. You can define a new Deployment, or you can create a new one to replace the old Deployment.

two。 A typical use case uses Deployment to create a ReplicaSet. ReplicaSet creates a pod in the background. Check the startup status to see if it succeeds or fails. Then, declare the new state of the Deployment by updating the Pod's PodTemplateSpec field. This creates a new ReplicaSet,Deployment that moves the pod from the old ReplicaSet to the new ReplicaSet at a controlled rate. If the current state is unstable, roll back to the previous Deployment revision. The revision of Deployment is updated with each rollback. Expand Deployment capacity to meet higher load. Pause Deployment to apply multiple fixes for PodTemplateSpec, and then come back online. Judge whether the online hang resides according to the status of Deployment. Clean up old and unnecessary ReplicaSet. 3. Use environment

Deployment integrates features such as online deployment, rolling upgrade, creating replicas, suspending online tasks, resuming online tasks, and rolling back to a previous version (successful / stable) of Deployment. To some extent, Deployment can help us achieve unattended launch, greatly reducing the complex communication and operational risks of our launch process.

Define Deployment to create Pod and ReplicaSet rolling upgrades and rollback applications to expand and reduce capacity pause and resume Deployment3. The difference between DaemonSet and Deployment the replicas of Deployment deployments Pod are distributed across Node, and each Node may run several copies. The difference with DaemonSet is that at most one copy can be run on each Node. 2) use the DaemonSet controller to run the httpd service, requiring the name to be named under its own name. The tag is: tier=backend,env=dev. [root@master ~] # vim daemonset.yaml kind: DaemonSetapiVersion: extensions/v1beta1metadata: name: xgp-dsspec: template: metadata: labels: tier: backend env: dev spec: containers:-name: xgp-ds image: httpd check out [root@master ~] # kubectl get pod-- show-labels

[root@master] # kubectl get pod-L env,tier

3) create a service resource object to associate with the above resources, with verification. [root@master ~] # vim service.yaml kind: ServiceapiVersion: v1metadata: name: servicespec: type: NodePort selector: env: dev ports:-protocol: TCP port: 90 targetPort: 80 nodePort: 30123 execute [root@master ~] # kubectl apply-f service.yaml to check [root@master ~] # kubectl describe svc

Visit [root@master ~] # curl 127.0.0.1purl 30123

4) what is the use of tidying up about tags and tag selectors?

Tags: solve the same type of resource objects, for better management, grouped according to tags.

Tag selector: query filter criteria for tags.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.