api-server - kubernetes backend - 404 when reading single Mesh object

[michal-franc]

Summary

Was planning to do - #283 but hit a roadblock with k8s backend returning 404 when trying to get a single Mesh.

It looks like the hardcoded namespace value default in https://github.com/Kong/kuma/blob/master/pkg/api-server/resource_ws.go#L17 doesn't work correctly with examples in https://kuma.io/docs/0.2.1/installation/kubernetes/

Example namespace: kuma-system
hardcoded namespace: default
This is related to issue - https://github.com/Kong/kuma/issues/122

Steps To Reproduce

1. start k8s (kind in this example - https://github.com/kubernetes-sigs/kind)
2. Start default kuma-cp kumactl install control-plane | kubectl apply -f -
3. forward proxy to kuma api server
4. add additional Mesh as per https://kuma.io/docs/0.2.1/installation/kubernetes/
5. call curl localhost:<port>/meshes/<mesh_name>
6. you will always get 404 even if you use correct <mesh_name>

Additional Details & Logs

• Version: 0.2.1
• Platform and Operating System: Ubuntu 18 on VirtualBox running k8s on kind

Should we move some of the details from this issue to #122 or close this one completely?

[yskopets]

@michal-franc Hi!

Thanks a lot for your interest in Kuma! Especially, your willingness to get involved and contribute.

The issue you're observing is, in fact, very relevant to #283.

It's caused by a mismatch between kubernetes and universal modes:

• all resources on kubernetes are namespaced (even Mesh)
• while in universal mode we decided to avoid k8s-like namespace in favour of tags/labels (so that namespace is nothing more than just a tag/label on a resource)

At the moment, Kuma REST API looks the following way:

GET /meshes/
GET /meshes/<mesh name>
GET /meshes/<mesh name>/<policy type>/
GET /meshes/<mesh name>/<policy type>/<policy name>

List operations work on k8s by returning resources from all namespaces.
Get operations does not work on k8s because they don't account for k8s namespace.

So, as part of #283 we need to choose the most intuitive way for users to indicate k8s namespace they are interested in.

E.g.,

1) kumactl get traffic-logs example --mesh demo --label k8s/ns=team1
2) kumactl get traffic-logs example.team1 --mesh demo
3) some other option

Once we agree on a solution for a general case, we could either apply it to Mesh as well or make Mesh a cluster-scoped resource on k8s.

@michal-franc Does it help you with #283 ? Which flavour of kumactl get ... would you prefer as a user ?

[michal-franc]

@yskopets hi
Thanks for the response. It all makes sense now.

I do understand that kumactl is a similar tool to kubectl. Based on that assumption the best idea is to mirror conventions present in kubectl it would mean having an option like.

kumactl get traffic-logs example --mesh demo -n team1

The reason for that would be - you could easily transfer habits of using kubectl to kumactl, it would help tremendously with adoption of kumactl. I found it really useful that similar to kubectl get pods i could do kumactl get meshes.

[yskopets]

@michal-franc Having an option like -n team1 would mean that kumactl supports a concept of a namespace. So far, we've been trying to avoid that.

If you want to continue working on #283, please stay in touch with us to work out design first.

[michal-franc]

@yskopets sure I won't do too much without your input in design, I might pick up another issue, or for now create a simple dev guide on how to run kuma on top of kind

[yskopets]

@michal-franc Sounds great!

On our side, we will try to unblock you as soon as possible.

[yskopets]

@michal-franc Hi!

I've updated description of #283 to clarify expected behaviour on Kubernetes.

In short,

• we decided to start with kumactl get traffic-logs example.team1 --mesh demo option
• there will be no support for filtering by namespace

If you have any questions, we're always available on Slack

Looking forward to your PR!

[jakubdyszkiewicz]

Solved with #458