mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-28 05:59:03 +00:00
Add version-2.7 docs
This commit is contained in:
Billy Tat
+60
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Additional Steps for Installing Istio on RKE2 and K3s Clusters
|
||||
---
|
||||
|
||||
When installing or upgrading the Istio Helm chart through **Apps,**
|
||||
|
||||
1. If you are installing the chart, click **Customize Helm options before install** and click **Next**.
|
||||
1. You will see options for configuring the Istio Helm chart. On the **Components** tab, check the box next to **Enabled CNI**.
|
||||
1. Add a custom overlay file specifying `cniBinDir` and `cniConfDir`. For more information on these options, refer to the [Istio documentation.](https://istio.io/latest/docs/setup/additional-setup/cni/#helm-chart-parameters) An example is below:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
```yaml
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
k8s:
|
||||
overlays:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "DaemonSet"
|
||||
name: "istio-cni-node"
|
||||
patches:
|
||||
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
|
||||
value: true
|
||||
values:
|
||||
cni:
|
||||
cniBinDir: /opt/cni/bin
|
||||
cniConfDir: /etc/cni/net.d
|
||||
```
|
||||
</TabItem>
|
||||
<TabItem value="K3s">
|
||||
|
||||
```yaml
|
||||
apiVersion: install.istio.io/v1alpha1
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
k8s:
|
||||
overlays:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "DaemonSet"
|
||||
name: "istio-cni-node"
|
||||
patches:
|
||||
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
|
||||
value: true
|
||||
values:
|
||||
cni:
|
||||
cniBinDir: /var/lib/rancher/k3s/data/current/bin
|
||||
cniConfDir: /var/lib/rancher/k3s/agent/etc/cni/net.d
|
||||
```
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** Now you should be able to utilize Istio as desired, including sidecar injection and monitoring via Kiali.
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: Enable Istio with Pod Security Policies
|
||||
---
|
||||
|
||||
If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin.
|
||||
|
||||
The Istio CNI plugin removes the need for each application pod to have a privileged `NET_ADMIN` container. For further information, see the [Istio CNI Plugin docs](https://istio.io/docs/setup/additional-setup/cni). Please note that the [Istio CNI Plugin is in alpha](https://istio.io/about/feature-stages/).
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
- The cluster must be an RKE Kubernetes cluster.
|
||||
- The cluster must have been created with a default PodSecurityPolicy.
|
||||
|
||||
To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.
|
||||
|
||||
:::
|
||||
|
||||
1. [Set the PodSecurityPolicy to unrestricted](#1-set-the-podsecuritypolicy-to-unrestricted)
|
||||
2. [Enable the CNI](#2-enable-the-cni)
|
||||
3. [Verify that the CNI is working.](#3-verify-that-the-cni-is-working)
|
||||
|
||||
### 1. Set the PodSecurityPolicy to unrestricted
|
||||
|
||||
An unrestricted PSP allows Istio to be installed.
|
||||
|
||||
Set the PSP to `unrestricted` in the project where is Istio is installed, or the project where you plan to install Istio.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
1. Click **Cluster > Projects/Namespaces**.
|
||||
1. Find the **Project: System** and select the **⋮ > Edit Config**.
|
||||
1. Change the Pod Security Policy option to be unrestricted, then click **Save**.
|
||||
|
||||
### 2. Enable the CNI
|
||||
|
||||
When installing or upgrading Istio through **Apps,**
|
||||
|
||||
1. Click **Components**.
|
||||
2. Check the box next to **Enabled CNI**.
|
||||
3. Finish installing or upgrading Istio.
|
||||
|
||||
The CNI can also be enabled by editing the `values.yaml`:
|
||||
|
||||
```
|
||||
istio_cni.enabled: true
|
||||
```
|
||||
|
||||
Istio should install successfully with the CNI enabled in the cluster.
|
||||
|
||||
### 3. Verify that the CNI is working
|
||||
|
||||
Verify that the CNI is working by deploying a [sample application](https://istio.io/latest/docs/examples/bookinfo/) or deploying one of your own applications.
|
||||
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Additional Steps for Project Network Isolation
|
||||
---
|
||||
|
||||
In clusters where:
|
||||
|
||||
- You are using the Canal network plugin with Rancher before v2.5.8, or you are using Rancher v2.5.8+ with an any RKE network plug-in that supports the enforcement of Kubernetes network policies, such as Canal or the Cisco ACI plugin
|
||||
- The Project Network Isolation option is enabled
|
||||
- You install the Istio Ingress module
|
||||
|
||||
The Istio Ingress Gateway pod won't be able to redirect ingress traffic to the workloads by default. This is because all the namespaces will be inaccessible from the namespace where Istio is installed. You have two options.
|
||||
|
||||
The first option is to add a new Network Policy in each of the namespaces where you intend to have ingress controlled by Istio. Your policy should include the following lines:
|
||||
|
||||
```
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
app: istio-ingressgateway
|
||||
```
|
||||
|
||||
The second option is to move the `istio-system` namespace to the `system` project, which by default is excluded from the network isolation.
|
||||
+120
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: Selectors and Scrape Configs
|
||||
---
|
||||
|
||||
The Monitoring app sets `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`, which enables monitoring across all namespaces by default.
|
||||
|
||||
This ensures you can view traffic, metrics and graphs for resources deployed in a namespace with `istio-injection=enabled` label.
|
||||
|
||||
If you would like to limit Prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources.
|
||||
|
||||
|
||||
### Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True
|
||||
|
||||
To limit monitoring to specific namespaces, you will edit the `ignoreNamespaceSelectors` Helm chart option. You will configure this option when installing or upgrading the Monitoring Helm chart:
|
||||
|
||||
1. When installing or upgrading the Monitoring Helm chart, edit the values.yml and set`prometheus.prometheusSpec.ignoreNamespaceSelectors=true`.
|
||||
1. Complete the install or upgrade.
|
||||
|
||||
**Result:** Prometheus will be limited to specific namespaces which means one of the following configurations will need to be set up to continue to view data in various dashboards
|
||||
|
||||
### Enabling Prometheus to Detect Resources in Other Namespaces
|
||||
|
||||
There are two different ways to enable Prometheus to detect resources in other namespaces when `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`:
|
||||
|
||||
- **Monitoring specific namespaces:** Add a Service Monitor or Pod Monitor in the namespace with the targets you want to scrape.
|
||||
- **Monitoring across namespaces:** Add an `additionalScrapeConfig` to your rancher-monitoring instance to scrape all targets in all namespaces.
|
||||
|
||||
### Monitoring Specific Namespaces: Create a Service Monitor or Pod Monitor
|
||||
|
||||
This option allows you to define which specific services or pods you would like monitored in a specific namespace.
|
||||
|
||||
The usability tradeoff is that you have to create the service monitor or pod monitor per namespace since you cannot monitor across namespaces.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example ServiceMonitor is provided below.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
1. In the top navigation bar, open the kubectl shell.
|
||||
1. If the ServiceMonitor or PodMonitor file is stored locally in your cluster, in `kubectl create -f <name of service/pod monitor file>.yaml`.
|
||||
1. If the ServiceMonitor or PodMonitor is not stored locally, run `cat<< EOF | kubectl apply -f -`, paste the file contents into the terminal, then run `EOF` to complete the command.
|
||||
1. Run `kubectl label namespace <your namespace> istio-injection=enabled` to enable the envoy sidecar injection.
|
||||
|
||||
**Result:** `<your namespace>` can be scraped by prometheus.
|
||||
|
||||
<figcaption>Example Service Monitor for Istio Proxies</figcaption>
|
||||
|
||||
```yaml
|
||||
apiVersion: monitoring.coreos.com/v1
|
||||
kind: ServiceMonitor
|
||||
metadata:
|
||||
name: envoy-stats-monitor
|
||||
namespace: istio-system
|
||||
labels:
|
||||
monitoring: istio-proxies
|
||||
spec:
|
||||
selector:
|
||||
matchExpressions:
|
||||
- {key: istio-prometheus-ignore, operator: DoesNotExist}
|
||||
namespaceSelector:
|
||||
any: true
|
||||
jobLabel: envoy-stats
|
||||
endpoints:
|
||||
- path: /stats/prometheus
|
||||
targetPort: 15090
|
||||
interval: 15s
|
||||
relabelings:
|
||||
- sourceLabels: [__meta_kubernetes_pod_container_port_name]
|
||||
action: keep
|
||||
regex: '.*-envoy-prom'
|
||||
- action: labeldrop
|
||||
regex: "__meta_kubernetes_pod_label_(.+)"
|
||||
- sourceLabels: [__meta_kubernetes_namespace]
|
||||
action: replace
|
||||
targetLabel: namespace
|
||||
- sourceLabels: [__meta_kubernetes_pod_name]
|
||||
action: replace
|
||||
targetLabel: pod_name
|
||||
```
|
||||
|
||||
### Monitoring across namespaces: Set ignoreNamespaceSelectors to False
|
||||
|
||||
This enables monitoring across namespaces by giving Prometheus additional scrape configurations.
|
||||
|
||||
The usability tradeoff is that all of Prometheus' `additionalScrapeConfigs` are maintained in a single Secret. This could make upgrading difficult if monitoring is already deployed with additionalScrapeConfigs before installing Istio.
|
||||
|
||||
1. When installing or upgrading the Monitoring Helm chart, edit the values.yml and set the `prometheus.prometheusSpec.additionalScrapeConfigs` array to the **Additional Scrape Config** provided below.
|
||||
1. Complete the install or upgrade.
|
||||
|
||||
**Result:** All namespaces with the `istio-injection=enabled` label will be scraped by prometheus.
|
||||
|
||||
<figcaption>Additional Scrape Config</figcaption>
|
||||
|
||||
``` yaml
|
||||
- job_name: 'istio/envoy-stats'
|
||||
scrape_interval: 15s
|
||||
metrics_path: /stats/prometheus
|
||||
kubernetes_sd_configs:
|
||||
- role: pod
|
||||
relabel_configs:
|
||||
- source_labels: [__meta_kubernetes_pod_container_port_name]
|
||||
action: keep
|
||||
regex: '.*-envoy-prom'
|
||||
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
|
||||
action: replace
|
||||
regex: ([^:]+)(?::\d+)?;(\d+)
|
||||
replacement: $1:15090
|
||||
target_label: __address__
|
||||
- action: labelmap
|
||||
regex: __meta_kubernetes_pod_label_(.+)
|
||||
- source_labels: [__meta_kubernetes_namespace]
|
||||
action: replace
|
||||
target_label: namespace
|
||||
- source_labels: [__meta_kubernetes_pod_name]
|
||||
action: replace
|
||||
target_label: pod_name
|
||||
```
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: CPU and Memory Allocations
|
||||
---
|
||||
|
||||
This section describes the minimum recommended computing resources for the Istio components in a cluster.
|
||||
|
||||
The CPU and memory allocations for each component are [configurable.](#configuring-resource-allocations)
|
||||
|
||||
Before enabling Istio, we recommend that you confirm that your Rancher worker nodes have enough CPU and memory to run all of the components of Istio.
|
||||
|
||||
:::tip
|
||||
|
||||
In larger deployments, it is strongly advised that the infrastructure be placed on dedicated nodes in the cluster by adding a node selector for each Istio component.
|
||||
|
||||
:::
|
||||
|
||||
The table below shows a summary of the minimum recommended resource requests and limits for the CPU and memory of each core Istio component.
|
||||
|
||||
In Kubernetes, the resource request indicates that the workload will not deployed on a node unless the node has at least the specified amount of memory and CPU available. If the workload surpasses the limit for CPU or memory, it can be terminated or evicted from the node. For more information on managing resource limits for containers, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
|
||||
| Workload | CPU - Request | Memory - Request | CPU - Limit | Memory - Limit |
|
||||
|----------------------|---------------|------------|-----------------|-------------------|
|
||||
| ingress gateway | 100m | 128mi | 2000m | 1024mi |
|
||||
| egress gateway | 100m | 128mi | 2000m | 1024mi |
|
||||
| istiod | 500m | 2048mi | No limit | No limit |
|
||||
| proxy | 10m | 10mi | 2000m | 1024mi |
|
||||
| **Totals:** | **710m** | **2314Mi** | **6000m** | **3072Mi** |
|
||||
|
||||
## Configuring Resource Allocations
|
||||
|
||||
You can individually configure the resource allocation for each type of Istio component. This section includes the default resource allocations for each component.
|
||||
|
||||
To make it easier to schedule the workloads to a node, a cluster-admin can reduce the CPU and memory resource requests for the component. However, the default CPU and memory allocations are the minimum that we recommend.
|
||||
|
||||
You can find more information about Istio configuration in the [official Istio documentation](https://istio.io/).
|
||||
|
||||
To configure the resources allocated to an Istio component,
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps**.
|
||||
1. Click **Installed Apps**.
|
||||
1. Go to the `istio-system` namespace. In one of the Istio workloads, such as `rancher-istio`, click **⋮ > Edit/Upgrade**.
|
||||
1. Click **Upgrade** to edit the base components via changes to the values.yaml or add an [overlay file](../../pages-for-subheaders/configuration-options.md#overlay-file). For more information about editing the overlay file, see [this section.](cpu-and-memory-allocations.md#editing-the-overlay-file)
|
||||
1. Change the CPU or memory allocations, the nodes where each component will be scheduled to, or the node tolerations.
|
||||
1. Click **Upgrade**. to rollout changes
|
||||
|
||||
**Result:** The resource allocations for the Istio components are updated.
|
||||
|
||||
### Editing the Overlay File
|
||||
|
||||
The overlay file can contain any of the values in the [Istio Operator spec.](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/#IstioOperatorSpec) The overlay file included with the Istio application is just one example of a potential configuration of the overlay file.
|
||||
|
||||
As long as the file contains `kind: IstioOperator` and the YAML options are valid, the file can be used as an overlay.
|
||||
|
||||
In the example overlay file provided with the Istio application, the following section allows you to change Kubernetes resources:
|
||||
|
||||
```
|
||||
# k8s:
|
||||
# resources:
|
||||
# requests:
|
||||
# cpu: 200m
|
||||
```
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Disabling Istio
|
||||
---
|
||||
|
||||
This section describes how to uninstall Istio in a cluster or disable a namespace, or workload.
|
||||
|
||||
## Uninstall Istio in a Cluster
|
||||
|
||||
To uninstall Istio,
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps > Installed Apps**.
|
||||
1. In the `istio-system` namespace, go to `rancher-istio` and click **⋮ > Delete**.
|
||||
1. After `rancher-istio` is deleted, you can then select all the remaining apps in the `istio-system` namespace and click **Delete**.
|
||||
|
||||
**Result:** The `rancher-istio` app in the cluster gets removed. The Istio sidecar cannot be deployed on any workloads in the cluster.
|
||||
|
||||
:::note
|
||||
|
||||
You can no longer disable and re-enable your Istio installation. If you would like to save your settings for a future install, view and save individual YAMLs to refer back to / reuse for future installations.
|
||||
|
||||
:::
|
||||
|
||||
**Troubleshooting Uninstall:** If you didn't follow the uninstall steps, you may encounter a warning during uninstall:
|
||||
|
||||
`Error: uninstallation completed with 1 error(s): unable to build kubernetes objects for delete: unable to recognize "": no matches for kind "MonitoringDashboard" in version "monitoring.kiali.io/v1alpha1"`
|
||||
|
||||
This could mean a few things. You either selected all the apps in the `istio-system` namespace and deleted them at the same time, or you deleted `rancher-istio` chart dependencies prior to deleting the `rancher-istio` chart. Since the uninstall did not complete properly, you will have resources remaining in the `istio-system` namespace that you will need to manually clean up. Another option to avoid manual clean up is to install `rancher-istio` again, then uninstall it in the correct order.
|
||||
|
||||
## Disable Istio in a Namespace
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
1. Click **Cluster > Projects/Namespaces**.
|
||||
1. Go to the namespace where you want to enable Istio and click **⋮ > Enable Istio Auto Injection**. Alternately, click the namespace, and then on the namespace detail page, click **⋮ > Enable Istio Auto Injection**.
|
||||
|
||||
**Result:** When workloads are deployed in this namespace, they will not have the Istio sidecar.
|
||||
|
||||
## Remove the Istio Sidecar from a Workload
|
||||
|
||||
Disable Istio in the namespace, then redeploy the workloads with in it. They will be deployed without the Istio sidecar.
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Role-based Access Control
|
||||
---
|
||||
|
||||
This section describes the permissions required to access Istio features.
|
||||
|
||||
The rancher istio chart installs three `ClusterRoles`
|
||||
|
||||
## Cluster-Admin Access
|
||||
|
||||
By default, only those with the `cluster-admin` `ClusterRole` can:
|
||||
|
||||
- Install istio app in a cluster
|
||||
- Configure resource allocations for Istio
|
||||
|
||||
|
||||
## Admin and Edit access
|
||||
|
||||
By default, only Admin and Edit roles can:
|
||||
|
||||
- Enable and disable Istio sidecar auto-injection for namespaces
|
||||
- Add the Istio sidecar to workloads
|
||||
- View the traffic metrics and traffic graph for the cluster
|
||||
- Configure Istio's resources (such as the gateway, destination rules, or virtual services)
|
||||
|
||||
## Summary of Default Permissions for Kubernetes Default roles
|
||||
|
||||
Istio creates three `ClusterRoles` and adds Istio CRD access to the following default K8s `ClusterRole`:
|
||||
|
||||
ClusterRole create by chart | Default K8s ClusterRole | Rancher Role |
|
||||
------------------------------:| ---------------------------:|---------:|
|
||||
`istio-admin` | admin| Project Owner |
|
||||
`istio-edit`| edit | Project Member |
|
||||
`istio-view` | view | Read-only |
|
||||
|
||||
Rancher will continue to use cluster-owner, cluster-member, project-owner, project-member, etc as role names, but will utilize default roles to determine access. For each default K8s `ClusterRole` there are different Istio CRD permissions and K8s actions (Create ( C ), Get ( G ), List ( L ), Watch ( W ), Update ( U ), Patch ( P ), Delete( D ), All ( * )) that can be performed.
|
||||
|
||||
|
||||
|CRDs | Admin | Edit | View
|
||||
|----------------------------| ------| -----| -----
|
||||
| <ul><li>`config.istio.io`</li><ul><li>`adapters`</li><li>`attributemanifests`</li><li>`handlers`</li><li>`httpapispecbindings`</li><li>`httpapispecs`</li><li>`instances`</li><li>`quotaspecbindings`</li><li>`quotaspecs`</li><li>`rules`</li><li>`templates`</li></ul></ul>| GLW | GLW | GLW
|
||||
|<ul><li>`networking.istio.io`</li><ul><li>`destinationrules`</li><li>`envoyfilters`</li><li>`gateways`</li><li>`serviceentries`</li><li>`sidecars`</li><li>`virtualservices`</li><li>`workloadentries`</li></ul></ul>| * | * | GLW
|
||||
|<ul><li>`security.istio.io`</li><ul><li>`authorizationpolicies`</li><li>`peerauthentications`</li><li>`requestauthentications`</li></ul></ul>| * | * | GLW
|
||||
Reference in New Issue
Block a user