Lable Kubernetes basic concepts and terminology sum Replication Controller

1.Kubernetes of labels Lable

Lable is a central concept in kubernetes, a lable is a key = value of key-value pairs, key and value specified by the user, can be attached to various lable resource objects, e.g. Node, Pod, Service, RC, etc., a resource object can define any number of Lable, also can be added to any number of resource objects up with a Lable, Lable usually determined when the resource object definition, can also be dynamically added or removed after the object is created.

Can be achieved by binding to a resource object or a plurality of different packet resource management Lable multidimensional, e.g., deploy different versions of the application to different environments; or monitoring and analysis applications (logging, monitoring, alarm) Wait. Some common examples of tags as follows:

  1. Version label "release": "stable", "release": "canary". . . . .
  2. Environmental label "environment": "dev", "environment": "production"
  3. 架构标签   "tier":"frontend","tier":"backend","tier":"middleware"
  4. Partition label "partition": "customerA" ....
  5. Quality control tag "track": "daily", "track": "weekly"

To define a resource object Lable gave him the equivalent of a label, then you can query and filter have some Lable resource object through Lable Selector (tag selector), kubernetes achieve a SQL-like query objects in this way mechanism. Lable Selector equivalent to where the query in SQL, currently there are two kinds of expressions Lable Selector: Based on the equation (equality-based) and based on a set (set-based) of.

The former uses "equation based" matching tag expression, the following example:

  1. name = redis-slave: Match all resource object having a label name = redis-slave of
  2. ! Env = production: object does not have the resources to match all tags env = production of

The latter set of operations using expression matching tag, the following example:

  1. name in (redis-master, redis-slave): match all resource object having a label name = redis-master or the name = redis-slave
  2. name not in (mysql-backend): resource object does not have to match all the label name = mysql-backend of

Can be achieved by combining a plurality of lable selector complex conditional expressions selection, multiple expressions with a comma "," can be separated, the relationship "AND" between several conditions, i.e., a plurality of conditions are satisfied , the following example:

  1. name=redis-master,env!=production
  2. name in (redis-master,redis-slave),env!=production

Usually, we give a definition of a Pod lable, as follows:

apiVersion: v1

kind: pod

metadata:

   name:  myweb

   lables:

      app:  myweb

RC and Service Management Objects associate in the spec defined Selector and Pod:

apiVersion: v1

kind:   ReplicationController

metadata:

   name:  myweb

spec:

  replicas:  1

  selector:

      app:  myweb

 

 

apiVersion: v1

kind:   Service

metadata:

   name:  myweb

spec:

  selector:

      app:  myweb

  ports:

  - port:  8080

The managed object emerging Deployment, ReplicaSet, DaemonSet Job where you can use a set of filter criteria defined based on the selector, as follows:

selector:

   matchLables:

       app: myweb

   matchExpressions:

       -  {key: tier,operator: In,values: [frontend]}

matchLables for defining a set of the Lable, direct write Selector same role, matchExpressions used to define a set of filtering criteria based on the set of available condition operators include: In, NotIn, Exists, DoesNotExist

If both matchLables and matchExpressions, the two sets of conditions for the "AND" relationship, need to be met to complete the screening selector.

Lable selector in kubernetes in several important usage scenario has the following:

  1. kube-controller process to filter the number of copies to be monitored Pod Lable Selector defined by the resource object RC, in order to achieve the number of copies Pod consistently meet expectations set by automatic flow control
  2. kube-proxy process to select the corresponding via Lable Selector Service of the Pod, to automatically establish the corresponding request for each Service Pod forwarding routing table, enabling intelligent load balancing mechanism of Service
  3. By defining specific Lable some Node, and use NodeSelector this label in the Pod scheduling policy definition file, kube-scheduler process can be "directed scheduling" feature to achieve Pod

2.Kubernetes之Replication Controller

Replication Controller in kubernetes referred to in RC, it is actually the definition of a desired scene, that is, the number of copies of certain Pod statement at any time in line with an expected value, including the following values:

  1. Pod expected number (replicas) copy
  2. Lable Selector target for the screening of Pod
  3. When the number of copies Pod is less than the expected number, the template used to create new Pod (template)

When we define a number of the RC and submitted to kubernetes, Controller Manager components on the Master node to be notified, regular inspection system currently viable target Pod, and that the target Pod example of exactly equal to the value of replicas, if more than this value, the system will be stopped some of the Pod, the less it will create some Pod. It can be said, by RC, kubernetes user applications to achieve high availability cluster, reducing the operation and maintenance of many manual operations

We can dynamically zoom Pod number of instances, kubectl scale RC command provides this functionality for us

kubectl scale rc redis-slave --replicas=3

It should be noted that the deletion will not affect the RC and RC already created by the Pod, to remove all the Pod, you can set the replicas is 0, then updates the RC. In addition kubectl provides stop and delete commands to delete all Pod RC and RC-time control

RC also provides a smooth upgrade the user application functions, such as the current system has 10 older versions of Pod needs to be updated to the new version, the best way is to stop every time an old version of Pod, to create a new version of Pod, a few minutes after when all the Pod is a new version of the upgrade is complete, the user will not feel any effects of the business, this is referred to kubernetes in a "rolling upgrade."

 

Guess you like

Origin www.cnblogs.com/lemon-dog/p/12417048.html