Shulou(Shulou.com)06/03 Report--

The official Kong has many detailed references, such as configuration files, command line, Admin API, agents, and load balancers. Let's take a brief look at what they provide.

This article is mainly based on the description of Kong version 1.3. if you have any updates, please check the latest documentation.

Configuration file

Through an in-depth understanding of configuration files, you can optimize Kong clusters, use databases, and configure Nginx

The official reference is Configuration Reference.

When Kong starts, you can specify the configuration file with the-c or-- conf parameters, such as:

Kong start-c / path/to/kong.conf

You can use the check command to verify the syntax correctness of the configuration file

$kong check configuration at is valid

The configuration of Kong also looks for the environment variable with the same name when loading, and Kong can also be configured through the environment variable, and the environment variable takes precedence over the configuration file. Kong can be configured through environment variables to facilitate container-based deployment and operation. If you want to use environment variables, you need to start with the KONG_ field.

Command line referenc

The provided CLI (command line interface) allows you to start, stop, and manage Kong instances. CLI can manage local nodes (such as on the current machine). You can refer to the official website documentation.

CLI Reference

The main commands are as follows

Global markup

All commands can use the following parameters

-- help: print command help information-- v: open detail mode-- vv: open debug mode commands available kong check check configuration file syntax, etc. Kong config uses declarative configuration files. Kong health checks to see if kong on that node is running kong migration Management Kong's database kong prepare this command prepares the Kong prefix folder and its subfolders and files. Kong quit graceful exit Kong instance kong reload reload kong instance configuration kong restart restart kong instance kong start start kong instance kong stop stop kong instance kong version print version information Admin API reference

For instructions on Admin API, please refer to the official website:

Admin API Reference

Admin API accepts 2 two connection types at each terminal.

Are

Application/x-www-from-urlencodedapplication/json

There are a total of 9 objects, namely:

Service ObjectRoute ObjectConsumer ObjectPlugin Object-PrecedenceCertificate ObjectCA Certificate ObjectSNI ObjectUpstream ObjectTarget ObjectProxy referenc

In this document, we will introduce the proxy function of Kong by explaining its routing function and internal operation in detail.

Kong exposes several interfaces that can be adjusted through two configuration properties:

Proxy_listen, which defines a list of addresses / ports on which Kong will accept public traffic from clients and proxy it to your upstream service (default is 8000). Admin_listen, which also defines a list of addresses and ports, but these should be restricted to administrator access because they expose the configuration function of Kong: Admin API (8001 by default).

Proxy Reference

The terms commonly used in Kong are:

Client: refers to a request from a downstream customer to the Kong proxy port. Upstream service: refers to the API/Service behind the Kong to which client requests are forwarded. Service: as the name implies, a service entity is an abstraction of an upstream service. Examples of services include data conversion microservices, billing API, and so on. Route: this refers to the Kong routing entity. The Route is the entry point into the Kong, defines rules for the request to match, and then routes to the given service. Plugin: refers to the "plugins" of Kong, which is a fragment of business logic that runs in the agent life cycle. Plug-ins can be configured by managing the API-- either globally (all incoming traffic) or on specific routes and services. Load balancing reference

Kong provides a variety of ways to load balance requests for multiple back-end services: a simple DNS-based approach and a more dynamic ring balancer that also allows service registration without the need for a DNS server.

Load balancer can refer to the official website documentation.

Load Balancing Reference to understand.

Load balancing based on DNS

When using DNS-based load balancing, the registration of the back-end service is done outside the Kong, while Kong only receives updates from the DNS server.

"if the hostname does not resolve to an upstream name or a name in the DNS hosts file, each service defined with a host that contains the hostname instead of the IP address automatically uses DNS-based load balancing."

DNS records ttl settings (time to live) that determine how often the information is refreshed. When ttl is 0, each request is parsed using its own DNS query. This will result in a performance penalty, but the latency of updates / changes will be very low.

A record

An A record corresponds to one or more IP addresses, so when a host name resolves to an A record, each back-end service must have its own IP address.

Because there is no weight information, all entries will be treated as equal weights in the load balancer, and the balancer will loop directly.

SRV record

The SRV record contains weight and port information for all IP addresses. Back-end services can be identified by a unique combination of IP address and port number. Therefore, an IP address can host multiple instances of the same service on different ports.

Because the weight information is available, each entry gets its own weight in the load balancer and performs a weighting loop.

Priority of DNS

1. The last success type parsed earlier

2. SRV record

3. A record

4. CNAME record

These can be configured in the dns_order of the configuration file.

Load balancing based on Ring-balancer

When using Ring-balancer, the addition and deletion of back-end services will be handled by Kong and no DNS updates are required. Kong will serve as the service registry. Nodes can be added / removed through a HTTP request and will immediately start / stop receiving traffic.

Configuring Ring-balancer work requires two entities, Upstream and target.

Target: the IP address or hostname with the port number of the back-end service, for example, "192.168.100.12 80". Each goal gets an additional weight to indicate the relative load it gets. IP addresses can be in IPv4 and IPv6 formats. Upstream: a virtual hostname, a host field that can be used for routing. For example, a upstream is a weather.v2 that receives all requests from the service host=weather.v2.service. Summary

Originally roughly described the Kong configuration file, command line, agent, load balancing and so on.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.