Back to all use cases

AssessmentCross-Industry

A written verdict per namespace before anyone relabels anything

Platform Engineering Team

A typical engagement for a platform team that runs Istio with sidecars and is weighing ambient mode: a namespace-by-namespace verdict on what can move, what needs a waypoint and what blocks the move.

Overview

A typical engagement starts with a platform team that runs Istio in sidecar mode across many namespaces and wants to know whether ambient mode is worth the move. Ambient mode has been generally available since Istio 1.24, but the team has not worked out which of its policies and routes depend on the sidecar.

Challenge

Namespaces that only need mTLS and layer 4 authorization are easy to move. Layer 7 policies, routes and JWT validation need a waypoint, EnvoyFilter is not supported on waypoints, and some deployments hit hard blockers. Istio's migration guide says that with layer 7 policies a zero-downtime move is not currently possible, so the order and the maintenance windows matter.

Environment

Kubernetes clusters running a supported Istio minor in sidecar mode, with gateways, AuthorizationPolicy and PeerAuthentication resources, a mix of VirtualService and Gateway API routes, and a few EnvoyFilter customizations written by engineers who have since moved on.

Approach

AceMQ engineers inventory the policies, routes, gateways and customizations in each namespace and compare them with the ambient feature stages and the blockers Istio documents. Each namespace gets a verdict: move now to ztunnel only, move with a waypoint, or wait, with the reason. The first move is planned as a rehearsal with a tested way back.

Solution

  1. Per-namespace inventory of AuthorizationPolicy, PeerAuthentication, VirtualService, HTTPRoute, DestinationRule and EnvoyFilter resources
  2. Check for hard blockers: VM workloads, SPIRE as certificate provider, PeerAuthentication in DISABLE mode and primary-remote multicluster
  3. List of policies that must be retargeted to a waypoint, and routes that must move from VirtualService to HTTPRoute for each workload
  4. Review of feature stages for anything the namespace uses that is still alpha or beta in ambient mode
  5. Namespace order, maintenance windows for namespaces with layer 7 policy, and the sidecar callers that bypass waypoints until they move
  6. Rehearsal plan for the first namespace, with rollback

Outcome

The engagement delivers a written assessment with a verdict for every namespace, the list of policies and routes that change, the blockers found, the order of moves with the windows they need, and a rehearsal plan for the first namespace. The customer decides from the facts whether to move.

Technologies

IstioKubernetesEnvoyGateway API
  • Consulting

    Kong Gateway Architecture and Migration Consulting

    Multi-Line Insurance CarrierCross-Industry

    Designing a Kong topology for a company consolidating several ad-hoc API entry points, including control plane separation and environment promotion.

    KongKubernetesPostgreSQLDockerNGINX
    Read case study: Kong Gateway Architecture and Migration Consulting
  • Managed Services

    Managed EKS Cluster Operations in the Customer's AWS Account

    SaaS Platform TeamSoftware

    A typical Tier 3 engagement: AceMQ takes over upgrades, node pools, certificates, backups and on-call for production EKS clusters that stay in the customer's AWS accounts.

    KubernetesAmazon EKSVelerocert-managerPrometheus
    Read case study: Managed EKS Cluster Operations in the Customer's AWS Account
  • Assessment

    Ingress NGINX to Gateway API Migration Assessment

    Platform Engineering TeamCross-Industry

    A typical engagement for a platform team that still runs the retired Ingress NGINX controller: every Ingress resource, annotation and snippet inventoried and mapped route by route to Gateway API resources, with a parallel-run plan.

    NGINXKubernetesGateway APIIngress NGINX
    Read case study: Ingress NGINX to Gateway API Migration Assessment
  • Assessment

    Airbyte Pipeline and Connector Estate Assessment

    Insurance Services GroupCross-Industry

    A structured review of an Airbyte estate that had grown organically — auditing connector versions, sync modes, state handling, and failure visibility.

    AirbyteKubernetesPostgreSQLdbtKafka
    Read case study: Airbyte Pipeline and Connector Estate Assessment
  • Assessment

    ansible-core Upgrade and AWX Control Plane Assessment

    IT Operations TeamCross-Industry

    A typical engagement to check an AWX estate and its execution environments against ansible-core's maintained versions, find the job templates the 2.19 templating changes will break, and decide between staying on AWX with a plan and moving the control plane to Red Hat Ansible Automation Platform.

    AnsibleAWXKubernetesPostgreSQL
    Read case study: ansible-core Upgrade and AWX Control Plane Assessment

Related Reading

Ready for an Istio Health Check?

AceMQ's senior Istio engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.