Hello everyone! SO today is an exiting day yeah. Now I’m going to share some more of Kubernetes Fundamental concept and object component that you need to know before you’re becoming Kubernetes Administrator. There’s still a lot of things that we need to know, so don’t give up!

Okay in this time, we’re going to discuss Label and Selector also some of the implementation of it that is Service in Kubernetes, that handles the connectivity within the cluster.

Let’s Go!

Label and Selector

Pod with many labels

Label is a property to define whatever you want that attach to each Kubernetes components. While selector is a filter to select what label’s component that you want to show. Here’s the example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
    function: frontend
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 8080

What are the use cases?

  1. You can specify the label to show specific pod, like: kubectl get pods —selector function=frontend

2. Replica Set – to connect replica set with pod

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: new-replica-set
	labels:
    app: busybox
    function: frontend
spec:
  template:
    metadata:
      labels:
        app: busybox
	function: frontend
    spec:
      containers:
      - name: busybox-pod
        image: busybox
  replicas: 4
  selector:
    matchLabels:
      app: busybox

3. Service – there are selector to connect which pod that you want to integrate with.

Services is an object to connect our pod to the other party, it could be a pod, or a user request. Based on how and who’s service work with, it is classified with three kind:

  1. Service NodePort – make an internal pod is accessible from port’s node.
  2. Service ClusterIP – make a virtual IP within a node to connect between different services.
  3. Service LoadBalancer – make a load balancer for our service.

Node Port

Here’s for the logic architecture for where is Node Port location.

The node port has a range from 30.000-32.767 that can we use.

To make a service we need a yaml file manifest :

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  ports:
  - targetPort: 80
    port: 80
    nodePort: 30008
  selector:
    app: MyApp

The selector is referring into the label in your pod.

Make the service using kubectl and after that you can see the service that have been built with : kubectl get service. It automatically assign the pod application that have same label on it with the same port.

Now you can access your application by curl <your-ip>:30008.

Cluster IP

Cluster IP Logic in Cluster within node.

In your application, there’s always be front-end view, back-end part and databases to keep your data persistence. So in order to connect it within the node of your app is use Cluster IP Service interface. Here’s how to make a cluster IP service is :

apiVersion: v1
kind: Service
metadata:
  name: service-db
spec:
  type: ClusterIP
  ports:
  - targetPort: 80
    port: 80
  selector:
    app: MyApp

The selector is referring into the label in your pod.

Make the service using kubectl and after that you can see the service that have been built with : kubectl get service .

Load Balancer

Load Balancer

The load balancer type of service is help you to simplify the node port service access. You understand that node port can be accessible if we use the same port, but that’s gonna make a lot of end point that end user can access, and it make people confused.

So here’s how to make a Load Balancer type of service in a cloud service platform kuberenetes:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  ports:
  - targetPort: 80
    port: 80
    nodePort: 30008

This requirement need to fulfill in GKE, or Kubernetes Cloud Environment. If we use VM in our local machine, we need to do some external configuration like adding MetalLB to our cluster to make the LoadBalancer service work.

4. Annotations – for show version, contact, email id, etc. for any other integration purpose.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: new-replica-set
	labels:
    app: busybox
    function: frontend
	annotations:
	  buildversion: 2.34
...

Okay That’s all for now. This is a very important concept because in production there’s a bunch of component so we need to named it all, to make it everything is going well. So in the next article we’re going to discuss about Scheduling and another important object that very helpful to the cluster.

See you later!!

Last modified: April 22, 2022

Author

Comments

Write a Reply or Comment

Your email address will not be published.