Out of Scope (Built in Resources)

Transcript:

Now, it may have felt like we took forever in this section. That's because there are a ton of built-in resources that Kubernetes provides.

I did want to call out a few things that I am not covering here, and I'm leaving these as an exercise for the viewer. They're useful to know about, but I didn't deem them critical for this particular course.

And those are:

Limit ranges. A limit range allows you, as a Kubernetes administrator, to govern the number of resources that a particular object kind can request. This prevents resources from being deployed that take up the entirety of the cluster's resources.

Network policies. Network policies are a mechanism to control access from a network standpoint across different boundaries. You can say this set of pods are the only ones that are allowed to talk to this set of pods. It allows you to declaratively specify the set of allowable network traffic patterns. Applying network policies can be a great way to increase the security of your cluster by preventing connectivity from pods that shouldn't be talking to each other anyway.

Mutating webhook configurations and validating webhook configurations. These are ways that you can enforce specific standards about the characteristics of the resources you're deploying. For example, you could have a validating webhook configuration that required every deployment to specify its memory request and limit. You could reject any configurations that did not meet those rules.

You can use validating webhooks to enforce specific standards that you care about. Mutating webhooks allow you to take a request to deploy some resource and make a change to it on the fly. This allows for some really interesting behavior.

For example, you could automatically inject a sidecar container that is performing some functionality without the end user needing to know about it or include it in their definition.

Horizontal pod autoscaler. This is a tool you can use to automatically scale the number of replicas within, let's say, a particular deployment or stateful set based on metrics that you define. You could scale based on CPU usage (that's kind of included out of the box) or you can have custom metrics.

For example, let's say you have some queue processing workload—the length of that queue could be included as a custom metric, and you could scale accordingly.

Custom resource definitions (CRDs). These are one of the more interesting pieces of Kubernetes. They allow you to extend the Kubernetes API and define resources that are not in this built-in set, which can be used for the specific purposes of your application.

We're going to cover this a little bit in a later section because this is a really key aspect of many of the tools that are built on top of Kubernetes.

If any of these additional resources sound like they would be useful for your particular application, I urge you to go look at the documentation for them and figure out how to use them for your particular use case.