# Running eck in production best practices

**URL:** <https://discuss.elastic.co/t/running-eck-in-production-best-practices/324248>\
**Category:** Elastic Cloud on Kubernetes (ECK)\
**Created:** [January 30, 2023, 4:00pm UTC](https://discuss.elastic.co/t/running-eck-in-production-best-practices/324248 "2023-01-30T16:00:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![elastic-db-user](https://avatars.discourse-cdn.com/v4/letter/e/e19b73/32.png) [@elastic-db-user](https://discuss.elastic.co/u/elastic-db-user)\
**Post date:** [January 30, 2023, 4:00pm UTC](https://discuss.elastic.co/t/running-eck-in-production-best-practices/324248/1 "2023-01-30T16:00:49Z")

</div>

I am about to go for running multiple Elasticsearch clusters managed by an eck operator on k8 in production. eIasticsearch, kibana, curator and all other deployments are working as expected. I am wondering if there's any best practices/guide for managing eck operator. Sometimes I've noticed that eck operator does ack'ed for new configs changes deploy via k8-cli but eck doesn't do anything until that Elasticsearch cluster is in green state. for example: if k8 nodes goes down and there's no where the new pod can spin up, in this case I might want to reduce Elasticsearch pod count. but the new new es cluster config is deployed eck operator will do nothing until first that es cluster becomes green.

---

<div class="post-metadata">

**Author:** ![andrask](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrask/32/20318_2.png) [@andrask](https://discuss.elastic.co/u/andrask)\
**Post date:** [January 31, 2023, 4:17pm UTC](https://discuss.elastic.co/t/running-eck-in-production-best-practices/324248/2 "2023-01-31T16:17:19Z")

</div>

IMHO, the fundamental issue with operators is the fact that they are generally built with optimal faultless operation in mind and usually can't do anything if an unexpected event happens. Stateful applications, like the Elasticsearch, are especially hard to manage automatically. I suggest you to keep testing the setup with error and edge cases, like you describe. If you feel so you can still make the operator work, then go for it. If it feels awkward that now you have to fight with one more entity to actually do what you expect it to do, then I would urge you to reconsider the utlility of such a solution, or figure out ways how you can override it when necessary.

---

<div class="post-metadata">

**Author:** ![elastic-db-user](https://avatars.discourse-cdn.com/v4/letter/e/e19b73/32.png) [@elastic-db-user](https://discuss.elastic.co/u/elastic-db-user)\
**Post date:** [January 31, 2023, 4:59pm UTC](https://discuss.elastic.co/t/running-eck-in-production-best-practices/324248/3 "2023-01-31T16:59:09Z")

</div>

great points! I agree and I like eck operator compared to deploying es with just sts, and is working fine.its managing couple of Elasticsearch clusters actually. like you said I'll look for ways to override options to get it going. --Thanks for your comments.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [February 28, 2023, 4:59pm UTC](https://discuss.elastic.co/t/running-eck-in-production-best-practices/324248/4 "2023-02-28T16:59:40Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.