If I take extensions, it has also the client object, which was cloned in between, you can
also use this to perform some redevelopations like get.
There is also a fetch, which allows you to establish a reference, which is very typical
in multiple customary sources, defining your essentially ecosystem, where you have to reference
some config maps, secret or other resource.
This fetch command is for fetching resources immediately, without any additional logic.
Takeout.
So for controller at the time, there is to use as well.
We have type system, which allows us to define this sort of commonly known list and object
type, pod list and pod object.
They come in from core.
So one of the benefits of go-long obviously have import switch.
Automatically found by your project and you compile go-long, it suggests you the import
for the object you want to use.
As currently pretty good working in this regard, you can get, for example, what is this core
we want object for, automatically submitted for you, which is a great benefit in comparison
to what have been in the past, because controller at the time is built on client
go-frame work, and you have essentially a DSL language to build the path to the object
and construct it in terms of what you want to pass to the client.
Unfortunately nothing like this is in e-system cumbers, but what is happening there?
It's built upon the K8S open app, which uses open API, generation code.
For each grand scale is all the core libraries, generating all the types with the same path
essentially of the import, which you can use later like this pod object displayed in the
initial example, that's the open API, generation code.
So it's pretty good.
Now coming to error handling, you want to go structured path or structured path.
Controllers, there are some things which you want to define, for example, if you want to
return one type of error or another type of error, very well we can write this error
framework allows you to derive those things automatically, and yeah you can just map the error
if you don't know this or you can have this from stands, which automatically says to you
what type of error it expects so you can just question mark this out.
And you have the log message as well, included this, which is a big benefit in comparison
to go on when you have to always return an error, log something out, do something, this
heavy path or unheaded path deviations can be described by this specific structure and
works pretty well with the applications, but you can go even simpler.
We can define any how and just say we want to document some things in this error scenario
and imagine that we have some results, which has also this log message, we have tracing.
We can define this error type, I don't think it's actually very well visible here, but
at the end of this mark us.
This allows you whenever you have an error code from this method, I'll put this to the
log message through the log pipeline with this instrument command, which is very powerful
allows you to focus on the code and this results in a very condensed, reaching logic code,
which only focuses on things you want to do.
So I believe in my personal opinion code written and asked this way is much more readable than
goal and when you have thousands of lines of code in multiple occasions, but performance,
obviously we need to touch this topic, I'm not expert, I'm guessing there are things in my
spare time for fun, so I like Chrome, I like atomic reference counts, things which damage
the performance obviously, but it's difficult to get a drunk essentially.
The RAS type system forces you to build things the right way, bro checker is hard to avoid,
which by the way is one of the problems which is often talked in this cast in RAS comparisons,
it's not much of a problem for those type of resources because we work for those structures,
we essentially write a state machine, we can work from one structure to another structure,
moving the data out, so the object never really happens to be a problem in this scenario,
in my spare time, I never tried to write big, normal stuff like for example, write something like
class data, in RAS that's going to be definitely a difficult topic, but for small projects,
CLI tools, I find nothing better than a cube or so at this point.
Contour runtime, yeah it's very well optimized if you know what you're doing, advanced configurations
are available, they have to be basically, you have to go through a code to understand this,
there's no documentation for that unfortunate, but if you match the right, it works
similar, if not better, for some examples, but I mean nothing is perfect,
one of the things which is missing in my opinion is cache implementation,
or at least the one which we used in controller runtime, by default, as I said,
controller runtime diri's client go and extends this implementation and they use
certain forms cache, so each client request which you issue essentially goes through the
cache date first, which is related and populated during the time of the, like, lifetime of the controller,
so you don't really issue that money request to the API server, unlike with cube RAS, when it comes
to multiple client interactions, they always go to API server, which might be a problem, but might
not because, you know, in the latest API server discussions, they're trying to implement
server sidecaching, and if you don't worry about network overhead, then you can still
benefit on the cache in a case detail, this thing, but controller runtime, yeah, cache,
have optimized scenarios, multiple things are available there, but it's difficult to configure this
right, if you don't go, like, beyond click start, you probably won't notice this,
but anything more than that requires lots of things you have to tinker out, and cube RAS actually
is very well built for not doing this in my applications, compiler will help you out to build your controller,
so there's an example of a simple click start controller, which watches my custom resource,
and sets ownership on the pods, expects them to be set to own the pod resource,
and then reconcile some things on the change of this pod resource with ownership references,
same thing in cube RAS, API for pod custom resource, and you get the old standards, everything is
very similar, as you can see, there's also a consummate, which is immediately bound to the
resource itself, so it knows what type you're working with, the difference in cube RAS that cache
is only present in this scenario, so when you open a new controller, API, you have a cache, which is
like, watch list in some scenarios, but definitely something which is populated by the open
watches, and the resource you're using this, my customers are in this account cell, it's actually
coming from cache, so if you don't want to do anything complex, just map something to some
other stores or sensory guests, this is pretty performance as well as doesn't have any overhead
when it doesn't work, it can work with us, as such, it can source us in another time,
which is tricky, not many people use it, but sometimes you want to do this, which is much easier
to do in cube RAS, because you have generic object, and all those resources I'm talking about,
they inherit the resource trade, so you have things like name, the space of the object,
the rest of the selection labels, as literators, as lists, annotations, nothing like this existing
controller runtime, and you cannot really expand on this, expecting this to be some sort of standard
at this point, because people don't do this unfortunately, while here you have all the
opportunities to build your trade extensions, expanded rates on this specific definition,
not sure if I have enough time, but coming to essential generation of CRDs, I'm going to
talk about how it was used in one of the CLI tools I wrote, CRD generation, you see, you can
create your own customers' source, very easy to do with controller runtime, but this goes through
a cube build ring it, if you want to write something like this, on your own, be prepared for
most board-tinker and issues with this approach, unknown dependencies, pulling the customized
things, it's very difficult to get a trade for the first try if you don't use this click start,
and if you deviate from this, prepare for always matching those annotations, which have
absolutely no documentation whatsoever, but it works, what has the cameras for this
is macro-markerses, one of those macerses is customer source, everything you see here is
compiled and checked, you won't make a mistake that will lead to something compiled incorrectly
and does not work in your production code, once you've compiled, you have a CRD and that is what
you see here, so there's some expected string types, food and bar, there's a customer resource,
spec and status, it's equivalent to the previous slide if you want to compare,
all option types results in essentially pointer types, so it's not supposed to be there,
and you can define some sort of rows on that and also set over it's on top, which allows you to
rename those fields to the way you like, so it's typical in scenarios like this to have
a live canal case, names of those variables, same thing is actually over here, but the
fastest method is to be under a score case, so you can inherit the sources,
so as I talked about the three definitions, some resource, you can inherit some sort of
basis or from the core library or anything you draw from other sources like customer
subsidy defined on your own, for example in here we have a config map imported and I'm using
this config map as a source for this more structured type I want to use, so when I call the API
get on this CA config map, if it's not the one I spell to see with the specific units, it'll
air out in the server and you'll see this error, so it's very easy to, like exclude this non-heavy path
scenarios, you can actually avoid having problems with Kubernetes and you know, last new type path
this way, if you want to use some external API, you can actually derive from external API,
define only two to three fields like spec status from there and then you have your own type,
you can build native monetations upon etc, it's very easy to use and I have an example of the project
which is automatically synchronizing the cluster API definitions from the CRDs, okay, so
you are of time, we need to get to the next. Yeah, anyway, feel free to go through the slides,
they're quite interesting things, thank you very much.