Operações

Esta página aborda as operações do dia 2 do connector em ambos os destinos de instalação. Para instalação e inscrição, consulte o onboarding. A operação dos próprios serviços (criação, escalonamento, exclusão e atualizações de plataforma) é abordada em managed services e platform updates.

Upgrade

Kubernetes

As operações do Kubernetes no dia 2 usam a CLI helm na sua estação de trabalho. Somente o init inclui um cliente Helm integrado; portanto, instale o helm antes do primeiro upgrade.

Faça upgrade do lançamento a partir do repositório público de charts com a sobreposição de valores preparada pelo init:

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm upgrade --install clicklink-connector clicklink-connector \
  --repo https://releases.clicklink.clickhouse.com/charts \
  --version <version> \
  -n "${CONNECTOR_NAMESPACE}" \
  -f clicklink-values.yaml

As versões do chart são as tags de lançamento sem o v inicial (o chart X.Y.Z corresponde à tag vX.Y.Z). O chart publicado já aponta para a imagem pública de contêiner, portanto instalações e upgrades simples não exigem valores de imagem. Para inspecionar os valores padrão do chart, execute helm show values clicklink-connector --repo https://releases.clicklink.clickhouse.com/charts. O executor é executado como uma única réplica com a estratégia Recreate, de modo que um upgrade o desconecta brevemente. Consulte quando o connector está offline para saber o que acontece com os comandos nessa janela. Uma instalação a partir de uma referência direta ao chart (oci://, uma URL ou um arquivo ou diretório local) não tem um repositório em relação ao qual possa ser resolvida. Em vez disso, execute novamente helm upgrade clicklink-connector <same-chart-reference> na nova versão. Executar novamente o init com uma CLI mais recente também produz o mesmo resultado, mas exige um ponto de entrada: --handoff se você manteve o pacote ou um novo token de inscrição com --force após a limpeza documentada. O helm upgrade acima é o procedimento usual (consulte reexecuções e recuperação).

VM Linux

Execute novamente o instalador no host. Ele baixa e verifica o lançamento mais recente como fez durante o onboarding. Ele cria um backup do binário anterior, instala as systemd units atuais e preserva seus padrões de mascaramento ativos e o arquivo de ambiente. Em seguida, reinicie os daemons:

curl -fsSL https://releases.clicklink.clickhouse.com/install.sh | sudo bash -s -- --host
sudo systemctl restart clicklink-scraper clicklink-troubleshooter clicklink-executor

Para atualizar para um lançamento específico em vez do mais recente, adicione --version vX.Y.Z ao comando de instalação.

Saúde

Cada daemon disponibiliza um endpoint /livez em sua porta de saúde. O indicador de saúde é o campo JSON status no corpo da resposta, não o código de status HTTP. As métricas do Prometheus são disponibilizadas em /metrics na mesma porta; não há uma porta de métricas separada. Portas padrão em ambos os destinos:

Componente	Porta de saúde
Scraper	8082
Solucionador de problemas	8084
Executor	8086

O executor também disponibiliza sua API de comandos local em 127.0.0.1:9999. Ela não possui autenticação própria e nunca é exposta fora do host ou do pod do Kubernetes; os comandos de serviço do clicklink clctl a acessam localmente. Quando as sessões de suporte estão habilitadas, o gateway também escuta na porta 8443: TLS autossinado em uma VM, HTTP local ao pod por meio de kubectl port-forward ou uma Entrada com terminação TLS no Kubernetes. Em uma VM, execute toda a suíte de verificações a qualquer momento:

sudo clicklink clctl preflight

Verifica a configuração, os arquivos, conflitos de porta, a acessibilidade da rede, a conectividade com o ClickHouse, o estado da unidade do systemd, o acesso por componente, o disco e os padrões de mascaramento. Encerra com 2 se alguma verificação falhar.

Certificados

O connector renova seu próprio certificado de cliente. O scraper, o solucionador de problemas e o executor verificam o certificado final a cada 12 horas e o renovam quando restam 10 dias. A renovação retorna um certificado final com validade de 30 dias pelo canal existente autenticado por mTLS e HMAC, portanto nenhuma ação do operador é necessária. No Kubernetes, o daemon grava o certificado final renovado novamente no Secret clicklink-mtls; em uma VM, ele o grava em /etc/clicklink/tls/. Para verificar a data de expiração atual:

# Linux VM
sudo openssl x509 -in /etc/clicklink/tls/client.crt -noout -enddate

# Kubernetes
CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
kubectl get secret clicklink-mtls -n "${CONNECTOR_NAMESPACE}" -o jsonpath='{.data.tls\.crt}' \
  | base64 -d | openssl x509 -noout -enddate

Rotação de credenciais

Credenciais da API (HMAC)

Solicite um novo token de inscrição à sua equipe de conta e execute novamente o comando init original com --enroll e --force. Mantenha todas as flags específicas do destino usadas na primeira instalação (--target-namespace, --values e quaisquer flags de espelhamento, como --chart, --chart-repo ou --chart-version), pois --force prepara novamente a configuração preservada. O modo managed é herdado da configuração que está sendo substituída, portanto --managed é opcional aqui. Em uma instalação padrão:

# Kubernetes, from your workstation
clicklink clctl init --enroll https://<subdomain>.<connector-domain> --target helm --force

# Linux VM, on the host
sudo clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force

Em uma VM, o init apenas habilita e inicia unidades que ainda não estão em execução, portanto reinicie os daemons após a rotação:

sudo systemctl restart clicklink-scraper clicklink-troubleshooter clicklink-executor

No Kubernetes, o init cria previamente os Secrets rotacionados clicklink-hmac e clicklink-mtls; o chart não os renderiza. Sua annotation de checksum não os abrange, portanto os pods em execução continuam usando as credenciais com as quais foram iniciados. Reinicie todos os componentes após a rotação:

kubectl rollout restart deployment,statefulset -n "${CONNECTOR_NAMESPACE}" \
  -l app.kubernetes.io/part-of=clicklink-connector

Para rotação não assistida, quando o provisionamento SQL exige uma senha, o stdin recebe ambos os segredos nesta ordem: o token na primeira linha e a senha na segunda. A leitura do token consome exatamente uma linha.

printf '%s\n' "$ENROLLMENT_TOKEN" "$CH_ADMIN_PASSWORD" | \
  clicklink clctl init --enroll https://<subdomain>.<connector-domain> --force --ch-admin-password-stdin

Usuários do ClickHouse

Reprovisione os usuários somente leitura do connector em cada instância que você mesmo registrou. No Kubernetes, execute os comandos a partir da sua estação de trabalho. --apply-ch-grants reaplica os grants regenerados no pod para que as novas credenciais cheguem ao ClickHouse; se o usuário admin tiver uma senha, adicione --ch-admin-password-stdin e forneça-a por pipe:

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
clicklink clctl scraper access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force
clicklink clctl troubleshoot access provision --target helm \
  --target-namespace "${CONNECTOR_NAMESPACE}" \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force

Em uma VM, execute-os no host fornecendo a senha do admin por pipe; nesse caso a senha é obrigatória, a menos que você passe --ch-user-via cr:

printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl scraper access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --ch-admin-password-stdin --force
printf '%s\n' "$CH_ADMIN_PASSWORD" | sudo clicklink clctl troubleshoot access provision --provider local \
  --instance <instance-name> --server <kubernetes-api-server-url> --ch-admin-password-stdin --force

Para instâncias gerenciadas pelo operador, adicione --ch-user-via cr e as flags de seleção do pod do Kubernetes a qualquer uma das opções; consulte a referência da CLI.

Certificado do cliente

A renovação é automática (consulte certificados). Para substituir imediatamente um certificado ainda válido, execute init novamente com --force. Em seguida, reinicie cada componente para que os daemons apresentem o novo certificado final: no Kubernetes, conforme descrito em credenciais de API; em uma VM, as três unidades.

Reexecuções e recuperação

As reexecuções de init são convergentes; portanto, executar novamente o mesmo comando é sempre a primeira medida. Sem --force, um /etc/clicklink/config.yaml (VM) ou uma sobreposição clicklink-values.yaml (Kubernetes) existente é mantido, e uma chave de cliente existente é reutilizada; o init substitui as credenciais e a cadeia de CA atomicamente. Os comandos de recuperação exibidos pela CLI após uma falha parcial podem ser repetidos com segurança. --force substitui a configuração ou sobreposição mantida, regenera a chave de cliente e substitui um certificado do cliente ainda válido. Ele nunca gera um novo UUID de cluster, de modo que a identidade do connector é preservada. A postura do modo managed da configuração substituída é mantida em reexecuções não assistidas e oferecida como padrão em um terminal, a menos que você passe --managed ou --no-managed. Se a assinatura do certificado falhar após o staging ou se o endpoint de assinatura retornar 409 porque já existe um certificado ainda válido, não será necessário um novo token nem uma segunda emissão. Conclua a instalação com os materiais assinados já presentes no disco:

sudo clicklink clctl init --signed-cert client.crt --chain ca-chain.crt

Esse é o formato para VM (o root reescreve /etc/clicklink e gerencia os serviços). No Kubernetes, a CLI imprime o formato completo, incluindo --target helm, --target-namespace e --values; use o comando impresso como está. Connector offline. Enquanto o connector está fora do ar ou inacessível, os serviços que ele gerencia continuam em execução. O ClickHouse operator no seu cluster os mantém ativos, e o executor não está no data path. Mudanças de ciclo de vida exigem o executor conectado, portanto nenhuma é aplicada até que ele se reconecte. Ao reiniciar, o executor recupera do seu banco de dados de comandos aqueles que estavam em andamento. Um comando que o ClickHouse Cloud entrega novamente é respondido a partir do resultado registrado; somente um comando que falhou é executado de novo. Para os comandos de ciclo de vida enquanto nenhum executor está conectado, consulte quando o connector está offline.

Desinstalar

Exclua todos os serviços gerenciados antes de desinstalar, conforme excluir um serviço, e aguarde a conclusão de cada remoção. Remover o connector primeiro deixa os serviços sem nenhum component capaz de gerenciar seu ciclo de vida.

VM Linux

O uninstall.sh é incluído no tarball do lançamento. Se não houver um tarball extraído no host, busque e extraia um (consulte download e verificação manuais). Execute o uninstall.sh no diretório extraído:

sudo ./uninstall.sh

Isso interrompe e desabilita as unidades clicklink-scraper, clicklink-troubleshooter e clicklink-executor e remove as unidades do systemd e o binário. Preserva os itens a seguir, para que uma reinstalação posterior reutilize a configuração existente:

/etc/clicklink, incluindo os access bundles do executor em /etc/clicklink/access/executor
/var/lib/clicklink, incluindo o banco de dados de comandos executor.db do executor e o registry de serviços
/var/log/clicklink
o usuário clicklink

Para remover esses itens também:

sudo ./uninstall.sh --purge

O grant cluster-wide do executor reside no seu cluster, não no host. Remova-o como administrador do cluster assim que não restar nenhum serviço gerenciado:

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n clicklink-system

O grant também criou o espaço de nomes clicklink-system; exclua-o quando nada mais o utilizar.

Kubernetes

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
helm uninstall clicklink-connector -n "${CONNECTOR_NAMESPACE}"

O PersistentVolumeClaim do executor tem a anotação helm.sh/resource-policy: keep, portanto a desinstalação o preserva, junto com o banco de dados de comandos e o registry de serviços nele contidos. Os Secrets criados pelo init, o Secret do platform bundle gravado pelo platform approve e o ConfigMap do registry de serviços mantido pelo executor também não pertencem ao chart e sobrevivem à desinstalação. Exclua-os explicitamente. Inclua o par de Secret de acesso e ServiceAccount de cada instance que você mesmo registrou e de cada serviço gerenciado para o qual você provisionou o solucionador de problemas (nomeado a partir do serviço). O --ignore-not-found cobre objetos que nunca chegaram a ser criados, como o Secret do platform bundle antes da primeira aprovação:

kubectl delete pvc -n "${CONNECTOR_NAMESPACE}" -l app.kubernetes.io/instance=clicklink-connector --ignore-not-found
kubectl delete secret clicklink-hmac clicklink-mtls clicklink-platform-bundle -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete configmap clicklink-instance-registry -n "${CONNECTOR_NAMESPACE}" --ignore-not-found
kubectl delete secret -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  clicklink-connector-scraper-access-<instance> \
  clicklink-connector-troubleshooter-access-<instance>
kubectl delete serviceaccount -n "${CONNECTOR_NAMESPACE}" --ignore-not-found \
  pcm-scraper-<instance> pcm-troubleshooter-<instance>
# Repeat for every ClickHouse namespace that holds an instance you registered yourself;
# a managed service's namespace went away with the service.
for ns in <clickhouse-namespace-1> <clickhouse-namespace-2>; do
  kubectl delete serviceaccount,role,rolebinding -n "${ns}" --ignore-not-found \
    pcm-scraper pcm-troubleshooter
done

init aplicou o grant cluster-wide do executor, não o chart. Remova-o como admin do cluster assim que não restar nenhum serviço gerenciado:

kubectl delete validatingadmissionpolicybinding pcm-executor-prefix-guard
kubectl delete validatingadmissionpolicy pcm-executor-prefix-guard
kubectl delete clusterrolebinding pcm-executor-cluster
kubectl delete clusterrole pcm-executor-cluster
kubectl delete serviceaccount pcm-executor -n "${CONNECTOR_NAMESPACE}"

A camada de plataforma

Desinstalar o connector não remove a camada de plataforma. Os espaços de nomes e as cargas de trabalho da plataforma, o RBAC pcm-platform e os objetos de admission instalados pelas suas aprovações permanecem no cluster, assim como todos os serviços gerenciados. Exclua primeiro os serviços; consulte excluir um serviço. Em um cluster de teste sem serviços, o comando clicklink clctl platform reset desinstala os lançamentos da plataforma. As CustomResourceDefinitions, o RBAC e a StorageClass que ele deixa para trás precisam ser excluídos manualmente; consulte redefinir um cluster de teste. Fora de um cluster de teste, defina um plano de remoção junto à sua equipe de conta antes de mexer na camada de plataforma.

Usuários do ClickHouse

A desinstalação em qualquer um dos destinos mantém os usuários provisionados como somente leitura nas instâncias que você mesmo registrou. Exclua-os como administrador em cada instância (adicione seu --ch-user-suffix aos nomes, caso tenha definido um):

DROP USER IF EXISTS pcm_scraper, pcm_troubleshooter;

Primeiros passos

Serviços e infraestrutura

Bring Your Own Cloud

Dados e integrações

Conectar e consultar

Gerenciamento de acesso

Segurança e conformidade

Monitoramento e backups

Ferramentas e agentes de IA

API do Cloud

Faturamento

Suporte

ClickHouse Private

Upgrade

Kubernetes

VM Linux

Saúde

Certificados

Rotação de credenciais

Credenciais da API (HMAC)

Usuários do ClickHouse

Certificado do cliente

Reexecuções e recuperação

Desinstalar

VM Linux

Kubernetes

A camada de plataforma

Usuários do ClickHouse

​Upgrade

​Kubernetes

​VM Linux

​Saúde

​Certificados

​Rotação de credenciais

​Credenciais da API (HMAC)

​Usuários do ClickHouse

​Certificado do cliente

​Reexecuções e recuperação

​Desinstalar

​VM Linux

​Kubernetes

​A camada de plataforma

​Usuários do ClickHouse

Upgrade

Kubernetes

VM Linux

Saúde

Certificados

Rotação de credenciais

Credenciais da API (HMAC)

Usuários do ClickHouse

Certificado do cliente

Reexecuções e recuperação

Desinstalar

VM Linux

Kubernetes

A camada de plataforma

Usuários do ClickHouse