https://signoz.io logo
Join Slack
Powered by
This message was deleted.
# support
s
This message was deleted.
a
@Prashant Shahi can you help here?
p
Hi @Robert Winter 👋
What's the recommended approach?
If possible, it would be best to keep SigNoz and ClickHouse isolated in a separate K8s cluster.
without installing the ClickHouse operator (which we have installed already) - is this possible? That feels like it would be ideal?
yes, it is possible. However, there are multiple changes that you would need to do to your existing cluster as stated in the external clickhouse guide. You will also need to version match the operator and the clickhouse server.
Run both operators in parallel - not sure if that has any other consequences?
Your existing clickhouse operator might be using 
ClusterRole
and 
ClusterRoleBinding
, you will need to use 
Role
and 
RoleBinding
instead.
r
Hey thanks a lot!
I think I'll try to run 2x clickhouse operators and 2x clickhouse clusters (our original + signoz) in the same k8s cluster . When I quickly tried just installing the signoz helm chart with the default settings it at least managed to install both the operator and clickhouse cluster in the platform namespace without any obvious problems - not sure how it could affect our other workloads that uses the other clickhouse cluster though.
p
not sure how it could affect our other workloads that uses the other clickhouse cluster though.
As stated in previous message, you will need to use 
Role
and 
RoleBinding
instead for your clickhouse operator. That will keep the scope of your clickhouse operator to its own namespace. Otherwise, your existing clickhouse operator might make multiple periodic attempts to communicate to SigNoz-managed CHI pods.
👆 1
👍 1
r
Thanks @Prashant Shahi, I'll give it a go. Just a follow-up question on your answer below to clarify if option (1) is possible:
Install a ClickHouse instance through the SigNoz helm chart without installing the ClickHouse operator (which we have installed already) - is this possible?
yes, it is possible. However, there are multiple changes that you would need to do to your existing cluster as stated in the external clickhouse guide. You will also need to version match the operator and the clickhouse server.
Is there a setting in the signoz or clickhouse values.yaml files allows me to disable installing the clickhouse operator but still install ClickHouse using my existing clickhouse-operator? I see I can disable installing clickhouse but I didn't find a similar setting for skipping installing the operator?
p
Setting 
clickhouse.enabled
to 
false
should disable the clickhouse dependency chart i.e both operator and clickhouse installation.
Otherwise, your existing clickhouse operator might make multiple periodic attempts to communicate to SigNoz-managed CHI pods.
also, this is not a major issue, when it comes to functionality-wise. But it makes many unnecessary network calls and you will see lots of error logs in your existing operator pod.
r
Ok thanks! Then option (1) is out the window I guess as I can't use the signoz chart to install just the clickhouse cluster but not the operator
Hey @Prashant Shahi thanks for your help. I run the altinity-clickhouse-operator 0.21.3 in my cluster. I started to look into this again and I couldn't find a setting where I could make the operator run with just a cluster role. I think it always provisions this clusterrolebinding:
Copy code
❯ kubectl get <http://clusterrolebindings.rbac.authorization.k8s.io|clusterrolebindings.rbac.authorization.k8s.io> | grep altinity
clickhouse-operator-altinity-clickhouse-operator                  ClusterRole/clickhouse-operator-altinity-clickhouse-operator
I'm not sure that blocks the SigNoz clickhouse-operator though as it seems to work fine anyways? Based on this comment would it be enough you think to set my existing ClickHouse operator to only look in my existing namespaces?
Copy code
# Concurrently running operators should watch on different namespaces.
        namespaces: ["myexistingnamespacewithclickhouse"]
p
Based on this comment would it be enough you think to set my existing ClickHouse operator to only look in my existing namespaces?
``` # Concurrently running operators should watch on different namespaces.
namespaces: ["myexistingnamespacewithclickhouse"]```
seems like it. However, I cannot say for certain without testing out the complete set up with two different operators and respective CHIs.
94 Views
Open in Slack
PreviousNext
Powered by