-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathllms.txt
More file actions
114 lines (95 loc) · 42.5 KB
/
Copy pathllms.txt
File metadata and controls
114 lines (95 loc) · 42.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
# Alauda Service Mesh v2 Documentation
> User-facing documentation for Alauda Service Mesh v2 — installation, configuration, gateways, ambient mode, multi-cluster, upgrades, integrations, and APIs.
Documentation for installing, operating, and integrating with Alauda Service Mesh v2.
Content is organized into about, installing, gateways, updating, integration, apis, and uninstalling sections,
with coverage of sidecar mode, ambient mode, multi-cluster, high availability, observability (Kiali), and Kubernetes APIs.
## Root
- [docs/en/index.mdx](docs/en/index.mdx): Top-level documentation entry point that renders the navigation overview for the Alauda Service Mesh v2 docs site via the `<Overview>` component.
## about
- [docs/en/about/about/about-service-mesh.mdx](docs/en/about/about/about-service-mesh.mdx): Introduces Alauda Service Mesh as an Istio-based control plane for microservices, summarizing the four core capability areas: traffic management (routing, retries, failover, fault injection), service identity and security via mutual TLS, policy enforcement (access control, rate limiting, quotas), and telemetry/observability through metrics, logs, and traces.
- [docs/en/about/about/index.mdx](docs/en/about/about/index.mdx): Landing page for the About section, surfacing the overview of Alauda Service Mesh features via the `<Overview>` component.
- [docs/en/about/about/understanding-service-mesh.mdx](docs/en/about/about/understanding-service-mesh.mdx): Catalogs the components shipped by Alauda Service Mesh and Alauda Build of Kiali, then explains each CRD exposed by the v2 Operator (`Istio`, `IstioRevision`, `IstioRevisionTag`, `IstioCNI`) with example YAML, the `InPlace` vs `RevisionBased` update strategies, the `spec.values` passthrough to Istio Helm chart options, and the Kiali architecture plus integrations with Prometheus/VictoriaMetrics, Alauda Build of Jaeger, Alauda Build of OpenTelemetry, cert-manager, Flagger, and ArgoCD.
- [docs/en/about/index.mdx](docs/en/about/index.mdx): Top-level About section index, rendering an overview of conceptual material covering Alauda Service Mesh features, lifecycle policies, and release notes.
- [docs/en/about/lifecycle-policy/alauda-build-of-kiali.mdx](docs/en/about/lifecycle-policy/alauda-build-of-kiali.mdx): Tabulates release dates and end-of-support windows for the Alauda Build of Kiali operator (v2.11.z, v2.17.z, v2.22.z), and states the 4-month release cadence plus the 18-month maintenance commitment covering patches, security updates, and upgrade assistance.
- [docs/en/about/lifecycle-policy/alauda-service-mesh.mdx](docs/en/about/lifecycle-policy/alauda-service-mesh.mdx): Tabulates release dates and end-of-support windows for the Alauda Service Mesh v2 operator (v2.0.z, v2.1.z), and states the 4-month release cadence plus the 24-month maintenance commitment covering patches, security updates, and upgrade assistance.
- [docs/en/about/lifecycle-policy/index.mdx](docs/en/about/lifecycle-policy/index.mdx): Section landing page for lifecycle policies, surfacing entries that document support windows and release cadence for the Alauda Service Mesh and Alauda Build of Kiali operators.
- [docs/en/about/release-notes/alauda-service-mesh-v2.0.mdx](docs/en/about/release-notes/alauda-service-mesh-v2.0.mdx): Announces Alauda Service Mesh v2.0 built on a Sail-Operator-derived Istio Operator, lists supported component versions (Istio v1.24.6 and v1.26.3, Kiali operator v2.11.0), and highlights `istioctl` support, multi-cluster (multi-primary and primary-remote) deployments, canary control-plane upgrades via revisions, the `IstioRevisionTag` stable alias, the `IstioCNI` CRD, and Prometheus/VictoriaMetrics/Jaeger/OpenTelemetry/Kiali integrations.
- [docs/en/about/release-notes/alauda-service-mesh-v2.1-known-issues.mdx](docs/en/about/release-notes/alauda-service-mesh-v2.1-known-issues.mdx): Documents three known v2.1 limitations and their fixes in v2.1.2: ambient mode incompatibility on FIPS-enabled clusters (resolved by upgrading Istio to v1.28.6), Kiali tracing integration failing in ambient mode due to waypoint service-name mismatch (resolved by upgrading Kiali to v2.22 with the new `use_waypoint_name` option under `external_services.tracing`), and multi-cluster `global.remotePilotAddress` rejecting IPv6 literals (resolved upstream and in v1.28.6).
- [docs/en/about/release-notes/alauda-service-mesh-v2.1.mdx](docs/en/about/release-notes/alauda-service-mesh-v2.1.mdx): Release notes for Alauda Service Mesh v2.1.0 through v2.1.2, listing supported Istio versions (v1.26.3, v1.28.1, v1.28.3, v1.28.6) and Kiali operator versions (v2.17.1, v2.22.2), plus headline features including Istio 1.28 inference extension and InferencePool, ambient multicluster with Waypoint cross-network routing, nftables, dual-stack IPv4/IPv6 Beta, CRL/JWT/seccomp security hardening, Gateway API ListenerSets and BackendTLSPolicy, persona-based installs, and Kiali 2.17–2.22 enhancements such as AI Chatbot/MCP developer preview, OIDC PKCE, SPIRE UI integration, PatternFly 6 modernization, and Gateway API v1.4.0 support.
- [docs/en/about/release-notes/index.mdx](docs/en/about/release-notes/index.mdx): Section landing page for Alauda Service Mesh release notes, surfacing per-release entries (v2.0, v2.1, and v2.1 known issues) via the `<Overview>` component.
## apis
- [docs/en/apis/index.mdx](docs/en/apis/index.mdx): Landing page for the API Reference section, rendering the overview that links into the Kubernetes APIs catalog for Alauda Service Mesh CRDs.
- [docs/en/apis/intro.mdx](docs/en/apis/intro.mdx): Hosts the `<AcpApisOverview />` component, providing the introductory page for the Alauda Container Platform / Service Mesh API reference.
- [docs/en/apis/kubernetes_apis/index.mdx](docs/en/apis/kubernetes_apis/index.mdx): Landing page for the Kubernetes APIs subsection, rendering an overview that links to the per-resource reference pages for `Istio`, `IstioRevision`, `IstioRevisionTag`, `IstioCNI`, and related Sail Operator CRDs.
- [docs/en/apis/kubernetes_apis/servicemesh-operator.mdx](docs/en/apis/kubernetes_apis/servicemesh-operator.mdx): Lists the sail-operator CRDs that make up the Service Mesh Operator API surface: `Istio`, `IstioCNI`, `IstioRevision`, `IstioRevisionTag`, and `ZTunnel`, each linking to the upstream `sailoperator.io/v1` reference in the `alauda-mesh/sail-operator` release-2.1 branch.
## gateways
- [docs/en/gateways/directing-outbound-traffic/index.mdx](docs/en/gateways/directing-outbound-traffic/index.mdx): Introduces egress gateways as dedicated forward proxies on designated egress nodes for centralizing outbound mesh traffic, covering use cases like traffic restrictions and network policy enforcement. Explains that egress routing combines `ServiceEntry`, `Gateway`, `VirtualService`, and `DestinationRule` resources in sidecar mode, while ambient mode must instead use Kubernetes Gateway API `Gateway` and `HTTPRoute`/`GRPCRoute` resources.
- [docs/en/gateways/directing-outbound-traffic/routing-egress-traffic-via-istio-apis.mdx](docs/en/gateways/directing-outbound-traffic/routing-egress-traffic-via-istio-apis.mdx): Step-by-step procedure for routing outbound HTTP traffic through an injected egress gateway using Istio APIs, registering an external host (`docs.alauda.io`) via a `MESH_EXTERNAL` `ServiceEntry` and then routing `curl` traffic through an egress `Gateway`, `DestinationRule` subset, and `VirtualService` that binds the `mesh` and gateway selectors. Includes namespace sidecar-injection labeling for both `InPlace` and `RevisionBased` upgrade strategies (using `istio.io/rev` from `istiorevisions.sailoperator.io`) and verification via a `Telemetry` resource enabling Envoy access logs.
- [docs/en/gateways/directing-outbound-traffic/routing-egress-traffic-via-k8s-gateway-api-in-ambient-mode.mdx](docs/en/gateways/directing-outbound-traffic/routing-egress-traffic-via-k8s-gateway-api-in-ambient-mode.mdx): Walks through ambient-mode egress routing by deploying a waypoint proxy with `gatewayClassName: istio-waypoint` and the `istio.io/waypoint-for: service` label on an HBONE listener (port 15008), then tying a `ServiceEntry` for `httpbingo.org` to it via `istio.io/use-waypoint`. Prerequisites include ambient-profile `Istio` and `IstioCNI`, a `Ztunnel` resource, and kernel compatibility; verification uses a `curl` pod plus ztunnel access logs showing HBONE flows through the waypoint, with an `istioctl waypoint apply --enroll-namespace` shortcut.
- [docs/en/gateways/directing-outbound-traffic/routing-egress-traffic-via-k8s-gateway-api.mdx](docs/en/gateways/directing-outbound-traffic/routing-egress-traffic-via-k8s-gateway-api.mdx): Configures sidecar-mode egress routing with the Kubernetes Gateway API by deploying a `Gateway` (class `istio`, `ClusterIP` service type) plus two `HTTPRoute`s — one with `parentRef` to a `ServiceEntry` to redirect sidecar traffic to the egress gateway, and another with `parentRef` to the gateway to forward to the `httpbingo.org` Hostname backend. Includes verification via a `curl` pod with sidecar injection labels for both `InPlace` and `RevisionBased` upgrade strategies, and an optional `asm-kube-gateway-options` ConfigMap (`infrastructure.parametersRef`) for scheduling onto ACP Infra Nodes.
- [docs/en/gateways/directing-traffic-into-the-mesh/configuring-an-injected-gateway.mdx](docs/en/gateways/directing-traffic-into-the-mesh/configuring-an-injected-gateway.mdx): Shows how the Istio `Gateway` and `VirtualService` resources together configure an injected gateway for ingress, using a sample `bookinfo-gateway` that exposes HTTPS port 443 on `bookinfo.com` with `tls.mode: SIMPLE` and `credentialName: bookinfo-credential`, paired with a `VirtualService` that routes the `/reviews/` URI prefix to the `reviews.bookinfo.svc.cluster.local` service on port 9080.
- [docs/en/gateways/directing-traffic-into-the-mesh/exposing-a-service-via-istio-gateway.mdx](docs/en/gateways/directing-traffic-into-the-mesh/exposing-a-service-via-istio-gateway.mdx): End-to-end task that exposes the `httpbin` sample service via an injected gateway using an Istio `Gateway` (port 80, host `httpbin.example.com`, `selector: istio: <gateway_name>`) and a `VirtualService` with URI prefix matches on `/status` and `/headers`. Verifies success with `curl` returning 200 on matched paths and 404 on `/get`, then patches the gateway `Service` to type `LoadBalancer` and resolves `INGRESS_HOST` from `status.loadBalancer.ingress[].ip` or `.hostname`.
- [docs/en/gateways/directing-traffic-into-the-mesh/exposing-a-service-via-k8s-gateway-api-in-ambient-mode.mdx](docs/en/gateways/directing-traffic-into-the-mesh/exposing-a-service-via-k8s-gateway-api-in-ambient-mode.mdx): Exposes `httpbin` in ambient mode by combining an ingress `Gateway` (class `istio`) and an `HTTPRoute` with a waypoint proxy (`istio.io/waypoint-for: service`, HBONE listener on 15008) that enforces L7 path-prefix routing. Uses `istio.io/dataplane-mode=ambient`, `istio-discovery=enabled`, `istio.io/ingress-use-waypoint=true` on the service, and `istio.io/use-waypoint=httpbin-waypoint` on the namespace; warns that `VirtualService` should not be mixed with Gateway API in ambient and verifies with `curl` plus `networking.istio.io/service-type` annotation removal to switch to `LoadBalancer`.
- [docs/en/gateways/directing-traffic-into-the-mesh/exposing-a-service-via-k8s-gateway-api.mdx](docs/en/gateways/directing-traffic-into-the-mesh/exposing-a-service-via-k8s-gateway-api.mdx): Exposes the `httpbin` service through an injected gateway using a Kubernetes `Gateway` (class `istio`, `networking.istio.io/service-type: ClusterIP`, `istio.io/rev` label) and an `HTTPRoute` with `parentRefs` and path-prefix matches on `/status` and `/headers`. Includes `kubectl wait --for=condition=programmed`, switching to `LoadBalancer` by removing the service-type annotation, deriving `INGRESS_HOST`/`INGRESS_PORT` from `gtw.status.addresses` and listeners, and an optional `asm-kube-gateway-options` ConfigMap for placing the gateway on ACP Infra Nodes.
- [docs/en/gateways/directing-traffic-into-the-mesh/index.mdx](docs/en/gateways/directing-traffic-into-the-mesh/index.mdx): Landing page for ingress traffic management with gateways installed via gateway injection, noting that internal services can be inside or outside the Istio mesh and that gateway proxies are exposed to external clients by setting the gateway `Service` to type `LoadBalancer`. Links to upstream Istio `Gateway`/`VirtualService` references and the Kubernetes Gateway API concept page.
- [docs/en/gateways/gateway-installation/about-gateway-injection.mdx](docs/en/gateways/gateway-installation/about-gateway-injection.mdx): Explains that gateway injection reuses the sidecar-injection mechanism to deploy Envoy as a gateway proxy, summarizing the three-step pattern: create a `Deployment` and `Service` in a namespace visible to the Istio control plane, annotate and label the deployment so the control plane injects an Envoy gateway, then apply `Gateway` and `VirtualService` resources to control ingress or egress traffic.
- [docs/en/gateways/gateway-installation/index.mdx](docs/en/gateways/gateway-installation/index.mdx): Section landing for gateway installation in Alauda Service Mesh, stating that gateways are installed via **gateway injection** and routing readers to the about, installation, and Linux kernel compatibility subtopics.
- [docs/en/gateways/gateway-installation/installing-a-gateway-via-injection.mdx](docs/en/gateways/gateway-installation/installing-a-gateway-via-injection.mdx): Full procedure for installing an ingress or egress gateway via gateway injection: create the gateway namespace, define a `secret-reader` `ServiceAccount`/`Role`/`RoleBinding` for TLS secret access, apply a `Deployment` annotated with `inject.istio.io/templates: gateway` and labeled `sidecar.istio.io/inject: "true"` (or `istio.io/rev` for non-default revisions) using `image: auto`, then create a `Service` (ClusterIP or LoadBalancer) selecting the same `istio: <gateway_name>` label. Includes optional `HorizontalPodAutoscaler` (CPU 80% target, min 2/max 5) and `PodDisruptionBudget` (minAvailable: 1) examples and ACP Infra-Node `nodeSelector`/`tolerations`.
- [docs/en/gateways/gateway-installation/linux-kernel-compatibility-notice.mdx](docs/en/gateways/gateway-installation/linux-kernel-compatibility-notice.mdx): Configuration workaround for nodes running Linux kernels older than 4.11 (e.g., CentOS 7), where the default `net.ipv4.ip_unprivileged_port_start` sysctl is unavailable. Provides two scenarios — gateways listening on ports >= 1024 (set `sysctls: []`) and ports < 1024 (also add the `NET_BIND_SERVICE` capability, or optionally run as root) — for both Istio Gateway (patching the `sidecarInjectorWebhook.templates.gateway` injection template on the `Istio` CR with `jq`) and Kubernetes Gateway API (via an `asm-kube-gateway-options` ConfigMap referenced through `infrastructure.parametersRef`).
- [docs/en/gateways/index.mdx](docs/en/gateways/index.mdx): Top-level Gateways section landing that defines a gateway as a dedicated Envoy proxy `Deployment` paired with a Kubernetes `Service` operating at the mesh edge to provide fine-grained control over traffic entering or leaving the mesh, with an overview of the child topics covering installation, directing inbound traffic, and directing outbound traffic.
## installing
- [docs/en/installing/ambient-mode/ambient-discovery-selectors.mdx](docs/en/installing/ambient-mode/ambient-discovery-selectors.mdx): Restricts ambient-mode mesh scope by configuring `discoverySelectors` under `meshConfig` in the `Istio` resource so the control plane only monitors namespaces carrying a matching label (for example, `istio-discovery=enabled`). Walks through labeling the `istio-cni`, `istio-system`, and `ztunnel` namespaces, then applying an `Istio` CR with `profile: ambient` and `trustedZtunnelNamespace` to reduce per-proxy config overhead and allow multiple meshes to coexist on one cluster.
- [docs/en/installing/ambient-mode/ambient-l7-features.mdx](docs/en/installing/ambient-mode/ambient-l7-features.mdx): Demonstrates Layer 7 features available in ambient mode via Gateway API `HTTPRoute` and Istio `AuthorizationPolicy` resources. Walks through an 80/20 traffic split between `reviews-v1` and `reviews-v2` using a waypoint proxy, then enforces a waypoint-attached `AuthorizationPolicy` that allows only GET requests from the `curl` service account to `productpage` while denying POSTs (`HTTP 403`) and unauthenticated callers (`RBAC: access denied`), and notes that `ZTunnel` ignores `PeerAuthentication` policies set to `DISABLE` because HBONE always enforces mTLS.
- [docs/en/installing/ambient-mode/deploying-ambient-bookinfo.mdx](docs/en/installing/ambient-mode/deploying-ambient-bookinfo.mdx): Deploys the Bookinfo sample application in ambient mode without sidecar injection, relying on the `ZTunnel` proxy via the `IstioCNI` and `Istio` resources. Covers creating the `bookinfo` namespace, labeling it with `istio-discovery=enabled` and `istio.io/dataplane-mode=ambient`, deploying the standard and versioned Bookinfo manifests, and verifying enrollment with `istioctl -n ztunnel ztunnel-config workloads` showing the HBONE protocol on each pod.
- [docs/en/installing/ambient-mode/index.mdx](docs/en/installing/ambient-mode/index.mdx): Introduces Istio ambient mode as a sidecar-less architecture in Alauda Service Mesh, built on a per-node `ZTunnel` proxy for L4/mTLS, optional per-namespace or per-service-account waypoint proxies for L7, and the Istio CNI plugin for transparent traffic capture. Notes benefits such as simplified operations, lower per-pod overhead, incremental adoption, and zero-trust mTLS by default, and flags ambient mode as Technology Preview that should only be installed on clusters without an existing sidecar-mode mesh.
- [docs/en/installing/ambient-mode/installing-ambient-mode.mdx](docs/en/installing/ambient-mode/installing-ambient-mode.mdx): Installs Istio in ambient mode on Alauda Container Platform with Alauda Service Mesh Operator 2.1.1+ by creating `IstioCNI`, `Istio`, and `ZTunnel` custom resources, all with `profile: ambient`. Sets `reconcileIptablesOnStartup: true` on `IstioCNI` to repair drifted iptables rules, configures `pilot.trustedZtunnelNamespace` and `discoverySelectors` on `Istio`, requires the Multus CNI plugin and kube-ovn v4.1.5+, and uses `kubectl wait` to confirm each resource reaches the Ready condition.
- [docs/en/installing/ambient-mode/waypoint-proxies.mdx](docs/en/installing/ambient-mode/waypoint-proxies.mdx): Deploys Envoy-based waypoint proxies as Gateway API `Gateway` resources (gatewayClassName `istio-waypoint`, HBONE listener on port 15008) to add L7 features such as HTTP routing, retries, rate limiting, authorization, and tracing on top of the L4 `ZTunnel` overlay. Covers per-namespace enrollment via the `istio.io/use-waypoint` label, the `istio.io/waypoint-for: service|workload` selector, and cross-namespace waypoints using `allowedRoutes` and the `istio.io/use-waypoint-namespace` label, verified with `istioctl ztunnel-config services`.
- [docs/en/installing/dual-stack/index.mdx](docs/en/installing/dual-stack/index.mdx): Introduces Istio dual-stack networking support, tracing it from experimental in Istio 1.17 to Alpha in 1.24 and Beta in 1.28, so meshed services can communicate over both IPv4 and IPv6 endpoints. Explains how Kubernetes assigns both address families per pod and how `Service.spec.ipFamilyPolicy` values `SingleStack`, `PreferDualStack`, and `RequireDualStack` control which families a Service exposes.
- [docs/en/installing/dual-stack/install-mesh-in-dual-stack-mode.mdx](docs/en/installing/dual-stack/install-mesh-in-dual-stack-mode.mdx): Installs Istio with dual-stack networking by creating `IstioCNI` and an `Istio` resource that sets `pilot.ipFamilyPolicy: RequireDualStack` and `ISTIO_DUAL_STACK="true"` in both `proxyMetadata` and Pilot env. Verifies the configuration by deploying `tcp-echo` sample apps in `dual-stack`, `ipv4`, and `ipv6` namespaces (each with sidecar injection enabled) plus a `sleep` client, then runs `nc tcp-echo.<ns> 9000` from the sleep pod to confirm connectivity across all three IP-family policies.
- [docs/en/installing/index.mdx](docs/en/installing/index.mdx): Landing page for the Installing section of the Alauda Service Mesh v2 documentation, linking to subsections that cover installing the service mesh, application deployment, dual-stack mode, and ambient mode.
- [docs/en/installing/installing-service-mesh/application-deployment/application-requirements.mdx](docs/en/installing/installing-service-mesh/application-deployment/application-requirements.mdx): Lists Istio sidecar requirements for application pods: avoid running containers as UID `1337` (reserved for the sidecar proxy), set the recommended `app`/`version` (or `service.istio.io/canonical-name`/`canonical-revision`) labels that Kiali uses for telemetry, and name service ports for protocol selection. Tabulates the Envoy ports applications must avoid, including 15000 (admin), 15001/15006 (outbound/inbound), 15008 (HBONE mTLS), 15020/15090 (Prometheus telemetry), and 15021 (health checks).
- [docs/en/installing/installing-service-mesh/application-deployment/deploying-the-bookinfo-application.mdx](docs/en/installing/installing-service-mesh/application-deployment/deploying-the-bookinfo-application.mdx): Deploys the Bookinfo sample (`productpage`, `details`, `ratings`, `reviews-v1/v2/v3`) under sidecar mode by creating the `bookinfo` namespace and enabling injection with either `istio-injection=enabled` (InPlace upgrade) or `istio.io/rev=<revision>` after listing `istiorevisions.sailoperator.io` (RevisionBased upgrade). Then exposes the app via two paths: gateway injection (`istio-ingressgateway` Deployment/Service with optional HorizontalPodAutoscaler and PodDisruptionBudget) and the Kubernetes Gateway API (`Gateway` plus `HTTPRoute`), verified by `curl`ing `/productpage` and observing round-robin reviews.
- [docs/en/installing/installing-service-mesh/application-deployment/index.mdx](docs/en/installing/installing-service-mesh/application-deployment/index.mdx): Landing page for the Application Deployment section, introducing how Istio provides mesh functionality to applications with minimal application code changes and linking to namespace requirements, application requirements, and the Bookinfo deployment walkthrough.
- [docs/en/installing/installing-service-mesh/application-deployment/namespace-requirements.mdx](docs/en/installing/installing-service-mesh/application-deployment/namespace-requirements.mdx): Notes that namespaces created with `kubectl create namespace` have no special requirements, while namespaces created from the Alauda Container Platform web console (Projects > Namespace) must have their Pod Security Admission `Enforce` mode set to something other than `Restricted` — `Baseline` is recommended for mesh-enabled workloads.
- [docs/en/installing/installing-service-mesh/custom-istio-config.mdx](docs/en/installing/installing-service-mesh/custom-istio-config.mdx): Customizes the deployed Istio control plane by editing the `values` field of the `Istio` custom resource (Helm-style configuration). Navigates via Marketplace > OperatorHub > Alauda Service Mesh v2 > All Instances > the `default` Istio instance, then uses Actions > Update to modify YAML, and points to the sail-operator API reference for the full set of supported `values` fields.
- [docs/en/installing/installing-service-mesh/index.mdx](docs/en/installing/installing-service-mesh/index.mdx): Landing page for the Installing Alauda Service Mesh section, gathering procedures for installing the Operator and control plane, configuring custom Istio values, deploying applications, and related setup topics.
- [docs/en/installing/installing-service-mesh/install-mesh.mdx](docs/en/installing/installing-service-mesh/install-mesh.mdx): Walks through installing the Alauda Service Mesh v2 Operator (web console and CLI flows for the `servicemesh-operator2` Subscription, `stable` channels, and InstallPlan approval), then deploying the Istio data plane by creating the `IstioCNI` and `Istio` custom resources in the `istio-cni` and `istio-system` namespaces. Lists the Sail Operator CRDs (`Istio`, `IstioRevision`, `IstioCNI`, `ZTunnel`) installed under `sailoperator.io`, prerequisites such as the Multus plugin and kube-ovn v4.1.5+, and verification commands like `kubectl wait --for condition=Ready istiocni/default`.
- [docs/en/installing/installing-service-mesh/istio-high-availability/configuring-istio-ha-by-using-autoscaling.mdx](docs/en/installing/installing-service-mesh/istio-high-availability/configuring-istio-ha-by-using-autoscaling.mdx): Configures high availability for the Istio control plane by patching the `Istio` resource with `spec.values.pilot.autoscaleMin`, `autoscaleMax`, and CPU/memory `targetAverageUtilization` so the Horizontal Pod Autoscaler scales `istiod` replicas based on load. Covers both web console and `kubectl patch` workflows and verifies two `istiod` pods are running as the minimum HA baseline.
- [docs/en/installing/installing-service-mesh/istio-high-availability/configuring-istio-ha-by-using-replica-count.mdx](docs/en/installing/installing-service-mesh/istio-high-availability/configuring-istio-ha-by-using-replica-count.mdx): Configures Istio control plane HA with a fixed replica count by setting `spec.values.pilot.autoscaleEnabled: false` and `replicaCount: 2` on the `Istio` resource, suitable for steady or predictable control plane load. Provides web console and `kubectl patch` procedures and verifies the result by listing `istiod` pods.
- [docs/en/installing/installing-service-mesh/istio-high-availability/index.mdx](docs/en/installing/installing-service-mesh/istio-high-availability/index.mdx): Introduces Istio control plane High Availability and the two enablement approaches (static replica count vs HPA-driven autoscaling), explaining how multi-replica `istiod` survives pod failures, smooths upgrades, and supports zone-level fault tolerance. Includes a single-node cluster note for disabling the default Pod Disruption Budget via `spec.values.global.defaultPodDisruptionBudget.enabled: false` to avoid blocking drains.
- [docs/en/installing/installing-service-mesh/scoping-the-service-mesh/index.mdx](docs/en/installing/installing-service-mesh/scoping-the-service-mesh/index.mdx): Explains why limiting Istiod's configuration scope matters at scale and compares the three Istio scoping mechanisms — `Sidecar` for workload-side import, `exportTo` for service-owner visibility, and `discoverySelectors` for namespace-level filtering. Includes FAQ entries on unmatched traffic when calling out-of-scope services and how Gateways interact with these scoping primitives.
- [docs/en/installing/installing-service-mesh/scoping-the-service-mesh/using-discovery-selectors.mdx](docs/en/installing/installing-service-mesh/scoping-the-service-mesh/using-discovery-selectors.mdx): Uses `meshConfig.discoverySelectors` in the `Istio` resource with Kubernetes label selectors (such as `istio-discovery=enabled`) to control which namespaces Istiod monitors, reducing proxy configuration cost at scale. Warns that discovery selectors are not a security boundary and walks through labeling `istio-system` and patching the control plane resource.
- [docs/en/installing/installing-service-mesh/scoping-the-service-mesh/using-export-to.mdx](docs/en/installing/installing-service-mesh/scoping-the-service-mesh/using-export-to.mdx): Restricts service visibility from the producer side using the `spec.exportTo` field on `VirtualService`, `DestinationRule`, and `ServiceEntry`, plus the `networking.istio.io/exportTo` annotation on `Service`. Shows an example that limits the `details` Service to its own namespace and a `client` namespace.
- [docs/en/installing/installing-service-mesh/scoping-the-service-mesh/using-sidecar-import.mdx](docs/en/installing/installing-service-mesh/scoping-the-service-mesh/using-sidecar-import.mdx): Limits the configuration each Envoy sidecar receives by listing hosts under `egress.hosts` of a `Sidecar` resource, supporting same-namespace (`./*`), other-namespace (`bookinfo/*`), and specific-host (`external-services/example.com`) patterns. Useful for trimming proxy memory and CPU when workloads only need a subset of cluster services.
- [docs/en/installing/istioctl.mdx](docs/en/installing/istioctl.mdx): Installs the `istioctl` command-line utility for debugging and diagnosing Alauda Service Mesh deployments, including how to look up the running `Istio` resource version, download the matching binary from the Istio GitHub releases, extract it on Linux/macOS or Windows, and confirm client/control plane/data plane versions with `istioctl version`.
- [docs/en/installing/mtls.mdx](docs/en/installing/mtls.mdx): Configures mutual TLS in Alauda Service Mesh using `PeerAuthentication` (`PERMISSIVE` vs `STRICT`) and `DestinationRule` (`DISABLE`, `SIMPLE`, `MUTUAL`, `ISTIO_MUTUAL`) modes, plus the auto-mTLS feature controlled by `enableAutoMtls`. Provides namespace-scoped and mesh-wide STRICT mTLS examples (including an `api-server` DestinationRule that disables TLS for the Kubernetes API) and shows how to validate encryption with Kiali lock-icon indicators.
- [docs/en/installing/multi-cluster/configuration-overview.mdx](docs/en/installing/multi-cluster/configuration-overview.mdx): Prepares a multi-cluster mesh by generating a shared root CA and per-cluster intermediate CA certificates with OpenSSL (using `root-ca.conf` and `intermediate.conf` configs for the East and West clusters), then applying them as `cacerts` secrets in `istio-system` on both clusters via `kubectl --context`. Lists the multi-cluster prerequisites — Multus, kube-ovn v4.1.5+, the Alauda Service Mesh v2 Operator on every cluster, and cross-cluster API server reachability.
- [docs/en/installing/multi-cluster/index.mdx](docs/en/installing/multi-cluster/index.mdx): Introduces multi-cluster service mesh deployment with Alauda Service Mesh v2 and enumerates the four supported topologies built from two control-plane models (Multi-Primary vs Primary-Remote) and two network models (Single Network vs Multi-Network). Explains when east-west gateways are required and how the primary cluster's control plane configures sidecars on remote clusters.
- [docs/en/installing/multi-cluster/install-multi-primary-multi-network.mdx](docs/en/installing/multi-cluster/install-multi-primary-multi-network.mdx): Installs Istio in a multi-primary multi-network topology across an East and West cluster, creating `IstioCNI` and `Istio` resources with `global.meshID=mesh1`, distinct `network1`/`network2` and `clusterName` values, plus east-west gateways from the `sail-operator` manifests and `expose-services.yaml`. Uses `istioctl create-remote-secret` to swap API server credentials, then validates by deploying `helloworld` v1/v2 and `sleep` in a `sample` namespace and curling across clusters.
- [docs/en/installing/multi-cluster/install-primary-remote-multi-network.mdx](docs/en/installing/multi-cluster/install-primary-remote-multi-network.mdx): Installs Istio in a primary-remote multi-network topology where the East cluster runs the control plane with `externalIstiod: true` and the West cluster uses `profile: remote` pointing at `global.remotePilotAddress` (the East east-west gateway IP) and `istiodRemote.injectionPath`. Covers exposing istiod via `expose-istiod.yaml`, annotating `istio-system` on the remote with `topology.istio.io/controlPlaneClusters=cluster1`, sharing remote secrets, and verifying load balancing of `helloworld` v1/v2 across both clusters.
- [docs/en/installing/sidecar-injection/identifying-the-revision-name.mdx](docs/en/installing/sidecar-injection/identifying-the-revision-name.mdx): Explains how `IstioRevision` resources are named — matching the `Istio` resource name under the `InPlace` update strategy, or `<name>-v<version>` under `RevisionBased` — and how to list them with `kubectl get istiorevisions`. Documents the namespace/pod labels that enable injection (`istio-injection=enabled`, `sidecar.istio.io/inject=true`, `istio.io/rev=<revision>`) and the precedence rules when both `istio-injection` and `istio.io/rev` are set.
- [docs/en/installing/sidecar-injection/index.mdx](docs/en/installing/sidecar-injection/index.mdx): Introduces how Istio sidecar proxies are injected into mesh workloads, primarily via namespace- or pod-level labels handled by an admission controller at pod creation. Explains that the revision label binds a workload to a specific Istio control plane instance and that automatic injection only changes pods (verifiable with `kubectl describe`), not the parent Deployment.
- [docs/en/installing/sidecar-injection/sidecar-injection-with-istiorevisiontag.mdx](docs/en/installing/sidecar-injection/sidecar-injection-with-istiorevisiontag.mdx): Walks through creating an `IstioRevisionTag` resource named `default` (kind `sailoperator.io/v1`) that points at a non-default `Istio` revision such as `default-v1-28-6`, so workloads can keep using the conventional `istio-injection=enabled` namespace label. Includes the apply, verify, label, and `kubectl rollout restart` steps against the Bookinfo namespace, and confirms success by pods moving from `1/1` to `2/2` READY.
- [docs/en/installing/sidecar-injection/sidecar-injection-with-lables.mdx](docs/en/installing/sidecar-injection/sidecar-injection-with-lables.mdx): Demonstrates two label-driven sidecar injection methods on the Bookinfo application: namespace-wide enablement using `kubectl label namespace bookinfo istio-injection=enabled` plus a rollout restart, and per-pod selection via the revision label `istio.io/rev=<name>` (for example `my-mesh`) in the Deployment's `spec.template.metadata.labels`. Also shows how to opt a workload like `ratings-v1` out of an injected namespace by setting `sidecar.istio.io/inject: "false"`.
## integration
- [docs/en/integration/index.mdx](docs/en/integration/index.mdx): Landing page for the Integration section, which groups guides on connecting Alauda Service Mesh to external systems and observability stacks.
- [docs/en/integration/observability/distributed-tracing-and-mesh.mdx](docs/en/integration/observability/distributed-tracing-and-mesh.mdx): Covers wiring Alauda Service Mesh into distributed tracing, including the headers (`x-request-id`, W3C `traceparent`/`tracestate`) applications must propagate so Envoy-emitted spans can be stitched into traces. Provides an end-to-end procedure that installs a `Jaeger` instance via `install-jaeger.sh`, deploys an `OpenTelemetryCollector` exporting OTLP to `jaeger-prod-collector-headless`, enables tracing on the `Istio` resource through `meshConfig.enableTracing` and an `opentelemetry` extension provider, and activates it with a `Telemetry` CR setting `randomSamplingPercentage`.
- [docs/en/integration/observability/index.mdx](docs/en/integration/observability/index.mdx): Landing page for the Observability integration section, which orients readers to the Alauda observability components that plug into Service Mesh.
- [docs/en/integration/observability/kiali.mdx](docs/en/integration/observability/kiali.mdx): Installs and configures Alauda Build of Kiali (Kiali Operator v2.17.1-r1) as the mesh management console, covering OperatorHub and CLI install via Subscription/InstallPlan, then creating a `Kiali` CR with OpenID auth backed by Dex, ingress through the platform's ALB class, and Prometheus/VictoriaMetrics access via the `kiali-monitoring-basic-auth` Secret and optional Thanos proxy. Also shows how to enable distributed tracing in Kiali by setting `external_services.tracing` to a Jaeger or Tempo backend so traces appear under the Workload Traces tab.
- [docs/en/integration/observability/metrics-and-mesh.mdx](docs/en/integration/observability/metrics-and-mesh.mdx): Configures user-workload monitoring for Service Mesh by applying a `ServiceMonitor` (`istiod-monitor` selecting `istio=pilot`) and a `PodMonitor` (`istio-proxies-monitor` scraping `istio-proxy` containers at `/stats/prometheus`) labelled `prometheus: kube-prometheus` for ACP Prometheus. Also defines an Istio `Telemetry` resource (`asm-default`) that adds a `mesh_id` tag override sourced from `xds.node.metadata['MESH_ID']` so multi-cluster ambient deployments can disambiguate metrics.
- [docs/en/integration/observability/observability-and-mesh.mdx](docs/en/integration/observability/observability-and-mesh.mdx): Outlines how Alauda Service Mesh combines monitoring (Prometheus or VictoriaMetrics with Alertmanager), distributed tracing (Jaeger and OpenTelemetry), and Alauda Build of Kiali to deliver a unified telemetry view of mesh topology, traffic, and request flow.
## uninstalling
- [docs/en/uninstalling/index.mdx](docs/en/uninstalling/index.mdx): Landing page for the Uninstalling section, which links to the procedures for removing Alauda Service Mesh, its ambient-mode resources, and Alauda Build of Kiali.
- [docs/en/uninstalling/uninstalling-alauda-build-of-kiali.mdx](docs/en/uninstalling/uninstalling-alauda-build-of-kiali.mdx): Removes Alauda Build of Kiali from ACP by deleting the `Kiali` custom resource (via web console All Instances or `kubectl delete kiali/<name> -n <namespace>`) and then the `kiali-operator` Subscription, with an optional final step that deletes all `kiali.io` CRDs using `kubectl get crds -oname | grep -e kiali.io | xargs kubectl delete`.
- [docs/en/uninstalling/uninstalling-alauda-service-mesh-in-ambient-mode.mdx](docs/en/uninstalling/uninstalling-alauda-service-mesh-in-ambient-mode.mdx): Tears down an ambient-mode Service Mesh by deleting waypoint proxy `Gateway` resources (selected via `istio.io/waypoint-for`), removing the `istio.io/dataplane-mode=ambient` label from enrolled namespaces, then deleting the `ZTunnel`, `Istio`, and `IstioCNI` resources, the `servicemesh-operator2` Subscription, and the `ztunnel`, `istio-system`, and `istio-cni` namespaces. Includes a final optional step to remove all `istio.io` and `sailoperator.io` CRDs.
- [docs/en/uninstalling/uninstalling-alauda-service-mesh.mdx](docs/en/uninstalling/uninstalling-alauda-service-mesh.mdx): Uninstalls the standard (sidecar-mode) Alauda Service Mesh v2 Operator by deleting the `Istio` and `IstioCNI` custom resources through the web console or `kubectl delete`, removing the `servicemesh-operator2` Subscription in the `sail-operator` namespace, and cleaning up the `istio-system` and `istio-cni` namespaces, with an optional CRD purge covering `istio.io` and `sailoperator.io`.
## updating
- [docs/en/updating/index.mdx](docs/en/updating/index.mdx): Landing page for the Updating section, which links to the operator-update and Istio control-plane update procedures.
- [docs/en/updating/update-mesh/index.mdx](docs/en/updating/update-mesh/index.mdx): Explains semantic versioning for Alauda Service Mesh releases and how OLM channels (`stable` versus versioned channels like `stable-2.0`) control Operator updates and approval flow. Describes the two `Istio` resource update strategies (`InPlace`, the default, and `RevisionBased`) and how `spec.version` (including aliases such as `vX.Y-latest`) drives control-plane upgrades after the Operator itself is updated.
- [docs/en/updating/update-mesh/istio-cni.mdx](docs/en/updating/update-mesh/istio-cni.mdx): Updates the Istio CNI plugin in place by modifying the `spec.version` field on the `IstioCNI` resource, which prompts the Service Mesh v2 Operator to roll the `istio-cni-node` daemonset pods to the target `vX.Y.Z` build. Includes a `kubectl patch istiocni default` example targeting `v1.28.6` and a `kubectl get istiocni` readiness check showing `Healthy` status.
- [docs/en/updating/update-mesh/revision-based-strategy/index.mdx](docs/en/updating/update-mesh/revision-based-strategy/index.mdx): Introduces the `RevisionBased` update strategy, which provisions a second Istio control plane instance for each change to `spec.version` so workloads can migrate gradually via `istio.io/rev` label changes or `IstioRevisionTag` retargeting. Highlights its support for canary upgrades, jumps across more than one minor version, and validation against a subset of workloads before fully cutting over large or mission-critical meshes.
- [docs/en/updating/update-mesh/revision-based-strategy/selecting-revisionbased-strategy.mdx](docs/en/updating/update-mesh/revision-based-strategy/selecting-revisionbased-strategy.mdx): Shows the minimal `Istio` resource YAML that selects the `RevisionBased` upgrade strategy by setting `spec.updateStrategy.type: RevisionBased` alongside `spec.version`. Notes that the Operator then materializes an `IstioRevision` named `<istio_resource_name>-<version>`.
- [docs/en/updating/update-mesh/revision-based-strategy/update-revisionbased-and-istiorevisiontag.mdx](docs/en/updating/update-mesh/revision-based-strategy/update-revisionbased-and-istiorevisiontag.mdx): Walks through a full canary upgrade driven by an `IstioRevisionTag` that points at an `Istio` resource using `RevisionBased`: install `IstioCNI`, `Istio`, the tag, and the Bookinfo sample, then patch `spec.version` from `v1.26.3` to `v1.28.6`. Verifies parallel `istiod` revisions with `kubectl get istio/istiorevision/istiorevisiontag`, retargets workloads by rolling deployments without editing namespace labels, and explains how `spec.updateStrategy.inactiveRevisionDeletionGracePeriodSeconds` controls cleanup of the old revision.
- [docs/en/updating/update-mesh/revision-based-strategy/update-revisionbased.mdx](docs/en/updating/update-mesh/revision-based-strategy/update-revisionbased.mdx): Performs a `RevisionBased` upgrade without `IstioRevisionTag`, relying on the `istio.io/rev=<revision_name>` namespace label to move Bookinfo workloads from `default-v1-26-3` to `default-v1-28-6`. Covers installing `IstioCNI` and the `Istio` resource, patching `spec.version`, confirming two `istiod` pods coexist via `istioctl proxy-status`, relabeling the namespace, rolling deployments, and waiting out `inactiveRevisionDeletionGracePeriodSeconds` before the old `IstioRevision` is reaped.
- [docs/en/updating/update-mesh/update-inplace.mdx](docs/en/updating/update-mesh/update-inplace.mdx): Covers the `InPlace` update strategy, where a single `istiod` revision is restarted with the new version and existing sidecars automatically reconnect; only one minor version step is supported per upgrade. Provides end-to-end procedures for installing `IstioCNI` and `Istio` with `spec.updateStrategy.type: InPlace`, deploying Bookinfo, patching `spec.version` to `v1.28.6`, restarting workloads to refresh Envoy proxies, verifying via `istioctl proxy-status`, and tearing down the dev environment with `kubectl delete istio/default istiocni/default`.
- [docs/en/updating/upgrade-kiali/index.mdx](docs/en/updating/upgrade-kiali/index.mdx): Documents the sequential Kiali Operator upgrade path 2.11.z to 2.17.z to 2.22.z for Alauda Build of Kiali, noting that the Operator automatically upgrades the matching Kiali Server. Post-upgrade verification uses `kubectl get pods -l app.kubernetes.io/name=kiali`, log inspection for the `Version:` line, and the Kiali UI About dialog to confirm the new release.