Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 6. Deploying multiple service meshes on a single cluster

You can use the Red Hat OpenShift Service Mesh to operate many service meshes in a single cluster, with each mesh managed by a separate control plane. Using discovery selectors and revisions prevents conflicts between control planes.

6.1. About deploying multiple control planes
Copiar enlace

You can configure a cluster to host multiple control planes by deploying unique Istio resources in separate namespaces and using revision labels to manage sidecar injection for specific workloads.

Each Istio resource must also configure discovery selectors to specify which namespaces the Istio control plane observes. Only namespaces with labels that match the configured discovery selectors can join the mesh. Additionally, discovery selectors determine which control plane creates the istio-ca-root-cert config map in each namespace, which encrypts traffic between services with mutual TLS within each mesh.

When adding an additional Istio control plane to a cluster with an existing control plane, ensure that the existing Istio instance has discovery selectors configured to avoid overlapping with the new control plane.

Note

All control planes in a cluster share a single IstioCNI resource, and you must update this resource independent of other cluster resources.

6.2. Using multiple control planes on a single cluster
Copiar enlace

You can use discovery selectors to limit the visibility of an Istio control plane to specific namespaces in a cluster.

By combining discovery selectors with control plane revisions, you can deploy multiple control planes in a single cluster, ensuring that each control plane manages only its assigned namespaces. This approach avoids conflicts between control planes and enables soft multi-tenancy for service meshes.

6.2.1. Deploying the first control plane
Copiar enlace

You deploy the first control plane by creating its assigned namespace.

Prerequisites

  • You have installed the OpenShift Service Mesh operator.

  • You have created an Istio Container Network Interface (CNI) resource.

    Note

    You can run the following command to check for existing Istio instances: 

    $ oc get istios
  • You have installed the istioctl binary on your localhost.
Note

You can have extended support for more than two control planes. The maximum number of service meshes in a single cluster depends on the available cluster resources.

Procedure

  1. Create the namespace for the first Istio control plane called istio-system-1 by running the following command: 

    $ oc new-project istio-system-1

  2. Label the first namespace, which the Istio discoverySelectors field uses by running the following command: 

    $ oc label namespace istio-system-1 istio-discovery=mesh-1

  3. Create a YAML file named istio-1.yaml with the name mesh-1 and the discoverySelector as mesh-1 similar to the following example: 

    kind: Istio
apiVersion: sailoperator.io/v1
metadata:
  name: mesh-1
spec:
  namespace: istio-system-1
  values:
    meshConfig:
      discoverySelectors:
        - matchLabels:
            istio-discovery: mesh-1
# ...

  4. Create the first Istio resource by running the following command: 

    $ oc apply -f istio-1.yaml

  5. To restrict workloads in mesh-1 from communicating freely with decrypted traffic between meshes, deploy a PeerAuthentication resource to enforce mutual TLS (mTLS) traffic within the mesh-1 data plane. Apply the PeerAuthentication resource in the istio-system-1 namespace by using a configuration file, such as peer-auth-1.yaml, by running the following command: 

    $ oc apply -f peer-auth-1.yaml

    You can see the following example configuration for reference: 

    apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "mesh-1-peerauth"
  namespace: "istio-system-1"
spec:
  mtls:
    mode: STRICT

6.2.2. Deploying the second control plane
Copiar enlace

After deploying the first control plane, you can deploy the second control plane by creating its assigned namespace.

Procedure

  1. Create a namespace for the second Istio control plane called istio-system-2 by running the following command: 

    $ oc new-project istio-system-2

  2. Label the second namespace, which the Istio discoverySelectors field uses by running the following command: 

    $ oc label namespace istio-system-2 istio-discovery=mesh-2

  3. Create a YAML file named istio-2.yaml similar to the following example: 

    kind: Istio
apiVersion: sailoperator.io/v1
metadata:
  name: mesh-2
spec:
  namespace: istio-system-2
  values:
    meshConfig:
      discoverySelectors:
        - matchLabels:
            istio-discovery: mesh-2
# ...

  4. Create the second Istio resource by running the following command: 

    $ oc apply -f istio-2.yaml

  5. Deploy a policy for workloads in the istio-system-2 namespace to only accept mutual TLS traffic peer-auth-2.yaml by running the following command: 

    $ oc apply -f peer-auth-2.yaml

    You can see the following example configuration for reference: 

    apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "mesh-2-peerauth"
  namespace: "istio-system-2"
spec:
  mtls:
    mode: STRICT

6.2.3. Verifying multiple control planes
Copiar enlace

Verify that both Istio control planes deploy and run as expected. You can validate that the istiod pod is successfully running in each Istio system namespace.

Procedure

  1. Verify that the control plane in istio-system-1 manages the workloads by running the following command: 

    $ oc get pods -n istio-system-1

    You should see output similar to the following example: 

    NAME                            READY   STATUS    RESTARTS   AGE
istiod-mesh-1-b69646b6f-kxrwk   1/1     Running   0          4m14s

  2. Verify that the control plane in istio-system-2 manages the workloads by running the following command: 

    $ oc get pods -n istio-system-2

    You should see output similar to the following example: 

    NAME                            READY   STATUS    RESTARTS   AGE
istiod-mesh-2-8666fdfc6-mqp45   1/1     Running   0          118s

6.3. Deploy application workloads in each mesh
Copiar enlace

To deploy application workloads, assign each workload to a separate namespace.

Procedure

  1. Create an application namespace called app-ns-1 by running the following command: 

    $ oc create namespace app-ns-1

  2. To ensure the first control plane discovers the namespace, add the istio-discovery=mesh-1 label by running the following command: 

    $ oc label namespace app-ns-1 istio-discovery=mesh-1

  3. To enable sidecar injection into all the pods by default, while mapping the pods in this namespace to the first control plane, add the istio.io/rev=mesh-1 label to the namespace by running the following command: 

    $ oc label namespace app-ns-1 istio.io/rev=mesh-1

  4. Optional: You can verify the mesh-1 revision name by running the following command: 

    $ oc get istiorevisions

  5. Deploy the sleep and httpbin applications by running the following command: 

    $ oc apply -n app-ns-1 \
   -f https://raw.githubusercontent.com/openshift-service-mesh/istio/release-1.24/samples/sleep/sleep.yaml \
   -f https://raw.githubusercontent.com/openshift-service-mesh/istio/release-1.24/samples/httpbin/httpbin.yaml

  6. Wait for the httpbin and sleep pods to run with sidecars injected by running the following command: 

    $ oc get pods -n app-ns-1

    You should see output similar to the following example: 

    NAME                       READY   STATUS    RESTARTS   AGE
httpbin-7f56dc944b-kpw2x   2/2     Running   0          2m26s
sleep-5577c64d7c-b5wd2     2/2     Running   0          91m

  7. Create a second application namespace called app-ns-2 by running the following command: 

    $ oc create namespace app-ns-2

  8. Create a third application namespace called app-ns-3 by running the following command: 

    $ oc create namespace app-ns-3

  9. Add the label istio-discovery=mesh-2 to both namespaces and the revision label mesh-2 to match the discovery selector of the second control plane by running the following command: 

    $ oc label namespace app-ns-2 app-ns-3 istio-discovery=mesh-2 istio.io/rev=mesh-2

  10. Deploy the sleep and httpbin applications to the app-ns-2 namespace by running the following command: 

    $ oc apply -n app-ns-2 \
   -f https://raw.githubusercontent.com/openshift-service-mesh/istio/release-1.24/samples/sleep/sleep.yaml \
   -f https://raw.githubusercontent.com/openshift-service-mesh/istio/release-1.24/samples/httpbin/httpbin.yaml

  11. Deploy the sleep and httpbin applications to the app-ns-3 namespace by running the following command: 

    $ oc apply -n app-ns-3 \
   -f https://raw.githubusercontent.com/openshift-service-mesh/istio/release-1.24/samples/sleep/sleep.yaml \
   -f https://raw.githubusercontent.com/openshift-service-mesh/istio/release-1.24/samples/httpbin/httpbin.yaml

  12. Optional: Use the following command to wait for a deployment to be available: 

    $ oc wait deployments -n app-ns-2 --all --for condition=Available

Verification

  1. After deploying the applications, use the istioctl ps command to verify that the correct control plane manages each workload:

    1. Verify that the istio-system-1 control plane manages the workloads by running the following command: 

      $ istioctl ps -i istio-system-1

      You should see output similar to the following example: 

      NAME                                  CLUSTER        CDS              LDS              EDS              RDS              ECDS        ISTIOD                            VERSION
httpbin-7f56dc944b-vwfm5.app-ns-1     Kubernetes     SYNCED (11m)     SYNCED (11m)     SYNCED (11m)     SYNCED (11m)     IGNORED     istiod-mesh-1-b69646b6f-kxrwk     1.23.0
sleep-5577c64d7c-d675f.app-ns-1       Kubernetes     SYNCED (11m)     SYNCED (11m)     SYNCED (11m)     SYNCED (11m)     IGNORED     istiod-mesh-1-b69646b6f-kxrwk     1.23.0

    2. Verify that the istio-system-2 control plane manages the workloads by running the following command: 

      $ istioctl ps -i istio-system-2

      You should see output similar to the following example: 

      NAME                                  CLUSTER        CDS                LDS                EDS                RDS                ECDS        ISTIOD                            VERSION
httpbin-7f56dc944b-54gjs.app-ns-3     Kubernetes     SYNCED (3m59s)     SYNCED (3m59s)     SYNCED (3m59s)     SYNCED (3m59s)     IGNORED     istiod-mesh-2-8666fdfc6-mqp45     1.23.0
httpbin-7f56dc944b-gnh72.app-ns-2     Kubernetes     SYNCED (4m1s)      SYNCED (4m1s)      SYNCED (3m59s)     SYNCED (4m1s)      IGNORED     istiod-mesh-2-8666fdfc6-mqp45     1.23.0
sleep-5577c64d7c-k9mxz.app-ns-2       Kubernetes     SYNCED (4m1s)      SYNCED (4m1s)      SYNCED (3m59s)     SYNCED (4m1s)      IGNORED     istiod-mesh-2-8666fdfc6-mqp45     1.23.0
sleep-5577c64d7c-m9hvm.app-ns-3       Kubernetes     SYNCED (4m1s)      SYNCED (4m1s)      SYNCED (3m59s)     SYNCED (4m1s)      IGNORED     istiod-mesh-2-8666fdfc6-mqp45     1.23.0

  2. Verify that the mesh restricts application connectivity to local workloads:

    1. Send a request from the sleep pod in app-ns-1 to the httpbin service in app-ns-2 to check that the communication fails by running the following command: 

      $ oc -n app-ns-1 exec deploy/sleep -c sleep -- curl -sIL http://httpbin.app-ns-2.svc.cluster.local:8000

      The PeerAuthentication resources created earlier enforce mutual TLS (mTLS) traffic in STRICT mode within each mesh. Each mesh uses its own root certificate, managed by the istio-ca-root-cert config map, which prevents communication between meshes. The output indicates a communication failure, similar to the following example:

      You should see output similar to the following example: 

      HTTP/1.1 503 Service Unavailable
content-length: 95
content-type: text/plain
date: Wed, 16 Oct 2024 12:05:37 GMT
server: envoy

    2. Confirm that the communication works by sending a request from the sleep pod to the httpbin service that are present in the app-ns-2 namespace, which mesh-2 manages by running the following command: 

      $ oc -n app-ns-2 exec deploy/sleep -c sleep -- curl -sIL http://httpbin.app-ns-3.svc.cluster.local:8000

      You should see output similar to the following example: 

      HTTP/1.1 200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' camo.githubusercontent.com
content-type: text/html; charset=utf-8
date: Wed, 16 Oct 2024 12:06:30 GMT
x-envoy-upstream-service-time: 8
server: envoy
transfer-encoding: chunked
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba