Consultoría de Kubernetes en Pittsburgh y Cleveland

Diseño de clústeres en servidores físicos o en Proxmox

Un clúster puede ejecutarse directamente en servidores físicos o en máquinas virtuales bajo Proxmox. El hardware físico da a los nodos acceso directo al equipo. Las máquinas virtuales de Proxmox facilitan las instantáneas, las reconstrucciones y los clústeres de prueba. Elegimos junto con usted, según su hardware, sus aplicaciones y quién lo va a operar.

• Plano de control: suficientes nodos para que el clúster siga funcionando cuando uno falla.
• Almacenamiento: volúmenes persistentes respaldados por discos locales o por almacenamiento Ceph, según lo que necesiten sus datos.
• Acceso: ingress, certificados TLS y quién puede llegar a la API del clúster.

Entrega y operación

Mantenemos la configuración del clúster y de las aplicaciones en control de versiones. Un cambio es una solicitud de fusión en GitLab, y el clúster sigue al repositorio.

Operar significa actualizaciones, monitoreo, alertas, respaldos y capacidad. Dejamos por escrito cómo funciona cada pieza, para que su equipo o el nuestro pueda operarlo. Para profundizar, lea las guías de Kubernetes y las guías de Talos Linux de nuestra base de conocimiento.

Cuando Kubernetes no es la respuesta

Un clúster requiere más trabajo que un solo servidor. Una sola aplicación con una base de datos suele funcionar mejor en una máquina virtual Linux con respaldos adecuados, algo que cubre nuestro soporte de servidores Linux. Unos pocos contenedores en un host se ajustan a Docker y Docker Compose.

Recomendamos un clúster cuando necesita conmutación por falla entre máquinas, actualizaciones graduales o muchos servicios que deben programarse en conjunto. Si tiene dudas, nuestra descripción general de Linux y Kubernetes muestra cómo se comparan las opciones.

Cómo funciona un proyecto

1. Llamada de diagnóstico. Averiguamos qué ejecuta, qué debe permanecer en línea y quién lo va a operar.
2. Alcance por escrito. Un diseño o una revisión, con el orden de los trabajos y el plan de respaldo y reversión.
3. Construcción y entrega. Desplegamos, probamos la falla y la restauración, y documentamos la operación.
4. Operación continua. Opcional, con un ingeniero asignado y sin ataduras.

Nuestras oficinas están en Coraopolis y Beaver Falls, Pennsylvania. El trabajo en sitio en el área de Cleveland se coordina según el proyecto, y el soporte remoto está disponible en todo el país. Respondemos en un día hábil.

Preguntas sobre la consultoría de Kubernetes

¿Pueden hacerse cargo de un clúster que construyó otra persona?

Sí. Primero revisamos los nodos, los accesos, los respaldos y el método de despliegue, y luego corregimos problemas específicos o asumimos la operación.

¿Por qué Talos Linux?

Talos no tiene shell ni administrador de paquetes. Los nodos se configuran mediante una API, lo que los mantiene idénticos y reduce lo que puede configurarse mal o ser atacado.

¿Necesitamos Kubernetes para nuestra aplicación?

Con frecuencia no. Se lo diremos en la primera llamada y sugeriremos una máquina virtual Linux o Docker si alguno encaja mejor.

¿Pueden pasar nuestras cargas de trabajo de Docker a Kubernetes?

Sí. Convertimos los servicios de Compose a charts de Helm, movemos los datos, probamos y hacemos el cambio en el horario que usted apruebe.