Kubernetes annotations vs labels11/8/2023 ![]() Note that these service catalogs should not be confused with the Kubernetes Service Catalog project. Popularized by tools such as Shopify's ServicesDB and Spotify's System Z, service catalogs are internally-facing developer portals that present critical information about microservices. Over the past few years, service catalogs have gained greater visibility in the Kubernetes ecosystem. Moreover, using kubectl describe requires every developer to have some direct access to the Kubernetes cluster. Visualizing annotations: Service CatalogsĪs the number of microservices and annotations proliferate, running kubectl describe can get tedious. Unstructured text describing the service dependencies for humans. Slack channel, or link to external chat system. ![]() SSO username (GitHub), email address (linked to GitHub account), or unstructured owner description. Unstructured text description of the service for humans. Here is one set of conventions, documented at a8r.io, and reproduced below: Annotation convention for human-readable services Annotation Namespacing your annotations is also very important. Typically, you’ll want to attach the annotation to the service object, as services are the high-level resource that maps most clearly to a team’s responsibility. If you’re practicing GitOps (and you should be!) you’ll want to code these values directly into your Kubernetes manifest, e.g.,ĪpiVersion: v1 kind: Service metadata: name: quote annotations: a8r.io/owner: spec: ports: - name: http port: 80 targetPort: 8080 selector: app: quote A Convention for AnnotationsĪdopting a common convention for annotations ensures consistency and understandability. You can do the following: kubectl annotate service quote this example, we've just added an annotation called a8r.io/owner with the value of Now, we can use kubectl describe to get the information. Imagine you have a Kubernetes service for quoting, called the quote service. ![]() As such, label structure and values are constrained so they can be efficiently used by Kubernetes. This is a contrast to labels, which are designed for uses internal to Kubernetes. As such, annotations can contain any type of data. The Kubernetes documentation says annotations can “attach arbitrary non-identifying metadata to objects.” This means that annotations should be used for attaching metadata that is external to Kubernetes (i.e., metadata that Kubernetes won’t use to identify objects. Oft-overlooked, Kubernetes annotations are designed to add metadata to Kubernetes objects. Kubernetes annotations are designed to solve exactly this problem. Who owns a particular service? What Slack channel does the team work on? Where is the source for the service? What issues are currently known and being tracked? Kubernetes annotations While much attention has been paid to centralizing machine data (e.g., logs, metrics), much less attention has been given to the human aspect of service discovery. Troubleshooting always begins with information gathering. When it comes to troubleshooting, however, developers need to be able to find the source, understand the service and dependencies, and chat with the owning team for any service. As the number of services grows, developers start to specialize working with specific services. One of the problems as Kubernetes applications grow is the proliferation of services. Have you ever been asked to troubleshoot a failing Kubernetes service and struggled to find basic information about the service such as the source repository and owner?
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |