Skip to main content

Kubernetes: 8. Labels & Selectors

Labels

  • Labels are a way of grouping the objects
  • While Kubernetes understands the objects it create, it is easier to identify the objects by using custom labels
  • With labels you group the objects by types (Pods, Services, ReplicaSet etc) or by Applications
  • For a pod, labels are defined under the metadata section
Selectors
  • Selectors are used to filter the objects using labels defined on them
  • Using kubectl and selector pods can be listed by filtering on the labels attached to them
  • If a Selector has multiple labels, they are understood as logical AND, which means pods must match all labels.
pod-definition.yaml
apiVersion: v1
kind: Pod
metadata:
    name: myapp-pod
    labels:
        app: myapp
        location: IN

spec:
    containers:
    - name: nginx-container
      image: nginx

kubectl get pods --selector app=myapp 
-> Get pods filtered by labels

kubectl get pods --selector app=myapp,tier=frontend 
-> Get pods filtered by labels app=myapp and tier=frontend

Replica Set
  • Kubernetes also uses labels to build objects.
  • For example take a case of replica set, 
    • Labels under metadata are replicaSet labels
    • labels under template.metadata are pod labels
    • labels under selector.matchLabels are selector labels
  • Kubernetes uses the selector.matchLabels to identify which pods have to be created as defined in spec.template by matching it with spec.template.metadata.labels

replica-set-definition.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: myapp-rs
    labels:
        app: myapp
        type: front-end

spec:
    template:
        metadata:
            name: myapp-pod
            labels:
                app: myapp
                type: front-end
            spec:
                containers:
                - name: nginx-container
                  image: nginx


    replicas: 3
    selector:
        matchLabels:
            type: front-end

Service
  • For a Service object Kubernetes matches the labels defined under spec.selector to metadata.labels as defined under pod-definition file
apiVersion: v1
kind: Service
metadata:
    name: myapp-rs
    labels:
        app: my-svc-app

spec:
    selector:
        app: myapp
    ports:
    - protocol: TCP
      port: 8080
      targetPort: 9376

Annotations
  • Annotations though sound similar to labels are to be used to store the custom information specific to object
  • With labels, you can use them to group objects or filter them with selectors
  • Annotations are custom information about the object
pod-definition.yaml
apiVersion: v1
kind: Pod
metadata:
    name: myapp-pod
    labels:
        app: myapp
        location: IN
    annotations:
        buildVersion: 1.34
        contact: am@memories.com

spec:
    containers:
    - name: nginx-container
      image: nginx
Labels:

Comments

Post a Comment

Popular posts from this blog

Azure Active Directory

Azure Active directory (AAD) is a Identity as a Service. This is a smaller subset of Active directory. This is not a replacement to active directory at all. Azure active directory provides the identity services to the mobile apps and web apps in Private cloud. These apps may be connected to on-premise applications. So an SSO is enabled for these apps. So Azure active directory has very simple functionality. Create Users, Groups. Map groups to network security groups and provide the authentication to the resources. When you login to Azure portal, right upper corner of the screen has username along with the domain. Domain or tenant or organization are used interchangeably. Management of Users and Groups: Cloud identity (create users manually)  Directory synchronized identifiers (users are synchronized)  Add users Adding a cloud identity users makes the user as Guest When you do directory synchronization on Premise AD Groups are synched up wi...
Post a Comment
Read more

Kubernetes: 18. Rollout and Rollback

Deployment When a deployment is created, it triggers a rollout Rollout creates a new revision (version) In the future when new deployment is created,  a new rollout is created The new rollout creates one more "new" version These versions help to keep track of the changes and rollback if necessary Deployment Strategy First strategy is delete and recreate strategy.  Delete all the existing pods and deploy the new updated pods But this comes with application downtime Second strategy and default strategy is Rolling update strategy Kubernetes deletes one pod at a time in the older version and in its place creates a one pod at a time in the newer version Update Strategy Updates can be many things like updating the labels, docker image, replicas etc These are directly updated into the deployment file and the changes are applied When the changes are applied using kubectl apply command, a new rollout and a new revision is created Another way to update the image name is to use the kube...
Post a Comment
Read more

Kubernetes: 19. Configure Application

Configuring application consists of Configuring commands and arguments on applications Configuring environment variables Configuring secrets Docker Commands docker run ubuntu  -> Runs ubuntu container and exit, container CMD is set to [bash], so the container quitely exits docker run ubuntu echo "Hello World" -> Runs ubuntu container, prints "Hello World" exits quitely. To update the default settings, create your own image from the base image lets call this ubuntu-sleeper image FROM ubuntu CMD sleep 5 CMD can also be mentioned in the JSON format like CMD ["sleep", "5"] Note that with JSON format the first element should always be the command to execute,  for eg, it CANNOT be ["sleep 5"] Run build the new ubuntu-sleeper image and run the new image docker build -t ubuntu-sleeper .  -> Build the image docker run ubuntu-sleeper -> Run the new image So the new image will launch ubuntu container, sleep for 5 seconds and quitely ex...
Post a Comment
Read more