Merge pull request #319 from tetratelabs/update-istio-charts-1.26.4+2

Update Istio charts 1.26.4+2

Author: bamachrn

charts/istio/1.26.4+tetrate2/README.md

@@ -0,0 +1,152 @@
+# Istio Installer
+
+## WARNING: Do not use the files in this directory to install Istio
+
+This directory contains the helm chart _sources_ which are versioned, built and pushed to following helm
+repositories with each Istio release.  If you want to make changes to Istio helm charts, you're in the
+right place.
+
+If you want to _install_ Istio with Helm, instead please [follow the Helm installation docs here](https://istio.io/latest/docs/setup/install/helm/).
+
+Charts in this folder are published to the following Helm repos:
+ - `https://istio-release.storage.googleapis.com/charts` (charts for official release versions)
+ - `oci://gcr.io/istio-release/charts/` (charts for official release versions and dev build versions)
+
+Chart publishing is handled by [release builder](https://github.com/istio/release-builder).
+
+---
+
+Note: If making any changes to the charts or values.yaml in this dir, first read [UPDATING-CHARTS.md](UPDATING-CHARTS.md)
+
+Istio installer is a modular, 'a-la-carte' installer for Istio. It is based on a
+fork of the Istio helm templates, refactored to increase modularity and isolation.
+
+Goals:
+- Improve upgrade experience: users should be able to gradually roll upgrades, with proper
+canary deployments for Istio components. It should be possible to deploy a new version while keeping the
+stable version in place and gradually migrate apps to the new version.
+
+- More flexibility: the new installer allows multiple 'environments', allowing applications to select
+a set of control plane settings and components. While the entire mesh respects the same APIs and config,
+apps may target different 'environments' which contain different instances and variants of Istio.
+
+- Better security: separate Istio components reside in different namespaces, allowing different teams or
+roles to manage different parts of Istio. For example, a security team would maintain the
+root CA and policy, a telemetry team may only have access to Prometheus,
+and a different team may maintain the control plane components (which are highly security sensitive).
+
+The install is organized in 'environments' - each environment consists of a set of components
+in different namespaces that are configured to work together. Regardless of 'environment',
+workloads can talk with each other and obey the Istio configuration resources, but each environment
+can use different Istio versions and different configuration defaults.
+
+`istioctl kube-inject` or the automatic sidecar injector are used to select the environment.
+In the case of the sidecar injector, the namespace label `istio-env: <NAME_OF_ENV>` is used instead
+of the conventional `istio-injected: true`. The name of the environment is defined as the namespace
+where the corresponding control plane components (config, discovery, auto-injection) are running.
+In the examples below, by default this is the `istio-control` namespace. Pod annotations can also
+be used to select a different 'environment'.
+
+## Installing
+
+The new installer is intended to be modular and very explicit about what is installed. It has
+far more steps than the Istio installer - but each step is smaller and focused on a specific
+feature, and can be performed by different people/teams at different times.
+
+It is strongly recommended that different namespaces are used, with different service accounts.
+In particular access to the security-critical production components (root CA, policy, control)
+should be locked down and restricted.  The new installer allows multiple instances of
+policy/control/telemetry - so testing/staging of new settings and versions can be performed
+by a different role than the prod version.
+
+The intended users of this repo are users running Istio in production who want to select, tune
+and understand each binary that gets deployed, and select which combination to use.
+
+Note: each component can be installed in parallel with an existing Istio 1.0 or 1.1 installation in
+`istio-system`. The new components will not interfere with existing apps, but can interoperate,
+and it is possible to gradually move apps from Istio 1.0/1.1 to the new environments and
+across environments ( for example canary -> prod )
+
+Note: there are still some cluster roles that may need to be fixed, most likely cluster permissions
+will need to move to the security component.
+
+## Everything is Optional
+
+Each component in the new installer is optional. Users can install the component defined in the new installer,
+use the equivalent component in `istio-system`, configured with the official installer, or use a different
+version or implementation.
+
+For example, you may use your own Prometheus and Grafana installs, or you may use a specialized/custom
+certificate provisioning tool, or use components that are centrally managed and running in a different cluster.
+
+This is a work in progress - building on top of the multi-cluster installer.
+
+As an extreme, the goal is to be possible to run Istio workloads in a cluster without installing any Istio component
+in that cluster. Currently, the minimum we require is the security provider (node agent or citadel).
+
+### Install Istio CRDs
+
+This is the first step of the installation. Please do not remove or edit any CRD - config currently requires
+all CRDs to be present. On each upgrade it is recommended to reapply the file, to make sure
+you get all CRDs.  CRDs are separated by release and by component type in the CRD directory.
+
+Istio has strong integration with certmanager.  Some operators may want to keep their current certmanager
+CRDs in place and not have Istio modify them. In this case, it is necessary to apply CRD files individually.
+
+```bash
+kubectl apply -k github.com/istio/installer/base
+```
+
+or
+
+```bash
+kubectl apply -f base/files
+```
+
+### Install Istio-CNI
+
+This is an optional step - CNI must run in a dedicated namespace, it is a 'singleton' and extremely
+security sensitive. Access to the CNI namespace must be highly restricted.
+
+**NOTE:** The environment variable `ISTIO_CLUSTER_ISGKE` is assumed to be set to `true` if the cluster
+is a GKE cluster.
+
+```bash
+ISTIO_CNI_ARGS=
+# TODO: What k8s data can we use for this check for whether GKE?
+if [[ "${ISTIO_CLUSTER_ISGKE}" == "true" ]]; then
+    ISTIO_CNI_ARGS="--set cni.cniBinDir=/home/kubernetes/bin"
+fi
+iop kube-system istio-cni $IBASE/istio-cni/ ${ISTIO_CNI_ARGS}
+```
+
+TODO. It is possible to add Istio-CNI later, and gradually migrate.
+
+### Install Control plane
+
+This can run in any cluster. A mesh should have at least one cluster should run Pilot or equivalent XDS server,
+and it is recommended to have Pilot running in each region and in multiple availability zones for multi cluster.
+
+```bash
+iop istio-control istio-discovery $IBASE/istio-control/istio-discovery \
+            --set global.istioNamespace=istio-system
+
+# Second istio-discovery, using master version of istio
+TAG=latest HUB=gcr.io/istio-testing iop istio-master istio-discovery-master $IBASE/istio-control/istio-discovery \
+            --set policy.enable=false \
+            --set global.istioNamespace=istio-master
+```
+
+### Gateways
+
+A cluster may use multiple Gateways, each with a different load balancer IP, domains and certificates.
+
+Since the domain certificates are stored in the gateway namespace, it is recommended to keep each
+gateway in a dedicated namespace and restrict access.
+
+For large-scale gateways it is optionally possible to use a dedicated pilot in the gateway namespace.
+
+### Additional test templates
+
+A number of helm test setups are general-purpose and should be installable in any cluster, to confirm
+Istio works properly and allow testing the specific installation.

charts/istio/1.26.4+tetrate2/UPDATING-CHARTS.md

@@ -0,0 +1,84 @@
+<!-- markdown-toc start - Don't edit this section. Run M-x markdown-toc-refresh-toc -->
+# Table of Contents
+
+- [Updating charts and values.yaml](#updating-charts-and-valuesyaml)
+    - [Acceptable Pull Requests](#acceptable-pull-requests)
+    - [Making changes](#making-changes)
+    - [Value deprecation](#value-deprecation)
+
+<!-- markdown-toc end -->
+
+# Updating charts and values.yaml
+
+## Acceptable Pull Requests
+
+Helm charts `values.yaml` represent a complex user facing API that tends to grow uncontrollably over time
+due to design choices in Helm.
+The underlying Kubernetes resources we configure have 1000s of fields; given enough users and bespoke use cases,
+eventually someone will want to customize every one of those fields.
+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.
+
+To avoid this, the project attempts to minimize additions to the `values.yaml` API where possible.
+
+- Helm is for configuration that is expected to be set at install-time only. 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). This allows configuration without re-installing or restarting deployments.
+
+- Adding new `global` values is discouraged as a general rule. The only exceptions are values that are frequently and consistently consumed across at least 2 charts (things like image tags, common labels, etc), but these would only be accepted on a strict case-by-case basis.
+
+- If the change is to a Kubernetes field (such as modifying a Deployment attribute), it will likely need to be install-time configuration. However, that doesn't necessarily mean a PR to add a value will be accepted. The `values.yaml` API is intended to maintain a *minimal core set of configuration* that most users will use. 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 to allow arbitrary customizations.
+
+- Avoid exposing a single subkey of a multi-value field if it would be more flexible to expose the entire field as arbitrary YAML. If the change truly is generally purpose, it is generally preferred to have broader APIs. For example, instead of providing direct access to each of the complex fields in [affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), just providing a single `affinity` field that is passed through as-is to the Kubernetes resource. This provides maximum flexibility with minimal API surface overhead.
+
+- All value additions or removals are user-facing and must come with a release note.
+
+- If you find yourself writing the same templating logic across several charts or needing to craft complex conditionals, consider using a shared Helm template for consistency rather than inlining.
+
+## Making changes
+
+### Step 1. Make changes in charts and values.yaml in `manifests` directory
+
+Be sure to provide sufficient documentation and example usage in values.yaml.
+
+- If the chart has a `values.schema.json`, that should be updated as well.
+
+### Step 2. Update the istioctl/Operator values
+
+If you are modifying the `gateway` chart, you can stop here.
+All other charts, however, are exposed by `istioctl` and need to follow the steps below.
+
+- The charts in the `manifests` directory are used in istioctl to generate an installation manifest.
+
+- If `values.yaml` is changed, be sure to update corresponding values changes in [../profiles/default.yaml](../profiles/default.yaml)
+
+### Step 3. Update istioctl schema
+
+Istioctl uses a [schema](../../operator/pkg/apis/values_types.proto) to validate the values. Any changes to
+the schema must be added here, otherwise istioctl users will see errors.
+Once the schema file is updated, run:
+
+```bash
+$ make operator-proto
+```
+
+This will regenerate the Go structs used for schema validation.
+
+### Step 4. Update the generated manifests
+
+Tests of istioctl use the auto-generated manifests to ensure that the istioctl binary has the correct version of the charts.
+
+To regenerate the manifests, run:
+
+```bash
+$ make copy-templates update-golden
+```
+
+### Step 5. Create a PR using outputs from Steps 1 to 4
+
+Your PR should pass all the checks if you followed these steps.
+
+## Value deprecation
+
+- Values may be marked as deprecated, but may not be removed until a minimum of 2 releases after the PR marking them as such is merged.
+
+- If you are _marking_ a value as `deprecated`, the PR doing so **must* add a [release note](../../releasenotes/README.md) mentioning the value being deprecated, and any replacements/alternatives.
+
+- When _removing_ a value that has been marked as `deprecated` for a minimum of 2 releases, **both** the `releaseNote` and `upgradeNote` fields must be populated in the release note in the removal PR, mentioning the value being removed, and any replacements/alternatives.

charts/istio/1.26.4+tetrate2/base/Chart.yaml

@@ -0,0 +1,10 @@
+apiVersion: v2
+appVersion: 1.26.4-tetrate2
+description: Helm chart for deploying Istio cluster resources and CRDs
+icon: https://istio.io/latest/favicons/android-192x192.png
+keywords:
+  - istio
+name: base
+sources:
+  - https://github.com/istio/istio
+version: 1.26.4+tetrate2

charts/istio/1.26.4+tetrate2/base/README.md

@@ -0,0 +1,35 @@
+# Istio base Helm Chart
+
+This chart installs resources shared by all Istio revisions. This includes Istio CRDs.
+
+## Setup Repo Info
+
+```console
+helm repo add istio https://istio-release.storage.googleapis.com/charts
+helm repo update
+```
+
+_See [helm repo](https://helm.sh/docs/helm/helm_repo/) for command documentation._
+
+## Installing the Chart
+
+To install the chart with the release name `istio-base`:
+
+```console
+kubectl create namespace istio-system
+helm install istio-base istio/base -n istio-system
+```
+
+### Profiles
+
+Istio Helm charts have a concept of a `profile`, which is a bundled collection of value presets.
+These can be set with `--set profile=<profile>`.
+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.
+
+For consistency, the same profiles are used across each chart, even if they do not impact a given chart.
+
+Explicitly set values have highest priority, then profile settings, then chart defaults.
+
+As an implementation detail of profiles, the default values for the chart are all nested under `defaults`.
+When configuring the chart, you should not include this.
+That is, `--set some.field=true` should be passed, not `--set defaults.some.field=true`.