Red Hat OpenShift Ask an OpenShift Admin | Red Hat Livestreaming, 16 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Ask an OpenShift Admin (Ep 61) | Service Mesh

Description

Do you need better insight into how your application services are communicating with each other? Do you wish you had the ability to fully implement blue/green deployment scenarios with little administrative overhead?

Red Hat Service Mesh gives OpenShift Administrators insights to their clusters with built-in observability and traceability features. They can control traffic distribution to their applications and operate in a true blue/green deployment scenario. Red Hat Service Mesh provides all of these capabilities without the need to change the application code!

Try Red Hat OpenShift: https://red.ht/3uVxkya

Follow us:
Andrew Sullivan https://twitter.com/practicalandrew
Jonathan Rickard https://twitter.com/jrocktx1
OpenShift https://twitter.com/openshift

Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1

About Ask an OpenShift Admin:
Do you have questions? We want to answer them! Every Wednesday at 11am ET, hosts Andrew Sullivan and Jonathan Rickard sit down to answer your questions about Red Hat OpenShift.

About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
OpenShift on redhat.com https://red.ht/3rYz5ZS
OpenShift on GitHub https://github.com/openshift/

#RedHat #OpenShift #Kubernetes #ContainerPlatform

A

Let's get into the big topic of open source, something that we actually.

B

A

What is that process that a developer or, let's say.

B

As the kubernetes ecosystem really boom.

C

Hello and welcome to this week's ask an openshift admin office hours live stream as always a mouthful, and I am andrew sullivan, uh the co-host of the stream and, as always, joined by johnny johnny happy wednesday, happy wednesday, my friend. How are you uh you know still vertical, so I can't complain too much it's a it's another great red hat day and that uh that always makes a difference.

A

That's right, how's, the weather out there, like the weather here in san antonio, is it's like it's a little chilly right now, but it should be like 82 today, nice and sunny.

C

uh It's it's gray, it's it's that time of year, okay, yeah! So it last week it was so funny because it was like tuesday through friday was just all gray all the time and for me, like I, I'm one of those people who I wake up best like with the blinds open right and just let the light do its thing and I wake up, and I feel you know I don't feel grug or anything like that.

C

So all week last week I was struggling to get up at my normal time, which is usually like you know, 7 7 15 in the morning and then saturday morning it's bright and sunny out and of course you know it's like so immediately. First thing in the morning awake and then sunday, of course, we had the time change so yeah, it's it's been fun.

A

Ruined everything.

C

Yeah, so glad glad that you're having good weather- though oh yeah, so hello khalid, thank you for joining us again nice to see you uh this week and hello to everyone else in our audience. So we are excited to be here. I'm happy to welcome one of my peers in the technical marketing team and that is ortwin schneider. So today's topic is the red hat open shift service mesh.

C

This is something that we've had on our calendar for a long time, and ortwin happens to be one of the top subject matter: experts inside of red hat so very happy to have you join us orwin.

C

Sorry, I just realized that I had to.

A

Thank you for having me here.

C

So yeah it's! um This is one I'm looking forward to because, uh if I'm being honest I really don't know much about service mesh like I can, I can tell you kind of what the purpose is and kind of the components, but that's about it. So this will be an interesting one.

B

Yeah I I I mean I have to um honestly admit that um I'm I'm I'm not sure if I'm right here, so this is ask an openshift admin. So, to be honest, I'm more a developer. So at least my background is more development, so I thought I could ask you some silly questions about service mesh, at least at the infra level. No.

C

I'm just kidding so um I'll learn together. What's the worst that happens.

A

C

To be amazing,.

B

I I hope for uh interesting. uh You know discussions and uh I mean I think service mesh is for both right. So this is, for there are aspects for developers. There are a lot of platform aspects and, but just to mention I'm also not that deep in the infrasight, so I'm more from the developer perspective. So um so I'm and I'm really um interested in in the audience today. So what? uh What? What is the experience really like?

B

um How are they using and how is the separation of you know um how they use the service mesh like what the ops people are doing? What deaf people are doing? Where's the hand over things like this, because there's a lot of discussion, confusion everywhere everywhere around it right so um yeah.

C

Yeah and it's it's interesting that you bring that up um so I'll use that as a segue into our top of mind topics and I'm going to surprise both johnny and stephanie behind the scenes by adding one at the very last second um actually johnny, already kind of knows about this one. uh So let me share my screen here.

C

I want to share this guy, and the first thing that I'm going to bring up here is actually a blog post that johnny- and I we discussed inviting the author here christina on to the ask an openshift admin, and I think this is a really interesting topic and very much in line with what artwen just brought up right, which is you know, hey we're not creating deploying managing.

C

You know we're not doing this job as an open, open shift administrator for ourselves, we're doing it for the applications we're doing it for the development teams, and I thought this blog post is really interesting, because it very much takes the same approach that we try to hear, which is hey, reach out and talk to those folks find out what they find out.

C

What they're doing so that you know you can work together so that you can figure out the best solutions for all the things that are going on, so I would definitely encourage you to uh check out the post read through it again. We will reach out we'll see if we can get uh get them to join and you know we can have a conversation about it and all of that, let me let me post the link here. um Yes, I want to watch now twitch I want to. I want to watch myself.

C

That's not strange at all.

A

Yeah she did a really good job of breaking it down, right and and really like, simplifying, not really a complex process, but just like complex conversations with customers. You know- and I think she did an awesome job on that.

C

Yeah and it's something you know, even I sometimes forget you know who who the customer is when you're, an administrator which is those app teams, those developer teams, and you know, last week we were talking about bgp right and you know: hey go talk to your network, admins go, you know, buy them, coffee, go bring them donuts or bagels, or something and make friends the same thing with storage teams, and you know so on and so forth.

C

um You know if you're, if you're, not the virtualization admin, the same thing with the virtualization team you know on and on and on um so yeah it's important to remember that and to of course, uh build bridges so to speak.

A

Yeah for sure, for sure it's it's all about the so what to everybody right like it, because everybody matters at this point.

C

Yep, exactly um okay, so after my little surprise there, uh let's talk about a couple of other things. So first uh we were a little bit mum about it because um we kind of had to be but openshift 4.10 is ga. It is fully released it. Actually.

C

I think the bits hit the mirror, like maybe 20, minutes after we went off stream last week, so they um we we knew it was in the process, but it also that process takes something like 12 hours, so we didn't know when it would actually go out- and I didn't want to you know I didn't I didn't- want to spoil it or otherwise cause frustration or anything.

C

If something happened at the last minute that that caused that to get delayed so surprise, openshift 4.10 is ga and if you would like to upgrade today, you can switch to the fast channel and you can do that. Openshift 4.9 to 4.10 upgrades are available. Remember fast channel is fully supported. So if you encounter any issues, you can pick up the phone and call us and we'll help, but stable will take a little bit of time.

C

So we we usually talk about this with every new release of openshift, where it takes somewhere between 45 and 60 days, for a new release to reach the stable upgrade channel, but remember that doesn't mean that new deployments with openshift 4.10 or upgrades in the fast channel they're both still fully supported generally available so on and so forth.

C

uh Our hope- none apart from being able to enforce security within the cluster, um enables tracing, helps focus on the right components: yep yeah, yeah, our hope, nine. I know this is a topic that you've been looking forward to, in particular for a long time. um So I I I I know you're excited to have ort, went on and be able to ask those questions and talk about it.

C

Yup switch back to stable 410. Yes, that is a uh that is a good option and a good reminder. um So, as our hope nine pointed out there in his last comment, uh so you can switch to the fast channel to do your 409 to 410, update and then switch back to 410 stable right and that's that's a fully supported process as well, and then you'll pick up.

C

Only the stable, you know releases for 4.10 after that, depending on how many, using already right now that is um or for it to become stable, so the process, the precise process that they use to decide when to go from fast to stable um or even candidate to stable, is unknown to me and every time I ask engineering they they kind of give me this weird look like. Why do you want to know that you don't need to know that just trust us when we do it?

C

So what I know is effectively. It is based on a number of things, um so one, of course, is how many how many times people have gone through the upgrade process right. So yes, some of it is based on simply. You know, people going through the update and all of that other stuff and seeing if there are any problems right, how many tickets were opened? How many bz's have been found, what are the severity of those bzs and so on and so forth?

C

And you know it isn't solely dependent on that, because, of course, in the background, the ci systems, the engineering folks are constantly doing upgrades as well like literally ci, is every moment of every day is burning through different deployments and upgrade scenarios, and all of that. So it's really a confidence thing that it is going to work with minimal issues, for the widest set of folks is when they make that decision.

C

uh Let's see what's next: oh, oh good, another cve! um So so last week we talked about a cve and now which one is escaping me, and I don't have that that uh note stock up. I did check it before. We started the stream today and I did not see any updates since last week, um but the there was a cve that was recently announced or released rather, and it is 20 22 25, 636, 25636 I'll go ahead and paste this link over into twitch.

C

So this one is a. um It seems to me to be a fairly severe one right. It is a 4.7 on the impact score here. um One thing to note here and johnny: please correct me if you have anything to add um so one as we see down here, rel eight is affected right, so remember: core os is at rel eight, so core os and openshift will also be affected with this.

C

um So please do keep an eye on the update channels, for whatever z stream um or the z streams, for whatever y release you happen to be using, uh but you'll notice that the main mitigation here is to turn off user name spaces, and there is a very handy note here that says: well, if you're using containers, you can't turn off user name spaces. Well, of course, openshift uses containers, so the mitigation here doesn't apply.

C

I don't have any further details or information on that at the moment. I'll continue to keep an eye on it. If you have any questions, feel free to reach out through the various you know usual ways. um You know twitter, uh reddit, um kubernetes slack, uh there's an openshift users channel and kubernetes slack, so you can always reach out and ask for clarification or ask for questions and, of course, email andrew.sullivan at redhead.com.

C

But that's that's all I know for now. Johnny do you have do you have anything.

A

No, that that covers it.

C

A

Okay, uh I'm sorry I was gonna say in the in the link or in the chat I put the uh the cbd for last week, the dirty pipe. There is a fix for raleigh, so it came out. It was released march uh march. 10Th. Sorry about that. Give me.

C

A catch, no, no, no worries. Thank you for posting that, because I did not see that um so usually what that means is.

C

Let me think from the last time this happened it it takes somewhere between one and four weeks for a rel patch to make it into core os to make it into openshift.

C

You know, depending on all of the things that are going on so on and so forth, so again keep an eye on these streams that are released, keeping on the release notes for each one of those to see which ones it is uh patching and affecting uh next up um a quick one, uh so sandbox containers, which you remember we talked about in episode, 50 with adele zuluk, uh so sandbox containers are now generally available uh yay.

C

So if you happen to be uh using or have a use case for sandbox containers, remember that is a fully isolated container right. It basically uses kvm rate virtualization to create a fully sandbox, fully isolated container instance, separate kernel and everything inside of there, so maybe important for some security. You know high security type scenarios, various other things where it is untrusted code that you're running inside of there um so yeah be sure to uh check that out.

C

If it's interesting to you and I've got a link to episode, 50 here I'll, just copy that in oops wrong window, so I'll post, the youtube link there for episode 50. If you want to go back and review sandbox containers, um let's see two two quick ones left: um johnny podman, four.

A

Yep so so podman four, we talked about it last week where podman4 was released and uh there's a bunch of support, but I was going back through the blog and I saw that podman 4 is not going to be released on fedora 35.. uh It introduces a breaking change on fedora and fedora has a long standing process of. If there's a breaking change, they won't allow it to be released.

A

um So if you're, looking, if you're, using podman, 30 or backup, if you're using fedora 35- and you want to upgrade to pod m4- you cannot, it won't be part of their. um They won't be available um and then there's another release today, 4.0.2 and that gives, if you're a mac, user and you're using podband. Then it allows for volume access so where you can now run like pod. Man run with dash volumes and you can mount your mac um volume into your container.

C

Very cool yeah I I have to admit that I I use podman, but I use it like in vms and stuff like that. um You know to to run things like um like a web server and stuff, like that. I I don't use it often on my laptop um and definitely not on my mac laptop.

A

Yeah, I I hardly ever use it on a mac. I mean I'll I'll. Do it just to kind of like tinker with it, but you know generally I'm in the same way as you I'll run it on my linux machine and go from there.

C

All right so last but not least, I'm going to switch the window that I'm sharing here over to my terminal.

C

And so this one came from somebody internally asked: you know: hey what are all of the openshift star namespaces. What does each one of those do and there is no documentation right or nothing that I'm aware of in the docs. That says you know hey, you know, openshift api dash server. Is this or hey open shift, dash storage? Is this and so on and so forth?

C

um So there is a command, and am I sharing this? Yes, I'm sharing this. um So if we share that terminal window there we go so there's a command that you can use in order to see basically all of those things. So if I do an oc get cluster operator oc get co.

C

I have this whole list of cluster operators running in my in my cluster, and you can see I'm running 4.10.3 here, which is the ga release and for each one of these I can basically identify which namespaces are assigned to it or used by it and and some other information just by doing a describe on the cluster operator. So if I do oc get I'll use that random we'll go with machine api and I want describe not get.

C

It helps if I tell it the resource type, all right so down here at the bottom. We have a related objects section, and then you see here, I've got like a namespace and machine sets roles, cluster roles, so this one only has one namespace and it happens to be openshift machine api.

C

So that's the first hint that you know if I'm looking at oc, get project and open shift right. So I've got this huge list of system level name spaces. So that's the first indication of you know: hey openshift machine api is owned by well the machine operator.

C

So what if I want to find out more information about that, so there's a command, oc, adm, release and info, and it gives me a whole bunch of information about the particular release that I'm using- and you can see in this big list here here- is all of my cluster operators right all the images that are associated with it. So that alone is somewhat useful. But what's really useful is if we use the dash dash, commit dash urls option.

C

Helps, if I spell it correctly,.

C

And here we now get the github repo link for each one of these operators, so machine api operator, for example. We can see here I can find in github.com openshift machine api operator, and I can go there and I can now find out a whole bunch of information about that operator and what it manages- and you know usually the devs are really good about, including things like how to troubleshoot or how to get more information.

C

If you feel like reading go code, you know you can certainly dig in and see what's going on inside of there. So I thought that was an interesting one. I think we talked about this like way back in the early days of the stream, I want to say like somewhere in before episode 10., so it's been a while, since I looked at this command um the last time I did it, there was maybe 30 of these and now there's well a lot yeah. So um so yeah.

C

It interesting bit of uh information interesting way to kind of find out how to really dig deep into particular operators or particular functionality.

A

Yeah, I didn't even know about that that that's an awesome command.

C

So yeah, I don't. I don't remember how I found that out. It was either from engineering or for support. It might have been somebody like eric rich on the support side, who uh who told me that one yeah that's.

A

Pretty awesome this.

B

Is really cool, really cool and again uh learn something I I think I should um see this show more often.

C

We we always welcome new new audience, always all right, I'll I'll stop sharing. Now. That's that's all the top of mind topics we had for today. So uh so yeah. Let's talk about service mesh and I don't want to steal your thunder or anything like that, and I think you had some slides prepared, art one and I have to say I love your title slide um and and the the the prettiness of it. If you will um so I I won't spoil anything by asking you any pre questions I'll.

C

Let you um you know tell us about service mesh.

B

Yeah thanks andrews, so let me just share my screen. I think I have way too much slides. So this is just kind of things we could talk about and discuss, but um let's see how far we get and also really if there are questions out there or things to to discuss um yeah feel free to ask. So let me share my screen and yeah. Give me a ping something.

A

B

A

C

B

As mentioned, um I mean openshift, service, mesh and and service meshes in general. They are quite I mean this is a very how to say extensive topic right, so some people say service meshes are as complex as kubernetes itself. So um so that's why um also? There is some, I would say some restraint out there in the in the community and the adoption of service meshes really isn't that high um compared to other, let's say, technologies and um yeah.

B

This is for a reason, and um today what I would like to do is to kind of um talk about service measures more on the introductory level to to give especially um administrators kind of the awareness what it is and and why in the world would I need it at all and uh do we have some specific or is there a specific kind of you know, workload characteristic where it makes sense over it where it is appropriate when not um who is using service meshes at all? If I, if I yeah.

C

Decide to introduce.

B

A service mesh so who are the personas using it? I have developers, I have different types of platform, let's say responsibilities, and so on so and then, of course, we all kind of know that it is kind of on a platform service. So there is an additional service on on top of the actual platform, so there is kind of overhead. So what is the? What is the overhead right- and um this is also concerned for for many customers, so to say um so.

B

Basically, what I wanted to to talk today is kind of yeah, like a 360 degree, brief overview on a service mesh so basically covering what is it in general? What is a service mesh? Why do I need it? What are key features and capabilities and very typical usage scenarios of service mesh, then have a look at the specific, the openshift service, mesh and um yeah. How can you get it? Do you need to buy it and how to install and things like this um considering then a little bit the the different types of applications?

B

Where is it appropriate or not? Probably um what is considered there, um as mentioned the the personas and users overhead, a little bit um yeah I've prepared a demo for mesh federation. This is a new feature in our um recent um or the latest release of service mesh 2.1. So there we introduced the mesh federation.

C

B

There's a demo out there, so we can have a look and just I I haven't installed it. My plan would be to deploy together with you and see if my um scripts and everything works out so uh and then also like faq and roadmap items. I think there's way too much stuff, but this is general at least my preparation and plan for today. So, okay.

C

Yeah this this is perfect because I can spell service mesh and I know that there's istio involved in there somewhere and I think jager and that's that we've now reached the extent of my knowledge so I'll uh I'll. Let you move on ahead and for our audience for anybody who's watching us. Please. uh Please help us prioritize.

C

If there's things that are interesting to you, that you would like to see or like to know, uh please feel free to ask us in chat so whatever platform you're on, so it doesn't matter if it's youtube or twitch or anything like that, all the chat gets accumulated and re-broadcast all of them. So don't don't hesitate to post those questions.

A

Yep and ort, when I'm sure you're going to get to it, but um khalid did have a question like when he should or shouldn't use the service mesh so kind of. Keep that in mind as you're talking through some of these things, like. Maybe you can.

B

A

Going through your list right kind of like associate that.

B

Yeah we can, we can definitely address it in certain aspects.

A

B

And yeah, you know, as mentioned, the the the whole topic is very, let's say, complex extensive. So if there is a kind of you know in the in the audience, there are specific interests in in certain topics like whatever you know, distributed tracing and so on. So that could be something where we could create kind of a follow-up also in a session, because there is a lot in every aspect.

B

We could really go deep dive into some things, and this is really a generic overview to really get the awareness and context and and just the understanding of what it is in general. But there is much much more than what I covered today right so um yeah just to let you know so, then let us begin with um the very basic question. So if you really don't know what.

C

B

Is the question: what in the world is a service mesh and if I would need to answer it in in kind of one sentence? I would say this is a programmable network, so it's kind of an overlay on top of. What's uh what's in openshift the sdn and basically you can reduce it to a service mesh is, I mean, are different, implementations out there in the market. You know. So there is istio, there is linker d and so on, um but basically they all work the same way.

B

So we have a bunch of user space proxies sitting most of time as a side car container next to your actual services. So this is kind of um you have a bunch of proxies and of course, additional. You have a control plane. So you have some management processes and components with which you actually manage your proxies and they provide a certain apis for the proxy.

B

So normally the proxies will kind of access the management components to get some informations or to send some metrics to to the control plane, but also you have several apis to be able to kind of configure the proxies out there. So if you reduce it to this, this is what a service mesh is.

B

So it is user proxies and it is a control plane and what the proxies do is um they intercept the the calls so every traffic going to a certain service they intercept and they do something with it right and um normally um so the the feature set depends on really the the proxy you use so, depending on on the service mesh implementation, you could use different type of proxies.

B

Normally you have or we're talking about tcp layer, seven aware proxies and for inbound and outbound messaging, so they act as proxies and reverse proxies, and um so the focus is really on on the inter-service communication, and this is kind of also or I would say, that different shades from api management or api gateway solutions. You know so they're more focusing on ingress traffic to apis where service mesh is more the focus on inter-service communication in a let's say, trusted: environment yeah. So basically, this is what it is.

B

So the control plane has certain capabilities like uh different types of service discovery, um tls certificate, issuing um and and a lot more like metrics, aggregation and so on. um But this is basically what it is. So um this is just from from the issue page here, the the the architecture.

B

So you see there's the data plane, so um all the proxies we have in our environment, they kind of form the data plane, and this is where the actual traffic goes through and where we apply our configuration, some some routing stuff load, balancing whatever the proxy is capable of doing, and uh so the communication is um kind of from from proxy to service and from proxy to proxy and so on, and we can do a lot of nice fancy stuff with it.

B

But um if you, if you think about it, um okay, we have now um like 1000 services in our environment and, if we add like a sidecar for every service, this is it sounds like a lot of you know overhead, and um so, when you think about proxy requirements, of course, they should be very fast. The proxies because you're also adding latency. Of course. So you, you add additional two hops for two to every call right so on the client and service side.

B

So um you add latency, um the proxies definitely consume them, cpu and memory, and also you know um you need to to maintain and configure all this proxies out there. So these are the things to to consider- and this is.

C

B

uh Or I would say some some, especially if you consider to use a service mesh, a lot of customers are afraid of doing it because of these reasons, so um yeah.

C

And it's important to think about right because it it can't get that information. You know magically it's. You know we're not doing like a a like a a ip capture right, a network capture. You know for every one of these things that's going across; rather they get proxied and the proxy does the analysis and reports back that information to the control plane and that's how we get visibility into what's going on with the application and the things that it's doing so? Yes, there is overhead and it comes down to you know, balancing that.

C

You know value versus cost.

B

Exactly exactly so, the the question is now: if you decide okay, I'm installing a service mesh, let's go for it. So all of a sudden, you have to kind of manage, like hundreds, thousands of proxies, and and uh is it worth doing it right. So this is the question and I would say there are different aspects to the answer. It's worth doing it.

B

So the first thing I would say is um you it is, or one thing to consider is really the operational cost of deploying- and this is really reduced to, um for example, by using kubernetes by using openshift service mesh. The way you manage the proxies you deploy and and bring them, let's say uh into life right.

B

So this is uh one thing to consider, but the the um actually more important thing is that you could really add additional logic to your existing services, to your existing ecosystem and really um capabilities which are vital, especially for let's say, a more a bigger micro service architecture, and you can do that without changing the ecosystem in any way right so- and this is especially, this is very important that you can add all of the capabilities without changing the service itself.

B

So um this is what what makes it worth the most of the time, at least so. You have to consider a lot.

C

B

Things but basically I would say these are the benefits of a service mesh.

C

A quick question um from walid: can we use service mesh for cluster level ingress, or is it only for pod to pod communications.

B

C

You you have in general, you.

B

Like you see here, you have um envoy proxy, so um our openshift service mesh is based on istio.

C

B

Your user's envoy proxies um at this layer and they are used as side sidecars for uh the interior um or the internal mesh communication and for um external communication. We have also um kind of um envoy proxies standalone kind of at the edge for ingress and egress, and there is also an integration with openshift. So, for example, if you configure an ingress gateway, you would um or um um openshift service mesh would configure an openshift route for you.

B

So there is ingress and egress gateways as to to let traffic into the service mesh and also to go out of the service mesh.

C

To be clear and a clarifying question from khalid so effectively, you can either continue to use the traditional. You know open shift, ingress controller based on h, a proxy or you can use the envoy based ingress pro proxy, for you.

B

C

B

You would use the for cluster ingress. You would use the combination of ocp routes with the envoy istio ingress.

C

Okay, so it does replace h.a proxy.

B

Yeah, it is a combination, so aj proxy is for the ocp routes, the implementation right, okay and also then, the the route will uh forward traffic to the envoy proxy to the issue. Ingress um invoice proxy got.

C

It, okay, okay, so it's it does use both. It's just a client from outside the cluster. Coming in we'll hit h a proxy first and h, a proxy will send it to envoy and from.

A

There, yes now now is that for all services, or is that just for those services that are within that within the mesh.

B

No, this is only for the services you want to expose, or they need to be um kind of accessible from outside the mesh right.

A

Okay, so so, if I have an application, just call it app a that's just a standard openshift app. It's an oc new app that I just stood up outside of the service mesh that would still use h.a proxy ingress coming in and the normal oc routes and stuff like that, without using the surface mesh at all. But if I had app b that was in the surface mesh, it would go through h8, proxy and then route down to the envoy proxy into the mesh.

B

Yeah you would, you would have like an uh let's say: normally, you would have like an ui service kind of thing right for your application and this one is exposed and accessible. So you would configure kind of a gateway component in istio, and this would kind of translate into an ingress gateway configuration for the envoy and also it would create an ocp route to access this ui service from outside the mesh. So from a customer or client perspective, you would then hit this um kind of url.

B

You would go through the ingress gateway and also then be routed into the mesh to the different services. So the only thing exposed would be this ui service and the necessary um paths. You need from the client side right. Every traffic would then stay inside the mesh.

C

Okay, gotcha yep, that makes sense and audience please. Please uh continue to ask questions if, if there's any confusion,.

B

C

Can see that also later.

B

If we come to the demo part right, so we can see that there is an access.

C

B

Outside and what you see, and the communication inside and things like that yeah, so um that's basically the thing. So it's um it's worth doing it. If you have like um um kind of the the right type of applications, the the right requirements, it depends on what you want to do so. This is why we should look at what are the key capabilities of the service mesh right. So what what does a service mesh typically offer? So more or less everything which is out there in the market?

B

They have some key capabilities which are around traffic management. This is the way on how you want to route your traffic from outside the mesh to the different services and as well as inside the mesh so and uh what it also includes things like um implementing, uh resiliency and reliability like, um for example, configuring, retries um configuring things like a circuit breaker to to prevent some cascading failures. Things like this and also then load balancing to the target services. So with different strategies, um you can have different, um also release deployment strategy, for example.

B

If you want to do a b testing canary deployments things like this, so there is a way to really granular define all this traffic flow inside a mesh, that's um pretty nice and cool. The other thing is observability.

C

B

Also, for I would say for for application developers very interesting because if you have um really an application which consists of multiple services- and you know like this service- a called bcd and so on, so you have a lot of service calls and your request paths is quite long through the service mesh. So you need to understand kind of where that what are the paths, um your requests go? um What services are are um getting access and also to um if there are any issues, if there are latencies, you need to identify these issues and.

C

We all know microservices.

B

Are are distributed, it's a distributed architecture and to to troubleshoot it and um yeah. Help in such situations is quite hard right, so um observability metrics um tracing is very, very important, also to understand what is going on there. So, even if you don't need any other features like you don't want to route anything, you want to um kind of apply any security stuff, just the purpose of observability and also, for example, with kiali, which is our visualization dashboard. It's worth to have it to to really see what's happening in your application right.

B

So this is one aspect, the other thing, policy enforcement, so they're different type of types of policies. So we have authentication authorization.

B

So there is a custom resource called um authorization policy, for example, and there you can specify, for example, the the who is allowed to access the service from this specific ip from this service identity and so on. So you can really granular define um all the the authorization policies you need for all the services inside the mesh and the mesh will um enforce these policies and um will distribute it among the consumers and so on.

B

So and the nice thing is, as mentioned, all the things you can do here, so all the features I'm also applying security, which is nice, I mean there is an integrated certificate, author authority, coming with istio so and by default, the traffic inside the mesh is always using mtls when it's possible.

B

um So um this is also one way to to, or you could use a service mesh to kind of facilitate, facilitate things like zero trust, networking with authorization policies with kubernetes network policies and also with the identity and security features that the service mesh offers. So this is a combination of all the three things and with these um combination, you could really do things like zero trust, so yeah.

C

And- and I want to point out that there is some overlap with some other uh other openshift features right, so things like network policies and um now it's escaping me. What's the thing johnny, where we can turn on um sdn encryption between nodes in the cluster uh yeah ipsec at with ovn right, so one I think that service mesh gives you a lot greater granularity and visibility into what's happening there. As our hope, nine just pointed out right, each one of the services has its own tls certificate right.

C

You can very granularly control those things, and I also I don't want to um understate how valuable the the metrics around the various services can be, um and I say that particularly if you know you're working with an application, you know decomposing or what is it? The strangler pattern right with uh a monolithic application.

C

You know it used to run on the server that had you know, 800 cores and 97 terabytes of ram and now we're you know splitting into containers and deploying this thing across kubernetes and it went from everything being local communication.

C

You know on a single host now it's distributed across, maybe dozens of hosts in particular as it scales, so sometimes application components suddenly have latency where there wasn't latency before, and they have to take that into account, and you know things like that. Observability can really make a difference for finding those uh those gremlins. If you will.

A

Yeah 100 agree, um and so or we have a couple questions coming in um so one of them is essentially can you have like multi-cluster applications, so an app a runs in cluster one and two uh does service mesh support, multiple clusters or an application running in multiple clusters, and then uh the other one is uh from pete does. um Does the service mesh support the openshift virtualization.

B

Yeah, so the the first question is around multi-cluster, so I have some slides. This is really later on. So the short answer is yes: we have kind of um two options. We support so upstream istio, for example, there's a bunch of let's say: multi-cluster deployment options and topologies you could use to install. um We have we have more this security first approach and currently we have kind of two things. We have service mesh federation as mentioned.

B

This is the new feature with the latest version, so you have um kind of distinct service meshes in one or multiple clusters, and then you can export and import services um from one cluster to another. So this is an explicit, explicit configuration you have to do um and the communication is really you don't need. The good thing is that the the control plane, so the sud control plane, doesn't need to access the other clusters. uh Kubernetes api servers.

B

So it's the whole communication and everything um is through ingress and egress gateways, additionals that you have on both clusters- and this is the the way you could use, for example, to, for example, um some failover scenarios for mirroring traffic uh in in a staging environment.

B

So, for example, you have a production cluster, now you're developing a new version of the service, and you want to test it with production data right, so you could, for example, federate the meshes and could um export the mesh from the new service from your stage environment and import into the production one, and then you could mirror the actual production data to this new service in the stage cluster and you can test with production data.

B

If your service performs the right way works the right way, and things like this, so federation is one thing and the other thing is. You can have also a multi-cluster insulation, but with one control plane in one cluster. What we don't have is a single um control plane outside for multiple clusters and multiple service meshes so to um yeah um address this thing. I mean it's on our agenda.

B

It's a thing for the second half of this year or beginning next year. There are some efforts going on in the context of acm, so advanced cluster management to have their kind of a central way to manage multiple service meshes in different clusters. So this.

A

Is a roadmap item.

B

And I think that was kind of the second question right.

C

Yeah well so I'll. I can touch on the second question in just a moment from uh peter, um so our hope nine touched on something here. That might be interesting in what, in the context of what you just said, which is you know, submariner, which is deployed and managed by acm. So you have, you know two or more clusters that are managed by acm and a cluster pool, and then you use submariner to create essentially a federation across those right with at the network level. So does service mesh and submariner work together is like.

C

Would you have you know, say: there's three clusters: would it be three distinct service meshes and the clusters are connected through submariner or would federation at the service mesh level be the better answer?

C

Hopefully that made sense.

C

um I'm gonna go with no, because you.

B

I mean um the the the the you know, the the actual um implementation with a submariner or something I'm not sure how it's how it's uh gonna be done right so currently, so this is really. um This is something ongoing right now there are plans to integrate that. I have no idea um what you know technology and what network level the integration will be uh with acm. So I can answer this question right. So right now,.

C

No no worries. I I jumped ahead on it.

B

Yeah, so currently it would be really the way to use federation. So, okay, you have a multi-cluster scenario. This is what I would kind of recommend right now.

C

Okay, so I I think you know and- and I see gorov asking- um I think it would be helpful if you have a demo- that we could take a look at and see in action kind of what the capabilities are and to jump back and answer uh peter's question peter lauterbach there. um So, yes, I believe, as of openshift virtualization 4.9, if not for sure 4.10 virtual machines can connect to the service mesh.

C

So if you have virtual machine based application, components that are talking to communicating with you know, container-based application components running in the openshift cluster with service mesh, it all works and it's all happy.

B

Right so um the demo thing the question for me would be: should I directly start with a demo or should we proceed? What is your opinion, especially the audience.

C

um So we've we've got uh 10 minutes or so until the top of the hour. So um I'll, let you be the judge. I think we definitely want to spend a few minutes. You know looking at the demo, you know kind of digging into it and all that, um while he'd saying you know to get to the demo, I think warov is thinking the same thing. So um maybe we can, um for a strange turn of phrase, kill birds with two birds with one stone, right um and kind of discuss, as we demo.

B

Okay, so I'm kind of afraid that you say we have 10 minutes.

C

No, no, I so we have more than 10 minutes. um I I just I I try to be cognizant of not going way far over um no.

B

Sure, but um you know um I have prepared like uh 90 90 slides and we are on slide seven, and that was not my plan. So this is what I wanted to say. Yeah.

A

B

Then uh let me let me do it this way, um the demo! I have to to see it in action. So let us try to get the federation thing. What we've just briefly discussed here right! Okay, um yes,.

C

And welcome to the live stream, where nothing ever goes, according to the plan that you had and time never is relative.

B

Yeah yeah, so you see a lot of other things. So why do I need a service mesh? A difference to upstream is your openshift service mesh. So I've prepared much more so, but um we should have like a three hour session for all that. So let us jump to the service mesh across clusters. I just show you uh in one or two minutes, um some slides um just explaining briefly the concept right, um how the federation things work.

B

um So, as mentioned with upstream issue, we have really multiple deployment options and so on for multi-network, single network multi-primary and so on, um but normally what you need to use, there's no really a multi-tenancy out of the box there at least I'm not sure with 113 of sq. I think there's still nothing out of the box, um but um you need to accident need to have access with with sdud to the other kubernetes services.

B

So our approaches, as mentioned, we have service mesh federation where you have like distinct service, meshes in one cluster or in different clusters, and you can enable sharing, load, sharing and um load balancing and for specific failover scenarios, for example, and then also a multi-cluster service mesh where you have one control plane. Currently, this is the way we have it right now and we have a multi-tenant approach by default in openshift. So you don't. You need a privilege, ledge or escalated privileges to kind of install a service mesh.

B

So you need a cluster admin to to install the operator stuff, and the operator needs the the privileges on behalf of the user to do um the stuff, but the user doesn't need any escalated privileges. This is great in terms of security, so um now come coming through the federation topic.

B

What we have is, if you want to federate um service meshes, you can do that with 2.1 plus right now and the way it works is um you configure distinct service meshes as mentioned in one or different clusters, and the communications then through the ingress and additional egress gateways, and then exposing services to the other cluster is so.

B

We have introduced additional custom resources for that, and you would specify an exported service set and also an imported service head, and then you can kind of um use the services from the other cluster, so these are kind of in terms of the federation. The additional things we've done. There is a service mesh peer configuration. There is an exported and imported server side. This is what federation is then made up so different ways to um use the stuff. Let us jump to the day more.

B

I have let me check here ah by the way. So if you want, if you have an openshift cluster, and if you want to try exactly this setup, you could go to. Let me see the repositories here is a github repository which is called mesh federation. So this mesh federation, um github repo, you could just clone this one and then you're landing here. This is what I have um here. We have kind of the setup. What we want to do is we deploy now two service meshes uh two different control planes.

B

uh Just briefly, let's have a look what's in there, um so we have a production service mesh and we have a stage service mesh and uh the first thing is: we have a control plane. So this is the the custom resource to deploy a tenant of a service mesh, and you specify specify, do you want to have kiali prometheus, what type of policy telemetry and so on. So this is a quite extensive custom resource. There are some complaints around it because this can be very complex. This is from an admin perspective.

B

The way you would kind of upgrade your service mesh. You would um add additional features things like this, so this is kind of the central piece of your your configuration and what you see is we have an additional egress and an additional ingress for the other federation service mesh. So there needs to be a discovery, port and so on. By the way, there's also an article I've written on this federation thing, um you could probably have this link as well, and you could just follow the description here and it should work.

B

This is basically what we what we do right now, so a control plane. The next thing we need is a member role, so this defines in this control plane namespace. What are the namespaces projects we want to include in our mesh? So we have one book info production namespace.

B

Then we have appearing configuration to these state to to the state mesh where we configure like the address in our, in this case it's in the same cluster, so I will deploy both meshes in the same cluster and all the workload components. So this is the configuration you need to configure the trust domain, and so on. So some of the steps here you need a root certificate of the other um service mesh to validate the certificates and then actually we deploy in the production mesh.

B

This book info, which is the standard, let's say demo for istio service mesh. We deployed a complete book info in this production mesh and then in the stage we do pretty much the same thing we deploy also control plane. We configure the peering configuration and the member role, and here we only deploy kind of the new version of one of these book info services. This is our new one, and this is what we want to mirror the traffic from production to to here right. So this is the setup.

B

Let's get started, so we just open in terminal.

C

Just for the record, all of this is fascinating to me, because there's a bunch of different ways, you can do this right. I I was the other day learning about dibysium and kafka and effectively using dibesium in order to selectively extract records from a database to replicate into kafka. To then, have you know the the non-production side of the application begin doing things. So it's fascinating to me to see all of the different ways that our app and development teams can accomplish this.

C

um I do want to jump back. I know we skipped over it. It was one of your topics that you wanted to cover and that was resources or resource requirements for service mesh. Do you have like a a 30? Second, you know deploying x, number of you know instances of the uh the proxies will consume. You know y amount of resources or anything like that.

B

Yeah, just a second, um what I'm doing um forget about this? One, don't have a look at this docker command, so my apartment is currently not running sorry, so yeah. The thing is with with a stream editor um cli, it's not working as the the way it it works with linux. You know so. This is why I run the openshift origin cli container and deploy from there, because I'm running in the mac and verb um yeah uh andrew. I just um just a second.

B

Let me just start the deploy process, and then we can just directly jump to the slides there. Okay, something.

C

And it's it's! Okay! If you, um if you, if you want to, um we can answer that question afterwards and include it in the blog post. um So I figured that might be the easiest way to answer um several of these. By linking into uh so we'll take the slides, we'll publish those to um uh speaker deck. I think it's speaker deck that we use now um and we'll we'll link that in the slides and we'll or in the blog post and we'll answer all the questions and stuff that folks um are.

B

Asking so um I have created a deployed script here, so all the components here should be deployed out of the box and um ah okay, I'm not locked in from here. uh Just a second.

C

And I'm not sure if you're intending to share the cli or the terminal that you're using or if you want to keep your browser up.

B

ah You don't see anything.

B

Oh jesus, okay. I am sorry.

C

I asked I asked because sometimes I'm sharing a browser while doing something on the sides.

B

Okay, just a second I'm sorry, I thought I've shared my complete screen, so I'm just okay, um just a second I'm um wow. This is not not believable entire screens. We.

A

B

Anything from my very cool custom resources so far right so.

B

So here we are right, so um this is what I've mentioned. So here is, for example, the service mesh control plane configuration. So this is the git report, if you, if you download it so we have the control plane configuration. We have the member role, we have the peering config for the other mesh. um We have the certificate part of it, and then this is the istio virtual service mirror configuration then to mirror the traffic to the stage environment. Here is the um imported server set.

B

So here we specify the services we want to import from the other mesh, and this is the other mesh which is the stage one which is very kind of the similar thing. But here we have kind of an exported service set uh custom resource custom resource where you say: okay, um we want to export this service that it's available in the production environment, and we only have this deployment here of of the detailed.

C

Service so basically.

B

This is what it is now um um just a second, I'm not sure what was the I'm in the container deploying the stuff. So uh let me just check the url of my my cluster here, okay, what is so slow um that should be this one.

B

B

So, as mentioned I've, I'm I'm in this.

B

um I mean this docker container and the cli have mounted this git repository as volume in there. So I'm deploying I'm just executing the deploy script from here now and you see okay, it's starting, so I'm creating the the namespaces the projects right here. um This is by the way, the um deploy script. So we basically create projects we create the we install the control planes. This takes some time until everything is up.

B

We create the workload um projects, um then also the peering and and memberall configuration we deploy the workload um uh yeah get the certificates and all that stuff and um at the end we should have everything up and running so two measures with a mirroring configuration and with federation uh configured in one cluster. So this is what we do. We wait a little bit and in the meantime let me go back to the slides. So um what is the overhead? What's the question, um so there are some there's some data out there.

B

You see it here, there's also the link to istio, where you can find this one. We also do some benchmarking, but you also find for the different versions of istio, which also applies to our openshift service mesh, because this is kind of the foundation we use istu and additional things for observability like gyali and jaeger and um prometheus graffana things like this, but you see that um it will add.

B

So this is the low test scenario, with a thousand servers and 2000 sidecars running, and so the the envoy proxy um consumes like a half virtual cpu and 50 megabyte of memory per thousand weakness per second going through the proxy sqd. The control plane uses one virtual cpu in this scenario and one and a half gigabyte of memory, and it adds uh 3 milliseconds to the 19th, percentile latency so and there's some additional stuff. So things to consider also for the control plane is really the rate of deployment changes.

B

The rate of config changes which have to be proc, propagated to all the proxies out there, the number of proxies, of course um out in the field. One very important thing in reality is always like um by default. You know all the if you, if you, for example, um create a sql configuration like virtual service destination, rule things like this, so this translates to an envoy proxy configuration and by default this will be available in all proxies out there. But the reality is your services.

B

They don't need to talk with every um potentially available service in the mesh right. If you have thousands of services, this will increase really the memory and everything. So one of the things always to consider is where to expose the configuration. Is it really necessary to have the the specific routing configuration on every proxy in your mesh on or where is it necessary? And you could limit things like this with a sidecar custom resource of issue, for example? So this is very important in in a production environment, for example, it's.

C

Like firewall rules, you don't want to have firewall rules that open everything to everyone. Rather, you want it to be selected and also to be clear that previous slide was referring to the istio control plane, not the open shift control plane exactly.

B

um Yes, things to consider for the data plane and then there is also some you know, considerations um regarding the the latency, depending on the amount of client connections and and the specific, let's say, telemetry um you want to access. So in general, you can say you, you add like three to seven milliseconds to to each request in terms of latency. So if you have really very very uh sensitive uh latency sensitive applications, um yeah.

C

B

To consider if service mesh is the right thing in this case, it's not always is because there is a kind of overhead for normal. Let's say: microservice applications it. It's.

C

Not that that much important.

B

In terms of latency, um the resource consumption is something you will have to fine-tune for your specific, um let's say setup and the requirements you you you have so normally um by the way, the the feature which is really most often used or why do customers use service mesh is most of the time because not of the the traffic routing things is most of the time.

B

The security thing, because you can lock down or implement an mtls across the complete service mesh with thousands of services with one very small custom resource, for example, and you can really do really nice things um to offload work from security related things from from developers and their services with very easy steps to do right. So this.

C

B

One of the top things why it is used and.

C

To be clear you wouldn't want to like so turn, turn the service mesh on and off. If you will, you know, like hey, we think we're experiencing increased latency. With this you know a micro service. Let me turn on the service mesh. Let me connect it to the service mesh, so I can collect a bunch of data and then disconnect it. That's I I don't know how you know either simple or complex. You know non-trivial the uh integrating with the service mesh is that may be completely infeasible.

B

Yeah yeah right so normally there is, um you, have a service mesh, there's, no way to just turn it off some in some way. You turn some features off. Probably, but you don't kind of um haven't, have an uh feature switch to turn the complete service mesh on and off, or something.

C

Yeah uh our hope, nine great for hipaa traffic, um not good. If you get ddosed, though.

B

So yeah, um as far as I've seen here, so our um deployment is done. So all the things are created um installation complete. You see. We could now query, for example, to see. Okay is there a connection between the meshes, so we can just go and say: okay, um get the service mesh, pier custom resource and see what the status is here right. um This is something we definitely could do.

B

Okay, so let me open it here.

A

B

Jq in the container and the the important things here is you see? Okay, this is the status section of this peering configuration for the federation and you see. Okay, there is one for the remote, so um the remote for incoming and outgoing connection- and you see important- is that both should be true, and you see. Okay, both are true, so we have a connection. So this is from the stage mesh from our staging environment view.

B

We could check the same thing now from the um production environment, but let's just check if our services are imported and exported, so we could also check now the imported service.

C

B

In the stage mesh from the stage mesh you see, okay, there is an exported name. So this is the name under which the um stage service is now exported, and this is the local service name. So this is the way I would address this imported service now in my production mesh- and this is what we use, for example, for the mirroring configuration you see, there is not a cluster local um service uri, so it is stage mesh imports. In this case, there are also different ways how you could import services.

B

You can import them as local, so there would wouldn't be a difference. So, for example, if you have a detailed service in your namespace locally running- and you would import it also with an um alias of um of um local, so the the actual endpoints would add to your service. So you would have your uh when you address this local service url. You would address your local service as well as load balancing to the remote host transparently right so because the endpoints are just aggregated um at the level.

C

Yeah I like how it masks all of that complexity behind what is effectively a dns entry. You know for for the service um that that makes it dramatically easier for me, a lowly admin to uh to understand.

B

um So you see, we have a broad mesh, we have the stage mesh. These are the things we have deployed. Let me switch to the admin view here. um Okay,.

B

um So here is our production measure environment. You see also here we can launch directly chiali or jaeger. So hyali is our visualization of what we have here. So let us log in.

B

B

So now we have gyalli, this is kind of a visualization and I can see now I can select name.

C

B

In here so drop mesh product book info, what I can do is: okay, let's see the applications we are here. What are um what we have display idle nodes? Currently, there is no traffic coming in right, so no access. So all the things are idle. You see, we have the details service, we have a product page, we have ratings service and the review service in different versions. So we we could do canary deployments and and router traffic there um workload services. Now let us just create some traffic and to do so.

B

Just a second that was the uh here: we need the url of the of the in is your ingress route.

B

So um let us just get the book info url and also then we just curl here in the loop every second, um we just access the um product page. So now we should see in the graph of chiari that some traffic is coming in. So at least this is currently updating every 15 seconds. We can also um display weakness rates response times.

B

Throughput request durations, let us add some things important is that we want to see the cluster boxes here and also the name space, and you see that there is now some traffic coming in um also display the security.

B

So, okay, my browser is a bit slow.

C

So what you see.

B

um We have a namespace the production mesh, which is our control um plane. Namespace here is our ingress gateway. This is where, where our curl requests, so our actual things coming in, so we have a gateway configuration here. The things we've mentioned earlier, so there's gateway configuration that allows traffic to this product page to nothing else. So we can just access the product page and now the product page. There is one workload, one version this one will call the detail service and it will call the review service, and here we have configuration.

B

We have different versions of this review service and we split like one third of the traffic is going to version. One version, two version three and version two and three: they are also accessing the ratings service uh version. One doesn't do it and what we have configured here is a mirroring configuration so for this detailed service um you see this icon means there is a virtual service applied to this actual service.

B

Let's have a look into this virtual service. We should have a look here in the product mesh.

A

These are the sql.

B

Configurations we have currently in place, they should be uh if the browser or something is working. We should see some of the the virtual services- hello, hello, okay,.

C

If you're anything like me, you've got like 800.

B

C

Open at any point in time, so.

B

So it's not really working, so I I.

C

I do like that previous graphic, because I think it highlights a couple of important things um one for me. It reinforces that we don't deploy service mesh or use service mesh in a vacuum right. It's not the administrator defi decided to deploy service mesh so that they could get visibility into what's going on or the application team simply went in and you know created a mesh and so that they can do it. It's definitely a joint thing. It's definitely.

C

The two teams have to work together to understand the requirements to understand the impact to the cluster as a whole. You know both to resources consumed, as we pointed out um before, but also to the application itself. You know hey, I'm I'm going to be. You know, as you're attempting to show here right, I'm going to be replicating data from one to the other. That's going to you know, potentially increase the workloads you know more than you might expect by default type of thing. So it's one of those like I.

C

I had some awareness, some knowledge that service mesh is one of those features that spans both sides of the uh of the street. If you will or sides of the aisle um to use a u.s politics reference- and this very much reinforces that um so almost christian on youtube asks, can you auto inject side, cars in deployment configs uh the deployments or the the samples in the docs use deployment instead of deployment configs peter? I haven't forgotten about your question. I see it too.

B

Yeah, it can of course, inject also and do into deployment configs. um The difference to upstream issue is there is no namespace based injection. You cannot label a namespace to um like, like in upstream istio, so you have to explicitly um yeah um put the the sidecar injection annotation to the deployment or deployment config to inject the sidecar and the the mesh namespace must be part of the service mesh domain right.

B

So it should work that way right. So I'm a little bit confused, um not sure what is not working here, because.

C

This is just it's part of live streaming, something always has to go wrong.

A

C

Johnny's, the uh the king of that.

A

I am yeah. I I learned like you've got to sacrifice a number of goats before uh before you go and do live demos. uh I I failed to do that. My last couple, so things have not gone well, um hey, so orton or one I'm sorry. um There was another question earlier about api gateway integration. um I I know that we can use three skill with seo, but, like our some of the upstream api gateways like kong or yeah, whatever the other ones are, are, are they supported with uh the red hat service mesh.

B

Or maybe maybe not supported in the sense thing really supported. Currently is the three scale integration um there is a web assembly. That's the way you you can extend.

A

B

Service mesh, the features of a service mesh with.

C

A

B

Web assembly um plugins there is one for uh three scale currently, but there's nothing for kong at least nothing officially supported that. I'm aware of okay.

A

Yeah and as I was saying, I was okay supported in the sense of like it'll just work like we don't necessarily support kong in their implementation, but we would support that integration.

B

A

C

So peter asked uh an interesting question a few minutes ago um that I I thought we might want to spend a minute on which is, you know, are: are there patterns or anti-patterns that typically apply or are conducive to using a service mesh? So peter's specific question was: do you are there times where you think you need a service mesh, but really you shouldn't be using a service mesh.

B

I mean this, this question is something you could spend really a day discussing.

B

uh Probably one thing I mean there are a lot of things to consider right. So um one of the things- and this is.

C

Also important and I.

B

Think this is kind of one aspect of this question is what type of applications you see here right. So what what type of applications um are appropriate so to say for a service mesh and um so to kind of yeah looking there at the first step would be, for example, okay, microservice architecture, um so we're talking a server about a service mesh. So um obviously we need some kind of services whatever it.

A

B

Say so now microservices we have a bunch of um let's say, services communicating over a network in a synchronous fashion. This is perfect. This is kind of what it's made for so for, let's say typical micro services architecture, especially um if it's pretty huge and you have a lot of services and a lot of um inter-service communication. So this is really where it makes a lot of sense um to to have a service.

A

B

um The other thing, um for example, what is with monolithic um applications, so we only have like two three, so very typical. If you think about java, you have an application. Server type of application with I mean monolithic, doesn't mean it's not modular or something it's just from the aspect of you have like different development teams, contributing the same code base and you have more or less one deployment unit right. So um does it make sense if you have two three monolithic applications, some databases, things like this: some caching or uh message queue uh it.

B

Yes, it could, but to be honest um service mesh, doesn't add that much right. So in this case I would think you you could, or you should think carefully about using a service mesh. uh What features do you want to have or want to apply so security in terms of implementing it with a specific library or something might make more sense in this case, for example, so the the reality is with monolithic applications. Service mesh doesn't add that much that much.

B

If you have a lot of inter or communication between monolithic um applications, okay, then it might but yeah think about it. What is with uh with serverless applications, this type of thing um yeah, I would say definitely in this case it makes sense why, because serverless applications, and I'm talking now about openshift serverless, which is based on k native, so we actually use also containers like everything else. It's basically just a different packaging format we have um for serverless, and you can scale to zero things like this.

B

There is also an official integration with serverless, but the essential thing is here that serverless applications are actually microservices even smaller. Most of the time they serve for a specific purpose right, so um so definitely with serverless. It makes sense with microservices it makes sense. Then I have some customers also um asking what is with jobs, run jobs, batch type of things, right, processing,.

C

Yes, I would say.

B

It uh it depends on the actual implementation of a job. What is this job doing? Is there uh some? You know, communication involved where you need observability? Is there something involved where you need to secure the communication flow to?

B

Because you know very often it's things like you start a job.

B

The job is kind of um grabbing something from a job queue, so there's an implementation in kafka, whatever a database where we grab some um actual jobs or what the job should do, and then it's executing job things like this, so it depends really on what the job is doing and the problem with jobs is always you have. We have the sidecar container, the invoice thing, and um so the job won't finish.

B

If we don't um kind of um shut down this user proxy right, so you need- and there are some workarounds- I know of them- but um there's not really an official way so to say that we support jobs and crown jobs. So it's possible and it depends on the workload but um not really the the best kind of type of workload. I would say right.

C

B

Highlighted the.

C

B

So so sorry, I don't want you to interrupt so.

B

Yeah. Okay, sorry.

C

Anon just highlighted, or the same thing that you were just saying around you know the job status won't complete if the proxy sidecar is, is there and you know.

B

C

um So there's a number of questions that have come in and you know for our audience. Please um go ahead and submit any questions that you happen to have.

C

um I do want to be a little bit cognizant of time, because I think I have a meeting coming up here shortly, so um I I will get through as many of the questions as we can um again any that we can't answer here on the stream we'll follow up in the blog post, we'll make sure we get all of those answered, uh including the slides that erwin has and all that other stuff and um or or when you're very popular, because we've had a couple of folks asking like.

C

Can we have like more than one of these streams? Can we have like a mini series? Type of thing, so you know stephanie. Yes, I do care about your lunch hour. Stephanie's chatting me on the back end here. um I I do care about your lunch hour. I, I am obviously a very um we'll say healthy individual. I also like like lunch myself.

C

A

C

So just a couple other questions that we have here um and please everybody keep me honest- um will service mesh trust, self-signed certificates applied to routes, openshift routes.

B

To open shift routes.

A

So, if you're using the default c8, if you're coming in right coming in on the route, it's going through the h a proxy over to the envoy, will that accept that self-signed insert.

B

Yeah it it does, if not, it depends on on the the route config. If you kind of terminate at the route level or if you kind of um configure the route as pass through, then you would need to have the the issue, um the the from from the ingers gateway, the certificates for um the client side right. So but in general I would say yes sure.

C

B

Either way regarding just just one thing to mention, because I'm also working on this topic, we know that especially you know all these day, two operation, things in the context of service mesh, they are pretty much um complex. There are a lot of different ways.

B

You could do things right, because there's so many options and so different types of requirements, and um we also know that the documentation or kind of you know best practices on how to do things in especially from an operational side that there is kind of also a let's say, lack of documentation and currently we're working on a on a service mesh day, two cookbook, you know where we try to cover some of these things, so just for yeah for admins for operators, so if you're planning, for example, yeah implementing the service mesh, if you, uh what are the things to consider if you want to head to production- and things like this, this is uh yeah just to make you aware, there's something coming.

A

Yeah or when you guys should do a service mesh coloring book.

A

Or or just turn it holding on its head and just do a comic book, you know just have like its own little like superhero thing that would be kind of cool. I go ahead. I've already, given you permission to, do it you're good, to go.

C

I've pre-released this idea um so can can the open shift service mesh be extended outside of openshift, for example, to include a virtual machine hosted in rev vsphere, you know, or even a physical server.

B

Yeah, this is kind of um as far as I know, a road map item, so we can say, can can you use openshift service mesh outside of openshift? The answer is no, so it is not supported outside so the service mesh itself.

B

This is um based on upshift, so there is the dependency but um including like what we have. What we had before, like external bare metal machines, uh virtual machines which are outside the mesh outside openshift. This is something which is a roadmap item and I don't know andrew you said: I'm not really aware. If this is already ga, I'm I don't think so, but uh my current status, this is a roadmap.

B

I had a roadmap item for for the over next release, so for 2.3, which would be somewhere in I think june, or something so in the middle of the year. So yeah answer would be yes roadmap item. This is coming.

C

So not not yet, but eventually yeah excuse me.

A

So there's another question from um and I'm so sorry, if I messed your name up seriousness um and it was, how do you access an external service using the tls origination from an egress gateway so like once, you set up an egress gateway in your mesh? How do you access that tls endpoint.

B

Yeah I mean the the the way you would configure it is for external services. Normally, you have you create a service entry right to to make this available to the sqo service registry, and then you configure a virtual service and a destination rule or or two where you kind of redirected, traffic to the egress gateway and there you would configure in the destination rule the um tls config for the outgoing um service, then right.

B

So this is something also documented in on istio side and I'm not sure also on our side.

C

And then I I think the last question I see here and apologies for any that we missed I'll again. We always go back and look at all the chat and everything to pick them up. But um I apologize for butchering your name. Elchin. um Can we add a delay to the sidecar shutdown.

B

B

I'm not sure I think you can with the with the um annotation for envoy proxy, but I would have to look it up um exactly. I think it is possible with an annotation, not a 100.

C

Sure, I'm really 100 sure on anything, so yeah.

A

I'm 100 sure about that.

C

I I had a I had a conversation the other day it was al, always never use always or never yeah.

C

So all right. uh Thank you very much. uh uh Ortwin really appreciate you joining today. This one has been a long time in the making, and it has certainly not disappointed from my uh from my perspective, I've learned a ton here. um I expected to learn a lot and I learned even more than I expected to so. Thank you so much and I know.

B

Yeah, thank you for having me here. I mean um always happy to to share something and um just to consider that was just seven of my 90s 90 slides I've prepared so there there is probably some content for an additional session somewhere yeah.

C

Just a little bit, I I know who we can reach out to whenever johnny and I are are struggling to come up with ideas or topics right. Okay, so thank you so much for joining us today. um Ortwin, you know again really really appreciate it. I know our audience has uh has appreciated it as well. There's been some folks who've been waiting for this one too um yeah.

B

Thank you and thank the audience as well for all the the the questions and the the engagement. This is really great.

C

Yeah, so for our audience uh again, thank you for joining us. If you have any other questions that we didn't get to, if it was happened to me something we missed for anybody who is not watching us live you're watching a recording, please don't hesitate to reach out. You can contact me uh via email, andrew.sullivan, redhat.com, I'm also on social media, so twitter, at practical, andrew. Just like you see on the screen there uh on reddit on all kinds, all of the platforms, all of the places you can find me and johnny as well.

C

I will happily throw him under the bus for uh being a public contact, so I can it's. uh I always have to look at the screen to remember your twitter username for some reason.

A

C

You've been here for like six months, and I still have to look at it every single time because when I type it into twitter, I just do at j and it's you and that's right. Most.

A

Important first.

C

Yeah uh or johnny redhat.com and that's no h, j-o-n-n-y.

A

Yep and I'm pretty active on the reddit channel or the reddit subreddit. So if you, if you have questions out there, just go ahead and post them and I'll try and reply.

C

Yep, so thank you. Everybody! Please join us next week where we'll be joined by the microshift team uh and then we're looking at some other topics a little bit further out, so things like openshift virtualization, maybe bringing back some vmware folks so on and so forth. If you any have any thoughts, ideas, suggestions, etc, please don't hesitate to send those are well. I can't talk all of a sudden. Please don't hesitate to send those our way as well. uh So with that I'll uh I'll leave. The last word with you: johnny.

A

Ortwoon, thank you so much andrew. This is a great show.

C

And johnny died on us. Oh.

A

No, um I'm I'm lost too you you.

C

Made it out, we lost you for like 10 seconds there, so I'm sure whatever you're saying was awesome.

A

All right but yeah, so so, if you have, um if there's something that you want to see, then you know let us know and we'll try and get a demo for you. You know just just let us know what you want to see, especially when it comes to the surface mesh stuff, because, like there's so much and like you can see, we barely even scraped the surface. So yep.

C

All right well, thank you so much everyone have a great week and stay safe.

B