Deployment in Kubernetes

[butonic]

links

• https://github.com/rak8s/rak8s for kubernetes on raspberrypis

[tboerger]

For Kubernetes itself you don't even need Ansible, you should give k3s a try: https://medium.com/@mabrams_46032/kubernetes-on-raspberry-pi-c246c72f362f

[refs]

I implemented a quick draft using Helm and minikube, it can be found here

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[pascalwengerter]

@refs can this be closed since you introduced https://owncloud.dev/ocis/deployment/kubernetes/ ? 🤓

[wkloucek]

@refs can this be closed since you introduced https://owncloud.dev/ocis/deployment/kubernetes/ ? nerd_face

I'll close this since it doesn't give additional information on what we have right now. Current work on this is tracked on another (sadly internal) ticket.

[georglauterbach]

Even though this was closed, I'd like to provide some feedback that might be useful for your "internal" ticket.

The docs under https://owncloud.dev/ocis/deployment/kubernetes/ sadly aren't that great. They explain what K8s is, but there is no point in doing this. People that want to know more about K8s wont be looking it up in the oCIS docs. When I visit the oCIS docs for K8s, I'd like to see

1. an overview of a possible Helm chart, where to got it and how (and I really won't clone a git repo to install a Helm chart...)
2. information on what deployments, services, etc. are to be run
3. what about the storage (provide a simple example with Longhorn maybe?)
4. how to compose the ecosystem if you're not using Helm

A git diff file, or external identity providers are unfit to explain how or why I'd go for oCIS. And seeing that oCIS is advertised as massively scaling, K8s support is quintessential for a good documentation!

At least I find myself in no better position at writing a deployment or a service when finished with the current article than before, i.e. the documentation failed its purpose...

[wkloucek]

@georglauterbach Thanks for your feedback!

Even though this was closed, I'd like to provide some feedback that might be useful for your "internal" ticket.

The docs under https://owncloud.dev/ocis/deployment/kubernetes/ sadly aren't that great. They explain what K8s is, but there is no point in doing this. People that want to know more about K8s wont be looking it up in the oCIS docs. When I visit the oCIS docs for K8s, I'd like to see

It's definitely also outdated. I'm on this. Yesterday I also added basic documentation to the helm chart itself: https://github.com/owncloud/ocis-charts/tree/structure-and-documentation/charts/ocis. I think we should also try to have the documentation mostly in the owncloud/ocis-charts repo and reference it only or sync it to owncloud.dev. What do you think about it?

1. an overview of a possible Helm chart, where to got it and how (and I really won't clone a git repo to install a Helm chart...)

There's already a ticket for it owncloud/ocis-charts#3. oCIS is currently in Tech Preview phase and therefore breaking changes can happen at any time. We will soon enter the BETA phase for version 2.0, so things will become more stable. We then also can confidently maintain a stable Helm Chart. I'm not sure if it's really a blocker for releasing the Helm chart as it is, but we would definitely mark it as unstable.

2. information on what deployments, services, etc. are to be run

I agree, that's also an general oCIS documentation issue since there is no (up to date) overview of all services and there interaction.

3. what about the storage (provide a simple example with Longhorn maybe?)

persistent storage was added recently (eg. https://github.com/owncloud/ocis-charts/blob/6155c38a5ea2112ea76eb6d1c3649d696f52b82a/ocis/values.yaml#L71-L92).
I didn't see that much focus on different storage in Helm Chart documentations, do you have an good example for that?

4. how to compose the ecosystem if you're not using Helm

Do you mean how to run oCIS on Kubernetes without Helm or no Kubernetes at all?

A git diff file, or external identity providers are unfit to explain how or why I'd go for oCIS. And seeing that oCIS is advertised as massively scaling, K8s support is quintessential for a good documentation!

I agree that Kubernetes is the go-to tooling for massive scaling. Therefore it needs first-class support and documentation.

At least I find myself in no better position at writing a deployment or a service when finished with the current article than before, i.e. the documentation failed its purpose...

I'm sorry about this and can fully understand that and we are working to improve on that. I would be interested on your usecase for oCIS. Can you tell me something about it?

[georglauterbach]

I think we should also try to have the documentation mostly in the owncloud/ocis-charts repo and reference it only or sync it to owncloud.dev. What do you think about it?

From personal experience in another project, only maintaining it in one place and referencing this one place is the best option in my opinion.

persistent storage was added recently (eg. https://github.com/owncloud/ocis-charts/blob/6155c38a5ea2112ea76eb6d1c3649d696f52b82a/ocis/values.yaml#L71-L92).

That looks quite good!

I didn't see that much focus on different storage in Helm Chart documentations, do you have an good example for that?

My main concern was that the Helm chart also provided an option for the storageClass (which every good Helm chart should). Seeing as the current chart does, all is well and we need not worry about this note anymore.

4. how to compose the ecosystem if you're not using Helm

Do you mean how to run oCIS on Kubernetes without Helm or no Kubernetes at all?

When you're using oCIS in K8s without Helm (writing all by hand). This ties together with an understanding of all services, etc. If the docs are clear about what images to run etc., this point resolves itself.

I agree that Kubernetes is the go-to tooling for massive scaling. Therefore it needs first-class support and documentation.

👍🏼

I would be interested on your usecase for oCIS. Can you tell me something about it?

I'm running my own infrastructure in K8s and I would like to have a very simple go-to cloud solution. Current ownCloud demands an external SQL database which I certainly don't need. While I made a point about "massively scaling", in my case I need scaling (down) to 1 - 3 persons :D I thought oCIS might be a good option for this seeing that only one image is needed. (I might be wrong here, please correct me if I am.) I'm also running authelia/authelia for OIDC and would like to use this with ownCloud as well.

[srgvg]

When you're using oCIS in K8s without Helm (writing all by hand). This ties together with an understanding of all services, etc. If the docs are clear about what images to run etc., this point resolves itself.

Some people prefer to manage static manifests instead of helm charts, often through kustomize. Generating something like deploy/static/, possibly via helm template and some tidying up, and adding a kustomization.yaml.

[georglauterbach]

When you're using oCIS in K8s without Helm (writing all by hand). This ties together with an understanding of all services, etc. If the docs are clear about what images to run etc., this point resolves itself.

Some people prefer to manage static manifests instead of helm charts, often through kustomize. Generating something like deploy/static/, possibly via helm template and some tidying up, and adding a kustomization.yaml.

Exactly what I am doing 😆 👍🏼

[srgvg]

Exactly what I am doing

Sorry, my point is, if upstream provides a decent generic set of manifests, including a kustomization.yaml, it becomes easy to consume that by just pointing your local kustomization to it, and then further kustomizing it.

[georglauterbach]

Exactly what I am doing

Sorry, my point is, if upstream provides a decent generic set of manifests, including a kustomization.yaml, it becomes easy to consume that by just pointing your local kustomization to it, and then further kustomizing it.

Ah, I see. One could write a kustomization.yaml though that just uses the Helm chart (this is what I'm partly doing). I therefore do not see a real benefit in also maintaining a Kustomize file.

[srgvg]

Ah, I see. One could write a kustomization.yaml though that just uses the Helm chart (this is what I'm partly doing). I therefore do not see a real benefit in also maintaining a Kustomize file.

Currently, one wouyld need to manually do helm template and update manifests, which is an extra step.
As upstream, you could provide a set of manifests, as an extra next to helm charts.

For reference, ingress-nginx does this:

• https://github.com/kubernetes/ingress-nginx/tree/main/charts/ingress-nginx
• https://github.com/kubernetes/ingress-nginx/tree/main/deploy/static/provider
  (The latter with some variations depending on privider etc.)

Deploying nginx here I just need to reference one of those folders from my kustomization, and possibly add some patches via it. Very simple.

I should add that I use gitops for deployments. So an upgrade just means commiting a patch updating the version tag.