Tengo los siguientes requisitos para que mi aplicación se implemente en Kubernetes Cluster. Estoy tratando de idear una arquitectura que se asemeje a mi otra implementación de microservicios y que no sea complicada.

• Los nodos del servidor de la base de datos deben tener capacidad reservada
• Cuando la utilización de la CPU supera el 60%, debería generarse una nueva instancia de base de datos
• La aplicación y la base de datos residirán en el mismo clúster.
• Necesidad de soportar alta consistencia (NO consistencia eventual)

Estoy pensando en tener múltiples réplicas que se conectarán al mismo volumen (NAS en mi caso). Las instancias de Postgres se ubicarán detrás de un servicio como los microservicios de mi aplicación. La aplicación se conectará al servicio y no necesita saber con qué instancia de Postgres está hablando. Esto simplifica mucho mi arquitectura, ya que no tengo que preocuparme por configurar la replicación de Postgres.

Un problema en esta arquitectura es qué sucede con los datos si una instancia de Postgres deja de funcionar después de recibir una solicitud de escritura. Puedo presentar un intermediario de mensajes con reconocimiento del consumidor para manejar este escenario, pero eso tiene alguna implicación en el rendimiento.

A continuación se muestra un ejemplo de configuración de implementación de Postgres K8s. Tendré que agregar servicio, etc.

¿Cuáles son algunas trampas de esta arquitectura? ¿Alguien ha implementado algo similar?

 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: postgres spec: replicas: 3 template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:latest imagePullPolicy: "IfNotPresent" ports: - containerPort: 5432 envFrom: - configMapRef: name: postgres-config volumeMounts: - mountPath: /var/lib/postgresql/data name: postgredb volumes: - name: postgredb persistentVolumeClaim: claimName: postgres-pv-claim