#Alauda Build of Kiali

#Using Alauda Build of Kiali

The Alauda Build of Kiali provides observability and visualization capabilities for applications deployed within the service mesh. After adding an application to the mesh, the Alauda Build of Kiali can be used to inspect traffic flow and monitor mesh behavior.

#About Kiali

The Alauda Build of Kiali is derived from the open source Kiali project and serves as the management console for Alauda Service Mesh.

It provides:

• Visualization of mesh topology and real-time traffic flow
• Insight into application health status and performance metrics
• Centralized access to configuration and validation tools
• Integration with Grafana for metric dashboards
• Support for distributed tracing via Jaeger or OpenTelemetry

These capabilities enable users to diagnose service behavior, identify potential issues, and optimize mesh configuration from a unified interface.

#Installing Alauda Build of Kiali

The following steps show how to install Alauda Build of Kiali.

Prerequisites

• You are logged in to the Alauda Container Platform web console as cluster-admin.

Procedure

1. In the Alauda Container Platform web console, navigate to Administrator.
2. Select Marketplace > OperatorHub.
3. Search for the Alauda Build of Kiali.
4. Locate the Alauda Build of Kiali, and click to select it.
5. Click Install.
6. Click Install and Confirm to install the Operator.

Verification

Verify that the Operator installation status is reported as Succeeded in the Installation Info section.

#Configuring Monitoring with Kiali

The following steps show how to integrate the Alauda Build of Kiali with user-workload monitoring.

Prerequisites

• Alauda Service Mesh is installed.
• Monitoring has been configured with Service Mesh. See Configuring Monitoring with Service Mesh.
• Alauda Build of Kiali is installed.

Procedure

# CA certificate for ACP - base64-encoded
kubectl -ncpaas-system get secret dex.tls -o jsonpath='{.data.ca\.crt}'

export PLATFORM_URL=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.platformURL}')
export CLUSTER_NAME=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.clusterName}')
export ALB_CLASS_NAME=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.systemAlbIngressClassName}')

export OIDC_ISSUER=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.oidcIssuer}')
export OIDC_CLIENT_ID=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.oidcClientID}')
export OIDC_CLIENT_SECRET=$(kubectl -nkube-public get configmap global-info -o jsonpath='{.data.oidcClientSecret}')

export MONITORING_URL=$(kubectl get feature monitoring -o jsonpath='{.spec.accessInfo.database.address}')

kubectl create secret generic kiali --from-literal="oidc-secret=$OIDC_CLIENT_SECRET" -nistio-system

secret/kiali created

SECRET_NAME=$(kubectl get feature monitoring -o jsonpath='{.spec.accessInfo.database.basicAuth.secretName}')

AUTH_USERNAME=$(kubectl -ncpaas-system get secret "$SECRET_NAME" -o jsonpath="{.data.username}" | base64 -d)
AUTH_PASSWORD=$(kubectl -ncpaas-system get secret "$SECRET_NAME" -o jsonpath="{.data.password}" | base64 -d)

kubectl create secret generic "kiali-monitoring-basic-auth" \
  --from-literal="username=$AUTH_USERNAME" \
  --from-literal="password=$AUTH_PASSWORD" \
  -n istio-system

secret/kiali-monitoring-basic-auth created

apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  name: kiali
  namespace: istio-system
spec:
  server:
    web_port: "443"
    web_root: /clusters/${CLUSTER_NAME}/kiali
  auth:
    openid:
      api_proxy: ${PLATFORM_URL}/kubernetes/${CLUSTER_NAME}
      api_proxy_ca_data: ${PLATFORM_CA}
      insecure_skip_verify_tls: true
      issuer_uri: ${OIDC_ISSUER}
      client_id: ${OIDC_CLIENT_ID}
      username_claim: email
    strategy: openid
  deployment:
    view_only_mode: false
    replicas: 1
    resources:
      requests:
        cpu: "100m"
        memory: "64Mi"
      limits:
        memory: "1Gi"
    ingress:
      enabled: true
      class_name: ${ALB_CLASS_NAME}
  external_services:
    grafana:
      enabled: false  # Since Grafana is not bundled in ACP anymore, it is disabled by default
    prometheus:
      # query_scope only required in multi cluster
      query_scope:
        mesh_id: <mesh_id>
      auth:
        type: basic
        username: secret:kiali-monitoring-basic-auth:username
        password: secret:kiali-monitoring-basic-auth:password
        insecure_skip_verify: true
      # Define thanos_proxy if Prometheus is to be queried through a Thanos proxy (it is required when using VictoriaMetrics)
      thanos_proxy:
        enabled: true
        retention_period: 7d
        scrape_interval: 60s
      url: ${MONITORING_URL}
  kiali_feature_flags:
    ui_defaults:
      i18n:
        language: en
        show_selector: true

# Replace <platform-ca> with the real base64-encoded CA certificate saved previously.
export PLATFORM_CA=<platform-ca>

envsubst < kiali.yaml | kubectl apply -f -

#Integrating distributed tracing platform with Alauda Build of Kiali

After integration with a distributed tracing platform, the Alauda Build of Kiali enables visualization of request traces directly in the Kiali console. These traces provide insight into inter-service communication within the service mesh and can help identify latency, failures, or bottlenecks in request paths.

This capability supports the analysis of request flow behavior, aiding in root cause identification and performance optimization across services in the mesh.

Prerequisites

• Alauda Service Mesh is installed.
• Distributed tracing platform such as Alauda Build of Jaeger is installed and successfully configured.

Procedure

1. Update the Kiali resource spec configuration for tracing:

   Example Kiali resource spec configuration for tracing

   spec:
     external_services:
       tracing:
         # query_scope only required in multi cluster
         query_scope:
           istio.mesh_id: <mesh_id>
         enabled: true
         provider: jaeger
         use_grpc: true
         internal_url: "http://jaeger-prod-query.istio-system:16685/jaeger"
         # (Optional) Public facing URL of Jaeger
         # external_url: "<platform-url>/clusters/<cluster>/istio/jaeger"
         # When external_url is not defined, disable_version_check should be set to true
         disable_version_check: true
   1. Required in multi cluster mesh. <mesh_id> should be the same as the .spec.values.global.meshId in Istio resource.
   2. Specifies whether tracing is enabled.
   3. Specifies the tracing provider (jaeger or tempo).
   4. Specifies the internal URL for the Jaeger or Tempo API.

2. Save the updated spec in kiali_cr.yaml.

3. Run the following command to apply the configuration:

   kubectl -nistio-system patch kiali kiali --type merge -p "$(cat kiali_cr.yaml)"

   Example output:

   kiali.kiali.io/kiali patched

Verification

1. Navigate to the Kiali UI.
2. Navigate to Workload Traces tab to see traces in the Kiali UI.