release下载失败

[YourException]

下载提示：下载该任务需要登录此站点，无法下载应用程序，window版本。

[alex-zaitsev]

Try podGenerateName:

apiVersion: "clickhouse.altinity.com/v1"
kind: "ClickHouseInstallation"
metadata:
  name: "pod-generate-name"
spec:
  configuration:
    clusters:
      - name: shard1-repl1
        templates:
          podTemplate: clickhouse-pod-template
        layout:
          shardsCount: 1
          replicasCount: 1
  templates:
    podTemplates:
      - name: clickhouse-pod-template
        generateName: "chi-{chi}-{cluster}-{host}"
        spec:
          containers:
            - name: clickhouse-pod
              image: clickhouse/clickhouse-server:22.3
              volumeMounts:
                - name: clickhouse-storage-template
                  mountPath: /var/lib/clickhouse

But cluster name is pretty much hardcoded internally, you are right.

[prashant-shahi]

@alex-zaitsev Any idea on how I can update existing cluster name with the old data in PVCs intact?

[rauanmayemir]

I've just started exploring clickhouse by using CHOP, and the terminology of installation vs cluster really confuses me.

Why wouldn't I want to model clusters by the underlying pods and pvcs? If I don't tie clusters to pods and pvcs, how should I model them? Should 'installation' be the key 'instance'?

I would appreciate any links where this is defined, I can't seem to find a basic explanation of how topology is constructed.

[Slach]

@rauanmayemir installaction could to contain multiple clickhouse clusters look kubectl explain chi.spec.configuration.clusters for details

each clickhouse cluster could contain multiple clickhouse-server pods which could be customized with podTemplates

look

kubectl explain chi.spec.configuration.clusters.layout
kubectl explain chi.spec.defaults.templates
kubectl explain chi.spec.templates.podTemplates
kubectl explain sts.spec.template

each podTemplate could contain multiple volumeClaimTemplate which will render multiple PVC, which you can mount and use in the custom storage_policy

look detals in

kubectl explain chi.spec.templates.podTemplates
kubectl explain chi.spec.templates.podTemplates.spec
kubectl explain chi.spec.templates.volumeClaimTemplates
kubectl explain sts.spec
kubectl explain sts.spec.volumeClaimTemplates
kubectl explain sts.spec.template.spec
kubectl explain sts.spec.template.spec.volumes

and look examples in https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/03-persistent-volume-07-multiple-resizable-volumes-3.yaml

kubectl explain chi.spec.configuration.files and https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-multiple-volumes_configure

[rauanmayemir]

@Slach Thank you for your answer. I know all that, I've followed those examples and have set up an installation with one cluster.

I meant, when would I need to have 1 installation with several clusters as opposed to say several installations with 1 cluster each?

[Slach]

I meant, when would I need to have 1 installation with several clusters as opposed to say several installations with 1 cluster each?

It has no sense, multiple ClickHouseInstallation for one clickhouse-server cluster, and it is not trivial to achieve it (but possible in theory).

Usually, in a most of the cases you will use only one ClickHouseInstallations for each clickhouse-server cluster

[rauanmayemir]

Several installations with 1 cluster each. But I'm guessing installation is essentially a tenant.

Usually, in a most of the cases you will use only one ClickHouseInstallations for each clickhouse-server cluster

What do you mean? That it is usually not necessary to have several clusters and 1 cluster per installation is enough?

[Slach]

Several installations with 1 cluster each.

This is usual case

But I'm guessing installation is essentially a tenant.

Usually tenant is namespace or even separate kubernetes cluster with several ClickHouseInstallation

That it is usually not necessary to have several clusters and 1 cluster per installation is enough?

Yes, multiple clickhouse-cluster in one installation still create separate statefulsets+pvc+service for each clickhouse-server instance.

But use one CHI for multiple clusters have sense if you want to share some configuration between clsuters and don't want to use ClickHouseInstallationTemplate