<commit_before>---
title: Loadbalancing reference
---

# Load Balancing Reference

Kong provides multiple ways of load balancing requests to multiple backend
services: a straightforward DNS-based method, and a more dynamic ring-balancer
that also allows for service registry without needing a DNS server.

### Table of Contents

- [DNS-based loadbalancing](#dns-based-loadbalancing)
  - [A records](#a-records)
  - [SRV records](#srv-records)
  - [DNS priorities](#dns-priorities)
  - [DNS caveats](#dns-caveats)
- [Ring-balancer](#ring-balancer)
  - [Upstream](#upstream)
  - [Target](#target)
  - [Balancing algorithms](#balancing-algorithms)
  - [Balancing caveats](#balancing-caveats)
- [Blue-green Deployments](#blue-green-deployments)
- [Canary Releases](#canary-releases)

### DNS-based loadbalancing

When using DNS-based load balancing, the registration of the backend services
is done outside of Kong, and Kong only receives updates from the DNS server.

Every Service that has been defined with a `host` containing a hostname
(instead of an IP address) will automatically use DNS-based load balancing
if the name resolves to multiple IP addresses, provided the hostname does not
resolve to an `upstream` name or a name in your DNS hostsfile.

The DNS record `ttl` setting (time to live) determines how often the information
is refreshed. When using a `ttl` of 0, every request will be resolved using its
own DNS query. Obviously this will have a performance penalty, but the latency of
updates/changes will be very low.

[Back to TOC](#table-of-contents)

#### **A records**

An A record contains one or more IP addresses. Hence, when a hostname
resolves to an A record, each backend service must have its own IP address.

Because there is no `weight` information, all entries will be treated as equally
weighted in the load balancer, and the balancer will do a straight forward
round-robin.

[Back to TOC](#table-of-contents)

#### **SRV records**

An SRV record contains weight and port information for all of its IP addresses.
A backend service can be identified by a unique combination of IP address
and port number. Hence, a single IP address can host multiple instances of the
same service on different ports.

Because the `weight` information is available, each entry will get its own
weight in the load balancer and it will perform a weighted round-robin.

Similarly, any given port information will be overridden by the port information from
the DNS server. If a Service has an `host=myhost.com` attribute,
and `myhost.com` resolves to an SRV record with `127.0.0.1:456`, then the request
will be proxied to `http://127.0.0.1:456/somepath`, as port `123` will be
overridden by `456`.<commit_msg>docs(ce/lb) mention 'port' attribute for Services<commit_after>---
title: Loadbalancing reference
---

# Load Balancing Reference

Kong provides multiple ways of load balancing requests to multiple backend
services: a straightforward DNS-based method, and a more dynamic ring-balancer
that also allows for service registry without needing a DNS server.

### Table of Contents

- [DNS-based loadbalancing](#dns-based-loadbalancing)
  - [A records](#a-records)
  - [SRV records](#srv-records)
  - [DNS priorities](#dns-priorities)
  - [DNS caveats](#dns-caveats)
- [Ring-balancer](#ring-balancer)
  - [Upstream](#upstream)
  - [Target](#target)
  - [Balancing algorithms](#balancing-algorithms)
  - [Balancing caveats](#balancing-caveats)
- [Blue-green Deployments](#blue-green-deployments)
- [Canary Releases](#canary-releases)

### DNS-based loadbalancing

When using DNS-based load balancing, the registration of the backend services
is done outside of Kong, and Kong only receives updates from the DNS server.

Every Service that has been defined with a `host` containing a hostname
(instead of an IP address) will automatically use DNS-based load balancing
if the name resolves to multiple IP addresses, provided the hostname does not
resolve to an `upstream` name or a name in your DNS hostsfile.

The DNS record `ttl` setting (time to live) determines how often the information
is refreshed. When using a `ttl` of 0, every request will be resolved using its
own DNS query. Obviously this will have a performance penalty, but the latency of
updates/changes will be very low.

[Back to TOC](#table-of-contents)

#### **A records**

An A record contains one or more IP addresses. Hence, when a hostname
resolves to an A record, each backend service must have its own IP address.

Because there is no `weight` information, all entries will be treated as equally
weighted in the load balancer, and the balancer will do a straight forward
round-robin.

[Back to TOC](#table-of-contents)

#### **SRV records**

An SRV record contains weight and port information for all of its IP addresses.
A backend service can be identified by a unique combination of IP address
and port number. Hence, a single IP address can host multiple instances of the
same service on different ports.

Because the `weight` information is available, each entry will get its own
weight in the load balancer and it will perform a weighted round-robin.

Similarly, any given port information will be overridden by the port information from
the DNS server. If a Service has attributes `host=myhost.com` and `port=123`,
and `myhost.com` resolves to an SRV record with `127.0.0.1:456`, then the request
will be proxied to `http://127.0.0.1:456/somepath`, as port `123` will be
overridden by `456`.
{'fraction_non_alphanumeric': 0.08067165541157145, 'fraction_numerical': 0.009673298047088885, 'mean_word_length': 4.569105691056911, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 4, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4916171', 'n_tokens_mistral': 1599, 'n_tokens_neox': 1488, 'n_words': 739}