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