Labels and Annotations

Transcript:

Before we move on, though, I do want to call out labels and annotations. We've used labels a little bit throughout this section, specifically to tie things together and allow referencing between, for example, a deployment and the pods that it's managing.

In general, labels should be used for attaching key-value pairs to resources that can be used to identify and organize Kubernetes resources. So, that example where you're tying a service to a pod or a deployment to a pod are perfect examples where those are identifiable labels that you have to attach to these resources.

You also can use labels when you're making your kubectl queries or querying the API server to filter the results. Oftentimes, you'll include a label specifying what application it is associated with.

For example, you might have the name of your application on it, or you might specify a version that the application is running.

Annotations similarly live within the resource metadata. However, they should be used for information that is non-identifying. The Kubernetes system often uses annotations to do things like store configuration details or deployment history.

We saw in the ingress section that many controllers use annotations to add configuration beyond the default specification. I just wanted to highlight the difference between labels, which should be used for identifying information, and annotations, which should be used for non-identifying information.

While annotations can be used to configure behaviors, like we saw in the case of ingress, it's important to call out that they are arbitrary, untyped strings with no schema enforcement. It is very easy to make a mistake and fairly hard to debug those mistakes.

So, when using annotations in that way, you'll want to just be careful that you're double-checking the values that you're putting in and making sure that they're valid and perform the way that you would like them to.