Content of the repo

[renehernandez]

Would this repo store plain kubernetes manifests, or is the plan to support multiple deployment options?, e.g:

• Helm charts
• Kustomize
• Plain kubernetes manifests

[tpayet]

Hi @renehernandez, initially I created this repo in order to get these manifests here.

I am not familiar with kustomize so far, but I guess we could have the plain manifests & the helm charts. If the kustomize file seems good to have here in your opinion we should too :)

What I would like to have is when developers search to deploy MeiliSearch on K8s, they should end there and the README should redirect them to the appropriate way of deploying it on a K8s cluster according to what they are used to do.

Are you a kubernetes user yourself?

[renehernandez]

Are you a kubernetes user yourself?

Yes, I work with kubernetes in AWS at our company. I have deployed Meilisearch on kubernetes using a helm chart I created for it.

What I would like to have is when developers search to deploy MeiliSearch on K8s, they should end there and the README should redirect them to the appropriate way of deploying it on a K8s cluster according to what they are used to do.

That seems like a good idea. The only concern there is that supporting multiple ways to deploying to kubernete means that every time you are doing a change you need to verify that change is replicated across the different tooling

I am not familiar with kustomize so far, but I guess we could have the plain manifests & the helm charts. If the kustomize file seems good to have here in your opinion we should too :)

I haven't used kustomize in the past, I was asking about it because I know it has traction in the community. IMO, I will start with a helm chart for deployment ( I may be biased here 😂 ), but that will also require to provide a chart repository for developers to be able to fetch the chart and avoid copying it from source

[renehernandez]

I am going to look if I can open source the code for the meilisearch chart

[tpayet]

The only concern there is that supporting multiple ways to deploying to kubernete means that every time you are doing a change you need to verify that change is replicated across the different tooling

Yes, I get your concern.. I do not have any solution in mind so far to avoid this situation..

but that will also require to provide a chart repository for developers to be able to fetch the chart and avoid copying it from source

You're right! I can create a meilisearch/meilisearch-helm repository for this once we have a improved README on this K8s repository ^^ We used k8s internally, so I also have some manifests on my side but they are pretty basic with a deploy, a private volume claim & a service. I only tried them on DO k8s, so maybe they are not universal.. Do you think we should also provide an ingress manifest?

[renehernandez]

Do you think we should also provide an ingress manifest?

Definitely, an ingress allows for customizing host and rules access to the service in the cluster.

Also, in my case I went with a statefulset instead of a deployment

[rio]

Hi everyone, I was the one that suggested kubernetes manifests and @tpayet initially invited me as an maintainer. However vacation and other stuff happened so by the time I got around to it the invitation expired :sweat_smile:, sorry about that.

The initial manifests I wanted to post were kustomize based as is just about everything in our clusters. I'm a big fan of it especially with the components that got introduced in 3.7.0. That said helm charts is probably what the majority of people use and it would be a shame if people would skip this just because of tooling. The downsides of both kustomize and helm is that you can't simply apply them with a kubectl apply -f ./ and because the files on disk do not represent the final output sent to the cluster some unexpected transformations can still occur. Being able to use just git diff the local files is extremely nice to determine if any changes are incompatible with your deployments.

A solution that I've seen is that the helm chart is the primary development target and before release use helm template ./ to generate a set of manifests that get tagged along with the actual helm chart. I think that would be a good place to start. Later on we can add variations if needed.

[tpayet]

Hey @Rio :) Thanks for coming back!

Are you saying that we could have manifests automatically generated using helm template that we could commit on this repository? Indeed that sounds a good place to start :)

[rio]

Exactly. A good example is cert manager's repo.

This way people that quickly want to helm install to play with things can still do so while other operators that like to add customizations and see exactly what is going on in their manifests can still do all of their git and yaml foo. They can even use something like kpt or raw kubectl apply -f https://github.com/meilisearch/meilisearch-kubernetes/releases/download/v0.13.0/ha-install.yaml without trouble.

[Bajix]

See https://github.com/Imagine-Impact/meilisearch-helm for a reference chart I previously created

[eskombro]

Hey @Rio thanks, following that idea I added manifests and a little getting started in the README.md. Can you have a look at https://github.com/meilisearch/meilisearch-kubernetes/pull/10 ?

[eskombro]

Thanks for your contributions!!! 🎉