Skip to content

Commit c186e87

Browse files
tetrate-citetrate-ci
authored
Update Istio charts 1.21.6+11 legacy (#168)
1 parent c177e24 commit c186e87

File tree

189 files changed

+29789
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

189 files changed

+29789
-0
lines changed

‎charts/istio/1.21.6-tetrate-v11/README.md

+136
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,136 @@
1+
# Istio Installer
2+
3+
Note: If making any changes to the charts or values.yaml in this dir, first read [UPDATING-CHARTS.md](UPDATING-CHARTS.md)
4+
5+
Istio installer is a modular, 'a-la-carte' installer for Istio. It is based on a
6+
fork of the Istio helm templates, refactored to increase modularity and isolation.
7+
8+
Goals:
9+
- Improve upgrade experience: users should be able to gradually roll upgrades, with proper
10+
canary deployments for Istio components. It should be possible to deploy a new version while keeping the
11+
stable version in place and gradually migrate apps to the new version.
12+
13+
- More flexibility: the new installer allows multiple 'environments', allowing applications to select
14+
a set of control plane settings and components. While the entire mesh respects the same APIs and config,
15+
apps may target different 'environments' which contain different instances and variants of Istio.
16+
17+
- Better security: separate Istio components reside in different namespaces, allowing different teams or
18+
roles to manage different parts of Istio. For example, a security team would maintain the
19+
root CA and policy, a telemetry team may only have access to Prometheus,
20+
and a different team may maintain the control plane components (which are highly security sensitive).
21+
22+
The install is organized in 'environments' - each environment consists of a set of components
23+
in different namespaces that are configured to work together. Regardless of 'environment',
24+
workloads can talk with each other and obey the Istio configuration resources, but each environment
25+
can use different Istio versions and different configuration defaults.
26+
27+
`istioctl kube-inject` or the automatic sidecar injector are used to select the environment.
28+
In the case of the sidecar injector, the namespace label `istio-env: <NAME_OF_ENV>` is used instead
29+
of the conventional `istio-injected: true`. The name of the environment is defined as the namespace
30+
where the corresponding control plane components (config, discovery, auto-injection) are running.
31+
In the examples below, by default this is the `istio-control` namespace. Pod annotations can also
32+
be used to select a different 'environment'.
33+
34+
## Installing
35+
36+
The new installer is intended to be modular and very explicit about what is installed. It has
37+
far more steps than the Istio installer - but each step is smaller and focused on a specific
38+
feature, and can be performed by different people/teams at different times.
39+
40+
It is strongly recommended that different namespaces are used, with different service accounts.
41+
In particular access to the security-critical production components (root CA, policy, control)
42+
should be locked down and restricted. The new installer allows multiple instances of
43+
policy/control/telemetry - so testing/staging of new settings and versions can be performed
44+
by a different role than the prod version.
45+
46+
The intended users of this repo are users running Istio in production who want to select, tune
47+
and understand each binary that gets deployed, and select which combination to use.
48+
49+
Note: each component can be installed in parallel with an existing Istio 1.0 or 1.1 installation in
50+
`istio-system`. The new components will not interfere with existing apps, but can interoperate,
51+
and it is possible to gradually move apps from Istio 1.0/1.1 to the new environments and
52+
across environments ( for example canary -> prod )
53+
54+
Note: there are still some cluster roles that may need to be fixed, most likely cluster permissions
55+
will need to move to the security component.
56+
57+
## Everything is Optional
58+
59+
Each component in the new installer is optional. Users can install the component defined in the new installer,
60+
use the equivalent component in `istio-system`, configured with the official installer, or use a different
61+
version or implementation.
62+
63+
For example you may use your own Prometheus and Grafana installs, or you may use a specialized/custom
64+
certificate provisioning tool, or use components that are centrally managed and running in a different cluster.
65+
66+
This is a work in progress - building on top of the multi-cluster installer.
67+
68+
As an extreme, the goal is to be possible to run Istio workloads in a cluster without installing any Istio component
69+
in that cluster. Currently, the minimum we require is the security provider (node agent or citadel).
70+
71+
### Install Istio CRDs
72+
73+
This is the first step of the installation. Please do not remove or edit any CRD - config currently requires
74+
all CRDs to be present. On each upgrade it is recommended to reapply the file, to make sure
75+
you get all CRDs. CRDs are separated by release and by component type in the CRD directory.
76+
77+
Istio has strong integration with certmanager. Some operators may want to keep their current certmanager
78+
CRDs in place and not have Istio modify them. In this case, it is necessary to apply CRD files individually.
79+
80+
```bash
81+
kubectl apply -k github.com/istio/installer/base
82+
```
83+
84+
or
85+
86+
```bash
87+
kubectl apply -f base/files
88+
```
89+
90+
### Install Istio-CNI
91+
92+
This is an optional step - CNI must run in a dedicated namespace, it is a 'singleton' and extremely
93+
security sensitive. Access to the CNI namespace must be highly restricted.
94+
95+
**NOTE:** The environment variable `ISTIO_CLUSTER_ISGKE` is assumed to be set to `true` if the cluster
96+
is a GKE cluster.
97+
98+
```bash
99+
ISTIO_CNI_ARGS=
100+
# TODO: What k8s data can we use for this check for whether GKE?
101+
if [[ "${ISTIO_CLUSTER_ISGKE}" == "true" ]]; then
102+
ISTIO_CNI_ARGS="--set cni.cniBinDir=/home/kubernetes/bin"
103+
fi
104+
iop kube-system istio-cni $IBASE/istio-cni/ ${ISTIO_CNI_ARGS}
105+
```
106+
107+
TODO. It is possible to add Istio-CNI later, and gradually migrate.
108+
109+
### Install Control plane
110+
111+
This can run in any cluster. A mesh should have at least one cluster should run Pilot or equivalent XDS server,
112+
and it is recommended to have Pilot running in each region and in multiple availability zones for multi cluster.
113+
114+
```bash
115+
iop istio-control istio-discovery $IBASE/istio-control/istio-discovery \
116+
--set global.istioNamespace=istio-system
117+
118+
# Second istio-discovery, using master version of istio
119+
TAG=latest HUB=gcr.io/istio-testing iop istio-master istio-discovery-master $IBASE/istio-control/istio-discovery \
120+
--set policy.enable=false \
121+
--set global.istioNamespace=istio-master
122+
```
123+
124+
### Gateways
125+
126+
A cluster may use multiple Gateways, each with a different load balancer IP, domains and certificates.
127+
128+
Since the domain certificates are stored in the gateway namespace, it is recommended to keep each
129+
gateway in a dedicated namespace and restrict access.
130+
131+
For large-scale gateways it is optionally possible to use a dedicated pilot in the gateway namespace.
132+
133+
### Additional test templates
134+
135+
A number of helm test setups are general-purpose and should be installable in any cluster, to confirm
136+
Istio works properly and allow testing the specific installation.

‎charts/istio/1.21.6-tetrate-v11/UPDATING-CHARTS.md

+66
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
# Updating charts and values.yaml
2+
3+
## Acceptable Pull Requests
4+
5+
Helm charts `values.yaml` represent a complex user facing API that tends to grow uncontrollably over time
6+
due to design choices in Helm.
7+
The underlying Kubernetes resources we configure have 1000s of fields; given enough users and bespoke use cases,
8+
eventually someone will want to customize every one of those fields.
9+
If all fields are exposed in `values.yaml`, we end up with an massive API that is also likely worse than just using the Kubernetes API directly.
10+
11+
To avoid this, the project attempts to minimize additions to the `values.yaml` API where possible.
12+
13+
If the change is a dynamic runtime configuration, it probably belongs in the [MeshConfig API](https://github.com/istio/api/blob/master/mesh/v1alpha1/config.proto).
14+
This allows configuration without re-installing or restarting deployments.
15+
16+
If the change is to a Kubernetes field (such as modifying a Deployment attribute), it will likely need to be install-time configuration.
17+
However, that doesn't necessarily mean a PR to add a value will be accepted.
18+
The `values.yaml` API is intended to maintain a *minimal core set of configuration* that most users will use.
19+
For bespoke use cases, [Helm Chart Customization](https://istio.io/latest/docs/setup/additional-setup/customize-installation-helm/#advanced-helm-chart-customization) can be used
20+
to allow arbitrary customizations.
21+
22+
If the change truly is generally purpose, it is generally preferred to have broader APIs. For example, instead of providing
23+
direct access to each of the complex fields in [affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), just providing
24+
a single `affinity` field that is passed through as-is to the Kubernetes resource.
25+
This provides maximum flexibility with minimal API surface overhead.
26+
27+
## Making changes
28+
29+
## Step 1. Make changes in charts and values.yaml in `manifests` directory
30+
31+
Be sure to provide sufficient documentation and example usage in values.yaml.
32+
If the chart has a `values.schema.json`, that should be updated as well.
33+
34+
## Step 2. Update the istioctl/Operator values
35+
36+
If you are modifying the `gateway` chart, you can stop here.
37+
All other charts, however, are exposed by `istioctl` and need to follow the steps below.
38+
39+
The charts in the `manifests` directory are used in istioctl to generate an installation manifest.
40+
41+
If `values.yaml` is changed, be sure to update corresponding values changes in [../profiles/default.yaml](../profiles/default.yaml)
42+
43+
## Step 3. Update istioctl schema
44+
45+
Istioctl uses a [schema](../../operator/pkg/apis/istio/v1alpha1/values_types.proto) to validate the values. Any changes to
46+
the schema must be added here, otherwise istioctl users will see errors.
47+
Once the schema file is updated, run:
48+
49+
```bash
50+
$ make operator-proto
51+
```
52+
53+
This will regenerate the Go structs used for schema validation.
54+
55+
## Step 4. Update the generated manifests
56+
57+
Tests of istioctl use the auto-generated manifests to ensure that the istioctl binary has the correct version of the charts.
58+
To regenerate the manifests, run:
59+
60+
```bash
61+
$ make copy-templates update-golden
62+
```
63+
64+
## Step 5. Create a PR using outputs from Steps 1 to 4
65+
66+
Your PR should pass all the checks if you followed these steps.

‎charts/istio/1.21.6-tetrate-v11/base/Chart.yaml

+14
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
apiVersion: v1
2+
name: base
3+
# This version is never actually shipped. istio/release-builder will replace it at build-time
4+
# with the appropriate version
5+
version: 1.21.6-tetrate-v11
6+
appVersion: 1.21.6-tetrate-v11
7+
tillerVersion: ">=2.7.2"
8+
description: Helm chart for deploying Istio cluster resources and CRDs
9+
keywords:
10+
- istio
11+
sources:
12+
- https://github.com/istio/istio
13+
engine: gotpl
14+
icon: https://istio.io/latest/favicons/android-192x192.png

‎charts/istio/1.21.6-tetrate-v11/base/README.md

+35
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
# Istio base Helm Chart
2+
3+
This chart installs resources shared by all Istio revisions. This includes Istio CRDs.
4+
5+
## Setup Repo Info
6+
7+
```console
8+
helm repo add istio https://istio-release.storage.googleapis.com/charts
9+
helm repo update
10+
```
11+
12+
_See [helm repo](https://helm.sh/docs/helm/helm_repo/) for command documentation._
13+
14+
## Installing the Chart
15+
16+
To install the chart with the release name `istio-base`:
17+
18+
```console
19+
kubectl create namespace istio-system
20+
helm install istio-base istio/base -n istio-system
21+
```
22+
23+
### Profiles
24+
25+
Istio Helm charts have a concept of a `profile`, which is a bundled collection of value presets.
26+
These can be set with `--set profile=<profile>`.
27+
For example, the `demo` profile offers a preset configuration to try out Istio in a test environment, with additional features enabled and lowered resource requirements.
28+
29+
For consistency, the same profiles are used across each chart, even if they do not impact a given chart.
30+
31+
Explicitly set values have highest priority, then profile settings, then chart defaults.
32+
33+
As an implementation detail of profiles, the default values for the chart are all nested under `defaults`.
34+
When configuring the chart, you should not include this.
35+
That is, `--set some.field=true` should be passed, not `--set defaults.some.field=true`.

0 commit comments

Comments
 (0)