Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 1. Planning your tagging strategy
1.1. Using tags
Tags, which are also known as labels in OpenShift, are strings of custom metadata that you can assign to resources. In cost management, tags enable you to allocate costs to different parts of your environment and get a more accurate view of your cost data.
You can use tags in conjunction with hierarchies, such as projects, in your clouds and clusters. Cloud providers place limits on the number of tags that you can associate with resources, so you should plan a tagging strategy for cost management.
Tags can also help you achieve the following goals:
- Map business concepts to reports
- Show costs grouped by business concepts
- Define operations like business automation, operational profiles, or access and security controls
- Apply policies based on tags
- Split resources into smaller units when it is not possible to use projects or subprojects
- Identify relationships between integrations and group applications across multiple clusters with the same environment, cost center, or team
- Identify dependencies when there is no direct link between a resource, such as an RDS database and the OpenShift project that uses it
1.2. Creating a strategy for tags
When you plan a strategy for your tags, you should consider how you will organize and report costs for your integrations. Start with the minimum number of tags that you think you need to accomplish your organizational objectives. If you need more, slowly build over time.
The following sections outline some key considerations to make before you begin creating your tags:
Value precedence:
When multiple values are associated with the same key for a specific resource, Value precedence refers to the criteria that determines which value takes precedence. To avoid duplicating costs when you group by a tag, each tag or label key must be unique for every resource.
To learn more about how to consider value precedence, see Section 1.3, “Understanding value precedence in tags”.
Map business to reporting::
Define the business perspectives you want to report on. For example, your taxonomy for cost management could consider these different perspectives:
+ .Ownership and usage: Defining the owner and the user of the resource: for example, the unique identifier of the user who requested the resource, and the one that is actually consuming the resource.
+ .Tenancy: If your environment is shared, it can be beneficial to understand which group or business unit has requested the resource. When the user is part of different groups, one group needs to be selected. For cost reporting, you can achieve this in many cases using cost center; but department, project, or partner are also good candidates.
+ .Location: For organizations with software deployed globally, cloud providers already identify the region where your resources are running, but your private cloud may be different.
+ .Environment or stage: You may want to differentiate between development and production, so that different cost decisions can be made depending on the environment where you are creating or running the resources. If your development pipeline already includes stages, such as development, testing, staging, pre-production and production, this is a good candidate.
+ .Application / Project / Service / Event: Perhaps your environment is providing a service, such as a group of transient resources for an event (for example, your yearly customer-focused conference). You could even include the application version.
- Standardize your labels
Consistency is the most important aspect of a tagging strategy to deliver accurate and comparable cost reporting results.
Create a clear tagging policy that defines what resources need to be tagged, what tags are mandatory and what tags are optional, making sure that there is no room for interpretation.
If the values need to be chosen between a list, verify that those values are defined, consistent, and easily accessible, or that the list is presented to the user. For example, if you are defining development with the key “Development”, do not also use variations such as “Dev”, “DEV”, or “R&D” to also identify resources as “Development”.
- Tag all elements on your integrations (manually or through automation)
Since untagged resources cannot be reported, tag as many elements as possible, ideally using automation to prevent human error. Integrations have different automation features to take advantage of for tagging:
- In Azure, you can use Azure Policies to enforce tagging rules and conventions and avoid resources being deployed that do not comply with your expectations. You can create a policy that automatically applies necessary tags during provisioning, that enforces a predefined format for dates, or that makes some tags mandatory for some resource type.
- In AWS, you can use IAM policies for the same. Additionally, you can use an automation tool such as Ansible to add the necessary tags during provisioning and to verify that all the resources have been properly tagged.
- OpenShift Container Platform does not presently have a method of automating labelling.
- Review your tags often and refine as needed
Define your tags and use them as early as possible with cost management, even if you need to adjust your tagging scheme afterwards.
Review the resulting reports with your business owner and stakeholders early on to ensure your tags are helping you to generate the desired reports, and review your tagging strategy every few weeks to optimize it.
- Select your tag terminology
- Name your resources with names that allow you to identify your resources without accessing metadata, and then continue by adding metadata to it. Many clouds have a guide about how to do this properly; see Chapter 5, Additional resources for links.
- Map your resources into keys and values. Keys will map to perspectives, while values will define the different options allowed for each key. In some cases, the value will be Null.
Not all integrations allow the same identifiers, and have different limitations. See Section 5.1, “Tag specifications by integration type” for limitations by integration.
1.3. Understanding value precedence in tags
When you associate multiple values with the same key for a specific resource, value precedence refers to the criteria that determines which value cost management prioritizes. To avoid duplicating costs when you group by a tag, each tag or label key should be unique for every resource.
1.3.1. OpenShift value precedence
In OpenShift, create a protocol that maintains the most specific value possible.
1.3.1.1. Namespace, node, and pod labels
If each resource has the same key, pod values override both node and namespace values. Cost management prioritizes pod values because the labels at these levels are more specific to the workload that is running inside of them. Node labels and namespace labels are more generic and describe characteristics at a higher level.
Namespace, node, and pod labels have the following value precedence:
- Pod labels
- Namespace labels
- Node labels
1.3.1.2. Persistent Volumes and Persistent Volume Claims labels
Persistent Volumes (PVs) are resources in the cluster that exist independently from the node or namespace. Pods create Persistent Volume Claims (PVCs) to make requests for those resources from the available PVs. When a request matches the criteria for one of these PVs, the pod uses these claims as volumes.
PVs and PVCs have the following value precedence:
- Persistent Volume Claim labels
- Persistent Volume labels
- Pod labels
- Namespace labels
- Node labels
1.3.1.3. Cloud data that is filtered by Openshift
When something is filtered by OpenShift, it indicates what amount of the cloud provider’s cost is associated with running an OpenShift cluster. When a cloud provider and an OpenShift source have matching tags or resource IDs in the cost reports, cost management correlates the two reports. This correlation calculates how much of the cloud provider cost is related to running OpenShift.
We combine the tags and labels of the two reports into one, but prioritize the cloud instance’s tags—rather than the Openshift labels—because the cloud instance is the original source of the data:
- Cloud instance tags
- OpenShift labels
