# Adding a resolver causes cluster to become non-reconciled

**URL:** <https://forums.foundationdb.org/t/adding-a-resolver-causes-cluster-to-become-non-reconciled/2971>\
**Category:** Kubernetes Operator\
**Tags:** performance, operator\
**Created:** [October 28, 2021, 2:11pm UTC](https://forums.foundationdb.org/t/adding-a-resolver-causes-cluster-to-become-non-reconciled/2971 "2021-10-28T14:11:58Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![tangerine](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/tangerine/32/1084_2.png) [@tangerine](https://forums.foundationdb.org/u/tangerine)\
**Post date:** [October 28, 2021, 2:11pm UTC](https://forums.foundationdb.org/t/adding-a-resolver-causes-cluster-to-become-non-reconciled/2971/1 "2021-10-28T14:11:59Z")

</div>

HI,  
Whenever we expand our cluster to add a new resolver pod to the cluster, the cluster has become non-reconciled and unstable. Is there a particular requirement on how many resolver and cpu/memory resource requirement to that resolver pod?  
foundationdb:  
cluster:  
process\_counts:  
cluster\_controller: 1  
proxy: 3  
resolver: 1  
stateless: -1  
storage: 6

But if we reduce the proxy. to 2, the cluster is ok, so why this strange behaviour?

---

<div class="post-metadata">

**Author:** ![john\_brownlee](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/john_brownlee/32/22_2.png) [@john\_brownlee](https://forums.foundationdb.org/u/john_brownlee)\
**Post date:** [October 28, 2021, 3:15pm UTC](https://forums.foundationdb.org/t/adding-a-resolver-causes-cluster-to-become-non-reconciled/2971/2 "2021-10-28T15:15:48Z")

</div>

It’s hard to say without more context on why the reconciliation is not completing. If reducing another process count helps, it could be that your Kubernetes cluster doesn’t have enough resources for the new resolver process.

---

<div class="post-metadata">

**Author:** ![john\_brownlee](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/john_brownlee/32/22_2.png) [@john\_brownlee](https://forums.foundationdb.org/u/john_brownlee)\
**Post date:** [October 28, 2021, 3:21pm UTC](https://forums.foundationdb.org/t/adding-a-resolver-causes-cluster-to-become-non-reconciled/2971/3 "2021-10-28T15:21:54Z")

</div>

Ignore my previous message; I forgot something more critical. The `resolver` field in process counts is deprecated, and is known to not work correctly: [fdb-kubernetes-operator/cluster\_spec.md at master · FoundationDB/fdb-kubernetes-operator · GitHub](https://github.com/FoundationDB/fdb-kubernetes-operator/blob/master/docs/cluster_spec.md#processcounts)

---

<div class="post-metadata">

**Author:** ![tangerine](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/tangerine/32/1084_2.png) [@tangerine](https://forums.foundationdb.org/u/tangerine)\
**Post date:** [October 29, 2021, 1:46am UTC](https://forums.foundationdb.org/t/adding-a-resolver-causes-cluster-to-become-non-reconciled/2971/4 "2021-10-29T01:46:41Z")

</div>

I think I have read in another thread that need to use the DatabaseConfiguration spec to do this resolver thing, is that correct?

---

<div class="post-metadata">

**Author:** ![john\_brownlee](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/john_brownlee/32/22_2.png) [@john\_brownlee](https://forums.foundationdb.org/u/john_brownlee)\
**Post date:** [October 29, 2021, 5:09pm UTC](https://forums.foundationdb.org/t/adding-a-resolver-causes-cluster-to-become-non-reconciled/2971/5 "2021-10-29T17:09:20Z")

</div>

The `databaseConfiguration` section does something different, but that may be what you want. `databaseConfiguration` tells the database the number of workers to recruit for each role, whereas `processCounts` tells the operator the number of pods to run for each process class. If you don’t specify `processCounts`, the operator will infer the process counts based on the database configuration, and I think that is the way to go, unless you have a specific requirements that is different from what the operator infers. We have some more information on this in the user manual, in the [Scaling section](https://github.com/FoundationDB/fdb-kubernetes-operator/blob/master/docs/manual/scaling.md).