HAProxy Ingress configuration keys may be in one of five distinct scopes: Tens of thousands of Ingress and Service resources report to work smoothly and There is no hard limit to the number of Ingresses or Services - clusters with Might lead to conflicting configuration, more about conflict in the HAProxy Ingress will merge all the resources, so there is no difference if theĬonfiguration is in the same or in distinct Ingress. The ConfigMap spec expects a string as the key value, so declare numbers and booleansĪs strings, HAProxy Ingress will convert them when needed.ĪpiVersion : /v1 kind : Ingress metadata : annotations : /rewrite-target : / name : app-back spec : rules : - host : app.local http : paths : - path : /api pathType : Prefix backend : service : name : backend port : number : 8080 See about IngressClass later in this same section.Ī configuration key is used verbatim as the ConfigMap key name, without any prefix. IngressClass config, using its parameters field linked to a ConfigMap declared in the same namespace of the controller.Note, -configmap needs to be in the following format: /. This is the only way to configure keys from the Global scope. The installation process configures a Global config ConfigMap named haproxy-ingress in the controller namespace. Global config, using -configmap command-line option.ConfigMapĬonfigMap key/value options are read in the following conditions: The following sections describe in a few more details about configuration strategies. Keys, and this is what the rest of this documentation page is all about. So any Ingress spec configuration should work as stated by the Kubernetes documentation.Īnnotations and ConfigMap customizations extend the Ingress spec via the configuration Spec configurations from classified Ingress resources.Annotations from classified Ingress resources and also from Services that these Ingress are linking to.
ConfigMaps are assigned either via -configmap command-line option (used by Global options), or via parameters field of an IngressClass HAProxy Ingress reads configuration on three distinct ways: Note that this is a new behavior since v0.12.
Kubernetes.io/ingress.class annotation and also does not have the ingressClassNameįield. add Ingress resources that does not have the Ingress to the final configuration - i.e. The third and latest option asks HAProxy Ingress to also add “unclassified” The annotation value wins and a warning is logged.Īdding a class annotation or defining an IngressClass name means “classify” an Ingress Says the controller belongs to HAProxy Ingress and the other says that it does not belong. Ifīoth options are configured in an Ingress resource, and they conflict - i.e. Class annotation and the IngressClass name can be changed on a runningĬontroller, the configuration will be adjusted on the fly to reflect the new status. The first two options give more control on which Ingress resources should be part of theįinal configuration.
The list above also describes the precedence if the same configuration key is used Per backend, annotating Service resources.Per Ingress, configuring or annotating Ingress resources.Per IngressClass, from a ConfigMap linked in the IngressClass’ parameters field.HAProxy Ingress reads configuration keysįrom Kubernetes resources, and this can be done in a couple of ways:
List of all annotations and global ConfigMap options.Ĭonfiguration keys are entry point configurations that allow users and admins toĭynamically fine-tune HAProxy status.
0 kommentar(er)
