Part 2: Service Mesh Visibility

What Will You Do¶

In this part of the self-paced exercise, you will deploy a test application and view the service mesh visualization for that application.

Web ConsoleRCTL

Create Namespaces¶

You will create three namespaces - foo, bar and legacy. You will enable sidecars for two of the namespaces (for foo and bar) but not for the legacy namespace.

Navigate to the Namespaces page
Create a new namespace, specify the name (e.g. foo) and select type as Wizard

Namespace Creation

In the Configuration section, navigate to Service Mesh Policies and select Enable Sidecar Injection (Skip this step for legacy namespace)

Sidecar Injection

In the placement section, select the cluster that you want to deploy the namespace to

Namespace Creation

Click Save & Go to Publish
Publish the namespace

Repeat the process to create bar and legacy namespaces. Make sure that you don't enable sidecar injection for legacy namespace.

Deploy the test application¶

Deploy httpbin application to foo and bar namespaces¶

Navigate to the Workloads page
Create a new Workload, specify the name (e.g. foo-httpbin) and Package type as yaml
Select Upload files manually as the Artifact Sync option
Select the namespace (e.g. foo) from the dropdown menu
Select continue
Upload the httpbin.yaml file
Click Save and Go to Placement
Select the cluster that you want to deploy the workload to, Click Save and Go to Publish
Click Publish

Follow the same process to deploy httpbin to bar namespace (name the workload as bar-httpbin).

Below is the httpbin YAML file that you will deploy to foo and bar namespaces.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80
---

Deploy sleep application to foo, bar and legacy namespaces¶

Navigate to the Workloads page
Create a new Workload, specify the name (e.g. foo-sleep) and Package type as yaml
Select Upload files manually as the Artifact Sync option
Select the namespace (e.g. foo) from the dropdown menu
Select continue
Upload the sleep.yaml file
Click Save and Go to Placement
Select the cluster that you want to deploy the workload to, Click Save and Go to Publish
Click Publish

Follow the same process to deploy sleep to bar and legacy namespaces (name the workloads as bar-sleep and legacy-sleep).

Below is the sleep YAML file that you will deploy to foo, bar and legacy namespaces.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command:
        - sh
        - "-c"
        - |
          while true
          do
          sleep 3
          curl http://httpbin.foo:8000/ip
          curl http://httpbin.bar:8000/ip
          done
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

Create Namespaces¶

You can alternatively create a namespace by using the declarative spec YAML. For more information on automation via RCTL CLI, refer here.

You will create three namespaces - foo, bar and legacy. You will enable sidecars for two of the namespaces (for foo and bar) but not for the legacy namespace.

Spec for foo and bar namespaces (with sidecar injection enabled)¶

Important

Ensure that you update the "value: demo-cluster" with the name of the cluster in your project

kind: ManagedNamespace
apiVersion: config.rafay.dev/v2
metadata:
  name: foo
spec:
  type: RafayWizard
  namespaceMeshPolicyParams:
    meshEnabled: true
  placement:
    placementType: ClusterSpecific
    clusterLabels:
    - key: rafay.dev/clusterName
      value: demo-cluster

Spec for legacy namespace (with sidecar injection not enabled)¶

Important

Ensure that you update the "value: demo-cluster" with the name of the cluster that you are working with

kind: ManagedNamespace
apiVersion: config.rafay.dev/v2
metadata:
  name: legacy
spec:
  type: RafayWizard
  namespaceMeshPolicyParams:
    meshEnabled: false
  placement:
    placementType: ClusterSpecific
    clusterLabels:
    - key: rafay.dev/clusterName
      value: demo-cluster

Type the command below to create the new namespaces

rctl create ns -f <path-to-filename>.yaml

Type the command below to publish the new namespaces

rctl publish ns <namespace_name>

Type the command below to verify creation of the namespaces

rctl get namespace

Deploy the test applications¶

Deploy httpbin application to foo and bar namespaces¶

Below is the httpbin YAML file that you will deploy to foo and bar namespaces.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80
---

You can deploy the test application by using the declarative spec YAML. For more information on automation via RCTL CLI, refer here

name: foo-httpbin
namespace: foo
project: defaultproject
type: NativeYaml
clusters: demo-cluster
payload: <path-to-filename>.yaml

Type the command below to create the workload

rctl create workload <path-to-filename>.yaml

If there were no errors, you should see a message like below

Workload created successfully

Type the command below to publish the workload

rctl publish workload foo-httpbin

In the web console, click on Applications -> Workloads. You should see the workload deployment status as In Progress. After a few minutes, you will see the workload deployment status as Ready

Follow the same process to deploy httpbin to bar namespace (name the workload as bar-httpbin).

Deploy sleep application to foo, bar and legacy namespaces¶

Below is the sleep YAML file that you will deploy to foo, bar and legacy namespaces.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sleep
---
apiVersion: v1
kind: Service
metadata:
  name: sleep
  labels:
    app: sleep
    service: sleep
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: sleep
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      terminationGracePeriodSeconds: 0
      serviceAccountName: sleep
      containers:
      - name: sleep
        image: curlimages/curl
        command:
        - sh
        - "-c"
        - |
          while true
          do
          sleep 3
          curl http://httpbin.foo:8000/ip
          curl http://httpbin.bar:8000/ip
          done
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /etc/sleep/tls
          name: secret-volume
      volumes:
      - name: secret-volume
        secret:
          secretName: sleep-secret
          optional: true
---

You can deploy the test application by using the declarative spec YAML. For more information on automation via RCTL CLI, refer here

name: foo-sleep
namespace: foo
project: defaultproject
type: NativeYaml
clusters: demo-cluster
payload: <path-to-filename>.yaml

Type the command below to create the workload

rctl create workload <path-to-filename>.yaml

If there were no errors, you should see a message like below

Workload created successfully

Type the command below to publish the workload

rctl publish workload foo-sleep

In the web console, click on Applications -> Workloads. You should see the workload deployment status as In Progress. After a few minutes, you will see the workload deployment status as Ready

Follow the same process to deploy sleep application to bar and legacy namespaces (name the workloads as bar-sleep and legacy-sleep).

Service Mesh Visibility¶

Click Home
Select Dashboards -> Service Mesh
Select the project and cluster from the dropdown menu
Select foo, bar and legacy namespaces from the namespace dropdown menu
You will see the dashboard populate with foo, bar and legacy namespaces with edges between them to represent traffic flows.

Service Mesh Visibility Dashboard

Important

Note that the legacy namespace and the sleep application running in that namespace are represented as unknown as we did not enable sidecar injection for legacy namespace

Using the Display option provided within the dashboard, enable Security via the dropdown.

Service Mesh Visibility Dashboard

The visualization now shows lock icons on the edges between foo and bar. This is because we enabled sidecars on these namespaces and Istio installs mTLS in permissive mode i.e., namespaces will use mutual TLS wherever possible but do not restrict non-encrypted communication.

Show TLS

Recap¶

Congratulations! At this point, you have successfully deployed the test application and are able to view Service Mesh flows for the application.