Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve deployment on Kubernetes #13

Open
8 tasks
mattrent opened this issue Feb 24, 2023 · 0 comments
Open
8 tasks

Improve deployment on Kubernetes #13

mattrent opened this issue Feb 24, 2023 · 0 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@mattrent
Copy link
Member

mattrent commented Feb 24, 2023

The kind/Kubernetes deployment currently has some issues; this is meant to be a meta-issue, to simplify grouping them up and potentially adding problems found while testing.

  • Postgres password/user are hardcoded and visible; they should be treated as secrets and potentially given by the system administrator (see also issue Handle SECRET_KEY_BASE as k8s secret/env file #5)
  • Filebeat, ElasticSearch and Kibana are not present in the Kubernetes deployment (they are in the docker-compose version)
  • Core pods should have a wait-for-postgres InitContainer, to have them wait until init-postgres has completed before starting deployment (avoiding potential initial crashes)
  • postgres data should be persistent (i.e. we should give postgres both a PersistentVolume and a PersistentVolumeClaim to ensure the service works properly even after restarts)
  • init-postgres job could have a wait-for-postgres InitContainer, instead of a while command waiting for postgres (makes it easier for logs and diagnostics to see if it's stuck in an InitContainer instead of the main one)
  • When a core is restarted, the DB migration and seeding is run again, causing an error as the database was already seeded; this might just be solvable by catching the constraint exception directly in the core component
  • core and worker pods should be able to coexist (right now they both depend on the fl label to be deployed, and are mutually exclusive)
  • Replicas of postgres should be coupled with the instances of core. This might require changes also on funless itself, but would allow us to exploit co-location of data with the actual service, reducing latency for database operations (as of right now postgres and core are simply deployed on core nodes, but no explicit coupling is specified)
@mattrent mattrent added enhancement New feature or request help wanted Extra attention is needed labels Feb 24, 2023
@mattrent mattrent self-assigned this Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant