Prepare the mesh for network topology

To successfully onboard non-Kubernetes workloads like VMs, the Service Mesh pilot must first be configured to understand and integrate these external network topologies.

Prerequisites:

• Red Hat OpenShift Container Platform (OCP) 4.16 or higher
• Red Hat OpenShift Service Mesh (OSSM) 3.x
• Red Hat OpenShift Virtualization

In this lesson, you will:

• Configure and deploy Red Hat Service Mesh.

Configure your service mesh

For this specific use case, we will configure the required values centrally. While you are free to adjust the naming conventions to align with your environment, we will use the following conventions throughout this guide.

Key configuration steps:

1. Enable external control plane connectivity: This step tells the mesh that it should expect and manage workloads that are not running directly inside the cluster's Kubernetes environment.
2. Define a central location (Cluster ID): We will designate a central identifier for the service mesh instance. This is crucial for the legacy workloads to correctly locate and join the mesh's control plane.

By configuring the pilot to recognize these external structures, you ensure that the VM can receive configuration, policies, and security credentials necessary to participate in the service mesh's zero trust environment.

The mandatory values to configure are (replacing ‘corporate’ with your own values if so desired):

values:
  global:
    meshID: corporate
    multiCluster:
      clusterName: corporate
    network: corporate

The complete Red Hat Service Mesh deployment can be deployed by executing the following steps.

To activate the subscription for OSSM and ensure there are no service gaps: 

cat <<'EOF' | oc create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  labels:
    operators.coreos.com/servicemeshoperator3.openshift-operators: ''
  name: servicemeshoperator3
  namespace: openshift-operators
spec:
  channel: stable
  config:
    annotations:
      openshift.io/required-scc: restricted-v2
      target.workload.openshift.io/management: '{"effect": "PreferredDuringScheduling"}'
    resources:
      requests:
        cpu: 10m
        memory: 64Mi
  installPlanApproval: Automatic
  name: servicemeshoperator3
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: servicemeshoperator3.v3.1.0
EOF 

To create the istio-system namespace necessary for our walkthrough to reference: 

cat <<'EOF' | oc create -f - 
apiVersion: v1
kind: Namespace
metadata:
  labels:
    istio.io/rev: default
    topology.istio.io/network: corporate
  name: istio-system
EOF

To implement the Istio version:

cat <<'EOF' | oc create -f -
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  namespace: istio-system
  updateStrategy:
    inactiveRevisionDeletionGracePeriodSeconds: 30
    type: InPlace
  values:
    global:
      configCluster: true
      istioNamespace: istio-system
      logAsJson: true
      logging:
        level: http:debug,http2:debug,router:debug
      meshID: corporate
      multiCluster:
        clusterName: corporate
      network: corporate
      platform: openshift
      defaultConfig:
        meshId: corporate
      discoverySelectors:
        - matchExpressions:
            - key: maistra.io/member-of
              operator: DoesNotExist
            - key: istio.io/rev
              operator: Exists
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
  version: v1.26-latest
EOF

Deploy an East-West gateway for external access

To integrate non-Kubernetes workloads like your VMs securely, the service mesh requires a dedicated gateway to manage and route traffic flow between the mesh and external resources. This is commonly referred to as the East-West gateway. The East-West gateway serves a critical function. It acts as the secure entry point for all traffic destined for services that exist outside the primary Kubernetes cluster—a category that includes the legacy VM you are preparing to onboard.

Key deployment focus

External resource routing: This gateway ensures that when a service within the mesh attempts to communicate with the VM, the traffic is correctly directed and managed by the mesh policies, like TLS and mutual authentication.

Virtual machine classification: By routing VM-bound traffic through this gateway, we formally classify the VM as an external resource that must abide by the mesh's security and routing protocols.

You will need to deploy a standard Istio Gateway object, configuring it specifically for East-West traffic. This typically involves ensuring it is reachable by the external workloads and correctly configured to handle cross-cluster or cross-environment communication.

To align with the established service mesh topology and ensure secure external connectivity, the next crucial step is to deploy the East-West gateway. 

To deploy the East-West gateway, execute the following steps:

1. Create a service account:

   cat <<'EOF' | oc create -f -  
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     annotations:
       argocd.argoproj.io/sync-wave: "5"
     name: istio-eastwestgateway-service-account
     namespace: istio-system

2. Create the necessary role and role-binding for the service account:

   cat <<'EOF' | oc create -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     annotations:
       argocd.argoproj.io/sync-wave: "10"
     name: istio-eastwestgateway-sds
     namespace: istio-system
   rules:
     - apiGroups:
         - ""
       resources:
         - secrets
       verbs:
         - get
         - watch
         - list
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       argocd.argoproj.io/sync-wave: "10"
     name: istio-eastwestgateway-sds
     namespace: istio-system
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: istio-eastwestgateway-sds
   subjects:
     - kind: ServiceAccount
       name: istio-eastwestgateway-service-account
   EOF

3. Create the East-West gateway deployment:

   cat <<'EOF' | oc create -f -
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     annotations:
       argocd.argoproj.io/sync-wave: "20"
     name: istio-eastwestgateway
     labels:
       istio: eastwestgateway
       app: istio-eastwestgateway
   spec:
     selector:
       matchLabels:
         istio: eastwestgateway
         topology.istio.io/network: corporate
     template:
       metadata:
         annotations:
           inject.istio.io/templates: gateway
         labels:
           istio: eastwestgateway
           sidecar.istio.io/inject: "true"
           topology.istio.io/network: corporate
       spec:
         containers:
         - name: istio-proxy
           image: auto
           env:
           - name: ISTIO_META_REQUESTED_NETWORK_VIEW
             value: corporate
   EOF

4. Create a service for the East-West gateway deployment:

   cat <<'EOF' | oc create -f -
   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       argocd.argoproj.io/sync-wave: "20"
     name: istio-eastwestgateway
     namespace: istio-system
   spec:
     ports:
       - name: status-port
         port: 15021
         protocol: TCP
         targetPort: 15021
       - name: tls
         port: 15443
         protocol: TCP
         targetPort: 15443
       - name: tls-istiod
         port: 15012
         protocol: TCP
         targetPort: 15012
       - name: tls-webhook
         port: 15017
         protocol: TCP
         targetPort: 15017
     selector:
       istio: eastwestgateway
       topology.istio.io/network: corporate
     type: LoadBalancer
   EOF

5. Create an East-West gateway configuration for workload traffic:

   cat <<'EOF' | oc create -f -
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     annotations:
       argocd.argoproj.io/sync-wave: "20"
     name: istio-eastwestgateway
   spec:
     selector:
       app: istio-eastwestgateway
       istio: eastwestgateway
       topology.istio.io/network: corporate
     servers:
     - port:
         number: 15443
         name: tls
         protocol: TLS
       hosts:
       - "*.local"
       tls:
         mode: AUTO_PASSTHROUGH
   EOF

Next, we will prepare the environment into which our VM will be deployed.