Labels, selectors, Replication controller

Labels, selectors, Replication controller

Labels and selectors:

- Labels are the mechanism you use to Organise Objects
- Labels is a Key-Value pair without any pre-defined meaning that can be attached to the objects
- Labels are similar to tags in AWS or git where you use name to qiuck references
- So you are free to choose labels as you need it to refer an environment which is used for dev or testing or production , refer a product group like Department A, Department B
- Multiple labels can be added to a single object
- eg. vi pod5.yml

kind: Pod
apiVersion: v1
metadata:
name: delhipod
labels:
env: development
class: pods
spec:
containers:
- name: c00
image: ubuntu
command: ["/bin/bash", "-c", "while true; do echo Hello-Shishir; sleep 5 ; done"]

- kubectl apply -f pod5.yml
- kubectl get pod5 --show-labels

Now , if you want to add a label to an existing pod
- kubectl label pods delhipod myname=Shishir
- kubectl get pods --show-labels
Now, list pods matching a label
- kubectl get pods -l env=development
Now, give a list, where 'development' label is not present
- kubectl get pods -l env!=development
Now, if you want to delete pod using labels
- kubectl delete pods -l env!=development
- kubectl get pods

Labels-Selectors:

- Unlike name/UIDs, labels do not provide uniqueness, as in general, we can expect many objects to carry the same label
- Once the labels are attached to an object, we would need filter to narrow down and these are called as label selectors
- The api currently supports two types of selectors - equally based and set based
- A label selector can be made of multiple requirements which are comma-separated
Equality Based (= , != )
eg. name: Shishir
class: nodes
project: development

Set Based: (in, notin, and exist)

env in for (production, dev)
env notin for (team1, team2)
- kubernetes also supports , set-based selectors, i,e. match multiple values.
- kubectl get pods -l 'env in(development,testing)'
- kubeclt get pods -l 'env notin(development,testing)'
- kubectl get pods -l class=pods, myname=Shishir

Node-Selector:

- One use case for selceting labels is to constrain the set of nodes onto which a pod can schedule. i,e . you can tell a pod to only be able to run on particular nodes.
- Generally such constraints are unnecessary, as the schedular will automatically do a resonable placement, but on certain circumstances we might need it.
- We can use labels to tag nodes.
- if the nodes are tagged, you can use the label selector to specify the pods it run only on the specific nodes.
- first we give label to the node
- Then use node selector to the pod configuration
- vi pod1.yml

kind: Pod
apiVersion: v1
metadata:
name: nodelabels
labels:
env: development
spec:
containers:
- name: c00
image: ubuntu
command: ["/bin/bash", "-c", "while true; do echo Hello-Shishir; sleep 5 ; done"]
nodeSelector:
hardware: t2-medium

Scaling and Replication:

- kubernetes was designed to orchestrate multiple containers and replication.
- Need for multiple Containers/replication helps us with these.

Reliability:
• by having multiple versions of an application, you prevent problems if one or more fails.

Load Balancing:

• Having multiple version of a containers enables you to easily send traffic to different instances to prevent overloading of a single instances or node

Scaling:

• When load does become too much for the number of existing instances
• Kubernetes enables you to easily scale up your application, adding additional instances as needed.
• Rolling updates: Updates to a service by replacing pods one by one.

Replication Controller:

- A replication controller is a object that enables you to easily create multiple pods, then make sure that number of pods always exist.
- If a pod created using RC will be automatically replaced if they does crash, failed, or terminated.
- RC is recommended if you just want to make sure 1 pod is always running, even after system reboots.
- You can run the RC with 1 replica & the RC will make sure the pod is always running

- vi pod2.yml

kind: ReplicationController
apiVersion: v1
metadata:
name: myreplica
spec:
replicas: 2
selector:
myname: Shishir Tambe
template:
metadata:
name: testpod6
labels:
myname: Shishir
spec:
containers:
- name: c00
image: ubuntu
command: ["/bin/bash", "-c", "while true; do echo Hello-Shishir; sleep 5 ; done"]

Replica Set:

• Replica set is a next generation replication controller.
• The replication Controller only supports equlaity-based selector, whereas the replica set supports set-based selector. i,e. filtering according to set of values.
• Replicaset rather than the replication controller is used by other objects like deployment.
eg.vi pod3.yml

kind: ReplicaSet
apiVersion: apps/v1
metadata:
name: myrs
spec:
replicas: 2
selector:
matchExpressions: # these must match the labels
- {key: myname, operator: In, values: [Shishir, Shisir, Shishr]}
- {key: env, operator: NotIn, values: [production]}
template:
metadata:
name: testpod7
labels:
myname: Shishir
spec:
containers:
- name: c00
image: ubuntu
command: ["/bin/bash", "-c", "while true; do echo The beatles; sleep 5 ; done"]

Did you find this article valuable?

Support Shishir Tambe by becoming a sponsor. Any amount is appreciated!