diff --git a/README.adoc b/README.adoc deleted file mode 100644 index 2f3086248..000000000 --- a/README.adoc +++ /dev/null @@ -1,113 +0,0 @@ -:toc: macro -:toc-title: - -= Kiali.io - -https://app.netlify.com/sites/kiali/deploys[image:https://api.netlify.com/api/v1/badges/05b3eed1-6ea2-41a1-8b64-c76bda241be6/deploy-status[title="Netlify Status"]] - -toc::[] - -This repository contains the source code for the http://kiali.io[http://kiali.io] website. - -The website is written using http://asciidoctor.org[AsciiDoc], generated using https://gohugo.io[Hugo], hosted on Github and deployed using netlify. - - -== Requirements == -To run the website locally, you will need: - -* https://docker.io[Docker] or https://podman.io[Podman] -* https://www.gnu.org/software/make/[GNU Make] - -Generally `podman` is easier to setup, but less used due to being newer. - - -== Configuring and Running == -Hugo has a command to run a small, self-contained web server locally, so you can test the website without having to upload/deploy it anywhere. The server supports live-reload, so changes to the content will reflect into the browser as they happen. - -To run the server, you need to run the following on a terminal: - -[source,shell] ----- -make serve ----- - -[NOTE] -==== -If you are using podman, you need to set `CONTAINER_RUNTIME` when starting the server, as such: -==== - -[source,shell] ----- -CONTAINER_RUNTIME=podman make serve ----- - -If everything is working as expected, you should see something like this: - -[source,] ----- - | EN -+------------------+------+ - Pages | 1353 - Paginator pages | 0 - Non-page files | 0 - Static files | 119 - Processed images | 0 - Aliases | 155 - Sitemaps | 1 - Cleaned | 0 - -Total in 15304 ms -Watching for changes in /site/{content,data,layouts,static,themes} -Watching for config changes in /site/config.toml -Environment: "development" -Serving pages from memory -Web Server is available at http://localhost:1313/ (bind address 0.0.0.0) -Press Ctrl+C to stop ----- - -The server should be available on http://localhost:1313[http://localhost:1313]. Some files might not be supported for live reload. If, for some reason, you are not seeing your changes appearing you may need to restart the server. - -=== Faster generation === - -The website generation includes every past releases of the documentation, which might be slow and unnecessary. Instead of generating everything, you can speed up the process if you're only interested in latest or staging version. To do so, run the following: - -[source,shell] ----- -make serve-latest -# or, with podman: -CONTAINER_RUNTIME=podman make serve-latest ----- - -It will move the archived documentation to a temporary location before starting the server, and put it back once the server is closed. Just double-check it's back to its original place before committing (ie. there's no undesired deleted/moved content in your git status). - -== Documentation Versioning == - -The documentation is versioned, and all new changes should go to `content/documentation/staging`. The release script runs every 3 weeks usually and generates a `content/documentation/vX.X` with the contents of staging, as well as creating a symbolic link on `content/documentation/latest`. - -The versioning/release script can be found on `scripts/build-archive.sh`. - -== Production Deployment == - -Deployment is done automatically when a pull request is merged, and preview deployments are also done for each PR, so you can verify that your changes will work in production before actually deploying. - -== Directory Structure == - -* archetypes :: Content definitions, tag, categories and so on -* content :: Content for the website (pages and articles) -** contribute :: Contribution how-to -** documentation :: Documentation for Kiali -*** staging :: The documentation for the next released versions, changes should go here -*** latest :: A symbolic link to the latest generated version, replaced on release -*** vX.X :: Documentation for older versions, those are usually generated by the release scripts -** news :: News about the project -* data :: Website data, such as localization configuration -* layouts :: Page layout templates -* public :: Content for website automatically generated by Hugo, it is not included in the repository -* scripts :: Scripts for generating swagger documentation and versioning -* static :: Any static files that need to be added to the website (images, css and js) -* themes :: The website theme - - -== License and Code of Conduct == - -The kiali.io website, like the other kiali-related projects are licensed under the https://www.apache.org/licenses/LICENSE-2.0[Apache License 2.0]. It also follows the https://github.com/kiali/kiali/blob/master/CODE_OF_CONDUCT.md[Kiali Community Code of Conduct]. diff --git a/README.md b/README.md new file mode 100644 index 000000000..f9f527f29 --- /dev/null +++ b/README.md @@ -0,0 +1,85 @@ + +# Kiali.io + +[![title="Netlify Status"](https://api.netlify.com/api/v1/badges/05b3eed1-6ea2-41a1-8b64-c76bda241be6/deploy-status)](https://app.netlify.com/sites/kiali/deploys) + +This repository contains the source code for the [http://kiali.io](http://kiali.io) website. + +The website is written using markdown, the [Docsy](https://www.docsy.dev/) theme, and generated using [Hugo](https://gohugo.io). It is hosted on Github and deployed using netlify. + + +## Requirements + +To run the website locally, you will need: + +* [Podman](https://podman.io) or [Docker](https://docker.io) +* https://www.gnu.org/software/make/[GNU Make] + +Generally `podman` is easier to setup. + + +## Configuring and Running + +Hugo has a command to run a small, self-contained web server locally, so you can test the website without having to upload/deploy it anywhere. The server supports live-reload, so changes to the content will reflect into the browser as they happen. + +To run the server, you need to run the following on a terminal: + +``` +make serve +``` + +> :warning: +> If you are using Docker, you need to set `DORP` when starting the server; e.g: +> ``` +> make -e DORP=docker make serve +> ``` + +If everything is working as expected, you should see something like this: + +``` + | EN ++------------------+------+ + Pages | 1353 + Paginator pages | 0 + Non-page files | 0 + Static files | 119 + Processed images | 0 + Aliases | 155 + Sitemaps | 1 + Cleaned | 0 + +Total in 15304 ms +Watching for changes in /site/{content,data,layouts,static,themes} +Watching for config changes in /site/config.toml +Environment: "development" +Serving pages from memory +Web Server is available at http://localhost:1313/ (bind address 0.0.0.0) +Press Ctrl+C to stop +``` + +The server should be available on [http://localhost:1313](http://localhost:1313). Some files might not be supported for live reload. If, for some reason, you are not seeing your changes appearing you may need to restart the server. + + +## Documentation Versioning + +The documentation is versioned using a branch strategy. The `master` branch holds all new content. On each Kiali release `master` will be captured in a versioned branch. This typically happens every three weeks. + +The versioning/release script can be found on `scripts/build-archive.sh`. + +## Production Deployment + +Deployment is done automatically when a pull request is merged, and preview deployments are also done for each PR, so you can verify that your changes will work in production before actually deploying. + +## Directory Structure + +The directory structure is typical for projects using the [Docsy](https://www.docsy.dev/) theme. A couple of notes: + +* The site only supports English and as such, all content is under `content/en`. +* The site minimizes customization but custom CSS is found in `assets/scss`. +* The site keeps consolidates static content under `static`. + * e.g. images are under `static\images` + + +## License and Code of Conduct + +The kiali.io website, like the other kiali-related projects are licensed under the [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0). It also follows the [Kiali Community Code of Conduct](https://github.com/kiali/kiali/blob/master/CODE_OF_CONDUCT.md). diff --git a/assets/scss/_content.scss b/assets/scss/_content.scss index 4a1d1528b..10f04af46 100644 --- a/assets/scss/_content.scss +++ b/assets/scss/_content.scss @@ -107,6 +107,8 @@ } img { + margin-bottom: 1rem; + margin-top: 1rem; margin-left: 5%; max-width: 90%; } diff --git a/config.toml b/config.toml index 810665145..78d13dbcc 100644 --- a/config.toml +++ b/config.toml @@ -222,10 +222,6 @@ enable = false url = "https://kiali.io" [[params.versions]] - version = "latest" - url = "localhost:1313" - -[[params.versions]] - version = "archive" - url = "https://kiali.io" + version = "pre-v1.41" + url = "https://pre-v1-41.kiali.io" diff --git a/content/en/_index.html b/content/en/_index.html index 810e3f53e..70b1f76a7 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -68,4 +68,7 @@ {{< videos >}} {{< /blocks/section >}} + + Deploys by Netlify + diff --git a/content/en/docs/Architecture/terminology/_index.adoc b/content/en/docs/Architecture/terminology/_index.adoc deleted file mode 100644 index a0f8b2570..000000000 --- a/content/en/docs/Architecture/terminology/_index.adoc +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Terminology" -date: 2018-06-20T19:04:38+02:00 -draft: false -weight: 9 ---- diff --git a/content/en/docs/Architecture/terminology/_index.md b/content/en/docs/Architecture/terminology/_index.md new file mode 100644 index 000000000..3f261a076 --- /dev/null +++ b/content/en/docs/Architecture/terminology/_index.md @@ -0,0 +1,4 @@ +--- +title: "Terminology" +weight: 9 +--- diff --git a/content/en/docs/FAQ/general.md b/content/en/docs/FAQ/general.md index a07a4b341..0a346549f 100644 --- a/content/en/docs/FAQ/general.md +++ b/content/en/docs/FAQ/general.md @@ -112,7 +112,7 @@ Kiali currently requires the following metrics and attributes (note, this assume |istio_tcp_received_bytes_total |used in metrics displays | |istio_tcp_sent_bytes_total |used throughout Kiali and the primary metric for tcp traffic graph generation | -
+
|Attribute |Metric |Notes| |---------------|-------------------------------------|-----| diff --git a/content/en/docs/FAQ/graph.md b/content/en/docs/FAQ/graph.md index 6bc85dbb9..235db9536 100644 --- a/content/en/docs/FAQ/graph.md +++ b/content/en/docs/FAQ/graph.md @@ -41,7 +41,6 @@ In some situations you can see a lot of connections from an "Unknown" node to yo From the Graph page, you can filter them out by typing `node = unknown` in the _Graph Hide_ input box. ![Graph Hide](/images/documentation/faq/graph/graph-hide.png) -
For a more definitive solution, there are several ways to prevent Istio from gathering this kind of telemetry. diff --git a/content/en/docs/Features/configuration.md b/content/en/docs/Features/configuration.md index 809bdf00f..b8c8e554b 100644 --- a/content/en/docs/Features/configuration.md +++ b/content/en/docs/Features/configuration.md @@ -10,13 +10,7 @@ Kiali is more than observability, it also helps you to configure, update and val The Istio configuration view provides advanced filtering and navigation for Istio configuration objects such as Virtual Services and Gateways. Kiali provides inline config edition and powerful semantic validation for Istio resources. -
- - - - - -
+![Istio Config List](/images/documentation/features/config-list-v1.22.0.png "Istio Config List") ## Validations @@ -26,15 +20,7 @@ Galley validations are mostly syntactic validations based on the object syntax a Check the complete [list of validations](#validations) for further information. - -
- - - - - -
- +![Istio Config Validation](/images/documentation/features/config-validation-v1.22.0.png "Istio Config Validation") ## Istio Forms @@ -43,47 +29,21 @@ Kiali also offers actions to create Istio Config for Gateways and Security scena These actions are located under the Istio Config page. -
- - - - - -
+![Create Istio Config](/images/documentation/features/create-istio-config-v1.32.0.png "Create Istio Config") ### Istio Security Forms Kiali allows creation of Istio AuthorizationPolicy resources: -
- - - - - -
-
+![AuthorizationPolicy](/images/documentation/features/form-authorization-policy-v1.32.0.png "AuthorizationPolicy") Istio PeerAuthentication resources: -
- - - - - -
-
+![PeerAuthentication](/images/documentation/features/form-peer-authentication-v1.32.0.png "PeerAuthentication") Istio RequestAuthentication resources: -
- - - - - -
+![RequestAuthentication](/images/documentation/features/form-request-authentication-v1.32.0.png "RequestAuthentication") ### Istio Traffic Forms @@ -91,33 +51,13 @@ Kiali uses Istio Wizards to generate Istio Traffic config for a specific Service Istio Gateway resources: -
- - - - - -
-
+![Gateway](/images/documentation/features/form-gateway-v1.32.0.png "Gateway") Istio ServiceEntry resources: -
- - - - - -
-
+![ServiceEntry](/images/documentation/features/form-serviceentry-v1.32.0.png "ServiceEntry") Istio Sidecar resources: -
- - - - - -
+![Sidecar](/images/documentation/features/form-sidecar-v1.32.0.png "Sidecar") diff --git a/content/en/docs/Features/details.md b/content/en/docs/Features/details.md index 756f0f2d4..cd432a2b1 100644 --- a/content/en/docs/Features/details.md +++ b/content/en/docs/Features/details.md @@ -16,7 +16,6 @@ Kiali provides filtered list views of all your service mesh definitions. Each vi ![Detail list workload](/images/documentation/features/detail-list-workload.png) ![Detail list Istio config](/images/documentation/features/detail-list-config.png) -
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 @@ -40,26 +39,22 @@ And also type-specfic information. For example: ![Detail overview service](/images/documentation/features/detail-overview-service.png) ![Detail overview workload](/images/documentation/features/detail-overview-workload.png) -
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](https://github.com/kiali/kiali-operator/blob/master/deploy/kiali/kiali_cr.yaml). ![Detail overview additional details](/images/documentation/features/detail-overview-additional-details.png) -
## Traffic The Traffic Tab presents a service, app, or workload's Inbound and Outbound traffic in a table-oriented way: ![Detail traffic](/images/documentation/features/detail-traffic.png) -
## 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. ![Detail logs](/images/documentation/features/detail-logs.png) -
## 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. @@ -69,7 +64,6 @@ Kiali allows the user to customize the charts by choosing the charted dimensions ![Detail metric inbound](/images/documentation/features/detail-metrics-in.png) ![Detail metrics outbound](/images/documentation/features/detail-metrics-out.png) -
## Traces Each detail view provides a _Traces_ tab with a native integration with Jaeger. For more, see [Tracing]({{< relref "./tracing" >}}). @@ -89,7 +83,6 @@ The most important built-in dashboard is for Envoy. Kiali offers the _Envoy_ ta ![Detail Envoy](/images/documentation/features/detail-envoy.png) -
Istio's Envoy sidecars supply [some internal metrics](https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats), 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](https://istio.io/docs/ops/telemetry/envoy-stats/): it's possible to get more metrics using the `statsInclusionPrefixes` annotation. Make sure you include `cluster_manager` and `listener_manager` as they are required. diff --git a/content/en/docs/Features/health.md b/content/en/docs/Features/health.md index e263f6926..1abd75618 100644 --- a/content/en/docs/Features/health.md +++ b/content/en/docs/Features/health.md @@ -11,10 +11,8 @@ Colors in the graph represent the health of your service mesh. A node colored re 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. - - - -
+![Visualize the health of your mesh](/images/documentation/features/graph-health-thumb-v1.22.0.png "Visualize the health of your mesh") + ## Health Configuration diff --git a/content/en/docs/Features/istio-component-status.md b/content/en/docs/Features/istio-component-status.md index 3b02a74c1..f0f55d9d9 100644 --- a/content/en/docs/Features/istio-component-status.md +++ b/content/en/docs/Features/istio-component-status.md @@ -9,13 +9,7 @@ weight: 9 The Istio service mesh architecture is comprised of several components, from istiod to Jaeger. Each component must work as expected for the mesh to work well overall. Kiali regularly checks the status of each Istio component to ensure the mesh is healthy. -
- - - - - -
+![Istio components status: components not healthy or found](/images/documentation/features/istio-components-1.24.png "Istio components status: components not healthy or found") A component *status* will be one of: `Not found`, `Unreachable`, `Not healthy` and `Healthy`. The `Not found` status means that Kiali is not able to find the deployment. The `Unreachable` status means that Kiali hasn't been succesfuly able to communicate with the component (Prometheus, Grafana and Jaeger). The `Not healthy` status means that the deployment doesn't have the desired amount of replicas running. The `Healthy` status is when the component is not in the previous ones, plus, healthy components won't be shown in the list. @@ -38,13 +32,7 @@ The certificates shown depends on how Istio is configured. The following cases a The following is an example of viewing the default case: -
- - - - - -
+![Certificates information](/images/documentation/features/certificates-information-indicators.png "Certificates information") 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). diff --git a/content/en/docs/Features/multi-cluster.md b/content/en/docs/Features/multi-cluster.md index 9936444cf..65a9527cf 100644 --- a/content/en/docs/Features/multi-cluster.md +++ b/content/en/docs/Features/multi-cluster.md @@ -14,13 +14,7 @@ Kiali v1.29 introduces experimental support for advanced deployment models. The ## List View: Mesh Discovery Kiali will attempt to discover the clusters configured in the mesh. And 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, _Kukulcan_ and _Tzotz_. Kukulcan 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: -
- - - - - -
+![Mesh list view](/images/documentation/features/multi-cluster-mesh-v1.29.png "Mesh list view") ## Graph View: Cluster and Namespace Boxing @@ -28,11 +22,5 @@ Starting in v1.8 Istio provides cluster names in the traffic telemetry for multi Each new box type supports selection and will provide a side-panel summary of traffic. Below we see a Bookinfo traffic graph for when Bookinfo services are deployed across the Kukulcan and Tzotz clusters. The Kukulcan cluster box is selected. Because Kukulcan is the Kiali home cluster, you see traffic from the perspective of Kukulcan. Note that you do not see the internal traffic on Tzotz (the requests from Reviews to Ratings service). To see traffic from the Tzotz cluster point of view, you would open a Kiali session on Tzotz, assuming you have privileges. -
- - - - - -
+![Multi-cluster traffic graph](/images/documentation/features/multi-cluster-graph-v1.29.png "Multi-cluster traffic graph") diff --git a/content/en/docs/Features/security.md b/content/en/docs/Features/security.md index f94514eef..f37449e81 100644 --- a/content/en/docs/Features/security.md +++ b/content/en/docs/Features/security.md @@ -11,16 +11,8 @@ Kiali gives support to better understand how mTLS is used in Istio meshes. Find 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`. -
- - - - - - - - -
+![mTLS mesh-wide enabled strictly](/images/documentation/features/masthead-mtls-v1.22.0.png "mTLS mesh-wide enabled strictly") +![Custom Vertx Metrics](/images/documentation/features/masthead-mtls-hollow-v1.22.0.png "Custom Vertx Metrics") 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. @@ -28,13 +20,7 @@ Kiali shows a hollow lock when either the mesh is configured in `PERMISSIVE` mod 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. -
- - - - - -
+![Overview page: showing mTLS at namespace-wide](/images/documentation/features/overview-mtls-v1.22.0.png "Overview page: showing mTLS at namespace-wide") ## Graph @@ -42,23 +28,11 @@ The `mTLS` method is used to establish communication between microservices. In t Enable the option in the `Display` dropdown, select the `security` badge. -
- - - - - -
+![Graph shows edges which uses mTLS](/images/documentation/features/graph-mtls-v1.22.0.png "Graph shows edges which uses mTLS") ## Validations Kiali has different validations to help troubleshoot configurations related to `mTLS` such as `DestinationRules` and `PeerAuthentications`. -
- - - - - -
+![Validation supporting mTLS configuration](/images/documentation/features/validations-mtls-v1.22.0.png "Validation supporting mTLS configuration") diff --git a/content/en/docs/Features/topology.md b/content/en/docs/Features/topology.md index f8b0783ed..2d8f73876 100644 --- a/content/en/docs/Features/topology.md +++ b/content/en/docs/Features/topology.md @@ -12,7 +12,6 @@ Kiali's default page is the topology _Overview_. It presents a high-level view ![Topology namespace overview](/images/documentation/features/topology-overview.png) -
## Graph @@ -24,8 +23,6 @@ You can configure the graph to show the namespaces and data that are important t ![Topology graph](/images/documentation/features/topology-graph.png) -
- ### 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. @@ -34,8 +31,6 @@ The health of nodes and edges is refreshed automatically based on the user's pre ![Topology graph health](/images/documentation/features/topology-graph-health.png) -
- ### 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: @@ -50,8 +45,6 @@ The collapsible side-panel summarizes the current graph selection, or the graph ![Topology graph side-panel service](/images/documentation/features/topology-graph-sidepanel-2.png) ![Topology graph side-panel workload](/images/documentation/features/topology-graph-sidepanel-3.png) -
- ### 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 @@ -61,8 +54,6 @@ You can return back to the main graph, or double-click to change to a different ![Topology graph node detail](/images/documentation/features/topology-graph-node-detail.png) -
- ### Traffic Animation Kiali offers several display options for the graph, including traffic animation. @@ -73,8 +64,6 @@ TCP traffic is represented by offset circles where the speed of the circles indi ![Topology graph animation](/images/documentation/features/topology-graph-node-animation.gif) -
- ### Graph Types Kiali offers four different traffic-graph renderings: @@ -92,15 +81,13 @@ Kiali offers four different traffic-graph renderings: ![Topology graph type versioned app](/images/documentation/features/topology-graph-type-versioned-app.png) ![Topology graph service](/images/documentation/features/topology-graph-type-service.png) -
- ### 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. {{< youtube CC_dl4zSZiU >}} -
+
### Operation Nodes diff --git a/content/en/docs/Features/tracing.md b/content/en/docs/Features/tracing.md index 38301178c..ac60a2297 100644 --- a/content/en/docs/Features/tracing.md +++ b/content/en/docs/Features/tracing.md @@ -10,7 +10,7 @@ than that, Kiali incorporates tracing into several correlated views, making your 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](https://medium.com/kialiproject/trace-my-mesh-part-1-3-35e252f9c6a9) blog series, -
+
## Workload detail @@ -19,10 +19,8 @@ presents a tab for trace detail, and a tab for span details. Kiali always tries heatmap approach to help the user identify problem traces or spans. ![Trace detail](/images/documentation/features/trace-detail.png) - ![Span detail](/images/documentation/features/trace-span-detail.png) -
## Metric Correlation @@ -31,7 +29,6 @@ span will navigate back to the _Traces_ tab, focused on the trace of interest. ![Metrics with Tracing](/images/documentation/features/trace-metric-overlay.png) -
## Graph Correlation @@ -42,7 +39,6 @@ views. ![Graph with Tracing](/images/documentation/features/trace-graph-overlay.png) -
## Logs Correlation diff --git a/content/en/docs/Features/validations.md b/content/en/docs/Features/validations.md index 0efdbde25..44fa9e9c3 100644 --- a/content/en/docs/Features/validations.md +++ b/content/en/docs/Features/validations.md @@ -11,14 +11,7 @@ Kiali performs a set of validations to the most common Istio Objects such as Des Galley validations are mostly syntactic validations based on the object syntax analysis of Istio objects while Kiali validations are mostly semantic validations between different Istio objects. Kiali validations are based on the runtime status of your service mesh, Galley validations are static ones and doesn't take into account what is configured in the mesh. -
- - - - - -
-
+![Istio Config Validation](/images/documentation/features/config-validation-v1.22.0.png "Istio Config Validation") Check the complete list of validations for further information. diff --git a/content/en/docs/Features/wizards.md b/content/en/docs/Features/wizards.md index b5b5a843a..00871c2c9 100644 --- a/content/en/docs/Features/wizards.md +++ b/content/en/docs/Features/wizards.md @@ -8,39 +8,21 @@ weight: 6 Kiali is more than observability, it also helps you to configure, update and validate your Istio service mesh. ## Istio Wizards + Kiali provides actions to create, update and delete Istio configuration, driven by wizards. Actions can be applied to a *Service* -
- - - - - -
-
+![Service Details Actions](/images/documentation/features/service-actions-v1.24.0.png "Service Details Actions") Actions can also be applied to a *Workload* -
- - - - - -
-
+![Workload Details Actions](/images/documentation/features/workload-actions-v1.24.0.png "Workload Details Actions") Also, actions are available for an entire *Namespace* -
- - - - - -
+![Namespace Actions](/images/documentation/features/overview-actions-v1.24.0.png "Namespace Actions") + ## Service Actions @@ -53,14 +35,7 @@ The Request Routing Wizard allows creating multiple routing rules. * 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. -
- - - - - -
-
+![Request Routing](/images/documentation/features/wizard-request-routing-v1.24.0.png "Request Routing") Istio applies routing rules in order, meaning that the first rule matching an HTTP request performs the routing. The Matching Routing Wizard allows changing the rule order. @@ -71,25 +46,13 @@ The Fault Injection Wizard allows injecting faults to test the resiliency of a S * HTTP Delay specification is used to inject latency into the request forwarding path. * HTTP Abort specification is used to prematurely abort a request with a pre-specified error code. -
- - - - - -
+![Fault Injection](/images/documentation/features/wizard-fault-injection-v1.24.0.png "Fault Injection") ### Traffic Management: Traffic Shifting The Traffic Shifting Wizard allows selecting the percentage of traffic that is routed to a specific workload. -
- - - - - -
+![Traffic Shifting](/images/documentation/features/wizard-traffic-shifting-v1.24.0.png "Traffic Shifting") ### Traffic Management: Request Timeouts @@ -98,14 +61,7 @@ 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. - -
- - - - - -
+![Request Timeouts](/images/documentation/features/wizard-request-timeouts-v1.24.0.png "Request Timeouts") ### Traffic Management: Gateways @@ -113,13 +69,7 @@ Traffic Management Wizards have an Advanced Options section that can be used to 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. -
- - - - - -
+![Request Timeouts](/images/documentation/features/wizard-advanced-options-gateways-v1.24.0.png "Request Timeouts") ### Traffic Management: Circuit Breaker @@ -128,13 +78,7 @@ Traffic Management Wizards allows defining Circuit Breakers on Services as part * Connection Pool defines the connection limits for an upstream host. * Outlier Detection implements the Circuit Breaker based on the consecutive errors reported. -
- - - - - -
+![Circuit Breakers](/images/documentation/features/wizard-advanced-options-gateways-v1.24.0.png "Circuit Breakers") ### Security: Traffic Policy @@ -144,13 +88,7 @@ Traffic Management Advanced Options allows defining Security and Load Balancing * Automatically generate a PeerAuthentication resource for this Service. * Load balancing policies to apply for a specific destination. -
- - - - - -
+![Traffic Policy](/images/documentation/features/wizard-advanced-options-traffic-policy-v1.24.0.png "Traffic Policy") ## Workload Actions @@ -162,26 +100,14 @@ A default scenario is to indicate this at *Namespace* level but there can be cas Kiali allows users to annotate the Deployment template and propagate this configuration into the Pods. -
- - - - - -
+![Automatic Sidecar Injection](/images/documentation/features/workload-actions-sidecar-injection-v1.24.0.png "Automatic Sidecar Injection") ## Namespace Actions The Kiali Overview page offers several *Namespace* actions, in any of its views: Expanded, Compacted or Table. -
- - - - - -
+![Namespace Actions](/images/documentation/features/overview-table-actions-v1.24.0.png "Namespace Actions") ### Show @@ -201,25 +127,11 @@ 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: -
- - - - - -
-
+![Traffic Policies: Graph](/images/documentation/features/overview-actions-trafficpolicies-graph-v1.24.0.png "Traffic Policies: Graph") 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*. -
- - - - - -
- +![Traffic Policies: Graph](/images/documentation/features/overview-actions-trafficpolicies-authorizationpolicies-v1.24.0.png "Traffic Policies: Graph") diff --git a/content/en/docs/Tutorials/travels/01-Prerequisites.md b/content/en/docs/Tutorials/travels/01-Prerequisites.md index adb1272b1..70afb8d1c 100644 --- a/content/en/docs/Tutorials/travels/01-Prerequisites.md +++ b/content/en/docs/Tutorials/travels/01-Prerequisites.md @@ -76,7 +76,5 @@ There are other alternatives to expose Kiali or other Addons in Istio. Check [Re After the *Prerequisites* you should be able to access Kiali. Verify its version by clicking the "?" icon and selecting "About": - - - +![Verify Kiali Access](/images/tutorial/01-04-access-kiali-v1.39.0.png "Verify Kiali Access") diff --git a/content/en/docs/Tutorials/travels/02-install-travel-demo.md b/content/en/docs/Tutorials/travels/02-install-travel-demo.md index 8a7eb2a26..32f63e468 100644 --- a/content/en/docs/Tutorials/travels/02-install-travel-demo.md +++ b/content/en/docs/Tutorials/travels/02-install-travel-demo.md @@ -81,9 +81,7 @@ Additionally, some users, like _registered_ users, can have access to special di Service relations between namespaces can be described in the following diagram: - - - +![Travel Demo Design](/images/tutorial/02-02-travels-demo-design.png "Travel Demo Design") #### Travel Portal and Travel Agency flow @@ -101,6 +99,5 @@ The *travel-control* namespace runs a *business dashboard* with two key features * Allow setting changes for every travel shop simulator (traffic ratio, device, user and type of travel). * Provide a *business* view of the total requests generated from the *travel-portal* namespace to the *travel-agency* services, organized by business criteria as grouped per shop, per type of traffic and per city. - - - +![Travel Dashboard](/images/tutorial/02-02-travels-dashboard.png "Travel Dashboard") + diff --git a/content/en/docs/Tutorials/travels/03-first-steps.md b/content/en/docs/Tutorials/travels/03-first-steps.md index fcc36b68c..ae416d65e 100644 --- a/content/en/docs/Tutorials/travels/03-first-steps.md +++ b/content/en/docs/Tutorials/travels/03-first-steps.md @@ -13,25 +13,15 @@ In that case, the application won't connect to the control plane and won't take In Kiali, we will see the new namespaces in the overview page: - - - - -
+![Overview](/images/tutorial/03-01-overview.png "Overview") But we won't see any traffic in the graph page for any of these new namespaces: - - - - -
+![Empty Graph](/images/tutorial/03-01-empty-graph.png "Empty Graph") If we examine the Applications, Workloads or Services page, it will confirm that there are missing sidecars: - - - +![Missing Sidecar](/images/tutorial/03-01-missing-sidecar.png "Missing Sidecar") ## Enable Sidecars @@ -44,20 +34,14 @@ We are going to start with the *control* workload deployed into the *travel-cont {{% alert title="Step 1" color="success" %}} Enable Auto Injection on the *travel-control* namespace {{% /alert %}} - - - -
+![Enable Auto Injection per Namespace](/images/tutorial/03-02-travel-control-namespace.png "Enable Auto Injection per Namespace") {{% alert title="Step 2" color="success" %}} Enable Auto Injection for *control* workload {{% /alert %}} - - - -
+![Enable Auto Injection per Workkload](/images/tutorial/03-02-control-workload.png "Enable Auto Injection per Workkload") Understanding what happened: @@ -122,49 +106,32 @@ not define a DNS entry, instead, where you see `control.travel-control.istio-clu {{% alert title="Step 2" color="success" %}} Use the Request Routing Wizard on the *control* service to generate a traffic rule {{% /alert %}} - - - -
+![Request Routing Wizard](/images/tutorial/03-03-service-actions.png "Request Routing Wizard") Use "Add Route Rule" button to add a default rule where any request will be routed to the *control* workload. - - - - -
+![Routing Rule](/images/tutorial/03-03-request-routing.png "Routing Rule") Use the Advanced Options and add a gateway with host `control.travel-control.istio-cluster.org` and create the Istio config. - - - - -
+![Create Gateway](/images/tutorial/03-03-create-gateway.png "Create Gateway") Verify the Istio configuration generated. - - - +![Istio Config](/images/tutorial/03-03-istio-config.png "Istio Config") {{% alert title="Step 3" color="success" %}} Test the *control* service by pointing your browser to `\http://control.travel-control.istio-cluster.org` {{% /alert %}} - - - + +![Test Gateway](/images/tutorial/03-03-test-gateway.png "Test Gateway") {{% alert title="Step 4" color="success" %}} Review *travel-control* namespace in Kiali {{% /alert %}} - - - -
+![Travel Control Graph](/images/tutorial/03-03-travel-control-graph.png "Travel Control Graph") Understanding what happened: diff --git a/content/en/docs/Tutorials/travels/04-observe.md b/content/en/docs/Tutorials/travels/04-observe.md index 7e9431b48..ce56c55d4 100644 --- a/content/en/docs/Tutorials/travels/04-observe.md +++ b/content/en/docs/Tutorials/travels/04-observe.md @@ -20,11 +20,8 @@ We have added new powerful features but the application is still missing visibil {{% alert title="Step 1" color="success" %}} Switch to the Workload graph and select multiple namespaces to identify missing sidecars in the Travel Demo application {{% /alert %}} - - - -
+![Missing Sidecars](/images/tutorial/04-01-missing-sidecars.png "Missing Sidecars") That *control* workload provides good visibility of its traffic, but telemetry is partially enabled, as *travel-portal* and *travel-agency* workloads don't have sidecar proxies. @@ -50,20 +47,17 @@ kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/ kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travel_portal.yaml) -n travel-portal ``` -
+
Verify that *travel-control*, *travel-portal* and *travel-agency* workloads have sidecars deployed: - - - +![Updated Workloads](/images/tutorial/04-01-updated-workloads.png "Updated Workloads") {{% alert title="Step 3" color="success" %}} Verify updated telemetry for *travel-portal* and *travel-agency* namespaces {{% /alert %}} - - - + +![Updated Telemetry](/images/tutorial/04-01-updated-telemetry.png "Updated Telemetry") ## Graph walkthrough @@ -76,37 +70,26 @@ Our goal will be to identify the most critical service of the demo application. {{% alert title="Step 1" color="success" %}} Select all *travel-* namespaces in the graph and enable *Traffic Distribution* edge labels in the Display Options: {{% /alert %}} - - - -
+![Graph Request Distribution](/images/tutorial/04-02-graph-request-distribution.png "Graph Request Distribution") Review the status of the mesh, everything seems healthy, but also note that *hotels* service has more load compared to other services inlcuded in the *travel-agency* namespace. {{% alert title="Step 2" color="success" %}} Select the *hotels* service, use the graph side-panel to select a trace from the Traces tab: {{% /alert %}} - - - -
+![Hotels Normal Trace](/images/tutorial/04-02-hotels-normal-trace.png "Hotels Normal Trace") Combining telemetry and tracing information will show that there are traces started from a portal that involve multiple services but also other traces that only consume the *hotels* service. - - - +![Hotels Single Trace](/images/tutorial/04-02-hotels-single-trace.png "Hotels Single Trace") {{% alert title="Step 3" color="success" %}} Select the main *travels* application and double-click to zoom in {{% /alert %}} - - - -
+![Travels Zoom](/images/tutorial/04-02-travels-zoom.png "Travels Zoom") The graph can focus on an element to study a particular context in detail. Note that a contextual menu is available using right-click, to easily shortcut the navigation to other sections. @@ -122,11 +105,8 @@ In this tutorial we are going to learn how to use them to examine the main *trav {{% alert title="Step 1" color="success" %}} Navigate to the *travels* application {{% /alert %}} - - - -
+![Travels Application](/images/tutorial/04-03-travels-application.png "Travels Application") An *application* is an abstract group of workloads and services labeled with the same "application" name. @@ -135,27 +115,18 @@ From Service Mesh perspective this concept is significant as telemetry and traci At this point of the tutorial, the *travels* application is quite simple, just a *travels-v1* workload exposed through the *travels* service. Navigate to the *travels-v1* workload detail by clicking the link in the *travels* application overview. - - - +![Travels-v1 Workload](/images/tutorial/04-03-travels-v1-workload.png "Travels-v1 Workload") {{% alert title="Step 2" color="success" %}} Examine *Outbound Metrics* of *travels-v1* workload {{% /alert %}} - - - -
+![Travels-v1 Metrics](/images/tutorial/04-03-travels-v1-metrics.png "Travels-v1 Metrics") The Metrics tab provides a powerful visualization of telemetry collected by the Istio proxy sidecar. It presents a dashboard of charts, each of which can be expanded for closer inspection. Expand the *Request volume* chart: - - - - -
+![Travels-v1 Request Volume Chart](/images/tutorial/04-03-travels-v1-metrics-request-volume.png "Travels-v1 Request Volume Chart") Metrics Settings provides multiple predefined criteria out-of-the-box. Additionally, enable the *spans* checkbox to correlate metrics and tracing spans in a single chart. @@ -175,19 +146,11 @@ From the application container log we can spot that there are two main business In the Istio sidecar proxy log we see that *GetDestinations* invokes a `GET /hotels` request without parameters. - - - - -
+![Travels-v1 Logs GetDestinations](/images/tutorial/04-03-travels-v1-logs-getdestinations.png "Travels-v1 Logs GetDestinations") However, *GetTravelQuote* invokes multiple requests to other services using a specific city as a parameter. - - - - -
+![Travels-v1 Logs GetTravelQuote](/images/tutorial/04-03-travels-v1-logs-gettravelquote.png "Travels-v1 Logs GetTravelQuote") Then, as discussed in the [Travel Demo design]({{< relref "./02-install-travel-demo/#travel-agency-namespace" >}}), an initial query returns all available hotels before letting the user choose one and then get specific quotes for other destination services. @@ -203,15 +166,9 @@ The next step is to get more context to answer if some particular service is act The Traces tab allows comparison between traces and metrics histograms, letting the user determine if a particular spike is expected in the context of average values. - - - - -
+![Travels-v1 Traces](/images/tutorial/04-03-travels-v1-tracing-details.png "Travels-v1 Traces") In the same context, individual *spans* can be compared in more detail, helping to identify a problematic step in the broader scenario. - - - +![Travels-v1 Spans](/images/tutorial/04-03-travels-v1-tracing-spans.png "Travels-v1 Spans") diff --git a/content/en/docs/Tutorials/travels/05-connect.md b/content/en/docs/Tutorials/travels/05-connect.md index 8096c7cad..3426f9ffd 100644 --- a/content/en/docs/Tutorials/travels/05-connect.md +++ b/content/en/docs/Tutorials/travels/05-connect.md @@ -24,19 +24,12 @@ To deploy the new versions of the *travels* service execute the following comman kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travels-v2.yaml) -n travel-agency kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travels-v3.yaml) -n travel-agency ``` -
- - - - -
+![Travels-v2 and travels-v3](/images/tutorial/05-01-travels-v2-v3.png "Travels-v2 and travels-v3") As there is no specific routing defined, when there are multiple workloads for *travels* service the requests are uniformly distributed. - - - +![Travels graph before routing](/images/tutorial/05-01-travels-before-routing.png "Travels graph before routing") {{% alert title="Step 2" color="success" %}} Investigate the http headers used by the Travel Demo application @@ -55,11 +48,7 @@ But, where to find the HTTP headers ? That information typically belongs to the There are multiple possibilities. The Travel Demo application uses an [Istio Annotation](https://istio.io/latest/docs/reference/config/annotations/) feature to add an annotation into the Deployment descriptor, which adds additional Istio configuration into the proxy. - - - - -
+![Istio Config annotations](/images/tutorial/05-01-deployment-istio-config.png "Istio Config annotations") In our example the [HTTP Headers](https://github.com/kiali/demos/blob/master/travels/travels-v2.yaml#L15) are added as part of the trace context. @@ -68,11 +57,8 @@ Then tracing will populate custom tags with the *portal*, *device*, *user* and * {{% alert title="Step 3" color="success" %}} Use the Request Routing Wizard on *travels* service to generate a traffic rule {{% /alert %}} - - - -
+![Travels Service Request Routing](/images/tutorial/05-01-travels-request-routing.png "Travels Service Request Routing") We will define three "Request Matching" rules as part of this request routing. Define all three rules before clicking the Create button. @@ -80,36 +66,22 @@ In the first rule, we will add a request match for when the *portal* header has Define the exact match, like below, and click the "Add Match" button to update the "Matching selected" for this rule. - - - - -
+![Add Request Matching](/images/tutorial/05-01-add-match.png "Add Request Matching") Move to "Route To" tab and update the destination for this "Request Matching" rule. Then use the "Add Route Rule" to create the first rule. - - - - -
+![Route To](/images/tutorial/05-01-route-to.png "Route To") Add similar rules to route traffic from *viaggi.it* to *travels-v2* workload and from *voyages.fr* to *travels-v3* workload. When the three rules are defined you can use "Create" button to generate all Istio configurations needed for this scenario. Note that the rule ordering does not matter in this scenario. - - - - -
+![Rules Defined](/images/tutorial/05-01-rules-defined.png "Rules Defined") The Istio config for a given service is found on the "Istio Config" card, on the Service Details page. - - - +![Service Istio Config](/images/tutorial/05-01-service-istio-config.png "Service Istio Config") {{% alert title="Step 4" color="success" %}} Verify that the Request Routing is working from the *travels-portal* Graph @@ -119,21 +91,13 @@ Once the Request Routing is working we can verify that outbound traffic from eve see this clearly use a "Workload Graph" for the "travel-portal" namespace, enable "Traffic Distribution" edge labels and disable the "Service Nodes" Display option: - - - - -
+![Travel Portal Namespace Graph](/images/tutorial/05-01-request-routing-graph.png "Travel Portal Namespace Graph") Note that no distribution label on an edge implies 100% of traffic. Examining the "Inbound Traffic" for any of the *travels* workloads will show a similar pattern in the telemetry. - - - - -
+![Travels v1 Inbound Traffic](/images/tutorial/05-01-travels-v1-inbound-traffic.png "Travels v1 Inbound Traffic") Using a custom time range to select a large interval, we can see how the workload initially received traffic from all portals but then only a single portal after the Request Routing scenarios were defined. @@ -147,9 +111,7 @@ These scenarios can be updated or deleted from the "Actions" menu of a given ser To experiment further you can navigate to the *travels* service and update your configuration by selecting "Request Routing", as shown below. When you have finished experimenting with Routing Request scenarios then use the "Actions" menu to delete the generated Istio config. - - - +![Update or Delete](/images/tutorial/05-01-update-or-delete.png "Update or Delete") ## Fault Injection @@ -164,17 +126,12 @@ This step will show how to test the resilience of the Travel Demo application by {{% alert title="Step 1" color="success" %}} Use the Fault Injection Wizard on *hotels* service to inject a delay {{% /alert %}} - - - -
+![Fault Injection Action](/images/tutorial/05-02-fault-injection-action.png "Fault Injection Action") Select an HTTP Delay and specify the "Delay percentage" and "Fixed Delay" values. The default values will introduce a 5 seconds delay into 100% of received uuests. - - - +![HTTP Delay](/images/tutorial/05-02-http-delay.png "HTTP Delay") {{% alert title="Step 2" color="success" %}} Understanding *source* and *destination* metrics @@ -184,27 +141,17 @@ Telemetry is collected from proxies and it is labeled with information about the In our example, let's say that *travels* service ("Service A" in the Istio diagram below) invokes the *hotels* service ("Service B" in the diagram). *Travels* is the "source" workload and *hotels* is the "destination" workload. The *travels* proxy will report telemetry from the source perspective and *hotels* proxy will report telemetry from the destination perspective. Let's look at the latency reporting from both perspectives. - - - - -
+![Istio Architecture](/images/tutorial/05-02-istio-architecture.png "Istio Architecture") The *travels* workload proxy has the Fault Injection configuration so it will perform the call to the *hotels* service and will apply the delay on the *travels* workload side (this is reported as *source* telemetry). We can see in the *hotels* telemetry reported by the *source* (the *travels* proxy) that there is a visible gap showing 5 second delay in the request duration. - - - - -
+![Source Metrics](/images/tutorial/05-02-source-metrics.png "Source Metrics") But as the Fault Injection delay is applied on the source proxy (*travels*), the destination proxy (*hotels*) is unaffected and its destination telemetry show no delay. - - - +![Destination Metrics](/images/tutorial/05-02-destination-metrics.png "Destination Metrics") {{% alert title="Step 3" color="success" %}} Study the impact of the *travels* service delay @@ -212,9 +159,7 @@ Study the impact of the *travels* service delay The injected delay is propagated from the *travels* service to the downstream services deployed on *travel-portal* namespace, degrading the overall response time. But the downstream services are unaware, operate normally, and show a green status. - - - +![Degraded Response Time](/images/tutorial/05-02-degraded-response-time.png "Degraded Response Time") {{% alert title="Step 4" color="success" %}} Update or delete Istio Configuration @@ -238,25 +183,17 @@ At the beginning we will send 80% of the traffic into the original *travels-v1* Use the Traffic Shifting Wizard on *travels* service {{% /alert %}} - - - - -
+![Traffic Shifting Action](/images/tutorial/05-03-traffic-shifting-action.png "Traffic Shifting Action") Create a scenario with 80% of the traffic distributed to *travels-v1* workload and 10% of the traffic distributed each to *travels-v2* and *travels-v3*. - - - +![Split Traffic](/images/tutorial/05-03-split-traffic.png "Split Traffic") {{% alert title="Step 2" color="success" %}} Examine Traffic Shifting distribution from the *travels-agency* Graph {{% /alert %}} - - - +![Travels Graph](/images/tutorial/05-03-travels-graph.png "Travels Graph") {{% alert title="Step 3" color="success" %}} Compare *travels* workload and assess new changes proposed in *travels-v2* and *travels-v3* @@ -266,17 +203,8 @@ Istio Telemetry is grouped per logical application. That has the advantage of ea In our example, we can use the "Inbound Metrics" and "Outbound Metrics" tabs in the *travels* application details, group by "Local version" and compare how *travels-v2* and *travels-v3* are working. - - - - -
- - - - - -
+![Compare Travels Workloads](/images/tutorial/05-03-compare-local-travels-version.png "Compare Travels Workloads") +![Compare Travels Workloads](/images/tutorial/05-03-compare-local-travels-version-2.png "Compare Travels Workloads") The charts show that the Traffic distribution is working accordingly and 80% is being distributed to *travels-v1* workload and they also show no big differences between *travels-v2* and *travels-v3* in terms of request duration. @@ -313,27 +241,17 @@ kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/ Use the TCP Traffic Shifting Wizard on *mysqldb* service {{% /alert %}} - - - - -
+![TCP Traffic Shifting Action](/images/tutorial/05-04-tcp-traffic-shifting-action.png "TCP Traffic Shifting Action") Create a scenario with 80% of the traffic distributed to *mysqldb-v1* workload and 10% of the traffic distributed each to *mysqldb-v2* and *mysqldb-v3*. - - - +![TCP Split Traffic](/images/tutorial/05-04-tcp-split-traffic.png "TCP Split Traffic") {{% alert title="Step 3" color="success" %}} Examine Traffic Shifting distribution from the *travels-agency* Graph {{% /alert %}} - - - - -
+![MysqlDB Graph](/images/tutorial/05-04-tcp-graph.png "MysqlDB Graph") Note that TCP telemetry has different types of metrics, as "Traffic Distribution" is only available for HTTP/gRPC services, for this service we need to use "Traffic Rate" to evaluate the distribution of data (bytes-per-second) between *mysqldb* workloads. @@ -343,12 +261,7 @@ Compare *mysqldb* workload and study new indexes proposed in *mysqldb-v2* and *m TCP services have different telemetry but it's still grouped by versions, allowing the user to compare and study pattern differences for *mysqldb-v2* and *mysqldb-v3*. - - - - - -
+![Compare MysqlDB Workloads](/images/tutorial/05-04-tcp-compare-versions.png "Compare MysqlDB Workloads") The charts show more peaks in *mysqldb-v2* compared to *mysqldb-v3* but overall a similar behavior, so it's probably safe to choose either strategy to shift all traffic. @@ -384,25 +297,15 @@ Add a rule to add a request timeout only on requests coming from *voyages.fr* po - Use the Request Timeouts tab to add an HTTP Timeout for this rule. - Add the rule to the scenario. - - - - -
+![Request Timeout Rule](/images/tutorial/05-05-request-timeout-rule.png "Request Timeout Rule") A first rule should be added to the list like: - - - - -
+![Voyages Portal Rule](/images/tutorial/05-05-voyages-rule.png "Voyages Portal Rule") Add a second rule to match any request and create the scenario. With this configuration, requests coming from *voyages.fr* will match the first rule and all others will match the second rule. - - - +![Any Request Rule](/images/tutorial/05-05-generic-rule.png "Any Request Rule") {{% alert title="Step 3" color="success" %}} Review the impact of the request timeout in the *travels* service @@ -412,25 +315,12 @@ Create the rule. The Graph will show how requests coming from *voyages.fr* start Requests coming from other portals work without failures but are degraded by the *hotels* delay. - - - - -
+![Travels Graph](/images/tutorial/05-05-travels-graph-voyages-error.png "Travels Graph") This scenario can be visualized in detail if we examine the "Inbound Metrics" and we group by "Remote app" and "Response code". - - - - -
- - - - - -
+![Travels Inbound Metrics](/images/tutorial/05-05-voyages-rule-metrics.png "Travels Inbound Metrics") +![Travels Inbound Metrics](/images/tutorial/05-05-voyages-rule-metrics-2.png "Travels Inbound Metrics") As expected, the requests coming from *voyages.fr* don't propagate the delay and they fail in the 2 seconds range, meanwhile requests from other portals don't fail but they propagate the delay introduced in the *hotels* service. @@ -464,19 +354,11 @@ kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/ The *loadtester* workload will try to create 50 concurrent connections to the *travels* service, adding considerable pressure to the *travels-agency* namespace. - - - - -
+![Loadtester Graph](/images/tutorial/05-06-loadtester-graph.png "Loadtester Graph") The Travel Demo application is capable of handling this load and in a first look it doesn't show unhealthy status. - - - - -
+![Loadtester Details](/images/tutorial/05-06-loadtester-details.png "Loadtester Details") But in a real scenario an unexpected increase in the load of a service like this may have a significant impact in the overall system status. @@ -486,16 +368,10 @@ Use the Traffic Shifting Wizard on *travels* service to generate a traffic rule Use the "Traffic Shifting" Wizard to distribute traffic (evenly) to the *travels* workloads and use the "Advanced Options" to add a "Circuit Breaker" to the scenario. - - - - -
+![Traffic Shifting with Circuit Breaker](/images/tutorial/05-06-traffic-shifting-circuit-breaker.png "Traffic Shifting with Circuit Breaker") The "Connection Pool" settings will indicate that the proxy sidecar will reject requests when the number of concurrent connections and requests exceeds more than one. -
- The "Outlier Detection" will eject a host from the connection pool if there is more than one consecutive error. {{% alert title="Step 3" color="success" %}} @@ -508,17 +384,11 @@ Remember, that these connections are stopped by the proxy on the *loadtester* si Using the Graph we can select the failed edge, check the Flags tab, and see that those requests are closed by the Circuit breaker. - - - - -
+![Loadtester Flags Graph](/images/tutorial/05-06-loadtester-flags-graph.png "Loadtester Flags Graph") If we examine the "Request volume" metric from the "Outbound Metrics" tab we can see the evolution of the requests, and how the introduction of the Circuit Breaker made the proxy reduce the request volume. - - - +![Loadtester Outbound Metrics](/images/tutorial/05-06-loadtester-flags-details.png "Loadtester Outbound Metrics") {{% alert title="Step 4" color="success" %}} Update or delete Istio Configuration @@ -526,8 +396,6 @@ Update or delete Istio Configuration As part of this step you can update the scenarios defined around the *travels* service to experiment with more Circuit Breaker settings, or you can delete the generated Istio config in the service. -
- Understanding what happened: [(i) Circuit Breaking](https://istio.io/latest/docs/tasks/traffic-management/circuit-breaking/) @@ -563,9 +431,7 @@ We will simulate the following: - *travels-v2* is the new version to deploy, it's being evaluated and it will get 20% of the traffic to compare against *travels-v1* - But *travels-v3* will be considered as a new, experimental version for testing outside of the regular request path. It will be defined as a mirrored workload on 50% of the original requests. - - - +![Mirrored Traffic](/images/tutorial/05-07-mirrored-traffic.png "Mirrored Traffic") {{% alert title="Step 2" color="success" %}} Examine Traffic Shifting distribution from the *travels-agency* Graph @@ -576,29 +442,17 @@ although it is not flagged as mirrored, and therefore an edge from *travels* to Note the traffic rates reflect the expected ratio of 80/20 between *travels-v1* and *travels-v2*, with *travels-v3* at about half of that total. - - - - -
+![Mirrored Graph](/images/tutorial/05-07-mirrored-graph.png "Mirrored Graph") This can be examined better using the "Source" and "Destination" metrics from the "Inbound Metrics" tab. The "Source" proxy, in this case the proxies injected into the workloads of *travel-portal* namespace, won't report telemetry for *travels-v3* mirrored workload. - - - - -
+![Mirrored Source Metrics](/images/tutorial/05-07-mirrored-source-metrics.png "Mirrored Source Metrics") But the "Destination" proxy, in this case the proxy injected in the *travels-v3* workload, will collect the telemetry from the mirrored traffic. - - - - -
+![Mirrored Destination Metrics](/images/tutorial/05-07-mirrored-destination-metrics.png "Mirrored Destination Metrics") {{% alert title="Step 3" color="success" %}} Update or delete Istio Configuration diff --git a/content/en/docs/Tutorials/travels/06-secure.md b/content/en/docs/Tutorials/travels/06-secure.md index 5347e04cf..cffb8a5e7 100644 --- a/content/en/docs/Tutorials/travels/06-secure.md +++ b/content/en/docs/Tutorials/travels/06-secure.md @@ -33,9 +33,7 @@ kubectl delete -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master We should validate that telemetry has updated the *travel-portal* namespace and "Security" can be enabled in the Graph Display options. - - - +![Travel Portal Graph](/images/tutorial/06-01-travel-portal-graph.png "Travel Portal Graph") {{% alert title="Step 2" color="success" %}} Create Authorization Policies for current traffic for *travel-agency* namespace @@ -47,17 +45,11 @@ Every workload in the cluster uses a [Service Account](https://kubernetes.io/doc This information is propagated into the Istio Telemetry and Kiali can use it to define a set of AuthorizationPolicy rules using the "Create Traffic Policies" action located in the Overview page. - - - - -
+![Create Traffic Policies](/images/tutorial/06-01-create-traffic-policies.png "Create Traffic Policies") This will generate a main DENY ALL rule to protect the whole namespace, and an individual ALLOW rule per workload identified in the telemetry. - - - +![Travel Agency Authorization Policies](/images/tutorial/06-01-travel-agency-authorization-policies.png "Travel Agency Authorization Policies") {{% alert title="Step 3" color="success" %}} Deploy the *loadtester* portal in the *travel-portal* namespace @@ -75,25 +67,15 @@ kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/ Now, *travels* workload will reject requests made by *loadtester* workload and that situation will be reflected in Graph: - - - - -
+![Loadtester Denied](/images/tutorial/06-01-loadtester-denied.png "Loadtester Denied") This can also be verified in the details page using the Outbound Metrics tab grouped by response code (only the 403 line is present). - - - - -
+![Loadtester Denied Metrics](/images/tutorial/06-01-loadtester-denied-metrics.png "Loadtester Denied Metrics") Inspecting the Logs tab confirms that *loadtester* workload is getting a HTTP 403 Forbidden response from *travels* workloads, as expected. - - - +![Loadtester Logs](/images/tutorial/06-01-loadtester-logs.png "Loadtester Logs") {{% alert title="Step 4" color="success" %}} Update *travels-v1* AuthorizationPolicy to allow *loadtester* ServiceAccount @@ -103,25 +85,15 @@ AuthorizationPolicy resources are defined per workload using matching selectors. As part of the example, we can show how a ServiceAccount can be added into an existing rule to allow traffic from *loadtester* workload into the *travels-v1* workload only. - - - - -
+![AuthorizationPolicy Edit](/images/tutorial/ "AuthorizationPolicy Edit") As expected, now we can see that *travels-v1* workload accepts requests from all *travel-portal* namespace workloads, but *travels-v2* and *travels-v3* continue rejecting requests from *loadtester* source. - - - - -
+![Travels v1 AuthorizationPolicy](/images/tutorial/06-01-travels-v1-authorizationpolicy.png "Travels v1 AuthorizationPolicy") Using "Outbound Metrics" tab from the *loadtester* workload we can group per "Remote version" and "Response code" to get a detailed view of this AuthorizationPolicy change. - - - +![Travels v1 AuthorizationPolicy](/images/tutorial/06-01-loadtester-authorized-metrics.png "Travels v1 AuthorizationPolicy") {{% alert title="Step 5" color="success" %}} Update or delete Istio Configuration diff --git a/content/en/docs/Tutorials/travels/99-uninstall/01-uninstall-travel-demo.adoc b/content/en/docs/Tutorials/travels/99-uninstall/01-uninstall-travel-demo.md similarity index 80% rename from content/en/docs/Tutorials/travels/99-uninstall/01-uninstall-travel-demo.adoc rename to content/en/docs/Tutorials/travels/99-uninstall/01-uninstall-travel-demo.md index b7e5d0b9b..f73b7cd1a 100644 --- a/content/en/docs/Tutorials/travels/99-uninstall/01-uninstall-travel-demo.adoc +++ b/content/en/docs/Tutorials/travels/99-uninstall/01-uninstall-travel-demo.md @@ -2,15 +2,12 @@ title: Undeploy the Travel Demo weight: 99 --- -:icons: font -:sectlinks: -:linkattrs: To uninstall the Travel Demo application perform the following commands: -[source,bash] ----- +``` kubectl delete namespace travel-agency kubectl delete namespace travel-portal kubectl delete namespace travel-control ----- +``` + diff --git a/scripts/backfill-tags.sh b/scripts/backfill-tags.sh deleted file mode 100755 index e54e5fc1a..000000000 --- a/scripts/backfill-tags.sh +++ /dev/null @@ -1,69 +0,0 @@ -#!/bin/bash - -# This script does the backfilling of tags for our legacy version, to be used -# for the versioned documentation migration. It is kept here for archiving -# purposes. -# -# Be careful running it as it creates tags on the current repo you're on. -# Run with "-f" to disable dry run mode. - -KIALI_REPO="${KIALI_REPO:-${GOPATH}/src/github.com/kiali/kiali}" -FIRST_LEGACY_VERSION="v1.0.0" -LAST_LEGACY_VERSION="v1.17.0" - -die() { - echo "ERROR: ${1}" -} - -# TODO: rename -create_kiali_io_tags() { - # We need to get the latest tags from the repo so we don't overwrite them. - echo "Updating kiali.io to get the latest tags..." - git fetch --all --tags - - pushd "${KIALI_REPO}" &>/dev/null || die "pushd failed." - - echo "Updating Kiali core repository to get the latest tags..." - git fetch --all --tags - - # - List all versions in semver order - # - Remove old versions that were tagged incorrectly (like "0.2.0") - # - Remove snapshot versions - # - Remove some named quickfix versions, (like "v0.9.1.helmfix") - # - Remove patch versions as they are out of order - # - # Removing those versions from the list is safe because we are only going to - # iterate over legacy tags. New tags are supposed to be created on version - # release. - versions=$(git tag -l --sort=v:refname | grep -E "v[0-9]+\\.[0-9]+\\.0$") - start_date=$(git show -s --format="%at" ${FIRST_LEGACY_VERSION}) - end_date=$(git show -s --format="%at" ${LAST_LEGACY_VERSION}) - - for version in ${versions}; do - commit_date=$(git show -s --format="%at" "${version}") - - [ "${commit_date}" -lt "${start_date}" ] && continue - [ "${commit_date}" -gt "${end_date}" ] && continue - - popd &>/dev/null || die "popd failed" - - # Important: here we only fetch merge commits, so we don't point at incomplete work. - latest_commit_on_tag=$(git rev-list -1 --merges --before="$(date +%s -d "@$(echo "${commit_date} - 1" | bc)")" --format="%at" master \ - | grep commit | sed -e "s/commit //" \ - | tail -n 1) - - echo "Creating tag for version ${version}..." - - if [ "${1}" = "-f" ]; then - git tag "${version}" "${latest_commit_on_tag}" || echo "Version ${version} already exists" - else - echo "DRY_RUN: git tag ${version} ${latest_commit_on_tag}" - fi - - pushd "${KIALI_REPO}" &>/dev/null || die "pushd failed." - done - - popd &>/dev/null || die "popd failed." -} - -create_kiali_io_tags "${1}" diff --git a/scripts/build-archive.sh b/scripts/build-archive.sh deleted file mode 100755 index c15880bab..000000000 --- a/scripts/build-archive.sh +++ /dev/null @@ -1,20 +0,0 @@ -#!/bin/bash - -set -xe - -tag="${1%.0}" -root="$(pwd)/content/documentation" - -echo "Preparing documentation for version ${tag}" - -cp -r "${root}"/staging "${root}"/${tag} - -find "${root}/${tag}" -type f -name "*.adoc" -exec sed -i -e "s/ main:/ $(echo "${tag}" | tr "." "-"):/" "{}" \; -find "${root}/${tag}" -type f -name "*.adoc" -exec sed -i -e "s;/staging/;/${tag}/;g" "{}" \; -sed -i -r "s/: \"(Staging|Documentation)\"/: ${tag}/g" "${root}/${tag}/_index.adoc" - -rm "${root}/latest" -cd "${root}" - -ln -s ${tag} latest - diff --git a/scripts/build-swagger.sh b/scripts/build-swagger.sh deleted file mode 100755 index 7c6fb330d..000000000 --- a/scripts/build-swagger.sh +++ /dev/null @@ -1,11 +0,0 @@ -#!/usr/bin/env bash -# Build Swagger API - -######################################################## -# @todo: next sprint add new working/lighter weight developer-api docs via asciidoc -# once the kiali npm package is published -######################################################## - -# curl https://raw.githubusercontent.com/kiali/kiali/master/swagger.json > swagger.json -# npx @kiali/swagger2adoc swagger.json -o content/documentation/staging/developer-api/index.adoc -# rm swagger.json