Istio 0.4 makes installation choices explicit in Helm values
Istio 0.4 adds Helm charts and minimal Cloud Foundry discovery in Pilot. The tagged chart shows how authentication and ingress choices become installation inputs, alongside new diagnostics and policy integrations.
Installing a service mesh includes decisions about the components to run and the behavior to enable. A collection of Kubernetes manifests can express those decisions, but repeated local edits make the installation harder to describe as a coherent configuration. The Istio 0.4 announcement introduces Helm charts, giving operators a set of values that feed the installation templates.
The release also adds minimal Cloud Foundry support in Pilot, a Circonus Mixer adapter and Pilot diagnostic metrics. It contains only a few weeks of changes as the project establishes the monthly release cadence announced with 0.3. Its additions address different operating tasks, including deployment configuration, service discovery and observation of the control system itself.
I see installation configuration as part of a mesh's architecture. The choice to enable authentication or expose ingress is a decision about how the system operates. A chart is useful where it makes those decisions visible and keeps their effects consistent across the resources being installed.
Helm values describe the installation's selected behavior
The values file at the 0.4.0 tag includes switches for base configuration, the initializer, Mixer and Pilot. It also declares shared values for the namespace and component image locations and tags. These inputs separate installation choices from the repeated resource definitions that consume them.
By default, the shared namespace is istio-system, and global.auth_enabled is false. Component and proxy image tags in this file are 0.4.0. Installing the chart therefore does not, merely by virtue of installing Istio, select its authentication-enabled configuration.
An operator selecting authentication and NodePort ingress can express those particular overrides as follows. These are chart values, not a complete Kubernetes manifest or an instruction that every environment should use this ingress mode.
global:
auth_enabled: true
Istio:
ingress:
use_nodeport: true
nodeport_port: 32000
The capitalized Istio key is part of this version's actual values format. Its ingress defaults instead select a LoadBalancer Service. The NodePort option supplies a different exposure mechanism, with a configurable port for HTTP traffic.
The templates show what the flags change
The ingress template selects NodePort or LoadBalancer according to use_nodeport. When NodePort is selected, it assigns the configured port to the HTTP Service port. HTTPS remains another exposed Service port in the template. This is a concrete resource change arising from an installation value.
Authentication affects more than the chart's description. The mesh configuration template writes authPolicy: MUTUAL_TLS when global.auth_enabled is true. It also writes controlPlaneAuthPolicy: MUTUAL_TLS in the default proxy configuration. A shared value therefore influences both application proxy communication and communication with the control plane.
The template excludes kubernetes.default.svc.cluster.local from the service mutual-TLS policy. Its comments explain the need to exclude control services that do not have an Istio sidecar to terminate that authentication transparently. This makes an adoption boundary visible within the generated mesh configuration.
The ingress Deployment also selects its control-plane authentication argument from the same value. In the authenticated case it passes MUTUAL_TLS, and otherwise it passes NONE. Reading the template shows which behavior the option selects, without assuming that a product's general security capabilities determine every installation default.
Packaging versions are not runtime image versions
The chart metadata still declares chart version 0.3.0 at the 0.4.0 source tag. Its dependency declarations also name 0.3.0 for Pilot, Mixer and initializer charts. Those metadata versions should not be confused with the 0.4.0 runtime image tags in the values file.
The dependency file ties each subchart to its corresponding enablement condition. Pilot uses Istio.pilot_enabled, for example. The installation's composition is therefore another declared choice, separate from the version of the image a selected component will run.
This detail is useful when describing the release precisely. Version 0.4 adds the Helm installation mechanism, but its chart metadata does not simply mirror the product's release number. The tagged files provide the authoritative description of that packaging arrangement.
Cloud Foundry support starts with discovery
The announcement describes minimum Pilot support for discovering Cloud Foundry services and service instances. That is narrower than complete integration of every Istio deployment and security workflow with the platform. Discovery supplies information Pilot needs about the services it will configure proxies to reach.
This follows the 0.2 release's outside-Kubernetes work, which added standalone Pilot inputs from Consul and Eureka. Another registry or platform can feed service information into the common proxy configuration role. The release does not claim that adding a discovery source alone provisions every proxy or supplies every credential in the environment.
My interest in the Cloud Foundry addition is that separation of responsibilities. A mixed environment can have a common traffic-management goal while retaining different sources of service information. The specific contribution in 0.4 is letting Pilot discover the Cloud Foundry services and instances named in the announcement.
Diagnostics cover Pilot itself
Pilot now collects diagnostic metrics. The release does not enumerate their names or provide a performance result, so the defensible claim is the availability of additional observation of Pilot itself. Application request metrics and control-plane diagnostics concern different parts of the system an operator must understand.
Mixer gains a Circonus adapter and additional functions in its attribute-expression language. The adapter provides another monitoring integration, while the expression functions expand how policy rules can be written. Together with Helm installation inputs, these changes make more of Istio's surrounding operational behavior configurable without requiring application source changes. Cloud Foundry discovery remains a specific new input to Pilot within that broader configuration and integration work.