#Understanding Alauda Service Mesh

Alauda Service Mesh consists of the following components:

• Alauda Service Mesh resources
• Alauda Build of Kiali

The Alauda Build of Kiali includes:

• The Kiali Operator provided by Alauda
• The Kiali Server

Alauda Service Mesh integrates with the following:

• Monitoring:
  • Prometheus
  • VictoriaMetrics
• Distributed Tracing:
  • Alauda Build of Jaeger
  • Alauda Build of OpenTelemetry
• Certificate management:
  • cert-manager
• Progressive delivery:
  • Flagger
  • ArgoCD

#Alauda Service Mesh resources

Alauda Service Mesh v2 Operator manages the lifecycle of Istio control planes by leveraging Istio's Helm chart APIs. Rather than introducing new configuration schemas, the operator exposes existing Istio configuration through custom resources.

#Istio resource

The Istio custom resource defines the desired state of an Istio control plane. As the control plane requires cluster-wide access, this resource is cluster-scoped.

To specify the namespace in which control plane components should run, set the spec.namespace field.

All customization options are exposed through the spec.values field:

Example Istio resource CRD

apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  version: v1.28.3
  namespace: istio-system
  updateStrategy:
    type: InPlace
  values:
    pilot:
      resources:
        requests:
          cpu: 100m
          memory: 1024Mi

To list all available configuration options:

kubectl explain istios.spec.values

To perform canary updates of the control plane, Alauda Service Mesh supports multiple Istio versions. You can set the version field to the new version by either using the full version or the v<x>.<y>-latest alias to automatically select the latest version for a specific minor version. For example, setting v1.23-latest ensures that the Operator maintains the latest version of Istio 1.23.

Alauda Service Mesh supports the following control plane update strategies:

• InPlace: The Alauda Service Mesh v2 Operator immediately replaces your existing control plane resources with the ones for the new version.
• RevisionBased: Uses Istio's canary update mechanism by creating a second control plane to which you can migrate your workloads to complete the update.

When an Istio resource is created, the operator generates a unique revision name based on the updateStrategy and automatically creates an associated IstioRevision resource.

#IstioRevision resource

The IstioRevision resource represents a specific versioned instance of the Istio control plane. It is automatically created by the operator and is not typically managed directly by users.

A revision of the control plane you want to be present in your cluster is an instance of Istio with a specific version and revision name, and its revision name can be used to add workloads or entire namespaces to the mesh. Revision labels (e.g., istio.io/rev=revision-name) are used to associate workloads and namespaces with a specific control plane revision.

This resource is analogous to the relationship between a Kubernetes ReplicaSet and its Pods: the user defines the desired control plane through the Istio resource, and the operator generates the corresponding IstioRevision.

Similarly, users create an Istio resource which instructs the Alauda Service Mesh v2 Operator to create a matching IstioRevision resource, which then in turn triggers the creation of the Istio control plane. To do that, the Alauda Service Mesh v2 Operator will copy all of your relevant configuration from the Istio resource to the IstioRevision resource.

#IstioRevisionTag resource

The IstioRevisionTag resource represents a stable revision tag that functions as an alias for Istio control plane revisions. With the stable tag, prod, you can use the label istio.io/rev=prod to inject proxies into your workloads. When you perform an upgrade to a control plane with a new revision name, you can update your tag to point to the new revision instead of having to relabel your workloads and namespaces. For more information, see Stable revision labels (Istio documentation).

You can use the IstioRevisionTag resource with the Alauda Service Mesh v2 Operator. Therefore you can reference both an IstioRevision and an Istio resource. When using an Istio resource, after you update your control plane, the underlying IstioRevision resource changes, and the Alauda Service Mesh v2 Operator automatically updates your revision tag. You only need to restart your deployments to re-inject the new proxies.

The IstioRevisionTag has one field in its spec: field, targetRef, which can reference an Istio or IstioRevision resource. After deploying the IstioRevisionTag, you can use both the istio.io/rev=default and istio-injection=enabled labels to inject proxies into your workloads.

The istio-injection label can only be used for revisions and revision tags that have the name default, like the IstioRevisionTag resource in the following example:

Example IstioRevisionTag resource

apiVersion: sailoperator.io/v1
kind: IstioRevisionTag
metadata:
  name: default
spec:
  targetRef:
    kind: Istio
    name: default

#IstioCNI resource

The lifecycle of Istio's Container Network Interface (CNI) plugin is managed separately when using Alauda Service Mesh v2 Operator. To install Istio's CNI plugin, you create an IstioCNI resource.

The IstioCNI resource is a cluster-wide resource as it installs a daemon set that operates on all nodes of your cluster. You can select a version by setting the spec.version field, as you can see in the example that follows.

Example IstioCNI resource

apiVersion: sailoperator.io/v1
kind: IstioCNI
metadata:
  name: default
spec:
  version: v1.28.3
  namespace: istio-cni
  values:
    cni:
      cniConfDir: /etc/cni/multus/net.d # /etc/cni/net.d in ACP 4.0
      excludeNamespaces:
        - istio-cni
        - kube-system

To upgrade the plugin, update the spec.version field.

#Alauda Build of Kiali

Alauda Build of Kiali is based on the Kiali open source project and provides a user-friendly web-based observability interface for Alauda Service Mesh.

#Components

• Kiali Operator: Installs and manages the Kiali Server.
• Kiali Server: Interacts with service mesh components, processes telemetry data, and serves the Kiali console.

#Integration and Dependencies

• Istio: Required. Kiali queries Istio CRDs and telemetry to render the mesh state.
• Prometheus: Required. Used for metrics and mesh topology visualization.
• Alauda Container Platform API: Used to query and resolve relationships among cluster resources (e.g., services, workloads).
• Jaeger and OpenTelemetry: Optional. Enables tracing views in the Kiali console.
• Grafana: Optional. If installed, metrics pages in Kiali link to equivalent Grafana dashboards. Note: Grafana is not officially supported by Alauda Service Mesh.

#Architecture

• Kiali Server: Backend service that queries Prometheus and cluster APIs.
• Kiali Console: Frontend interface that displays telemetry data retrieved by the server.

#Features

• Health: Identifies degraded or unhealthy services, workloads, and applications.
• Topology: Visualizes service interactions and traffic flows in near real time.
• Metrics: Includes default dashboards for supported runtimes (e.g., Go, Node.js, Spring Boot).
• Tracing: Displays trace spans using Jaeger integration.
• Validation: Checks for misconfigurations in Istio resources.
• Configuration: Enables optional creation and editing of routing configurations via a UI wizard or YAML editor.

#Observability in Alauda Service Mesh

#Monitoring

Prometheus or VictoriaMetrics can be deployed to monitor applications participating in the mesh. These components collect metrics related to resource usage, service health, and network behavior.

Custom alerts and dashboards can be configured to observe CPU, memory, and networking characteristics of workloads.

#Distributed Tracing

Alauda Service Mesh supports distributed tracing through integration with:

• Alauda Build of Jaeger Based on the Jaeger project, this component visualizes end-to-end request flows and latency across microservices.

• Alauda Build of OpenTelemetry Based on the OpenTelemetry project, this component simplifies telemetry data collection and forwarding.

The OpenTelemetry Collector supports data ingestion in multiple formats, processes telemetry data (traces, metrics, logs), and forwards them to storage or visualization backends. See the OpenTelemetry Collector documentation for more details.

Tracing views in Kiali are enabled when tracing features are configured and the user has access to the relevant namespaces.