0:50 Introduction & Housekeeping

0:50 Hello, and welcome to today's episode of Rawkode Live. I'm your host, Rawkode. Today, we're taking a look at Telepresence, a tool for helping Kubernetes development, which has been notoriously difficult over the years. Now before we get started, I just wanna start with a little bit of housekeeping. First, if you've not subscribed to the YouTube channel, shame on you. Please do that now and click the bell so that you get notifications for all future episodes. Also, if you like to chat, talk cloud native and Kubernetes, there is a Discord server where you can come and join. We are

1:20 around 400 people now talking about all things tech all the time. Really good fun. Come and say hello. And, of course, lastly, I wanna thank Equinix Metal. They are my employer, but they also allow me to produce this show on their time, helping us all learn cloud native together. So thank you Equinix Merrill. You can use a code Rawkode. This will get you two hundred hours of credits to test on our platform. That's roughly four hundred hours of compute if you use a modest instance, but you're gonna have much more fun using it with the bigger instances.

1:48 So, you know, use it as you wish. And today, we're taking a look at Telepresence. Sorry. I caught a comment out of the corner of my eye. I'll answer that in a minute. No. Today, I'm joined by Daniel and Peter. Hello. Hello, everyone. Hey, David. Yeah. Sorry. I I don't often get caught by comments but it just popped right up and it was just Noel asking do I have new headphones. Very good thing to know. Yes. I do. My wife was moaning at me because my last headphones were noise cancelling and I would talk too loud so these are open ears so

2:21 that I can maintain my volume. Anyway Brilliant. Random segue. So thank you for joining me today, Daniel and Peter. Do just wanna just take a little bit of time and tell us who you are, what you do? We'll start with you, Daniel, there. Yeah. Hi, everyone. Thanks for the intro, David. Thanks for inviting us along. So my name is Daniel Bryan, director of DevRel Ambassador Labs. My background actually started in academia, but then moved into Java development. I say my native language is Java, then a whole bunch of JavaScript and other things along the way.

2:25 Guest Introductions

2:50 Reluctant operator is what I like to say to myself. Right? I was always the build person. Like, I I naturally gravitated towards Hudson and then Jenkins as it changed, and then kinda just followed that through my consulting career in London, doing a lot of work with Mesos. And then, of course, when Kubernetes came on, like, initially betting on Mesos, then suddenly I realized, hang on. Kubernetes is where it's at. Right? And then I've got friendly with the Vasa Labs folks or Data Wires, we were called back then. And Telepresence, the first version of it, was just popping up. And and for me,

3:18 it solved a real problem. And that's actually when I joined the company. I was like, this Telepresence tool and then the Ambassador API Gateway, super useful for what I'm doing. You know, I like these people. I should work with them. And that's what I did. Peter, over to you. Cool. Thanks, Daniel. Yeah. So Peter O'Neil, developer advocate at Ambassador Labs. I kinda got my start in network engineering, moved more into dev ops space, did a little bit more coding stuff, came across DevRel about a year ago, and then moved over to Ambassador Labs about six

3:46 months ago where I've kind of been, leading the charge on on talking about Telepresence and teaching Telepresence, kind of, like, getting it into the hands of as many people as possible. And so yeah. So I've been having a great time kinda kinda kinda playing with the tech. So great to be here, David. Mhmm. Awesome. We have a Java developer and a network engineer. Awesome. It's a nice It's like a big of a joke. Right? Well, yeah, definitely could be. Walked into a bar. Yeah. Yeah. No. I'm not gonna try and make up a joke. I'm not that smart. Right.

4:17 Discussion: Java in Cloud Native

4:17 How is Java in the cloud native landscape these days? Is it better? Because it it used to be quite a challenge. Yeah. I mean, funny. Richard, like, boss and I were just talking to everyone today. You know, the advent of Spring Boot in particular changed a lot of stuff. So hats it to the Spring community. The the Java community and everyone sort of picked up from them. There's Microprofile. There's Quarkus from the Red Hat team. There's lots of interesting web frameworks in the space now that have baked in cloud libraries, cloud primitives. So I'm playing around a lot on

4:45 my free time quite a bit with Quarkus. It's super interesting. You can do native builds, for example. So, like, a lot of problems you have with the big JVM of kind of you know, you can address them now and run small footprint stuff. That's awesome. Yeah. I was always really excited by GraalVM. I thought that was really exciting. That's it. Yes. Yeah. And Scala, I think they just last week, they released version three of that language, and I always really liked writing Scala, but running the JVM and containers just got really cumbersome. So maybe that's something

5:00 What is Telepresence (Slides)

5:12 I can start experimenting with more now. That's cool. Right. Here, that's our segue done. Let's get let's get back on track. We're gonna talk Telepresence today. So I believe, Daniel, you're gonna give us a little bit of a quick introduction, and then we're gonna get straight into our hands on section. Yeah. Sure thing. Let me just set us up here with the share screen. There you go. You're up. Looking good. So I'm sure anyone who's a coder will recognize this. You get the inner and outer dev loops. Now the massive hat tip to Mitch Denny, where I got the initial idea

5:18 Introducing Telepresence & Kubernetes Dev Challenges

5:47 from. Unfortunately, the the blog post has disappeared now. It's a four zero four. So I've managed to find the graphic from someone else who's saw this as well. But you'll recognize that if you're doing TDD, you get that inner loop. Right? You come up with a test. You write some code. You verify it, and you go go around and and, you know, you're often working locally here. Even if you're not doing TDD, you come up with an idea. You code some stuff. You, you know, put your print line in. You see what's going on. When you're happy, then you go to the

6:13 outer loop. You typically, you know, commit to git, commit to, you know, version control. You might run some integrations, some testing, and then you release ultimately and and so forth. Now the challenge we've seen oh, I'm challenge we've seen with Kubernetes is once you get to a certain point, if you the in and out loop are quite similar. You're writing code, then you're building a container, you're pushing to registry, deploying to cluster just to test, and this can be quite slow. You know, you wanna stay local as long as you can, You wanna mock things, but, of course,

6:45 when you're running, like, say, mocks, stubs, doubles, there's a whole bunch of assumptions in there. Right? So sometimes you just you're in that small little inner loop, but you really wanna test what you're doing against some dependency. And you really wanna avoid that docker build, let alone the docker push, like, to a remote registry. Right? And it's something that Peter and I play around with a lot is you actually wanna be using your own tools locally. So, you know, much as you might have some services running on a remote Kubernetes cluster, some, you know, locally,

7:15 you wanna be connecting them all up but using the local tools. You know, I'm sure many of us know about remote debugging, you know, ports and, you know, Kubernetes cluster or just their VM in general. But, you know, swapping between local then remote, local and remote is all a bit of a hassle. When you're starting out, a lot of folks do just code literally everything locally. Right? Pick your poison, Docker, minikube, branch, or micro kits, k three s. But and this comes from my Java days. Once you get past a certain number of services, your laptop, even, you know, even a nice

7:49 max 16 inch here will not keep up. Right? Like, you you just you get that point where you have to expand into remote cluster. You know, you can't run all your services locally. And that's where Telepresence really helps. A bunch of different sort of phrases I've heard around Telepresence is fancy Kubernetes VPN for development. It's something I hear quite a bit. Kube couple port forward on steroids. Hear that one quite a bit. And if anyone knows that Kube couple port forward, like the syntax, I always have to Google it because it's quite tricky to remember. Right? And and you're

8:00 What is Telepresence?

8:20 doing one pod at a time, whereas Telepresence kinda makes that much, much easier. So that's why they're on steroids. But fundamentally, it's a network bridge between your laptop and the Kubernetes cluster. So I mentioned a few times there that kind of scenario where you got local services and remote services. Telepresence is that bridge. So we can do stuff locally without Docker build, without Docker push. We can use our IDE, use our tools locally as if we were in the cluster. The local services we got running are bridged effectively in terms of network namespace with the remote cluster.

8:53 And if this seems a bit sort of hand wavy at the moment, the demo that David is gonna look through and and Peter should make this all super clear. Telepresence is one of those tools and you see it, you're like, oh, yeah. Totally get it. You try it, and then often you really, how do I do development without it? You often think. Right? So that's the kind of setup I wanted to do, if that's alright, sir. Perfect. David, I'll stop sharing. Alright. Thank you for that. So let's ask you the the the difficult question, easy question. Oh, we'll see.

9:15 When to Adopt Telepresence

9:24 Like, the the picture with the laptop on fire. Right? I think this is a problem that is now ubiquitous when I speak to people that are trying to work out how to get their development workflow working in a Kubernetes environment. And there's a certain pain threshold, if you will, that at x number of services, it just doesn't become physically possible anymore to run all that stuff locally. You do need to revert back to like the shared dev server of 19 whatever 90. Yep. So if we invert that a little bit, does it make sense and would you encourage

9:56 that everybody starts to look at Telepresence now regardless of the number of services with that pain with that pain point there, or do you think that there's a certain point where then you start to look at Telepresence? Like, does that make sense? It does. Peter, do you wanna have a go at that one? Oliver Oliver think. Yeah. Definitely. And so so what it really comes down to is building out a consistent development workflow. Right? And so so if you are a team of one, it it may seem like a bit of overkill because you're like, oh, I can do

10:28 all this stuff now. But and so then when you change the process later, then you have that that that that change tax where all of a sudden it's like, oh, now you're trying to introduce something new. So if you can actually introduce Telepresence when it is only one service and one person, right, and then you add two or three more people onto the team, all of a sudden now you have this process that scales very well as the team grows with you. So so so, yes, like, you you can adopt it very early and and but I

10:56 think it scales very well if you do. Awesome. That's exactly the answer I was hoping to hear because I think that you're building these really good development practices early is really important. And I'll go back to something Daniel said in the slides as well is that doubles and mocking are never really good enough. Right? And especially if you're using cloud, you know, provided services like s three or RDS, etcetera. You know, we do have tools like local stack that try to provide enough of an API that your application's gonna work, but why not just use those actual services

10:59 Discussion: Mocking vs Real Services (Fidelity)

11:27 and actually have guarantees in the way that it's gonna work? And I think those approaches definitely work better for most situations. I would add that's great point there. And I would add, like I've got a hat to it always on on every chat, really. Cindy work, copy construct. I'm sure you bumped into her fantastic writings. And she talks a lot about fidelity. Right? It's the amount of fidelity you want. Like, there's the testing against, like, mocks, which gives you you know, it's quick, but it gives you limited confidence. Then you can fire up, say, local stack.

11:54 It gives you a bit more confidence because it's, you know, an emulation of those data stores. But then if you actually push into, like, the the real thing, well, the fidelity is super high there. Right? But it can be typically a bit slower. So I think for me, it's let's see if anyone hasn't read Cindy's work. You know, after the stream, Google copy construct. She's on Twitter. She's on medium. Like, some fantastic blog posts that talk about the trade offs around fidelity when testing. Yeah. And generally just all around awesome writing under a Sherpa system. Yeah. Find just go

12:23 read everything on the blog. Yeah. Basically. Alright. Well, awesome. I'm really excited to start playing with Telepresence. So let's get my screen shared and we're gonna start from nothing. We're gonna see how we can start to use this for our development workflow. So let's see. We have three floating heads. I have the Telepresence documentation, and I have a terminal. It's all I need. Right? We happy? Looks good. Looks good. Looks good to me. Yep. Alright. Awesome. So let's see. I'm assuming I'm gonna have to just install the Telepresence binary to my machine. Yep. Yep. Just do Yeah. You could just go all

12:30 Installing Telepresence

13:09 in whole block if you want. Yeah. Yeah. We could go all in on the quick start, David, and it literally downloads and does everything for you. Depends how manual you wanna go. Oh, I skipped the page. Yeah. If you go new to Kubernetes on the left there, like, it'll literally provision your cluster up in our cloud and also give you a package to download, and it will then download Telepresence everything for you. Okay. So let's see. Sign in to ambassador cloud. Let's do that. Did you wanna give us the the pitch on ambassador cloud while I just

13:19 Using the Quick Start & Demo Cluster

13:43 quickly sign up? Yeah. Sure thing. So I'll have them oh, go for it. Go for it, Peter. Sorry. Yeah. So so I'll say Ambassador Cloud is is something that we've relatively recently added, and it connects our open source tools under kind of one umbrella and allows you to to to have, like, one central place. For, like, Telepresence, we have the idea of what is an intercept, which which does the connection. And so Ambassador Cloud can hold those for you. And, like, you can see a list of not just yours, but if you are associated with the team, you can see intercepts

14:17 for for the rest of your team as well. And then that allows you to share and collaborate very easily. Okay. So it has downloaded something. You have to unzip it. Maybe should be good to go. Alright. I have a cube config and an install fail. I was gonna be very trusting there, but you know, maybe I'll just get it at least. Yeah. I've curled it and picked it to bash just fine. But the fact that I downloaded it, no. I gotta be careful. Alright. I like the way you completely skipped over the read me as well. Love it.

14:58 Read me's what? What are those? Okay. So several dependencies. Oh, okay. Let's do something. So should I have read the read me? Was that was I being very That's up to you. Peter and I spent like hours crafting the perfect weaving. We're not offended though. Right? Alright. Okay. Let's read that. Actually, it has to the team. I don't think it was us that wrote it, Peter, was it? I don't think so. I think I think we might have commented on it, though. Yeah. It's our amazing engineering team that have done a lot of the heavy lifting here.

15:37 Yeah. I I always really appreciate it when companies provide these kind of just one push button deploys to give me something to actually play with it, test with it with. So it's really cool and that I was able to do that. And I didn't have to enter a credit card which is always a major plus one. So we've installed this is telling me I now have access to Telepresence. We have some demo applications. It looks like we've got something in node. We've got something in flask slash Python. Fast API is that Python too? Is that

16:08 something else? Yeah. Yeah. Okay. Java and go. Where's the rust? Where's the rust love? And I can reuse install to trigger any of it. Okay. Nice. Let's just make sure I have the Telepresence CLI. That was nice and easy to get started. Now I just jump back over to here and okay. So now let's test that cube control. The chat people know me so well. No rust. Rawkode will be sad. Thanks, Nuno. Now your audience. Good stuff. Yeah. Let's export our cube config. What was it called? Dot YAML. Wait. I already had one here locally. That

16:56 could have been awkward. At least it would get. And run. Let's see. Looks good. So the I just wanna make sure I got this right. This is provided to me via ambassador cloud. It's just a Kubernetes API. I don't know if oh, yeah. KCS, I can see it there in a version. And and this is just mine. I can use this. Does this disappear? Does it run for a certain amount of time? Can you maybe help me understand the magic a little bit? Yeah. With the so so with the with the quick start, this spins up

17:34 kind of your access to one of our demo clusters. And the demo cluster, we I think we we've changed the lifespan of them a couple times, but right now, believe it lasts a couple of days. I have to I I don't remember exactly, but but, like, I think you have a couple days of of where you can log in and use it. But then once it disappears, you can just start it up again and get a get a brand new demo cluster. So is this namespace exclusive to me, or am I sharing this with anyone else that

17:58 just happened to kinda be using it at the same time? No. No. The whole cluster should be yours. Like, it's one virtual Kubernetes cluster. So that whole thing is yours. Awesome. Cool. And we do watch for bit more coin mining. If anyone's thinking of jumping in. Right? I wasn't gonna make that joke. It didn't cross my mind. I thought, no. Let's not put people ideas in people's heads because these they don't need anymore. But you're right. You were straight in there. I don't know. Were you susceptible to any of the pull request spam over the last

18:27 few months with crypto miners and open source projects? I know that we got hit by a fair bit on Tinkerbell and other projects. But like, you know No. That's CircleCI and and and that gets out for example. Right? Sort of, know, big name casualties there. But no. We do monitor our our sort of stack pretty pretty aggressively. Yeah. That's perfectly understandable. Alright. Okay. We run get services. I can see these are running. So we've got our Kubernetes one, which is just API. We've got some other services running. So it's not asking me to run a

18:46 Connecting Telepresence to the Cluster

18:58 Telepresence status. Mhmm. That raises questions. So as Telepresence using my kubectl context to understand if I already have something running, or am I making too many guesses? Yes. So so with that Telepresence has parts. Right? Because Telepresence is is bridging your local laptop with your remote cluster. Right? And it's creating what is kind of like a VPN, but it's more so bridging your local network with that remote network. So there's two two pieces, like one on each end. Right? You have your Telepresence, binary locally on your machine, which runs that local daemon, and then you have the what

19:00 Telepresence Daemon / Networking Magic

19:41 is called a traffic manager running in the cluster. And those are the two pieces that create the bridge that allows you to access the network resources in the cluster. Okay. So these ambassador pods, are these what are fulfilling that duty? No. No. I think it's not running yet. Once you actually when the next steps when we actually connect, Telepresence is going to do a scan for for those services. And when it doesn't see them, it will spin them up. Right. Okay. Yeah. That makes sense. And so here we here we we are asking for the password because because we are

20:22 starting that local daemon, that is a suited process. Yeah. I've made so many mistakes typing my password in that I'm just gonna run off screen. Open up your notepad with all your passwords and you're Here we go. I don't know. It happened to me like it was with Alex Ellis. I don't know if you're familiar but we we did the stream together like four months ago or something. And the actual shell of the pseudo process segfalse which I've never seen before ever as I was halfway through typing my password and it was all on the screen. Oh.

20:57 So now I'm just always that little bit extra careful. Even though it's just my laptop password, there's there's still I'll I'll take precautions. Okay. I'm really glad I ran get pods all before just out of sheer luck I guess. Now we've ran Telepresence Connect. So what I suggest or what I think is we're gonna see nothing different. Oh no. Do we? Yeah. Very last one. The very last one. Yeah. Cool. Yeah. I missed that. Okay. So that's just running the traffic manager, enter cluster. I'm assuming I'm sure I could read the docs and it's gonna tell me what

21:33 to do, but I like to assume yeah. There we go. We now have bets connected stuff to do even though I don't know what that stuff is here. Awesome. So, that's interesting. The magic just keeps coming. So I can just curl and hit my cluster? Yes. So so so this is this is the networking that I was previously speaking about where now your local laptop has a direct network connection into your cluster. So your DNS resolution in the cluster is now available on your local machine, and that Kubernetes service in the default namespace is now reachable

21:37 Accessing Cluster Services Locally

22:18 through the Kubernetes API. Mhmm. Fancy. Alright. I've got a few maybe two questions. So if I am switching kubectl context regularly, will that be a problem for Telepresence? So so right now, Telepresence, it it if you start it up and you switch context, it will it will air out because it'll say, oh, context has changed. And remember, the Telepresence binary on your machine is essentially creating a tunnel to one cluster. So right now, that is that is a limitation where you'd want to quit out of one connection before you started up a new connection with another cluster.

22:26 How Telepresence Networking Works

23:05 But but it is something that we are aware of, and because I feel like no one has just one cluster nowadays. Right? So so so it is something that that that we we we have a we have a note to to see if we can make that switching a little more seamless. Alright. Okay. So is there a like, did I run Telepresence disconnect when I was changing cluster? Is that a command? Am I We have we have Telepresence quit. Quit. Or Telepresence uninstall, which will actually remove the the will tear down the the pieces that create the connection.

23:39 Okay. Telepresence quit says there's something I would type after. I've got my unit test failing and I'm giving up for the day. So maybe maybe I think I'll enjoy that after a bit more time. Okay. So that's I mean, right off the bat, that's just interesting. Querying the an actual service within my cluster locally. That's pretty cool. I really like that. That is a while straight away, David. Right? In terms of like it's even more impressive when like you're hitting a like I said, an application, which we'll do in a minute, I think, in in the getting started. Right?

24:09 But I remember when I first up, this is kinda cool. Right? Before I'd have to look for the pod name, do a koo kettle port forward, hit that, you know, all that kind of thing. Where's this? Like, one command? Now you're sharing the namespace. Yeah. Because the fact that it's working with my actual host networking through some mysterious way. Yeah. We can ask questions about that but I probably wouldn't understand it but maybe we can talk about it. But I mean, there are no limitations on the way that I work or develop my application locally. If I

24:40 just if I don't wanna use containers or Kubernetes at all, I mean, I could just do go build and go run and it can speak to Kubernetes services. Right? I mean, that's that's pretty special. Like that's that's not something that we're used to in developing against remote APIs and I I really like that. That's that's nice. I mean and now though you're completely overshadowed the fact that you've given me a dev environment for sudo free for testing as well as that's no longer important. What's important is the network magic. I mean how confident are we talking about

25:12 the networking stuff? Can we dig into that a little bit? I'm curious like is it a am I written table? Is it DNS resolution? Is it intercepting all my traffic? Like, if I open up Twitter.com, is it gonna go through Telepresence first? Like, can we maybe just shed a little bit more light on that if we can? Yeah. Definitely. So so now that you've established that connection and the tunnel has been created, what the Telepresence, the local Telepresence binary, what it's doing is it's it's adding in the DNS resolution for the Kubernetes objects before your normal resolution.

25:50 So it's looking for, oh, he's the the user typed in dot default or they typed in dot namespace a. Right? And so those things will try to get resolved first against the cluster. And if it doesn't see that, then it will default back to your normal network. And so the other thing the other thing that Telepresence does on that connect is it builds a it builds an IP tables, kind of construct and just says, oh, this is what's available to me. And I think I think we'll get to it eventually. But there's a if you run Telepresence list, it'll say

26:18 everything that it sees in the current namespace. And so those all get created on the Telepresence Connect, which makes it very quick once you actually want to want to curl that service or access that service. All of those IP table routes are are created up front. Ah. Mhmm. Very cool. Okay. Let's get back to the actual doc. I'll I'll stop driving us down little rabbit holes here. But, yeah, we can run get paused. It never seems super interesting, though. Right? Yeah. I mean, coming from the network engineering background and then Yeah. Like, once I touched

26:53 Kubernetes, I was like, wow. There's a lot of networking in Kubernetes. Yeah. Definitely is. Okay. Yeah. That's really cool. So DNS plus IP tables all mixed and matched together to give us exactly what we need from the cluster. Okay. I've lost my place. Kubernetes we did. Get pods we ran. Also now I can just browse to our very large Java service. And there it is. Educorp. I like it. Edgy's our mascot. David, know if you've seen our little blackbird on Telepresence, Telepresence. Name. Edgy. Edgy. Edgy the bed. Yeah. Edgy the blackbird. Alright. Yeah. Feel like we we we need

27:15 Running and Intercepting a Local Service

27:37 to update this. We really get a picture of Edgy just on on that on that page. Totally. Totally video. Right? Yeah. Yeah. Definitely. Front and center somewhere here. Okay. I'm AJ. Welcome to my company. Yes. Okay. I'll get over the magic of the networking. Let's let's do something. So we've got an NPM application here that we can spin into and run. It is worth doing, David. Just on instruction number three above, just like nothing under the sleeves. Right? You should see the Edgecore website with a green title and green pod because we're gonna change some of that stuff.

28:12 Mhmm. Alright. Okay. Okay. Just so everyone watching along as well, it's it's green. Yeah. Okay. So the node application that we're potentially gonna change, you're you're gonna ask me to change the CSS or something that change the color of this. Is that where we're going? Okay. Yep. Alright. So that's c d and I need to just n p m start. So I don't need to do an install first? Are we shipping node modules here? Yeah. Okay. So we've got a local process running on port 3,000. Should I browse to that? Oh, yeah. There we go.

28:57 All the answers and I just keep going in questions anyway. Okay. So we got something here where the color is blue. Yep. And now we're gonna use a Telepresence Interceptor to I won't guess. I'm gonna I'm gonna delegate that to someone here. Pierre. Yeah. So so so so now we're at the part where we're actually intercepting traffic. Right? And so for if anyone if anyone listening, used Telepresence one, we used to call this swap deployment where there there we actually kind of swap the deployments out, and now we call it an intercept because it is much more

29:19 Unauthenticated Intercept

29:42 of a routing rule where we are intercepting traffic, destined for a service, in this case, data processing service. Right? And we're intercepting that traffic. It's hitting that traffic manager in the remote cluster, going to a sidecar, and then being routed down into your local Telepresence, binary where it can hit your local service. And so and then from there, right, Telepresence also gives you access to to the Kubernetes API. So if your local service is reaching out to any database connections or other services, right, then you can it gets passed right back through. And so that intercept is kind

30:16 of handled seamlessly as it connects your local laptop into the rest of the cluster. Sweet. Alright. So before I run that, let's tackle a question we got on the chat then. Naveen is asking, does every developer get their own demo cluster or a shared one? I think on our conversation, what we said is that we each get our own virtualized Kubernetes cluster, but can we just confirm that, I guess? Sounds good. But there is a limited number. That's the only thing. Yeah. And I think, actually, if you're on a shared team, you you actually end up

30:30 Discussion: Intercepts & Collaboration

30:51 getting added to the same cluster. If you add with your personal GitHub account, you'd have your own demo cluster. So I think that's but but once you actually start using Telepresence, you're gonna be using it with your own cluster. And whether you wanna share or not, that's completely up to you. Yeah. When I signed up, it did ask me which of my teams I wanted to use for for this, and I just selected my own personal account. So I guess if I had selected Equinix, then anyone else at Equinix is selecting Equinix. We'd probably get the same one. So cool.

31:19 Mhmm. Alright. And if there's a lot of folks jumping in, we might see, like we we don't have a camera we we run now. But I know, like, a few times, if there's lots of people, like, on a on a livestream, on a demo, like, is a limited the finite number of the the free clusters. But you could totally spin up Docker desktop or something else or GKE, I've often used. It won't stop you playing around with demo, but you might have to come back tomorrow and try again if you did wanna use our one.

31:43 Yeah. Great points. I'm assuming that because we downloaded that KubeConfig as part of the registration part with a master cloud. But if I was using my regular KubeConfig, when I run Telepresence Connect, it would just have set up that traffic manager on my own cluster. Like, they're completely irrelevant that my cluster came from this place right now. Well, except for the example services, of course. Yes. Yep. Alright. And then we got a comment from Lewis who just thinks he's being funny. Spelling color the Yukui. Nice. I I had this conversation with Daniel all the time. You

32:20 know, I think I've just worked for so many US companies. I've I've just given up and I I know just type everything in US English. Okay. Let's intercept some traffic then. So let's just jump into here. Why is that red? Oh, the paths. So when I ran the install Yeah. Set the path to your that current directory. Oh, is the banner which is here? Yeah. I'm guessing. There we go. Okay. Yeah. Thank you. Yeah. There we go. Alright. So now we're setting up an intercept for data processing service on three slightly off the bottom of my screen there, Dave. Don't know if

33:03 that's Yep. I do that every day. It's because I use that like a tile and window manager on Mac that automatically sets the size of my windows and I keep forgetting that the bottom of my console is not visible. Nice. Well, thanks for mentioning that. Otherwise, it would have taken me like forty minutes if I remember. Alright. So our intercept was created. We're not doing any SSHFS. We can talk about that I guess in a minute. But now if I curl on 1 2 7 0 0 3 Thousand oh, that's the destination. Okay. Is this telling me that there is something

33:40 and the traffic manager of my cluster, I redirecting traffic to the data processing service to my local machine. Is is that correct? Yeah. So so so what would go to the data processing service in your remote cluster is now being forwarded to that that local address of 12700 on port 3000 because we specified that port flag at the top. And so if you're obviously using a different different service, you can specify whichever port is running locally. Yeah. Mhmm. What about I'm trying to think now, like, you know, say we've got a large Kubernetes cluster or

34:14 dev team or, you know, maybe six people and we both wanna intercept the service at the same time. Is that something that's possible or is that a conflict? So so there's the difference between authenticated intercepts and unauthenticated intercepts. And so when you ran if you or if you run Telepresence status one more time, you're gonna see that you are logged out right now. And and so we we could show this again at the end, but, essentially, right, that gets down into the difference between team collaboration and solo collaboration. If you want to authenticate to Ambassador Cloud, and connect to your team,

34:52 that's when you have those team features. And so that's when you can do, more specialized intercepts and do things like separation on header based routing and and and more collaborative tools. But right now, this intercept, because you're unauthenticated, is just sending all traffic down to your local machine. It's not it's not separating anything. Awesome. Cool. So I'm assuming the docs are gonna tell me to refresh edgy corp in a minute. Oh, no. We have to make a code change first. Right? No. No. No. I think I think it's that step two. You might have skipped over

35:28 it. So after that intercept oh, yeah. Okay. There we go. We went from green to blue. And now it's telling me to make a change to make it orange. All right, let's see. Dataprocessing@.JS. Well, that's annoying. Let's just close it. Educator data processing that. So this would just be me as our developer working on my micro service locally, making changes as we go, and these are just gonna be updated in real time. Yep. So if we switch back there, we'll see that node picked up the change, restarted the service, and and now we can refresh.

36:39 Yeah. I think this is the kind of feedback loop that everyone working against Kubernetes wants. And I don't really feel that we've ever really been there yet, but less magic y stuff, doing things that I don't understand is very cool. Just to paint the picture again to the folks like well, showing on the stream. So we're now, like, going into the very large Java service. It is calling out to the data processing service, which is on your local machine, which your local machine is reaching into the cluster again to the very large data store, getting some data. It's coming back. Data processing

37:12 service is returning that to the very large Java service. The very large Java service is building its web page. It's like a spring app. So it's kinda cool as we've got, like, requests coming in through, like, a, you know, a front end microservice, if you like, maybe the monolith. It's calling out to your laptop. You're doing your thing with Telepresence, but you can still call in. So you got that complete chain there going on, which I think is like it's not always always a first glance, but it's like, hang on. We're testing it like the user would see,

37:36 and we're calling into the cluster accessing services that are not running on my machine. When I first saw that, I was like, woah. Yeah. That's pretty cool. Right? Yeah. That is definitely very cool. I mean, that means I could be on the call with a very unhappy client who's telling me to change the colors of something and just actually do a nice thing. That's the inspiration for the demo. I'm telling you, I've been there. Yeah. Especially with remote work. No. Your margin's not right. One more pixel. No. Two more pixel. Yeah. CSS. Right? I I I really should be

38:06 better at CSS. It's one of those things I keep I keep thinking I should be better at and then every time I look at it, I'm like, no. Not for me. Okay. So I'm gonna try not to skip any more stuff here and have you have to correct me. But I think we've done this back here. We've made a code change. We've seen our NPM service restart locally at all the traffic within the cluster is now seen our new value. Very cool. Now we can do a Telepresence leave on this service, which I'm assuming just means that

38:34 the traffic will no longer be routed to my machine. Yes. It's just gonna tear down that intercept that we created and and disconnect the the the the tunnel for that. The overall tunnel will still be up, but the connection for for that intercept will be down. Okay. And now it wants me to do a login and then do an intercept again. Okay. The passing is fun for me. That's a good bit of feedback for us, David, actually on that one. I I think it's just because I switched terminal. I made it more complicated for myself

38:57 Authenticated Intercept & Preview URLs

39:16 rather than anything else. Mhmm. Oh, so we also get a nice UI view as well then from the the cloud interface. Mhmm. Yeah. So Peter was mentioning earlier, we call this our service catalog. So we use annotations. So you just add annotations to your Kubernetes services. If you actually Dave, if you pop that to the cluster, you can do a k or describe service data processing service, and you'll see the annotations with we're using the ahr.i0 standard. Data processing service. Yeah. In addition to all the things you usually see there My inability to type. Mhmm.

39:22 Ambassador Cloud Service Catalog

39:57 I might have got the oh, different context. Of course. Again, me splitting my terminals gets me into touch. If you scroll up a little bit, see there, a atilde.io. Folks can pop along to a tilde.io and see we've got a bunch of sort of standardized annotations. And you can add in, you know, links to Slack, links to GitHub repos. And when you pop back the service catalog, we'll pass those annotations into the metadata you see in the service catalog. Yeah. That's very cool. It's one of those things that you don't really realize is a problem until your team is dealing with dozens

40:36 to hundreds of micro services. One of them is causing problems. You need to be able to oh, there's my dog. You have to be able to reach out to them and work out, oh, well, who do I even need to speak to first? Didn't realize. That's exactly the use case. So, yeah, we've we've, like, we've chatted a lot of customers and they're like, when an instant, you know, page duty fires off 3AM, even being able to see who owns the service and where the repo is is like gold. Yeah? So and and then, you you

40:57 know, you don't have to use master cloud. You can just put the a t r dot I o annotations there and, you know, 80% of the value. But if you want that nice UI onto it and you can drill into the services and explore around there, master cloud gives you that one. The community license free for as many services as you like for the annotations. Nice. Well, looks like one of our audience viewers just ran into some trouble by deleting everything on their cluster. What? Oh, no. Unlucky no. I'm only taking partial blame for you working while

41:28 watching this, but still. Okay. So I like the service catalog and a lot of values there and let's see what's next. So we've done the login, we've seen the service catalog and we're gonna run the intercept again. So what is different from running the intercept as an unauthenticated user versus running it as an authenticated user? Is this where the team functionality comes in? Yes. And so now now once you run this, it's going to prompt you for a lot more information because now because it's running in that kind of collaborative intercept mode, it wants to know, okay,

42:05 we're gonna create this thing called a preview URL, which is gonna show you your application, while using this intercept and only this intercept. So so now this is a specialized view. And so we're not gonna be use we're gonna be using the the very large Java service dot default namespace for this one. And so so this way, right, this preview URL is only going to show what this application looks like while using your intercept, and you can share that with anyone while the main ingress is unaffected. I mean, that sounds good. Okay. So what should I be typing here

42:41 for our ingress IP address? Is that gonna be This is the service that yeah. This is the service that we want to, render when we go to this preview URL. So we wanna see that, the the orange Educorp app, so we're using the very large Java service in the default namespace. Right. Port We're gonna be using 8080, I believe. Should I be looking at the docs and you're just letting me me? It's looking pretty good so far. I'm not you know, I'm always going to remember as well. TLS now. Yeah. Alright. No. I won't ask you anymore. I'll just I'll

43:28 read the documentation like I could say. Okay. So now I think we're just having return here. Right? That's Yep. Okay. We're just using the default. Okay. See, and this is this is interesting because we're intercepting on the data processing service, but we're rendering the very large Java service for our preview. And so it's showing it's showing that connection flow of, like, this is what your application is going to look like from the front even though we've changed one of the middle services further down the stack. Okay. So is this is this stalling because it's it's

44:05 Demonstrating Preview URLs

44:08 now doing the thing? Like, I should just leave that and and move on. Right? Okay. I won't wait for that to finish. I just wanna make sure I know what's going on on this side. So we're not intercepting our NPM one anymore. Does this mean this is gonna be green again? Or are we still intercepting? No. We don't. We left. Right? We got a a Telepresence leave. We left the intercept. So this should revert back to the default view that it was before we did anything. And then once that preview URL is created right? And so so that takes a a little

44:40 bit of time because that's reaching out to the ambassador cloud, and it's creating, that network connection, and it's also creating, the the this DNS for the preview URL. So it takes a little bit of time for all those pieces to to kind of come together. And so here here, we can see that that has popped up now. The second to last line there is our our new preview URL. Hstack.me. Okay. Right. And so now this is rendering that orange view that you created earlier. What? So you're hitting the same front end Java service, but because the preview URL injects a

45:28 header and we pass that header down through, Telepresence is smart enough to say, when the header is present on the preview URL, show me the local stuff, route to the local. And when there's no header present, pass me through. Right. Okay. So we There was a disconnect in my head there. But we ran the same intercept command we did previously. But because were authenticated this time, it's allowing us to have an actual ingress preview environment that does some sort of traffic shaping. So the only I am seeing the orange one. Okay. But if I refresh here,

45:58 we still got the green one. Okay. It clicked. I got there. Nice. Yeah. That's that's really cool. So that's I'm I'm assuming anyone watching this episode can just browse to that URL now and they're gonna see the orange one. That's that's now meant to share with people. They could check it out. They can be give me the thumbs up and go, cool. Merge it. That that's that's us. At the very least, they do have to log in because this is right. This is an authenticated view, so they have to at least log into AmbassadorCloud so that you can see which users clicked

46:29 on this link. Right? So so so that there is there's some it's not just a public, URL where anyone in the world can click it. You have to at least authenticate to Ambassador Cloud. Okay. I mean, I'm I'm gonna test that. But I I do trust you. That's that's all I'm saying. So if I go to it and I say, okay. You have to log in. You gotta be authentic. That's a really cool feature as well. There's lots to love here. That's really cool. Alright. Let's see what's next. What more magic am I getting today?

47:03 So yeah, we've browsed that. We saw the green. We've seen the orange on the preview environment. What's next? So we've got collaborating open sessions and then the FAQs. Cool. What should we what should I click on next? Is it? In fact Yeah. So so so there's definitely, like like, quite a few other features that Telepresence have. Like, Intercept is the the the main the main operating mode of Telepresence. But if you click on, technical reference, I believe, is where the the rest of the options are are located under. Right? And so, one that we've recently we've recently we've recently

47:38 Advanced Features: Docker Intercepts & Environment Variables

47:44 released is the the Docker for Intercepts. Daniel was talking about that earlier, but then there are also other other options here which can which can kind of enhance your local development, experience by using using containers that have volume mounts or, you know, passing down environment variables from your cluster directly into, your locally running services. So there are quite a few different ways in which you can enhance the Intercept experience. Yeah. Okay. We we can run through some of this this technical reference in a second. I I just I'm gonna come back to the demo we've

48:19 just done for a second because it's just dawned on me that this is completely different to every other tool that's trying to solve this challenge. Ambassador has made this a networking problem rather than a fail sync problem. Yeah. One of the things I see with all these dev tools is either they're doing a container about locally pushing it to a registry, pulling it in the cluster, and then doing a port forward, or they're literally syncing the entire file system locally and to something inside of the cluster and trying to handle this way. This seems really different and in a really

48:52 really good way and that you've just went, no, let's work locally and we'll do all the traffic magic and it definitely is traffic magic. There's no doubt. I mean, this isn't real. I think that's really really interesting. I don't know why that hadn't clicked in my head before this session but I don't think anyone else is solving it in this way. And now I understand why we have a Java engineer and a network engineer on our call as we dissect the problem of what Telepresence is doing. It's like this is a networking approach to a challenge that has been

49:21 solved multitude of other ways. But this one just seems to work better in my very limited experience. Super interesting you noticed that, though, because that that's like it's a great inference because Peter and I are big fans of Scaffold. So we use Scaffold quite a lot, which is a Google tool for basically automating the build of containers behind the scenes. So we talked earlier about fidelity. There's some argument that if you're using Scaffold, syncing up either file system or or more correctly, using Scaffold to automate the building of the container and pushing up. So you're coding

49:51 away. You hit build. Scaffold magically pushes your container up behind the scenes. Then what you're testing against in the cluster is exactly what you're gonna deploy or very close to it because it's built in a container. The one thing with Telepresence is you actually are running it typically outside of a container locally. Does that make sense? So that that's like in terms of I've heard a few folks say, oh, fidelity wise, Scaffold gives me that high fidelity. It's like, totally get it, but Telepresence is that gives you a faster dev loop. And then right at the end, you

50:20 can use Scaffold. So Peter and I both can say that. It's it's not an either or. Right? You can use Telepresence super fast dev loop, then you can have Scaffold in the background uploading to to an actual container to give you that super high fidelity. So all these tools plug together, but you are spot on in terms of the file system approach and all the container approach versus the networking approach. Yeah. I think that feedback loop is what's so important here. You know, again, I do a lot of Rust. Like, if I'm working on my Rust application

50:35 Discussion: Telepresence vs Other Dev Tools

50:50 and doing compilations and run locally, I mean, there has some level of hot reloading and getting that really quick feedback loop even without running it in Kubernetes, which is nice. But then because it's a compiled application that runs on a Docker container, you can get it. At the end, I can see why I'd want to say, you just tell it or scaffold or something that's gonna do the build, deploy it, and then make sure that everything still works the way I want it to work. So it's not either or, it's find what works right for you and and leverage it. That's really

51:17 cool. Wow. I mean, I never like networking stuff but today I think it's it's definitely changing for me. I'm starting to appreciate networking a lot more. We have a a question. Sorry. I didn't go up here. Mhmm. Go ahead. I'll say And and, like like, there's a lot of times when you are working on that local service where you just have the external external dependencies where like, most of the time, it's like a database or something where you just need to connect to it, and that's exposed via service. And you just want access to that stuff,

51:46 right, without creating all the network tunnels yourself. And so just doing, a simple Telepresence Connect and then allowing your local service to connect to those things just makes even those processes just so much faster, so much more seamless. Awesome. Okay. We we got a question from Russell in the chat. Is the login for the preview environment a required feature if I'm using my own cluster? What's the situation there? Yeah. That's a that's a good question there. Can we can we answer that? So the ambassador cloud login is a requirement for to do the collaboration features where you

52:03 Discussion: Free Tier and Paid Features

52:23 want to create the preview URL or you want to do selected intercepts, which is which is it it's also a requirement if you wanna use our demo clusters, but for separate reasons. Right? Like, we we we giving a demo cluster, right, we need to at least know who you are and who's receiving it so that we have some level of tracking. And so that's kind of the requirement there. But for the the segregated, traffic, intercepts, those ones, we you also wanna see who where the traffic's going to, who's actually viewing the preview URLs, and it gives it much more organization,

52:56 to understand how that whole process is working. But you can use the default intercept all traffic without having to log in to Ambassador Cloud. And I do know some some users really prefer this when they're just working by themselves early on in the process, and so they're just like, oh, it's just my local cluster, and I'm just wanting to intercept traffic for myself. And then at some point later down the development cycle, then they'll be like, okay. Now I'm ready to start sharing things. And then they can log in and do those intercepts based on header routing.

53:26 Okay. I just wanna make sure I understood that correctly. So if I'm using my own Kubernetes clusters and I wanted to preview environments, I would still need the ambassador cloud account, and my team would have to be there too. Okay. Correct. Yes. Mhmm. If I don't And you go. Sorry. Is it worth actually, if you did a a kubectl get pods all, which would just be easier, we can show you as this one pops up. You actually notice in the data processing service, there's two containers. One of those is a sidecar. It's actually an Envoy proxy doing the routing

54:04 under the hood. And when you log in, we swap the sort of the basic proxy, which routes everything with a smart proxy. So that's kind of the the the actual, like, technical details there. As as you do Telepresence login, that pod that container gets swapped out, and then you can route based on headers and other things. Okay. Can can we just gonna be clear about, like, can can I do all of this stuff with the ambassador cloud login? Am I on Kubernetes cluster for free, or is this where the paying option comes in? Like, where where is the

54:34 line here? I think I'm pretty So is it today? Sorry. Yeah. I think that the line currently is at five managed services for for Telepresence. So so up to that point, it is free. Okay. So people can get started then and start using all of these really cool features early on and playing, kicking the tires. And then once they're as impressed as I am, start giving you a little bit of money back. That that's Right. And you can use the and you can use the intercept all feature all you want. Right? That's because that's unauthenticated,

55:07 and so that's our open source product, and you can use that without any limitations. Mhmm. So everything until you do the Telepresence login, David, like, you know, go nuts. You can, like, do as many things as you like there. But as soon as you do Telepresence login, then, yeah, the five services gets kicks in. Yeah. Yeah. I think that makes sense. You know, if teams wanna be able to do preview environments like that, I think they're solving a real problem there. So if that makes a lot of sense. And it's it's worth noting is that's two problems we

55:31 solve. There's one is the private kind of mode, like, you personal intercepts we call them as in just you carve out your little bit of the cluster because you asked that you're on, David. Can we both be intercepting services, the same service? Mhmm. The answer is yes. And, like, you I could be coding, you'd be coding, and we're not as long as we're not mutating state in the cluster, we're gonna be kind of isolated. Right? But then there's also what Peter was talking about, the shared intercept. So Peter and I could be pairing, typically, as you mentioned in that

55:56 remote context, I can share the preview URL. Peter can see exactly what I'm doing, and we can get that super fast loop going on. So it's kind of the personal intercept versus the shareable intercept as well. Awesome. Okay. So let's cover a couple of more things, then we'll kind of wrap up our session for today. We've got the technical reference here, which you said I should just pop open. What should we take a look at? What what explains more of the magic? I guess what explains the magic right? Like, if you if you click on

56:08 Exploring More Technical Details & Integrations

56:32 DNS resolution, like, I think this is where a lot of the magic happens. Right? And and, right, we're we're resolving a lot of stuff based on on namespaces and what intercept you're using. And if you are now intercepting something in the namespace a, right, like like, gives you access to everything in that namespace without having to to list it list out, specifically the whole, service dot namespace. It allows you to just use those service names. And, right, that gives you much more a much closer, connection to what that, experience is if you actually are in the

57:06 cluster and something is living in that namespace. So the Telepresence list command, does that that just lists all of the Intercepts? That lists all the available, services to Intercept in the the namespace that you're in. And it also it also shows if one of those is already being intercepted, then it'll show, that Intercept's information. Okay. Cool. And you mentioned that the docker intercepts as well? Mhmm. So Yeah. Sorry. I need to go. Yeah. So this is a really cool one. I think Daniel mentioned this earlier. And so essentially, what this does is this this will take a local

57:50 an image that you have locally. And when you start the Intercept, it will start that image as a container locally on your machine and route the traffic directly into that container. So one of the use cases I've done is I I was working on a spree app as a Ruby framework, and the gems were just, like, super old. It was an old version of Ruby. Sure. I could have used r r v m, for example, to, you know, run different versions of Ruby. I could have done some probably clever things with gems. But by just running

58:19 that application in a Docker container, I could do it by gem installs and gem bundles in that container, not pollute my local file system, and then I just routed my service to that container. So it's kind of like, you know, encapsulating the dev environment. And because the the the cool feature with volume mounts, so I can even mount my code into that container. Right? So I can be coding in Versus code on my local machine, mounting the results into the container, getting hot reload because Spree supports hot reload. But that hot reload, I can be hitting

58:51 from my ingress, my actual remote ingress. Okay. That was there's a lot of concepts there. That that that makes sense, David. It does make sense. Yeah. I was just trying to, you know, keep a hold of all the different strings. Yeah. So as was talking, I was thinking there was a lot a lot of concepts there. But essentially, like, particularly for Python or or Ruby, think of RBM, think of virtualenv. You know, the beauty of of doing a build even without Telepresence within a container that folks often do multistage builds Yeah. Is you don't pollute your local machine with all the

59:21 different gem files and so forth or or the Python equivalents. So the the beauty of doing with Telepresence, you just say, hey. Intercept, but don't route it to my local host, whatever. Routed to my Docker container I'm spinning up as part of this command. I mean, it it just gives me so much more questions. Like so everything in the Docker container can speak to my Kubernetes cluster. Yeah. That's it. It's pretty awesome. Right? Because my spree my spree app was calling out to my SQL database running in the cluster. It was calling out to another microservice

59:52 running in the cluster. Yeah. And I was coding Versus code, doing my code, hitting save. How cool is that? Right? I I I mean, even if I tried to understand a little bit of how it was working on my native host, I am really confused at how it even works in a container because it's going through a bridge network. I'm assuming it doesn't matter which Docker network it's on. Does it have to be on the bridge? What if it was on a composed network? Like, does does any of that matter or does it just work?

1:00:20 So Telepresence is actually yeah. Yeah. Telepresence is actually creating the container for you. So Right. So all of those all of those features are or like the networking features and stuff are actually Mhmm. Hidden away from the user. And so so you don't actually have to think about it. Telepresence is just looking for that image that you have locally, and it's going to start it with all the proper network connections. Okay. That helps because I thought you were magically changing something within my containers were already running, and I was like, what? So okay. You you actually orchestrate the container for me. I

1:00:51 just have to tell you that. Okay. At this point, can we shout out Thomas, Luke, Donnie, the amazing engineers that do the work at the source project? Lots of folks contribute. They're fantastic. But, like, in particular, some of the networking stuff, like, you know, wow. It's amazing that the team would do. So, yeah, Thomas, Luke, Donnie, massive hat tip. Yeah. I'm gonna have to read some more networking books. Is there anything else we should cover before we finish up for today? Is there anything that we haven't talked about showing off? Anything you wanna make sure people are familiar with?

1:01:22 The one final thing I was gonna mention, Peter, is the environment variables. I know you and I use that quite a bit. So definitely worth, like some folks have been using that 12 factor style, and you bake things into your environment variables. So we can export them to a file, either a m file format or a JSON file format. So when I'm using IntelliJ, there's a m dash file plug in. So I can export all my environment variables from the remote cluster, the the pod I'm running in, to a file and load that file into IntelliJ so that when

1:01:51 my app spins up and it looks for the m's, it will find them. You because the plug in joins together the the file I've exported. So we find the the two ones that the two things that people often migrate to pretty quick in the IntelliJ presence journey is the environment variables and the volume mounts. I hadn't thought of that. And now that you do, it seems silly that it didn't yeah. Like, course, we want to build one container image to run-in all of our environments. We use a multitude of environment variables to configure where the databases are, where the services are.

1:02:22 Some people go by convention, but I think it's more common just to have an environment fail. So we can actually expose those from the remote pod to our local environment too. Exactly. David, yeah, both like, I've got a walk through on IntelliJ, and Peter's got a walk through for Versus code. So whatever you're using, and we can and if you're using just a shell, we can do that as well. So that's super useful being able to export your environment variables locally. Alright. I guess I'll I'll throw one more thing out, and and then, Peter, if you

1:02:48 have anything, we can tackle that too. But I see our back here, and I'm scared to click on it, but also curious to click on it. Go for it. Is this gonna mean does this mean that if my pod has access to a service account in my cluster, we're gonna make that work locally, or am I as my guess, widely inaccurate? This RBAC is actually when you do the Telepresence Connect, remember, it's going to create that traffic manager for you if it doesn't exist. So there are some levels of permission that Telepresence is expecting. And so, like, for especially for larger teams,

1:03:20 some some developers don't exactly have full admin rights to the cluster to create those namespaces, create the traffic manager. So you have to pre deploy, the Telepresence infrastructure, and this kind of walks you through what is the bare minimum RBAC procedure that you would need in order to use Telepresence. Okay. Perfect. Yeah. That that makes a lot of sense. Is there anything that you wanna look at before we finish up here? Is there anything we've missed? I I I think we I think we've covered pretty much everything. I think this is a a good walkthrough.

1:03:53 Well, I think One thing I just sort of snuck into the docs, I think it's brand new, Peter. I think you and I are talking to Casey about it. Is Telepresence and Linkerd? I I think that's that's that's hot off the presses, folks, seeing that. So we have a lot of requests of folks using Telepresence with Linkerd and Istio and Console. And Nick Jackson from HashiCorp very did a very kind demo for us in our ambassador fest a couple of weeks ago. I know Casey on the team is working on the Linkerd integration, and Istio is supported as well

1:04:17 even with MTLS. So the doc's coming soon. So half the presses. Just thought of that as you were navigating, David. Awesome. Very, very cool as well. There's just I mean, I'll be honest, it's rare that I'm borderline speechless with some of these demos. And I gotta say, there's just there's that it really has a lot to love about the way that this just enables me. That kind of hands off approach to how I wanna develop my application. Like, you're not enforcing me to adopt any real standards or tools. You're just saying work how you normally work using Node, Ruby,

1:04:30 Summary & Closing Remarks

1:04:49 Python, whatever. We'll handle the traffic a bit and then things just work. And I think that kind of hands off approach just will resonate with a lot of people. And I think that if you're not checking out Telepresence yet, people should. And this is almost turned into a shell which I feel really bad about. But again, it's rare that I am that impressed with the tool on the show. Thank you for Appreciate it. Just coming on and sharing that with us. It's very very cool. No. Thank you. Is there anything Yeah. Thanks for having us.

1:05:14 Is there anything you wanna share before we finish up, or will I just cut you off now? Like, what do you want? We'll do a shameless plug for, like, Peter does amazing onboarding sessions, office hours as well. So pop along to Get Ambassador website. Join us on our Slack. You can reach out to both of us. We're both of us there. Cindy's does amazing work managing the community as well. So we love to connect with folks. We love to hear gnarly problems because as you hinted at, David, the networking stuff is far from simple. Right? So Peter's often

1:05:40 debugging these kind of things. Get involved. We're spinning up a summer of Kubernetes, some training or some resources of folks that wanna learn if they're brand new to Kubernetes. So pop along to Slack, and we'll be giving some more information on that in a I think next week, of this week next week. So we look we basically love just chatting. We really appreciate the invite there. We just love connecting with folks. But half the thing with Kubernetes is just figuring out all the tools out there. Right? So many awesome tools that we, you know, we'd love you

1:06:08 to look at our tools, but that equally scaffold other tools out there that help out. We're happy to share our thoughts on those as well. Yeah. There are so many tools in the cloud native landscape and to the point I'll never run out of episodes to be able to play and experiment with them. Alright. Well, again, thank you so much for joining me today. It's been an absolute pleasure taking a look at Telepresence. I'm really excited to try it out and play with it on my own time. I'm sure if I have any problems, she'll

1:06:32 be more than happy to help me, I hope. If anyone else, reach out to people on Twitter, leave questions in the comments. I will do my best to forward them on to Peter and Daniel as required. Thank you again. Have a wonderful day, and I will speak to you both soon. Thanks. Thanks, everyone. Cool. Thanks, David. Thanks, David.