label in kubernets

1.The function of Label

 Label is not a resource object in kubernets. It is a label used to attach to various resource objects. These resource objects can be: Node, Pod, Service, RC, etc. Multi-dimensional resource grouping management functions can be implemented by bundling one or more different Labels with specified resource objects, so that resource allocation, scheduling, configuration, deployment and other management tasks can be performed flexibly and conveniently.

2. Definition of Label

 A Label is a key-value pair with key=value, and the key and value are specified by the user. A resource object can define any number of Labels, and the same Label can be added to any number of resource objects. Label is usually determined when the resource object is defined, and can also be dynamically added or deleted after the object is created.

3. How to use Label

 Defining a Label for a resource object is equivalent to giving it a label. Then you can query and filter resource objects that have certain Labels through **Label Selector**.

3.1 Usage scenarios of LabelSelector in kubernets

  • The kube-controller process filters the number of Pod copies to be monitored through the Label Selector defined on the resource object RC, so that the number of Pod copies always conforms to the fully automatic control process set as expected.
  • The kube-proxy process selects the corresponding Pod through the Label Selector of the Service, and automatically establishes a request forwarding routing table for each Service to the corresponding Pod, thereby realizing the intelligent load balancing mechanism of the Service.
  • By defining specific Labels for certain Nodes and using the label scheduling strategy NodeSelector in the Pod definition file, the kube-scheduler process can implement the features of Pod-directed scheduling.

3.2 LabelSelector expression

 Label Selector can be compared to the where query condition in a SQL statement, for example, name=nginx. When this Label Selector is applied to a Pod, it can be compared to a statement such as select * from pod where pod's name ='nginx'. There are currently two types of Label Selector expressions: Equality-based and Set-based.

  1. Use equality expressions to match tags. Here are some specific examples:
  • name=redis-slave: Matches all resource objects with the label name=redis-slave.
  • env!=production: Matches all resource objects that do not have the label env=production. For example, env=test is one of the labels that meets this condition.
  1. Use set operation class expressions to match tags. Here are some specific examples:
  • name in (redis-master, redis-slave): matches all resource objects with the label name=redis-master or name=redis-slave
  • name not in (php-frontend): Matches all resource objects that do not have the label name=php-frontend.
    Complex condition selection can be achieved by combining multiple Label Selector expressions. Multiple expressions can be separated by ",". There is an "AND" relationship between several conditions, that is, multiple conditions are met at the same time.

4. Label usage examples

  1. For Pod objects, Label is defined in its metadata:
apiVersion: v1
kind: Pod
metadata: 
  name: myweb
  labels:
    app: myweb
  1. Other management objects such as Deployment, StatefulSet, DaemonSet and Job can define labels in the Selector and associate pods in the template:
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql 
spec:
  replicas: 1
  serviceName: mysql
  selector:
    matchLabels:
      app: mysql #符合目标的Pod拥有此标签
  template: #此模板创建pod的副本
    metadata:
      labels:
        app: mysql #pod副本拥有的标签,对应selector
  1. To manage Deployment, StatefulSet, DaemonSet and Service, set the Label that needs to be associated with the Pod through the Selector field:
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  selector:
    app: mysql
    ports:
    ......  
  1. matchLabels is used to define a set of Labels, which has the same effect as writing it directly in the Selector; matchExpressions is used to define a set of filtering conditions based on the set. Available condition operators include In, NotIn, Exists, and DoesNotExist. If matchLabels and matchExpressions are set at the same time, the two sets of conditions are AND relationships, that is, all conditions need to be met at the same time to complete the Selector filtering.
selector:
  matchLabels:
    app: myweb
  matchExpressions:
    - {
    
    key: tier,operation: In,values:{
    
    frontend}}
    - {
    
    key: environment,operation: NotIn,values:{
    
    dev}}

Guess you like

Origin blog.csdn.net/Ethin_l/article/details/131732695