Relationships
Meshery Relationships characterize how components are connected and interact with each other. Relationships are defined within models to aid in structuring the interrelationships between one or more components in a design to further in comprehending the overall structure and dependencies within managed systems.
Meshery recognizes that relationships exist in various forms and that the existence of a relationship might be interdependent upon the existence (or absence) of another relationship. To support this complexity, Meshery relationships are highly expressive, characterizing the nature of interaction of interconnected components no matter their genealogy.
Benefits of Using Meshery Relationships
- Improved Visibility: Relationships provide a clear visual representation of the connections between components, making it easier to understand the system’s architecture.
- Enhanced Design: Relationships help you make informed decisions about component selection and placement, leading to better design choices.
- Automated Configuration: Relationship-driven actions can automate the configuration of components, reducing manual effort and potential errors.
- Increased Flexibility: The use of selectors, actions, and operators provides flexibility in defining and managing relationships.
Contributor Guide to Meshery Relationships
If you want to create a new relationship definition or modify existing relationship definitions, see the Contributing to Meshery Relationships guide.Types of Relationships
Meshery supports different types of relationships to cater to various use cases:
- Hierarchical Relationships: These represent parent-child relationships between components, where one component is a dependency of another. arent-child relationships show clear lineage, similar to a family tree (child, parent, grandparent, etc.).
- Sibling Relationships: These represent relationships between components that are not directly dependent on each other but may still interact or influence each other’s behavior; they describe components that share a common origin but operate independently (siblings, cousins, etc.).
- Edge Relationships: These represent relationships that are visually depicted as edges connecting components in MeshMap. Edge relationships are used to define how components interact with each other, such as network connections, bindings, or permissions. They are also used to identify interdependencies between components.
Relationships are are categorized into different kinds, types, and subtypes, so that can be expressive of the specific manner in which one or more components relate to one another. Each type of relationship can be interpretted by Meshery UI (or other extensions) and mapped to a specific visual paradigm for the given kind relationship. Let’s look at some examples of these visual paradigms; let’s explore examples of way in which relationships are represented in Meshery.
Example Visual Representations
Kind: Hierarchical
Kind: Edge
The Meaning of Relationships
Meshery supports a variety of relationships between components. These relationships are categorized into two types: Semantic and Non-Semantic. Relationships are categorized by whether they are meaningful in terms of how Meshery manages entities - a Semantic relationship - or are simply annotations to aid in the comprehension of you as the designer of the relationship - a Non-Semantic relationship.
Semantic Relationships
Semantic relationships are those that are meaningful in the context of the application or infrastructure. For example, a Service
in Kubernetes is semantically related to a Deployment
or a Pod
. These relationships are meaningful and are managed by Meshery.
Non-Semantic Relationships
Non-semantic relationships are those that are meaningful to you as a user and your mental representation of your infrastructure and applications, but are not meaningful in terms of how Meshery evaluates the design or manages these relationships and their associated components. Non-sematic relationships are ignored by Meshery’s lifecycle management engine. For example, a Rectangle
shape that encloses other components (has a parent relationship with other child components) is not semantically meaningful to the way in which Meshery manages these resources. While the Rectangle
shape might have a parent-child relationship with any number of Meshery-managed components, such a relationship does not implicate any management that Meshery might perform; they are not managed by Meshery.
Identifiying Non-Semantic Relationships
The isAnnotation
attribute of a Relationship or Component determines whether the given Relationship or Component represents a management concern for Meshery; whether the given Relationship or Component is sematically meaningful, and whose lifecycle is managed by Meshery.
Core Concepts of Relationships
- Kinds
- Types
- Subtypes
- Selectors
- Selectors Sets
Kind, Type, and Subtype of Relationships
The combination of kind
, type
, and subType
uniquely determines the visual paradigm for a given relationship; i.e., relationships with the same kind
, type
, and subType
will share an identical visual representation regardless of the specific components involved in the relationship.
1. Edge - Network
This Relationship type configures the networking between one or more components.
Examples: An edge-network relationship between a Service and a Deployment or an edge-binding relationship between an Ingress and a Service.
- Example 1) Service –> Deployment
- Example 3) IngressController –> Ingress –> Service
Visual Representation of Edge-Network Relationships
2. Edge - Mount
Example: Assignment of PersistentVolumes to Pods via PersistenVolumeClaim.
- Example 1) Pod –> PersistenVolumeClaim –> PersistentVolume
Visual Representation of Edge-Mount Relationship
1. Edge - Mount: Pod and Persistent volume via Persistent volume claim (open in playground)
3. Edge - Permission
Example: The set of Service Accounts that are entitled with the one or more Roles/ClusterRoles bound via Role/ClusterRoleBinding.
- Example 1) ClusterRole –> CluserRoleBinding –> ServiceAccount
- Example 2) Role –> RoleBinding –> ServiceAccount
Visual Representation of Edge-Permission Relationship
4. Edge - Firewall
Kubernetes Network Policy for controlling ingress and egress traffic from Pod-to-Pod
- Example 1) Pod –> NetworkPolicy –> Pod
Visual Representation of Edge-Firewall Relationship
5. Heirarchical - Inventory
Example
- Example 1) (binary and configuration) –> IstioWASMPlugin
- Example 2) WASMFilter (binary and configuration) –> IstioEnvoyFilter
Visual Representation of Hierarchical-Inventory Relationship
6. Heirarchical - Parent
Example:
- Example 1) Any namespaced Kubernetes component –> Kubernetes Namespace
Visual Representation of Hierarchical-Parent Relationship
Selectors in Relationships
In Meshery, a selector is a way to specify which set of components a certain other component should affect or interact with. Selectors provide a flexible and powerful way to manage and orchestrate resources within a under Meshery’s management.
Selectors can be applied to various components, enabling a wide range of relationship definitions. Here are some examples:
Model Component | Relationship Kind | Relationship SubType | Model Component |
---|---|---|---|
Kubernetes ConfigMap | Hierarchical | Inventory | Kubernetes Pod |
Kubernetes ConfigMap | Hierarchical | Inventory | Kubernetes Deployment |
Meshery WASMFilter | Hierarchical | Inventory | Istio EnvoyFilter |
The above relationships pairs have hierarchical inventory relationships, and visual paradigm remain consistent across different components. A snippet of the selector backing this relationship is listed below.
Example Relationship Selector
"selector": {
"allow": {
"from": [
{
"kind": "ConfigMap",
"model": "kubernetes",
"patch": {
"patchStrategy": "replace",
"mutatorRef": [
[
"name"
]
],
"description": "In Kubernetes, ConfigMaps are a versatile resource that can be referenced by various other resources to provide configuration data to applications or other Kubnernetes resources.\n\nBy referencing ConfigMaps in these various contexts, you can centralize and manage configuration data more efficiently, allowing for easier updates, versioning, and maintenance of configurations in a Kubernetes environment."
}
}
],
"to": [
{
"kind": "Pod",
"model": "kubernetes",
"patch": {
"patchStrategy": "replace",
"mutatedRef": [
[
"settings",
"spec",
"containers",
"_",
"envFrom",
"0",
"configMapRef",
"name"
]
],
"description": "ConfigMaps can be referenced in the Pod specification to inject configuration data into the Pod's environment.\n\nThe keys from the ConfigMap will be exposed as environment variables to the container within the Pod."
}
}
]
}
}
The above snippet defines a selector configuration for allowing relationships between Kubernetes ConfigMap
and Kubernetes Pod
.
Relationship Evaluation
Meshery employs a policy-driven approach to evaluate relationships between components. This evaluation helps in:
- Determining compatible components for establishing relationships
- Suggesting potential relationships based on the current design
- Validating existing relationships and identifying potential conflicts
- Automating the configuration of components based on established relationships
How Relationships are formed?
-
You can create relationships manually by using the edge handles, bringing related components to close proximity or dragging a component inside other component. It may happen that, you created a relationship from the UI, but the Policy Engine rejected or overrode the decision if all the constraints for a particular relationship are not satisfied.
-
Relationships are automatically created when a component’s configuration is modified in a way that relationship criteria is satisfied.
Explore an example relationship
To explore an example of this behavior, see the Example Edge-Permission Relationship and follow the steps written in its description.When the relationships are created by the user, almost in all cases the config of the involved components are patched. To see the specific of patching refer Patch Strategies.
Designs are evaluated by the Policy Engine for potential relationships.
Patch Strategies
Patches in Meshery relationships utilize strategies and references (mutatorRef/mutatedRef) for the from and to fields. These convey the property path that will be updated as the relationship is created.
Cavets and Considerations
- If the user creates a
Hierarchical Inventory
relationship betweenPod
,Job
, and any other high-level Kubernetes resources likeDeployment
,StatefulSet
, orCronJobs
, after the relationship has been established unfortunately, there’s no system to remove the extra pod configuration automatically. If the design is not configured withlabels
selectors
andreplicas
appropriately, there’s a possibility of additional resources getting provisioned when deployed. eg: The relationship between a Pod and deployment can result in 2 Pods (1 pod coming as part of deployment resource) and 1 Deployment. It’s important to be aware of this possibility and manage configurations carefully to avoid unexpected issues during deployment
Itemizing your Relationship Definitions in your Meshery deployment
In any given Meshery deployment, you can reference and search the full set of registered relationships (in Meshery’s internal registry) in using either of Meshery’s client interfaces.
Meshery UI
- Visit Setttings –> Registry
Meshery CLI
- Run
mesheryctl relationship list