kubernetes

Guide Kubernetes controller upgrades across Gateway API alpha, beta, and GA phases.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/Pandaala/Edgion --skill kubernetes-pandaala
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kubernetes
Source: https://github.com/Pandaala/Edgion/tree/main/skills/08-kubernetes
Command: npx skills add https://github.com/Pandaala/Edgion --skill kubernetes-pandaala

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Kubernetes Gateway API upgrades often fail in subtle ways because controllers and CRDs evolve across alpha, beta, and GA, causing inconsistent watch/CRUD behavior or broken compatibility.

Core Features & Use Cases

  • API version lifecycle strategy: Guidance for upgrading Gateway API and related Kubernetes resources across alpha → beta → GA while preserving compatibility guarantees.
  • Controller-side upgrade tactics: Techniques for version probing, safe fallback, and consistent version selection across watch, preflight, CRUD, and status writes.
  • Canonical internal typing: Methods to unify version-specific inputs into a single internal model so business logic does not fork per API version.
  • Non-Kubernetes input normalization: A parsing-first conversion flow for filesystem/static sources when API Server conversion is unavailable.
  • Practical case studies & test matrix: Concrete examples (ReferenceGrant, BackendTLSPolicy, TLSRoute) plus a minimum test checklist to validate correctness.

Quick Start

Use this skill to plan and implement a single-version-probe plus canonical-type upgrade approach for your Edgion controller when migrating Gateway API resources across versions.

Frequently Asked Questions about kubernetes

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely upgrade Gateway API resources in Kubernetes across alpha, beta, and GA versions?

To safely upgrade Gateway API resources, you need a controller-side strategy that applies version probing with fallback and maintains consistent version selection across watch, CRUD, and status operations. This ensures compatibility is preserved throughout the lifecycle phases.

What is canonical internal type unification for Kubernetes controller reconciliation?

Canonical internal type unification is a method to map version-specific Kubernetes CRD inputs into a single internal model. This prevents business logic from forking per API version during controller reconciliation and multi-version coexistence.

How do I normalize Gateway API configurations when the Kubernetes API Server conversion webhook is unavailable?

When API Server conversion is unavailable, you must implement a parsing-first conversion flow to normalize filesystem or static sources. This handles non-Kubernetes input ingestion by converting raw data into the canonical internal type.

How should a Kubernetes controller handle CRD multi-version coexistence during an API upgrade?

Controllers handle CRD multi-version coexistence by enforcing single-active watcher behavior and aligning read, write, and status API versions. This guarantees consistent reconciliation across different CRD versions simultaneously.

What are the limitations of relying on Kubernetes API Server conversion for Gateway API upgrades?

Relying on API Server conversion breaks down for non-Kubernetes input ingestion and static filesystem sources where the conversion webhook cannot intercept. Controllers must implement their own version probing and fallback logic to handle these edge cases.