0
votes

I have a java application that runs inside a Kubernetes pod.

The application performs several tasks (taskA, taskB, etc.). The application supports running multiple instances in different pods. All the pods are doing the same tasks.

However, there is a task that should only be done by only one of the pods (e.g. taskA should only run in one of the pods). And if the pod that is performing the specific task dies, one of the other nodes should start doing that task (passive node, with regards to taskA, takes over).

Is there some support for this feature in k8s, or do I need use some other service (e.g. zookeeper)?

2
what is a task in your case? batch job? serving some specific endpoint? other?morgwai

2 Answers

0
votes

Kubernetes doesn't know what's running inside your pods or what's inside your requests. There's (almost) no direct support for what you're suggesting.

The more general topic you might look up is leader election. In your example, the cluster leader is the only one who can perform the taskA. ZooKeeper is popularly used for this; there's a newer algorithm called Raft that can work too. You'd have to write support for this into your application.

The closest thing in Kubernetes is a StatefulSet. The helpful feature of a StatefulSet is that its replicas are numbered starting from 0, so a pod can look at its own hostname and figure out which one it is. If a lower-number pod fails then Kubernetes will restart it with the same identity. You could set the rule that only pod 0 could perform taskA, which in practice might meet your requirements.

0
votes

As far as I understand I think you should use ReplicaSet.

You should create two ReplicaSet, first one for task A, and second one for task B.

A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods it should create to meet the number of replicas criteria. A ReplicaSet then fulfills its purpose by creating and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod template.

The link a ReplicaSet has to its Pods is via the Pods’ metadata.ownerReferences field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning ReplicaSet’s identifying information within their ownerReferences field. It’s through this link that the ReplicaSet knows of the state of the Pods it is maintaining and plans accordingly.

A ReplicaSet identifies new Pods to acquire by using its selector. If there is a Pod that has no OwnerReference or the OwnerReference is not a Controller and it matches a ReplicaSet’s selector, it will be immediately acquired by said ReplicaSet.

A ReplicaSet is responsible for running specified number of pod replicas at any given time.

Here is simple yaml configuration file for ReplicaSet:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: example
  labels:
    app: guestbook
    tier: eg
spec:
  replicas: 1 #provided appreciated amount of replicas
  selector:
    matchLabels:
      tier: eg
  template:
    metadata:
      labels:
        tier: eg
    spec:
      containers:
      - name: php
        image: gcr.io/google_samples/gb-frontend:v3