0:02 Yo, it's your boy back in the place to be. Livestreaming, bringing the heat. Can't you see? Got something special, something brand new, a guest and a project just for you. Give it up for Avital, a mastermind dropping knowledge, the future you'll find. He's brought Cipher Netties. It's the name changing the game. Ain't nothing the same. Kubernetes complex and deep, but Cypher query secrets they keep. Unlock the power, simplify the task. Avital's here, answers to ask. So grab your headphones, get ready to vibe this live stream's fire. We're taking your lives. Tech talking insights flowing like a stream. Let's dive in deep to

0:45 Cypher Netty's dream. Yo, it's your boy back in the place to be. Livestreaming, bringing the heat. Can't you see? Got something special, something brand new, a guest and a project just for you. Give it up for Avi To, a mastermind dropping knowledge, the future you'll find. He's brought Cipher Netty. It's the name changing the game ain't nothing the same. Kubernetes complex and deep, but Cypher query secrets they keep. Unlock the power, simplify the task. Avital's here, answer to ask. Go grab your headphones, get ready to vibe. So grab your headphones, get ready to vibe. This livestream's

1:56 fire. We're taking you live. Tech talking insights flowing like a stream. Let's dive in deep. The Syphonetti's dream. To the Rawkode Academy. I'm your host, David Flanagan, also known across the Internet as Rawkode. And this is an episode of Rawkode Live where we take a look at some of the coolest and most interesting Kubernetes and cloud native adjacent projects we can find. And today is no exception. We're taking a look at a new way to work with Kubernetes and query Kubernetes using a new Cypher based language. So let's meet. Sorry. There's something in my ear there. Let's

2:58 jump over and meet our guest for today. Hello, Avital. How's it going, man? Hey, David. How are you? Thanks for being good, man. This was of the coolest things I heard in a while. Yeah. I mean, I'm always absolutely astounded at just how good AI music generation has gotten these days and being able to put together, you know, just a couple of minutes of personalization to thank the guests for coming on. You know? It's it's just so nice. And Even pronounce my name right. You know? Well, I I more than yeah. That took a lot

3:29 of work. Like, you have to go out and change. I couldn't just write Avital. I had to phonetically do it. But same with Cypher Netties and Kubernetes. I'm getting quite good at just predicting how to get it to say the right thing though. But, yeah. Four e's. Yeah. Yeah. But it's it's a pleasure to have you join us today, and we're gonna be taking a look at a project called Cypher Netties that enables a new way to interact with Kubernetes clusters. I could not be more excited to take a look and show people how this all works. However,

3:58 let's meet you first. Could you please take a moment to introduce yourself and tell the audience who you are? Yeah. So my name is Avital. I've been doing this for a while. I started working with computers when I was a young kid. I taught myself programming when I was six. I got my first computer and taught myself BASIC. I think there was BASIC installed on the MS DOS. And so I've pretty much been doing that since. When I was 20, I actually made it big with my high school band. So I had a semi successful career as a professional

4:34 musician during my twenties and, kind of from there, I kind of shifted towards, doing a career in the industry, mostly revolving around infrastructure. I did some stuff with backend, front end work, some full stack, but ultimately gravitated toward infra, since container technology and Kubernetes started becoming a thing, found myself really drawn into it. And so this has been like the focus of my career for the past ten years or so. Awesome. Thank you for sharing. I mean, I'm now really curious about what type of music you were playing in your band and what instrument you played, you know? Well, my my

5:15 I got my face tattooed, so you can probably guess that he was on the heavier side of things. Hey. Always a pleasure to have a fellow metalhead on things, know, because I could set and place some soil work at the start of all these episodes. That'd be a very happy man, but I don't think the audience would appreciate it too much. So conversation for KubeCon, perhaps. Maybe we can do that over a beer. However Sounds good. Today, we're keeping things geeky, techy, and Kubernetes. That is a terrible I'm never saying that again. There we go. Said that.

5:47 Could you tell us I wanna get into the history of CipherNetties, but let's just start with what is it? Right. So, so Cypher Netties is what it sounds like. It's Cypher for Kubernetes and Cypher, for those of you who don't know what Cypher is, is the language from Neo4j, which is one of the, I guess, pioneering graph databases that put graph technology in the center. And Cypher evolved over time into the GQL standard, which is like being a franc of graph databases now, but Cypher, the originals flavor of Cypher was the first graph oriented query language that I came across.

6:34 And I remember this first interaction with Neo4j and what Cypher does really cool is that you use ASCII art, I guess, to draw these patterns using parentheses and arrows, and you draw these patterns that you want to match on a graph and get back or act on, like do these CRUD operations on instances in the graph that match the pattern, the ASCII pattern that you drew. This immediately, like I fell in love with it immediately because it turns all these joins like joins that you express in SQL are just expressed by a little arrow in Cypher.

7:21 And it was, to me, it was, you know, it was whimsical and like creative and fun, even just one of those things that brings a lot of fun into computing, you know? And as I got more and more into doing infra work, it always kept nagging me that Cypher would be such a great language for infrastructure because a lot of what we do when we communicate with each other and we're doing design sessions on whiteboards is drawing like node graphs, right? We're drawing these circles that connect to each other to express our ideas. And I always had like carried this notion

7:58 in my head that Cypher would be a really great language for infrastructure from like going from whiteboard to code kind of. So over time I had, like five years ago, I had this initial attempt to do something with this, which was, I called it OpsLang and it was like a language that would compile down to Terraform or Vulumi and would, would let you express like infrastructure stuff using Cypher. But that was, I guess not, not that well directed or the idea in my head wasn't, you know, complete yet. But then five years later I revisited,

8:45 you know, we were, I was leading the DevOps team in Lemonade and we were dealing with this cluster that was having this, you know, it was a big dev cluster of 300 something nodes, ingress controllers were going wild and we had a theory and why this was happening. But just to prove our theory, it took, like this, I guess 10 line, 10 lines of bash code piped and parsed and, you know, nest UCTL commands and just to prove that this is what was going on. And then we had to actually to, to implement this as a solution. We

9:25 had to write API code and we had to like implement an operator. And it's, you know, it nagged me at that time that I could express this one thing with this whole thing could be expressed with one line of Cypher. Like if I had Cypher for Kubernetes, I could do this with, with just one line, you know. And that's when I started to actually build Cypher Netties initially as just a tool that I could use to, to show that this was the actual problem. Right? So just doing the read parts, not even full CRUD, but just be able to be

10:05 able to do like match this pattern and return something. Match any deployment that is exposed by a service that has an ingress routing into it where some of these conditions, you know, match and just return all of these. So where the deployment has zero replicas, just return all of these. So the ability to do this on a large cluster with a single command that would also take rate limiting into account. Right? Because API server would like, this is an example where kubectl would fail because there's rate limiting and stuff. So, and also being able to compose this

10:54 ad hoc response with only very specific fields from different resource kinds together. So this was the thing I started working on a year and a half ago, almost a year and a half ago. This is what it started out from just being able to do match this pattern and return these elements and these fields. And then I found it so useful and it very quickly became an important tool in my belt, you know, that I was using daily. So I just kept extending it. And first I added a match set to be able to update

11:32 like patch resources and then came delete and then create. And then I started improving the language and adding more and more language features, adding aggregation functions. Yeah. And it's like in continuous motion ever since, you know, every, every time somebody and, well, first it was just me, but then all of a sudden a community started forming around this. I think somewhere around last September, it took me a year, I think, to go from zero GitHub stars to 50. And then in twenty four hours, it went from 50 to a hundred and then twenty four hours more, it was 100 to 200

12:12 and then it built up to 500. And then in forty eight hours more, suddenly I was on the front page of hacker news and forty eight hours more, went from 500 to a thousand. And now I'm all of a sudden I'm counting and I'm counting my stars in hundreds, you know, and not in singles anymore. It's yeah. So, so a small community started to form around this, which is, which is crazy to me because I kind of thought this was super niche and I was going to develop in the public and put it out there anyway. But

12:46 I thought if I find 10 people in the world who are Cypher fans who work with Kubernetes a lot, it would be cool. You know, we could have a small community and yeah, all of a sudden I have users from all over the world, people working in large environments, large clusters, which is where my problems were, you know, and I find that these exact kind of users find, you know, they get they get the value from this tool and it's it's just incredible. Yeah. There's there's a lot to unpack there, but you're completely right. I'll say first, you're like a thousand stars

13:23 away from VC funding. Right? So you just gotta keep that hockey stick growth going. But I think using Cypher and, you know, a graph based query language is such a clever move. Right? I spend a lot of my time running kubectl commands. And because we have so many disparate resources that are interconnected, but, you know, not like a real graph, you end up running one command here, getting an output, run another command. At some point, you start writing bash scripts. I'm now at the stage where I've got TypeScript scripts, TypeScript scripts, where I'm, you know, hitting the Kube control

13:53 API server, parsing some JSON, running it through a function, and it's a lot of work. And the reason it's a lot of work is because it's just not the right approach. And then the minute I seen Cypher Netties, I was like, oh, you know, I've just been looking at the problem the wrong way. When you flip it on its head and actually use a language that is built to do this kind of graph traversal Yes. Things start to click. And that was, like, the the moment I was just like, okay. Right. We need to we need to

14:18 show people this project. So I was very excited. Yeah. Thank you. Yeah. I think you you you hit the spot. Like, this is the exact problem that this is solving and yeah. So thanks for thank you so much for appreciating and inviting me to be on the show. Okay. Cool. Well, I mean, I don't need to ask you what the name means. I think that's pretty self explanatory. But I do think maybe we should, you know, share a screen. Yep. Do some examples, give people an idea of how to get started, and then hopefully we can explore some of those more difficult

14:51 use cases. I'm definitely curious to see what you have been doing with CypherNet is beyond what I think I would end up doing with CypherNet. Yeah. Yeah. Definitely. Pushes over here. Now we see your terminal. Yeah. Just take it away, and I'll throw loads of questions at you as we go. Sounds good. Okay. So let's just fire it up. And so Cypher NetEase, the CLI actually contains a few applications, but I'll start from the one that I, that I started from, which is a Cypher NetEase shell. It's just an interactive shell that lets you write,

15:29 evaluate Cypher queries or Cypher Native queries, right, in your terminal. And so this is the very minimal example, right, of doing a match return statement is I would match, and then I would draw this pattern, right. This, graph node, node graph pattern, and inside each node would be a variable name. D, and let's say a Kubernetes kind in Cypher, this is called the label, but Cypher Niddies, we use labels to denote resource kinds, right? So match all deployments that are exposed by services and then return, the number of replicas in each deployment and the cluster IP of each service. Right.

16:30 And then this would return a list of all deployments and replicas. Right? And their respective services and cluster IPs. And I could refine this query further by adding a where clause and say where the spec replicas is large, let's say larger than two, greater than two. And then I would only get back billing service where I have three rep, And this thing right here, this little arrow is, is where all the magic happens, right? This is the magic of CypherDesk. It's understanding the connections between resource kinds and this chain of, so we're not limited to only two resource

17:26 kinds. Of course we could match, that's for example, config maps, all the config maps that are being used by pods, that belong in a replica sets that belong in a deployment, you know, and just, return the data from this config map and the P let's say the phase of the pod and the name of the replica sets and a number of replicas and the deployment. Right. And I would get this, all the data, you know, from four different resource kinds, aggregated in one custom payload. Yeah. Before you take anything else. Mhmm. We we we need to take a

18:18 moment. Right? Because if there's anyone that's watching that hasn't already sold on Cybernetics, what the fuck is wrong with you? Right? Because this is like, it's the devil is in the details here. There was just so much that I think we need we're gonna have to go over some of this. Right? But Yep. The autocomplete, I I wasn't expecting that. That was wonderful. The relationship inference is very cool. We could talk about how you're doing that. I'm very curious. But the thing that caught my eye right from the very, very start is that when you

18:45 kicked off the CypherNet shell, it actually analyzed the schema of the cluster to build these types. Right? And when you scroll up, there was just two log lines that stood out as really, really awesome. Now my first question was gonna be I'm assuming the answer is a yes. Right? But you're not just working with the core v one APIs. I'm assuming it works with CRDs within the cluster. It would work with your CRDs, no problem, and it can even add custom relationships. So the relationship engine, yeah, that was, this is something that's always in continuous right?

19:16 In the beginning, everything was hard coded. I just had a list of, resources or rules between two kinds and each rule needs to contain one or more criterions for the, for the resources to match. So for example, a rule between, replica sets and deployments would be of course the owner reference, from the metadata of the, replica set needs to match the metadata name on field on the deployment. And so that's one rule between replica sets and deployments. And I just had, like, I guess a hundred or so hard coded rules. For the first year or so, I want

20:08 to say of Cypher Native's development, this entire relationship engine was just, hard coded. Same goes for auto completion, like resource specs. I just asked an AI to generate a bulk of, you know, just a huge list of, for each resource guide in the core resources and in the V1 groups, you know, just list as many adjacent paths as possible for each one. And for a long time it was hard coded. And I think it was around last September that I kind of realized, okay, this is becoming a serious thing. And people already started to ask,

20:50 you know, in the community and passing, well, not really passing criticism, but asking me, how did you do this? And I would say, yeah, this is hard coded right now. And eventually I'll get to do this. And, so once more people started actually, not just using it but having their eyes on the code, you know, when I realized, okay, people are actually looking at this, better save my reputation and do something serious here. So I started doing this thing where, where, when you connect to the, when you launch Cypher Natives either into the shell or the web client, which we'll

21:30 look into in a bit, then it downloads the open API schema from the, from the cluster. It generates all the auto completion, specs for all the resource kinds that the service supports and no more hard coded auto completion anymore. And then it starts scanning. Well, it does a few things. So a few of the, of those relationships are still hard coded. This is, you know, this is always a work in progress. I like to say this is, yeah, right. This is continuous, but something, I think the most dramatic thing that I did that I started doing there was just

22:12 looking up after I generated this list for auto completion, right. I started going through field names and then wherever I see a field that ends with either ref or key ref or name, then I would look behind that, you know, key ref or ref or name. I would look at the word behind that. And I would look in the, in the GVR cache that I built from the open API spec. If there's an actual resource kind that matches this name. And if there is, then I would just create this relationship. So you could, you can add a CRD

22:50 that has a field called deployment name and Cypher Natives would automatically detect the relationship between deployments and your, in your CRD. Yeah. I mean, like I said, the devil's in the details here because in Kubernetes land, there's no concept of relationships whatsoever. It's all very loose definition. I mean Yeah. So so again, to me, this was if I go back to that moment where I was looking at all the API code that we wrote and the operator that we were implementing, and I thought to myself, this needs to be internal. Like Kubernetes needs to expose,

23:28 like to hold a graph model internally and just have this language available to us. Like I shouldn't be writing these 800 lines or 2,000 lines of operator code that everybody's writing. It's always the same code. Like the actual business logic inside most of these custom Kubernetes controllers, especially the ones handling, only handling internal resources, it's not much. Like most of the code is what everybody else is writing, all the SKU builder gen controller stuff. So to me, this was like a moment where I figured I'm going to build the system that can take these one liners, like these

24:07 Cypher one liners and just run them continuously like an operator or even listen to events. And yeah, so this is, this was where I came up with the idea for actually building a mini operator framework around this. Yeah. Are we back? Hey. Hey. I'm not sure if I'm out or if David is. Let me stop my screen share. We'll see. Hey. Well, I guess David is out, but I might as well continue demoing this. So let me show off a few cool other examples for stuff I use, cipher nettings on the daily with, which is not,

25:57 only match return. Like let's, let's look at how this goes beyond the, just doing read operations. So, let's say I wanted to look at all pods. Am I back? Yeah. You are. Wanna be sure if you're Sorry. Yeah. My Wi Fi decided that it's done for the day, and I'm now tethering. So thank you for I I don't know. Maybe you sang a song or you've just been showing off your No. Would kill something. Yeah. I realized you dropped, and then I figured, yeah, let's let's carry this thing. But you joined right when I did. So,

26:39 okay. All right. So, so maybe I'll show, I'll show something beyond the, like match return stuff. So for example, this is something very common, right? That I see people doing on the daily where, and this is the example, actually the first example I have on my readme, right. Which is something a lot of people do, which is like to match all pods where the, where the status, phase of the pod isn't running, right. And then delete the pod, right. Faulty service. I had one, I had one let's, I could show match all pods and return the piece

27:23 status, phase. Right. And I can see, I have all these pods. This is running, this one's running and faulty services. Well, it's, it's pending right now. Right. So if I run this query, right. It'll just delete the one or, or yeah. Or if I ask it to, only match the ones that are running right. And set their, say metadata, annotations foo equals bar. Right? And, what did I do wrong here? So rejected due to an error in my request. Oh, Well, this isn't, this isn't nice, but, I'll give another example. So let's match, all deployments

28:22 where the spec, replicas replicas is higher than two, return the metadata name, right? It's billing service. So let's ask it to set the spec replicas to, I don't know, one or four, and it will patch billing service. And then if I ask it to, return, the number of replicas again, I can see that patched up to four because, Similarly, yeah, similarly, I could ask it to, you know, use a, use a complex pattern here, like, like I showed before with four or five or however many resource kinds where with one or more conditions in the where clause

29:22 and yeah, it'll just know how to patch all of them. Yeah, it's such a powerful model. Limits of what you could do with this are pretty cool. I I like where it goes, and it just simplifies a lot of those tedious kubectl commands and piping through j q and all this other stuff. Right? This this is just a really elegant way of working with it. And, again, it's because you've approached it without looking at the existing query methods and just came at it from a different angle, which I think works really well. And did you, during my absence, handle the

29:54 question from Alejandro? I did not. Did not. I did not realize it was So Alejandro is curious if he can use this from Go. So I guess Yeah. Maybe you could share some information on and as as CypherKnight is written in Go, can people use it as a library? What are they used? Definitely. So this, I think is a good is maybe a good segue for like my vision for this generally. Right? Or the why I'm doing this, writing this shell. We'll look in a minute, we'll look at the web client and the operator framework that I built

30:27 around cybernetics. So my idea for this is that this is a really great language and I just want this to be a language for Kubernetes that's available to any project out there. The latest release that we did for Cypher NetEase v15, which was released just last week was very much around this, around the effort of separating the language, like creating a clean interface between the language and the actual Kubernetes provider. So, when you, integrate this into Go, you can use, so Syphonetics includes this package, called core and a provider called API server, which is a provider for running Kubernetes queries

31:18 against the API server of your cluster. And you can just include this package. And if your existing project is already a Kubernetes project and you just want to, include Cypher Netties, support, then you can bring your own Kubernetes client into Cypher Netties and they'll use that. You can also, just have the Cypher Natives core package spun up its own, set of like Kubernetes dynamic client and, and, and, discovery clients. But additionally, like, as I said, the interface is very clean, like cleanly separates the language from actually Kubernetes. So even products that don't use Kubernetes, like ones for big, larger observability

32:08 product that use, I know, like reflect etcd into Postgres or elastic search or something like that. Then you can also implement a new provider on top of our API server provider and just change the GET requests, for example, to read them from Postgres or Elasticsearch or your custom backend. Right. And all of these, applications that I built, the operator framework, the shell, the web, I see them as proof of concept, right? That the language has merit because almost everybody that I show them this, ask me something like, oh, so how can I use this for alerts? Right? How can

32:50 I create metrics with this? Oh, this would be great for showing me best practices. Like where do I have misconfigurations and stuff? So I think all of these are great applicable ideas for cipher natives. And I just want the the language to be out there, for other go projects to be able to integrate and build awesome stuff around. Yeah. I mean, I think once you have, I'm assuming I know. I've I've tried not to make assumptions on behalf of other people. Right? For me personally, I can see myself coming up with a whole bunch of health

33:23 checks and safety queries that I wanna run regularly against my cluster that do identify anomalies. Now, of course, I've got monitoring and other stuff. Right? But those are read only and so require manual intervention or other tooling. What I like about the Cypher NetEase approach is that I can actually build down some rather well, I mean, you can start off with primitive reconciliation where required, you know, opt in the replicas if you need to, if things are getting too slow. But also I could I see a situation where I have a runbook, like a Jupyter

33:51 Notebook that runs a various of these queries and provides like a single pane of glass into the cluster for people that, you know, just aren't that clear of Kubernetes. Like, you know, one of That would be incredible. Knowledge as much as possible. Right? Because, again, we can't expect everyone on the team to be able to drop one into a terminal, run 50 queries just to say, is my cluster healthy? And, again, I know people are screaming at me going, well, have Grafana and have all these tools and spend money here and then do all that. That.

34:16 Sometimes you just need to get into the weeds of things. And I think there's a time and a place. And I do have monitoring, but sometimes I think I know better than the monitoring, which is maybe a little bit of a hubris. However, does I think what you're everything you said there is perfect as well. It's like, you know, you proved the method in the language, and I think the bounds of what you could build on top of this and tools and interfaces, user interface, all of this is really exciting, and I can't wait to see some more.

34:42 Before we take a look at operators and and web stuff, like, what else does the CLI do? What else is available to people? Is it just a shell or is there something else? So the shell is also it also includes a web client and you can actually also deploy the operator, but that's more for testing and dev work. The operator also exists on artifact hub, of course. But, so the shell, Cypher, Kubernetes, it has the shell application that we just saw. You can also run single queries. So like Cypher Natives query something. I can just take this into Bash scripts.

35:26 Yeah. Yeah. Exactly. For CI, manage p pod, return p. Right? Can those queries be chained? Like, if I do a match, find all pods, and I wanna chain those results to another query, is that something we can do with Cypher? So not yet. Well, with actual Cypher, yes. With Cypher Nitties, not yet. This is definitely on the roadmap, but, but not yet. And yeah, so besides shell and query, which is what I started off with, you know, and I was developing the shell, adding auto completion, coloring, all of this, at one point, you know, I added,

36:09 a friend told me what, well, why won't this draw graphs? Right. And I thought about it and I kind of like in my mind, went over it and I said, yeah, I mean, I do collect all this info and I have the relationship info. I can just create a list of nodes and graphs and just draw it. So I started out by adding this option in the, in the shell first, you know, it was, so this disabled graph output, it's true by default, but if you, just run the backslash G it'll start, drawing graphs for everything to match. So let's

36:45 do this one again. So match the configured maps into pods, into record sets, into deployments and just return all of this and it'll, Oh no. So I have, I have an issue here. I'm going to have to fix this afterwards. I'm sorry about that, but let's, but let's actually look at this in the web, right? Let's look at this in the web client. So, it'll send me into a local host 8080, And then let's, let's see what do I have here. Oh, yeah. I have I have pretty much the same query here in in history. So is

37:17 that the query history from the interactive shell as well? Is it Not from the shell. This one actually stays in local storage in the browser, but just so happens that I have the same query because I was demoing, before. So this is an example I like to give, right? So, you can see that it's, it gives us a nice little graph representation of, of the deployment that goes into the replica sets and going, goes into the pod and the, config map and just hovering over one would, would narrow down the results that we see on the, on the lessons. I mean, looks

37:50 familiar. This is the actual Neo4j interface. So I was paying tribute, you know, I was paying tribute to the, to the, program that got me hooked on Cypher, you know, this is, so let's see, imagine deployments and services and return DS and, here are all the deployments and services. And let's say, I want to also see the, the pods and replica sets, right. The P yeah. And just get all of these back and this lets me kinda, you know, focus and narrow down the results here. And I added little options of view underneath as Jason or YAML and filter

38:37 out the managed fields that usually nobody wants to look at and a bunch of other options that kind of made this my new daily driver. I want to say I was doing this more kind of for PR reasons because I thought it looked sexy and, you know, I'll put the video out there and which it did, you know, it brought, definitely brought more attention to Cypher Nadees, but I actually found myself using this more than the interactive shell and just starting to use the web interface, which is pretty cool. So, so much so that I didn't notice

39:12 that the graph functionality broke in the shell. Like it did just now in the demo. So I'm gonna run and fix that right after our session. Okay. Nice. So what about a situation where it's unable to determine a relationship? Is it possible with the query language to say that these are related on these fields with this discriminator of some way like? Yes. Yes. Yes. So this is, this was something that the community was asking for and I just ended, I just added at one point you can see here that it says I added, it found 79

39:55 internal relationship and one custom. So the custom relationships you can put in your, dot cipher Nidhi's, relationships. And if we look at that, that would be a way to describe a relationship between, for example, pods and deployments. Right. So a deployment owns a pod if, and this is the criteria and it only has a single criterion. If the field metadata name of the pod contains the metadata name of the deployment. So just a demo, you know, pretty, you know, optimistic relationship that I added just for, you know, testing purposes or demo purposes right now. But let's

40:47 assume a deployment owns a pod, right? If the, if the name of the pod contains the name of the deployment, right? So if it's a user's service is the name of the deployment, then it makes sense that user service, 7477 something is related to that. So if I'll just launch back into the show and match, the deployments that are connected to pods and return the spec replicas again and the p status status phase. Yeah. So I get all of these. Okay. I'm gonna I don't wanna put you on a spot, so if this is too

41:37 tricky, we can follow-up later on this. Right? But let's do a match query and find all service accounts. Let's start query that'll find all service accounts. Alright. So let's say s a find all service accounts. Right? Return as a, whatever. Yeah. Meditator. Name. All right. Yeah. The name name is by the way, is always returned by default, you know, like a special name field, but yeah, we can do this and it'll return the name twice. So this is the only service account I have right here. It's default one. Okay. So can we now request the pods

42:14 that are using this service account? Let's see. Let's see. I'm gonna assume the inference doesn't detect us. I was wondering if we could do it manually. And then there's the hard mode as well. We we can try. We can try. Let's see. So status phase. Oh, it actually detected that all of these are using the the default. And this is not something I hard code service accounts into pods. Definitely not. So probably pod has a service account name on it. Yes. So just because it ends with the word name, then it looked up what's behind name, what

42:50 came before name and it was service account and it realized, oh, there is a GVR, you know, called service accounts. So that matches service accounts. So I would create the connection between these two. And yeah, it just worked. Let's let's try the hard mode question because now I'm I'm feeling a bit more confident that this might work. Alright. Alright. Let's find service It surprised me too. You know? Let's find service accounts and rule rule bindings. Let's see. So service accounts We may have to do this in the cube system namespace. Let's see. Let's do that. Let's do that. Let's

43:26 go to cube system and match all, service accounts that connect into a role bindings. Yeah. Role binding metadata name. Yours whole thing. Resource. It's scan. So yeah. No. No. Relationship not found. Yeah. It didn't detect the relationship between those two. Yeah. So we could probably write a custom relationship to do that. And but let's let's skip a step because I I I want us to do a couple of, oh, I don't know, like, maybe talk about the operator before we finish. Right? But Okay. What I actually want you to do is stay okay. There's been a service accounts that have some

44:10 sort of role bindings, and then really what I wanted to do is filter them on the role bindings where they have certain permissions. So let's just do the query of role binders to see if we can find one that has permission to create pods. Mhmm. Yeah. I'm not I'm not sure if I have one in this cluster, but let's see. So That's why I said go to cube system. So I'm assuming we'll be able to work with system masters. Mhmm. Mhmm. Let's let's first look at what this returns. Right? So, well, we have a few role bindings. Right?

44:41 Let's Oh, you'll need to get the role of that. Mhmm. So if you can then build the relationship to the role or cluster role. I don't know. Maybe that won't exist either, but we can try. Let's see. Yeah. So this works out of the box. Row bindings into roles works. Yeah. Mhmm. Okay. So can we see the whole rule object? Yeah. You just return r. Yeah. Yeah. There we go. So now we've got access to the rules where we could create on verbs create pods. So rules, verbs Our secrets secrets watch. Let's just keep it simple for now. Right?

45:31 Mhmm. So is that something we can query? So we're looking for any role that has or any role of a role binding that has the ability to execute secrets watch. So where role Roles. Let's say, Rules. Rules. Sorry. Rules. Yeah. Any. Right? Verbs. And we're looking for contains watch. Yeah. Contains watch. This is so cool. It was expecting a number in an array index and it got a star. It's supposed to take a star as well. I'll check why this didn't work, but, yeah, if I just change it to zero, then, yeah, it detects lot of these.

46:23 That is very, very interesting. I mean, these are some of the more difficult queries that I run against my clusters on a regular basis, which is, you know, trying to understand the security posture, who has access, who has over permissions. And, again, I do know there are tools I can go pay for for this than some open source tools, but sometimes I just like to run some queries. Like, this I can't believe how many this is like 80 characters at most, and I'm getting a lot of information back. To me, that is just that is wonderful.

46:51 I mean, I could not be happy to. Yeah. This is what turned it very quickly into a daily driver for me. You know, even just the most simple stuff you can think of just changing a value in a, in a Helm chart, right. And then applying this chart. And then I want to see the three different resources that it changed and effect that it had on specific fields, you know, just, just doing this day to day, very basic stuff, turn Cypher Nitties into a daily driver. Like I can't do without this on the, on the day for me, and I'm definitely

47:25 gonna fix the star not working here. We try it just with the open close squares. Would that work? So just remove the zero? No. No, no. It's a, it's supposed to take a, yeah, this is expected number and actually I'm, yeah. So this is a regression because I remember taking stars as well, but never mind though. We'll we'll get this working. There's gonna be a patch by the end of the day for this. That will take stars as well. Alright. Edward Hart, I've already popped a comment on the screen, but he's really loving the look

47:56 of this. And hi, Alejandro is asking, is this like having a sequel there on top of Kubernetes? I mean, yeah. It is So there's there's prior work, you know, there's, there's been other projects that did this with SQL, but while SQL, I think is a great choice for a query language because everybody knows SQL and almost nobody in the world knows Cypher. Well, most people from the data realm, right, they know Cypher, but not so much, not so many people in operations and DevOps. But I think SQL, fundamentally for doing this kind of stuff, just having

48:41 to write joins, you know, it's, to me it felt so off. I, I, it didn't even, you know, cross my mind. It was, I need Cypher for Kubernetes. This was a, like a given for me. So I did of course look into all the projects that tried to do this before me and all of them used SQL. And I think Cypher is just a better choice for this, you know, because I think this little arrow, being able to do this, you know, this is so powerful. There's so much that that's happening behind these two characters.

49:16 That to me feels like magic, you know? Yeah. Again, it's the user experience and the ergonomics, right? You're working with graph data, you need a language that can understand and take away some of the imperative nature. SQL with all these joins and extra things like that, it is not pleasant for this time of structured data. So Yes. You know, I think it's inside it's just an absolute brilliant project. I mean, I'm gonna say this is the coolest Kubernetes project I have seen this year. And by this year, mean, in last ten days. Not the last ten days, the last

49:48 twelve months. This is the coolest thing. I'm humbled. Thank you so much for taking that. Alright. You wanna take a look at the operator real quick? So this is going back, going back to the problem that started it all. Right. I told you before I was heading the, DevOps, the infrastructure division in Lemonade, and we had this big dev cluster, 300 something nodes, right? And these are all dev environments. So every night the cluster kind of goes to sleep, right? And the way we, because devs don't work at night and the way we put it to sleep is we scale

50:20 down all the deployments. And then over time we started noticing the ingress controller growing wild because the, let me boot up the shell and because, if you looked at the deployments and services that they connect to and exposed by ingresses, right, return the spec replicas and return the S cluster AP and the I spec ingress class name, right? So, yeah, if you looked at these over time NGINX Ingress started to grow bonkers because what we realized or what we were theorizing, right, was that there were missing endpoints because some of these people were not bringing their environments back online,

51:19 right? Either because they left the company or they don't need the environment anymore, or they went on vacation and so on and so forth. Right. But we kept on having a growing number of deployments that actually had zero replicas. And that caused the validation webhooks of NGINX ingress to crash over time in a larger cluster. You know, the more missing end points it had, the more CPU it was burning every time it was doing config reloads. And then our ingresses started failing altogether. Right. So my thought was we, all we need to do is find

51:57 all these deployments that have zero replicas, right? Like match. So do this thing right where these spec replicas equals zero. And then instead of returning something set, spec ingress class name to inactive, right. Or something just make, have the ingress control or not select. Right. And then, and then do the, and then on the flip side, change it to active if it has more than zero revenue. Right. So that was the initial idea that where I thought I could express this whole thing in one line of Cypher. It was this, right? So after almost a year of developing Cypher

52:48 Niddies and doing the shell and the shell started to feel kind of mature, that's where I said, okay, now I'm going to build a mini operator framework around this. And so in my mind, I wish right. That Kubernetes hold held this internally and to express decision making like this in Kubernetes, we can, we can express it with one line. Like ideally in my mind, Kubernetes would have this custom resource where I can tell it, or this is at least how I imagined it. Let's go to a project Cyphernes operator. I have a nice little sample here.

53:34 So dynamic operator, ingress activator, right? Where on update, right? It watches deployments. This is a concept I kind of invented for this, which is like a continuous query or I called it a dynamic operator. Right? So this is a way to spawn these many dynamic operators on the fly and just tell them, Hey, watch all the deployments in the default namespace. And when there's an update match the deployment with this name, right. That connects to a service connects to an ingress where the spec replicas is zero would change the ingress class name to inactive. If it, and then run another query

54:24 where if it's larger than zero, change it to active. So just run these two queries whenever, against a certain deployment, whenever this deployment changes. Right. So let's look at this in action. If I go to, helm, rights and let's do helm install, install this, install it into the, into the cluster. Let me open up the siphonase shell here. Siphonase shell. And let's look again at these, right? So I have public API with one replica and the ingress class name is active here, right? So let me apply from the, from that same, or let's look at it before. Oh, we

55:28 just did actually. So let me apply this dynamic operator, right? So apply, test. If you go dash f. Oh, yeah. Yeah. Dash f. Test. Oh, yeah. Apply test E2E samples and apply this, dynamic operator Ingress activator dynamic operator, right? So this is now applied to the cluster. The Cypher Nades operator, just detected it and it's, it created this dynamic operator, right? It set up the watcher for deployments and whenever a deployment changes, it's just going to run these two queries. So, again, if I look at this, this is public API with, right. And then let's take this and say,

56:25 set the spec replicas, change this to zero. Right. So it patched it. And now if I do the lookup again, I can see that the dynamic operator changed it to inactive and back again, set it to something else, one or two, whatever, and match it again, it'll set it to active. Nice. Very, very cool. Yeah. So this was one year after I started working on it and it finally solved the problem that, you know, that sparked the idea initially. That's very, very cool. I like that dynamic operator thing. I mean, that looks back to what I was saying earlier. I'd love to

57:09 be able to run things on a cadence and do some debugging and health checking, and it's already exists with the operator. So now we just need to build the Jupyter Notebook kernel and we'll be we'll be happy. So That sounds incredible. It sounds incredible. I I would love that. Something that popped into my head is that, you know, we've been running match statements against a single namespace. We've seen how to switch namespace. Can we query the entire cluster? Yes, definitely can. In the shell, if I do, namespace all, it'll go into this like namespaces mode and then yeah, we can, we can

57:42 match namespaces, which have a special relationship with, with the rest of the, so that's returned the name of all the namespaces and the P metadata name. And, we can see all the names, all the different namespaces and the parts that belong in them. And we can do the same thing for nodes and yeah. More, even more than that, switch back to default, even more than that, it supports multi context queries. I can do something like in, so I have two contexts here, right? Kind, kind and kind, kind prods. So match all the deployments into replica sets into pods

58:29 in both of these contexts. Right. And so it'll tell me that in kind kind prod, I have auth service with one replica and the kind kind prod P is, you know, it's just this, and this is the replica sets that I have in Kankind prod. And this is from this context. From Kankind, it has D. So it even does like multi namespace, multi cluster, what have you. Honestly, I feel like just flipping my table and storming off because it should not be this cool. I mean That's awesome. Again, I mean, I just can't imagine people watching

59:10 this and not finding this really exciting for change in the way they interact with Kubernetes clusters. So is there anything else you want to show us before we jump back and ask a few more questions? No. I think this is about it. Yeah. That's it. I just showed you these, like, four amazing things, but, you know, until next time. So let let's focus on you people on this now. It's a very good point from what I can see? Right? Like, I don't see a reason why people can't start using and adopting this today. What do you see for the

59:41 future of Kubernetes? Where are you going? What's on the roadmap? Yeah. So, two parallel lines is, first of all, there's a community building up around this thing and people are asking for features. People want to see, want to have a way to query metrics, right. And set up alerts around this. So I'm starting to think like, what would the language around this would look like? You know, watch something for return CPU. We didn't even look into actually in the demo now we didn't even look into aggregation functions. And, so you're able to aggregate, CPU usage and memory usage and a bunch

1:00:22 of really cool stuff that this already does. And I want to be able to, give away to the users because this is highly requested in community to query these metrics over time and then do this decision making like we saw in the operator based off. So kind of like setting up alerts or setting up, you know, different processes that happen, using metrics. That's one thing. And I want to keep extending the language with more Cypher features. So something that this doesn't yet do and I really wanted to do is to be able to also use

1:00:59 patterns, use ASCII art patterns inside where statements and inside the lead statements. So, match, all the config maps where not config map connects to pod, return this config map name. So return all the names of config maps that are not being used by any, by any pod. Right. So, this is, an extension of the language, which would bring it, you know, more on par with Cypher, that I'm going to be diving into in the near or medium future, I guess. But more long term, like I said in the beginning, my vision for this is not

1:01:42 to have a VC backed product that I'm building around this. I want this to be, standardized and I want this language to be available ideally, you know, and I know how much politics is involved, but ideally just, you know, internally held by Kubernetes and because I don't see this as replacing anything, right? I see this as an extension to like a missing tool because this is how I experienced it. It's a missing tool for seasoned Kubernetes professionals who've been doing this for a long time. They know the anatomy of their resources. They know, yeah. And they just need a, like they,

1:02:23 they end up writing all these long shell, like write once read, never, you know, shell, one liners that pipe and parse hell. I call this, you know, nested cube control commands. And ideally this is what I want for this, you know, to just be available and to be standardized and to become like another tool that's available to us because I really feel like it's a missing, and I don't think I'm the first one who feels like it's a missing tool because there's so much prior art of projects that tried to like create a SQL based query language for Kubernetes.

1:03:04 But I think this has a lot of merit and it'll work for a lot of people. And I actually think it's worth picking up the new syntax because it puts so much power in your hands and and it's actually enjoyable too, you know. So far, everything you've shown us has shown how to take Cypher Netties and look inwards with the cluster. Are there any plans to then broaden the scope of that? I'm thinking send web hooks and Slack notifications. Like, has there been any thoughts there? Like, it, or is this fresh? So there's been some thoughts around this. I'm still not sure

1:03:45 yet how this is going to work out. Because again, I want my fork, my focus to be more and more around, language feature development and less around, you know, developing applications for this. But yeah, I would love like Cypher has this really cool notation for using plugins, using ampersand where you can tell it to just like ampersand something, it'll shoot out an external Java function. And I think something like this would be really cool, you know, so that if you have a, like maybe a plugin system where if you have this plugin installed, where your Cypher Net is,

1:04:23 binary is or whatever, then you can also ask it to like, query some metrics over time and return an ampersand Slack something, you know, they'll send a Slack message or what have you. So I have, I have some ideas, you know, brewing around this. It's not yet, you know, per se on the road map, but, yeah, it's definitely definitely on my mind. Awesome. I mean, that was the the one thing I thought would be really cool to build on top of this. And I think a plug in system would be a good way to do it, especially if there's, like, a

1:04:57 web assembly runtime in the cluster where we can give it access to some components like HTTP requests or whatever. Then at that point, you're just seeing, you know, build whatever you want, and it saves you that middle step of, you know, I I I could imagine if I were to try and do something like this tomorrow, I would probably just write have create a a job. Right? And just spend it off run once to shut back down. But we could cut out that middle point with a plug in system. So I think that would be a very interesting and exciting

1:05:23 approach. But other than that, I mean, I've just gotta say I'm really impressed. I think this is a fantastic language. I hope people, again, are as passionate and interested in it as I am just from sixty minutes of your time. I'm like, wow. Like, this is even cooler than I thought it was coming into the session. And I was already excited, so this is awesome. Thank you so much for your time. Any Thank you. Final words before we wrap this up for today? Go check out CyberKnities. Our community is growing and we're always listening to our users. You know, this is top

1:05:54 of mind always, you know, open an issue, tell us what you want to see Cypher Natives doing next and it'll be the first thing we'll jump on. You know, it's the most important thing for us is listening to how people are actually using it and then just, you know, following along. Awesome. Well, if you are in London for KubeCon in a couple of months time, the beers are on me and Hopefully. Look back in your brain. Looking forward. Thank thank you all for watching. Thank you for joining me, and we'll catch you all next time. Have a good day.

1:06:44 Hit subscribe so you won't miss a beat. More livestream tutorials can't be beat. Keep coding, keep learning. It's the Rawkode way. We'll catch you next time. Have an awesome day. Hit subscribe time. Have an awesome day.