Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SIG CLI Intro and Updates - Phillip Wittrock, Apple, Maciej Szulik, Red Hat, Sean Sullivan, Google

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

SIG CLI Intro and Updates - Phillip Wittrock, Apple, Maciej Szulik, Red Hat, Sean Sullivan, Google & Eddie Zaneski, AWS

Maintainers from SIG CLI will introduce the audience to the projects hosted under the SIG and the SIG CLI community. They will provide a brief overview for each of these projects, including giving on update on the current state of the kubectl and kustomize CLIs. Maintainers will also cover the contribution process for the SIG, and they ways they have seen new contributors successfully onboard into the SIG. The final 15 minutes of the session will be reserved for answering questions from the audience.

https://sched.co/ekGg

A

Hello and thank you for joining us for the sig cli intro session. My name is eddie zaneski and I'm joined by phil, whitrock, sean sullivan and mache schulich. Six cli is the special interest group for the command line tools inside the kubernetes project. We don't necessarily work on every tool, but we provide libraries and frameworks that they build out of today. We have a couple quick short updates for you and we'll have plenty of time at the end. For your questions, obviously, though, the most burning question you have is: how do you pronounce this tool?

A

uh There is no official pronunciation. There is a logo in a mascot, so I will let you make your own decision there. I personally say cube ctl.

A

We have a bunch of amazing contributors. uh Two chairs, that oversee governance of the sig two tech leads that oversee steering we're made up of a handful of different sub projects. Cubecontrol is the command line tool that you use to talk to a kubernetes cluster customize lets you modify and manipulate yaml manifests that come down without making changes to the original crew and the crew index is the package manager for cubectl plugins. I think we're up to 120 plugins right now, so you should definitely go check.

A

Some of those out kui is a awesome project that provides an interactive graphical tool that you can use to work with cube control and output, and then, as I mentioned, we have a bunch of other libraries that are used for building command line tools.

A

You can find us on slack in the sig cli channel. We have a mailing list under google groups, we have a bi-weekly meeting uh wednesdays at 9 a.m, pacific time and we have a monthly bug scrub where we go over and triage open issues. This is great for people who want to get involved in the sig.

A

Sig cli and cube ctl has grown interest over the time. If you join the mailing list, you'll receive calendar invites to the meetings I mentioned. We are always welcoming new contributors, uh any feedback you have and and hopefully we have some cool things cooked up for you in the road map in the next couple of releases. So thanks for joining us- and I hope you enjoy the the sessions hi.

B

My name is phillip rock I'm here talking at the 6 0i deep dive session, I'm going to talk about something we're calling resource functions in six cli. These are really about. How do we model controllers on the client side and how do we take the level triggered holistic reconciliation of the system and take those concepts on the client so for context?

B

The way controllers work is, if you have a deployment controller here, its job is when a user specifies a deployment to manage replica sets right so, for instance, go create the replica set for this deployment.

B

But what makes this different than sort of the client-side patterns we see today around like uh templating, for instance- is that this controller also reads the replica sets before deciding what to write right. So it also writes back the deployment the status now. This is the one that I think is important.

B

It looks at the whole state of the system and it says: okay, do I need to delete a replica set, create a replica set scale, one up or down, and this makes sense in like a dynamic, changing system to do sort of the level triggered self-healing approach and a while back this project, called meta controller came along the way meta controller works.

B

Is it said, instead of setting up all this logic, for watching resources and figuring out how to list them and read them and then write them back out what if we just wrote this decoupled, how do I want the existing state of the system changed right from? How do I read the existing system? And how do I trigger this thing?

B

And how do I write it back up and what I like about this model is, while the meta controller model reads and writes from the api server and the framework provides the resources that, in our case, we can take the same approach and say hey what if it read from a file right and wrote back to a file or wrote to a different file or wrote to standard out right, and so now we can take this approach of looking at a holistic state of a system and defining some business logic.

B

That knows how to take a set of inputs, change the set of outputs and apply it to how we manage our configuration and define our applications.

B

The notion of saying hey, I want to write a system where I take in a set of resources and then apply some transformations to them before they get to their final destination is not new right. So this is how customize is architected, where you have customizations that get as import a set of resources and then modify them apply.

B

Patches, apply, annotations, apply, prefixes and suffixes, and then omit there and then pass them on to the next one right, and you can kind of think of these similar to you know that meta controller function that we demonstrated, and these look kind of, like controllers, which is really finely scoped to a static set of transformations like patches right instead of arbitrary transformations.

B

The second one is kind of the helm, helm flag for post rendering right, and so you can have some executable modify the output of helm before it's sent to the api.

C

B

And again, this looks kind of similar to the metacontroller model, where um you provide some executable helm is going to send some registered resources to you and then you're going to omit them, and then these go back to the api server right. So this model of writing logic, which reads resources transforms, then writes them back out, is taking root in a couple different places, and if we just focus in on like the core principle of what it's trying to do, how controllers do this? We can actually start to do some new and interesting things.

B

So one thing we can do is with customize or sorry with helm.

B

Helm, customized pairing: this is a common thing. Folks do when they have a helm chart. They want to change the output in some way. They don't want to change the underlying chart, so they use customize as a post, rendering step for the helm, resources to apply patch right, and while this is a cool thing to do, people find it successful.

B

One limitation of this approach is the post. Transformation, doesn't have any context of the helm chart right so, if you're doing a spring boot application you're applying patches to blindly at a resource level, not at the spring boot level right, and so, if you have a comes out and then you patch a and then tomorrow b comes out, we have to write a different patch right. You have to change this patch to patch b right, because this doesn't really have any context on on what this stuff is.

B

So there's two kind of cool things we can do here. One is you replace like static patches and stuff, and if you have something like a common cross-cutting piece like a log log injector right, you want to make sure a log. Rotator is installed as a sidecar container.

B

You can actually do it as a function right and then the function can maybe look at an annotation for a blogger on resources and then find everything. That's annotated with that and then figure out how to put the logger in right, and it can not just do something a patch can do which is like match to to these and patch them, but it can, for instance, look at what type of logger to install based on what type of whether it's a staple set or deployment or other things about it.

B

Other aspects right, you can dynamically reconfigure itself based on what it sees as input.

B

The second kind of cool pattern is that, instead of patching a resource on the way out right, so in this case we are modifying resources to have a logger on the way.

C

B

We can actually provide the patch as input to a function right. So if you replace maybe your template with a function that is going to act more like a deployment controller, then you can have you know your typical values as input, but you can also specify maybe the deployment that this thing would normally generate right. So you annotate this with. You know spring boot, and this is a screen boot function and rather than just spitting out a deployment that it generates.

B

um You know by rendering these values it can actually find this deployment that that was specified and given to the function. It can say, I'm actually going to decorate this deployment given to me now, there's no patching, there's no post step where you figure out how to take the output and change it because, as part of the input you're specifying actually what you want- and this function has the context to look at this thing and say: hey you're, specifying um some environment variable here.

B

uh But uh you know what you specified in the values file here doesn't make sense right through this combination, and only something like this function would have that context. The way controller would so those are kind of some of the interesting ways we're looking at functions and basically using them to augment existing solutions and using them as post renders or um as parts of customized extensions or other places and other tools and figure out. uh How can we bring the sort of holistic approach of looking at not just like here's?

B

Some input produce some output, but um here's some or not just here's, some like abstraction sort of uh template inputs, but also looking at here's some extraction. You know template inputs and here's um a set.

B

Here's some additional state like the the observed state, if you will the equivalent of those replica, sets for the deployment controller and say uh instead of just going off and doing your own thing and building a new thing like take this and modify it in place to make it look the way I want it to anyway thanks and have a great coupon.

C

Hello, I'm sean sullivan and I am a co-chair of the six cli and what I'd like to talk to you today about is how to reuse coupe control code.

C

So, as we all know, the coop control is the standard command line, client for communicating and controlling a kubernetes cluster, and because of that, there is already a significant amount of well-used well-tested battle hardened code for implementing functionality to communicate with our clusters.

C

So wouldn't it be cool if we could reuse this code and the good news is we can so over many quarters. The six cli has been working to refactor the coop control code to move it into a location called staging.

C

Now in this staging location, the control code is now significantly easier to import and reuse, and I've included a url here to show you where the code control code now lives and because it lives in staging. In this new location, we can easily import code control code with a simple, straightforward import, k.I io, coupe control uh statement.

C

So, during this brief overview, I'm going to use the control tank command in order to show how we can reuse cube control code. But what is coop control taint or what is it taint? So a taint is basically extra metadata that we're going to put on nodes that allows more advanced scheduling, opportunities and an example of this command is crew control, tank nodes, foo foo, being the name of the node, and then a label and an effect.

C

So it turns out that almost all coupe control commands follow a particular pattern and the pattern is there is a struct created that contains all of the fields necessary to run a particular command, and then there are three functions which work on that uh option: struct in order to implement the command, and these three commands are a complete command. The complete command will fill in the values of the struct.

C

The validate command will, unsurprisingly, ensure that all the fields are valid for the struct and then the execution of the command is is an options.run function and for for our example, tank command. There is the taint options: there is a taint options, dot complete a taint options, dot validate and then a taint options.run taint which actually executes the tame functionality.

C

So here is actually code in in staging implementing taint the tank command, and here is what the taint option structure looks like. So it's going to have particular fields that are necessary and used for the implementation of the taint command and then further down. We actually see how this struct is. This taint option structure is used, so here's the command here is where we created the taint options, and then here are the three, the three invocations of the functions necessary to implement the tank command.

C

The the three that I mentioned before complete validate and run taint. The execution.

C

So what if I wanted to use taint this tank functionality in one of my applications? Well, I would simply import this taint code base, and this is this k-I o coupe control package command taint is the location that I would import.

C

I would create a taint option structure and then massive hand waving here. I would fill in and validate the fields for that option structure and I would call run taint on that options so because we have such a small amount of time, I'm not going to be able to dig into the actual uh the actual filling in or validating those fields, but all I want to to convey is the general overview of how we would reuse code control code.

C

So, in summary, if you don't remember anything else from this short discussion, it's you can reuse coop control code in your own applications. Thank you very much.

D

I'm going to show you a few helpful tricks you might not have heard before when using cube control. Let's get going, I'm going to create a sentence pod and I'm going to copy cube cuddle binary into it and I'll explain a little bit. Why so? Keep cuddle has several places that it will search for configuration.

D

You are probably familiar with home, slash, dot, cube directory, which is the default directory, where cube cattle stores, its configuration and cache files. You've also heard about dash dash, cube, config, flag or cube config environment variable, which allows passing configuration file location, but not many users note that there is also one another location that cubcada will look for when loading files, the so-called in-cluster configuration since a picture is worth a thousand words. It's best to show you how this works with an example.

D

So inside of my pod, I can invoke keep cuddle get pot operation. Unfortunately, this operation will end with an error which says that my user does not have the necessary permissions to perform that operation.

D

If you look closely, though you'll notice that the username is actually a default service account assigned to my pod, this is in cluster configuration kicking in with checks, presence of three elements: a file, a service count, token located in slash bar slash, run, slash secret, slash quantities that io slash service, account, slash token and two environment variables, kubernetes service host and kubernetes service port. When it finds all three of these. It knows it's actually running inside of a kubernetes cluster and it should read injected data to talk to the cluster.

D

In my cluster, I have a set of pre-existing cluster roles, one of which was is view.

D

Let's create a cluster role binding that will add the view role to my service account and, let's again, try to repeat the get parts operation and now this time it succeeded.

D

Perfect, let's on move, let's move on to the next example: I'm going to change my user to be a non-system admin, and now I'm going to try to get parts from my previous example.

D

It's forbidden so kubernetes has a unix pseudo-like capabilities. It is called user impersonation to use it. You need to pass dash dash as flag and a user name that you want to impersonate. So, let's try to impersonate system admin. Unfortunately, that operation will fail because we don't have the necessary permissions. Similarly to how you do it in unix systems, namely, we need to have a impersonated verb permission in my cluster again, I have a pre-existing cluster role called sudor.

D

Let's again, add the sudor role to my user.

D

And, let's again, try to impersonate the system admin this time, this operation works to prove that the impersonation is working as expected. Let's try again invoking the same command, but without the impersonation and as expected, this operation will fail.

D

There's also dash dash ask dash group flag, which allows to impersonate a group but I'll leave this as an exercise to the viewers. The final two examples that I would like to present is tube cuddle.

C

D

Command by default, we'll use v editor on linux and notepad add their own windows. But if you want to change the cube cuddle edit editor to your own favorite, all you need to do is use cube, editor environment variable in my case, I'm going to use vs code and I'm going to edit that same part that we've been working with. Let's try to change the synthes image, save that one okay and let's try to verify the image of the modified pod and as expected, it is sent as 8.

D

as a final example.

D

There is a command new alpha command that we are hoping to to promote to beta in 120 cube cuddle, debug debug allows the backing gear application and best to learn all its possibilities and capabilities is by giving it a try. So happy debugging. Thank you very much for your time and now we're going to answer some of your questions.