Skip to content

Commit

Permalink
update docs
Browse files Browse the repository at this point in the history
  • Loading branch information
nataliasitko committed Sep 16, 2024
1 parent 0325501 commit f0468c5
Show file tree
Hide file tree
Showing 5 changed files with 43 additions and 48 deletions.
1 change: 1 addition & 0 deletions docs/user/00-15-overview-istio-setup.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
20 changes: 9 additions & 11 deletions docs/user/00-20-istio-sidecar-proxies.md
Original file line number Diff line number Diff line change
@@ -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
<!-- markdown-link-check-disable-next-line -->
Expand All @@ -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).
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).
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,12 @@
## Check If Sidecar Injection Is Enabled in the Pod's Namespace

<!-- tabs:start -->
#### **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:
Expand All @@ -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)
<!-- tabs:end -->

## Check If Sidecar Injection Is Enabled for the Pod's Deployment
Expand Down
42 changes: 19 additions & 23 deletions docs/user/tutorials/01-40-enable-sidecar-injection.md
Original file line number Diff line number Diff line change
@@ -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

<!-- tabs:start -->
#### **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**

Expand All @@ -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**.
<!-- tabs:end -->


* To enable sidecar proxy injection for a Pod, you can use either kubectl or Kyma dashboard:
## Enable Istio Sidecar Proxy Injection for a Pod

<!-- tabs:start -->

#### **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.
Expand All @@ -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"}}}}}'
```

<!-- tabs:end -->
15 changes: 8 additions & 7 deletions docs/user/tutorials/01-45-enable-istio-access-logs.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,20 +25,20 @@ The [log format](https://github.com/kyma-project/istio/blob/main/internal/istioo
Use the Telemetry API to selectively enable Istio access logs. See:
<!-- no toc -->
- [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
<!-- tabs:start -->
#### **Kyma Dashboard**
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**
Expand Down Expand Up @@ -127,15 +127,16 @@ To configure label-based selection of workloads, use a [selector](https://istio.
```
<!-- tabs:end -->

### 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.

<!-- tabs:start -->
#### **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
Expand All @@ -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**

Expand Down

0 comments on commit f0468c5

Please sign in to comment.