$ helm status {{ .Release.Name }} -n {{ .Release.Namespace }}
  $ helm get all {{ .Release.Name }} -n {{ .Release.Namespace }}

Next steps:
  * Deploy an HTTP Gateway: https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/

  }

  # Now deploy the specified number of KinD clusters and
  # wait till they are provisioned successfully.
  declare -a DEPLOY_KIND_JOBS
  for i in "${!CLUSTER_NAMES[@]}"; do
    deploy_kind "${i}" & DEPLOY_KIND_JOBS+=("${!}")
  done

  for pid in "${DEPLOY_KIND_JOBS[@]}"; do
    wait "${pid}" || exit 1
  done

{{- if (eq .Values.profile "ambient") }}
  * Get started with ambient: https://istio.io/latest/docs/ops/ambient/getting-started/
  * Review ambient's architecture: https://istio.io/latest/docs/ops/ambient/architecture/
{{- else }}
  * Deploy a Gateway: https://istio.io/latest/docs/setup/additional-setup/gateway/
  * Try out our tasks to get started on common configurations:
    * https://istio.io/latest/docs/tasks/traffic-management

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

- the new chart uses the default namespace service account, and doesn't require
additional RBAC permissions.

- simplified label structure. Label change is not supported on upgrade.

- for 'internal load balancer' you should deploy a separate gateway, in a different
namespace.

All ingress gateway have a "app:ingressgateway" label, used to identify it as an
ingress, and an "istio: ingressgateway$SUFFIX" label of Gateway selection.

    excludeNamespaces:
      - kube-system

    # Allows user to set custom affinity for the DaemonSet
    affinity: {}

    # Custom annotations on pod level, if you need them
    podAnnotations: {}

    # Deploy the config files as plugin chain (value "true") or as standalone files in the conf dir (value "false")?
    # Some k8s flavors (e.g. OpenShift) do not support the chain approach, set to false if this is the case
    chained: true

			return err
		}
		installLog.Info("Detected changes to the node-level CNI setup, checking to see if configs or binaries need redeploying")
		// We don't support (or want) to silently (re)deploy any binaries that were not in the initial "snapshot"
		// so we intentionally discard/do not update the list of installedBins on redeploys.
		if _, err := in.installAll(ctx); err != nil {
			return err
		}

lates/NOTES.txt "{{ include "gateway.name" . }}" successfully installed! To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} Next steps: * Deploy an HTTP Gateway: https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/ * Deploy an HTTPS Gateway: https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/ manifests/charts/gateway/files/profile-preview.yaml # The preview profile contains features that are...

                  name: istio-cni-config
                  key: cni_network_config
            - name: CNI_NET_DIR
              value: {{ default "/etc/cni/net.d" .Values.cni.cniConfDir }}
            # Deploy as a standalone CNI plugin or as chained?
            - name: CHAINED_CNI_PLUGIN
              value: "{{ .Values.cni.chained }}"
            - name: REPAIR_ENABLED
              value: "{{ .Values.cni.repair.enabled }}"