ClickHouseCluster 구성
기본 구성
레플리카와 세그먼트
- 레플리카: 세그먼트당 ClickHouse 인스턴스 수(고가용성을 위해)
- 세그먼트: 수평 파티션 수(스케일링을 위해)
replicas: 3 및 shards: 2로 구성된 클러스터는 총 6개의 ClickHouse 파드를 생성합니다.
Keeper 통합
모든 ClickHouse 클러스터는 클러스터 조정을 위해 Keeper 앙상블이 필요합니다.keeperClusterRef와 externalKeeper 중 정확히 하나만 설정하십시오. 둘 다 설정하거나 둘 다 설정하지 않은 클러스터는 거부됩니다.
keeperClusterRef에는 이 연산자가 관리하는 KeeperCluster를 지정하십시오:
keeperClusterRef.namespace가 설정되면 연산자는 두 네임스페이스를 모두 감시해야 합니다. WATCH_NAMESPACE가 구성되어 있다면 해당 목록에 ClickHouse와 Keeper 네임스페이스를 모두 포함하십시오.
외부에서 관리되는 Keeper
연산자가 관리하지 않는 Keeper 앙상블(ensemble)에 ClickHouse를 연결하려면externalKeeper를 사용하십시오.
다른 연산자가 소유한 앙상블, 다른 Kubernetes 클러스터나 가상 머신 또는
베어 메탈에서 실행되는 앙상블, 여러 시스템이 공유하는 앙상블 등이 이에 해당합니다.
port의 기본값은 9181입니다. host에는 DNS 이름 또는 IP 주소를 지정하며, IPv6 주소는 대괄호로
묶어야 합니다. TLS로 연결하려면 tls: Enabled를 설정하고, port에는 앙상블(ensemble)이 보안 연결(secure connection)을
수신 대기하는 포트를 지정하십시오:
caBundle을 기준으로 Keeper 인증서를
검증합니다. 자세한 내용은 TLS를 통한 ClickHouse-Keeper 통신을 참조하십시오.
여러 ClickHouse 클러스터가 하나의 앙상블(ensemble)을 공유한다면 settings.extraConfig로 클러스터마다 고유한 루트 znode를
지정하여 복제 메타데이터, SQL로 정의된 사용자, 이름이 지정된 컬렉션이
서로 충돌하지 않도록 하십시오. znode는 ClickHouse를 시작하기 전에 생성해야 하며, 생성한 후에는 변경하지 마십시오.
zookeeper.root를 settings.extraReloadableConfig에 넣지 마십시오. 설정을 다시 로드하면 실행 중인 클러스터의 루트가 바뀌어
복제된 테이블이 읽기 전용 상태가 됩니다. 루트 znode에 ACL이 설정되어 있다면 클러스터의 keeper-identity가
하위 znode를 생성할 수 있도록 허용해야 합니다.
연산자는 이 서버들을 변경하지 않으며, ClickHouse를 리컨실하기 전에 이 서버들이 준비될 때까지 기다리지도 않습니다.
앙상블(ensemble)의 가용성 유지는 사용자의 책임입니다.
인증은 연산자가 관리하는 Keeper와 동일한 방식으로 동작합니다. 연산자는 클러스터 시크릿(Secret)에서
keeper-identity 키를 읽어 ClickHouse에 전달합니다. 시크릿 구조는
외부 시크릿을 참조하십시오.
KeeperCluster 구성
종료 시 리더십 이양
Keeper 컨테이너에는 기본preStop 후크가 설정되어 있습니다. 이 후크는 레플리카가 중지되기 전에 Raft
리더십을 넘기도록 요청하고, 이양이 완료될 때까지 기다린 후에
컨테이너가 종료되도록 합니다. 이 후크는 연산자가 시작한 롤아웃뿐만 아니라
컨테이너가 정상적으로 중지될 때마다 실행됩니다. 디스케줄러에 의한 축출(eviction), 노드 드레인(drain), 자동 스케일러
동작도 모두 동일한 후크를 트리거합니다. 이 후크는 조정 루프(reconcile loop) 로직이 아니라 큐블릿 수준의 preStop 핸들러이기
때문입니다.
이 후크가 없으면 현재 리더를 재시작할 때 새 선출이 완료될 때까지 앙상블(ensemble)에 리더가 없는 상태가
지속됩니다. 부하가 높을 때는 선출에 수 초가 걸릴 수 있으며, ClickHouse에서는 이것이 Keeper 연결 끊김과 쿼리
지연 시간 증가로 나타납니다. 이 후크는 레플리카에 리더십 양보를 요청한 다음(Keeper의 4글자 명령어 ydld를
http_control 포트로 전송), 레플리카가 더 이상 리더가 아니게 될 때까지 상태를 폴링합니다. 요청만 보내고
곧바로 컨테이너를 중지하지 않는 이유는, 요청을 보낸 뒤 확인하지 않는 방식(fire-and-forget)으로는 쓰기 부하 상황에서
여전히 SIGTERM과의 경쟁에서 밀릴 수 있기 때문입니다. 이렇게 대기해야 리더가 없는 구간을 일정 범위 안으로 제한할 수 있습니다.
이 후크는 별도의 구성이 필요 없으며, 지원되지 않는 환경에서도 문제 없이 동작합니다. 여기서 사용하는 리더십 명령어를 아직 지원하지 않는
26.3 이전 버전의 Keeper에서는 요청이 아무 동작도 하지 않으며(no-op), 컨테이너는 후크가 없을 때와 동일하게 중지됩니다.
이 후크는 셸 스크립트를 실행하므로 image에 bash가 포함되어 있어야 합니다. distroless 또는 scratch Keeper image를 사용하는 경우
containerTemplate.lifecycle을 통해 후크를 재정의하거나 제거하십시오. 자세한 내용은
API 참조를 참고하십시오.
저장소 구성
PersistentVolumeClaimSpec인 dataVolumeClaimSpec을 사용해 영구 저장소를 구성합니다.
연산자는 이를 데이터 경로 /var/lib/clickhouse에 마운트되는 레플리카별 PersistentVolumeClaim으로 변환합니다:
연산자는 사용 중인 StorageClass가 볼륨 확장을 지원하는 경우에만 기존 PVC를 수정할 수 있습니다.
클러스터 도메인
spec.clusterDomain은 연산자가 ClickHouse 서버
구성에 기록하는 정규화된 파드 호스트 이름을 생성할 때 사용하는
Kubernetes DNS 접미사를 설정합니다. 기본값은 cluster.local이며,
ClickHouseCluster와 KeeperCluster 둘 다에 있습니다.
<cluster-name>-clickhouse-headless를 생성합니다.
또한 내부 트래픽과 연산자의 관리 요청을 위해 준비되지 않은 파드를 노출하는 레플리카별 Service <cluster-name>-clickhouse-internal-<shard>-<index>를 생성합니다.
레플리카가 자체적으로 준비 상태가 될 수 없는 경우 레플리카 복구에 사용할 수 있습니다.
Keeper 노드는 헤드리스 Service를 통해 파드 이름을 사용합니다: <pod>.<headless-service>.<namespace>.svc.<clusterDomain>.
클러스터의
큐블릿이 cluster.local이 아닌 --cluster-domain으로 실행되는 경우에만
이 값을 재정의하십시오. 값이 실제 클러스터 도메인과 일치하지 않으면
ClickHouse가 Keeper 및 레플리카 호스트 이름을 해석할 수 없어 조정과
Distributed 쿼리가 DNS 해석 오류로 실패합니다. 참조 대상인
ClickHouseCluster와 KeeperCluster에 동일한 값을 설정하십시오.파드 구성
토폴로지 분산 및 어피니티 자동 설정
가용 영역에 걸쳐 파드를 분산합니다:분산 제약 조건을 충족할 수 있도록 Kubernetes 클러스터에 서로 다른 zone에 걸쳐 충분한 수의 노드가 있는지 확인하세요.
topologyMinDomains를 가용 영역 수로 설정하세요:
topologyMinDomains를 사용하려면 topologyZoneKey가 필요합니다. 요청한 수보다 적은 zone만 사용할 수 있는 동안에는
파드가 Pending 상태로 남아 있으므로, 클러스터가 제공할 수 있는 zone 범위 내에서 설정하세요.수동 구성
파드 중단 예산
기본값
apply해도 우발적인 정족수 손실을 방지할 수 있습니다.
replicas: 3인 3개 세그먼트 ClickHouseCluster의 경우, 연산자는 세그먼트마다 하나씩 총 3개의 PDB를 생성하며, 각각 minAvailable: 1로 설정합니다.
기본값 덮어쓰기
minAvailable 또는 maxUnavailable 중 정확히 하나를 재정의하려면 spec.podDisruptionBudget를 사용합니다:
maxUnavailable 형식:
unhealthyPodEvictionPolicy 필드를 생성된 PDB에 전달할 수도 있습니다. 이는 아직 NotReady 상태인 파드의 축출(eviction)을 허용해야 할 때 유용합니다:
정책
spec.podDisruptionBudget.policy를 사용하면 연산자가 PDB를 어느 정도 적극적으로 관리할지 선택할 수 있습니다.
예시 — 개발 클러스터에서 PDB 관리를 완전히 비활성화합니다:
클러스터 전체 비활성화
ENABLE_PDB 환경 변수를 통해 클러스터 전체에서 비활성화할 수도 있습니다. ENABLE_PDB=false로 설정하면 오퍼레이터는 각 ClickHouseCluster 및 KeeperCluster의 spec.podDisruptionBudget.policy와 관계없이 모든 ClickHouseCluster와 KeeperCluster에 대해 PDB reconcile 단계를 건너뛰고, PodDisruptionBudget 리소스는 전혀 감시하지 않습니다. 따라서 오퍼레이터의 ServiceAccount에는 poddisruptionbudgets.policy/v1에 대한 RBAC 권한이 필요하지 않으며, 이는 해당 권한을 의도적으로 제외한 제한된 ServiceAccount로 오퍼레이터를 실행할 때 유용합니다.
컨테이너 구성
사용자 지정 이미지
컨테이너 리소스
환경 변수
볼륨 마운트
동일한
mountPath에 여러 볼륨 마운트를 지정할 수 있습니다.
Operator는 지정된 모든 마운트를 포함하는 프로젝티드 볼륨을 생성합니다.상태 프로브
연산자는 모든 ClickHouse 및 Keeper 컨테이너에 활성 상태(liveness) 프로브와 준비 상태(readiness) 프로브를 구성합니다. 시작(startup) 프로브는 기본적으로 설정되지 않습니다.
ClickHouse와 Keeper는 동일한 기본 타이밍 설정을 사용합니다.
ClickHouse는 테이블을 로드하기 전에 서버 간 리스너를 열고, 테이블 로드가 끝난 후에 클라이언트 리스너를 엽니다. 따라서 테이블 로딩이 오래 걸리더라도 활성 상태 프로브는 실패하지 않으며, 준비 상태 프로브를 통과했다면 레플리카가 쿼리를 처리할 수 있는 상태임을 뜻합니다.
두 리소스 모두
spec.containerTemplate을 통해 어떤 프로브든 재정의할 수 있습니다. 예를 들어 ClickHouse 활성 상태 프로브는 다음과 같이 사용자 정의합니다.
시작 프로브(Startup probe)
컨테이너 시작에 활성 상태 프로브가 허용하는 시간보다 더 오래 걸리는 경우startupProbe를 사용하십시오. 기본값에서 활성 상태 프로브는 약 60초의 초기 지연 후 5초 간격으로 최대 10회의 검사 실패를 허용합니다.
Kubernetes는 시작 프로브가 성공할 때까지 활성 상태 프로브와 준비 상태 프로브의 실행을 보류하므로, 시작이 느려도 재시작 루프가 발생하지 않습니다.
예를 들어, 대용량 스냅샷을 재생(replay)하는 Keeper 레플리카에 연결 수락을 시작하기까지 최대 10분을 부여하려면 다음과 같이 설정합니다:
TLS/SSL 구성
보안 endpoint 구성
SSL 인증서 시크릿 포맷
tls.crt- PEM으로 인코딩된 서버 인증서tls.key- PEM으로 인코딩된 개인 키
이 포맷은 cert-manager에서 생성한 인증서와 호환됩니다.
TLS를 통한 ClickHouse-Keeper 통신
keeperClusterRef가 참조하는 KeeperCluster에서 TLS가 활성화되어 있으면 ClickHouseCluster는 자동으로 Keeper 노드에 대한 보안 연결(connection)을 사용합니다.
externalKeeper를 사용할 때는 대신 tls: Enabled를 설정하고, 각 노드의 port를 앙상블의 보안 클라이언트 포트(예: 9281)로 지정하십시오.
ClickHouseCluster는 시스템 트러스트 스토어와 구성한 모든 caBundle을 기준으로 Keeper 노드 인증서를 검증합니다.
비공개 CA(예: 자체 서명 또는 내부 CA)를 신뢰하려면 사용자 지정 CA 번들 참조를 제공하십시오:
외부 시크릿
spec.externalSecret을 사용해 기존에 생성된 시크릿을 연산자가 참조하도록 지정하십시오:
참조된 시크릿은 ClickHouseCluster와 같은 네임스페이스에 있어야 합니다. 연산자는 직접 생성하지 않은 시크릿은 절대 삭제하지 않습니다.
필수 키
전체 시크릿은 다음과 같습니다:
정책: Observe와 Manage
spec.externalSecret.policy는 필수 키가 누락되었을 때 연산자가 어떻게 처리할지를 제어합니다.
policy: Manage를 사용하더라도 시크릿은 해당 네임스페이스에 이미 존재해야 합니다. 연산자는 시크릿 자체를 생성하지 않고, 기존 시크릿에 생성된 키만 기록합니다. 참조된 시크릿이 없으면 정책과 관계없이 ExternalSecretNotFound 사유로 리컨실리에이션이 차단됩니다.Observe를 선택하십시오. 자체적으로 초기 설정을 진행하면서도 시크릿 객체 자체의 소유권은 유지하려면(예: 백업 목적) Manage를 선택하십시오.
상태 조건과 문제 해결
ClickHouseCluster.status.conditions에 ExternalSecretValid 조건을 표시합니다. 리컨실리에이션이 멈춘 것처럼 보이면 이 조건을 확인하십시오:
시크릿이 유효하지 않은 동안 연산자는 리컨실리에이션을 다시 큐에 넣습니다. 따라서 누락된 키를 추가하면 다음 reconcile 시 자동으로 반영되므로 파드를 재시작할 필요가 없습니다.
필요한 키 집합은 실행 중인 ClickHouse 버전에 따라 달라집니다.
named-collections-key는 연산자의 버전 프로브가 ClickHouse 25.12 이상을 감지한 경우에만 검증됩니다. 이전 버전에서는 해당 키가 시크릿에 없을 수 있습니다. disk-encryption-key는 spec.settings.encryption이 설정된 경우에만 필요합니다.추가 포트
8123 HTTP, 9000 네이티브, 9009 interserver, 9001/9002 management, 9363 Prometheus 메트릭, 그리고 TLS가 활성화된 경우 8443/9440의 TLS 포트도 함께 노출됩니다. interserver 및 management 포트는 레플리카가 준비 상태가 되기 전에 레플리카와 연산자가 통신할 수 있도록 레플리카별 내부 Service를 통해 추가로 노출됩니다. ClickHouse가 MySQL, PostgreSQL, gRPC 또는 사용자 지정 포트 같은 추가 프로토콜을 수신하도록 하려면 spec.additionalPorts에 선언하십시오:
containerPorts와 공개 헤드리스 Service에 추가합니다.
전체 예시는 examples/custom_protocols.yaml에 있습니다.
종단 간 예시: MySQL wire protocol
9004에서 MySQL wire protocol로 ClickHouse를 노출하려면:
필드 제약 조건
예약된 포트 및 이름
additionalPorts 항목을 거부합니다. 모든 TLS 관련 포트는 예외 없이 예약되므로, 나중에 spec.settings.tls.enabled를 활성화하더라도 이전에 유효했던 클러스터가 손상되지 않습니다.
다음 이름도 거부됩니다. 이는 연산자의 내부 프로토콜 유형 식별자이며, 사람이 읽기 쉬운 별칭은 아닙니다.
거부된 요청은 다음과 같은 오류를 반환합니다:
버전 프로브 및 업그레이드 채널
- 버전 보고 —
ClickHouseCluster의 경우 KubernetesJob이 컨테이너 이미지를 한 번 실행해 현재 실행 중인 ClickHouse 버전을 확인하고,KeeperCluster의 경우 연산자가 실행 중인 레플리카에서 서버가 보고한 버전을 읽습니다. 확인된 버전은.status.version에 기록되며, 다른 리컨실리에이션 단계에서 사용됩니다(예:External Secretnamed-collections 키는 ClickHouse25.12부터만 필요합니다). - 업그레이드 채널 — 공개 ClickHouse 릴리스 피드(
https://clickhouse.com/data/version_date.tsv)를 주기적으로 확인합니다. 연산자는VersionUpgraded상태 조건을 통해 더 최신 버전을 사용할 수 있는지 보고합니다. 연산자가 자체적으로 클러스터를 업그레이드하지는 않으며, image tag는 사용자가 직접 제어합니다.
릴리스 채널 선택
spec.upgradeChannel은 연산자가 비교 대상으로 삼을 업스트림 릴리스 집합을 선택합니다. 동일한 필드는 ClickHouseCluster와 KeeperCluster 모두에 있습니다.
^(lts|stable|\d+\.\d+)?$로 검증함):
프로덕션 환경에서는 채널을 명시적인
<major>.<minor>(예: 25.8)에 고정하는 방식을 일반적으로 권장합니다. 이렇게 하면 클러스터가 의도한 major 릴리스 라인에 고정되며, 어떤 레플리카가 다른 major로 벗어나는 경우 연산자가 WrongReleaseChannel 경고를 표시할 수 있습니다. 이는 특히 image가 사람이 읽기 쉬운 태그가 아니라 다이제스트(@sha256:...)로 참조될 때 중요합니다. 기본 empty 값은 major 버전 점프가 문제가 되지 않는 개발 클러스터에서는 적절합니다.
상태 조건
다음으로 확인할 수 있습니다:
버전 프로브 Job 재정의
ClickHouseCluster에만 적용됩니다. KeeperCluster는 더 이상 version-probe Job을 실행하지 않습니다. 대신 버전은 실행 중인 Keeper 레플리카에서 직접 읽어 오므로 spec.versionProbeTemplate은 더 이상 사용이 권장되지 않으며 여기서는 아무런 효과가 없습니다.
프로브는 일반적인 Kubernetes Job으로 구현됩니다. 클러스터에 특정 Tolerations, 노드 셀렉터, 보안 컨텍스트를 요구하는 admission policy가 있거나 완료된 probe Job이 남아 있는 시간을 제한하려는 경우, spec.versionProbeTemplate을 통해 템플릿을 재정의하십시오:
version-probe는 연산자의 기본값입니다 — containers: 아래의 항목이 이름으로 일치하므로, 연산자는 사용자가 제공한 필드를 기본값 위에 깊게 병합합니다.
Operator 전체 제어
에어갭 환경이거나
clickhouse.com으로의 egress가 허용되지 않는 경우 --disable-version-update-checks=true를 설정하십시오.
ClickHouse 설정
기본 default 사용자 비밀번호
spec.settings.defaultUserPassword는 내장된 default
사용자의 비밀번호를 설정합니다. CR에 직접 인라인으로 지정하지 말고,
생성한 시크릿(권장) 또는 ConfigMap의 키에 저장된 값을 사용하십시오:
secret 또는 configMap 중 정확히 하나만 지정하십시오. 선택한 항목에는 name(객체 이름)
및 key(비밀번호가 들어 있는 항목)가 모두 포함되어야 합니다.
비밀번호 유형
passwordType은 값을 어떻게 해석할지 ClickHouse에 지정합니다. 기본값은
password(평문)이며, 대안으로는
password_sha256_hex 및 password_double_sha1_hex 같은 해시 형식이 있습니다. 평문이
저장되지 않도록 해시 유형을 사용하는 것이 좋습니다. 전체 목록은
ClickHouse 사용자 설정
을 참조하십시오.
시크릿을 사용하는 전체 예시
passwordType: password를 사용하면 파드 내 clickhouse-client에 이 비밀번호가 설정되므로
디버깅에 편리합니다.ConfigMap 사용하기
password_sha256_hex 다이제스트가 있습니다:
ConfigMap에 평문 비밀번호를 넣지 마십시오. 평문
(
passwordType: password) 값을 사용할 때는 시크릿을 사용하십시오.구성의 사용자 지정 사용자
설정 파일에서 추가 사용자를 구성합니다. 사용자용 ConfigMap과 시크릿을 생성합니다:데이터베이스 동기화
clickhouse.com/ReplicaInitialized readiness 게이트가 적용되므로, 연산자가 초기화를 완료한 후에만 새 레플리카가 공개 헤드리스 Service를 통해 게시됩니다. 초기화 과정에서는 default 데이터베이스가 Replicated 엔진으로 변환되고 스키마가 동기화됩니다. 그때까지 연산자와 다른 레플리카는 내부 Service를 통해 해당 레플리카에 연결합니다. enableDatabaseSync: false를 사용하면 연산자가 레플리카를 즉시 초기화된 것으로 표시하므로 readiness는 컨테이너 probe만 따릅니다.
연산자는 데이터가 채워진 non-Replicated default 데이터베이스를 절대 삭제하지 않습니다. 이러한 레플리카도 스키마 준비 후 클라이언트 트래픽 처리를 시작하지만, 해당 데이터베이스 문제를 직접 해결할 때까지 클러스터는 이유가 DefaultDatabaseNotReplicated인 SchemaInSync=False를 보고합니다.
축소 시 레플리카를 제거하기 전에 연산자는 먼저 해당 레플리카에서 클라이언트 트래픽을 로드 해제하고, 더 이상 게시되지 않을 때까지 기다린 후 남은 데이터를 유지되는 레플리카에 복제한 다음에만 삭제합니다.
서버 로깅
spec.settings.logger에서 ClickHouse 서버 로그를 구성합니다. 모든 필드는 안전한 기본값이 적용되는 선택 사항이므로, 별도로 설정하지 않은 클러스터도 기본적으로 컨테이너 콘솔과 디스크의 롤링 파일 모두에 information 수준으로 로그를 기록합니다.
연산자는
kubectl logs가 작동하도록 항상 콘솔 로깅을 유지하고, logToFile이 true이면 여기에 파일 로깅을 추가합니다. 기본값을 사용하는 클러스터는 다음 logger 블록으로 렌더링됩니다:
spec.settings.logger 블록은 KeeperCluster에도 적용되며, 이 경우 연산자는 파일을 /var/log/clickhouse-keeper/ 아래에 기록하고 Raft 로거(raft_logs_level)도 동일한 level로 설정합니다.
logToFile과 관계없이 콘솔 로깅은 계속 활성화되므로, 파일 로깅을 비활성화해도 kubectl logs는 계속 작동합니다. JSON을 파싱하는 구조화된 로그 저장소로 로그를 전송하는 경우 jsonLogs: true로 설정하십시오.시스템 로그 테이블
연산자는query_log, part_log, text_log, metric_log, asynchronous_metric_log 시스템 테이블을 활성화합니다. 이 테이블들은 데이터와 같은 볼륨에 저장되므로 spec.settings.systemLogsTTLDays가 테이블 TTL로 보관 기간을 제한합니다. 클러스터를 생성할 때 이 필드를 지정하지 않으면 기본값 지정 웹훅이 값을 30으로 설정합니다. TTL을 명시적으로 비활성화하려면 0으로 설정하세요.
이 기본값은 새 클러스터에만 적용됩니다.
systemLogsTTLDays가 도입되기 전에 생성된 클러스터에서는 이 필드를 직접 설정하기 전까지 시스템 로그 테이블(System Log Table)이 크기 제한 없이 계속 누적됩니다.@remove 속성을 사용한 테이블 완전 비활성화는 모두 extraConfig를 통해 수행할 수 있습니다:
테이블을 비활성화해도 삭제되지는 않습니다. 직접 테이블을 삭제할 때까지 기존 데이터는 디스크에 남아 있습니다.
ClickHouse는 TTL이 변경된 시스템 테이블을 재생성하고, 기존 데이터는
system.text_log_0처럼 이름을 변경한 테이블에 보관합니다. 이력이 더 이상 필요하지 않으면 해당 테이블을 삭제하세요.사용자 지정 구성
내장 추가 구성
extraConfig를 사용하여 사용자 지정 ClickHouse 구성을 추가하십시오:
유용한 링크:
다시 로드할 수 있는 추가 구성
extraConfig를 변경하면 ClickHouse 파드가 다시 시작됩니다. 연산자는 런타임에 어떤 설정이 적용되는지 알 수 없기 때문입니다. ClickHouse가 실행 중에 다시 로드할 수 있는 설정에는 extraConfig 대신 extraReloadableConfig를 사용하세요. 대표적인 예가 named_collections입니다. 연산자는 파드를 다시 시작하지 않고 구성을 다시 로드해 변경 사항을 적용합니다:
extraConfig와 extraReloadableConfig 중 한 곳에만 두십시오. 두 곳에서 같은 섹션을 설정하면 연산자가 경고를 표시합니다.
extraReloadableConfig를 사용한다는 것은 그 안의 설정을 다시 로드해도 안전하다고 보증한다는 의미입니다. 재시작해야만 적용되는 설정을 여기에 넣으면 오류는 발생하지 않지만, 다음 재시작 시점에야 적용됩니다.내장된 추가 사용자 구성
extraUsersConfig를 사용해 추가 ClickHouse 사용자 구성을 지정할 수도 있습니다. 이는 클러스터 사양에서 사용자, 프로필, 쿼터, 권한 부여를 직접 정의할 때 유용합니다.
extraUsersConfig는 k8s ConfigMap 객체에 저장됩니다. 여기에 평문 시크릿을 저장하지 마십시오.구성 예시
주기적 resync
연산자는 Kubernetes 이벤트에 반응하는 것 외에도, 일정한 인터벌마다 모든 클러스터를 다시 리컨실합니다. 이를 통해 어떤 watch로도 관찰할 수 없는 상태(ClickHouse 레플리카 health, Keeper quorum)의 상태 조건을 최신으로 유지하고, 멈춘 파드 정리와 같은 조치를 재시도합니다. 이 인터벌은 연산자의RESYNC_PERIOD environment variable(기본값 30s)로 제어됩니다. 이 설정은 KeeperCluster 리소스에 적용되며, 0으로 지정하면 주기적 resync가 비활성화됩니다. ClickHouseCluster 리소스는 30초마다 ClickHouse system.warnings를 폴링하면서 이미 리컨실리에이션을 다시 트리거하므로, 현재 RESYNC_PERIOD는 이러한 리소스에 아무런 영향을 주지 않습니다.
MAX_CONCURRENT_RECONCILES(기본값 4)로 설정합니다.
리컨실리에이션 일시 중지
ClickHouseCluster 또는 KeeperCluster에 clickhouse.com/pause-reconciliation: "true" 어노테이션을 설정하면 연산자가 해당 리소스의 리컨실리에이션을 중지합니다. 연산자는 일시 중지된 리소스에 ReconcileSucceeded=False와 사유 ReconciliationPaused를 보고하며, 그 외에는 리소스를 건드리지 않습니다. 연산자가 수동 변경 사항을 되돌리려 할 때 유용합니다. 일시 중지된 동안 연산자는 클러스터 상태를 관찰하지 않으므로 Ready와 Healthy를 포함한 모든 상태 조건을 사유가 ReconciliationPaused인 Unknown으로 보고합니다. 재개하려면 어노테이션을 제거하세요. 보류 중인 spec 변경 사항은 다음 리컨실리에이션에서 적용됩니다.