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>
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -29,7 +29,7 @@ If the Istio Dashboard or the Prometheus queries don’t 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 lifecycle’s 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 lifecycle’s 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:
|
||||
|
|
|
@ -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`
|
||||
|
|
|
@ -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
|
||||
---
|
Before Width: | Height: | Size: 8.9 KiB After Width: | Height: | Size: 8.9 KiB |
Before Width: | Height: | Size: 9.1 KiB After Width: | Height: | Size: 9.1 KiB |
Before Width: | Height: | Size: 8.7 KiB After Width: | Height: | Size: 8.7 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
@ -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
|
Before Width: | Height: | Size: 7.9 KiB After Width: | Height: | Size: 7.9 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 9.7 KiB After Width: | Height: | Size: 9.7 KiB |
Before Width: | Height: | Size: 5.8 KiB After Width: | Height: | Size: 5.8 KiB |
Before Width: | Height: | Size: 8.1 KiB After Width: | Height: | Size: 8.1 KiB |
Before Width: | Height: | Size: 8.0 KiB After Width: | Height: | Size: 8.0 KiB |
|
@ -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.
|
|
@ -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).
|
|
@ -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.
|
|
@ -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).
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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/).
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -39,7 +39,7 @@ We’ve 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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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 Istio’s [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 Istio’s [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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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`
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -13,4 +13,4 @@ aliases:
|
|||
请注意,这些说明不是互斥的。 在由两个以上集群组成的大型多集群部署中,可以使用这些方法的组合。 例如,两个集群可能共享一个控制平面,而第三个集群拥有自己的控制平面。
|
||||
{{< /tip >}}
|
||||
|
||||
欲获取更需信息请参考[多集群部署模型](/docs/setup/deployment-models/#multiple-clusters)。
|
||||
欲获取更需信息请参考[多集群部署模型](/docs/ops/prep/deployment-models/#multiple-clusters)。
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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 >}}
|
|
@ -40,7 +40,7 @@ We’ve 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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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 Istio’s [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 Istio’s [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.
|
||||
|
|
|
@ -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 |