WEBVTT 00:00.000 --> 00:10.480 If I take extensions, it has also the client object, which was cloned in between, you can 00:10.480 --> 00:13.440 also use this to perform some redevelopations like get. 00:13.440 --> 00:18.800 There is also a fetch, which allows you to establish a reference, which is very typical 00:18.800 --> 00:26.240 in multiple customary sources, defining your essentially ecosystem, where you have to reference 00:26.240 --> 00:30.560 some config maps, secret or other resource. 00:30.560 --> 00:36.640 This fetch command is for fetching resources immediately, without any additional logic. 00:36.640 --> 00:39.200 Takeout. 00:39.200 --> 00:42.600 So for controller at the time, there is to use as well. 00:42.600 --> 00:51.640 We have type system, which allows us to define this sort of commonly known list and object 00:51.640 --> 00:54.240 type, pod list and pod object. 00:54.240 --> 00:55.800 They come in from core. 00:55.800 --> 01:00.280 So one of the benefits of go-long obviously have import switch. 01:00.280 --> 01:08.040 Automatically found by your project and you compile go-long, it suggests you the import 01:08.040 --> 01:09.760 for the object you want to use. 01:09.760 --> 01:15.280 As currently pretty good working in this regard, you can get, for example, what is this core 01:15.280 --> 01:20.360 we want object for, automatically submitted for you, which is a great benefit in comparison 01:20.360 --> 01:24.440 to what have been in the past, because controller at the time is built on client 01:24.440 --> 01:30.120 go-frame work, and you have essentially a DSL language to build the path to the object 01:30.120 --> 01:35.720 and construct it in terms of what you want to pass to the client. 01:35.720 --> 01:41.680 Unfortunately nothing like this is in e-system cumbers, but what is happening there? 01:41.680 --> 01:47.960 It's built upon the K8S open app, which uses open API, generation code. 01:47.960 --> 01:55.120 For each grand scale is all the core libraries, generating all the types with the same path 01:55.120 --> 02:02.840 essentially of the import, which you can use later like this pod object displayed in the 02:02.840 --> 02:07.680 initial example, that's the open API, generation code. 02:07.680 --> 02:10.600 So it's pretty good. 02:10.600 --> 02:16.000 Now coming to error handling, you want to go structured path or structured path. 02:16.000 --> 02:22.480 Controllers, there are some things which you want to define, for example, if you want to 02:22.480 --> 02:26.840 return one type of error or another type of error, very well we can write this error 02:26.840 --> 02:34.840 framework allows you to derive those things automatically, and yeah you can just map the error 02:34.840 --> 02:43.480 if you don't know this or you can have this from stands, which automatically says to you 02:43.480 --> 02:47.960 what type of error it expects so you can just question mark this out. 02:47.960 --> 02:53.800 And you have the log message as well, included this, which is a big benefit in comparison 02:53.800 --> 02:58.440 to go on when you have to always return an error, log something out, do something, this 02:58.440 --> 03:04.520 heavy path or unheaded path deviations can be described by this specific structure and 03:04.520 --> 03:08.920 works pretty well with the applications, but you can go even simpler. 03:08.920 --> 03:16.840 We can define any how and just say we want to document some things in this error scenario 03:16.840 --> 03:22.160 and imagine that we have some results, which has also this log message, we have tracing. 03:22.160 --> 03:27.880 We can define this error type, I don't think it's actually very well visible here, but 03:27.880 --> 03:31.680 at the end of this mark us. 03:31.680 --> 03:36.560 This allows you whenever you have an error code from this method, I'll put this to the 03:36.560 --> 03:42.880 log message through the log pipeline with this instrument command, which is very powerful 03:42.880 --> 03:49.040 allows you to focus on the code and this results in a very condensed, reaching logic code, 03:49.040 --> 03:51.840 which only focuses on things you want to do. 03:51.840 --> 03:58.120 So I believe in my personal opinion code written and asked this way is much more readable than 03:58.200 --> 04:05.880 goal and when you have thousands of lines of code in multiple occasions, but performance, 04:05.880 --> 04:12.200 obviously we need to touch this topic, I'm not expert, I'm guessing there are things in my 04:12.200 --> 04:19.800 spare time for fun, so I like Chrome, I like atomic reference counts, things which damage 04:19.880 --> 04:27.320 the performance obviously, but it's difficult to get a drunk essentially. 04:27.320 --> 04:35.320 The RAS type system forces you to build things the right way, bro checker is hard to avoid, 04:35.320 --> 04:44.200 which by the way is one of the problems which is often talked in this cast in RAS comparisons, 04:44.280 --> 04:49.480 it's not much of a problem for those type of resources because we work for those structures, 04:49.480 --> 04:53.560 we essentially write a state machine, we can work from one structure to another structure, 04:53.560 --> 05:00.840 moving the data out, so the object never really happens to be a problem in this scenario, 05:02.120 --> 05:09.080 in my spare time, I never tried to write big, normal stuff like for example, write something like 05:09.080 --> 05:14.440 class data, in RAS that's going to be definitely a difficult topic, but for small projects, 05:14.440 --> 05:18.840 CLI tools, I find nothing better than a cube or so at this point. 05:21.160 --> 05:26.680 Contour runtime, yeah it's very well optimized if you know what you're doing, advanced configurations 05:26.680 --> 05:32.760 are available, they have to be basically, you have to go through a code to understand this, 05:32.760 --> 05:38.680 there's no documentation for that unfortunate, but if you match the right, it works 05:38.760 --> 05:45.720 similar, if not better, for some examples, but I mean nothing is perfect, 05:47.080 --> 05:52.440 one of the things which is missing in my opinion is cache implementation, 05:52.440 --> 05:57.800 or at least the one which we used in controller runtime, by default, as I said, 05:57.800 --> 06:04.040 controller runtime diri's client go and extends this implementation and they use 06:04.040 --> 06:11.640 certain forms cache, so each client request which you issue essentially goes through the 06:12.440 --> 06:20.360 cache date first, which is related and populated during the time of the, like, lifetime of the controller, 06:20.360 --> 06:26.360 so you don't really issue that money request to the API server, unlike with cube RAS, when it comes 06:26.360 --> 06:32.840 to multiple client interactions, they always go to API server, which might be a problem, but might 06:32.920 --> 06:38.040 not because, you know, in the latest API server discussions, they're trying to implement 06:38.040 --> 06:45.080 server sidecaching, and if you don't worry about network overhead, then you can still 06:45.080 --> 06:51.800 benefit on the cache in a case detail, this thing, but controller runtime, yeah, cache, 06:51.800 --> 07:00.040 have optimized scenarios, multiple things are available there, but it's difficult to configure this 07:00.360 --> 07:04.120 right, if you don't go, like, beyond click start, you probably won't notice this, 07:04.120 --> 07:09.720 but anything more than that requires lots of things you have to tinker out, and cube RAS actually 07:09.720 --> 07:18.680 is very well built for not doing this in my applications, compiler will help you out to build your controller, 07:18.680 --> 07:23.160 so there's an example of a simple click start controller, which watches my custom resource, 07:23.800 --> 07:28.760 and sets ownership on the pods, expects them to be set to own the pod resource, 07:30.360 --> 07:34.440 and then reconcile some things on the change of this pod resource with ownership references, 07:35.480 --> 07:43.640 same thing in cube RAS, API for pod custom resource, and you get the old standards, everything is 07:44.360 --> 07:50.600 very similar, as you can see, there's also a consummate, which is immediately bound to the 07:50.600 --> 07:55.720 resource itself, so it knows what type you're working with, the difference in cube RAS that cache 07:55.720 --> 08:02.200 is only present in this scenario, so when you open a new controller, API, you have a cache, which is 08:02.200 --> 08:09.080 like, watch list in some scenarios, but definitely something which is populated by the open 08:09.080 --> 08:13.800 watches, and the resource you're using this, my customers are in this account cell, it's actually 08:13.960 --> 08:19.000 coming from cache, so if you don't want to do anything complex, just map something to some 08:19.000 --> 08:24.600 other stores or sensory guests, this is pretty performance as well as doesn't have any overhead 08:24.600 --> 08:30.280 when it doesn't work, it can work with us, as such, it can source us in another time, 08:30.840 --> 08:37.320 which is tricky, not many people use it, but sometimes you want to do this, which is much easier 08:37.320 --> 08:42.760 to do in cube RAS, because you have generic object, and all those resources I'm talking about, 08:42.840 --> 08:50.920 they inherit the resource trade, so you have things like name, the space of the object, 08:50.920 --> 08:58.040 the rest of the selection labels, as literators, as lists, annotations, nothing like this existing 08:58.040 --> 09:03.880 controller runtime, and you cannot really expand on this, expecting this to be some sort of standard 09:03.880 --> 09:08.760 at this point, because people don't do this unfortunately, while here you have all the 09:08.760 --> 09:14.200 opportunities to build your trade extensions, expanded rates on this specific definition, 09:15.800 --> 09:22.040 not sure if I have enough time, but coming to essential generation of CRDs, I'm going to 09:22.040 --> 09:28.600 talk about how it was used in one of the CLI tools I wrote, CRD generation, you see, you can 09:28.600 --> 09:33.800 create your own customers' source, very easy to do with controller runtime, but this goes through 09:33.800 --> 09:38.440 a cube build ring it, if you want to write something like this, on your own, be prepared for 09:38.440 --> 09:44.440 most board-tinker and issues with this approach, unknown dependencies, pulling the customized 09:44.440 --> 09:49.080 things, it's very difficult to get a trade for the first try if you don't use this click start, 09:49.080 --> 09:53.640 and if you deviate from this, prepare for always matching those annotations, which have 09:53.640 --> 10:01.160 absolutely no documentation whatsoever, but it works, what has the cameras for this 10:02.120 --> 10:08.280 is macro-markerses, one of those macerses is customer source, everything you see here is 10:08.280 --> 10:13.960 compiled and checked, you won't make a mistake that will lead to something compiled incorrectly 10:13.960 --> 10:20.280 and does not work in your production code, once you've compiled, you have a CRD and that is what 10:20.280 --> 10:27.800 you see here, so there's some expected string types, food and bar, there's a customer resource, 10:27.800 --> 10:31.400 spec and status, it's equivalent to the previous slide if you want to compare, 10:32.840 --> 10:37.640 all option types results in essentially pointer types, so it's not supposed to be there, 10:38.200 --> 10:44.200 and you can define some sort of rows on that and also set over it's on top, which allows you to 10:46.120 --> 10:51.800 rename those fields to the way you like, so it's typical in scenarios like this to have 10:52.760 --> 10:58.600 a live canal case, names of those variables, same thing is actually over here, but the 10:58.600 --> 11:07.320 fastest method is to be under a score case, so you can inherit the sources, 11:08.120 --> 11:12.600 so as I talked about the three definitions, some resource, you can inherit some sort of 11:13.320 --> 11:18.360 basis or from the core library or anything you draw from other sources like customer 11:18.360 --> 11:23.240 subsidy defined on your own, for example in here we have a config map imported and I'm using 11:23.240 --> 11:28.760 this config map as a source for this more structured type I want to use, so when I call the API 11:28.760 --> 11:35.880 get on this CA config map, if it's not the one I spell to see with the specific units, it'll 11:35.880 --> 11:43.480 air out in the server and you'll see this error, so it's very easy to, like exclude this non-heavy path 11:43.480 --> 11:53.400 scenarios, you can actually avoid having problems with Kubernetes and you know, last new type path 11:53.400 --> 11:59.080 this way, if you want to use some external API, you can actually derive from external API, 11:59.080 --> 12:04.120 define only two to three fields like spec status from there and then you have your own type, 12:04.120 --> 12:11.720 you can build native monetations upon etc, it's very easy to use and I have an example of the project 12:11.800 --> 12:18.440 which is automatically synchronizing the cluster API definitions from the CRDs, okay, so 12:18.440 --> 12:24.120 you are of time, we need to get to the next. Yeah, anyway, feel free to go through the slides, 12:24.120 --> 12:28.120 they're quite interesting things, thank you very much.