Apache APISIX ingress controller

APISIX Ingress controller for Kubernetes using Apache APISIX as a high performance reverse proxy and load balancer.

If you have installed multiple ingress controller, add the kubernetes.io/ingress.class: apisix annotation to your Ingress resources.

This chart bootstraps an apisix-ingress-controller deployment on a Kubernetes cluster using the Helm package manager.

Prerequisites

Apisix ingress controller requires Kubernetes version 1.16+.

Get Repo Info

helm repo add apisix https://apache.github.io/apisix-helm-chart
helm repo update

Install Chart

Important: only helm3 is supported

helm install [RELEASE_NAME] apisix/apisix-ingress-controller --namespace ingress-apisix --create-namespace

The command deploys apisix-ingress-controller on the Kubernetes cluster in the default configuration.

See configuration below.

See helm install for command documentation.

Uninstall Chart

helm uninstall [RELEASE_NAME] --namespace ingress-apisix

This removes all the Kubernetes components associated with the chart and deletes the release.

See helm uninstall for command documentation.

Upgrading Chart

helm upgrade [RELEASE_NAME] [CHART] --install

See helm upgrade for command documentation.

Configuration

See Customizing the Chart Before Installing. To see all configurable options with detailed comments, visit the chart's values.yaml, or run these configuration commands:

helm show values apisix/apisix-ingress-controller

Pod priority

priorityClassName field referenced a name of a created PriorityClass object. Check here for more details.

Security context

A security context provides us with a way to define privilege and access control for a Pod or even at the container level.

Check here to see the SecurityContext resource with more detail.

Check also here to see a full explanation and some examples to configure the security context.

Right below you have an example of the security context configuration. In this case, we define that all the processes in the container will run with user ID 1000.

...

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
...

The same for the group definition, where we define the primary group of 3000 for all processes.

It's quite important to know, if the runAsGroup is omited, the primary group will be root(0), which in some cases goes against some security policies.

To define this configuration at the pod level, you need to set:

    --set podSecurityContext.runAsUser=«VALUE»
    --set podSecurityContext.runAsGroup=«VALUE»
    ...

The same for container level, you need to set:

    --set securityContext.runAsUser=«VALUE»
    --set SecurityContext.runAsGroup=«VALUE»
    ...

Values