Add helm chart #331
No reviewers
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#331
Loading…
Reference in a 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