Module 3: Platform operations (operating at scale)

This is integrated directly into the OpenShift console. No separate tool to access.

"The Service Mesh console is built into OpenShift. The platform engineer does not need a separate dashboard. Everything is accessible from the same console."

Point out the health indicators (green for healthy). Some namespaces are enrolled in the mesh, some are not (indicated by the presence of "istio config" field).

"All services enrolled in the mesh get mutual TLS encryption automatically. The developers did not write a single line of TLS code. The mesh handles certificate generation, rotation, and validation automatically. This satisfies the compliance requirement for encryption in transit."

Point out the production namespace with its services

"Here is the Parasol application’s production namespace. The platform manages communication between all services automatically."

Show the traffic policy creation form.

"This is where the platform engineer can define traffic routing policies — canary deployments, traffic splits, rate limiting, circuit breakers — all without touching application code. The mesh applies these policies at the infrastructure level."

"For example, if Parasol wants to roll out a new version to 10% of traffic first, the platform engineer configures it here. No code changes, no redeployments, just a policy change."

"Service Mesh also supports authorization policies that control which services can communicate with each other. This is the principle of least privilege applied to service-to-service communication. Only authorized services can make requests. This is configured by the platform team, not the developers."

On the Display menu, enable Traffic Animation, and set the refresh rate to 10 seconds at the upper right.

Show the service graph with animated traffic flow between the Parasol services

"This is a live traffic graph. The lines represent actual requests flowing between services right now. The animation shows the direction and volume of traffic."

Point out the service nodes and the connections between them

Figure 2. Service Mesh Traffic Graph with animated traffic flow between services

Green nodes indicate healthy services

Point out request success rate indicators on the connections

"At a glance, the platform engineer can see that both services are healthy and traffic is flowing normally. If a service starts failing, the node turns yellow or red immediately. No need to dig through logs to discover a problem."

Show the side panel with service details

Point out key metrics (not all are shown all the time)

"The platform engineer can see exactly how each service is performing. If latency spikes or error rates increase, they know immediately which service is affected and can drill in further."

Navigate to the detail view for one of the Parasol services

Show the inbound and outbound traffic metrics

Show the traffic breakdown by response code (200, 400, 500, etc.) (note: these aren’t shown in ambient mode)

"This is the level of detail you get without adding a single line of instrumentation to the application. The mesh collects all of this automatically."

Toggle different graph layouts (app graph, versioned app graph, workload graph)

Show how the graph adapts to show different perspectives

"Platform engineers can view traffic by application, by workload, or by version. During a canary deployment, for example, you can see traffic split between the old and new versions in real time."

In the traffic graph, click on the parasol-insurance service node (the triangle icon)

Click the three-dot menu on the right side panel and select Fault Injection

Select Add HTTP Abort and set the Abort Percentage to 5

Click Preview to see the new DestinationRule that will be applied, then click Create to inject the fault, and confirm the creation by clicking Create again.

"The platform engineer just injected a 5% failure rate into the Parasol service — without touching any application code. This is useful for testing how applications behave when facing network failures. You can also inject latency, timeouts, and other fault conditions to simulate real-world degradation."

Watch the traffic graph animation — error percentages start rising and the service node turns yellow, signaling to the platform engineer that something needs investigation

"Notice the service turned yellow and the error rate is climbing. In a real scenario, this is exactly what the platform engineer would see if a downstream service started failing. The mesh gives immediate, visual feedback — no need to dig through logs."

After demonstrating, remove the fault injection by clicking the three-dot menu again, selecting Delete Traffic Routing, and confirming

Navigate to Observe → Metrics in the OpenShift web console

Show CPU and memory utilization metrics for the Parasol workloads

"Beyond service mesh observability, the platform provides workload-level monitoring out of the box. CPU usage, memory consumption, network throughput — all available without any additional tooling."

Show the aggregate dashboard with CPU, memory, and network metrics

"These dashboards can be customized for specific teams or applications. Platform engineers can build views that aggregate metrics across all Parasol services, or drill down into individual workloads."

"The platform also supports custom alerts. Platform engineers can define thresholds — for example, alert if CPU exceeds 80% for 5 minutes, or if memory usage trends upward consistently. These alerts catch misbehaving applications before they impact customers."

Navigate to Workloads → HorizontalPodAutoscalers in the parasol-insurance-prod namespace

Click on parasol-insurance-hpa to show the configuration: min 2, max 5, CPU target 10%

"The platform engineer configured this HPA in the GitOps manifests. It is managed as code alongside the deployment, reviewed through merge requests, and managed by OpenShift GitOps. The platform automatically adjusts the number of replicas based on CPU utilization."

Open the Web Terminal using the >_ icon at the top of the OpenShift Console (if this is the first time you’ve run it, just accept defaults and click Start Terminal)

Run the following command in the terminal to create a load generator pod that continuously sends requests to the Parasol application, driving up CPU utilization:

oc run load-generator --image=quay.io/curl/curl:latest \
  -n parasol-insurance-prod --restart=Never -- /bin/sh -c \
  "while true; do curl -s -o /dev/null http://parasol-insurance.parasol-insurance-prod.svc:8080/api/claims; done"

"This generates continuous traffic to the Parasol application, driving up CPU utilization."

The blue donut shows scaling activity as new replicas are added

Show the HPA status: Workloads → HorizontalPodAutoscalers to see current vs. target CPU and replica count

"The platform detected the increased CPU utilization and automatically added replicas. No human intervention required. The application continues to serve traffic while scaling."

"After removing the load, the HPA will gradually scale back down to the minimum. The platform optimizes resource usage automatically."

"What we just showed is horizontal pod autoscaling — adding more replicas. But OpenShift provides several other autoscaling strategies:"

"Vertical Pod Autoscaler adjusts CPU and memory for individual pods based on observed usage. Instead of adding more replicas, it right-sizes each pod. This is suited for stateful workloads, or workloads that need more resources per instance rather than more instances."

"Cluster Autoscaler and Machine Autoscaler scale the cluster itself. If pods cannot be scheduled because the cluster is full, the platform automatically provisions new worker nodes. When demand drops, it removes them. The infrastructure grows and shrinks with demand."

"KEDA, the event-driven autoscaler, scales based on external event sources. For example, Parasol’s email processing could scale based on the Kafka topic queue depth. If thousands of emails arrive at once, KEDA spins up more consumers to process them faster, then scales back to zero when the queue is empty."

In the Vault UI, select Secrets at the top and then navigate to the kv (key/value) folder then to the secrets/ path

Show the secrets organized by application and purpose (e.g. parasol-insurance/, gitlab/, kafka/, quay/)

"All secrets are stored centrally in Vault, organized by application and purpose. The developer never sees these values in their code or manifests."

Figure 7. Secrets managed centrally in Vault

In the OpenShift Console, navigate to Workloads > Secrets, select the parasol-insurance-prod application namespace, and click on a secret such as kafka-credentials, then Reveal Values

This Secret was created by the External Secrets Operator based on the ExternalSecret created as part of the Argo CD deployment.

Click on the "Owner" link to show the ExternalSecret.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: kafka-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-secret-store
    kind: ClusterSecretStore
  target:
    name: kafka-credentials
    creationPolicy: Owner
  data:
    - secretKey: password
      remoteRef:
        key: secrets/kafka/user
        property: password

"The External Secret references a path in Vault, not the actual secret value. The External Secrets Operator syncs the value at runtime."

Point out that the secret exists in the cluster but was never committed to Git

"The operator automatically created this Kubernetes secret from the Vault data. The application consumes it like any normal secret. But the actual values never appear in source control."

"When the platform team rotates a secret in Vault, the External Secrets Operator syncs the new value automatically based on the refresh interval. No application restart required, no manual update. And every access to every secret is audited in Vault’s audit log."