diff --git a/calico-cloud/multicluster/kubeconfig.mdx b/calico-cloud/multicluster/kubeconfig.mdx index e398d77b36..94d26b27d7 100644 --- a/calico-cloud/multicluster/kubeconfig.mdx +++ b/calico-cloud/multicluster/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-cloud/multicluster/overview.mdx b/calico-cloud/multicluster/overview.mdx index 6f86b84e89..a93d613050 100644 --- a/calico-cloud/multicluster/overview.mdx +++ b/calico-cloud/multicluster/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster. diff --git a/calico-cloud_versioned_docs/version-23-2/multicluster/kubeconfig.mdx b/calico-cloud_versioned_docs/version-23-2/multicluster/kubeconfig.mdx index e398d77b36..94d26b27d7 100644 --- a/calico-cloud_versioned_docs/version-23-2/multicluster/kubeconfig.mdx +++ b/calico-cloud_versioned_docs/version-23-2/multicluster/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-cloud_versioned_docs/version-23-2/multicluster/overview.mdx b/calico-cloud_versioned_docs/version-23-2/multicluster/overview.mdx index 6f86b84e89..a93d613050 100644 --- a/calico-cloud_versioned_docs/version-23-2/multicluster/overview.mdx +++ b/calico-cloud_versioned_docs/version-23-2/multicluster/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster. diff --git a/calico-enterprise/multicluster/federation/kubeconfig.mdx b/calico-enterprise/multicluster/federation/kubeconfig.mdx index 3f33c16d74..6929b11997 100644 --- a/calico-enterprise/multicluster/federation/kubeconfig.mdx +++ b/calico-enterprise/multicluster/federation/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-enterprise/multicluster/federation/overview.mdx b/calico-enterprise/multicluster/federation/overview.mdx index 7c0f58413d..5823ae707a 100644 --- a/calico-enterprise/multicluster/federation/overview.mdx +++ b/calico-enterprise/multicluster/federation/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster. diff --git a/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/kubeconfig.mdx b/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/kubeconfig.mdx index f7e99ce537..2b60cef087 100644 --- a/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/kubeconfig.mdx +++ b/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/overview.mdx b/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/overview.mdx index 777537a648..ae248ce858 100644 --- a/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/overview.mdx +++ b/calico-enterprise_versioned_docs/version-3.21-2/multicluster/federation/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster. diff --git a/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/kubeconfig.mdx b/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/kubeconfig.mdx index c1a6734fe7..667a048ded 100644 --- a/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/kubeconfig.mdx +++ b/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/overview.mdx b/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/overview.mdx index 7c0f58413d..5823ae707a 100644 --- a/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/overview.mdx +++ b/calico-enterprise_versioned_docs/version-3.22-2/multicluster/federation/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster. diff --git a/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/kubeconfig.mdx b/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/kubeconfig.mdx index 3f33c16d74..6929b11997 100644 --- a/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/kubeconfig.mdx +++ b/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/overview.mdx b/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/overview.mdx index 7c0f58413d..5823ae707a 100644 --- a/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/overview.mdx +++ b/calico-enterprise_versioned_docs/version-3.23-2/multicluster/federation/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster. diff --git a/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/kubeconfig.mdx b/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/kubeconfig.mdx index 3f33c16d74..6929b11997 100644 --- a/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/kubeconfig.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/overview.mdx b/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/overview.mdx index 7c0f58413d..5823ae707a 100644 --- a/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/overview.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-1/multicluster/federation/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster. diff --git a/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/kubeconfig.mdx b/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/kubeconfig.mdx index 3f33c16d74..6929b11997 100644 --- a/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/kubeconfig.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/kubeconfig.mdx @@ -34,7 +34,7 @@ Note: much like intra-cluster routing in $[prodname], cross-cluster routing can ### Generate credentials for cross-cluster resource synchronization :::tip[mental model] -The basis of cluster mesh is the ability for a cluster connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. +The basis of cluster mesh is the ability for a cluster to connect to a remote cluster and sync data from it. This enables each $[prodname] cluster to have a view into the datastore that includes both local and remote cluster pods. ::: In this section, we will create a `kubeconfig` for each cluster. This `kubeconfig` is what other clusters will use to connect to a given cluster and synchronize data from it. diff --git a/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/overview.mdx b/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/overview.mdx index 7c0f58413d..5823ae707a 100644 --- a/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/overview.mdx +++ b/calico-enterprise_versioned_docs/version-3.24-2/multicluster/federation/overview.mdx @@ -14,7 +14,7 @@ Utilize $[prodname] to establish cross-cluster connectivity. At some point in your Kubernetes journey, you may have applications that need to access services and workloads running in another cluster. -By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh the following features: +By default, pods can only communicate with pods within the same cluster. Additionally, services and network policy only select pods from within the same cluster. $[prodname] can help overcome these barriers by forming a cluster mesh that provides the following features: - **Federated endpoint identity** Allow a local Kubernetes cluster to include the workload endpoints (pods) and host endpoints of a remote cluster in the calculation of local network policies applied on each node of the local cluster.