Kubernetes不知道你的pod里运行着什么，也不知道你的请求里有什么，你的建议（几乎）没有直接的支持。
您可以查找的更一般的主题是 leader election。在您的示例中，集群领导者是唯一可以执行taskA的人。ZooKeeper通常用于此;有一种叫做Raft的新算法也可以工作。
在Kubernetes中最接近的是StatefulSet。StatefulSet的有用特性是它的副本从0开始编号，因此pod可以查看自己的主机名并确定它是哪一个。如果编号较小的pod失败，Kubernetes将使用相同的标识重新启动它。您可以设置规则，只有pod 0可以执行taskA。这在实践中可能满足您的要求。

在研究了大卫的答案后，我发现Kubernetes博客推荐了一种领导人选举的方法：
https://kubernetes.io/blog/2016/01/simple-leader-election-with-kubernetes/
从那时起，新的文章已经出现了改进的算法，但他们仍然是基于原来的技术，根据这篇文章：
https://medium.com/hybrid-cloud-hobbyist/leader-election-architecture-kubernetes-32600da81e3c
看起来您必须为此复制一些代码或添加一个新的外部依赖项。

扩展Malgorzata的答案，你可以让一个单独的单示例应用通过向主应用发出HTTP请求来启动任务，或者通过向像Kafka这样的消息队列系统发布消息来启动任务，希望不需要与主应用复制或共享太多代码/配置。将它与主应用一起部署可能会产生一些设置成本。
在我的情况下，我需要一个任务来扫描FTP目录，并把新发现的文件名到Kafka，我意识到我的公司支持融合Kafka连接器，所以我能够只使用它代替。
如果你愿意实现的话，领导者选举看起来更健壮--不需要一个逻辑上属于主应用的单独组件，并且有一个单独的pod，这个pod可能会宕机，需要很长时间才能重新启动，也就是说，单点故障。

据我所知，我认为你应该使用ReplicaSet。
您应该创建两个ReplicaSet，第一个用于任务A，第二个用于任务B。
ReplicaSet是用字段定义的，这些字段包括指定如何标识它可以获取的Pod的选择器、指示它应该维护多少Pod的复制品的数量和一个Pod模板，该模板指定为满足副本数量标准而应创建的新Pod的数据。ReplicaSet然后通过根据需要创建和删除Pod以达到所需数量来实现其目的。当ReplicaSet需要创建新的Pod时，它会使用其Pod模板。
ReplicaSet与其Pod之间的链接是通过Pod的metadata. ownerReferences字段实现的，该字段指定当前对象的所有者。ReplicaSet获取的所有Pod在其ownerReferences字段中都有其所属ReplicaSet的标识信息。ReplicaSet正是通过此链接了解其所维护的Pod的状态并进行相应的计划。
ReplicaSet使用其选择器标识要获取的新Pod。如果Pod没有OwnerReference或OwnerReference不是Controller，并且它与ReplicaSet的选择器匹配，则该ReplicaSet将立即获取该Pod。
ReplicaSet负责在任何给定时间运行指定数量的Pod副本。
下面是ReplicaSet的简单yaml配置文件：

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