Hi Zeping,

Thanks for the prompt response. I’ll try defining the Lua-based processing
as ApisixPluginConfig CRs and referencing them from Ingress resources.

I also ran into an issue when enabling TLS for ApisixRoute resources. This
is likely a configuration issue on my side, so I’ll open a separate issue
with more details.

Thanks again,
Amila

On Fri, Feb 6, 2026 at 9:27 AM Zeping Bai <[email protected]> wrote:

> Hi, Amila.
>
> We do not mandate the use of ApisixRoute or Ingress. Even though Ingress
> does not natively support extension points, it can still configure plugins
> using annotations [1].
> However, ApisixRoute is indeed a CRD resource that aligns more closely with
> the APISIX concept. Its advantage lies in sharing many configuration
> options with APISIX, thereby reducing the friction cost of understanding.
>
> For question 1, as long as you can configure the plugin however you like,
> you can achieve functionality similar to the original code snippet. We
> support configuring plugins on HTTPRoute/Ingress/ApisixRoute.
> Since the Ingress standard has been frozen and will not see further
> development in the foreseeable future, you should prioritize using the
> Gateway API HTTPRoute (it's a popular standard), followed by ApisixRoute
> and other CRDs, and only resort to Ingress when absolutely necessary.
>
> For question 2, APISIX Ingress Controller (AIC) currently does not support
> ingress-nginx annotations [1]. However, it provides its own annotation
> support. AIC will transcribe these annotations into APISIX plugin
> configurations and apply them.
> The scope of annotations is limited, so directly configuring plugins is
> sometimes a more straightforward approach. This allows you to clearly
> understand what is configured, where it takes effect, and whether it meets
> expectations.
>
> APISIX enables hot-loading for many configurations, allowing updates to
> routes and upstream settings without reloading Nginx workers. Certain
> unsupported hot-loading features—such as the buffering you mentioned
> require pre-start configuration. You must configure those Nginx directives
> within your Helm chart.
>
> Currently, only the request body size [3] and request buffer [4] can be
> dynamically configured via plugins. Other settings only support static
> configuration. However, some workarounds supported by NGINX, such as the
> upstream x-accel-buffering response header, are still supported.
>
> [1]
>
> https://apisix.apache.org/docs/ingress-controller/reference/apisix-ingress-controller/annotation/
> [2]
>
> https://artifacthub.io/packages/helm/apisix/apisix?modal=values&path=apisix.nginx.configurationSnippet
> [3] https://apisix.apache.org/docs/apisix/plugins/client-control/
> [4] https://apisix.apache.org/docs/apisix/plugins/proxy-control/
>
>
> On Fri, Feb 6, 2026 at 2:57 AM Amila De Silva via dev <
> [email protected]>
> wrote:
>
> > Hi Devs,
> >
> > We are currently evaluating APISIX as a replacement for the NGINX Ingress
> > Controller and are in the process of migrating a few existing Ingress
> > resources. We would appreciate your recommendation on the best approach
> for
> > this migration.
> >
> > We mainly have two types of Ingress resources:
> >
> > *1. Ingresses with custom Lua routing logic*
> > These use annotations such as
> > nginx.ingress.kubernetes.io/server-snippet and
> > nginx.ingress.kubernetes.io/configuration-snippet
> > to inject custom Lua logic for routing and redirection.
> >
> > *2. Vanilla Ingresses with only annotations*
> > These do not contain custom processing but use annotations such as
> > nginx.ingress.kubernetes.io/client-body-buffer-size and
> > nginx.ingress.kubernetes.io/client-header-buffer-size
> > to enforce limits and restrictions.
> >
> > Based on the documentation, my understanding is:
> >
> >    -
> >
> >    The first type should be migrated to *ApisixRoute* resources, where
> Lua
> >    logic can be implemented through custom plugins or serverless plugins.
> >    -
> >
> >    The second type *might* be represented using standard Ingress
> resources.
> >    However, I could not find a clear mapping between NGINX annotations
> and
> >    APISIX annotations/plugins, so I am unsure whether these can remain as
> >    Ingresses or also need to move to ApisixRoute.
> >
> > Could you please advise:
> >
> >    -
> >
> >    Whether the above understanding is correct?
> >    -
> >
> >    The recommended way to migrate NGINX annotations such as buffer
> limits?
> >    -
> >
> >    Whether vanilla Ingress resources are expected to work reliably in
> >    APISIX without switching to ApisixRoute?
> >
> > Thanks in advance for your guidance.
> >
> > Best regards,
> > Amila
> >
> > --
> > *Amila De Silva*
> > Software Architect | Associate Director, Engineering - WSO2 Inc.
> > (m) +94 775119302 | (e) [email protected]
> > <http://wso2.com/signature>
> >
>


-- 
*Amila De Silva*
Software Architect | Associate Director, Engineering - WSO2 Inc.
(m) +94 775119302 | (e) [email protected]
<http://wso2.com/signature>

Reply via email to