Configuración de infraestructura

Esta página describe las distintas opciones de configuración de infraestructura disponibles para su despliegue de BYOC. Estas configuraciones le permiten personalizar las redes, la seguridad y los recursos de cómputo para satisfacer sus requisitos específicos.

​

Balanceadores de carga

Las implementaciones de BYOC utilizan Network Load Balancers (NLB) para gestionar y enrutar el tráfico hacia sus servicios de ClickHouse. Puede elegir entre endpoints de balanceador de carga públicos y privados según su modelo de red. Balanceador de carga público:

• Proporciona acceso público (expuesto a Internet) a sus servicios de ClickHouse.
• Normalmente está habilitado de forma predeterminada cuando se usa una VPC dedicada gestionada por ClickHouse.
• Está deshabilitado de forma predeterminada cuando se usa una VPC gestionada por el cliente para reforzar la seguridad.

Balanceador de carga privado:

• Proporciona acceso privado (interno), accesible solo desde las redes conectadas.
• Normalmente está habilitado de forma predeterminada cuando se usa una VPC gestionada por el cliente.
• Está deshabilitado de forma predeterminada cuando se usa una VPC dedicada gestionada por ClickHouse.

Puede habilitar el balanceador de carga privado para su infraestructura BYOC directamente en la consola de ClickHouse Cloud. Para otros ajustes de endpoints (por ejemplo, eliminar el balanceador de carga público), trabaje con ClickHouse Cloud Support.

​

Security Group del balanceador de carga privado para AWS

Si decide usar un balanceador de carga privado para su implementación de BYOC, debe asegurarse de que el Security Group tenga configuradas las reglas adecuadas para permitir el acceso desde las redes privadas previstas (como las VPC con peering). De forma predeterminada, el Security Group solo permite tráfico dentro de la VPC. Para configurar el Security Group de su balanceador de carga privado: Póngase en contacto con el soporte de ClickHouse para solicitar cambios en las reglas de entrada del Security Group que permitan tráfico desde sus redes de origen específicas:

• Peering de VPC: Solicite reglas que permitan tráfico desde los rangos CIDR de sus VPC con peering.
• PrivateLink: No es necesario realizar cambios en el Security Group, ya que el tráfico no está controlado por el Security Group del balanceador de carga.
• Otras configuraciones de red: Especifique su caso para que el soporte pueda ayudarle según corresponda.

​

PrivateLink, Private Service Connect o Private Link

Para lograr el máximo aislamiento y seguridad de la red, las implementaciones de BYOC pueden usar AWS PrivateLink, GCP Private Service Connect o Azure Private Link. Estas opciones permiten que sus aplicaciones se conecten de forma privada a los servicios de ClickHouse Cloud sin necesidad de peering de VPC/VNet ni de exponer endpoints a Internet público. Para obtener instrucciones de configuración paso a paso, consulte la guía de configuración de red privada.

​

Conexión privada a la API de Kubernetes

De forma predeterminada, el endpoint del servidor de la API de Kubernetes de tu cluster BYOC es accesible desde la Internet pública. En AWS, el acceso está restringido mediante filtrado de IP para permitir solo las IP del gateway NAT de ClickHouse; en GCP y Azure, en cambio, está controlado por el IAM de la nube (consulta Exposición del servidor de la API de Kubernetes). Para mayor seguridad, puedes restringir el servidor de la API de Kubernetes para que sea accesible exclusivamente a través de conexiones de red privadas. Las opciones de conexión privada disponibles dependen de tu proveedor de nube:

​

Tailscale (predeterminado)

Cuando se habilita un endpoint privado de la API, el servicio de administración de ClickHouse se conecta al servidor de la API de Kubernetes a través de la misma red de confianza cero de Tailscale utilizada para el acceso de resolución de problemas. Consulta Red privada de Tailscale para obtener detalles sobre cómo funciona esta conexión.

​

AWS VPC Lattice

Para las implementaciones en AWS, también se puede acceder al servidor de la API de Kubernetes de forma privada a través de AWS VPC Lattice, sin intervención de componentes de terceros:

• ClickHouse Cloud aprovisiona automáticamente un VPC Lattice Resource Gateway y una Resource Configuration dirigidos al endpoint del servidor de la API de EKS dentro de tu BYOC VPC, y comparte la Resource Configuration con la cuenta de administración de ClickHouse Cloud mediante AWS Resource Access Manager (RAM).
• El tráfico entre el servicio de administración de ClickHouse y tu servidor de la API de Kubernetes permanece por completo en la red privada de AWS.
• El recurso compartido de RAM se crea desde tu cuenta y se limita a un único cluster de BYOC; al eliminarlo, se revoca inmediatamente la ruta de acceso privada.
• Dado que el acceso no depende de un agente que se ejecute dentro de tu cluster de Kubernetes, el soporte de ClickHouse mantiene el acceso para la resolución de problemas incluso si los componentes dentro del cluster no están disponibles.

​

Endpoint privado del plano de control en GCP

En las implementaciones de GCP, es posible deshabilitar el endpoint del plano de control basado en IP del cluster de GKE para que deje de ser accesible desde la internet pública. En ese caso, los servicios de administración de ClickHouse acceden al plano de control a través de su endpoint basado en DNS (*.gke.goog), cuya autorización no depende de una lista de IP de origen permitidas, sino del permiso de IAM container.clusters.connect asignado a la cuenta de servicio que ClickHouse suplanta en su proyecto.

• El acceso se rige íntegramente por el IAM de la nube de su proyecto, de modo que, al revocar ese permiso, se revoca también la ruta de acceso.
• La solicitud termina en el frontend de Google y no dentro de su red VPC, por lo que debe evaluarse como una ruta de acceso a su plano de control y no como un enlace de red privado.
• Los ingenieros de ClickHouse siguen utilizando Tailscale para el acceso de resolución de problemas.

​

Azure Private Link

En las implementaciones de Azure, se puede acceder de forma privada al servidor de API de AKS a través de Azure Private Link:

• El cluster se crea como cluster privado con API Server VNet Integration y con su FQDN público deshabilitado.
• ClickHouse Cloud aprovisiona en su suscripción un Private Link Service delante del balanceador de carga interno del servidor de API, junto con el private endpoint correspondiente en la VNet de administración de ClickHouse Cloud. La conexión solo se aprueba automáticamente para la suscripción de administración de ClickHouse Cloud.
• El tráfico entre los servicios de administración de ClickHouse y su servidor de API no sale de la red troncal de Azure.
• Los ingenieros de ClickHouse siguen utilizando Tailscale para el acceso de resolución de problemas.

Póngase en contacto con el soporte de ClickHouse para solicitar la configuración de un endpoint privado de la API.

​

Grupos de nodos

Los grupos de nodos de Kubernetes son conjuntos de instancias de computación que proporcionan los recursos necesarios para ejecutar sus servicios de ClickHouse en un despliegue BYOC. ClickHouse Cloud administra estos grupos de nodos y gestiona automáticamente tanto su configuración como su escalado.

​

Configuración predeterminada

Los clústeres BYOC se aprovisionan con dos tipos principales de grupos de nodos:

• Grupo de nodos del sistema Aloja cargas de trabajo esenciales del sistema, como ClickHouse Operator, Istio (para la malla de servicios), componentes de monitorización (Prometheus, Grafana, AlertManager), cluster autoscaler y otros servicios principales. Estos nodos suelen usar tipos de instancia x86 estándar.
• Grupos de nodos de carga de trabajo Están dedicados a las cargas de trabajo de datos de ClickHouse, incluidos los servidores y los servicios de Keeper. Por defecto, los nodos de carga de trabajo se ejecutan en instancias basadas en ARM, lo que ofrece un equilibrio eficiente entre rendimiento y coste. No obstante, también pueden configurarse con perfiles alternativos de CPU/memoria o cambiarse a la arquitectura x86 a petición.

​

Personalización de los grupos de nodos

¿Necesita recursos o arquitecturas especializadas? Estas personalizaciones están disponibles; póngase en contacto con el soporte de ClickHouse para analizarlas e implementarlas:

• Selección del tipo de instancia Elija tipos de instancia específicos para satisfacer requisitos como rendimiento, cumplimiento normativo, alta capacidad de memoria/CPU o el uso de recursos reservados.
• Relaciones CPU/memoria Ajuste el perfil de cómputo de sus grupos de nodos de carga de trabajo según sea necesario.
• Arquitectura Cambie los grupos de nodos de carga de trabajo de ARM a x86 si es necesario.

Nota: Las instancias Spot (interrumpibles) no son compatibles; todos los grupos de nodos de BYOC se ejecutan en instancias bajo demanda de forma predeterminada.

​

Escalado automático

Los grupos de nodos del clúster escalan automáticamente mediante el cluster autoscaler, en función de:

• Solicitudes y límites de recursos de los pods de Kubernetes
• La capacidad y utilización generales del clúster
• Las necesidades de escalado del servicio de ClickHouse

No se requiere intervención manual. ClickHouse Cloud se encarga de la gestión continua de los recursos y del escalado de su implementación.