Skip to content

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.


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 sidecars enabled)

Important

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

apiVersion: infra.k8smgmt.io/v3
kind: Namespace
metadata:
name: foo
project: demo-service-mesh
spec:
limitRange:
    container: {}
    pod: {}
namespaceMeshPolicyParams:
    meshEnabled: true
placement:
    labels:
    - key: rafay.dev/clusterName
    value: demo-cluster
resourceQuotas: {}

Spec for legacy namespaces (with sidecars not enabled)

Important

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

apiVersion: infra.k8smgmt.io/v3
kind: Namespace
metadata:
name: legacy
project: demo-service-mesh
spec:
limitRange:
    container: {}
    pod: {}
namespaceMeshPolicyParams:
    meshEnabled: false
placement:
    labels:
    - key: rafay.dev/clusterName
    value: demo-eks-cluster-service-mesh
resourceQuotas: {}
  • Type the command below to create the new namespaces
rctl create ns -f <path-to-filename>.yaml
  • Type the command below to verify creation of the namespaces
rctl get ns -v <namespace_name>

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-service-mesh
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.sm-foo:8000/ip
          curl http://httpbin.sm-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-service-mesh
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 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.