 Hello and welcome to the talk today. We'll be talking about Clanggo, so how many of you have you heard about Clanggo? Cool. And how many actually use it? Okay, impressive. So at the time of submitting this talk, because the title to get the bad and the ugly, I was very frustrated with Clanggo, so I've come to terms with it a bit better, but at the time we were trying to extend some things that really didn't work then, so yeah. But I will try to end on a positive note and try to hopefully do some constructive criticism rather than bashing it. So my name is Lily. I'm a developer at Kinfolk and why am I qualified to talk about Clanggo? It's basically because I worked on a few personal projects that heavily included Clanggo, as well as the Habitat Operator, which I do at work with Chef, and basically that heavily relies on it. So as I mentioned, I work at Kinfolk. We have a boot, so do come and see us and talk to us. We're basically a consultancy based in Berlin. So let's start a bit about the good. I hope the gifts are turning out okay. Sorry for it's very heavy, so I apologize for that. So yeah, let's start a bit about what Clanggo is. Some of you might not know. It's basically a library used to communicate with the Kubernetes cluster and includes a collection of different clients. It basically is an upstream Kubernetes repo. It has 563 stars, which is the most important metric, and there's responsibility for it is the API machinery, and they're really nice, so do go over to their Slack channel, Kubernetes, if you have any questions about that. So some of the use cases, it's mainly used in operators, as you might have heard of them. They're basically controllers in Kubernetes, and they're used to extend the Kubernetes API. So something like, as I mentioned before, the Habitat operator, the Prometheus operator, the Puzzgress one from Zalindu, and also Flannel uses it, which is a network solution for containers, but it doesn't actually extend the API, but it integrates with it. And also, Kubernetes indirectly uses Clanggo as well. So let's first set up a client. So basically we will try to communicate with the Kubernetes API. So here we see we only need a few lines of code to actually get all the functionality and all the power from it. So first, we get the config, and we do that by building it from flags. And if the flags are not present, it defaults to ncluster. So we can pass in the master URL, which I'm not even sure if anyone does use that anymore. And you can pass in the kube config path. And after you get the config, you just pass it into the new for config, which basically returns the client set from where you can actually communicate with the cluster. So as I mentioned before, there are two ways to do that. You can run it outside of the cluster. So basically that is if you're developing for it, or if you have some special use cases for it. And that basically you just pass in your path to the kube config, and everything works fine. And you can also customize the master URL. Has anyone done that? No. So I guess no one uses it. And inside of the cluster, basically what it does is it doesn't use any paths or anything, but it sets up everything for you. So it uses the service account. And the token is used to enable the communication in the Kubernetes cluster. And it's in that path in your container, in your pod. And it also configures the TLS certificates, according to your Kubernetes cluster's default. So once you actually have the client set, this is how easy it is to actually communicate. So this is used to list the deployments. And all you need to do is just access through the client set, the deployments resource. And you just list all the resources in the default namespace here. You can pass in some different parameters, like the field selectors or labels. So what actually happens behind the scene is that the list we saw earlier in the previous slide, that is basically just this, it's basically just an abstraction or helper to communicate, to talk to the Kubernetes cluster. So basically it's just to get requests, nothing more than that. There's no magic behind it. So yeah, this is all it is. It just makes your life much easier, so you don't have to actually reimplement everything yourself. It's quite powerful. So how actually client go goes about doing all of this. It's basically out of generated from Kubernetes itself. And it does that by using the Kubernetes, under the Kubernetes repo, the staging area. And it's published by a bot. And these are the repositories that are generated. And then you can see client go is one of them. And we'll see some of the other ones a bit later. So I mentioned earlier that the Kubernetes client go uses indirectly Kubernetes. The Kubernetes uses client go indirectly. And basically in reality it's all just a sim link and the vendor directory. As you can see here, all of these, the API server, the client go, they're all just sim links to the same staging area in their vendor directory. So it doesn't import in a way that we vendor if we use it from a developer point of view. So from a consumer point of view. So as I mentioned earlier, we'll have a look a bit. So the most one you use besides client go is API machinery. And it heavily relies on client go heavily relies on it and vice versa. So that is basically just it's shared dependencies for servers and clients to work with the Kubernetes API without actually using the direct type dependencies basically. And the consumers are Kubernetes itself, client go and also the API server. And now let's discuss a bit about the bad part or I like to call it frequent points of friction because I think like all of these things had a reason why they were done this way. And some of the maintainers are here and I don't want them to be angry at me. So yeah. So this is mainly when you first come across client go and when you first use it, these are the, I've noticed a couple of people had the same pain points. So in general, lots of people agree that it does a bit too much. So meaning that you end up importing the whole world when you just want to communicate with the Kubernetes API. So we'll see that in a second. And things that it does are a bit disconnected. So meaning that you have a lot of client go packages. And this is how it looks. So this is the minimal example we have that we have in our vendor directory. And this is how much packages we import just from client go, for example. So yeah, it's impressive, isn't it? And some of these packages, like I mentioned before, they do quite various things. So for example, you have things from you communicate, which is the purpose, right? But they're not that much related at first glance. So you have the work queue, which is just a queue implementation. That's in the package util work queue, then you have the tools cache, which is for writing controllers. So it's not really how you would expect from the client library. But once you get used to it, you understand. Another friction or another bad thing is the API versions. So this is a question one of my coworkers had, when he first started with it, is that you can get quite confused by what the different, what is alpha one version one, beta one, stable, and what are all these versions like this is not client goes fault as such, but you do have to actually use that. So basically, it comes down from Kubernetes, but you're still ending up with the different confusing names and different versions. So I'll try to explain a bit about the different versions. So there are the four types. So the first one is the development one. And it's not something many people actually come across because it's not actually committed or available in the releases. It's basically just for testing out new features and up and coming features and doing proof of concept. Then the next one, which I'm sure some of you have seen is the alpha level one, but it is in the release. But it's not actually being you have to enable it in your cluster to be able to actually consume it. And then there's the beta, which I'm sure most of you familiar like the deployments, etc. Sterling beta in the 1.8. And the difference between the next one, which is the stable one in the beta is that beta is actually recommended for short live testing clusters, so that you can actually test things thoroughly before they actually go into stable and improve things until they are. So like mentioned, there's the stable version, which is for example, version one, and that's enabled by default. And all users and it's considered stable. So this is the API changes in the 1.9 Kubernetes version. So as you see, there's not that many documentation. And I think that's where people find this very confusing. There's not that many documentation on which resource is in which version, in which Kubernetes or client go version. So that's one of the points where documentation would be very helpful. But it's really hard to do. So for example, one of the things that's surprising to lots of people is that the deployments are still in beta. And they have been so for, I think, since three minor versions. But in 1.9, they're going to actually graduate to this table. So that's good. But one of the problems with that is that you actually have to then update, but we'll come back to that. So the next one, the next chapter is the ugly or things that are not so nice. So basically the main problem that lots of people have who work on developer tools, and from a developer point of view, so let's say operators with different kind of controllers that you use, is that the Kubernetes releases happen every three months, right? And you have to then upgrade because there are things like auto updating clusters and everyone wants the latest release of and for the tool to work, right? But so for the 1.8 release, there was a bit of a delay with kind go. So that didn't quite work out very smoothly. So yeah. So actually updating your project, your project would only work as well for some versions. So as we've seen earlier, the current deployments are going to be in 1.9 stable. But if you want your cluster to work for 1.6 and 1.9, it's not really going to work that well. So that's one of the pain points. So RBAC is in beta, but you have to actually adapt things because only for, it's only supported for two versions, two consecutive versions, the API changes. So that's one of the pain points because when you have to actually upgrade your developer tools, you have to be very quick as three months is not that much before client go actually gets released before you can catch up and test everything. So that's one of the main pain points everyone has, I noticed. So and one of the other things is this matrix. So this is basically how the client go is compatible with the Kubernetes versions. And if you see the green lines, it's basically mainly compatible with the version. Everything else is either a breaking change or not that well compatible. And you have to, basically you have to support the latest version of Kubernetes or just support the earlier version, unless you want to do some magic there. Another point of friction I noticed is that you, so if we've seen earlier, this is how you list all the deployments. And if you notice, there's the in the red, this is not part of client go itself, but it's part of the API machinery. So if you just want to list deployment, which is the simplest thing, right, you have to actually import API machinery to be able to list. And then that tends to end up looking something like this. So this is actually from our habit on operator. And yeah, it's a bit of a mess to be able to import everything just to be doing the basic things. So let's do a bit of a demo. Hopefully this works. Can you see? Okay. So today we'll demo just a simple example of how you can actually extend and use the use client go to actually extend your Kubernetes experience. So where are we? So what we'll demo is just a simple deployment rollout. So yeah, I'm trying to better. Okay. So as we've seen earlier, you can hear we can repeat the steps. So basically, we're trying to get the client set. And what we're doing is getting the configs will be running outside of the cluster. So we'll be passing the kube config file. And after that, we'll be creating the client and passing it over to our package. So let's have a look at that. So what it does is it basically takes a deployment and it creates it first with instance one. And after it's been created, we scale up to 10. As simple as that. And what we do is we first create the deployment. Can you see that? And we pass into deployment, which looks like this. So the deployment representation. And after that, every five seconds, we basically roll out a new deployment and we do that by using the update. So hopefully this works. So and you can use this to extend things like you can do canary deployments and extend this even more. And it's quite cool and really simple. It's only a few lines of code that you use to be able to just make the experience much nicer. Let's see. Okay. So it works. Yeah. Okay. So basically we here created a new deployment and now every five seconds we're scaling up by one. Hopefully. We should be scaling. Yeah. Okay. So as you can see, you can do this whatever you want with a very simple amount of time. So it took me like, I don't know, five, ten minutes to do this. So it's not that. Just don't look at the code quality. So yeah. And after ten seconds, after ten instances, it will actually shut down and we will have ten deployment scale. So it should shut down and we'll have a look at the deployments using kubectl. So we see that we have ten and it was created 51 seconds ago. So that's the demo actually worked. So let's have a look at a bit more. So there are many different alternatives or different implementations of languages. So for example, there is another go implementation, the Kubernetes one by Eric. And it only brings two dependencies with it. So it's a nice alternative for something smaller and quicker to do. So for example, if you want to do a small project, but it's not full-featured yet from what I'm aware. But do check it out. There is also lots of different language implementations because this is the go implementation. So you have two Rust clients and Python, Java, C-Sharp. And there's many more in the Kubernetes client. If you're interested, you can have that look, have a look there. So a bit about the future. I was speaking to a few maintainers here of client go and other tools. So basically the future is quite bright. So I do want to leave on a positive note. As I, there was lots of discussions here as well at KubeCon about this. So they're in the upcoming. So for Kubernetes version 1.9, there will be client go 6.0. And that will be much easier to update. There will be no, at least no major breaking changes planned is what I was told. So hopefully there will be release tags. They're already introduced. So you can actually vendor things much nicer. There are release notes for developers so they know what actually breaks. So you can change it, you can plan things. And also there are nightly releases fixed for client go soon so that you can actually test things. And there is a new channel on the Kubernetes Slack channel. So it's called client go docs. And it's a place to improve on the documentation. So do you check it out if you want to contribute something, something you know. Please have a look. Everyone's really nice. It should be a community effort and we should all contribute some documentation to make lives easier for people and hopefully not need talks like this in the future. And this KubeCon, there was a bunch of discussions as well from different points of view. And on the future of actually of client go and other projects and their libraries. So yeah, so the future is bright. Just want to point that out. So yeah, that was my presentation. So if you have any questions, yeah go for it. Yeah, I know, I know, I know. Yeah, so that's a bit like you can do it but you need to really catch the correct versions right. So for example we were, we are currently still using the client go for and it works fine for us because we haven't switched to five but we will have to switch to six. So that will be hell. But yes, once things settle down and Kubernetes is not so changing I guess. Things will be a bit better but now with new releases and everything, it takes quite a while. So yeah, my answer is you just have to do the work. Yeah, sadly. Anyone else? Yeah, yeah, we used depth and so far it worked fine for us. So I'm a bit confused by everyone complains about it but we haven't switched yet. We're planning on switching to 1.9 so 5.0 because we haven't had many, we don't use our back so we don't need to switch that. So we didn't have to switch too much with this version. But yeah, come and ask me after we switch to 1.9. But yeah, so far depth works for us but there is glide apparently is also good. There is some documentation for that whereas there are some problems with GoDepps. Yeah, go for it. Exactly. Yeah, I'll hand it over to you. Yeah, but he has done some. Yeah. That made sense, yes. Yeah, anyone else? Yeah, go for it. Yeah, no, we're doing end-to-end tests mainly. So we focus on those heavily and yeah, we tried not to do that. We tried to isolate the functions but you can only go so far. Yeah, it depends on the use case. Yeah, go for it. Sorry. We're using depth. Yeah, it works fine for us and also in like the smaller projects is we're perfectly fine as long as you will see. I'll come back to you when we do when we switch to 6.0 but so far it worked fine from the 4.0 I think to the 5.0 switch. It worked fine. Cool, thank you. Do come to our booth.