Kong Kuma Community, 3 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kuma Community Call - February 3, 2021

Description

Kuma hosts official monthly community calls where users and contributors can discuss about any topic and demonstrate use-cases. Interested? You can register for the next Community Call: https://bit.ly/3A46EdD

A

Okay: okay, let's start then- and let's see uh okay, so welcome to the uh kumar community call. We have a couple of things for today. So first thing is that we released command one zero six, and can I click on this yeah? Okay? So it's mostly about uh fixes, but also I don't see this changelog, but we released gui with new charts and it looks pretty good and we are adding even more charts bart is working on this right now, so the gui will be flashy so also uh yeah in 107.

A

We will see more chats and what I liked about this release that we had many external contributors. We had one two, three four five contributors on the minor release. So that's that's pretty awesome and uh yeah. It's mostly about fixes. You can now see remote cpu version in zone inside, so that's also helpful when you're running multi-zone deployment and see all the versions whether you need to update the remote control planes or not, and we introduced the health discovery service. That's super useful on universal, because previously we had the health checks, but those health checks.

A

Works like this, that every android health checks every other android right, which uh has some advantages, that it does not depend on the control plane, but with very large deployment. uh Of course, it does not scale really well. So, with this one, uh we send the information to the control plane and the control plane propagates this information to other envoys, uh which is pretty nice, that we now see a status of the data plane, the control plane.

A

So that's so that's great and also it's more scalable with larger deployments and uh what else and also we completed the v3 support in next major.

A

I suspect we will just switch to 1.1 because we also upgraded envoy in the master. So in next major you will see the envoy upgrade and v3, probably by default um and yep- that's pretty much it for the 106 release. There are a couple fixes there and yeah so x, dsb, free support uh is done and that's it. So are there any questions or demos or anyone wants to ask or share the story asking? Will you use kuma in in your current company.

B

uh I'm hoping to write some blo, so we don't. This company isn't um deploying anything internally which is kind of nice, but I hope to write some um blog posts on creating like a data mesh with kong or with kuma and our platform. So, okay, oh I'll, you I'll adjacent use. It.

A

B

Yeah, but I I definitely do have more time to um commit to kuma now at least half a day a week.

A

Okay, okay! So that's great! We are looking so forward for this.

B

Yeah, if there's anything, I can help out um bart. If you want me to do some something on the crds and you've been doing some good work over there. Let me know.

A

A

Okay, any more questions. I see that someone joined um yeah.

C

Hello, it's charlie miller.

A

Oh, hey charlie, how are you yeah all right? Okay, okay, how about.

C

A

Pretty good pretty good, we are good, I just uh run through the newest uh changelog. I don't know if you've seen this um yeah and now we have a small q a so. If you have any questions or do you want to discuss something or share your experience feel free to.

C

No, um no on our side we're making progress on what we want and um still discovering a few things, but everything's sort of clear in some ways.

A

Okay: okay, okay, that's pretty good! That's pretty good! I've seen this proposal of the of the dns filter.

A

Yeah! That's that's pretty nice because we can yeah. We can do a dns in a more high availability way. With this deployment right, we don't depend on the scp. So that's that's! That's pretty good yeah.

C

Thanks for reviewing.

A

Here yeah, I see there is a timeouts proposal. Do you want to say something about this? One.

D

Yeah, just a piece of information that we finished a proposal for the new policy called timeouts. If anyone.

D

I I'm right now in process of implementation, but if anyone has any questions, suggestion feel free to write in this luck or maybe as an issue on github, but anyway. I think it's worth to just check this proposal, how it will look like if anyone is interested.

A

Yeah definitely, okay, thanks for this all right, uh so we have this time out proposal.

C

One question I had is on the wish list that was shared a few weeks back um there's there is this section, this proposal about multi yeah. If you grab it, it's probably easier um about multiple ingresses, um any. It's not exactly clear to me what this is.

A

Okay, let me try to find this hole uh this one.

C

A

Okay, let's see this.

C

Yeah, this very last.

A

Point, okay, you know this is all friends uh for the community, so maybe someone uh just added this but multiple ingress per zone. You can put many instances of the ingress per zone and just put this behind the load balancer right so yeah. So I'm not sure what what is it.

C

About so my my guess, so that's me that commented there. um Okay, my guess was maybe if you have too many meshes, you might just want to have ingresses that are responsible of a subset of meshes so that there's not too much configs or even like you know. If you have one very busy mesh and then like other meshes, and you don't want traffic to just be melted on to be mixed together on the same ingresses.

C

I don't know that was my guess. Okay,.

A

Okay, maybe uh maybe, but at the same time then you've got more complicated deployment because you need to like deploy ingress for every mesh. But here is the ingress per zone right. So I'm also a little bit confused by this.

E

Hey jacob, actually, uh I have a couple of questions when it comes to ingress since we're already talking about this. Okay today it seems like there is a mesh requirement for the ingress resource, but that mesh requirement should not be there because really an ingress, it's not associated to any specific mesh. It's for all the meshes.

E

So that's one um and then two today for the english resource, it is possible to create accumulation service stack, which potentially could uh allow somebody to effectively in you know, make the ingress look like a legitimate service, whereas perhaps the human.your service tag for the ingress should be automatically generated.

A

E

Yeah, okay, we know we know option of being able to change it.

A

Yeah so the first question about the mesh requirement in the resource. That's true that, right now we require the mesh, because it's a data plane resource right and every data plane resource is a mesh scoped resource. So we don't use this uh when we generate configurations. So that's kind of confusing. I agree here.

A

We picked the the path of embedding ingress into data plane definition, because it was more convenient at that time that we thought that was the right way, but now that we see this probably worth to create separate resource called uh zone ingress right, which is global resource, not much scope, tweezers and then you know you have less common confusion about about this.

A

So that's the first thing and the second thing about the commando title service.

A

Even if you put comma dot io service of any service in the mesh, I don't think it will break anything right, because when we how to how to say this, when we generate configuration with endpoints of of of a service, we treat the ingress data planes in a special way right, so that shouldn't break anything and also ingress itself uh is not asking for mtls certificates. So that's uh that's also. Okay, but you're, probably right that it's a little bit weird, that uh comada tails service that you can kind of control this.

A

Maybe we should just how to generate uh the name and hard code this. So all the ingresses has the same. You know commando tiles service name or maybe we can just you know, get rid of get rid of this.

E

Which, which seems to be one more reason to deviate from the original implementation of trying to reuse data plane for ingress as well, because this is yet another exception that we're going to be adding for the english resource.

A

That's true: maybe this yeah, maybe the zone ingress resource, should not have tags at all right, since we are not matching any policies on top of this. Maybe it doesn't make sense for the zombingers to have facts.

E

So what does the rest of the group think about that about introducing a new ingress resource? That's different from data plane.

D

I agree with this.

D

I mean we need to have separate resources for ingress. That's good idea.

C

Yeah I agree like ingresses are very confusing at first like coming from the outside is just like it's a data plane, but it's it's not very, not really a data plane. It belongs to a mash, but actually it belongs to all the meshes um yeah. It's it's a little confusing at the moment and making it separate would probably simplify things.

E

Which brings me to a natural second question: should the gateway also be a specific resource or is for now is having the gateway being part of the data plane? For now, a good good decision still.

A

I think the gateway was a good decision, because it's very similar right because gateway for now at least is a mesh scoped resource. You need to have a gateway per mesh and you need those stacks for mtls certificate.

A

So for the gateway itself. I think it was the right decision, but ingress is a little bit too far from the regular data plane.

E

Very well, it seems like a decision was made. You should uh write, write this decision down when it comes to ingress in the in the dark in the community.

A

E

In the community.

E

No, I mean that in the blog for the community as well.

A

uh Sorry, okay.

A

Spread some ingress resource.

E

Yeah we'll do a proposal and then uh and then give give the chance to anybody else to comment on the proposal. Once it's been opened.

A

Yeah, that's probably a good idea to do in one 1.1 right, since that's uh that's a breaking change. Of course, we would need to kind of support both uh but still 1.1, probably our next um major version after after that, okay cool cool, so that was uh that was interesting. Any other uh interesting thoughts to share to discuss.

E

um Austin and charlie since you're here is there anything in your mind that you would like to bring up or perhaps something that's been circulating in the back of your head. That's been either bothering you or a suggestion. You would like to brainstorm about.

C

um I mean this ingress stuff was definitely like something like I find. This is once you understand it, you you understand it but like it definitely took me a while to get it so this would definitely help people getting started with kuma and then one one thing that is tricky for us is um the the gateway being per mesh, um because we're planning to actually have like quite a bunch of matches, um and it would just be easier to have one gateway that then redispatches to all the mesh.

C

We're jointly looking at hacking the ingress um to be able to do that in practice, um but hey, that's, not that's kind of a dirty way to do it. So I wouldn't recommend pushing that upstream.

C

And the final, the other thing that we were chatting about internally was about ports on the vip, um as in currently the vips just force you to be on port 80, which technically doesn't like, is just a port. Who cares, but um from a user point of view, people just sometimes get confused if they can't use their usual ports for their services.

C

I I don't know if I, if you're running postgres, you expect like using the postgres port and not 80, that's more from the user of the mesh point of view. um So yeah we were thinking about ways we could um expose the port um expose with the vip, a port that was in port 80.

C

um and it looks like it could be possible to just add metadata to an outbound. um That would then be able to be reused um for the.

A

For the maybe not okay, it's because um it's because we took this decision that, um even if you have one application with two parts right so, for example, I don't know you have conch and uh kong have a part two proxy traffic, and there is a part called congratme to kind of manage concrete.

A

We treat those two as a separate services in kuma, right, yeah, so our yeah, so our approach was to just you know, take the service tag, dot mesh and make this explicit right. That's this is uh this is the address.

A

With the metadata with yeah, so technically you could. We could implement this uh with some special tag on the inbound. So imagine you have this situation right and you put on the on the conch proxy inbound special tag, for example, comma dot, io, slash vport with some part right and then, once you have this information when you generate veep, you can use this information and you know generate the outbound with a proper part, not not 80, but with a part that you picked yeah.

C

That was what we were thinking about.

A

C

Doing um but I'm wondering if it's worth like making a proposal and maybe like pushing it upstream or if it's something that it's not worth it.

A

Yeah, I mean it depends. uh How important do you think is this in your use case right if uh this is important for some reason, then sure I mean it, it is an optional feature right, which should which probably won't cause that won't cost us that much right.

A

If this is opt-in and not a default, then then, why not.

E

Okay, looking back looking back choosing port 80, you know port 80, it's already being associated in the mindset of people as being a part, that's already familiar for other use cases. Perhaps you know looking back, you know, besides the fact that we should or should not add a way, for you know, choosing your own port.

E

We should have in the first place, choosing a port that was not four days like something that was associated to cuba. You cannot mistake it for anything else. Like you know, four four, four four part 80 just raises more questions, because people associate that part with a different use case as opposed to a part, that's not being associated with any use case because it didn't exist in you know elsewhere.

E

um When it comes to the gateway feedback, it seems like a gateway if we have one gateway that can consume potentially multiple meshes.

E

It seems like this is indeed very similar to the ingress use case, yet I'm thinking we should still allow the user to lock it down for one specific mesh. If there are services in another mesh that should never ever be exposed in the first place.

A

Yeah, the gateway is a little bit tricky because.

A

I think we would need to essentially implement the cross.

E

Because you would.

B

E

Because you have to have to connect to effectively different, because different meshes could potentially have different certificate authorities. Therefore yeah it would be tricky.

A

Yeah yeah, so that's the one thing that you need to have certificates for different ma for different measures, and the second thing is that our whole envoy, config generation is built with an assumption that everything is mesh scoped right, every every policy, every end point that we are trying to consume and so on right. So I'm not saying that's impossible to introduce and implement right be because of course it is, but uh it won't be super easy yeah.

C

Yeah, I I agree, it's not it's not easy and it's going like sort of against the way like kuma's.

C

um The way the way we ended up doing it is we have like a special mesh and we we have a fork of kuma with like the few hacks that, like either we haven't pushed upstream yet or we just don't- think it's worth pushing upstream, um but uh in in in this, we ended up having a special mesh that has its ca and the ca is injected on every single other mesh, and we have the ca of every single mesh on this like master mesh.

C

So and then we also end up hacking, the spiffer on the on the receiver side, um so that you you accept like like, so that the mtls actually does work out, um which, which is why I was saying I don't. I don't think it's very nice and I don't think it should be pushed upstream and there's probably a nicer way to do it.

C

Another way we we could, we could have been maybe thinking about it was having like a specific ca, um but it's yeah. It's it's tricky.

A

Yeah it is, it is uh yeah, but this is a feedback that we are hearing from like many many users, customers so yeah. Eventually, we will need to somehow implement the cross mesh communication in some form or introduce a gateway which is on top of every mesh.

A

By the way, uh is your fork of coma available on on github, or is it in a in a private repository.

C

I think I think it's private, but I could I. I need to double check with the the rest of the team, but I don't think there's anything actually private in there. um So so I could. I could just make it public. I think it was just made private because I don't know.

A

Okay, yeah. That would be really interesting to see your hacks right.

C

Yeah yeah well they're, not pretty.

A

Well, but they work right as well for for your for your use case. So still, it's probably worth checking them out.

A

uh Okay, um we are one minute over very good time. So so thanks for joining and see you in two weeks and if you have any more questions, you can catch us on kumaslak see you everyone.

C

B