Added the Best Practices section with general principles. (#5137)

* Added the Best Practices section with general principles.

This is the beginning of the new Best Practices section.
Our goal is to provide a section for all the best practices and recommendations
for Istio deployments. The best practices are based on the identified and
recommended deployment models.

Signed-off-by: rcaballeromx <grca@google.com>

* Change headings for clarity.

Adds clarity to some passages based on feedback.
Removes a list of recommendations that was causing some confusion.
Adds a glossary entry for failure domains and how they relate to a
platform's availability zones.

Signed-off-by: rcaballeromx <grca@google.com>

* Move Best Practices to Ops Guide

Signed-off-by: rcaballeromx <grca@google.com>

* Moved Deployment Best Practices to a new "Prepare Your Deployment" section.

Moved all deployment preparation content into a new section under "Setup".
For now the content includes the following sections:

- Deployment models
- Deployment best practices
- Pod requirements

Merged the two existing pages containing pod requirements into one single page.

Signed-off-by: rcaballeromx <grca@google.com>

* Replace example with better guidance around namespace tenancy.

Signed-off-by: Rigs Caballero <grca@google.com>

* Add links and language pointing to the Prepare section

Signed-off-by: Rigs Caballero <grca@google.com>

* Fix minor typos and broken links.

Signed-off-by: Rigs Caballero <grca@google.com>

* Move from Setup to Operations

Signed-off-by: Rigs Caballero <grca@google.com>

* Fix broken links

Signed-off-by: Rigs Caballero <grca@google.com>

* Fix rebasing issues.

Signed-off-by: Rigs Caballero <grca@google.com>

* Fix multicluster install link.

Signed-off-by: Rigs Caballero <grca@google.com>
This commit is contained in:
Rigs Caballero 2019-11-14 08:58:29 -08:00 committed by Frank Budinsky
parent 048c8e2deb
commit 22d066be37
56 changed files with 608 additions and 64 deletions

View File

@ -18,10 +18,10 @@ wondering if all these things will be just as simple in your real production env
Fortunately, Istio provides several ways to configure a service mesh so that applications
can, more-or-less transparently, be part of a mesh where the services are running
in more than one cluster, i.e., in a
[multicluster deployment](/docs/setup/deployment-models/#multiple-clusters).
[multicluster deployment](/docs/ops/prep/deployment-models/#multiple-clusters).
The simplest way to set up a multicluster mesh, because it has no special networking requirements,
is using a replicated
[control plane model](/docs/setup/deployment-models/#control-plane-models).
[control plane model](/docs/ops/prep/deployment-models/#control-plane-models).
In this configuration, each Kubernetes cluster contributing to the mesh has its own control plane,
but each control plane is synchronized and running under a single administrative control.

View File

@ -9,7 +9,7 @@ aliases:
---
This example shows how to configure a multicluster mesh with a
[single-network deployment](/docs/setup/deployment-models/#single-network)
[single-network deployment](/docs/ops/prep/deployment-models/#single-network)
over 2 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) clusters.
## Before you begin

View File

@ -11,7 +11,7 @@ aliases:
This example demonstrates how to setup network connectivity between two
[IBM Cloud Private](https://www.ibm.com/cloud/private) clusters
and then compose them into a multicluster mesh using a
[single-network deployment](/docs/setup/deployment-models/#single-network).
[single-network deployment](/docs/ops/prep/deployment-models/#single-network).
## Create the IBM Cloud Private clusters

View File

@ -52,7 +52,7 @@ but similar version routing rules have no effect on your own application, it may
your Kubernetes services need to be changed slightly.
Kubernetes services must adhere to certain restrictions in order to take advantage of
Istio's L7 routing features.
Refer to the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/)
Refer to the [Requirements for Pods and Services](/docs/ops/prep/requirements/)
for details.
Another potential issue is that the route rules may simply be slow to take effect.

View File

@ -29,7 +29,7 @@ If the Istio Dashboard or the Prometheus queries dont show the expected metri
### Verify Istio CNI pods are running (if used)
The Istio CNI plugin performs the Istio mesh pod traffic redirection in the Kubernetes pod lifecycles network setup phase, thereby removing the [`NET_ADMIN` capability requirement](/docs/setup/additional-setup/requirements/) for users deploying pods into the Istio mesh. The Istio CNI plugin replaces the functionality provided by the `istio-init` container.
The Istio CNI plugin performs the Istio mesh pod traffic redirection in the Kubernetes pod lifecycles network setup phase, thereby removing the [`NET_ADMIN` capability requirement](/docs/ops/prep/requirements/) for users deploying pods into the Istio mesh. The Istio CNI plugin replaces the functionality provided by the `istio-init` container.
1. Verify that the `istio-cni-node` pods are running:
@ -37,7 +37,7 @@ The Istio CNI plugin performs the Istio mesh pod traffic redirection in the Kube
$ kubectl -n kube-system get pod -l k8s-app=istio-cni-node
{{< /text >}}
1. If `PodSecurityPolicy` is being enforced in your cluster, ensure the `istio-cni` service account can use a `PodSecurityPolicy` with the [`NET_ADMIN` capability requirement](/docs/setup/additional-setup/requirements/)
1. If `PodSecurityPolicy` is being enforced in your cluster, ensure the `istio-cni` service account can use a `PodSecurityPolicy` with the [`NET_ADMIN` capability requirement](/docs/ops/prep/requirements/)
### Verify Mixer is receiving report calls
Mixer generates metrics to monitor its own behavior. The first step is to check these metrics:

View File

@ -39,7 +39,7 @@ before continuing.
The `istioctl describe` command returns a warning if the {{< gloss >}}Envoy{{< /gloss >}}
proxy is not present in a pod or if the proxy has not started. Additionally, the command warns
if some of the [Istio requirements for pods](/docs/setup/additional-setup/requirements/)
if some of the [Istio requirements for pods](/docs/ops/prep/requirements/)
are not met.
For example, the following command produces a warning indicating a `kubernetes-dashboard`

View File

@ -0,0 +1,13 @@
---
title: Prepare Your Deployment
description: Learn about how to prepare an Istio deployment including the
requirements for your pods and best practices.
weight: 6
keywords:
- deployment-models
- best-practices
- pods
- requirements
- installation
- configuration
---

View File

Before

Width:  |  Height:  |  Size: 8.9 KiB

After

Width:  |  Height:  |  Size: 8.9 KiB

View File

Before

Width:  |  Height:  |  Size: 9.1 KiB

After

Width:  |  Height:  |  Size: 9.1 KiB

View File

Before

Width:  |  Height:  |  Size: 8.7 KiB

After

Width:  |  Height:  |  Size: 8.7 KiB

View File

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

View File

@ -1,7 +1,7 @@
---
title: Deployment Models
description: Describes the system models that impact your overall Istio depolyment.
weight: 6
weight: 1
keywords:
- single-cluster
- multiple-clusters

View File

Before

Width:  |  Height:  |  Size: 7.9 KiB

After

Width:  |  Height:  |  Size: 7.9 KiB

View File

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

View File

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

View File

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

View File

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

View File

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 18 KiB

View File

Before

Width:  |  Height:  |  Size: 9.7 KiB

After

Width:  |  Height:  |  Size: 9.7 KiB

View File

Before

Width:  |  Height:  |  Size: 5.8 KiB

After

Width:  |  Height:  |  Size: 5.8 KiB

View File

Before

Width:  |  Height:  |  Size: 8.1 KiB

After

Width:  |  Height:  |  Size: 8.1 KiB

View File

Before

Width:  |  Height:  |  Size: 8.0 KiB

After

Width:  |  Height:  |  Size: 8.0 KiB

View File

@ -0,0 +1,32 @@
---
title: Deployment Best Practices
description: General best practices for your Istio deployments.
weight: 2
icon: best-practices
keywords: [deployment-models, cluster, availability-zones, control-plane]
---
We have identified the following general principles to help you get the most
out of your Istio deployments. These best practices aim to limit the impact of
bad configuration changes and make managing your deployments easier.
## Deploy fewer clusters
Deploy Istio across a small number of large clusters, rather than a large number
of small clusters. Instead of adding clusters to your deployment, the best
practice is to use [namespace tenancy](/docs/ops/prep/deployment-models/#namespace-tenancy)
to manage large clusters. Following this approach, you can deploy Istio across
one or two clusters per zone or region. You can then deploy a control plane on
one cluster per region or zone for added reliability.
## Deploy clusters near your users
Include clusters in your deployment across the globe for **geographic
proximity to end-users**. Proximity helps your deployment have low latency.
## Deploy across multiple availability zones
Include clusters in your deployment **across multiple availability regions
and zones** within each geographic region. This approach limits the size of the
{{< gloss "failure domain" >}}failure domains{{< /gloss >}} of your deployment,
and helps you avoid global failures.

View File

@ -1,20 +1,31 @@
---
title: Pods and Services
description: Prepare your Kubernetes pods and services to run in an Istio-enabled cluster.
weight: 5
description: Prepare your Kubernetes pods and services to run in an Istio-enabled
cluster.
weight: 3
aliases:
- /docs/setup/kubernetes/spec-requirements/
- /docs/setup/kubernetes/prepare/spec-requirements/
- /docs/setup/kubernetes/prepare/requirements/
- /docs/setup/kubernetes/additional-setup/requirements/
keywords: [kubernetes,sidecar,sidecar-injection]
- /docs/setup/kubernetes/spec-requirements/
- /docs/setup/kubernetes/prepare/spec-requirements/
- /docs/setup/kubernetes/prepare/requirements/
- /docs/setup/kubernetes/additional-setup/requirements/
- /docs/setup/additional-setup/requirements
- /help/ops/setup/required-pod-capabilities
keywords:
- kubernetes
- sidecar
- sidecar-injection
- deployment-models
- pods
- setup
---
To be a part of an Istio service mesh, pods and services in a Kubernetes
cluster must satisfy the following requirements:
To be part of a mesh, Kubernetes pods and services must satisfy the following
requirements:
- **Named service ports**: Service ports must be named. The port name key/value
pairs must have the following syntax: `name: <protocol>[-<suffix>]`. See [Protocol Selection](/docs/ops/traffic-management/protocol-selection/) for more details.
pairs must have the following syntax: `name: <protocol>[-<suffix>]`. See
[Protocol Selection](/docs/ops/traffic-management/protocol-selection/) for
more details.
- **Service association**: A pod must belong to at least one Kubernetes
service even if the pod does NOT expose any port.
@ -45,7 +56,8 @@ cluster must satisfy the following requirements:
## Ports used by Istio
The following ports and protocols are used by Istio. Ensure that there are no TCP headless services using a TCP port used by one of Istio's services.
The following ports and protocols are used by Istio. Ensure that there are no
TCP headless services using a TCP port used by one of Istio's services.
| Port | Protocol | Used by | Description |
|----|----|----|----|
@ -70,3 +82,37 @@ The following ports and protocols are used by Istio. Ensure that there are no TC
| 15443 | TLS | Ingress and Egress Gateways | SNI |
| 15090 | HTTP | Mixer | Proxy |
| 42422 | TCP | Mixer | Telemetry - Prometheus |
## Required pod capabilities
Follow these steps to verify which capabilities are allowed for your pods.
If [pod security
policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
are [enforced](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies)
in your cluster and unless you use Istio CNI Plugin, your pods must have the
`NET_ADMIN` capability allowed. The initialization containers of the Envoy
proxies require this capability. To check which capabilities are allowed for
your pods, check if their [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
can use a pod security policy that allows the `NET_ADMIN` capability.
If you don't specify a service account in your pods' deployment, the pods run as
the `default` service account in their deployment's namespace.
To check which capabilities are allowed for the service account of your pods,
run the following command:
{{< text bash >}}
$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:<your namespace>:<your service account>) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done
{{< /text >}}
For example, to check which capabilities are allowed for the `default` service
account in the `default` namespace, run the following command:
{{< text bash >}}
$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done
{{< /text >}}
If you see `NET_ADMIN` or `*` in the list of capabilities of one of the allowed
policies for your service account, your pods have permission to run the Istio
init containers. Otherwise, you must [provide such permission](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#authorizing-policies).

View File

@ -0,0 +1,10 @@
---
title: Failure Domain
---
A failure domain is a physical or logical section of the computing environment
that is negatively affected when a critical device or service experiences
problems.
For an Istio deployment, failure domains could encompass multiple availability
zones of your platform.

View File

@ -6,4 +6,4 @@ Mesh federation is the act of exposing services between meshes and enabling
communication across mesh boundaries. Each mesh may expose a subset of its
services to enable one or more other meshes to consume the exposed services. You
can use mesh federation to enable communication between meshes in a
[multi-mesh deployment](/docs/setup/deployment-models/#multiple-meshes).
[multi-mesh deployment](/docs/ops/prep/deployment-models/#multiple-meshes).

View File

@ -24,7 +24,7 @@ networking functionality but without requiring Istio users to enable elevated
Kubernetes RBAC permissions.
The Istio CNI plugin performs the Istio mesh pod traffic redirection in the Kubernetes pod lifecycle's network
setup phase, thereby removing the [`NET_ADMIN` capability requirement](/docs/setup/additional-setup/requirements/)
setup phase, thereby removing the [`NET_ADMIN` capability requirement](/docs/ops/prep/requirements/)
for users deploying pods into the Istio mesh. The Istio CNI plugin
replaces the functionality provided by the `istio-init` container.

View File

@ -34,7 +34,7 @@ your specific needs. The following built-in configuration profiles are currently
This profile comes with additional authentication features enabled by default (Strict Mutual TLS).
1. **remote**: used for configuring remote clusters of a
[multicluster mesh](/docs/setup/deployment-models/#multiple-clusters) with a
[multicluster mesh](/docs/ops/prep/deployment-models/#multiple-clusters) with a
[shared control plane](/docs/setup/install/multicluster/shared-vpn/) configuration.
The components marked as **X** are installed within each profile:

View File

@ -8,11 +8,11 @@ aliases:
keywords: [getting-started, install, bookinfo, quick-start, kubernetes]
---
To get started with Istio, just follow these three steps:
To get started with Istio, just follow these steps:
1. [Set up your platform](#platform)
1. [Download the release](#download)
1. [Install Istio](#install)
- [Set up your platform](#platform)
- [Download the Istio release](#download)
- [Install Istio](#install)
## Set up your platform {#platform}
@ -69,7 +69,7 @@ These instructions assume you are new to Istio, providing streamlined instructio
install Istio's built-in `demo` [configuration profile](/docs/setup/additional-setup/config-profiles/).
This installation lets you quickly get started evaluating Istio.
If you are already familiar with Istio or interested in installing other configuration profiles
or a more advanced [deployment model](/docs/setup/deployment-models/),
or a more advanced [deployment model](/docs/ops/prep/deployment-models/),
follow the [installing with {{< istioctl >}} instructions](/docs/setup/install/istioctl) instead.
{{< warning >}}
@ -135,7 +135,7 @@ access logging.
prometheus-67cdb66cbb-9w2hm 1/1 Running 0 1m
{{< /text >}}
## What's next
## Next steps
With Istio installed, you can now deploy your own application or one of the sample applications
provided with the installation.
@ -182,10 +182,16 @@ The following tasks are a good place for beginners to start:
- [Accessing external services](/docs/tasks/traffic-management/egress/egress-control/)
- [Visualizing your mesh](/docs/tasks/observability/kiali/)
The next step is to customize Istio and deploy your own applications.
Before you install and customize Istio to fit your platform and intended use, check out
our [deployment models](/docs/setup/deployment-models/) and [general installation](/docs/setup/)
documents.
Before you install and customize Istio to fit your platform and intended use,
check out the following resources:
- [Deployment models](/docs/ops/prep/deployment-models/)
- [Deployment best practices](/docs/ops/prep/deployment/)
- [Pod requirements](/docs/ops/prep/requirements/)
- [General installation instructions](/docs/setup/)
Once you have a deployment that suits your needs, the next step is to deploy
your own applications.
As you continue to use Istio, we look forward to hearing from you and welcoming
you to our [community](/about/community/join/).

View File

@ -35,7 +35,7 @@ and then further customize the configuration for your specific needs.
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
1. Check the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/).
1. Check the [Requirements for Pods and Services](/docs/ops/prep/requirements/).
1. [Install a Helm client](https://github.com/helm/helm#install) with a version higher than 2.10.

View File

@ -24,7 +24,7 @@ Before you begin, check the following prerequisites:
1. [Download the Istio release](/docs/setup/getting-started/#download).
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
1. Check the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/).
1. Check the [Requirements for Pods and Services](/docs/ops/prep/requirements/).
## Install Istio using the default profile

View File

@ -16,5 +16,5 @@ a combination of the approaches can be used. For example,
two clusters might share a control plane while a third has its own.
{{< /tip >}}
Refer to the [multicluster deployment model](/docs/setup/deployment-models/#multiple-clusters)
Refer to the [multicluster deployment model](/docs/ops/prep/deployment-models/#multiple-clusters)
concept documentation for more information.

View File

@ -11,8 +11,8 @@ keywords: [kubernetes,multicluster,gateway]
---
Follow this guide to install an Istio
[multicluster deployment](/docs/setup/deployment-models/#multiple-clusters)
with replicated [control plane](/docs/setup/deployment-models/#control-plane-models) instances
[multicluster deployment](/docs/ops/prep/deployment-models/#multiple-clusters)
with replicated [control plane](/docs/ops/prep/deployment-models/#control-plane-models) instances
in every cluster and using gateways to connect services across clusters.
Instead of using a shared Istio control plane to manage the mesh,

View File

@ -10,7 +10,7 @@ aliases:
---
Follow this guide to configure a multicluster mesh using a shared
[control plane](/docs/setup/deployment-models/#control-plane-models)
[control plane](/docs/ops/prep/deployment-models/#control-plane-models)
with gateways to connect network-isolated clusters.
Istio's location-aware service routing feature is used to route requests to different endpoints,
depending on the location of the request source.

View File

@ -9,14 +9,14 @@ aliases:
- /docs/setup/kubernetes/install/multicluster/shared-vpn/
---
Follow this guide to install an Istio [multicluster service mesh](/docs/setup/deployment-models/#multiple-clusters)
Follow this guide to install an Istio [multicluster service mesh](/docs/ops/prep/deployment-models/#multiple-clusters)
where the Kubernetes cluster services and the applications in each cluster
have the capability to expose their internal Kubernetes network to other
clusters.
In this configuration, multiple Kubernetes clusters running
a remote configuration connect to a shared Istio
[control plane](/docs/setup/deployment-models/#control-plane-models).
[control plane](/docs/ops/prep/deployment-models/#control-plane-models).
Once one or more remote Kubernetes clusters are connected to the
Istio control plane, Envoy can then form a mesh network across multiple clusters.

View File

@ -10,7 +10,7 @@ keywords: [kubernetes,multicluster]
This guide describes how to configure an Istio mesh that includes multiple Kubernetes clusters using a simplified experimental approach.
We hope to continue developing this functionality in coming releases, so we'd love your feedback on the overall flow.
We focus here on the details of getting a multicluster mesh wired up, refer to [multicluster deployment model](/docs/setup/deployment-models/#multiple-clusters) for
We focus here on the details of getting a multicluster mesh wired up, refer to [multicluster deployment model](/docs/ops/prep/deployment-models/#multiple-clusters) for
additional background information. We'll show how to connect two clusters that are on the same network together, along
with a third cluster that's on a different network.

View File

@ -19,7 +19,7 @@ instead.
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
1. Check the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/).
1. Check the [Requirements for Pods and Services](/docs/ops/prep/requirements/).
1. Deploy the Istio operator:

View File

@ -206,7 +206,7 @@ to the request by the `productpage` service.
Note that Kubernetes services, like the Bookinfo ones used in this task, must
adhere to certain restrictions to take advantage of Istio's L7 routing features.
Refer to the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/) for details.
Refer to the [Requirements for Pods and Services](/docs/ops/prep/requirements/) for details.
In the [traffic shifting](/docs/tasks/traffic-management/traffic-shifting) task, you
will follow the same basic pattern you learned here to configure route rules to

View File

@ -39,7 +39,7 @@ Weve done work around namespace isolation as well. This lets you use
Kubernetes namespaces to enforce boundaries of control, and ensures that your
teams cannot interfere with each other.
We have also improved the [multicluster capabilities and usability](/docs/setup/deployment-models/).
We have also improved the [multicluster capabilities and usability](/docs/ops/prep/deployment-models/).
We listened to the community and improved defaults for traffic control and
policy. We introduced a new component called
[Galley](/docs/ops/architecture/#galley). Galley validates that sweet,
@ -47,7 +47,7 @@ sweet YAML, reducing the chance of configuration errors. Galley will also be
instrumental in [multicluster setups](/docs/setup/install/multicluster/),
gathering service discovery information from each Kubernetes cluster. We are
also supporting additional multicluster topologies including different
[control plane models](/docs/setup/deployment-models/#control-plane-models)
[control plane models](/docs/ops/prep/deployment-models/#control-plane-models)
topologies without requiring a flat network.
There is lots more -- see the [change notes](./change-notes) for complete

View File

@ -61,7 +61,7 @@ Leverage Istio to integrate with Kubernetes and handle large fleets of Envoys in
- Added a new Grafana dashboard for Citadel
- Improved the Pilot dashboard to expose additional key metrics
- Added the new [Istio Deployment Models concept](/docs/setup/deployment-models/) to help you decide what deployment model suits your needs.
- Added the new [Istio Deployment Models concept](/docs/ops/prep/deployment-models/) to help you decide what deployment model suits your needs.
- Organized the content in of our [Operations Guide](/docs/ops/) and created a [section with all troubleshooting tasks](/docs/ops/common-problems) to help you find the information you seek faster.

View File

@ -12,7 +12,7 @@ aliases:
## Traffic management
- **Added** [automatic protocol determination](/docs/ops/traffic-management/protocol-selection/) of HTTP or TCP for outbound traffic when ports are not named according to Istios [conventions](/docs/setup/additional-setup/requirements/).
- **Added** [automatic protocol determination](/docs/ops/traffic-management/protocol-selection/) of HTTP or TCP for outbound traffic when ports are not named according to Istios [conventions](/docs/ops/prep/requirements/).
- **Added** a mode to the Gateway API for mutual TLS operation.
- **Fixed** issues present when a service communicates over the network first in permissive mutual TLS mode for protocols like MySQL and MongoDB.
- **Improved** Envoy proxy readiness checks. They now check Envoy's readiness status.

View File

@ -18,10 +18,10 @@ wondering if all these things will be just as simple in your real production env
Fortunately, Istio provides several ways to configure a service mesh so that applications
can, more-or-less transparently, be part of a mesh where the services are running
in more than one cluster, i.e., in a
[multicluster deployment](/docs/setup/deployment-models/#multiple-clusters).
[multicluster deployment](/docs/ops/prep/deployment-models/#multiple-clusters).
The simplest way to set up a multicluster mesh, because it has no special networking requirements,
is using a replicated
[control plane model](/docs/setup/deployment-models/#control-plane-models).
[control plane model](/docs/ops/prep/deployment-models/#control-plane-models).
In this configuration, each Kubernetes cluster contributing to the mesh has its own control plane,
but each control plane is synchronized and running under a single administrative control.

View File

@ -8,7 +8,7 @@ aliases:
---
This example shows how to configure a multicluster mesh with a
[single-network deployment](/docs/setup/deployment-models/#single-network)
[single-network deployment](/docs/ops/prep/deployment-models/#single-network)
over 2 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) clusters.
## Before you begin

View File

@ -10,7 +10,7 @@ aliases:
This example demonstrates how to setup network connectivity between two
[IBM Cloud Private](https://www.ibm.com/cloud/private) clusters
and then compose them into a multicluster mesh using a
[single-network deployment](/docs/setup/deployment-models/#single-network).
[single-network deployment](/docs/ops/prep/deployment-models/#single-network).
## Create the IBM Cloud Private Clusters

View File

@ -52,7 +52,7 @@ but similar version routing rules have no effect on your own application, it may
your Kubernetes services need to be changed slightly.
Kubernetes services must adhere to certain restrictions in order to take advantage of
Istio's L7 routing features.
Refer to the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/)
Refer to the [Requirements for Pods and Services]/docs/ops/prep/requirements/)
for details.
Another potential issue is that the route rules may simply be slow to take effect.

View File

@ -39,7 +39,7 @@ before continuing.
The `istioctl describe` command returns a warning if the {{< gloss >}}Envoy{{< /gloss >}}
proxy is not present in a pod or if the proxy has not started. Additionally, the command warns
if some of the [Istio requirements for pods](/docs/setup/additional-setup/requirements/)
if some of the [Istio requirements for pods]/docs/ops/prep/requirements/)
are not met.
For example, the following command produces a warning indicating a `kubernetes-dashboard`

View File

@ -18,7 +18,7 @@ instead, which is a stable feature.
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
1. Check the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/).
1. Check the [Requirements for Pods and Services]/docs/ops/prep/requirements/).
## Installation steps

View File

@ -25,7 +25,7 @@ Istio offers multiple installation flows
depending on your platform and whether or not you intend to use Istio in production.
At a high level, the basic flow is the same regardless of platform:
1. [Review the pod requirements](/docs/setup/additional-setup/requirements/)
1. [Review the pod requirements]/docs/ops/prep/requirements/)
1. [Prepare your platform for Istio](/docs/setup/platform-setup/)
1. [Download the Istio release](#downloading-the-release)
1. [Install Istio on your platform](#installing-istio)

View File

@ -13,4 +13,4 @@ aliases:
请注意,这些说明不是互斥的。 在由两个以上集群组成的大型多集群部署中,可以使用这些方法的组合。 例如,两个集群可能共享一个控制平面,而第三个集群拥有自己的控制平面。
{{< /tip >}}
欲获取更需信息请参考[多集群部署模型](/docs/setup/deployment-models/#multiple-clusters)。
欲获取更需信息请参考[多集群部署模型](/docs/ops/prep/deployment-models/#multiple-clusters)。

View File

@ -10,7 +10,7 @@ aliases:
---
Follow this guide to configure a multicluster mesh using a shared
[control plane](/docs/setup/deployment-models/#control-plane-models)
[control plane](/docs/ops/prep/deployment-models/#control-plane-models)
with gateways to connect network-isolated clusters.
Istio's location-aware service routing feature is used to route requests to different endpoints,
depending on the location of the request source.

View File

@ -9,14 +9,14 @@ aliases:
- /docs/setup/kubernetes/install/multicluster/shared-vpn/
---
Follow this guide to install an Istio [multicluster service mesh](/docs/setup/deployment-models/#multiple-clusters)
Follow this guide to install an Istio [multicluster service mesh](/docs/ops/prep/deployment-models/#multiple-clusters)
where the Kubernetes cluster services and the applications in each cluster
have the capability to expose their internal Kubernetes network to other
clusters.
In this configuration, multiple Kubernetes clusters running
a remote configuration connect to a shared Istio
[control plane](/docs/setup/deployment-models/#control-plane-models).
[control plane](/docs/ops/prep/deployment-models/#control-plane-models).
Once one or more remote Kubernetes clusters are connected to the
Istio control plane, Envoy can then form a mesh network across multiple clusters.

View File

@ -0,0 +1,411 @@
---
title: Installing with Istioctl
description: Install and customize any Istio configuration profile for in-depth evaluation or production use.
weight: 10
keywords: [operator,kubernetes,helm]
---
Follow this guide to install and configure an Istio mesh for in-depth evaluation or production use.
This installation guide uses the [`istioctl`](/docs/reference/commands/istioctl/) command line
tool to provide rich customization of the Istio control plane and of the sidecars for the Istio data plane.
It has user input validation to help prevent installation errors and customization options to
override any aspect of the configuration.
Using these instructions, you can select any one of Istio's built-in
[configuration profiles](/docs/setup/additional-setup/config-profiles/)
and then further customize the configuration for your specific needs.
## Prerequisites
Before you begin, check the following prerequisites:
1. [Download the Istio release](/docs/setup/getting-started/#download).
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
1. Check the [Requirements for Pods and Services]/docs/ops/prep/requirements/).
## Install Istio using the default profile
The simplest option is to install the `default` Istio
[configuration profile](/docs/setup/additional-setup/config-profiles/)
using the following command:
{{< text bash >}}
$ istioctl manifest apply
{{< /text >}}
This command installs the `default` profile on the cluster defined by your
Kubernetes configuration. The `default` profile is a good starting point
for establishing a production environment, unlike the larger `demo` profile that
is intended for evaluating a broad set of Istio features.
## Install a different profile
Other Istio configuration profiles can be installed in a cluster by passing the
profile name on the command line. For example, the following command can be used
to install the `demo` profile:
{{< text bash >}}
$ istioctl manifest apply --set profile=demo
{{< /text >}}
## Display the list of available profiles
You can display the names of Istio configuration profiles that are
accessible to `istioctl` by using this command:
{{< text bash >}}
$ istioctl profile list
minimal
demo
sds
default
{{< /text >}}
## Display the configuration of a profile
You can view the configuration settings of a profile. For example, to view the setting for the `default` profile
run the following command:
{{< text bash >}}
$ istioctl profile dump
autoInjection:
components:
injector:
enabled: true
k8s:
replicaCount: 1
enabled: true
configManagement:
components:
galley:
enabled: true
k8s:
replicaCount: 1
resources:
requests:
cpu: 100m
enabled: true
defaultNamespace: istio-system
gateways:
components:
egressGateway:
enabled: false
k8s:
hpaSpec:
maxReplicas: 5
metrics:
- resource:
name: cpu
targetAverageUtilization: 80
type: Resource
minReplicas: 1
...
{{< /text >}}
To view a subset of the entire configuration, you can use the `--config-path` flag, which selects only the portion
of the configuration under the given path:
{{< text bash >}}
$ istioctl profile dump --config-path trafficManagement.components.pilot
enabled: true
k8s:
env:
- name: POD_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
- name: GODEBUG
value: gctrace=1
- name: PILOT_TRACE_SAMPLING
value: "1"
- name: CONFIG_NAMESPACE
value: istio-config
hpaSpec:
maxReplicas: 5
metrics:
- resource:
name: cpu
targetAverageUtilization: 80
type: Resource
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: istio-pilot
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 30
timeoutSeconds: 5
resources:
requests:
cpu: 500m
memory: 2048Mi
{{< /text >}}
## Show differences in profiles
The `profile diff` sub-command can be used to show the differences between profiles,
which is useful for checking the effects of customizations before applying changes to a cluster.
You can show differences between the default and demo profiles using these commands:
{{< text bash >}}
$ istioctl profile dump default > 1.yaml
$ istioctl profile dump demo > 2.yaml
$ istioctl profile diff 1.yaml 2.yaml
{{< /text >}}
## Generate a manifest before installation
You can generate the manifest before installing Istio using the `manifest generate`
sub-command, instead of `manifest apply`.
For example, use the following command to generate a manifest for the `default` profile:
{{< text bash >}}
$ istioctl manifest generate > $HOME/generated-manifest.yaml
{{< /text >}}
Inspect the manifest as needed, then apply the manifest using this command:
{{< text bash >}}
$ kubectl apply -f $HOME/generated-manifest.yaml
{{< /text >}}
{{< tip >}}
This command might show transient errors due to resources not being available in
the cluster in the correct order.
{{< /tip >}}
## Show differences in manifests
You can show the differences in the generated manifests between the default profile and a customized install using these commands:
{{< text bash >}}
$ istioctl manifest generate > 1.yaml
$ istioctl manifest generate -f samples/pilot-k8s.yaml > 2.yaml
$ istioctl manifest diff 1.yam1 2.yaml
{{< /text >}}
## Verify a successful installation
You can check if the Istio installation succeeded using the `verify-install` command
which compares the installation on your cluster to a manifest you specify.
If you didn't generate your manifest prior to deployment, run the following command to
generate it now:
{{< text bash >}}
$ istioctl manifest generate <your original installation options> > $HOME/generated-manifest.yaml
{{< /text >}}
Then run the following `verify-install` command to see if the installation was successful:
{{< text bash >}}
$ istioctl verify-install -f $HOME/generated-manifest.yaml
{{< /text >}}
## Customizing the configuration
In addition to installing any of Istio's built-in
[configuration profiles](/docs/setup/additional-setup/config-profiles/),
`istioctl manifest` provides a complete API for customizing the configuration.
- [The `IstioControlPlane` API](/docs/reference/config/istio.operator.v1alpha12.pb/)
The configuration parameters in this API can be set individually using `--set` options on the command
line. For example, to disable the telemetry feature in a default configuration profile, use this command:
{{< text bash >}}
$ istioctl manifest apply --set telemetry.enabled=false
{{< /text >}}
Alternatively, a complete configuration can be specified in a YAML file and passed to
`istioctl` using the `-f` option:
{{< text bash >}}
$ istioctl manifest apply -f samples/pilot-k8s.yaml
{{< /text >}}
### Identify an Istio feature or component
The `IstioControlPlane` API groups control plane components by feature, as shown in the table below:
| Feature | Components |
|---------|------------|
`Base` | CRDs
`Traffic Management` | Pilot
`Policy` | Policy
`Telemetry` | Telemetry
`Security` | Citadel
`Security` | Node agent
`Security` | Cert manager
`Configuration management` | Galley
`Gateways` | Ingress gateway
`Gateways` | Egress gateway
`AutoInjection` | Sidecar injector
In addition to the core Istio components, third-party addon features and components are also available:
| Feature | Components |
|---------|------------|
`Telemetry` | Prometheus
`Telemetry` | Prometheus Operator
`Telemetry` | Grafana
`Telemetry` | Kiali
`Telemetry` | Tracing
`ThirdParty` | CNI
Features can be enabled or disabled, which enables or disables all of the components that are a part of the feature.
Namespaces that components are installed into can be set by component, feature, or globally.
### Configure the feature or component settings
After you identify the name of the feature or component from the previous table, you can use the API to set the values
using the `--set` flag, or create an overlay file and use the `--filename` flag. The `--set` flag
works well for customizing a few parameters. Overlay files are designed for more extensive customization, or
tracking configuration changes.
The simplest customization is to turn a feature or component on or off from the configuration profile default.
To disable the telemetry feature in a default configuration profile, use this command:
{{< text bash >}}
$ istioctl manifest apply --set telemetry.enabled=false
{{< /text >}}
Alternatively, you can disable the telemetry feature using a configuration overlay file:
1. Create this file with the name `telemetry_off.yaml` and these contents:
{{< text yaml >}}
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
telemetry:
enabled: false
{{< /text >}}
1. Use the `telemetry_off.yaml` overlay file with the `manifest apply` command:
{{< text bash >}}
$ istioctl manifest apply -f telemetry_off.yaml
{{< /text >}}
You can also use this approach to set the component-level configuration, such as enabling the node agent:
{{< text bash >}}
$ istioctl manifest apply --set security.components.nodeAgent.enabled=true
{{< /text >}}
Another customization is to select different namespaces for features and components. The following is an example
of installation namespace customization:
{{< text yaml >}}
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
defaultNamespace: istio-system
security:
namespace: istio-security
components:
citadel:
namespace: istio-citadel
{{< /text >}}
Applying this file will cause the default profile to be applied, with components being installed into the following
namespaces:
- The Citadel component is installed into `istio-citadel` namespace
- All other components in the security feature installed into `istio-security` namespace
- Remaining Istio components installed into istio-system namespace
### Customize Kubernetes settings
The `IstioControlPlane` API allows each component's Kubernetes settings to be customized in a consistent way.
Each component has a [`KubernetesResourceSpec`](/docs/reference/config/istio.operator.v1alpha12.pb/#KubernetesResourcesSpec),
which allows the following settings to be changed. Use this list to identify the setting to customize:
1. [Resources](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container)
1. [Readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
1. [Replica count](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
1. [`HorizontalPodAutoscaler`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
1. [`PodDisruptionBudget`](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#how-disruption-budgets-work)
1. [Pod annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
1. [Service annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
1. [`ImagePullPolicy`](https://kubernetes.io/docs/concepts/containers/images/)
1. [Priority class name](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass)
1. [Node selector](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector)
1. [Affinity and anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
All of these Kubernetes settings use the Kubernetes API definitions, so [Kubernetes documentation](https://kubernetes.io/docs/concepts/) can be used for reference.
The following example overlay file adjusts the `TrafficManagement` feature's resources and horizontal pod autoscaling
settings for Pilot:
{{< text yaml >}}
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
trafficManagement:
components:
pilot:
k8s:
resources:
requests:
cpu: 1000m # override from default 500m
memory: 4096Mi # ... default 2048Mi
hpaSpec:
maxReplicas: 10 # ... default 5
minReplicas: 2 # ... default 1
{{< /text >}}
Use `manifest apply` to apply the modified settings to the cluster:
{{< text syntax="bash" repo="operator" >}}
$ istioctl manifest apply -f @samples/pilot-k8s.yaml@
{{< /text >}}
### Customize Istio settings using the Helm API
The `IstioControlPlane` API includes a pass-through interface to the [Helm API](/docs/reference/config/installation-options/)
using the `values` field.
The following YAML file configures global and Pilot settings through the Helm API:
{{< text yaml >}}
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
trafficManagement:
components:
pilot:
values:
traceSampling: 0.1 # override from 1.0
# global Helm settings
values:
monitoringPort: 15050
{{< /text >}}
Some parameters will temporarily exist in both the Helm and `IstioControlPlane` APIs, including Kubernetes resources,
namespaces and enablement settings. The Istio community recommends using the `IstioControlPlane` API as it is more
consistent, is validated, and follows the [community graduation process](https://github.com/istio/community/blob/master/FEATURE-LIFECYCLE-CHECKLIST.md#feature-lifecycle-checklist).
## Uninstall Istio
To uninstall Istio, run the following command:
{{< text bash >}}
$ istioctl manifest generate <your original installation options> | kubectl delete -f -
{{< /text >}}

View File

@ -40,7 +40,7 @@ Weve done work around namespace isolation as well. This lets you use
Kubernetes namespaces to enforce boundaries of control, and ensures that your
teams cannot interfere with each other.
We have also improved the [multicluster capabilities and usability](/docs/setup/deployment-models/).
We have also improved the [multicluster capabilities and usability](/docs/ops/prep/deployment-models/).
We listened to the community and improved defaults for traffic control and
policy. We introduced a new component called
[Galley](/docs/ops/architecture/#galley). Galley validates that sweet,
@ -48,7 +48,7 @@ sweet YAML, reducing the chance of configuration errors. Galley will also be
instrumental in [multicluster setups](/docs/setup/install/multicluster/),
gathering service discovery information from each Kubernetes cluster. We are
also supporting additional multicluster topologies including different
[control plane models](/docs/setup/deployment-models/#control-plane-models)
[control plane models](/docs/ops/prep/deployment-models/#control-plane-models)
topologies without requiring a flat network.
There is lots more -- see the [change notes](./change-notes) for complete

View File

@ -62,7 +62,7 @@ Leverage Istio to integrate with Kubernetes and handle large fleets of Envoys in
- Added a new Grafana dashboard for Citadel
- Improved the Pilot dashboard to expose additional key metrics
- Added the new [Istio Deployment Models concept](/docs/setup/deployment-models/) to help you decide what deployment model suits your needs.
- Added the new [Istio Deployment Models concept](/docs/ops/prep/deployment-models/) to help you decide what deployment model suits your needs.
- Organized the content in of our [Operations Guide](/docs/ops/) and created a [section with all troubleshooting tasks](/docs/ops/common-problems) to help you find the information you seek faster.

View File

@ -12,7 +12,7 @@ aliases:
## Traffic management
- **Added** [automatic protocol determination](/docs/ops/traffic-management/protocol-selection/) of HTTP or TCP for outbound traffic when ports are not named according to Istios [conventions](/docs/setup/additional-setup/requirements/).
- **Added** [automatic protocol determination](/docs/ops/traffic-management/protocol-selection/) of HTTP or TCP for outbound traffic when ports are not named according to Istios [conventions]/docs/ops/prep/requirements/).
- **Added** a mode to the Gateway API for mutual TLS operation.
- **Fixed** issues present when a service communicates over the network first in permissive mutual TLS mode for protocols like MySQL and MongoDB.
- **Improved** Envoy proxy readiness checks. They now check Envoy's readiness status.

View File

@ -0,0 +1,26 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 23.1.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
viewBox="0 0 490 490" style="enable-background:new 0 0 490 490;" xml:space="preserve">
<g>
<path d="M158.8,342.1c13.3,12.7,29,19,47.2,19c10.9,0,21.5-3,31.7-9.1l-47.2,116.1c-1.8,4.8-5.3,7.7-10.4,8.6s-9.5-0.5-13.1-4.1
l-33.6-34.5L86.3,440c-5.4,0-9.7-2.1-12.7-6.3c-3-4.2-3.6-8.8-1.8-13.6l41.7-101.6c7.3,6,14.8,10.3,22.7,12.7l8.2,1.8
c4.2,1.2,6.8,2.1,7.7,2.7c0.9,0.6,2.3,1.8,4.1,3.6L158.8,342.1z M309.4,321.2c-6,6-13.3,9.5-21.8,10.4c-8.5,0.9-16.3-0.8-23.6-5
c-5.4-3.6-11.8-5.4-19-5.4s-13.6,1.8-19,5.4c-7.3,4.2-15.1,5.9-23.6,5c-8.5-0.9-15.6-4.4-21.3-10.4c-5.7-6-10.1-9.8-13.1-11.3
c-3-1.5-8.5-3.2-16.3-5l-6.3-1.8c-6-1.8-11.3-5.1-15.9-10c-4.5-4.8-7.7-10.3-9.5-16.3l-1.8-4.5c-2.4-9.7-4.4-15.9-5.9-18.6
s-5.6-7.7-12.2-15l-3.6-3.6c-4.8-4.8-8-10.4-9.5-16.8s-1.7-12.5-0.5-18.6l1.8-5.4c2.4-9.7,3.6-16,3.6-19s-1.2-9.4-3.6-19l-1.8-4.5
c-1.2-6.7-1.1-13.1,0.5-19.5s4.7-11.9,9.5-16.8l3.6-3.6c6.7-6.7,10.7-11.3,12.2-14.1s3.5-8.9,5.9-18.6l1.8-5.4
c1.8-6,5-11.5,9.5-16.3s9.8-8.2,15.9-10l4.5-0.9c9.7-2.4,15.9-4.5,18.6-6.3c2.7-1.8,7.4-6,14.1-12.7l3.6-3.6
c4.8-4.8,10.4-8,16.8-9.5c6.3-1.5,12.5-1.7,18.6-0.5l4.5,1.8c9.7,2.4,16,3.6,19,3.6s9.4-1.2,19-3.6l4.5-1.8
c6-1.2,12.2-1.1,18.6,0.5c6.3,1.5,11.9,4.7,16.8,9.5l3.6,3.6c6.7,6.7,11.3,10.9,14.1,12.7c2.7,1.8,8.9,3.9,18.6,6.3l4.5,0.9
c6,1.8,11.3,5.1,15.9,10s7.7,10.3,9.5,16.3l1.8,5.4c2.4,9.7,4.4,15.9,5.9,18.6c1.5,2.7,5.6,7.4,12.2,14.1l3.6,3.6
c4.8,4.8,8,10.4,9.5,16.8c1.5,6.3,1.7,12.8,0.5,19.5l-1.8,4.5c-2.4,9.7-3.6,16-3.6,19s1.2,9.4,3.6,19l1.8,5.4
c1.2,6,1.1,12.2-0.5,18.6c-1.5,6.3-4.7,11.9-9.5,16.8l-3.6,3.6c-6.7,7.3-10.7,12.2-12.2,15c-1.5,2.7-3.5,8.9-5.9,18.6l-1.8,4.5
c-1.8,6-5,11.5-9.5,16.3c-4.5,4.8-9.8,8.2-15.9,10l-7.3,1.8c-7.3,1.8-12.4,3.5-15.4,5C319.1,311.4,314.8,315.2,309.4,321.2z
M159.8,172.5c0,24.2,8.3,44.7,24.9,61.7s36.7,25.4,60.3,25.4s43.7-8.5,60.3-25.4c16.6-16.9,24.9-37.5,24.9-61.7
s-8.3-44.7-24.9-61.7c-16.6-16.9-36.7-25.4-60.3-25.4s-43.7,8.5-60.3,25.4S159.8,148.3,159.8,172.5z M418.2,420.1
c1.8,4.8,1.2,9.4-1.8,13.6c-3,4.2-7.3,6.3-12.7,6.3l-47.2-1.8L323,472.7c-3.6,3.6-8,5-13.1,4.1s-8.6-3.8-10.4-8.6l-47.2-116.1
c10.3,6,20.9,9.1,31.7,9.1c18.1,0,33.9-6.3,47.2-19l2.7-2.7c1.8-1.8,3.2-3,4.1-3.6c0.9-0.6,3.5-1.5,7.7-2.7l8.2-1.8
c7.9-2.4,15.4-6.7,22.7-12.7L418.2,420.1z"/>
</g>
</svg>

After

Width:  |  Height:  |  Size: 2.5 KiB