From f0468c57c1a5f5d7d6149e7a18f8b695c8df0fdc Mon Sep 17 00:00:00 2001 From: nataliasitko Date: Mon, 16 Sep 2024 13:29:49 +0200 Subject: [PATCH] update docs --- docs/user/00-15-overview-istio-setup.md | 1 + docs/user/00-20-istio-sidecar-proxies.md | 20 ++++----- ...5-check-if-sidecar-injection-is-enabled.md | 13 +++--- .../01-40-enable-sidecar-injection.md | 42 +++++++++---------- .../01-45-enable-istio-access-logs.md | 15 +++---- 5 files changed, 43 insertions(+), 48 deletions(-) diff --git a/docs/user/00-15-overview-istio-setup.md b/docs/user/00-15-overview-istio-setup.md index 68d267abf1..b4d5abcc90 100644 --- a/docs/user/00-15-overview-istio-setup.md +++ b/docs/user/00-15-overview-istio-setup.md @@ -11,6 +11,7 @@ Istio Operator provides baseline values for the Istio installation, which you ca - The use of HTTP 1.0 is enabled in the outbound HTTP listeners by the **PILOT_HTTP10** flag set in the Istiod component environment variables. - No Egress limitations are implemented - all applications deployed in the Kyma cluster can access outside resources without limitations. - The CNI component is provided as a DaemonSet, meaning that one replica is present on every node of the target cluster. +- The self-signed CA certificate’s bit length is set to 4096 instead of the default 2048. ## Configuration Based on the Cluster Size diff --git a/docs/user/00-20-istio-sidecar-proxies.md b/docs/user/00-20-istio-sidecar-proxies.md index 0ebc3f5fbe..2fd2a07af9 100644 --- a/docs/user/00-20-istio-sidecar-proxies.md +++ b/docs/user/00-20-istio-sidecar-proxies.md @@ -1,14 +1,14 @@ # Istio Sidecar Proxies -A service mesh is an infrastructure layer that handles service-to-service communication, proxying, service discovery, traceability, and security, independently of the code of the services. To deliver this functionality, the Istio module uses the [Istio](https://istio.io/docs/concepts/what-is-istio/) service mesh that is customized for the specific needs of the implementation. +A service mesh is an infrastructure layer that handles service-to-service communication, proxying, service discovery, traceability, and security, independently of the code of the services. To deliver this functionality, the Istio module uses the [Istio service mesh](https://istio.io/docs/concepts/what-is-istio/) that is customized for the specific needs of an implementation. -The main principle of the Istio service mesh is to inject Pods of every service with the Envoy sidecar proxy. Envoy intercepts the communication between the services and regulates it by applying and enforcing the rules you create. +The main principle of the Istio service mesh is to inject Pods of every service with Istio sidecar proxy, which is an extended version of the Envoy proxy. Envoy intercepts the communication between the services and regulates it by applying and enforcing the rules you create. ## Purpose and Benefits of Istio Sidecars -By default, Istio installed as part of the Istio module is configured with automatic Istio sidecar proxy injection disabled. This means that none of your workloads' Pods, except those in the `kyma-system` namespace, get their own sidecar proxy container running next to your application. You can manage mTLS traffic in services or at a namespace level by creating [DestinationRule](https://istio.io/docs/reference/config/networking/destination-rule/) and [PeerAuthentication](https://istio.io/docs/tasks/security/authentication/authn-policy/) resources. If you disable sidecar injection for a service or for a namespace, you must manage their traffic configuration by creating appropriate DestinationRule and PeerAuthentication resources. +By default, Istio installed as part of the Istio module is configured with automatic Istio sidecar proxy injection disabled. This means that none of your workloads' Pods, except those in the `kyma-system` namespace, get their own sidecar proxy container running next to the application. When sidecar injection is disabled for a service or for a namespace, you must traffic configuration in services or at a namespace level by creating [DestinationRule](https://istio.io/docs/reference/config/networking/destination-rule/) and [PeerAuthentication](https://istio.io/docs/tasks/security/authentication/authn-policy/) resources. -With an Istio sidecar, the resource becomes part of the Istio service mesh, which brings the following benefits that would be complex to manage otherwise. +With an Istio sidecar proxy injected, a resource becomes part of the Istio service mesh, which brings the following benefits that would be complex to manage otherwise. ### Secure Communication @@ -22,18 +22,16 @@ Istio proxies enhance tracing capabilities by performing global tracing and forw ### Traffic Management -[Traffic management](https://istio.io/latest/docs/concepts/traffic-management/) is an important feature of service mesh. If you have the sidecar injected into every workload, you can use Istio’s traffic routing rules without additional configuration. +If you have the sidecar injected into every workload, you can use Istio’s traffic routing rules without additional configuration. See [Traffic management](https://istio.io/latest/docs/concepts/traffic-management/). -With [traffic shifting](https://istio.io/latest/docs/tasks/traffic-management/traffic-shifting/) and [request routing](https://istio.io/latest/docs/tasks/traffic-management/request-routing/), developers can use techniques like canary releases and A/B testing to make their software release process faster and more reliable. - -To improve the resiliency of your applications, you can use [mirroring](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) and [fault injection](https://istio.io/latest/docs/tasks/traffic-management/fault-injection/) for testing and audit purposes. +[Traffic shifting](https://istio.io/latest/docs/tasks/traffic-management/traffic-shifting/) and [request routing](https://istio.io/latest/docs/tasks/traffic-management/request-routing/) allows you to use techniques like canary releases and A/B testing to make your software release process faster and more reliable. To improve the resiliency of your applications, you can use [mirroring](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) and [fault injection](https://istio.io/latest/docs/tasks/traffic-management/fault-injection/) for testing and audit purposes. ### Resiliency Application resiliency is an important topic within traffic management. Traditionally, resiliency features like timeouts, retries, and circuit breakers were implemented by application libraries. However, with service mesh, you can delegate such tasks to the mesh, and the same configuration options will work regardless of the programming language of your application. See [Network Resilience and Testing](https://istio.io/latest/docs/concepts/traffic-management/#network-resilience-and-testing). -## Restart of Workloads with Enabled Sidecar Injection +## Restart of Workloads with Enabled Istio Sidecar Injection When the Istio version is updated or the configuration of the proxies is changed, the Pods that have Istio injection enabled are automatically restarted. This is possible for all resources that allow for a rolling restart. If Istio is uninstalled, the workloads are restarted again to remove the sidecars. -However, if a resource is a job, a ReplicaSet that is not managed by any Deployment, or a Pod that is not managed by any other resource, the restart cannot be performed automatically. In such cases, a warning is logged, and you must manually restart the resources. -Istio Operator does not restart an Istio sidecar proxy, if it has a custom image set. See [Resource Annotations](https://istio.io/latest/docs/reference/config/annotations/#SidecarProxyImage). \ No newline at end of file +However, if a resource is a Job, a ReplicaSet that is not managed by any Deployment, or a Pod that is not managed by any other resource, the restart cannot be performed automatically. In such cases, a warning is logged, and you must manually restart the resources. +The Istio module does not restart an Istio sidecar proxy, if it has a custom image set. See [Resource Annotations](https://istio.io/latest/docs/reference/config/annotations/#SidecarProxyImage). \ No newline at end of file diff --git a/docs/user/tutorials/01-35-check-if-sidecar-injection-is-enabled.md b/docs/user/tutorials/01-35-check-if-sidecar-injection-is-enabled.md index ef8a793e9e..dbbc3f53a2 100644 --- a/docs/user/tutorials/01-35-check-if-sidecar-injection-is-enabled.md +++ b/docs/user/tutorials/01-35-check-if-sidecar-injection-is-enabled.md @@ -3,6 +3,12 @@ ## Check If Sidecar Injection Is Enabled in the Pod's Namespace +#### **Kyma Dashboard** + +1. Go to the Pod's namespace. +2. Verify if the `Labels` section contains `istio-injection=enabled`. If the section doesn't contain the label, the sidecar injection is disabled in this namespace. + Here's an example of a namespace where the Istio sidecar proxy injection is enabled: + ![Namespace with enabled Istio sidecar injection](../../assets/namespace-with-enabled-istio-sidecar.svg) #### **kubectl** To check if the Pod's namespace is labeled with `istio-injection=enabled`, run: @@ -12,13 +18,6 @@ To check if the Pod's namespace is labeled with `istio-injection=enabled`, run: ``` If the command does not return `enabled`, the sidecar injection is disabled in this namespace. -#### **Kyma Dashboard** - -1. Go to the Pod's namespace. -2. Verify if the `Labels` section contains `istio-injection=enabled`. If the section doesn't contain the label, the sidecar injection is disabled in this namespace. - Here's an example of a namespace where the Istio sidecar proxy injection is enabled: - ![Namespace with enabled Istio sidecar injection](../../assets/namespace-with-enabled-istio-sidecar.svg) - ## Check If Sidecar Injection Is Enabled for the Pod's Deployment diff --git a/docs/user/tutorials/01-40-enable-sidecar-injection.md b/docs/user/tutorials/01-40-enable-sidecar-injection.md index 50e41bedfc..a7bc3857c5 100644 --- a/docs/user/tutorials/01-40-enable-sidecar-injection.md +++ b/docs/user/tutorials/01-40-enable-sidecar-injection.md @@ -1,15 +1,19 @@ # Enable Automatic Istio Sidecar Proxy Injection -Enabling automatic sidecar injection allows `istiod` to watch all Pod creation operations on all namespaces, which should be part of the Istio service mesh, and inject the newly created Pods with a sidecar proxy. +Enabling automatic sidecar injection allows `istiod` to watch all creation operations of the Pods on all namespaces, which are part of the Istio service mesh, and inject the newly created Pods with a sidecar proxy. -You can enable sidecar proxy injection for either an entire namespace or a single Deployment. If the sidecar proxy injection is disabled at the namespace level, or the `sidecar.istio.io/inject` label on a Pod is set to `false`, the sidecar proxy is not injected. +You can enable sidecar proxy injection for either an entire namespace or a single Deployment. Adding the `istio-injection=enabled` label on the namespace level results in injecting sidecars to all newly created Pods inside of the namespace. If the sidecar proxy injection is disabled at the namespace level, or the `sidecar.istio.io/inject` label on a Pod is set to `false`, the sidecar proxy is not injected. -> [!NOTE] -> Adding the `istio-injection=enabled` label on the namespace level results in injecting sidecars to all Pods inside of the namespace. -* To enable sidecar proxy injection for a namespace, you can use either kubectl or Kyma dashboard: - +## Enable Istio Sidecar Proxy Injection for a Namespace + + #### **Kyma Dashboard** + + 1. Select the namespace where you want to enable sidecar proxy injection. + 2. Choose **Edit**. + 3. In the `Form` section, siwtch the toggle to enable Istio sidecar proxy injection. + 4. Choose **Save**. #### **kubectl** @@ -18,29 +22,13 @@ You can enable sidecar proxy injection for either an entire namespace or a singl ```bash kubectl label namespace {YOUR_NAMESPACE} istio-injection=enabled ``` - - #### **Kyma Dashboard** - - 1. Select the namespace where you want to enable sidecar proxy injection. - 2. Click **Edit**. - 3. In the `UI Form` section, set the **istio-injection** label value to `enabled` for the namespace. - ![Switch the toggle to enable Istio sidecar injection](../../assets/sidecar-injection-toggle-namespace.svg) - 1. Click **Update**. -* To enable sidecar proxy injection for a Pod, you can use either kubectl or Kyma dashboard: +## Enable Istio Sidecar Proxy Injection for a Pod - #### **kubectl** - - Use the following command: - - ```bash - kubectl patch -n {YOUR_NAMESPACE} deployments/{YOUR_DEPLOYMENT} -p '{"spec":{"template":{"metadata":{"labels":{"sidecar.istio.io/inject":"true"}}}}}' - ``` - #### **Kyma Dashboard** 1. Select the namespace of the Pod's Deployment. @@ -50,4 +38,12 @@ You can enable sidecar proxy injection for either an entire namespace or a singl ![Switch the toggle to enable Istio sidecar injection](../../assets/sidecar-injection-toggle-deployment.svg) 1. Click **Update**. + #### **kubectl** + + Run the following command: + + ```bash + kubectl patch -n {YOUR_NAMESPACE} deployments/{YOUR_DEPLOYMENT} -p '{"spec":{"template":{"metadata":{"labels":{"sidecar.istio.io/inject":"true"}}}}}' + ``` + \ No newline at end of file diff --git a/docs/user/tutorials/01-45-enable-istio-access-logs.md b/docs/user/tutorials/01-45-enable-istio-access-logs.md index a46a83d70f..5cd4b2a4c6 100644 --- a/docs/user/tutorials/01-45-enable-istio-access-logs.md +++ b/docs/user/tutorials/01-45-enable-istio-access-logs.md @@ -25,12 +25,12 @@ The [log format](https://github.com/kyma-project/istio/blob/main/internal/istioo Use the Telemetry API to selectively enable Istio access logs. See: -- [Configure Istio Access Logs for the Entire Namespace](#configure-istio-access-logs-for-the-entire-namespace) +- [Configure Istio Access Logs for a Namespace](#configure-istio-access-logs-for-the-entire-namespace) - [Configure Istio Access Logs for a Selective Workload](#configure-istio-access-logs-for-a-selective-workload) - [Configure Istio Access Logs for a Specific Gateway](#configure-istio-access-logs-for-a-specific-gateway) - [Configure Istio Access Logs for the Entire Mesh](#configure-istio-access-logs-for-the-entire-mesh) -### Configure Istio Access Logs for the Entire Namespace +### Configure Istio Access Logs for a Namespace @@ -38,7 +38,7 @@ Use the Telemetry API to selectively enable Istio access logs. See: 1. Go to the namespace for which you want to configure Istio access logs. 2. Go to **Istio > Telemetries** and select **Create**. -3. Provide the name, for example, `access-config`. +3. Provide a name, for example, `access-config`. 4. Select **Create**. #### **kubectl** @@ -127,15 +127,16 @@ To configure label-based selection of workloads, use a [selector](https://istio. ``` -### Configure Istio Access Logs for a Specific Gateway +### Configure Istio Access Logs for a Selective Gateway Instead of enabling the access logs for all the individual proxies of the workloads you have, you can enable the logs for the proxy used by the related Istio Ingress Gateway. #### **Kyma Dashboard** 1. Go to the `istio-system` namespace. -2. Go to **Istio > Telemetries** and select **Create**. -3. Switch to the `YAML` section and paste the following sample configuration into the editor: +2. Go to **Istio > Telemetries**. +3. Select **Create**. +4. Switch to the `YAML` section and paste the following sample configuration into the editor: ```yaml apiVersion: telemetry.istio.io/v1 kind: Telemetry @@ -150,7 +151,7 @@ Instead of enabling the access logs for all the individual proxies of the worklo - providers: - name: stdout-json ``` -4. Select **Create**. +5. Select **Create**. #### **kubectl**