Kubernetes upgrades are hard enough without stale APIs hiding in GitOps repos. Janos 2.4.0 audits manifests and selected live resources, previews supported migrations, and makes cases needing human judgment explicit. It is now available as a scoped package on npm.

Why this exists

A Kubernetes upgrade often fails in the repo before it fails in the cluster. A manifest can sit untouched for years, then hit an API removal: batch/v1beta1 CronJobs and policy/v1beta1 PodSecurityPolicies, for example, stopped being served in Kubernetes 1.25. A global search-and-replace is tempting, but some migrations need new fields or human decisions.

That is the gap I built Janos for. Named after the two-faced Roman god of transitions, it helps teams audit GitOps source manifests, preview a diff, migrate supported cases, and turn unresolved cases into visible CI failures. The aim is a reviewable workflow, not a promise that every old object has a safe automatic replacement.

Try the 2.4.0 release

Janos is now available on npm as @pgold30/janos (Node.js 18+). The executable is still called janos:

npm install --global @pgold30/janos@2.4.0
janos --audit -d ./k8s --target-version 1.25
janos -d ./k8s --target-version 1.25 --dry-run --diff
janos -d ./k8s --target-version 1.25 -i
janos --audit -d ./k8s --target-version 1.25 --check

The sequence is deliberate: audit first, inspect the proposed changes, apply supported migrations interactively, then make --check part of CI. --target-version limits work to the Kubernetes release you are preparing for. For a one-off audit without a global install, run:

npm exec --yes --package=@pgold30/janos@2.4.0 -- janos --audit -d ./k8s

Use the scoped package name. Older examples using npx janos refer to an unscoped npm name that is not the published package.

What changed since 2.2?

• PodSecurityPolicy is a manual migration. Kubernetes 1.25 removed the API, but there is no drop-in replacement object. Janos now leaves the PSP unchanged, points to Pod Security Admission, and fails --check instead of outputting another removed API version.
• Complex rules check required schema details. CRDs need an existing structural schema; webhooks need explicit sideEffects and admissionReviewVersions; CSRs need a signer, request, and valid usages; and supported HPA metrics need valid v2 targets. When those details cannot be inferred safely, Janos reports manual work.
• Cluster reports show what they actually know. For the fixed set of kinds it queries through kubectl, Janos prefers a matching last-applied manifest, then falls back to the API currently served by the cluster. Coverage counts expose that distinction. --cluster --audit --check --require-original fails if an original manifest is unavailable.
• Pre-commit hooks handle every passed file. The 2.4.0 hooks process multiple filenames, including names with spaces, and the migration hook checks files again after writing.

The repository also has a before/after gallery with successful migrations and cases deliberately left for human review.

What a safe edit looks like

For a simple CronJob, Janos can change the API version while leaving comments on unchanged YAML nodes in place:

# Managed by the platform team
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: nightly-cleanup # runs at 00:00 UTC

The preview changes batch/v1beta1 to batch/v1. For structural changes, replaced sections can be reformatted or lose comments, so review the diff before committing. The checks cover known requirements; they are not a substitute for validating against your target API server. For complex resources, use a disposable test cluster and kubectl apply --dry-run=server --validate=strict before production.

Where Janos fits alongside other tools

Pluto and Kube No Trouble are useful for deprecation discovery, including Helm history. Janos is strongest when you own the source YAML and want audit → preview → edit → CI in one workflow. Its cluster collector does not inspect every kind or Helm release history; keep scanning the source repos.

Janos can also generate a starter Gateway API HTTPRoute from an Ingress with --ingress-to-gateway. Review its parent references, TLS, backends, and annotations. For controller-specific behavior, compare with the Kubernetes Gateway API project's ingress2gateway and its provider-specific output.

There are GitHub Action and pre-commit examples for enforcing the result in pull requests. Start with a dry-run on a small directory, check the diff, and expand only after the target cluster accepts the output.

Help make the next release better

Janos is Apache-2.0 open source. Try the npm package, inspect the examples, and tell me which migration still needs human work. The roadmap prioritizes versioned schema validation, broader cluster evidence, and better GitOps inputs. Concrete failing manifests and target Kubernetes versions are especially useful in a GitHub issue.

Back in 2018, I wrote this guide on managing wildcard certificates in Kubernetes. It unexpectedly hit the top of Google search results because it solved a painful problem: avoiding Let’s Encrypt rate limits by manually replicating secrets across namespaces.

But 7 years is a lifetime in the container world. The v1alpha1 APIs are dead, Ingress is being superseded, and the idea of copying a private key to 50 different namespaces now feels... wrong.

We spent years building tools to patch architectural limitations, like copying secrets across namespaces. Today, we don’t need better patches; we have better architecture. The Gateway API proves that the smartest solution isn’t managing complexity — it’s designing it away.

Here is how to handle Wildcard TLS in 2026 using the Gateway API — the “no-copy” approach.

The Evolution: From Ingress to Gateway

In the “Old World” (Ingress), TLS termination happened at the Ingress controller, but the configuration was often fragmented. If you had an Ingress in the marketing namespace, it needed the TLS secret to exist inside the marketing namespace.

This forced us to create hacky “Reflector” scripts or use tools like kubernetes-replicator to clone our one precious Wildcard Certificate into every single namespace.

Enter Gateway API.

The Gateway API separates the Listener (Port 443 and TLS Configuration) from the Route (Application logic).

• The Ops Team manages the Gateway in a secure namespace (e.g., infra). The Wildcard Certificate lives here and only here.
• The Dev Team manages HTTPRoutes in their app namespaces. They attach to the Gateway without ever touching the certificates.

Step 1: The Certificate (Centralized)

We still use cert-manager, but we only issue the certificate once, in one place. We no longer need sidecars or replication scripts.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-mycompany-com
  namespace: infra  # The certificate stays HERE.
spec:
  secretName: wildcard-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: "*.mycompany.com"
  dnsNames:
  - "*.mycompany.com"

Step 2: The Gateway (The “Shared Edge”)

This is the replacement for your Ingress Controller setup. We define a Gateway that listens on HTTPS and references the secret we just created.

Crucially, we configure allowedRoutes to allow All Namespaces to attach to this listener.

Note: The gatewayClassName below is for the GKE Global Load Balancer. If you are using Regional LBs, check your provider's documentation.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: wildcard-secret # Referenced locally in 'infra'
    allowedRoutes:
      namespaces:
        from: All  # <--- This is the magic. No copying needed.

Ensure you have enabled the Gateway API on your GKE cluster (gcloud container clusters update ... --gateway-api=standard)

Step 3: The Application (No Secrets Needed)

Now, a developer in the checkout namespace wants to deploy their app. They don't need to ask you for the cert. They don't need a Reflector script. They just define a Route.

Best Practice: Notice the sectionName. This explicitly binds the route to the HTTPS listener we defined above, preventing ambiguity if you add port 80 later.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-route
  namespace: checkout # Different namespace!
spec:
  parentRefs:
  - name: shared-gateway
    namespace: infra # Pointing to the central Gateway
    sectionName: https # Explicitly bind to the secure listener
  hostnames:
  - "checkout.mycompany.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: checkout-service
      port: 80

Production Checklist: Don’t Forget These!

While the YAML above works, a production environment needs two more things to avoid downtime.

1. The DNS Reality Check

In the old Ingress world, every Ingress might have had its own IP. In the Gateway world, you have one single IP for the entire platform.

You must configure your DNS provider (e.g., Cloud DNS or Route53) to point *.mycompany.com (A Record) to the Gateway's IP Address. If you don't do this, the traffic never hits the Gateway to be routed.

Pro Tip: Use ExternalDNS with the Gateway source enabled. It will automatically read the hostnames from your HTTPRoutes and update Cloud DNS for you. No manual A-records needed.

2. The “502 Bad Gateway” Trap

GKE Gateway Load Balancers are strict about health checks. If your checkout-service doesn't return a 200 OK on its root path (or its configured readiness probe), the Gateway will return a 502 error instantly.

Ensure your deployments have valid readinessProbe configurations:

# Inside your Deployment spec
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

Summary

In 2018, we solved this problem with v1alpha1 APIs and bash loops. In 2026, we solve it with declarative architecture.

We spent time building tools to patch architectural limitations, like copying secrets across namespaces. Today, we don’t need better patches; we have better architecture. The Gateway API proves that the smartest solution isn’t managing complexity — it’s designing it away.

So, that’s it. I hope you find it useful, and the steps are easy to follow. Please comment and/or ask questions if I missed something — I’d love to get your feedback.

The 2026 Guide to Managing Wildcard TLS with Kubernetes Gateway API was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Verve we are handling a high volume of traffic with hundreds of millions of events daily (clicks, impressions, actions, in-app events, etc.).
This means we need to be able to scale our servers fast to handle traffic spikes and control who has access to our servers and with which permissions.
We have built our infrastructure on top of K8s to allow elasticity and scalability.

We recently published a blog post with Google related to a few topics (add link!), GKE Gateway LB envoy-based, C4, and CCC. Here we will cover CCC in depth.

Context

We use 100% spot nodes did some proper benchmarks for our application and assigned scores for each node type based on performance/ spot price, It is quite common that in certain regions we reach stockouts due to GCP not having the resource capacity

This is a graph showing the score for each instance type on our app

Google recently released CCC (custom compute class aka AWS Carpenter)you can find the blog post here and the official docs here

GKE custom compute classes maximize obtainability and reliability by providing fall-back compute priorities. This increases the chances of successful autoscaling while giving you control over the resources that get spun up. If your priority resource is unable to scale up, GKE will automatically try the second priority of node selection, and then continue to other lower priorities on the list.

One cool feature is activeMigration which Reconcile to preferential infrastructure, meaning Custom compute classes enable active migration of workloads to preferential node shapes, such as those based on cost or performance optimization. If workloads initially land on lower priority nodes, GKE automatically tries to migrate workloads to higher priority nodes over time, as availability allows.

Compute classes provide a consistent node configuration API that abstracts away node configuration complexity for developers. App teams can consume compute classes with a simple nodeSelector label or rely on namespace-scoped default compute classes.

Requirements

• GKE version > 1.30.3.1451000+
• Ensure that you have node auto-provisioning enabled in your cluster

TF block:

  ...cluster_autoscaling = {
    "auto_repair" : false,
    "auto_upgrade" : false,
    "autoscaling_profile" : "OPTIMIZE_UTILIZATION",
    "disk_size" : 30,
    "disk_type" : "pd-standard",
    "enabled" : true,
    "gpu_resources" : [],
    "max_cpu_cores" : 10000000000000,
    "max_memory_gb" : 10000000000000,
    "min_cpu_cores" : 0,
    "min_memory_gb" : 0,
    "autoprovisioningLocations": [
     "asia-southeast1-b"
    ]
  }...

Howto

Create a Compute class

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: adserver
spec:
  priorities:
    - machineType: n2d-standard-64
      spot: true
      storage:
        bootDiskType: pd-balanced
        bootDiskSize: 30
    - machineType: n4-standard-64
      spot: true
      storage:
        bootDiskSize: 30
#no pd-balanced since n4 supports only hyperdisk
    - machineType: n2-standard-64
      spot: true
      storage:
        bootDiskType: pd-balanced
        bootDiskSize: 30
    - machineType: n2d-standard-64
      spot: false
      storage:
        bootDiskType: pd-balanced
        bootDiskSize: 30
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70
#In this configuration, GKE removes unused nodes after five minutes, and nodes only become candidates for consolidation if both their CPU and memory utilization is less than 70%.
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

In this example, the GKE Cluster Autoscaler first tries to spin up an n2d node std 64, then n4,n2 all spot, and if none of those work we fall back to not spot n2d. Node auto-provisioning (NAP) is enabled in this example and creates new node pools automatically as needed.

As a developer, I just need to make sure that my workload is using that

...
  spec:
    nodeSelector:
      cloud.google.com/compute-class: adserver
....

To further streamline the developer experience, you can designate a custom compute class as the default for specific Kubernetes namespaces. When a compute class is set as the namespace default, any workloads deployed within that namespace automatically inherit the compute class configuration, eliminating the need for repetitive workload-level settings. To create a namespace-level adserver custom compute class, set a namespace label using the cloud.google.com/default-compute-class key, for example:

kubectl label namespaces adserver cloud.google.com/default-compute-class=adserver

With this, we aim to solve both availability and cost savings, even during high-traffic season.