octant webinar

octant-webinar.txt

## Octant CNCF Webinar

### Intro Slide

First let me say Hi and thank you everyone for taking some time out of your day to learn a bit more about Octant. 
(as mentioned) My name is Wayne Witzel and I am one of the Octant maintainers and I'm really excited to be here to show you,
what I think is a pretty awesome tool for developers.

I encourage you to ask questions as you watch, and if possible, I will answer some questions dircetly during the demo portion, but we will have a dedicated Q and A session at the end, so don't worry if I miss your question during the live demo.

So first,

### What is Octant?

To quote our README, Octant is a "Highly extensible platform for developers to better understand the complexity of Kubernetes clusters."

So, what exactly does that mean?

What that means, is that even though Octant has a lot in common with what you might find in a typical dashboard, Octant can also be used to create your own user interfaces and interactions with a Kubernetes cluster.

In fact, most of what you see when you are running Octant could be created completely in plugins. As part of the client piece of Octant we provide a set of common views and interactions that help to make Octant useful out of the box.

Almost everything that I am going to show during the demo is a feature that ships directly with Octant. I will be careful to make a note anytime I am showing a view that is generated via a plugin.

Some of the ways I use Octant:
 * kubectl UI
 * better understand / collate information
 * workload explorer and debugger
 
 That last one is what we will be doing during the demo.


### Demo

So with that, let's get in to the demo.

<Show Octant>

Here is Octant. This maybe a familar view to some of you. I am going to quickly go over the sections of Octant, but I am not going to walk through and click each thing right now, we'll be doing that as we work through the demo.

So working top to bottom, we have the context switcher and namespace switch in the top right.

Moving across we have our label filtering input.

The right hand side of the view has a collapable navigation menu. The navigation is sectioned in to Namespace, Cluster, Plugins, and of course at the bottom of the navigation bar is our Dark and Light mode toggle, and as you know, the most important feature of any application these days.

In the center is the content and by default, your first view will be the Overview or your default namespace as selected by your kubeconfig or with the --namespace argument when you first start Octant.

## Setup Demo

So my current namespace here is pretty boring.

I  want to create a new namespace. We'll call this namespace cncf-octant-webinar .. sure.

<Show Terminal>

You'll see here I have a very simple YAML file to creaet a namespace.

 cat 00-namespace.yaml
 k apply -f

<Show Octant>

So, you'll see here, nothing has changed because we are looking at the default namespace still.

If you move to the namespace switcher you'll see the newly created namespace and from there you can select it.

Now we are looking at our newly created namespace with nothing in it.

So I have an existing application, json-server and I want to get a version of that up in my cluster.

<Quickly show Dockerfile>
<Quickly show YAML>

So I've gone over my YAML and it looks good to me. You might see some mistakes, but I missed them because I've been looking at the same set of files all day.

k apply -f

Looks like everything applied correctly, must means it all works right?

<Open browser to localhost/json-server>

Looks like we have a problem. So tradionally I'd start running kubectl commands, trying to guess at where the issue might be, now I can do this because I have a basic understanding of how things in the cluster are connected, but honestly, I'd rather not have to.

So now-a-days, I'll pull up Octant.

<Show Octant>

Namespace switcher double check

<Events>

So we pull up the events list for our namespace and we can see that our pod that our deployment has created has some issues.

One that is slightly cryptic about ErrNeverPull, which is likely related to our image pull policy in our deployment, but even if we didn't know that, we have a second event with a message that is a bit more clear.

Looks like the container image is not present.

So previously I had built that container image and pushed it in to my local docker registry that kind uses.

So I can go out to the command line and verify the image name and tag, but I happen to have a plugin that will show me all of my local docker images that I can access within KinD.

<Docker Images Plugin>

Verify the repo and tag, see that it is latest and we used current.

So now we can see that our pod is using current, but should be using latest.

We want to edit this Pod so that it is using the correct image. So what if we just make that change right to the Pod.

<Click YAML> Edit container to latest and <Update>

<Try /json-server again>

<Namespace Overview>

Let's find out if we have any other resources that don't seem healthy. Looks like the Service has a warning. Lets go take a look at that.

<Service>

Here we see the service configuration and status. No much info here, lets take a look at the Resource Viewer.

So in the resource viewer you can see we have this ingress, and our service, but that's it, no more connections. If we click on the service we can see that the service has no matching endpoints.

So maybe we have to search for Kubernetes Service and we learn that an endpoint will be created automatically if there is a matching selector OR we can manually add an Endpoint object.

So lets take a look at our YAML and yep, there it is a selector. Which, since we are getting no endpoint, is likely wrong. Now, if we remember the exact name of our selector, we could just edit that here, and update.

But lets say we are unsure, well Octant provides a helpful edit on the Service configuration, which will include known selectors. So lets edit our Service there.

<Edit Service>

** Highlight endpoints

<Resource Viewer>

Now things are looking better, lets try our application again. Looks like we have a different error this time.

So lets step back to our pod. We can test our application right from the Pod summary by selecting the port forward action.

<Click PF, visit link>

Alright, so here is an error we've seen before that has nothing to do with Kubernetes. Empty resposnse error.

If you have been working with web applications and have attempted to setup forwarding using nginx or HAproxy or some other tool, you've probably see errors like this before when testing.

So that port, 8080, is giving us no content.

We can use the Terminal and the Logs tab to find out more information.

<Terminal>

Here we can run ps command and see that the node instance is indeed running and was started with the `-p 80` flag.

<Logs>

The logs show us a similar story, all of the request paths and listening addresses seem to be using port 80.

Alright, so we edit the Pod to use port 80, same as we did for the container image.

** Explain the failure, that we only edit certain fields of the Pod spec.

Ok, so what controls the lifecycle of our pod?

<Resource Viewer>

RelpicaSets, now I didn't actually create those explicitly, so I probably don't need to be editing them either. But I did create a Deployment. and that Deployment, is where I defined my containers.

<Deployment>

Ok, so no we are looking at our Deployment because we are interested in fixing the port of our pod. We can see our pod template. Notice that the image is still wrong. This is because we fixed it before directly in our pod.

As an example of why it is important to edit the Deployment, if I scale up this Deployment, the new pods, will fail to run successfully.

** Note the image is still wrong. Scale up the replicaset. Show failure.

** Scale it back down.
If we only had our image to fix, we can use Octant's built-in quick edit for the Pod Template and change it right here.

<Click Edit in Pod Template>, <Cancel>

But, since we want to do both, let's fix our image and port at the same time by using the YAML editor.

** Edit the depolyment.

Looks like our YAML was successfully applied. We should be able to now visit our pod and see the new port of 80 being displayed.

We can also now re-test our Port Forward.

<Port Forward>, Show Success

Alright, that's looking good now. So let's try our external URL again. Welp, same failure. That's not very helpful.

Let's use our resourcer viewer to better understand the relationships between things and maybe that will give us a clue as to where to look.

So looking at the resource viewer, I can infere that when I'm using the direct Port Foward to my Pod, I'm validating not only that pod, but the deployment that created it as well.

So this <trace step in RV> part of our application, we can have a pretty high confidence, that it is working.

What isn't working, is our external access, so from the Ingress, Service, and ultimately to the Pod.

Our next step, will now be to inspect each of these for clues.

Lets start with Ingress

<Ingerss via RV>

Things here look pretty normal and we have a direct link to our Backend, so lets follow that.

<Service via Backends Link>

We will step through each part of the Configuration just to make sure that everything is copasetic.

The selector is good, we fixed that previously.
ClusterIP is right.
Ahhh, 80 to 8080.

We fixed the previous 80/8080 mismatch we found on the Deployment object on the internal side of things, but never fixed it here in the service.

Let's edit our service yaml one last time to make sure we are sending traffic to the correct port.

<YAML Editor>, <Update>

Ok, updated <Service Summary>

Now, lets try our application again. Success!

And with that, what I'll do is I will copy and paste the parts of the YAML from the Service and the Deployment that changed so that I can make sure to persist those changes to my YAML outside of the cluster.

And that's it for the demo, that demo was intended to show an actual example of how I recently used Octant to trobuleshoot a deployment while migrating an application to run in Kubernetes. It was not intended to be a comprehensive demo covering every feature of Octant for that, I encourage you to download Octant and try it for yourself as well as visit our site https://octant.dev which has links to more content and detailed information about creating plugins.

### Q+A Slide


### Outro Slide
 * octant.dev to find all our links for GitHub, events, and documentation.
 * #octant on the Kubernetes slack.
 * community meeting (every Wednesday, 11AM PT, 1PM ET)
 * office hours (every Wednesday starting right after the community meeting and going until 4PM PT / 7PM ET)