DOCSEARCHbyAlgolia
Submit Docs

HAProxy Ingress

repository·master·Indexed 22 days ago

https://github.com/jcmoraisjr/haproxy-ingress

A Kubernetes ingress controller that configures HAProxy load balancers to route external network requests to in-cluster applications. It supports advanced traffic management features including Basic Authentication, Client Certificate Authentication, OAuth2 integration via oauth2-proxy, and Blue/Green deployment patterns using weighted groups and HTTP header routing.

Tokens
83.2K
Snippets
238
Records
397
Agent score
78%

What's inside haproxy-ingress

  1. Overview of HAProxy Ingress configuration options

    master

    HAProxy Ingress can be configured using several different mechanisms depending on the scope of the change required:

    • Ingress/Service Annotations: Used for resource-specific configuration (e.g., setting timeouts or SSL settings for a specific Ingress or Service).
    • Global ConfigMap options: Used to define settings that apply to the entire controller instance.
    • Command-line options: Used to configure the controller process itself during startup.
    • Template overwriting: Used to customize the generated HAProxy configuration files.

  2. Configure Blue-Green Deployments

    master

    Blue-green configuration allows you to manage backend server groups based on weights (balance) or specific selectors (headers/cookies).

    Blue/Green Balance: Configures the weight of a deployment using labels. The annotation accepts a comma-separated list of labelName=labelValue=weight (e.g., version=blue=10,version=green=90).

    Blue/Green Selector: Allows group selection based on an HTTP header or cookie value. If a header/cookie is provided and matches a group, that group is used; otherwise, the blue-green-balance is used.

    Key Configuration Options:

    • blue-green-mode: (Backend) Defines how to apply weights. Options: deploy (default) or pod.
    • blue-green-balance: (Backend) The list of label/weight pairs.
    • blue-green-header: (Backend) The HTTP header to use for selection.
    • blue-green-cookie: (Backend) The cookie to use for selection.

    Requirement: To use blue/green, your deployment/pod templates must have at least two labels: one for the standard service selector and one for the blue/green selector.

    blue-green-mode: deploy
blue-green-balance: version=blue=10,version=green=90

  4. Security behavior for misconfigured OAuth in v0.10.11

    master
    In version v0.10.11, the controller was updated to ensure that if OAuth is misconfigured (for example, due to a missing service name), the controller will always deny requests instead of allowing them to reach the backend. This release also updated the embedded HAProxy to 2.0.25 to address CVE-2021-40346 (Content-Length HTTP header vulnerability).

  5. Configure Blue/Green deployment weights and selectors

    master

    Blue/Green Weighting

    Weights are configured using the format group=blue=1,group=green=4, which redirects 20% of load to blue and 80% to green.

    There are two modes for applying weights:

    • pod mode: Every single pod receives the same weight. A deployment with double the replicas of another will receive twice as much traffic.
    • deploy mode: Weights are rebalanced based on the number of replicas in each deployment. Use this mode if you want to control the load ratio via the blue/green balance annotation regardless of replica counts.

    Weight values:

    • 0: The endpoint accepts persistent connections (see affinity) but does not participate in load balancing.
    • Maximum value: 256.

    Blue/Green Selectors

    Selectors allow you to match a specific group (blue or green) using an HTTP header or cookie. This is primarily for controlled testing scenarios.

    • blue-green-cookie: A CookieName:LabelName pair.
    • blue-green-header: A HeaderName:LabelName pair.

    Example: If you configure X-Server:group on blue-green-header, a request with the header X-Server: green will match a pod labeled group=green.

    Precedence: If both a header and a cookie are configured, the header takes precedence. If the header value doesn't match a healthy backend, the cookie is used.

    `group=blue=1,group=green=4`

  7. Migrate from peers-table to backend-scoped stick tables

    master

    In version v0.16.0-alpha.2, the peers configuration was changed to be backend-scoped. This allows distinct backends to have their own synchronized stick-tables.

    Migration Note: If you require a single global peers table (the previous behavior), you must now use the peers-table-global key instead of peers-table.

    peers-table-global