Install Istio in Production with IstioOperator and HA (2026)

Istio’s IstioOperator is not just a configuration file; it’s a declarative API that allows you to manage your Istio control plane’s lifecycle and configuration as a Kubernetes resource.

Let’s see IstioOperator in action, managing a highly available Istio control plane. Imagine we have a Kubernetes cluster and want to deploy Istio with multiple replicas of its core components, ensuring resilience.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: istio-control-plane
spec:
  profile: production
  components:
    pilot:
      k8s:
        hpaSpec:
          minReplicas: 3
          maxReplicas: 5
        replicaCount: 3
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          hpaSpec:
            minReplicas: 2
            maxReplicas: 4
          replicaCount: 2
  values:
    global:
      meshConfig:
        accessLogFile: /dev/stdout
        defaultConfig:
          tracing:
            zipkin:
              address: zipkin.istio-system:9411

This IstioOperator manifest defines a production-ready Istio installation. It specifies the production profile, which includes sensible defaults for performance and security. Critically, it configures high availability (HA) for pilot (the core control plane component responsible for service discovery and configuration) and the istio-ingressgateway.

Here’s how it works internally:

• profile: production: This pre-selects a set of components and their configurations optimized for production environments. It typically includes enabling features like mutual TLS by default, setting appropriate resource requests/limits, and configuring components for resilience.
• components.pilot.k8s.replicaCount: 3: This tells Istio to deploy three replicas of the pilot Deployment. If one replica fails, the others continue to serve traffic and configuration.
• components.pilot.k8s.hpaSpec: This defines Horizontal Pod Autoscaler (HPA) settings for pilot. minReplicas: 3 ensures we always have at least three pods running, even during low traffic. maxReplicas: 5 allows Istio to scale up automatically if pilot experiences high CPU or memory utilization.
• components.ingressGateways: This section configures the ingress gateways. We’ve enabled the default istio-ingressgateway and set its replicaCount to 2 for HA. The HPA is also configured with minReplicas: 2 and maxReplicas: 4.
• values.global.meshConfig: This section allows you to override or set specific Istio configuration options that would normally go into istio-system/mesh-config. Here, we’re enabling access logs to standard output and configuring tracing to send data to a Zipkin collector at zipkin.istio-system:9411.

To apply this configuration, you would typically use the istioctl command-line tool:

istioctl install -f your-istio-operator.yaml

This command reads the IstioOperator manifest and translates it into the necessary Kubernetes resources (Deployments, Services, ConfigMaps, etc.) within the istio-system namespace. The control plane components, like Pilot and the ingress gateways, will be deployed with the specified replica counts and HPA configurations.

The most surprising thing about IstioOperator is how it abstracts away the complexity of managing individual Kubernetes resources. Instead of manually creating Deployments, Services, and ConfigMaps for each Istio component, you declare the desired state of your Istio control plane, and istioctl handles the rest. This declarative approach aligns perfectly with Kubernetes’ own philosophy and makes managing Istio much more robust and repeatable. It also means that when you want to upgrade Istio, you simply update the IstioOperator manifest with the new version and re-apply it; istioctl will orchestrate the upgrade process.

The next step after installing Istio with HA is to understand how to configure your services to be part of the mesh.