Add helm chart #331
No reviewers
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#331
Loading…
Reference in New Issue
No description provided.
Delete Branch "chemicstry/garage:helm_chart"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR adds helm3 chart for deploying garage on k8s clusters.
This is based on template created by
helm create
, so it has a lot of configuration options. It makes the charts a bit complicated to read, but might be useful for more advanced deployments, so I kept it.WIP: Add helm chartto Add helm chart@ -0,0 +8,4 @@
dataDir: "/mnt/data"
replicationMode: "3"
rpcBindAddr: "[::]:3901"
rpcSecret: "1799bccfd7411eddcf9ebd316bc1f5287ad12a68094e1c6ac6abde7e6feae1ec"
Does it mean that if people deploy this helm chart without overriding this value,
they will have a working but vulnerable cluster?
We have some discussions about adding some defense in depth mechanisms to Garage (here: #310) in case this secret leaks but for now, an attack knowing this secret could join the clusteras long as the RPC port is accessible.
I think it could be better to replace this field by something that will make the cluster crashes if not overriden, like "CHANGE ME!!!!"
Good point. I think it would be best to store rcpSecret as a kubernetes Secret object, which is randomly generated if not provided, but then there is a problem how to inject that into container configuration. It would be easier if garage accepted configuration through env vars. Otherwise I think the only option is to fire up an init container and patch up configuration toml.
@ -0,0 +1,73 @@
# Garage helm3 chart
Could you put this file in the
/doc/book/cookbook
folder renamed askubernetes.md
, so it will be part of Garage's documentation.Then add some headers at its top, eg.:
You can keep this
README.md
file to inform people that the doc on K8S is located at/doc/book/cookbook/kubernetes.md
or https://garagehq.deuxfleurs.fr/documentation/cookbook/kubernetes/ (the URL does not work yet of course)
Moved documentation to book and implemented an automatic secret generation if one is not provided.
I'm not sure if it is okay to delete secret object when helm chart is deleted. If I understand it correctly, the RPC secret is only used for authenticating peers, but data is not encrypted? In that case it is okay to delete it and cluster can still be recreated if volumes remain intact.
Yes the RPC secret can be regenerated at any time, it's only used for live communication between nodes and doesn't impact data on disk.
Thanks a lot for your contribution @chemicstry and your quick response to my suggestions, I am sure your work will ease the life of K8S operators :-)
For the rest of your PR, I will let Maximilien review it: he knows K8S way better than me.
I'm still validating a couple of things related to the ingress default values.
I wasn't sure if two ingress rules are the way to go. This way you get more flexibility to configure each separately, but you lose the ability to have them both on the same domain with different path prefixes (correct me if I'm wrong).
889d196944
todb0c8b3980
Good for merge
LGTM, for a first try at least