Apresentamos o GizmoSQL Operator

Artigo de convidado: este artigo foi publicado originalmente em nima.blog por Nima Khoshini e é republicado aqui com a autorização do autor.

Hoje tenho o prazer de anunciar o lançamento do GizmoSQL Kubernetes Operator! O GizmoSQL é um projeto iniciado por um amigo meu, Philip Moore, para reduzir o custo operacional de consultas SQL em larga escala. Ele já demonstrou seu valor para os clientes, gerando economia de 90% nas despesas operacionais em comparação com os principais mecanismos de dados na nuvem.

O que é um Kubernetes Operator?

Um Kubernetes Operator estende a API do Kubernetes para criar, configurar e gerenciar aplicações. Quem já usou Kubernetes provavelmente conhece conceitos como Deployment, StatefulSet e Job. Operators, junto com Custom Resource Definitions (CRDs), permitem estender essa API para criar seus próprios recursos e gerenciá-los por ela.

Se você já usou ferramentas como Cert-Manager para gerenciar certificados TLS no cluster, já usou um Kubernetes Operator. Há muitos outros operators de terceiros, como Spark Operator e Postgres Operator, este último para gerenciar clusters PostgreSQL. O GizmoSQL Operator introduz a CRD GizmoSQL na API Kubernetes, permitindo gerenciar e configurar vários servidores GizmoSQL com facilidade.

Por que criar um Kubernetes Operator para o GizmoSQL?

Com ferramentas potentes como o GizmoSQL, os usuários normalmente querem gerenciar o ciclo de vida do recurso. Cada aplicação tem seu próprio ciclo, e é essencial criar uma lógica específica para lidar com cada etapa.

Por exemplo, um usuário pode executar uma tarefa noturna que processa grande volume de dados. Com volumes variáveis, a tarefa pode ultrapassar os recursos alocados e talvez até esgotar os limites de CPU e memória definidos. O Kubernetes oferece solicitações e limites de recursos, mas não ajusta dinamicamente os limites quando um processo fica sem memória. Com um operator, podemos introduzir um mecanismo que aumenta esses limites em uma porcentagem se o processo ficar sem memória e falhar. Podemos até introduzir a ideia de aumentar os limites de memória em uma porcentagem quando um pod falha ou reinicia. Mecanismos assim são essenciais para evitar interrupções em infraestruturas complexas de processamento de dados.

Por que não Helm?

Sempre que o assunto é Kubernetes Operators, surge a pergunta: por que não usar Helm? Embora seja excelente para instalar recursos Kubernetes, o Helm não é um controlador. Charts Helm são uma forma declarativa de instalar e gerenciar recursos. Eles não foram projetados para reagir a eventos ou condições que ocorrem após a criação do recurso. Pense no Helm como uma ferramenta estática e no operator como uma ferramenta dinâmica para gerenciar o ciclo de vida de um recurso.

Como usar o GizmoSQL Operator?

A primeira etapa é instalar o GizmoSQL Operator. Use o chart Helm para instalar o operator:

helm upgrade --install gizmosql-operator oci://registry-1.docker.io/gizmodata/gizmosql-operator-chart --namespace gizmosql-system --create-namespace

Isso instala o GizmoSQL Operator no namespace gizmosql-system do seu cluster Kubernetes. Depois, crie um cluster GizmoSQL aplicando o seguinte manifesto:

apiVersion: gizmodata.com/v1alpha1
kind: GizmoSQLServer
metadata:
  name: example-gizmosql
  namespace: default
spec:
  resources:
    limits:
      cpu: "1"
      memory: "2Gi"
    requests:
      cpu: "500m"
      memory: "1Gi"

Isso cria um cluster GizmoSQL no namespace padrão do Kubernetes. Confira a criação do recurso obtendo a saída YAML:

kubectl get gizmosqlservers.gizmodata.com -ndefault -oyaml

apiVersion: v1
items:
- apiVersion: gizmodata.com/v1alpha1
  kind: GizmoSQLServer
  metadata:
    creationTimestamp: "2025-12-19T02:22:13Z"
    finalizers:
    - gizmodata.com/finalizer
    generation: 2
    name: example-gizmosql
    namespace: default
  spec:
    auth:
      secretRef: {}
    image: {}
    resources:
      limits:
        cpu: "1"
        memory: 2Gi
      requests:
        cpu: 500m
        memory: 1Gi
  status:
    conditions:
    - lastTransitionTime: "2025-12-19T02:22:13Z"
      message: StatefulSet for custom resource example-gizmosql created successfully
      reason: Reconciling
      status: "True"
      type: Available
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

São criados um StatefulSet e um Service para o servidor GizmoSQL. Veja seus detalhes obtendo a saída YAML:

kubectl get pod -ndefault
NAME                 READY   STATUS    RESTARTS   AGE
example-gizmosql-0   1/1     Running   0          11h

kubectl get service example-gizmosql -ndefault
NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
example-gizmosql   ClusterIP   10.43.173.90   <none>        31337/TCP   11h

Agora você pode se conectar ao servidor GizmoSQL dentro do Kubernetes pelo nome e pela porta do serviço, ou encaminhar a porta do serviço para sua máquina local.

Quais são os próximos passos do GizmoSQL Operator?

O GizmoSQL Operator ainda está em uma fase inicial de desenvolvimento. Estamos adicionando recursos, como suporte a clusters. Acompanhe as próximas atualizações!

Recursos

Este artigo foi publicado originalmente em nima.blog por Nima Khoshini e é republicado aqui com autorização.