Cloud Native Computing Foundation Service Mesh Interface, 7 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF Service Mesh Interface Project 2021-04-07

Description

CNCF Service Mesh Interface Project 2021-04-07

A

Okay, welcome to this special edition of the smi 20 meeting today. We're gonna focus on and talk about a multi-cluster discussion, as captured in issue two one two and um if you haven't yet, please add yourself to the the google docs I shared early on on the chat. um That's always super useful and I don't know if you all had a chance to have a look and- and if not, you might want to do it now for for a few minutes worth.

A

um If not I I or I can also share the the um a quick screen share. If I'm allowed. Okay, I'm not allowed, uh can someone else who is allowed to share their screen uh open the the issue 212 and share the screen so that we can have a look at that together.

B

You should be able to share your screen now. I'm making.

A

Sure, okay, uh awesome! Thank you very much. um I want a window. um Google chrome that looks great. How about that?

A

Can you see um my screen here.

B

Yes, we can it's a little small for me.

A

um That might well be how about now is that better.

B

Yeah, that's better thanks.

A

Cool so uh nick, do you want to say something or.

C

C

So I think, there's a number of assets on that, but the fact that smi configuration should take advantage or should consider multi-cluster capabilities and but also to kind of come up with or to promote a way that leads uh a way of many different vendors to come together to work towards a single specification that benefits everybody.

C

So we created this issue just to kind of like settle a bit of context into you know to capture some feedback around whether this would be something that the community would like to see and if so you know some of the things that they would like to see and how smi would be able to to help with this.

C

So that issue, you know predominantly just set out the problem, as I saw it, and a lot of really good folks, adding adding their opinions in there and.

C

Yeah, that's just the kind of contact.

A

Right right thanks a lot, and I think that that makes and summarizes the the issue at hand uh perfectly well. I will point out in case you haven't seen it yet, and I think it is this one. Let me double check. um Yes, that's the one! So if you are not familiar with with that cap, which the cab is itself, I think relatively recent a couple of.

C

Wow, I've not responded to this, but I think there's a differentiation between service match, multicollector and kubernetes multi-cluster and- um and I think you've got different different considerations when it comes to actually running a workload and controlling the communication of a workload. So I'm not 100 certain is my opinion. um I'm not 100 certain that the sort of the kubernetes cap around multi cluster is particularly applicable to this issue. But maybe that's the topic for discussion.

D

As well, I uh tend to agree with nick on this, um so this um spec from kubernetes right so depending on how we are thinking about the service mesh right, so one of without getting even before getting into the details of this kubernetes spec right.

D

So if we are thinking in the service mesh as something that goes beyond kubernetes or is above kubernetes in terms of where it sits in terms of the infrastructure construct, then obviously uh you know kubernetes spec is not gonna do the work, um and uh even if it does today, which you know I don't know right, we have to sit down and see which are the requirements and how well does it match, but there can be divergences in the future right, because the equivalent spec is going to be focused on kubernetes, and there is going to be a strong kubernetes community focusing and giving priority to the kubernetes use cases.

E

Right, I guess before we dive too deep into first implementation, looks like michelle was asking a chat about if we have any like specific, like high level goals for this media. In terms of like what we're trying to accomplish with this discussion, I think.

C

I think, ultimately, as an end goal, for this should be a a broad agreement on whether we we believe that smi is the right forum to take this this further forward. I would be I mean I I'd, be surprised that we can kind of find a solution um in this meeting. But I think the thing that smi does bring to the table is that you have a group of individuals to represent the major players in the service mesh space who are already collaborating together and.

A

So I can only speak for for myself and for for us, you know not for for the whole group, obviously, but um what I would like to see out of this either we get it done today or there is a follow-up meeting is, on the one hand uh answering the question: should we be doing that right? It could be that we say nope not going to do it and if, yes, then, the scope right. Is it indeed multiple quantities cluster? Is it cross compute?

A

So you know it could be a a monolith running on a vm uh wanting to communicate with uh or discovery or whatever, uh with with some containerized microphone service, with some lander function or whatever right um so do we want, should we be doing it and if, yes, what is the scope? Is it purely quantities clusters? Then there is my understanding, quite some overlap with what's what the cap is is referencing. As far as I understand the cap, I'm not saying that I'm an expert there.

A

I didn't play player out with it that much uh it's very early days, um but that's that would be my expectation.

A

Should we go around and see what others think uh because, like at least like cersei said something, um but I don't know michelle blake, are there other expectations in terms of what should that meeting yield in idle world.

B

From my perspective, I think what you and um nick laid out uh in terms of goals makes a lot of sense to me um if there is some opportunity and if we feel like this is the right time, I'd really love to hear different experiences.

B

Sneha and deleon from our team have been working on a multi-cluster solution for osm and I'm sure there are others who have either at least done a poc or have implemented some multi-cluster solution for their own implementation and it'd be really great if we could align on okay. What are the problems that?

B

What are the common things that we have to kind of like uh figure out, but that may actually be even deeper than what we want to what I've heard we want to do today, and so I don't want to get too in the weeds if, if the conversation lends itself to that, then that's great. But if not it's okay, okay,.

A

Cool blake: do you want to share something.

F

Yeah, I think um you know nick's commenting here in the chat, and I think his comments are online with my views is, I think, from what we're seeing is that service mesh is more than just kubernetes.

F

A lot of you know, organizations that I speak to are using service mesh today. Sometimes it's things like you know, console across multiple kubernetes clusters and in different parts of the business they might be using other service, fetch solutions, and what they're commonly looking for across these business units or even sometimes geographies, is a way to connect those services together to make those services accessible discoverable, and then you know, provide secure connectivity across these trust boundaries. If you will so I from my perspective, this is definitely much larger than just multiple kubernetes clusters and services.

F

You need to talk to each other, it's more about interoperability between either isolated islands of the same mesh or the same mesh product or between service mesh solutions.

A

Mike you, you looked like you, you also wanted to see something. It's like. Oh, when what is it do you do? You would.

E

uh Yeah, I guess mostly just thought in terms of like how this relates to like multi-cluster. I feel like there's like two distinct cases worth considering like one is geo redundancy between clusters, having like two separate clusters, deployment like limited blast, radius, limited uh failure, capacity for services that are like, logically, the same identity uh and then- and I believe that is closer to like what the multi-cluster uh kate's pep is focused on uh and then like separate from that.

E

There is like federation between independent clusters that may have services with the same name that are like logically, set, like distinct, like managed by different teams. Different parts of an organization, uh different organizations.

G

Okay, okay agreed yeah. I I don't see anything.

E

I guess just like also like looking historically of like, uh like hamlet, was clearly like an early attempt at something like this. Like um was there something missing? Was there something like misaligned with uh how that ended up going in practice like what can we learn from that and apply towards like what we're trying to solve this time?.

A

Thank you, then. Let me let me try it with a straw man in the straw person, whatever um makes more sense uh proposal in the sense that so far at least the people who spoke up so far, I haven't heard anyone objecting saying like. Oh that's, that's an awful idea. We should not be doing that right, it doesn't make sense or whatever. So let me propose- um and that's mainly for scribing, because I, oh sorry, dylan or italian.

H

After you finish, no, please please go ahead. Please go ahead! Oh gosh, you are on to something incredible um okay, so I I actually my gosh, I'm so sorry that I'm interrupting. I wanted to hear what you were going to say um so one thing that, as a practitioner coming from trying to develop open service mesh- and this is in our github repo- I've been thinking about multi-cluster and I focused on one particular scenario, and I really appreciate you that you want to split up the various kind of topics.

H

I think that all of them are important. We could probably work on them kind of in parallel, for instance, federation and bringing in various different payloads. Yes, I want to bring in a vm. At the same time, one particular scenario that I'm focusing on and I struggle because smi doesn't doesn't have that yet is I want to have two clusters and essentially use them as um just increase the capacity of my existing cluster right and so have one service across two clusters.

H

Two pods on two different clusters: same service and smi- doesn't have that, and so in my mind, I'm thinking I can work probably on smi to make smi that in parallel I can also start thinking about. How do I bring in a vm and that's kind of a similar, but but a different problem right and both of them can probably that they're two different forks um not really orthogonal to each other, but it could be worked in parallel, and so I'm really focused on that uh two clusters same service on both of them.

C

I think that's something that folks folks would want to do, and I see the problem is twofold. I think one is that we have to come up with a way of supporting multi-cluster with it within smi configuration. So in the same way as you have the concept of name space, you have the concept.

A

Of the cluster, I don't know, let's, let's not get into into the solution space right now. I.

C

B

A

Take a step first step for now just hearing. Is there any objection to yes, we should be doing it, and- and if that is not the case, then we can say all right. This is our position. We want to do it. Then it's a matter of how we copied what do we focus on whatever, but let's that's before we get into you know. What exactly should we be doing? Should we you know using this versus that? Is there anyone else on the call that I may have overlooked or overheard or whatever?

A

Who has an opinion, and might you know have you know posing saying like? No? This is not a good idea, not a good. You know, use of our time or whatever and speak up now or forever be silenced or whatever the official words are.

B

Just because sneha has been working on this, I just want to ask say how do you have anything to add here? Oh no, nothing at the moment. Okay, thanks cool.

A

Then I would put forward the the straw straw person proposal saying um the uh at least the people who are here. I I think it might not be everyone, so we can go back to the entire uh smi group and saying like we say we recommend that we indeed want to do that and should be doing that um and- and we can now move forward to the to the scoping part. But I I I don't see the screen I have the screen share on.

A

So if whoever scribes that or volunteer describe wants to put that down and then we can essentially resolve that one and say yes, we um we have one concrete outcome to this meeting. We support that. We actually want to to take on that challenge in whatever form or shape.

A

Okay, so is that, uh are there any objections to this proposal to this um proposed resolution of of the question? Should we be doing that in whatever form going once going twice? Okay, then we take that as yes, we want to do that. Then the question is scoping.

A

What what exactly are we looking at our um what nick called heterogeneous workloads there? um What I usually call this as cross compute um like where do we want to draw the line? Do people have any uh preferences? Any uh customer based data points that we should be focusing on one or the other. Is that something that we can actually meaningfully discuss in 10 minutes or do we need a follow-up like what? What are? How can we approach this copy? Any ideas.

C

If I have workload in an application, I needed to be able to communicate with my other my other workload. Now, if you look at the non-service mesh context of that, I might have a react.

B

C

Running in a kubernetes cluster, it might have a banking gateway which is running in an ibm, fax or something like that sitting in some data center somewhere right, I will have a bunch of micro services or a bunch of monoliths running in my ipn.

C

They all connect together and I connect them together. With my you know, standard sort of networking protocols now, when you put the service mesh, is a layer on top of that.

C

You you're, obviously in some ways disconnecting those applications, because you you're running this higher level higher level network. On top of your your base network, which gives you the reliability and security, so I still need to facilitate that same communication. My my ibm z needs to be able to communicate to my my vm and my cluster needs to be able to communicate to the vvm and the ibm.

C

All of the workflows that can be can be part of the service. Mesh needs to be adopted as part of specification and while stephmai is obviously present, but kubernetes centric. We have to consider workflows outside of kubernetes because they need to be named in order to support it. Right.

A

So what I hear from from you- and I literally mean here because you're having a really bad connection today- is you're in favor of supporting heterogeneous workloads, cross-compute environments, that that's what I I.

C

I would more say around the other way that I wouldn't support anything.

A

Important heterogeneous, so I I think I wouldn't agree with that. That's you would not support anything. That is not. Can you can you pure irish people, you know, can if the scope.

C

Of this specification was purely kubernetes kubernetes. I wouldn't support that specification because I don't believe it's.

A

Far enough, thank you better any other opinions, ideally not using double negation.

A

Any please opinions or or preferences like in support or opposing what nick just said.

A

I take silence in general as agreement. Unless you you have.

D

A strong opinion that one thing maybe one thing I want to highlight right. I support that statement from from nick.

D

um So one thing to consider, if we were going into that direction is um which are the problems we want to solve right. If we, if we support this connectivity, connectivity is only the basics that we need this discovery and connectivity are the two things that the minimum viable product, I would say, um but then there's more right so, depending on how do we understand these concepts of uh connectivity and security and the service mess, and so on?

D

um There are more or less that we may want to do right so think about.

D

If I connect a workload and if I discover and connect workloads between kubernetes and non-kubernetes environments, let's say cross runtime a are we also thinking in the in addition to discovery and connectivity? Are we also thinking in the you know? Monitoring is instrumenting these workloads in some way, because in the end, when we look into the service mesh, what we have now our workloads are instrumented right. So we have a sidecar instrument in them when we are looking outside of the service mesh. In some cases, these workloads are instrumented right.

D

If we go to kuma, for example, they are instrumenting the workloads, but if we go to other service meshes, they might not be instrumenting them right and they are considered, like external workloads, pretty much like if we are doing aggress filtering right. So what we are putting on the top is really if we are doing only discovery and uh and a routing. What we are doing really is like a a directory service right. So this is also something we have to take into consideration. That is what extent are with.

A

I agree in terms of scoping that I I would expect, as you know, as a user. If I look at that that it clearly tells me uh this is in scope, this is out of scope right. It says you know, as as we have now, and I didn't hear any objections. uh It is not completely specific. It is across different compute. It is across different uh historical workloads. um I don't have a strong opinion right away.

A

What should be and should not be in scope beyond you know, should, for example, should we explicitly strongly standardize on on anything observability related or not right? um I think what is important that they're very explicit about it. We say clearly, you know um we do or do not take um security related things into into consideration right. We you know. Yes, it is in scope to be, you know able to identify a workload or whatever it is out of scope to do. I don't know some some cert management or rotation or whatever right. We.

B

Need to be very.

A

Very explicit about that absolutely no doubt, but I think it's still a little bit too early and then I always have the feeling, especially people who already have done work in that area that want to jump very, very quickly to the solution space, and I I'm an engineer myself.

A

I I want to do that as well, but I want to always make sure that we actually work backwards from what what people out there need and- and you know, if you have been working on hamlet for example- then obviously you're representing your stakeholder you're, representing already uh more or less indirectly what people, what customers, what users want? No doubt about that right, don't get me wrong.

A

All I'm saying is: let's not directly jump to you know a discussion where you know: should we be using spire or should that be you know we need something from scratch, but spiffy compliant or whatever right. Let's not get there. Let's first define what is the scope and- and you know we only have three minutes left, I'm aware of that.

A

But if we could at least um slice one bit off that and and and if there is no objections that we captured this um agreement- or this this- uh you know yeah in the group that we actually want to address heterogeneous workloads. I I would be very happy if we, if we were able to define that today or discuss that today and wrap that up and then use another meeting, either again dedicated or next time to to address the next scoping like what should be in scope. What should be out of scope?

A

That's possible.

H

Does it make sense to split them and have one group multi-cluster only work on point one and one group only work on point. Two are.

A

We solving we can, we can have multiple working groups, we can have any any setup. I I don't have any you know master plan there. I just wanna make sure that we actually moving forward that we're actually getting results, and for that we need some general agreement. If the majority of people here thinks that heterogeneous workloads is something we want and again I haven't heard anyone objecting to it. How we go about it, how we implement it. That's the.

B

A

Step right at least to me, but I I want to make sure that we use the time that we have to get an agreement on these basic things and again is there anyone on the call at least who has an argument against heterogeneous workload. So, like you know, we should be only focusing on when this works and.

A

E

I think it's important, but I think we just recognized that it's uh potentially expanding the scope of smi uh in like a non-trivial way.

A

It actually is absolutely yeah. No, no.

F

I mean that's yes, I think something else that you know I I was hearing that I just want to call out is whether it's uh you know single run time or multiple run times. I think it's also important to separate. Are these environments under um common administration of a single entity, or are these separate administrations, two different entities that are trying to connect services.

A

Yes, very well, absolutely absolutely yeah. um Can I come back to mike's um comment or it I don't know. Is it an objection per se like it's.

E

Not it's not an objection, because I think that it's important I just. I just think that it's worth recognizing that it is like a substantial increase in scope.

A

Absolutely I mean that's, that's why I'm so careful about it like. I think everyone in the call is aware of that by implication this this dramatically not changes but enhances and enlarges the scope. Absolutely that's, that's goes without saying at least to me um cool. Then I I would again put that forward to like um the group present today uh understands that or or supports the heterogeneous workloads and what I would say the best way to wrap that up for today is we have at least two concrete outcomes.

A

Yes, we want it and yes, we see a heterogeneous, and I would nevertheless essentially go back to the full group next week and present that saying, like you know, are there any objections? If that's not the case, then we can move forward and then talk a little bit more um about what is in scope, what is not in scope and how we organize our work. Should that, be you know different working groups or whatever? However, we want, and we need leads right. Many tech leads.

A

We need a number of organizational things, but for now it's still, I think, a little bit in the scoping and getting everyone on the same page in terms of support for that activity.

A

Okay, thank you so much everyone for this wonderful discussion and your input. What.

H

Is the cadence of this group should we uh plan next meeting sooner than later, sooner.

A

We have usually every two weeks, but we could and that's something I'm looking towards uh michelle- can.

H

We speed it up by.

A

Extension that we, yes, if we could by you know, get cncf that we essentially use every other week as a dedicated uh multi cluster multi, whatever working group session that would be awesome right, then we would have the like the cadence every other week. It would be dedicated to that and then people who actually want to work on that show up and then every other week it would be general smi for whatever we are usually discussing.

A

So um I guess that's if I may ask uh michelle for that, if that's something we or whoever bridget or whoever has a liaison, we can have this this time like we did today. Exceptionally, if we can kind of like regularly get that.

H

Michelle says I'll be supportive, I'm not familiar with how to schedule it in chat.

A

We can we can do that offline with maybe bridgette, maybe like whoever we need to subscribe or ask, or back or whatever,.

H

A

H

Energy, I would love to continue this high cadence and just solve it. It would.

A

H

Would be definitely positive.

A

All right, thank you, so much sorry for going slightly over the time. uh Thank you so much and definitely see you next week. Thank you so much.

D

Thank you. Everybody bye now, bye.