Kubernetes Fundamental – Part 3

In Part 1, We have gone through what is Kubernetes and its architecture.

In Part 2, We have gone some of the key components such as Nodes, Namespaces and Pods.

Now in this part, we will go through components such as Service, Job and Ingress.

Service

Service provides an abstraction to define a stable endpoint to access a group of pods. It allows us to expose application to other pods within the cluster or to external clients. It provides load balancing and auto scaling of pods behind them to ensure high availability.

Example

Lets have a look with the similar example that we used in the previous post.

# webapp-with-db-pod-and-service.yaml

apiVersion: v1
kind: Pod
metadata:
  name: webapp-with-db
  labels:
    app: my-webapp
spec:
  containers:
    - name: webapp
      image: nginx:latest
      ports:
        - containerPort: 80
    - name: database
      image: mongo:latest
---
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: my-webapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

• Here, we added a new YAML block to define service : webapp-service .
• The Selector field specifies which pod it targets toward. In this case, it points to the pod with label my-webapp .
• The service exposes port 80 which matches the port expose by webapp container in the pod.
• The targetPort specifies the port on the port that the service forwards traffic to. In this case, it matches the port specified on the containerPort of the webApp container.
• Now we have a service: webapp-service that can be referenced/accessed by other pods within the classes using the name webapp-service .

Job

Job is an object that creates a set of pods and it wait for it to terminate. Once all the pods are terminated, then job will be marked as completes. All failed pods will be retried until certain specified number have exited successfully.

Job provides the mechanism to run ad-hoc tasks within the cluster. Most common use case is to create cronjobs that will automatically run a job at specified time at regular interval to support batch activities, backups and other application related scheduled tasks.

Example

Let us create a simple cronjob that run task every minute.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

• Creates a cronjob : hello
• It run based on the schedule expression. Syntax is as below

In this case, it will run every minute.

• It creates a container : hello. It pulls image from busybox:1.28.
• It will print Hello from the Kubernetes Cluster inside the container pod at every minute.
• Based on restartPolicy, it will restart job in case of any failure.

Ingress

Ingress provides a mechanism to expose our services to the external clients outside the cluster. On contrary to the Services provides internal communication between the pods within the cluster.

It acts as an external entry point to our application and it will manage load balancing and incoming traffic routing rules (HTTP routes). It is also support HTTPS traffic secured by TLS certificates.

In order to make Ingress work, we need to install an Ingress Controller deployed in our Kubernetes Cluster.

Example

# webapp-with-db-pod-service-and-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
spec:
  rules:
    - host: mywebapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp-service
                port:
                  number: 80

• We have created an Ingress object : webapp-ingress.
• The host specifies the domain name: mywebapp.example.com where the application will be accessed externally.
• The path specifies the routing rules to access the application. In this case, / will be forwarded to the service : webapp-service
• The backend specifies the target service : webapp-service behind the cluster to allow the traffic towards.

I hope it makes sense and in the part we will go through ConfigMap, Secret, Volume, Deployment and Statefulset component.

Happy Containerising 🙂