This is the multi-page printable view of this section. Click here to print.
Features
- 1: Application Wizards
- 2: Detail Views
- 3: Health
- 4: Internationalization
- 5: Istio Configuration
- 6: Istio Infrastructure Status
- 7: Multi-cluster
- 8: Security
- 9: Topology
- 10: Tracing
- 11: Validation
1 - Application Wizards
Istio Application Wizards
Kiali provides Actions to create, update and delete Istio configuration, driven by wizards.
Actions can be applied to a Service
Actions can also be applied to a Workload
And, actions are available for an entire Namespace
Service Actions
Kiali offers a robust set of service actions, with accompanying wizards.
Traffic Management: Request Routing
The Request Routing Wizard allows creating multiple routing rules.
- Every rule is composed of a Request Matching and a Routes To section.
- The Request Matching section can add multiple filters using HEADERS, URI, SCHEME, METHOD or AUTHORITY HTTP parameters.
- The Request Matching section can be empty, in this case any HTTP request received is matched against this rule.
- The Routes To section can specify the percentage of traffic that is routed to a specific workload.
Istio applies routing rules in order, meaning that the first rule matching an HTTP request (top-down) performs the routing. The Matching Routing Wizard allows changing the rule order.
Traffic Management: Fault Injection
The Fault Injection Wizard allows injecting faults to test the resiliency of a Service.
- HTTP Delay specification is used to inject latency into the request forwarding path.
- HTTP Abort specification is used to immediately abort a request and return a pre-specified status code.
Traffic Management: Traffic Shifting
The Traffic Shifting Wizard allows selecting the percentage of traffic that is routed to a specific workload.
Traffic Management: Request Timeouts
The Request Timeouts Wizard sets up request timeouts in Envoy, using Istio.
- HTTP Timeout defines the timeout for a request.
- HTTP Retry describes the retry policy to use when an HTTP request fails.
Traffic Management: Gateways
Traffic Management Wizards have an Advanced Options section that can be used to extend the scenario.
One available Advanced Option is to expose a Service to external traffic through an existing Gateway or to create a new Gateway for this Service.
Traffic Management: Circuit Breaker
Traffic Management Wizards allows defining Circuit Breakers on Services as part of the available Advanced Options.
- Connection Pool defines the connection limits for an upstream host.
- Outlier Detection implements the Circuit Breaker based on the consecutive errors reported.
Security: Traffic Policy
Traffic Management Advanced Options allows defining Security and Load Balancing settings.
- TLS related settings for connections to the upstream service.
- Automatically generate a PeerAuthentication resource for this Service.
- Load balancing policies to apply for a specific destination.
Workload Actions
Automatic Sidecar Injection
A Workload can be individually managed to control the Sidecar Injection.
A default scenario is to indicate this at Namespace level but there can be cases where a Workload shouldn’t be part of the Mesh or vice versa.
Kiali allows users to alter the Deployment template and propagate this configuration into the Pods.
Namespace Actions
The Kiali Overview page offers several Namespace actions, in any of its views: Expanded, Compacted or Table.
Show
Show actions navigate from a Namespace to its specific Graph, Applications, Workloads, Services or Istio Config pages.
Automatic Sidecar Injection
When Automatic Sidecar Injection is enabled in the cluster, a Namespace can be labeled to enable/disable the injection webhook, controlling whether new deployments will automatically have a sidecar.
Canary Istio upgrade
When Istio Canary revision is installed, a Namespace can be labeled to that canary revision, so the sidecar of canary revision will be injected into workloads of the namespace.
Security: Traffic Policies
Kiali can generate Traffic Policies based on the traffic for a namespace.
For example, at some point a namespace presents a traffic graph like this:
And a user may want to add Traffic Policies to secure that communication. In other words, to prevent traffic other than that currently reflected in the Graph’s Services and Workloads.
Using the Create Traffic Policies action on a namespace, Kiali will generate AuthorizationPolicy resources per every Workload in the Namespace.
2 - Detail Views
Kiali provides filtered list views of all your service mesh definitions. Each view provides health, details, YAML definitions and links to help you visualize your mesh. There are list and detail views for:
- Applications
- Istio Configuration
- Services
- Workloads
Selecting an object from the list will bring you to its detail page. For Istio Config, Kiali will present its YAML, along with contextual validation information. Other mesh components present a variety of Tabs.
Overview Tab
Overview is the default Tab for any detail page. The overview tab provides detailed information, including health status, and a detailed mini-graph of the current traffic involving the component. The full set of tabs, as well as the detailed information, varies based on the component type.
Each Overview provides:
- links to related components and linked Istio configuration.
- health status.
- validation information.
- an Action menu for actions that can be taken on the component.
- several Wizards are available.
And also type-specfic information. For example:
- Service detail includes Network information.
- Workload detail provides backing Pod information.
Both Workload and Service detail can be customized to some extent, by adding additional details supplied as annotations. This is done through the additional_display_details
field in the Kiali CR.
Traffic
The Traffic Tab presents a service, app, or workload’s Inbound and Outbound traffic in a table-oriented way:
Logs
Workload detail offers a special Logs tab. Kiali offers a special unified logs view that lets users correlate app and proxy logs. It can also add-in trace span information to help identify important traces based on associated logging. More powerful features include substring or regex Show/Hide, full-screen, and the ability to set proxy log level without a pod restart.
Metrics
Each detail view provides Inbound Metrics and/or Outbound Metrics tabs, offering predefined metric dashboards. The dashboards provided are tailored to the relevant application, workload or service level. Application and workload detail views show request and response metrics such as volume, duration, size, or tcp traffic. The service detail view shows request and response metrics for inbound traffic only.
Kiali allows the user to customize the charts by choosing the charted dimensions. It can also present metrics reported by either source or destination proxy metrics. And for troublshooting it can overlay trace spans.
Traces
Each detail view provides a Traces tab with a native integration with Jaeger. For more, see Tracing.
Dashboards
Kiali will display additional tabs for each applicable Built-In Dashboard or Custom Dashboard.
Built-in dashboards
Kiali comes with built-in dashboards for several runtimes, including Envoy, Go, Node.js, and others.
Envoy
The most important built-in dashboard is for Envoy. Kiali offers the Envoy tab for many workloads. The Envoy tab is actually a Built-In Dashboard, but it is very common as it applies to any workload injected with, or that is itself, an Envoy proxy. Being able to inspect the Envoy proxy is invaluable when troublshooting your mesh. The Envoy tab itself offers five subtabs, exposing a wealth of information.
Istio’s Envoy sidecars supply some internal metrics, that can be viewed in Kiali. They are different than the metrics reported by Istio Telemetry, which Kiali uses extensively. Some of Envoy’s metrics may be redundant.
Note that the enabled Envoy metrics can be tuned, as explained in the Istio documentation: it’s possible to get more metrics using the statsInclusionPrefixes
annotation. Make sure you include cluster_manager
and listener_manager
as they are required.
For example, sidecar.istio.io/statsInclusionPrefixes: cluster_manager,listener_manager,listener
will add listener
metrics for more inbound traffic information. You can then customize the Envoy dashboard of Kiali according to the collected metrics.
Go
Contains metrics such as the number of threads, goroutines, and heap usage. The expected metrics are provided by the Prometheus Go client.
Example to expose built-in Go metrics:
http.Handle("/metrics", promhttp.Handler())
http.ListenAndServe(":2112", nil)
As an example and for self-monitoring purpose Kiali itself exposes Go metrics.
The pod annotation for Kiali is: kiali.io/dashboards: go
Kiali
Kiali has its own built-in dashboard that helps you observe performance of the Kiali server itself. To view this dashboard, navigate to either the application or workload view of the Kiali server and select the Kiali Internal Metrics
tab to see Kiali’s own internal metrics:
Node.js
Contains metrics such as active handles, event loop lag, and heap usage. The expected metrics are provided by prom-client.
Example of Node.js metrics for Prometheus:
const client = require('prom-client');
client.collectDefaultMetrics();
// ...
app.get('/metrics', (request, response) => {
response.set('Content-Type', client.register.contentType);
response.send(client.register.metrics());
});
Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/ratings
The pod annotation for Kiali is: kiali.io/dashboards: nodejs
Quarkus
Contains JVM-related, GC usage metrics. The expected metrics can be provided by SmallRye Metrics, a MicroProfile Metrics implementation. Example with maven:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-metrics</artifactId>
</dependency>
The pod annotation for Kiali is: kiali.io/dashboards: quarkus
Spring Boot
Three dashboards are provided: one for JVM memory / threads, another for JVM buffer pools and the last one for Tomcat metrics. The expected metrics come from Spring Boot Actuator for Prometheus. Example with maven:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-core</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/details
The pod annotation for Kiali with the full list of dashboards is: kiali.io/dashboards: springboot-jvm,springboot-jvm-pool,springboot-tomcat
By default, the metrics are exposed on path /actuator/prometheus, so it must be specified in the corresponding annotation: prometheus.io/path: "/actuator/prometheus"
Thorntail
Contains mostly JVM-related metrics such as loaded classes count, memory usage, etc. The expected metrics are provided by the MicroProfile Metrics module. Example with maven:
<dependency>
<groupId>io.thorntail</groupId>
<artifactId>microprofile-metrics</artifactId>
</dependency>
Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/productpage
The pod annotation for Kiali is: kiali.io/dashboards: thorntail
Vert.x
Several dashboards are provided, related to different components in Vert.x: HTTP client/server metrics, Net client/server metrics, Pools usage, Eventbus metrics and JVM. The expected metrics are provided by the vertx-micrometer-metrics module. Example with maven:
<dependency>
<groupId>io.vertx</groupId>
<artifactId>vertx-micrometer-metrics</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
Init example of Vert.x metrics, starting a dedicated server (other options are possible):
VertxOptions opts = new VertxOptions().setMetricsOptions(new MicrometerMetricsOptions()
.setPrometheusOptions(new VertxPrometheusOptions()
.setStartEmbeddedServer(true)
.setEmbeddedServerOptions(new HttpServerOptions().setPort(9090))
.setPublishQuantiles(true)
.setEnabled(true))
.setEnabled(true));
Full working example: https://github.com/jotak/bookinfo-runtimes/tree/master/reviews
The pod annotation for Kiali with the full list of dashboards is: kiali.io/dashboards: vertx-client,vertx-server,vertx-eventbus,vertx-pool,vertx-jvm
Custom Dashboards
When the built-in dashboards don’t offer what you need, it’s possible to create your own. See Custom Dashboard Configuration for more information.
3 - Health
Kiali help users know whether their service mesh is healthy. This includes the health of the mesh infrastructure itself, and the deployed application services.
Service Mesh Infrastructure Health
Users can quickly confirm the health of their infrastructure by looking at the Kiali Masthead. If Kiali detects any health issues with the infrastructure of the mesh it will show an indication in the masthead, severity will be reflected via color, and hovring will show the detail:
For more detail on how Kiali tracks the Istio infrastructure status, see the Istio Status Feature.
Overview Health
The default Kiali page is an Overview Dashboard. This view will quickly allow you to identify namespaces with issues. It provides a summary of configuration health, component health and request traffic health. The component health is selectable via a dropdown and the page offers various filter, sort and presentation options:
Graph Health
The Kiali Graph offers a rich visualization of your service mesh traffic. The health of Nodes and Edges is represented via a standard color system using shades of orange and red to reflect degraded and failure-level traffic health. Red or orange nodes or edges may need attention. The color of an edge represents the request health between the relevant nodes. Note that node shape indicates the type of component, such as service, workload, or app.
The health of nodes and edges is refreshed automatically based on the user’s preference. The graph can also be paused to examine a particular state, or replayed to re-examine a particular time period.
Health Configuration
Kiali calculates health by combining the individual health of several indicators, such as pods and request traffic. The global health of a resource reflects the most severe health of its indicators.
Health Indicators
The table below lists the current health indicators and whether the indicator supports custom configuration for its health calculation.
Indicator | Supports Configuration |
---|---|
Pod Status | No |
Traffic Health | Yes |
Icons and colors
Kiali uses icons and colors to indicate the health of resources and associated request traffic.
- No Health Information (NA)
- Healthy
- Degraded
- Failure
Custom Request Health
There are times when Kiali’s default thresholds for traffic health do not work well for a particular situation. For example, at times 404 response codes are expected. Kiali has the ability to set powerful, fine-grained overrides for health configuration. For details, see Traffic Health Configuration.
4 - Internationalization
Kiali is used worldwide and some users prefer to display Kiali in a language that they are more comfortable with than English. For this reason Kiali supports internationalization, and it can be localized into multiple languages.
Current supported languages are English and Chinese.
Language Selector
Kiali provides a language selector in the Masthead to be able to switch Kiali between supported languages:
By default the language selector is hidden, and English is the default language.
In order to show the language selector a feature flag must be enabled in the Kiali CR:
spec:
kiali_feature_flags:
ui_defaults:
i18n:
language: en
show_selector: true
You can also modify the default language shown in Kiali (values according to ISO 639-1 codes):
Language |
Code |
---|---|
Chinese | zh |
English | en |
As an example, this is how Kiali displays the Overview page in Chinese:
If you want to collaborate with us on adding a new language or improving the translation of an existing one, please refer to the internationalization section of the kiali project’s README for UI
5 - Istio Configuration
Kiali is more than observability, it also helps you to configure, update and validate your Istio service mesh.
The Istio configuration view provides advanced filtering and navigation for Istio configuration objects, such as Virtual Services and Gateways. Kiali provides inline config editing and powerful semantic validation for Istio resources.
Validations
Kiali performs a set of validations on your Istio Objects, such as Destination Rules, Service Entries, and Virtual Services. Kiali’s validations go above and beyond what Istio offers. Where Istio offers mainly static checks for well-formed definitions, Kiali performs semantic validations to ensure that the definitions make sense, across objects, and in some cases even across namespaces. Kiali validations are based on the runtime status of your service mesh.
Check the complete list of validations for further information.
Wizards
Kiali Wizards provide a way to apply an Istio service mesh pattern, letting Kiali generate the Istio Configuration. Wizards are launched from Kiali’s Action menus, located across the UI on relevant pages. Wizards can create and update Istio Config for Routing, Gateways, Security scenarios and more.
Istio Config Page Wizards
These Create Actions are available on the Istio Config page:
Authorization Wizards
Kiali allows creation of Istio AuthorizationPolicy resources:
Istio PeerAuthentication resources:
Istio RequestAuthentication resources:
Traffic Wizards
Kiali also allows creation of Istio Gateway resources.
Istio ServiceEntry resources:
Istio Sidecar resources:
Other Kiali Wizards
Kiali also has Wizards available from the Overview page, and many details pages, such as Service Detail to create routing rules. The Kiali Travel Tutorial goes into several of these wizards.
Overview Wizards
The Overview page has namespace-specific actions for creating traffic policies:
Service Wizards
The Service Detail page offers several wizards to create traffic control config:
6 - Istio Infrastructure Status
A service mesh simplifies application services by deferring the non-business logic to the mesh. But for healthy applications the service mesh infrastructure must also be running normally. Kiali monitors the multiple components that make up the service mesh, letting you know if there is an underlying problem.
A component status will be one of: Not found
, Not ready
, Unreachable
, Not healthy
and Healthy
. Not found
means that Kiali is not able to find the deployment. Not ready
means no pods are running. Unreachable
means that Kiali hasn’t been successfully able to communicate with the component (Prometheus, Grafana and Jaeger). Not healthy
means that the deployment doesn’t have the desired amount of replicas running. Otherwise, the component is Healthy
and it won’t be shown in the list.
Regarding the severity of each component, there are only two options: core
or add-on
. The core
components are those shown as errors (in red) whereas the add-ons
are displayed as warnings (in orange).
By default, Kiali checks that the core
components “istiod”, “ingress”, and “egress” are installed and running in the control plane namespace, and that the add-ons
“prometheus”, “grafana” and “jaeger” are available.
Certificate Information Indicators
In some situations, it is useful to get information about the certificates used by internal mTLS, for example:
- Know whether the default CA is used or if there is another CA configured.
- Check the certificates issuer and their validity timestamps to troubleshoot any issue with certificates.
The certificates shown depends on how Istio is configured. The following cases are possible:
- Using Istio CA certificates (default), the information shown is from a secret named istio-ca-secret.
- Using Plug in CA certificates, the information shown is from a secret named cacerts.
- Using DNS certificates, the information shown is from reading many secrets found in Istio configuration.
The following is an example of viewing the default case:
Note that displaying this configuration requires permissions to read secrets (istio-ca-secret by default, possibly cacerts or any secret configured when using DNS certificates).
Having these permissions may concern users. For this reason, this feature is implemented as a feature flag and not only can be disabled, avoiding any extra permissions to read secrets, but also a list of secrets can be configured to explicitly grant read permissions for some secrets in the control plane namespace. By default, this feature is enabled with a Kiali CR configuration equivalent to the following:
spec:
kiali_feature_flags:
certificates_information_indicators:
enabled: true
secrets:
- cacerts
- istio-ca-secret
You can extend this default configuration with additional secrets, remove secrets you don’t want, or disable the feature.
If you add additional secrets, the Kiali operator also needs the same privileges in order to configure Kiali successfully. If you used the Helm Charts to install the operator, specify the secretReader
value with the required secrets:
$ helm install \
--namespace kiali-operator \
--create-namespace \
--set "secretReader={cacerts,istio-ca-secret}"
kiali-operator \
kiali/kiali-operator
If you installed the operator via the OperatorHub you need to update the operator privileges as a post-installation step, as follows:
$ kubectl patch $(kubectl get clusterroles -o name | grep kiali-operator) --type "json" -p '[{"op":"add","path":"/rules/0","value":{"apiGroups":[""],"resources":["secrets"],"verbs":["get"],"resourceNames":["secret-name-to-be-read"]}}]'
Replace secret-name-to-be-read
with the secret name you want the operator to read and restart the Kiali operator pod after running the previous command.
7 - Multi-cluster
A basic Istio mesh deployment has a single control plane with a single data plane, deployed on a single Kubernetes cluster. But Istio supports a variety of advanced deployment models. It allows a mesh to span multiple primary (control plane) and/or remote (data plane only) clusters, and can use a single or multi-network approach. The only strict rule is that within a mesh service names are unique. A non-basic mesh deployment generally involves multiple clusters. See installation instructions for more detail on installing advanced mesh deployments.
A single Kiali install can currently work with at most one mesh, one metric store and one trace store but it can be configured for “single cluster” or “multi-cluster”. All clusters must be part of the same mesh and report to the same metric and trace store, whether directly or via some sort of aggregator. See the multi-cluster configuration page for more information on requirements.
For multi-cluster configurations, Kiali provides a unified view and management of your mesh across clusters.
Graph View: Cluster and Namespace Boxing
Istio provides cluster names in the traffic telemetry for multi-cluster installations. The Kiali graph can use this information to better visualize clusters and namespaces. The Display menu offers two multi-cluster related options: Cluster Boxes and Namespace Boxes. When enabled, either separately or together, the graph will generate boxes to help identify the relevant nodes and edges, and to see traffic traveling between them.
Each box type supports selection and provides a side-panel summary of traffic. Below we see a Bookinfo traffic graph for when Bookinfo services are deployed across the East and West clusters. The West cluster box is selected. You see traffic for all services and workloads across both clusters. Single cluster configurations will show some traffic across clusters but not all.
List View: Mesh Discovery
Kiali will show cluster information for all clusters in the mesh. It will identify the home cluster, meaning the cluster on which it is installed and from which it presents its traffic, traces and Istio config. In the following example there are two clusters defined in the mesh, East and West. East is identified as the home cluster in three places: the browser tab (not shown), the masthead, and with a star icon in the clusters list:
Unified Multi-cluster configuration
Unlike single-cluster configurations, multi-cluster configurations show list/details pages across all clusters.
List Views: Aggregated mesh view
With a multi-cluster Kiali configuration, you can view all apps, workloads, services, and Istio config in your mesh from a single place.
Detail Views: Dig into details across clusters
The detail pages provide the same functionality across all clusters that you have access to for a single cluster, including viewing logs, metrics, traces, envoy details, and more.
Overview: Cross cluster namespace info
The overview page shows namespace information across all configured clusters.
Roadmap
See this issue to see the multi-cluster roadmap for Kiali.
8 - Security
Kiali gives support to better understand how mTLS is used in Istio meshes. Find those helpers in the graph, the masthead menu, the overview page and specific validations.
Masthead indicator
At the right side of the Masthead, Kiali shows a lock when the mesh has strictly enabled mTLS
for the whole service mesh. It means that all the communications in the mesh uses mTLS
.
Kiali shows a hollow lock when either the mesh is configured in PERMISSIVE
mode or there is a misconfiguration in the mesh-wide mTLS
configuration.
Overview locks
The overview page shows all the available namespaces with aggregated data. Besides the health and validations, Kiali shows also the mTLS
status at namespace-wide. Similar to the masthead, it shows a lock when strict mTLS
is enabled or a hollow lock when permissive.
Graph
The mTLS
method is used to establish communication between microservices. In the graph, Kiali has the option to show which edges are using mTLS
and with what percentatge during the selected period. When an edge shows a lock icon it means at least one request with mTLS enabled is present. In case there are both mTLS and non-mTLS requests, the side-panel will show the percentage of requests using mTLS
.
Enable the option in the Display
dropdown, select the security
badge.
Validations
Kiali has different validations to help troubleshoot configurations related to mTLS
such as DestinationRules
and PeerAuthentications
.
9 - Topology
Kiali offers multiple ways for users to examine their mesh Topology. Each combines several information types to help users quickly evaluate the health of their service architecture.
Overview
Kiali’s default page is the topology Overview. It presents a high-level view of the namespaces accessible to Kiali, for this user. It combines service and application information, along with telemetry, validations and health, to provide a holistic summary of system behvior. The Overview page provides numerous filtering, sorting and presentation options. From here users can perform namespace-level Actions, or quickly navigate to more detailed views.
Graph
The Kiali Graph offers a powerful visualization of your mesh traffic. The topology combines real-time request traffic with your Istio configuration information to present immediate insight into the behavior of service mesh, allowing you to quickly pinpoint issues. Multiple Graph Types allow you to visualize traffic as a high-level service topology, a low-level workload topology, or as an application-level topology.
Graph nodes are decorated with a variety of information, pointing out various route routing options like virtual services and service entries, as well as special configuration like fault-injection and circuit breakers. It can identify mTLS issues, latency issues, error traffic and more. The Graph is highly configurable, can show traffic animation, and has powerful Find and Hide abilities.
You can configure the graph to show the namespaces and data that are important to you, and display it in the way that best meets your needs.
Health
Colors in the graph represent the health of your service mesh. A node colored red or orange might need attention. The color of an edge between components represents the health of the requests between those components. The node shape indicates the type of component such as services, workloads, or apps.
The health of nodes and edges is refreshed automatically based on the user’s preference. The graph can also be paused to examine a particular state, or replayed to re-examine a particular time period.
Side-Panel
The collapsible side-panel summarizes the current graph selection, or the graph as a whole. A single-click will select the node, edge, or box of interest. The side panel provides:
- Charts showing traffic and response times.
- Health details.
- Links to fully-detailed pages.
- Response Code and Host breakdowns.
- Traces involving the selected component.
Node Detail
A single-click selects a graph node. A double-click drills in to show the node’s Detail Graph. The node detail graph visualizes traffic from the point-of-view of that node, meaning it shows only the traffic reported by that node’s Istio proxy.
You can return back to the main graph, or double-click to change to a different node’s detail graph.
Traffic Animation
Kiali offers several display options for the graph, including traffic animation.
For HTTP traffic, circles represent successful requests while red diamonds represent errors. The more dense the circles and diamonds the higher the request rate. The faster the animation the faster the response times.
TCP traffic is represented by offset circles where the speed of the circles indicates the traffic speed.
Ranking
Nodes can be ranked in the graph based on pre-defined criteria such as ’number of inbound edges’. Combined with the find/hide feature, this allows you to quickly highlight or filter for important workloads, services, and applications.
Rankings are normalized to fit between 1..100 and nodes may tie with each other in rank. Ranking starts at 1 for the top ranked nodes so when ranking nodes based on ’number of inbound edges’, the node(s) with the most inbound edges would have rank 1. Node(s) with the second most inbound edges would have rank 2. Each selected criteria contributes equally to a node’s ranking. Although 100 rankings are possible, only the required number of rankings are assigned, starting at 1.
Graph Types
Kiali offers four different traffic-graph renderings:
-
The workload graph provides the a detailed view of communication between workloads.
-
The app graph aggregates the workloads with the same app labeling, which provides a more logical view.
-
The versioned app graph aggregates by app, but breaks out the different versions providing traffic breakdowns that are version-specific.
-
The service graph provides a high-level view, which aggregates all traffic for defined services.
Replay
Graph replay allows you to replay traffic from a selected past time-period. This gives you a chance to thoroughly examine a time period of interest, or share it with a co-worker. The graph is fully bookmarkable, including replay.
Operation Nodes
Istio v1.6 introduced Request Classification. This powerful feature allows users to classify requests into aggregates, called “Operations” by convention, to better understand how a service is being used. If configured in Istio the Kiali graph can show these as Operation nodes. The user needs only to enable the “Operation Nodes” display option. Operations can span services, for example, “VIP” may be configured for both CarRental and HotelRental services. To see total “VIP” traffic then display operation nodes without service nodes. To see “VIP” traffic specific to each service then also enable the “Service Nodes” display option.
When selected, an Operation node also provides a side-panel view. And when double-clicked a node detail graph is also provided.
Because operation nodes represent aggregate traffic they are not compatible with Service graphs, which themselves are already logical aggregates. For similar reasons response time information is not available on edges leading into or out of operation nodes. But by selecting the edge the response time information is available in the side panel (if configured).
Operation nodes are represented as pentagons in the Kiali graph:
10 - Tracing
Kiali offers a native integration with two different Distributed Tracing platforms, Jaeger and Grafana Tempo. As such, users can access trace visualizations. But more than that, Kiali incorporates tracing into several correlated views, making your investment in trace data even more valuable.
For a quick glimpse at Kiali tracing features, see below. For a detailed explanation of tracing in Kiali, see this 3-part Trace my mesh blog series. There is a detailed guide to configure access to the different distributed tracing platform, Jaeger and Grafana Tempo.
Workload detail
When investigating a workload, click the Traces tab to visualize your traces in a chart. When selecting a trace Kiali presents a tab for trace detail, and a tab for span details. Kiali always tries to surface problem areas, Kiali uses a heatmap approach to help the user identify problem traces or spans.
Heatmaps
A heatmap that you see in the Workload’s Tracing tab is a matrix that compares a specific trace’s request duration against duration metrics aggregated over time.
Each trace has a corresponding heatmap matrix. Each cell in the matrix corresponds to a specific metric aggregate; the value and color of a cell represents the difference between that metric and the duration of the matrix’s associated trace.
For example, the top-right cell of the heatmap above shows that the duration of the request represented by the trace (5.96ms) was 17.5ms faster than the 99th percentile of all inbound requests to the workload within the last 10 minutes.
The color of a cell will range between red and green; the more green a cell is, the faster the duration of the trace was compared to the aggregate metric data. A red cell indicates the associated trace was much slower compared to the aggregate metric data and so examining that trace could help detect a potential bottleneck or problem.
Metric Correlation
Kiali offers span overlays on Metric charts. The user can simply enable the spans
option to generate the overlay. Clicking any
span will navigate back to the Traces tab, focused on the trace of interest.
Graph Correlation
Kiali users often use the Graph Feature to visualize their mesh traffic. In the side panel, When selecting a graph node, the user will be presented with a Traces tab, which lists available traces for the time period. When selecting a trace the graph will display an overlay for the trace’s spans. And the side panel will display span details and offer links back to the trace detail views.
Logs Correlation
Kiali works to correlate the standard pillars of observability: traces, metrics and logs. Kiali can present a unified view of
log and trace information, in this way letting users use logs to identify traces of interest. When enabling the spans
option
Kiali adds trace entries to the workload logs view. Below, in time-sorted order, the user is presented with a unified view of application
logs (in white), Envoy proxy logs (in gold), and trace spaces (in blue). Clicking a span of interest brings you to the detail
view for the trace of interest.
11 - Validation
Kiali performs a set of validations on your Istio Objects, such as Destination Rules, Service Entries, and Virtual Services. Kiali’s validations go above and beyond what Istio offers. Where Istio offers mainly static checks for well-formed definitions, Kiali performs semantic validations to ensure that the definitions make sense, across objects, and in some cases even across namespaces. Kiali validations are based on the runtime status of your service mesh.
The complete list of validations:
AuthorizationPolicy
KIA0101 - Namespace not found for this rule
AuthorizationPolicy enables access control on workloads. Each policy effects only to a group of request. For instance, all requests started from a workload on a list of namespaces. The present validation points out those rules referencing a namespace that don’t exist in the cluster.
Resolution
Either remove the namespace from the list, correct if there is any typo or create a new namespace.
Severity
Warning
Example
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: default
spec:
selector:
matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces:
- default
- non-existing # warning
- unexisting # warning
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
See Also
KIA0102 - Only HTTP methods and fully-qualified gRPC names are allowed
An AuthorizationPolicy has an Operation field where is defined the oprations allowed for a request. In the method field are listed all the allowed methods that request can have. This validation appears when a problem is found in there. The only methods accepted are: either HTTP valid methods or fully-qualified names of gRPC service in the form of “/package.service/method”
Resolution
Either change or remove the violating method. It has to be either a HTTP valid method or a fully-qualified names of a gRPC service in the form of “/package.service/method”
Severity
Warning
Example
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: default
spec:
selector:
matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces:
- default
to:
- operation:
methods:
- "GET"
- "/package.service/method"
- "WRONG" # Warning
- "non-fully-qualified-grpc" # Warning
paths: ["/info*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
See Also
KIA0104 - This host has no matching entry in the service registry
AuthorizationPolicy enables access control on workloads. Each policy effects only to a group of request going to a specific destination. For instance, allow all the request going to details
host.
The present validation points out those rules referencing a host that don’t exist in the authorization policy namespace. Kiali considers services, virtual services and service entries. Those hosts that refers to hosts outside of the object namespace will be presented with an unknown error.
Resolution
Either remove the host from the list, correct if there is any typo or deploy a new service, service entry or a virtual service pointing to that host.
Severity
Error
Example
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: default
spec:
selector:
matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces:
- default
to:
- operation:
hosts:
- wrong # Error
- ratings
- details.default
- reviews.default.svc.cluster.local
- productpage.outside # Unknown
- google.com # Service Entry present. No error
- google.org # Service Entry not present, wrong domain. Error.
methods:
- "GET"
- "/package.service/method"
paths: ["/info*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
See Also
- Validator source code
- AuthorizationPolicy documentation
- Definition of the operations field
- Service association requirement
KIA0105 - This field requires mTLS to be enabled
AuthorizationPolicy has a Source field, where specifies the source identities of a request. In a Source field it accepts the principals and the namespaces, which requires mTLS enabled.
A validation Error message on a principals or namespaces fields means, that mTLS is not enabled.
This validation appears only when autoMtls is disabled.
Resolution
Either remove this field or enable autoMtls.
Severity
Error
Example
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: bookinfo
spec:
selector:
matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces:
- default
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
- operation:
methods: ["POST"]
paths: ["/data"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
See Also
- AuthorizationPolicy documentation
- Definition of the Source field
- Service association requirement
- Globally enabling Istio mutual TLS
KIA0106 - Service Account not found for this principal
AuthorizationPolicy has a Source field, where specifies the source identities of a request.
In a Source field it accepts the principals, a list of peer identities derived from the peer certificate. The peer identity is in the format of <TRUST_DOMAIN>/ns/<NAMESPACE>/sa/<SERVICE_ACCOUNT>
, for example, cluster.local/ns/default/sa/productpage
.
A validation Error message on a principal value means, that the specified Service Account was not found in a given Namespace.
Resolution
Correct the principal to refer to existing Service Account, make sure that the value is in correct format without a typo.
Severity
Error
Example
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: default
spec:
selector:
matchLabels:
app: httpbin
version: v1
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
- source:
namespaces:
- default
to:
- operation:
hosts:
- ratings
- details.default
- reviews.default.svc.cluster.local
methods:
- "GET"
paths: ["/info*"]
- operation:
methods: ["POST"]
when:
- key: request.auth.claims[iss]
values: ["https://accounts.google.com"]
See Also
Destination rules
KIA0201 - More than one DestinationRules for the same host subset combination
Istio applies traffic rules for services after the routing has happened. These can include different settings such as connection pooling, circuit breakers, load balancing, and detection. Istio can define the same rules for all services under a host or different rules for different versions of the service.
This validation warning could be a result of duplicate definition of the same subsets as well as from rules that apply to all subsets. Also, a combination of one Destination Rule (DR) applying to all subsets and another defining behavior for only some subsets triggers this validation warning.
Istio silently ignores the duplicate subsets and merge these destination rules without letting the user know. Only the first seen rule (by Istio) per subset is used and information from multiple definitions is not merged. While the routing might work correctly, this is most likely a configuration error. It may lead to a undesired behavior if one of the offending rules is removed or modified and that is probably not the intention of the deployer of this service. Also, if the two offending destination rules have different policies for traffic routing the wrong one might be used.
Resolution
Either merge the settings to a single DR or split the subsets in such a way that they do not interleave. This ensures that the routing behavior stays consistent.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-dr1
spec:
host: reviews
trafficPolicy:
loadBalancer:
simple: RANDOM
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-dr2
spec:
host: reviews
trafficPolicy:
loadBalancer:
simple: RANDOM
subsets:
- name: v1
labels:
version: v1
See Also
- Validator source code
- Destination rule documentation
- Istio source code for merging
- Istio documentation: Split large virtual services and destination rules into multiple resources
KIA0202 - This host has no matching entry in the service registry (service, workload or service entries)
Istio applies traffic rules for services after the routing has happened. These can include different settings such as connection pooling, circuit breakers, load balancing, and detection. Istio can define the same rules for all services under a host or different rules for different versions of the service. The host must have a service that is defined in the platform’s service registry or as a ServiceEntry. Short names are extended to include ‘.namespace.cluster’ using the namespace of the destination rule, not the service itself. FQDN is evaluated as is. It is recommended to use the FQDN to prevent any confusion.
If the host is not found, Istio ignores the defined rules.
Resolution
Correct the host to point to a correct service, in this namespace or with FQDN to other namespaces, or deploy the missing service to the mesh.
Severity
Error
There is an exception to the severity level: It will be shown as a Warning when OutboundTrafficPolicy Mode for MeshConfig is set to ALLOW_ANY.
Example
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: notpresent
trafficPolicy:
loadBalancer:
simple: RANDOM
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
See Also
KIA0203 - This subset’s labels are not found in any matching host
Istio applies traffic rules for services after the routing has happened. These can include different settings such as connection pooling, circuit breakers, load balancing, and detection. Istio can define the same rules for all services under a host or different rules for different versions of the service. The host must a service that is defined in the platform’s service registry or as a ServiceEntry. Short names are extended to include ‘.namespace.cluster’ using the namespace of the destination rule, not the service itself. FQDN is evaluated as is. It is recommended to use the FQDN to prevent any confusion.
Subsets can override the global settings defined in the DR for a host.
If the host is not found, Istio ignores the defined rules.
If the not found subset is not referenced in any Virtual Service, the severity of this error is changed to Info.
Resolution
Correct the host to point to a correct service, in this namespace or with FQDN to other namespaces, or deploy the missing service to the mesh. If the hostname is equal to the one used otherwise in the DR, consider removing the duplicate host resolution.
Also, verify that the labels are correctly matching a workload with the intended service.
Severity
Error
Example
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
loadBalancer:
simple: RANDOM
subsets:
- name: v1
labels:
version: v10
- name: v2
labels:
notfoundlabel: v2
- name: v3
labels:
version: v3
See Also
KIA0204 - mTLS settings of a non-local Destination Rule are overridden
Istio allows you to define DestinationRule at three different levels: mesh, namespace and service level. A mesh may have multiple DRs. In case of having two DestinationRules on the first one is at a lower level than the second one, the first one overrides the TLS values of the second one.
Resolution
This validation aims to warn Kiali users that they may be disabling/enabling mTLS from the higher DestinationRule. Merging the TLS settings to one of the DestinationRules is the only way to fix this validation. However, this is a valid scenario so it might be impossible to remove this warning.
Severity
Warning
Example
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "default"
namespace: "istio-system"
spec:
host: "*.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
loadBalancer:
simple: RANDOM
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
See Also
KIA0205 - PeerAuthentication enabling mTLS at mesh level is missing
Istio has the ability to define mTLS communications at mesh level. In order to do that, Istio needs one DestinationRule and one PeerAuthentication. The DestinationRule configures all the clients of the mesh to use mTLS protocol on their connections. The PeerAuthentication defines what authentication methods that can be accepted on the workload of the whole mesh. If the PeerAuthentication is not found or doesn’t exist and the mesh-wide DestinationRule is on ISTIO_MUTUAL mode, all the communication returns 500 errors.
Resolution
Add a PeerAuthentication within the istio-system
namespace without specifying targets but setting peers mtls mode to STRICT or PERMISSIVE. The PeerAuthentication should be like this.
Severity
Error
Example
# AutoMtls disabled, no PeerAuthentication at mesh-level defined
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "default"
namespace: "istio-system"
spec:
host: "*.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
See Also
KIA0206 - PeerAuthentication enabling namespace-wide mTLS is missing
Istio has the ability to define mTLS communications at namespace level. In order to do that, Istio needs both a DestinationRule and a PeerAuthentication targeting all the clients/workloads of the specific namespace. The PeerAuthentication allows mTLS authentication method for all the workloads within a namespace. The DestinationRule defines all the clients within the namespace to start communications in mTLS mode. If the PeerAuthentication is not found and the DestinationRule is on STRICT mode in that namespace but there is the DestinationRule enabling mTLS, all the communications within that namespace returns 500 errors.
Resolution
A PeerAuthentication enabling mTLS method is needed for the workloads in the namespace. Otherwise all the clients start mTLS connections that those workloads won’t be ready to manage. Add a PeerAuthentication without specifying targets but setting mTLS mode to STRICT or PERMISSIVE in the same namespace as the DestinationRule.
Severity
Error
Example
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "enable-mtls"
namespace: "bookinfo"
spec:
host: "*.bookinfo.svc.cluster.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
See Also
KIA0207 - PeerAuthentication with TLS strict mode found, it should be permissive
Istio needs both a DestinationRule and PeerAuthentication to enable mTLS communications. The PeerAuthentication configures the authentication method accepted for all the targeted workloads. The DestinationRule defines which is the authentication method that the clients of specific workloads has to start communications with.
Resolution
Kiali has found that there is a DestinationRule sending traffic without mTLS authentication method. There are two different ways to fix this situation. You can either change the PeerAuthentication applying to PERMISSIVE mode or change the DestinationRule to start communications using mTLS.
Severity
Error
Example
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "disable-mtls"
namespace: "bookinfo"
spec:
host: "*.bookinfo.svc.cluster.local"
trafficPolicy:
tls:
mode: DISABLE
---
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: "default"
namespace: "bookinfo"
spec:
peers:
- mtls:
mode: STRICT
See Also
KIA0208 - PeerAuthentication enabling mTLS found, permissive mode needed
Istio needs both a DestinationRule and PeerAuthentication to enable mTLS communications. The PeerAuthentication configures the authentication method accepted for all the targeted workloads. The DestinationRule defines which is the authentication method that the clients of specific workloads has to start communications with.
Kiali found a DestinationRule starting communications without TLS but there was a PeerAuthentication allowing all services in the mesh to accept only requests in mTLS.
Resolution
There are two ways to fix this situation. You can either change the PeerAuthentication to enable PERMISSIVE mode to all the workloads in the mesh or change the DestinatonRule to enable mTLS instead of disabling it (change the mode to ISTIO_MUTUAL).
Severity
Error
Example
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "default"
namespace: "bookinfo"
spec:
host: "*.bookinfo.svc.cluster.local"
trafficPolicy:
tls:
mode: DISABLE
---
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: STRICT
See Also
KIA0209 - DestinationRule Subset has not labels
A DestinationRule subset without labels may miss the destination endpoint linked with a specific workload.
If there is any other subset with valid labels, the severity of this warning is changed to Info.
Resolution
Validate that a subset is properly configured.
Severity
Warning
See Also
K8s Gateway API
Note that with the support of K8s Gateway API, a new mechanism of subsetting is introduced. Which means, that each version of a service should have a separate Service pointing to that particular version. And instead of the usage of DestinationRules, there should be a K8s HTTPRoute object created, referencing to Services per version in it’s rules.
See Also
Gateways
KIA0301 - More than one Gateway for the same host port combination
Gateway creates a proxy that forwards the inbound traffic for the exposed ports. If two different gateways expose the same ports for the same host, this creates ambiguity inside Istio as either of these gateways could handle the traffic. This is most likely a configuration error. This check is done across all namespaces the user has access to.
There is one exception: when both gateways points to a different ingress. Then the ambiguity doesn’t exist and, in consequence, no validation is shown. Kiali considers that two gateways points to the same ingress if they share the exact same selector.
Resolution
Remove the duplicate gateway entries or merge the two gateway definitions into a single one.
OR
When one of the duplicate Gateways has a wildcard in hosts, there is an option ‘skip_wildcard_gateway_hosts’ in Kiali CR, by setting it to ’true’, it will ignore Gateways with wildcards in hosts during validation. As Istio considers such a Gateway with a wildcard in hosts as the last in order, after the Gateways with FQDN in hosts.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway # Validation shown
namespace: bookinfo
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway-copy # Validation shown
namespace: bookinfo2
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway-diff-ingress # No validations shown
namespace: bookinfo
spec:
selector:
istio: ingressgateway-pub # Using different ingress
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
See Also
KIA0302 - No matching workload found for gateway selector in this namespace
This validation checks the current namespace for matching workloads as this is recommended, and potentially in the future required, by the Istio. Excluded from this check are the default “istio-ingressgateway” and “istio-egressgateway” workloads which are included in Istio by default.
Although your traffic might be correctly routed to a workload in other namespace, this is not a guaranteed behavior and thus a warning is flagged in such cases also.
Resolution
Deploy the missing workload or fix the selector to target a correct location.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway
namespace: bookinfo
spec:
selector:
app: nonexisting # workload doesn't exist in the namespace
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
See Also
Mesh Policies
KIA0401 - Mesh-wide Destination Rule enabling mTLS is missing
Istio has the ability to define mTLS communications at mesh level. In order to do that, Istio needs one DestinationRule and one PeerAuthentication. The DestinationRule configures all the clients of the mesh to use mTLS protocol on their connections. The PeerAuthentication defines what authentication methods can be accepted on the workload of the whole mesh. If the DestinationRule is not found or doesn’t exist and the PeerAuthentication is on STRICT mode, all the communication returns 500 errors.
Resolution
Add a DestinationRule with “*.cluster” host and ISTIO_MUTUAL as tls trafficPolicy mode. The DestinationRule should be like this.
Severity
Error
Example
# Make sure there isn't any DestinationRule enabling meshwide mTLS
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: STRICT
See Also
PeerAuthentication
KIA0501 - Destination Rule enabling namespace-wide mTLS is missing
Istio has the ability to define mTLS communications at namespace level. In order to do that, Istio needs one DestinationRule and one PeerAuthentication. The DestinationRule configures all the clients of the namespace to use mTLS protocol on their connections. The PeerAuthentication defines what authentication methods can be accepted on a specific group of workloads. PeerAuthentications without target field specified will target all the workloads within its namespace. If the DestinationRule is not found or doesn’t exist in the namespace and the namespace-wide PeerAuthentication is on STRICT mode, all the communication will return 500 errors.
Resolution
Add a DestinationRule with “*.namespace.svc.cluster.local” host and ISTIO_MUTUAL as tls trafficPolicy mode. The DestinationRule should be like this.
Severity
Error
Example
# Make sure there isn't any DestinationRule enabling meshwide mTLS
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "bookinfo"
spec:
mtls:
mode: STRICT
See Also
KIA0505 - Destination Rule disabling namespace-wide mTLS is missing
PeerAuthentication objects are used to define the authentication methods that a set of workloads can accept: Mutual, Istio Mutual, Simple or Disabled.
This validation warns the scenario where there is one PeerAuthentication at namespace level with DISABLE
mode but there is DestinationRule at namespace or mesh level enabling mTLS. With this scenario, all the traffic flowing between the services in that namespace will fail.
Resolution
You can either change the namespace/mesh-wide Destination Rule to DISABLE
mode or change the current PeerAuthentication to allow mTLS (mode STRICT
or PERMISSIVE
).
Severity
Error
Example
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "bookinfo"
spec:
mtls:
mode: DISABLE
---
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "enable-mtls"
namespace: bookinfo
spec:
host: "*.bookinfo.svc.cluster.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
See Also
KIA0506 - Destination Rule disabling mesh-wide mTLS is missing
PeerAuthentication objects are used to define the authentication methods that a set of workloads can accept: Mutual, Istio Mutual, Simple or Disabled.
This validation warns the scenario where there is one PeerAuthentication at mesh level with DISABLE
mode but there is DestinationRule at mesh level enabling mTLS. With this scenario, all the traffic flowing between the services in that namespace will fail.
Resolution
You can either change the mesh-wide Destination Rule to DISABLE
mode or change the current PeerAuthentication to allow mTLS (mode STRICT
or PERMISSIVE
).
Severity
Error
Example
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: DISABLE
---
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "enable-mtls"
namespace: bookinfo
spec:
host: "*.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
See Also
Ports
KIA0601 - Port name must follow [-suffix] form
Istio requires the service ports to follow the naming form of ‘protocol-suffix’ where the ‘-suffix’ part is optional. If the naming does not match this form (or is undefined), Istio treats all the traffic TCP instead of the defined protocol in the definition. Dash is a required character between protocol and suffix. For example, ‘http2foo’ is not valid, while ‘http2-foo’ is (for http2 protocol).
Resolution
Rename the service port name field to follow the form and the traffic flows correctly.
Severity
Error
Example
apiVersion: v1
kind: Service
metadata:
name: ratings-java-svc
namespace: bookinfo
labels:
app: ratings
service: ratings-svc
spec:
ports:
- port: 9080
name: wrong-http
selector:
app: ratings-java
version: v1
See Also
KIA0602 - Port appProtocol must follow form
Istio also optionally supports the appProtocol in service ports, following the form of ‘protocol’. When port name field does not contain the protocol the appProtocol field is considered as a protocol. If the naming does not match this form, Istio treats all the traffic TCP instead of the defined protocol in the definition.
Resolution
Rename the service port appProtocol field to follow the form and the traffic flows correctly.
Severity
Error
Example
apiVersion: v1
kind: Service
metadata:
name: ratings-java-svc
namespace: bookinfo
labels:
app: ratings
service: ratings-svc
spec:
ports:
- port: 3306
name: database
appProtocol: wrong-mysql
selector:
app: ratings-java
version: v1
See Also
Services
KIA0701 - Deployment exposing same port as Service not found
Service definition has a combination of labels and port definitions that are not matching to any workloads. This means the deployment will be unsuccessful and no traffic can flow between these two resources. The port is read from the Service ‘TargetPort’ definition first and if undefined, the ‘Port’ field is used as Kubernetes defaults the ‘TargetPort’ to ‘Port’. If the ‘TargetPort’ is using a integer, the port numbers are compared and if the ‘TargetPort’ is a string, the deployment’s portName is used for comparison.
Resolution
Fix the port definitions in the workload or in the service definition to ensure they match.
Severity
Warning
Example
Invalid example with port definitions unmatched:
apiVersion: v1
kind: Service
metadata:
name: ratings-java-svc
namespace: ratings-java
labels:
app: ratings
service: ratings-svc
spec:
ports:
- port: 9080
name: http
selector:
app: ratings-java
version: v1
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ratings-java
namespace: ratings-java
labels:
app: ratings-java
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "true"
labels:
app: ratings-java
version: v1
spec:
containers:
- name: ratings-java
image: pilhuhn/ratings-java:f
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
Valid example using targetPort definition matching:
apiVersion: v1
kind: Service
metadata:
name: ratings-java-svc
namespace: ratings-java
labels:
app: ratings
service: ratings-svc
spec:
ports:
- port: 9080
targetPort: 8080
name: http
selector:
app: ratings-java
version: v1
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: ratings-java
namespace: ratings-java
labels:
app: ratings-java
version: v1
spec:
replicas: 1
template:
metadata:
annotations:
sidecar.istio.io/inject: "true"
labels:
app: ratings-java
version: v1
spec:
containers:
- name: ratings-java
image: pilhuhn/ratings-java:f
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
See Also
Sidecars
KIA1004 - This host has no matching entry in the service registry
The Sidecar resources are used for configuring the sidecar proxies in the service mesh. IstioEgressListener specifies the properties of an outbound traffic listener on the sidecar proxy attached to a workload instance.
In the hosts field, there is the list of hosts exposed to the workload. Each host in the list have the namespace/dnsName
format where both namespace and dnsName may have non-obvious values. namespace
may be either .
, ~
, *
or an actual namespace name. dnsName
has to be a FQDN representing a service, virtual service or a service entry. This FQDN may use the wildcard character.
See more information about the syntax of both namespace
and dnsName
into istio documentation.
Resolution
Make sure there is a service, virtual service or service entry matching with the host.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: servicenotfound
namespace: bookinfo
spec:
workloadSelector:
labels:
app: reviews
egress:
- port:
number: 3306
protocol: MYSQL
name: egressmysql
captureMode: NONE
bind: 127.0.0.1
hosts:
- "bookinfo/*.bookinfo.svc.cluster.local" # Bookinfo running into bookinfo ns
- "default/kiali.io" # Service entry present in the namespace
- "bookinfo/bogus.bookinfo.svc.cluster.local" # Bogus service into bookinfo doesn't exist
- "bogus-ns/reviews.bookinfo.svc.cluster.local" # Cross-namespace validation: unable to verify validity
See Also
KIA1006 - Global default sidecar should not have workloadSelector
The Sidecar resources are used for configuring the sidecar proxies in the service mesh. By default, all the sidecars are configured with the default sidecar instance specified in the control plane namespace (usually istio-system). In case there are sidecar resources in the namespaces where your applications are, this default sidecar resource won’t be considered. The sidecar in your namespace will be applied.
Having workloadSelector
in your global default sidecar won’t make any effect in the other sidecars living outside of the control plane namespace.
Resolution
Make sure you don’t have the workloadSelector
in this global sidecar resource. In case you need specific settings for specific workloads, move those settings to the sidecar resources in your application namespaces.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: istio-system
spec:
workloadSelector: # Default sidecar can't have labels
labels:
version: v1
egress:
- port:
number: 3306
protocol: MYSQL
name: egressmysql
captureMode: NONE
bind: 127.0.0.1
hosts:
- "bookinfo/reviews.bookinfo.svc.cluster.local"
- "bookinfo/details.bookinfo.svc.cluster.local"
See Also
KIA1007 - OutboundTrafficPolicy shown with empty mode value is ambiguous
Due to issues with the Istio client and the protobuf library it uses, the way some defaults are handled becomes ambiguous. When a Sidecar resource spec.outboundTrafficPolicy.mode
is left unset or is explicitly set to REGISTRY_ONLY, the Kiali UI will show the value as unset (e.g. if nothing is set inside outboundTrafficPolicy
, its value will be shown as {}
). In this case, you are not guaranteed to know what the value of mode
truly is. So in the case where Kiali UI shows mode
as empty, you cannot know if Istio will be using a value of REGISTRY_ONLY or ALLOW_ANY.
Resolution
You cannot determine the value of mode
using the Kiali UI when this condition arises. You must inspect the Sidecar object using other means to determine the value (e.g. use kubectl get sidecar your-side-car-name -o jsonpath='{.spec.outboundTrafficPolicy.mode}'
).
Severity
Informational
Example
Both of these Sidecar resources will show mode
as unset/empty in the Kiali UI YAML editor:
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
...
spec:
outboundTrafficPolicy:
mode: REGISTRY_ONLY
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
...
spec:
# according to Istio documentation, the default will be ALLOW_ANY
outboundTrafficPolicy: {}
See Also
VirtualServices
KIA1101 - DestinationWeight on route doesn’t have a valid service (host not found)
VirtualService routes matching requests to a service inside your mesh. Routing can also match a subset of traffic to a certain version of it for example. Any service inside the mesh must be targeted by its name, the IP address are only allowed for hosts defined through a Gateway. Host must be in a short name or FQDN format. Short name will evaluate to VS’ namespace, regardless of where the actual service might be placed.
If the host is not found, Istio ignores the defined rules. However, if a subset with a Destination Rule is not found it affects all the subsets and all the routings. As such, care must be taken that the Destination rule is available before deploying the Virtual Service.
Resolution
Correct the host to point to a correct service (in this namespace or with FQDN to other namespaces), deploy the missing service to the mesh or remove the configuration linking to that non-existing service.
Severity
Error
Example
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: details
spec:
hosts:
- details
http:
- route:
- destination:
host: nonexistentsvc
subset: v2
See Also
KIA1102 - VirtualService is pointing to a non-existent gateway
By default, VirtualService routes apply to sidecars inside the mesh. The gateway field allows to override that default and if anything is defined, the VS applies to those selected. ‘mesh’ is a reserved gateway name and means all the sidecars in the mesh. If one wishes to apply the VS to gateways as well as the sidecars, the ‘mesh’ keyword must be used as one of the gateways. Incorrect gateways mean that the VS is not applied correctly.
Resolution
Fix the possible gateway field to target all necessary gateways or remove the field if the default ‘mesh’ is enough.
Severity
Error
Example
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: details
spec:
hosts:
- details
gateways:
- non-existent-gateway
http:
- route:
- destination:
host: details
subset: v1
See Also
KIA1104 - The weight is assumed to be 100 because there is only one route destination
Istio assumes the weight to be 100 when there is only one HTTPRouteDestination or RouteDestination. The warning is present because there is one route with a weight less than 100.
Resolution
Either remove the weight field or you might want to add another RouteDestination with an specific weight.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 10
See Also
- Istio documentation about HTTP Route Destination struct
- Istio documentation about Route Destination struct
- Validator source code
KIA1105 - This host subset combination is already referenced in another route destination
Istio allows you to apply rules over the traffic targetting to a specific service. In order to achieve that, it is necessary to add those rules into either http, tcp or tls fields in a VirtualService. In each field it is possible to specify rules for redirection or forwarding traffic. Those rules are the RouteDestination and HTTPRouteDestination structs. Each structs defines where the traffic is shifted to using host and subset fields. This warning message refers to the fact of referencing one host subset combination more than one time within the same route. Galley, Istio module in charge of configuration validation, allows host subset combination duplicity. However, the mesh it might become broken when there are different duplicates. Also, the presented warning might help spoting a typo.
Resolution
Make sure there is only one reference to the same host subset combination for each RouteDestination. Either HTTPRouteDestination or RouteDestination.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 80
- destination:
host: reviews
subset: v2 # duplicate
weight: 10
- destination:
host: reviews
subset: v2 # duplicate
weight: 10
See Also
- Istio documentation about HTTP Route Destination struct
- Istio documentation about Route Destination struct
- Validator source code
KIA1106 - More than one Virtual Service for same host
A VirtualService defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry.
Resolution
This is a valid configuration only if two VirtualServices share the same host but are bound to a different gateways, sidecars do not accept this behavior. There are several caveats when using this method and defining the same parts in multiple Virtual Service definitions is not recommended. While Istio will merge the configuration, it does not guarantee any ordering for cross-resource merging and only the first seen configuration is applied (rest ignored). As recommended, each VS definition should have a ‘catch-all’ situation, but this can only be defined in a definition affecting the same host.
Severity
Warning
Example
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews-cp
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
See Also
- Istio documentation: Split large virtual services and destination rules into multiple resources
- Validator source code
KIA1107 - Subset not found
VirtualService routes matching requests to a service inside your mesh. Routing can also match a subset of traffic to a certain version of it for example. The subsets referred in a VirtualService have to be defined in one DestinationRule.
If one route in the VirtualService points to a subset that doesn’t exist Istio won’t be able to send traffic to a service.
Resolution
Fix the routes that points to a non existing subsets. It might be fixing a typo in the subset’s name or defining the missing subset in a DestinationRule.
Severity
Error
Example
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: nosubset
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
See Also
KIA1108 - Preferred nomenclature: /
A virtual service may include a list of gateways which the defined routes should be applied to. Gateways in other namespaces may be referred to by
Resolution
Move the nomenclature of the gateways into the supported Istio form:
Example
kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
name: bookinfo
namespace: bookinfo
spec:
hosts:
- '*'
gateways:
- bookinfo-gateway.bookinfo.svc.cluster.local # unsupported format
- bookinfo/bookinfo-gateway # works
http:
- match:
- uri:
exact: /productpage
- uri:
prefix: /static
- uri:
exact: /login
- uri:
exact: /logout
- uri:
prefix: /api/v1/products
route:
- destination:
host: productpage
port:
number: 9080
---
kind: Gateway
apiVersion: networking.istio.io/v1alpha3
metadata:
name: bookinfo-gateway
namespace: bookinfo
spec:
servers:
- hosts:
- '*'
port:
name: http
number: 80
protocol: HTTP
selector:
istio: ingressgateway
See Also
WorkloadEntries
KIA1201 - Missing one or more addresses from matching WorkloadEntries
This validation shows, that the address field’s value of Workload Entry is not matching to any address of Service Entry.
Resolution
Add missing Service Entry which address will match the Workload Entry’s address.
Severity
Warning
Example
apiVersion: networking.istio.io/v1beta1
kind: WorkloadEntry
metadata:
name: ratings-v1
namespace: bookinfo
spec:
serviceAccount: ratings-vm
address: 3.3.3.3
labels:
app: ratings
version: v1
ports:
http: 9080
---
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: ratings-unmatching-address
namespace: bookinfo
spec:
addresses:
- 4.4.4.4 # This IP is not in any WorkloadEntry. It needs 3.3.3.3 to work.
hosts:
- ratings
location: MESH_INTERNAL
resolution: STATIC
ports:
- number: 9080
name: http
protocol: HTTP
targetPort: 9080
workloadSelector:
labels:
app: ratings-unmatching
See Also
K8s HTTPRoutes
KIA1401 - HTTPRoute is pointing to a non-existent K8s gateway
Gateway API HTTPRoute could be pointing to a [k8s] Gateway that the Route wants to be attached to. When the namespace field is not specified it takes Gateways from the current HTTPRoute’s namespace. Here the error indicates that the referenced Gateway is not found in the provided namespace.
Resolution
Fix the parentRefs field to target to an existing gateway.
Severity
Error
Example
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1alpha2
metadata:
name: httproute
namespace: bookinfo
spec:
parentRefs:
- group: gateway.networking.k8s.io
kind: Gateway
namespace: istio-system
name: gatewayapi
hostnames:
- details
See Also
KIA1402 - BackendRef on rule doesn’t have a valid service (Service name not found)
Gateway API HTTPRoute could be pointing to a Service inside your mesh the Route sends the traffic to. A Service name should be specified, not a hostname. This Service can be a certain version of a parent Service, but in that case a separate Service is required to be created. When the namespace field is not specified it takes Service from the current HTTPRoute’s namespace. In a case of referencing to a Service from remote namespace, a ReferenceGrant object needs to be created to enable cross namespace references. Here the error indicates that the referenced Service is not found in the provided namespace or the ReferenceGrant is missing (in a case of remote namespace).
Resolution
Correct the backendRefs name to point to a correct Service (in this namespace or to other namespaces):
- Deploy the missing Service to the mesh, create a ReferenceGrant object in a case of remote namespace.
- Or remove the configuration linking to that non-existing Service.
Severity
Error
Example
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1alpha2
metadata:
name: httproute
namespace: bookinfo
spec:
parentRefs:
- group: gateway.networking.k8s.io
kind: Gateway
namespace: istio-system
name: gatewayapi
hostnames:
- reviews
rules:
- matches:
- path:
type: PathPrefix
value: /get
backendRefs:
- group: ''
kind: Service
name: reviews-v1
namespace: default
port: 9080
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
name: refgrant
namespace: default
spec:
from:
- group: gateway.networking.k8s.io
kind: HTTPRoute
namespace: bookinfo
to:
- group: ""
kind: Service
See Also
Workloads
KIA1301 - This workload is not covered by any authorization policy
Istio Authorization Policy enables access control on workloads in the mesh. Auth Policy selector will match with workloads in the same namespace as the authorization policy. If the authorization policy is in the root namespace, the selector will additionally match with workloads in all namespaces. This validation shows, that the selector match did not happen.
Resolution
Add Autorization Policy which selector matches with Workload’s label selector.
Severity
Warning
See Also
Generic
KIA0002 - More than one selector-less object in the same namespace
This validation refers to the usage of the selector
. Selector-less Istio objects are those objects that don’t have the selector
field specified. Therefore, objects that apply to all the workloads of a namespace (or whole mesh if the namespace is the same as the control plane namespace).
This validation warns you that you have two different objects living in the same namespace. This may leave an non-deterministic or unexpected behavior on the workloads of the namespace.
Resolution
The natural solution is to merge both objects. In case there are different behaviors you want to apply, consider to define the selector
field targeting a specific set of workloads.
Severity
Error
Example
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "bookinfo"
spec:
mtls:
mode: STRICT
---
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "duplicate"
namespace: "bookinfo"
spec:
mtls:
mode: STRICT
See Also
KIA0003 - More than one object applied to the same workload
This validation refers to the usage of the selector
. In this field are defined the labels of the workloads that this object will be applied to. It might be one or more workloads in the same namespace.
This validation warns the scenario where there are two different objects applying to the same workload(s). This may leave an undeterministic or unexpected behavior on the workloads of the namespace.
Resolution
There isn’t a standard solution for that. It is a good practice not to have multiple rules of the same kind applying to the same workloads. Otherwise you would end up having interferences between objects and having troubles when debugging. The first approach would be to merge both objects into one if possible. The second approach would be to reorganize the objects of the same kind in a way that each one only applies to a different set of workloads. Applying no change into the objects is also an option although not desiderable.
Severity
Error
Example
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "productpage"
namespace: "bookinfo"
spec:
selector:
matchLabels:
app: productpage
mtls:
mode: STRICT
---
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "productpage-disable-80"
namespace: "bookinfo"
spec:
selector:
matchLabels:
app: productpage
version: v1
mtls:
mode: STRICT
portLevelMtls:
80:
mode: DISABLE
See Also
KIA0004 - No matching workload found for the selector in this namespace
This validation warns the scenario where there are not workloads matching with the selector
labels. In other terms, this object doesn’t have any implication into the mesh.
Resolution
There are three scenarios: either change the labels to match an existing workload (useful with typos), deploy a workload that match with those labels or safely remove this object.
Severity
Warning
Example
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "nomatchingworkloads"
namespace: "bookinfo"
spec:
selector:
matchLabels:
app: wrong-typo
version: v1
mtls:
mode: STRICT
portLevelMtls:
80:
mode: DISABLE
See Also
KIA0005 - No matching namespace found or namespace is not accessible
This validation error shows that the namespace where the config object is exported is not accessible or does not exist.
Resolution
Choose existing and accessible namespace to export to.
Severity
Error
K8s Gateway
KIA1501 - More than one K8s Gateway for the same host and port combination
A k8s Gateway defines a point where traffic can be translated to Services, within the cluster. This is defined through listeners or addresses. This validation warns when finding multiple Listener definitions for the same port and host combination, in different k8s Gateways. In this case the traffic handling can be in conflict.
The exception to this rule is where the listeners specify different handlers. That is the reason why the severity is a warning.
Resolution
Remove or merge the duplicate k8s gateway entries.
Severity
Warning
Example
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1alpha2
spec:
gatewayClassName: istio
listeners:
- name: default
hostname: host.com
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
selector: {}
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1alpha2
spec:
gatewayClassName: istio
listeners:
- name: primary
hostname: host.com
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
selector: {}
KIA1502 - More than one K8s Gateway for the address and type combination
A k8s Gateway defines a point where traffic can be translated to Services within the cluster. This is defined through listeners or addresses. This validation warns when finding more than one address (type and value) in different k8s Gateways, where the traffic handling can be in conflict.
Resolution
Remove or merge the duplicate k8s gateway entries.
Severity
Warning
Example
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1alpha2
spec:
gatewayClassName: istio
listeners:
- name: default
hostname: example.com
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
selector: {}
addresses:
- type: Hostname
value: example.com
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1alpha2
spec:
gatewayClassName: istio
listeners:
- name: secondary
hostname: secondary.com
port: 9080
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
selector: {}
addresses:
- type: Hostname
value: example.com
KIA1503 - Each listener must have a unique combination of Hostname, Port, and Protocol
A k8s Gateway cannot have more than one listener with the same Hostname, Port and Protocol.
Resolution
Update the hostname, port or protocol to another valid service so there are no more than one listener for the reported combination.
Severity
Error
Example
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1alpha2
spec:
gatewayClassName: istio
listeners:
- name: default
hostname: example.com
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
selector: {}
- name: secondary
hostname: example.com
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
selector: { }
KIA1504 - Gateway API Class not found in Kiali configuration
A k8s Gateway is referencing to a GatewayClass which is not configured in Kiali CR.
Resolution
Change the gatewayClassName
field to reference to existing configured GatewayClass or add the missing GatewayClass into gateway_api_classes
configuration of Kiali CR. More info about configuring K8s Gateway API implementations can be found in Gateway API Implementations
Severity
Error
K8s ReferenceGrants
ReferenceGrant is required for all cross-namespace references in Gateway API. From
field describes the trusted namespaces and kinds that can reference the resources described in “To”. To
field describes the resources that may be referenced by the resources described in “From”.
KIA1601 - Namespace is not found or is not accessible
The namespace where ReferenceGrant From
field is pointing is not accessible or does not exist.
Resolution
Choose existing and accessible namespace to point to.
Severity
Error
GWAPI - Gateway API status
The Gateway object provides a GatewayStatus to provide the status relative to the state represented in the spec. The validations under the GWAPI rule are generic and will highlight any invalid status created by the Gateway.
Resolution
This is a generic rule implemented by the Gateway, and each particular error should be fixed in the spec. The status should not be changed.
Severity
Warning