mirror of https://github.com/istio/istio.io.git
Remove Helm install instructions (#7083)
This commit is contained in:
Eric Van Norman
GitHub
parent
82d4851806
commit
83de8ae304
|
|
@ -91,7 +91,6 @@ Below is our list of existing features and their current phases. This informatio
|
|||
| [Kubernetes: Istio Control Plane Installation](/docs/setup/) | Stable
|
||||
| [Attribute Expression Language](/docs/reference/config/policy-and-telemetry/expression-language/) | Stable
|
||||
| Mixer Out-of-Process Adapter Authoring Model | Beta
|
||||
| [Helm](/docs/setup/install/helm/) | Beta
|
||||
| [Multicluster Mesh over VPN](/docs/setup/install/multicluster/) | Alpha
|
||||
| [Kubernetes: Istio Control Plane Upgrade](/docs/setup/) | Beta
|
||||
| Consul Integration | Alpha
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Fortunately, a standard Istio deployment already includes a [Gateway](/docs/conc
|
|||
|
||||
## In action: traffic routing with Istio
|
||||
|
||||
A simple way to see this type of approach in action is to first setup your Kubernetes environment using the [Platform Setup](/docs/setup/platform-setup/) instructions, and then install the **minimal** Istio profile using [Helm](/docs/setup/install/helm/), including only the traffic management components (ingress gateway, egress gateway, Pilot). The following example uses [Google Kubernetes Engine](https://cloud.google.com/gke).
|
||||
A simple way to see this type of approach in action is to first setup your Kubernetes environment using the [Platform Setup](/docs/setup/platform-setup/) instructions, and then install the **minimal** Istio profile using [Helm](https://archive.istio.io/1.4/docs/setup/install/helm/), including only the traffic management components (ingress gateway, egress gateway, Pilot). The following example uses [Google Kubernetes Engine](https://cloud.google.com/gke).
|
||||
|
||||
First, setup and configure [GKE](/docs/setup/platform-setup/gke/):
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ $ kubectl create clusterrolebinding cluster-admin-binding \
|
|||
--user=$(gcloud config get-value core/account)
|
||||
{{< /text >}}
|
||||
|
||||
Next, [install Helm](https://helm.sh/docs/intro/install/) and [generate a minimal Istio install](/docs/setup/install/helm/) -- only traffic management components:
|
||||
Next, [install Helm](https://helm.sh/docs/intro/install/) and [generate a minimal Istio install](https://archive.istio.io/1.4/docs/setup/install/helm/) -- only traffic management components:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio \
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ following:
|
|||
- Small customizations not in the API don't require chart or API changes
|
||||
- Version specific upgrade hooks can be easily and robustly implemented
|
||||
|
||||
The [Helm installation](/docs/setup/install/helm/) method is in the process of deprecation. Upgrading from Istio
|
||||
The [Helm installation](https://archive.istio.io/1.4/docs/setup/install/helm/) method is in the process of deprecation. Upgrading from Istio
|
||||
1.4 with a version not initially installed with Helm will also be replaced by a new
|
||||
[{{< istioctl >}} upgrade feature](https://archive.istio.io/v1.4/docs/setup/upgrade/istioctl-upgrade/).
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ In the [Istio Tools repository](https://github.com/istio/tools/tree/3ac7ab40db8a
|
|||
|
||||
To accurately measure the performance of a service mesh at scale, it's important to use an [adequately-sized](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install#istio-setup) Kubernetes cluster. We test using three worker nodes, each with at least 4 vCPUs and 15 GB of memory.
|
||||
|
||||
Then, it's important to use a production-ready Istio **installation profile** on that cluster. This lets us achieve performance-oriented settings such as control plane pod autoscaling, and ensures that resource limits are appropriate for heavy traffic load. The [default](/docs/setup/install/helm/#installation-steps) Istio installation is suitable for most benchmarking use cases. For extensive performance benchmarking, with thousands of proxy-injected services, we also provide [a tuned Istio install](https://github.com/istio/tools/blob/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install/values.yaml) that allocates extra memory and CPU to the Istio control plane.
|
||||
Then, it's important to use a production-ready Istio **installation profile** on that cluster. This lets us achieve performance-oriented settings such as control plane pod autoscaling, and ensures that resource limits are appropriate for heavy traffic load. The [default](https://archive.istio.io/1.4/docs/setup/install/helm/#installation-steps) Istio installation is suitable for most benchmarking use cases. For extensive performance benchmarking, with thousands of proxy-injected services, we also provide [a tuned Istio install](https://github.com/istio/tools/blob/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install/values.yaml) that allocates extra memory and CPU to the Istio control plane.
|
||||
|
||||
{{< warning_icon >}} Istio's [demo installation](/docs/setup/getting-started/) is not suitable for performance testing, because it is designed to be deployed on a small trial cluster, and has full tracing and access logs enabled to showcase Istio's features.
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ Why test with only two pods? Because scaling up throughput (RPS) and connections
|
|||
|
||||
## 3. Measure with and without proxies
|
||||
|
||||
While many Istio features, such as [mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication), rely on an Envoy proxy next to an application pod, you can [selectively disable](/docs/setup/additional-setup/sidecar-injection/#disabling-or-updating-the-webhook) sidecar proxy injection for some of your mesh services. As you scale up Istio for production, you may want to incrementally add the sidecar proxy to your workloads.
|
||||
While many Istio features, such as [mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication), rely on an Envoy proxy next to an application pod, you can [selectively disable](https://archive.istio.io/1.4/docs/setup/additional-setup/sidecar-injection/#disabling-or-updating-the-webhook) sidecar proxy injection for some of your mesh services. As you scale up Istio for production, you may want to incrementally add the sidecar proxy to your workloads.
|
||||
|
||||
To that end, the test scripts provide [three different modes](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#run-performance-tests). These modes analyze Istio's performance when a request goes through both the client and server proxies (`both`), just the server proxy (`serveronly`), and neither proxy (`baseline`).
|
||||
|
||||
|
|
|
|||
|
|
@ -71,13 +71,6 @@ When you set the `istio-injection=enabled` label on a namespace and the injectio
|
|||
|
||||
Note that unlike manual injection, automatic injection occurs at the pod-level. You won't see any change to the deployment itself. Instead you'll want to check individual pods (via `kubectl describe`) to see the injected proxy.
|
||||
|
||||
#### Disabling or updating the webhook
|
||||
|
||||
The sidecar injecting webhook is enabled by default. If you wish to disable the webhook, you can
|
||||
use [Helm](/docs/setup/install/helm/) to set option `sidecarInjectorWebhook.enabled` to `false`.
|
||||
|
||||
There are also a [variety of other options](/docs/reference/config/installation-options/#sidecarinjectorwebhook-options) that can be configured.
|
||||
|
||||
#### Deploying an app
|
||||
|
||||
Deploy sleep app. Verify both deployment and pod have a single container.
|
||||
|
|
|
|||
|
|
@ -1,245 +0,0 @@
|
|||
---
|
||||
title: Customizable Install with Helm
|
||||
description: Install and configure Istio for in-depth evaluation or production use.
|
||||
weight: 20
|
||||
keywords: [kubernetes,helm]
|
||||
aliases:
|
||||
- /docs/setup/kubernetes/helm.html
|
||||
- /docs/tasks/integrating-services-into-istio.html
|
||||
- /docs/setup/kubernetes/helm-install/
|
||||
- /docs/setup/kubernetes/install/helm/
|
||||
icon: helm
|
||||
---
|
||||
|
||||
{{< warning >}}
|
||||
The Helm installation approach will be deprecated in the future.
|
||||
We recommend [Installing with {{< istioctl >}}](/docs/setup/install/istioctl/), instead.
|
||||
{{< /warning >}}
|
||||
|
||||
Follow this guide to install and configure an Istio mesh for in-depth evaluation or production use.
|
||||
|
||||
This installation guide uses [Helm](https://github.com/helm/helm) charts that provide rich
|
||||
customization of the Istio control plane and of the sidecars for the Istio data plane.
|
||||
You can simply use `helm template` to generate the configuration and then install it
|
||||
using `kubectl apply`.
|
||||
|
||||
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
|
||||
|
||||
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/deployment/requirements/).
|
||||
|
||||
1. [Install a Helm client](https://github.com/helm/helm#install) with a version higher than 2.10.
|
||||
|
||||
{{< warning >}}
|
||||
Use a 2.x version of Helm. Helm 3 is not supported.
|
||||
{{< /warning >}}
|
||||
|
||||
## Helm chart release repositories
|
||||
|
||||
The commands in this guide use the Helm charts that are included in the Istio release image.
|
||||
If you want to use the Istio release Helm chart repository instead, adjust the commands accordingly and
|
||||
add the Istio release repository as follows:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm repo add istio.io https://storage.googleapis.com/istio-release/releases/{{< istio_full_version >}}/charts/
|
||||
{{< /text >}}
|
||||
|
||||
## Installation steps
|
||||
|
||||
Change directory to the root of the release and then
|
||||
follow the instructions below.
|
||||
|
||||
{{< tip >}}
|
||||
Istio, by default, uses `LoadBalancer` service object types. Some platforms do not support `LoadBalancer`
|
||||
service objects. For platforms lacking `LoadBalancer` support, install Istio with `NodePort` support
|
||||
instead with the flags `--set gateways.istio-ingressgateway.type=NodePort`
|
||||
appended to the end of the Helm instructions in the installation steps below.
|
||||
{{< /tip >}}
|
||||
|
||||
Previously, this document described a Helm installation method that utilized the [Tiller](https://helm.sh/docs/topics/architecture/#components) component. [That installation method](https://archive.istio.io/v1.4/docs/setup/install/helm/#option-2-install-with-helm-and-tiller-via-helm-install) is no longer recommended. Instead, we recommend using `istioctl` as documented in [Installing with {{< istioctl >}}](/docs/setup/install/istioctl/). If you want to use Helm, then you need to use the `helm template` method described below.
|
||||
|
||||
1. Create a namespace for the `istio-system` components:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create namespace istio-system
|
||||
{{< /text >}}
|
||||
|
||||
1. Install all the Istio
|
||||
[Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions)
|
||||
(CRDs) using `kubectl apply`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
1. {{< boilerplate verify-crds >}}
|
||||
|
||||
1. Select a [configuration profile](/docs/setup/additional-setup/config-profiles/)
|
||||
and then render and apply Istio's core components corresponding to your chosen profile.
|
||||
The **default** profile is recommended for production deployments:
|
||||
|
||||
{{< tip >}}
|
||||
You can further customize the configuration by adding one or more `--set <key>=<value>`
|
||||
[Installation Options](/docs/reference/config/installation-options/) to the helm command.
|
||||
{{< /tip >}}
|
||||
|
||||
{{< tabset category-name="helm_profile" >}}
|
||||
|
||||
{{< tab name="default" category-value="default" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="demo" category-value="demo" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
|
||||
--values install/kubernetes/helm/istio/values-istio-demo.yaml | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="minimal" category-value="minimal" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
|
||||
--values install/kubernetes/helm/istio/values-istio-minimal.yaml | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="Mutual TLS enabled" category-value="mtls" >}}
|
||||
|
||||
Enable mutual TLS in Istio by setting options `global.controlPlaneSecurityEnabled=true`
|
||||
and `global.mtls.enabled=true`, in addition to the specifying the Helm values file
|
||||
corresponding to your chosen profile.
|
||||
|
||||
For example, to configure the `demo` profile with mutual TLS enabled:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
|
||||
--values install/kubernetes/helm/istio/values-istio-demo.yaml \
|
||||
--set global.controlPlaneSecurityEnabled=true \
|
||||
--set global.mtls.enabled=true | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="Istio CNI enabled" category-value="cni" >}}
|
||||
|
||||
Install the [Istio CNI](/docs/setup/additional-setup/cni/) components:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=kube-system | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
Enable CNI in Istio by setting `--set istio_cni.enabled=true` in addition to the settings for your chosen profile.
|
||||
For example, to configure the **default** profile:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
|
||||
--set istio_cni.enabled=true | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
## Verifying the installation
|
||||
|
||||
1. Referring to components table in
|
||||
[configuration profiles](/docs/setup/additional-setup/config-profiles/),
|
||||
verify that the Kubernetes services corresponding to your selected profile have been deployed.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get svc -n istio-system
|
||||
{{< /text >}}
|
||||
|
||||
1. Ensure the corresponding Kubernetes pods are deployed and have a `STATUS` of `Running`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pods -n istio-system
|
||||
{{< /text >}}
|
||||
|
||||
## Uninstall
|
||||
|
||||
- You can use the `helm template` command to uninstall Istio. Uninstall with these commands:
|
||||
|
||||
{{< tabset category-name="helm_profile" >}}
|
||||
|
||||
{{< tab name="default" category-value="default" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f -
|
||||
$ kubectl delete namespace istio-system
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="demo" category-value="demo" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
|
||||
--values install/kubernetes/helm/istio/values-istio-demo.yaml | kubectl delete -f -
|
||||
$ kubectl delete namespace istio-system
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="minimal" category-value="minimal" >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \
|
||||
--values install/kubernetes/helm/istio/values-istio-minimal.yaml | kubectl delete -f -
|
||||
$ kubectl delete namespace istio-system
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="Mutual TLS enabled" category-value="mtls" >}}
|
||||
|
||||
Follow the instructions corresponding to your selected configuration profile.
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="Istio CNI enabled" category-value="cni" >}}
|
||||
|
||||
Follow the instructions corresponding to your selected configuration profile
|
||||
and then execute the following command to uninstall the CNI plug-in:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=kube-system | kubectl delete -f -
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
## Deleting CRDs and Istio Configuration
|
||||
|
||||
Istio, by design, expects Istio's Custom Resources contained within CRDs to leak into the
|
||||
Kubernetes environment. CRDs contain the runtime configuration set by the operator.
|
||||
Because of this, we consider it better for operators to explicitly delete the runtime
|
||||
configuration data rather than unexpectedly lose it.
|
||||
|
||||
{{< warning >}}
|
||||
Deleting CRDs permanently deletes any configuration changes that you have made to Istio.
|
||||
{{< /warning >}}
|
||||
|
||||
The `istio-init` chart contains all raw CRDs in the `istio-init/files` directory.
|
||||
You can simply delete the CRDs using `kubectl`.
|
||||
To permanently delete Istio's CRDs and the entire Istio configuration, run:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete -f install/kubernetes/helm/istio-init/files
|
||||
{{< /text >}}
|
||||
|
|
@ -51,7 +51,7 @@ $ istioctl manifest apply --set addonComponents.grafana.enabled=true
|
|||
{{< /text >}}
|
||||
|
||||
In general, you can use the `--set` flag in `istioctl` as you would with
|
||||
[Helm](/docs/setup/install/helm/). The only difference is you must
|
||||
Helm. The only difference is you must
|
||||
prefix the setting paths with `values.` because this is the path to the Helm pass-through API in the
|
||||
[`IstioOperator` API](/docs/reference/config/istio.operator.v1alpha1/).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,121 +0,0 @@
|
|||
---
|
||||
title: Upgrade using Helm
|
||||
description: Upgrade the Istio control plane, and optionally, the CNI plug-in using Helm.
|
||||
weight: 30
|
||||
aliases:
|
||||
- /docs/setup/kubernetes/upgrade/steps/
|
||||
- /docs/setup/upgrade/steps
|
||||
keywords: [kubernetes,upgrading]
|
||||
---
|
||||
|
||||
Follow this guide to upgrade the Istio control plane and sidecar proxies of an
|
||||
existing Istio deployment that was previously installed using Helm. The upgrade
|
||||
process may install new binaries and may change configuration and API schemas.
|
||||
The upgrade process may result in service downtime. To minimize downtime,
|
||||
please ensure your Istio control plane components and your applications are
|
||||
highly available with multiple replicas.
|
||||
|
||||
{{< warning >}}
|
||||
Be sure to check out the upgrade notes
|
||||
for a concise list of things you should know before upgrading your deployment to Istio {{< istio_version >}}.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< tip >}}
|
||||
Istio does **NOT** support skip level upgrades. Only upgrades from {{< istio_previous_version >}} to {{< istio_version >}}
|
||||
are supported. If you are on an older version, please upgrade to {{< istio_previous_version >}} first.
|
||||
{{< /tip >}}
|
||||
|
||||
## Upgrade steps
|
||||
|
||||
[Download the new Istio release](/docs/setup/getting-started/#download)
|
||||
and change directory to the new release directory.
|
||||
|
||||
### Istio CNI upgrade
|
||||
|
||||
If you have installed or are planning to install [Istio CNI](/docs/setup/additional-setup/cni/),
|
||||
you can check whether Istio CNI is already installed and to upgrade it. You can use Kubernetes’ rolling update mechanism to upgrade the Istio CNI components. This is suitable for cases where `kubectl apply` was used to deploy Istio CNI.
|
||||
|
||||
1. To check whether `istio-cni` is installed, search for `istio-cni-node` pods
|
||||
and in which namespace they are running (typically, `kube-system` or `istio-system`):
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pods -l k8s-app=istio-cni-node --all-namespaces
|
||||
$ NAMESPACE=$(kubectl get pods -l k8s-app=istio-cni-node --all-namespaces --output='jsonpath={.items[0].metadata.namespace}')
|
||||
{{< /text >}}
|
||||
|
||||
1. If `istio-cni` is currently installed in a namespace other than `kube-system`
|
||||
(for example, `istio-system`), delete `istio-cni`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=$NAMESPACE | kubectl delete -f -
|
||||
{{< /text >}}
|
||||
|
||||
1. Install or upgrade `istio-cni` in the `kube-system` namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=kube-system | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
### Control plane upgrade
|
||||
|
||||
You can use Kubernetes’ rolling update mechanism to upgrade the control plane components.
|
||||
This is suitable for cases where `kubectl apply` was used to deploy the Istio components,
|
||||
including configurations generated using
|
||||
[helm template](/docs/setup/install/helm/#installation-steps).
|
||||
|
||||
1. Use `kubectl apply` to upgrade all of Istio's CRDs. Wait a few seconds for the Kubernetes
|
||||
API server to commit the upgraded CRDs:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f install/kubernetes/helm/istio-init/files/
|
||||
{{< /text >}}
|
||||
|
||||
1. {{< boilerplate verify-crds >}}
|
||||
|
||||
1. Apply the update templates:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio --name istio \
|
||||
--namespace istio-system | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
You must pass the same settings as when you first [installed Istio](/docs/setup/install/helm).
|
||||
|
||||
The rolling update process will upgrade all deployments and configmaps to the new version.
|
||||
After this process finishes, your Istio control plane should be updated to the new version.
|
||||
Your existing application should continue to work without any change. If there is any
|
||||
critical issue with the new control plane, you can rollback the changes by applying the
|
||||
yaml files from the old version.
|
||||
|
||||
### Sidecar upgrade
|
||||
|
||||
After the control plane upgrade, the applications already running Istio will
|
||||
still be using an older sidecar. To upgrade the sidecar, you will need to re-inject it.
|
||||
|
||||
If you're using automatic sidecar injection, you can upgrade the sidecar
|
||||
by doing a rolling update for all the pods, so that the new version of the
|
||||
sidecar will be automatically re-injected.
|
||||
|
||||
{{< warning >}}
|
||||
Your `kubectl` version must be >= 1.15 to run the following command. Upgrade if necessary.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl rollout restart deployment --namespace default
|
||||
{{< /text >}}
|
||||
|
||||
If you're using manual injection, you can upgrade the sidecar by executing:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject -f $ORIGINAL_DEPLOYMENT_YAML)
|
||||
{{< /text >}}
|
||||
|
||||
If the sidecar was previously injected with some customized inject configuration
|
||||
files, you will need to change the version tag in the configuration files to the new
|
||||
version and re-inject the sidecar as follows:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject \
|
||||
--injectConfigFile inject-config.yaml \
|
||||
--filename $ORIGINAL_DEPLOYMENT_YAML)
|
||||
{{< /text >}}
|
||||
|
|
@ -3,4 +3,4 @@ title: What is the minimal Istio configuration required for distributed tracing?
|
|||
weight: 13
|
||||
---
|
||||
|
||||
The [Istio minimal profile](/docs/setup/install/helm/) with tracing enabled is all that is required for Istio to integrate with Zipkin-compatible backends.
|
||||
The [Istio minimal profile](https://archive.istio.io/1.4/docs/setup/install/helm/) with tracing enabled is all that is required for Istio to integrate with Zipkin-compatible backends.
|
||||
|
|
@ -24,5 +24,5 @@ change in 0.8 and beyond.
|
|||
|
||||
Known Issues:
|
||||
|
||||
Our [Helm chart](/docs/setup/install/helm)
|
||||
Our [Helm chart](https://archive.istio.io/0.7/docs/setup/install/helm)
|
||||
currently requires some workaround to apply the chart correctly, see [4701](https://github.com/istio/istio/issues/4701) for details.
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Here are some highlights:
|
|||
- [Authorization policies](/docs/concepts/security/#authorization) which control access to services are now entirely evaluated locally in Envoy increasing
|
||||
their performance and reliability.
|
||||
|
||||
- [Helm chart installation](/docs/setup/install/helm/) is now the recommended install method offering rich customization options to adopt Istio on your terms.
|
||||
- [Helm chart installation](https://archive.istio.io/1.0/docs/setup/install/helm/) is now the recommended install method offering rich customization options to adopt Istio on your terms.
|
||||
|
||||
- We’ve put a lot of effort into performance including continuous regression testing, large scale environment simulation and targeted fixes. We’re very happy with the results and will share more on this in detail in the coming weeks.
|
||||
|
||||
|
|
@ -141,7 +141,7 @@ be configured using [authentication policies](/docs/concepts/security/#authentic
|
|||
|
||||
- Amazon's EKS service does not implement automatic sidecar injection. Istio can be used in Amazon's
|
||||
EKS by using [manual injection](/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection) for
|
||||
sidecars and turning off galley using the [Helm parameter](/docs/setup/install/helm)
|
||||
sidecars and turning off galley using the [Helm parameter](https://archive.istio.io/1.0/docs/setup/install/helm)
|
||||
`--set galley.enabled=false`.
|
||||
|
||||
- In a [multicluster deployment](/docs/setup/install/multicluster) the mixer-telemetry
|
||||
|
|
|
|||
|
|
@ -108,5 +108,5 @@ Istio 1.5.0 multicluster setup has several known issues ([27102](https://github.
|
|||
|
||||
## Helm upgrade
|
||||
|
||||
If you used `helm upgrade` to update your cluster to newer Istio versions, we recommend you to switch to use [`istioctl upgrade`](https://archive.istio.io/v1.5/docs/setup/upgrade/istioctl-upgrade/) or follow the [helm template](/docs/setup/upgrade/cni-helm-upgrade/) steps.
|
||||
If you used `helm upgrade` to update your cluster to newer Istio versions, we recommend you to switch to use [`istioctl upgrade`](https://archive.istio.io/v1.5/docs/setup/upgrade/istioctl-upgrade/) or follow the [helm template](https://archive.istio.io/1.4/docs/setup/upgrade/cni-helm-upgrade/) steps.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,8 +23,8 @@ Both Istio gateways and sidecars are vulnerable to this issue. If you are runnin
|
|||
|
||||
## Mitigation
|
||||
|
||||
* For Istio 1.1.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade) to [Istio 1.1.16](/news/releases/1.1.x/announcing-1.1.16) or later.
|
||||
* For Istio 1.2.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade) to [Istio 1.2.7](/news/releases/1.2.x/announcing-1.2.7) or later.
|
||||
* For Istio 1.3.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade) to [Istio 1.3.2](/news/releases/1.3.x/announcing-1.3.2) or later.
|
||||
* For Istio 1.1.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](https://archive.istio.io/1.1/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade) to [Istio 1.1.16](/news/releases/1.1.x/announcing-1.1.16) or later.
|
||||
* For Istio 1.2.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](https://archive.istio.io/1.2/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade) to [Istio 1.2.7](/news/releases/1.2.x/announcing-1.2.7) or later.
|
||||
* For Istio 1.3.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](https://archive.istio.io/1.3/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade) to [Istio 1.3.2](/news/releases/1.3.x/announcing-1.3.2) or later.
|
||||
|
||||
{{< boilerplate "security-vulnerability" >}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue