Admin API

描述

Admin API 是为 Apache APISIX 服务的一组 API，我们可以将参数传递给 Admin API 以控制 APISIX 节点。更好地了解其工作原理，请参阅 Architecture Design 中的文档。

启动 Apache APISIX 时，默认情况下 Admin API 将监听 9080 端口（HTTPS 的 9443 端口）。您可以通过修改 conf/config.yaml 文件来改变默认监听的端口。

在下面出现的 X-API-KEY 指的是 conf/config.yaml 文件中的 apisix.admin_key.key，它是 Admin API 的访问 token。

Route

地址：/apisix/admin/routes/{id}?ttl=0

说明：Route 字面意思就是路由，通过定义一些规则来匹配客户端的请求，然后根据匹配结果加载并执行相应的插件，并把请求转发给到指定 Upstream。

注意：在启用 Admin API 时，它会占用前缀为 /apisix/admin 的 API。因此，为了避免您设计 API 与 /apisix/admin 冲突，建议为 Admin API 使用其他端口，您可以在 conf/config.yaml 中通过 port_admin 进行自定义 Admin API 端口。

请求方法

URL 请求参数

body 请求参数

有两点需要特别注意：

• 对于同一类参数比如 uri与 uris，upstream 与 upstream_id，host 与 hosts，remote_addr 与 remote_addrs 等，是不能同时存在，二者只能选择其一。如果同时启用，接口会报错。
• 在 vars 中，当获取 cookie 的值时，cookie name 是区分大小写字母的。例如：var 等于 “cookie_x_foo” 与 var 等于 “cookie_X_Foo” 表示不同的 cookie。

route 对象 json 配置内容：

{
    "id": "1",                            # id，非必填
    "uris": ["/a","/b"],                  # 一组 URL 路径
    "methods": ["GET","POST"],            # 可以填多个方法
    "hosts": ["a.com","b.com"],           # 一组 host 域名
    "plugins": {},                        # 指定 route 绑定的插件
    "priority": 0,                        # apisix 支持多种匹配方式，可能会在一次匹配中同时匹配到多条路由，此时优先级高的优先匹配中
    "name": "路由 xxx",
    "desc": "hello world",
    "remote_addrs": ["127.0.0.1"],        # 一组客户端请求 IP 地址
    "vars": [["http_user", "==", "ios"]], # 由一个或多个 [var, operator, val] 元素组成的列表
    "upstream_id": "1",                   # upstream 对象在 etcd 中的 id ，建议使用此值
    "upstream": {},                       # upstream 信息对象，建议尽量不要使用
    "timeout": {                          # 为 route 设置 upstream 的连接、发送消息、接收消息的超时时间。
        "connect": 3,
        "send": 3,
        "read": 3
    },
    "filter_func": ""                     # 用户自定义的过滤函数，非必填
}

具体示例：

# 创建一个路由
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "remote_addrs": ["127.0.0.0/8"],
    "methods": ["PUT", "GET"],
    "enable_websocket": true,
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'
HTTP/1.1 201 Created
Date: Sat, 31 Aug 2019 01:17:15 GMT
...
# 创建一个有效期为 60 秒的路由，过期后自动删除
$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'
HTTP/1.1 201 Created
Date: Sat, 31 Aug 2019 01:17:15 GMT
...
# 给路由增加一个 upstream node
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "upstream": {
        "nodes": {
            "127.0.0.1:1981": 1
        }
    }
}'
HTTP/1.1 200 OK
...
执行成功后，upstream nodes 将更新为：
{
    "127.0.0.1:1980": 1,
    "127.0.0.1:1981": 1
}
# 给路由更新一个 upstream node 的权重
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "upstream": {
        "nodes": {
            "127.0.0.1:1981": 10
        }
    }
}'
HTTP/1.1 200 OK
...
执行成功后，upstream nodes 将更新为：
{
    "127.0.0.1:1980": 1,
    "127.0.0.1:1981": 10
}
# 给路由删除一个 upstream node
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": null
        }
    }
}'
HTTP/1.1 200 OK
...
执行成功后，upstream nodes 将更新为：
{
    "127.0.0.1:1981": 10
}
# 替换路由的 methods -- 数组
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '{
    "methods": ["GET", "POST"]
}'
HTTP/1.1 200 OK
...
执行成功后，methods 将不保留原来的数据，整个更新为：
["GET", "POST"]
# 替换路由的 upstream nodes -- sub path
$ curl http://127.0.0.1:9080/apisix/admin/routes/1/upstream/nodes -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "127.0.0.1:1982": 1
}'
HTTP/1.1 200 OK
...
执行成功后，nodes 将不保留原来的数据，整个更新为：
{
    "127.0.0.1:1982": 1
}
# 替换路由的 methods  -- sub path
$ curl http://127.0.0.1:9080/apisix/admin/routes/1/methods -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '["POST", "DELETE", "PATCH"]'
HTTP/1.1 200 OK
...
执行成功后，methods 将不保留原来的数据，整个更新为：
["POST", "DELETE", "PATCH"]
# 禁用路由
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "status": 0
}'
HTTP/1.1 200 OK
...
执行成功后，status 将更新为：
{
    "status": 0
}
# 启用路由
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "status": 1
}'
HTTP/1.1 200 OK
...
执行成功后，status 将更新为：
{
    "status": 1
}

应答参数

目前是直接返回与 etcd 交互后的结果。

Back to TOC

Service

地址：/apisix/admin/services/{id}

说明：Service 是某类 API 的抽象（也可以理解为一组 Route 的抽象）。它通常与上游服务抽象是一一对应的，Route 与 Service 之间，通常是 N:1 的关系。

请求方法

body 请求参数

service 对象 json 配置内容：

{
    "id": "1",                # id
    "plugins": {},            # 指定 service 绑定的插件
    "upstream_id": "1",       # upstream 对象在 etcd 中的 id ，建议使用此值
    "upstream": {},           # upstream 信息对象，不建议使用
    "name": "test svc",       # service 名称
    "desc": "hello world",    # service 描述
    "enable_websocket": true, # 启动 websocket 功能
    "hosts": ["foo.com"]
}

具体示例：

# 创建一个 Service
$ curl http://127.0.0.1:9080/apisix/admin/services/201  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "plugins": {
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 503,
            "key": "remote_addr"
        }
    },
    "enable_websocket": true,
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'
# 返回结果
HTTP/1.1 201 Created
...
# 给 Service 增加一个 upstream node
$ curl http://127.0.0.1:9080/apisix/admin/services/201 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "upstream": {
        "nodes": {
            "127.0.0.1:1981": 1
        }
    }
}'
HTTP/1.1 200 OK
...
执行成功后，upstream nodes 将更新为：
{
    "127.0.0.1:1980": 1,
    "127.0.0.1:1981": 1
}
# 给 Service 更新一个 upstream node 的权重
$ curl http://127.0.0.1:9080/apisix/admin/services/201 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "upstream": {
        "nodes": {
            "127.0.0.1:1981": 10
        }
    }
}'
HTTP/1.1 200 OK
...
执行成功后，upstream nodes 将更新为：
{
    "127.0.0.1:1980": 1,
    "127.0.0.1:1981": 10
}
# 给 Service 删除一个 upstream node
$ curl http://127.0.0.1:9080/apisix/admin/services/201 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "upstream": {
        "nodes": {
            "127.0.0.1:1980": null
        }
    }
}'
HTTP/1.1 200 OK
...
执行成功后，upstream nodes 将更新为：
{
    "127.0.0.1:1981": 10
}
# 替换 Service 的 upstream nodes
$ curl http://127.0.0.1:9080/apisix/admin/services/201/upstream/nodes -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "127.0.0.1:1982": 1
}'
HTTP/1.1 200 OK
...
执行成功后，upstream nodes 将不保留原来的数据，整个更新为：
{
    "127.0.0.1:1982": 1
}

应答参数

目前是直接返回与 etcd 交互后的结果。

Back to TOC

Consumer

地址：/apisix/admin/consumers/{username}

说明：Consumer 是某类服务的消费者，需与用户认证体系配合才能使用。Consumer 使用 username 作为唯一标识，只支持使用 HTTP PUT 方法创建 Consumer。

请求方法

body 请求参数

consumer 对象 json 配置内容：

{
    "plugins": {},          # 指定 consumer 绑定的插件
    "username": "name",     # 必填
    "desc": "hello world"   # consumer 描述
}

绑定认证插件有些特别，当它需要与 consumer 联合使用时，需要提供用户名、密码等信息；另一方面，当它与 route/service 绑定时，是不需要任何参数的。因为这时候是根据用户请求数据来反向推出用户对应的是哪个 consumer

示例：

# 创建 Consumer ，指定认证插件 key-auth ，并开启特定插件 limit-count
$ curl http://127.0.0.1:9080/apisix/admin/consumers  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "auth-one"
        },
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 503,
            "key": "remote_addr"
        }
    }
}'
HTTP/1.1 200 OK
Date: Thu, 26 Dec 2019 08:17:49 GMT
...
{"node":{"value":{"username":"jack","plugins":{"key-auth":{"key":"auth-one"},"limit-count":{"time_window":60,"count":2,"rejected_code":503,"key":"remote_addr","policy":"local"}}},"createdIndex":64,"key":"\/apisix\/consumers\/jack","modifiedIndex":64},"prevNode":{"value":"{\"username\":\"jack\",\"plugins\":{\"key-auth\":{\"key\":\"auth-one\"},\"limit-count\":{\"time_window\":60,\"count\":2,\"rejected_code\":503,\"key\":\"remote_addr\",\"policy\":\"local\"}}}","createdIndex":63,"key":"\/apisix\/consumers\/jack","modifiedIndex":63},"action":"set"}

从 v2.2 版本之后，同一个 consumer 可以绑定多个认证插件。

应答参数

目前是直接返回与 etcd 交互后的结果。

Back to TOC

Upstream

地址：/apisix/admin/upstreams/{id}

说明：Upstream 是虚拟主机抽象，对给定的多个服务节点按照配置规则进行负载均衡。Upstream 的地址信息可以直接配置到 Route（或 Service) 上，当 Upstream 有重复时，就需要用“引用”方式避免重复了。

请求方法

body 请求参数

APISIX 的 Upstream 除了基本的负载均衡算法选择外，还支持对上游做主被动健康检查、重试等逻辑，具体看下面表格。

type 可以是以下的一种：

• roundrobin: 带权重的 roundrobin
• chash: 一致性哈希
• ewma: 选择延迟最小的节点，计算细节参考 https://en.wikipedia.org/wiki/EWMA_chart
• least_conn: 选择 (active_conn + 1) / weight 最小的节点。注意这里的 active connection 概念跟 Nginx 的相同：它是当前正在被请求使用的连接。
• 用户自定义的 balancer，需要可以通过 require("apisix.balancer.your_balancer") 来加载。

hash_on 比较复杂，这里专门说明下：

1. 设为 vars 时，key 为必传参数，目前支持的 Nginx 内置变量有 uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_***，其中 arg_*** 是来自 URL 的请求参数，Nginx 变量列表
2. 设为 header 时，key 为必传参数，其值为自定义的 header name，即 “http_key“
3. 设为 cookie 时，key 为必传参数，其值为自定义的 cookie name，即 “cookie_key“。请注意 cookie name 是区分大小写字母的。例如：”cookie_x_foo” 与 “cookie_X_Foo” 表示不同的 cookie。
4. 设为 consumer 时，key 不需要设置。此时哈希算法采用的 key 为认证通过的 consumer_name。
5. 如果指定的 hash_on 和 key 获取不到值时，就是用默认值：remote_addr。

以下特性需要 APISIX 运行于 APISIX-Base：

scheme 可以设置成 tls，表示 “TLS over TCP”。

tls.client_cert/key 可以用来跟上游进行 mTLS 通信。 他们的格式和 SSL 对象的 cert 和 key 一样。

tls.client_cert_id 可以用来指定引用的 SSL 对象。只有当 SSL 对象的 type 字段为 client 时才能被引用，否则请求会被 APISIX 拒绝。另外，SSL 对象中只有 cert和key 会被使用。

keepalive_pool 允许 upstream 对象有自己单独的连接池。 它下属的字段，比如 requests，可以用了配置上游连接保持的参数。 这个特性需要 APISIX 运行于 APISIX-Base。

upstream 对象 json 配置内容：

{
    "id": "1",                  # id
    "retries": 1,               # 请求重试次数
    "timeout": {                # 设置连接、发送消息、接收消息的超时时间，每项都为 15 秒
        "connect":15,
        "send":15,
        "read":15
    },
    "nodes": {"host:80": 100},  # 上游机器地址列表，格式为`地址 + 端口`
                                # 等价于 "nodes": [ {"host":"host", "port":80, "weight": 100} ],
    "type":"roundrobin",
    "checks": {},               # 配置健康检查的参数
    "hash_on": "",
    "key": "",
    "name": "upstream-xxx",     # upstream 名称
    "desc": "hello world",      # upstream 描述
    "scheme": "http"            # 跟上游通信时使用的 scheme，默认是 `http`
}

具体示例：

示例一：创建一个 upstream 并对 nodes 的数据做修改

# 创建一个 upstream
$ curl http://127.0.0.1:9080/apisix/admin/upstreams/100  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -i -X PUT -d '
{
    "type":"roundrobin",
    "nodes":{
        "127.0.0.1:1980": 1
    }
}'
HTTP/1.1 201 Created
...
# 给 Upstream 增加一个 node
$ curl http://127.0.0.1:9080/apisix/admin/upstreams/100 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "nodes": {
        "127.0.0.1:1981": 1
    }
}'
HTTP/1.1 200 OK
...
执行成功后，nodes 将更新为：
{
    "127.0.0.1:1980": 1,
    "127.0.0.1:1981": 1
}
# 给 Upstream 更新一个 node 的权重
$ curl http://127.0.0.1:9080/apisix/admin/upstreams/100 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "nodes": {
        "127.0.0.1:1981": 10
    }
}'
HTTP/1.1 200 OK
...
执行成功后，nodes 将更新为：
{
    "127.0.0.1:1980": 1,
    "127.0.0.1:1981": 10
}
# 给 Upstream 删除一个 node
$ curl http://127.0.0.1:9080/apisix/admin/upstreams/100 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "nodes": {
        "127.0.0.1:1980": null
    }
}'
HTTP/1.1 200 OK
...
执行成功后，nodes 将更新为：
{
    "127.0.0.1:1981": 10
}
# 替换 Upstream 的  nodes
$ curl http://127.0.0.1:9080/apisix/admin/upstreams/100/nodes -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PATCH -i -d '
{
    "127.0.0.1:1982": 1
}'
HTTP/1.1 200 OK
...
执行成功后，nodes 将不保留原来的数据，整个更新为：
{
    "127.0.0.1:1982": 1
}

示例二：将客户端请求代理到上游 https 服务

1、创建 route 并配置 upstream 的 scheme 为 https。

$ curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/get",
    "upstream": {
        "type": "roundrobin",
        "scheme": "https",
        "nodes": {
            "httpbin.org:443": 1
        }
    }
}'

执行成功后，请求与上游通信时的 scheme 将为 https。

2、 发送请求进行测试。

$ curl http://127.0.0.1:9080/get
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Host": "127.0.0.1",
    "User-Agent": "curl/7.29.0",
    "X-Amzn-Trace-Id": "Root=1-6058324a-0e898a7f04a5e95b526bb183",
    "X-Forwarded-Host": "127.0.0.1"
  },
  "origin": "127.0.0.1",
  "url": "https://127.0.0.1/get"
}

请求成功，表示代理上游 https 生效了。

注意：

节点可以配置自己的优先级。只有在高优先级的节点不可用或者尝试过，才会访问一个低优先级的节点。

由于默认的优先级是 0，我们可以给一些节点配置负数的优先级来作为备份。 举个例子：

{
    "uri": "/hello",
    "upstream": {
        "type": "roundrobin",
        "nodes": [
            {"host": "127.0.0.1", "port": 1980, "weight": 2000},
            {"host": "127.0.0.1", "port": 1981, "weight": 1, "priority": -1}
        ],
        "checks": {
            "active": {
                "http_path": "/status",
                "healthy": {
                    "interval": 1,
                    "successes": 1
                },
                "unhealthy": {
                    "interval": 1,
                    "http_failures": 1
                }
            }
        }
    }
}

节点 127.0.0.2 只有在 127.0.0.1 不可用或者尝试过之后才会被访问。 所以它是 127.0.0.1 的备份。

应答参数

目前是直接返回与 etcd 交互后的结果。

Back to TOC

SSL

地址：/apisix/admin/ssl/{id}

说明：SSL.

请求方法

body 请求参数

ssl 对象 json 配置内容：

{
    "id": "1",          # id
    "cert": "cert",     # 证书
    "key": "key",       # 私钥
    "snis": ["t.com"]   # HTTPS 握手时客户端发送的 SNI
}

更多的配置示例见 证书。

Back to TOC

Global Rule

地址：/apisix/admin/global_rules/{id}

说明：设置全局运行的插件。这一类插件在所有路由级别的插件之前优先运行。

请求方法

body 请求参数

Back to TOC

Plugin Config

地址：/apisix/admin/plugin_configs/{id}

说明：配置一组可以在路由间复用的插件。

请求方法

body 请求参数

Back to TOC

Plugin Metadata

地址：/apisix/admin/plugin_metadata/{plugin_name}

说明: 插件元数据。

请求方法

body 请求参数

一个根据插件 ({plugin_name}) 的 metadata_schema 定义的数据结构的 json object 。

例子：

$ curl http://127.0.0.1:9080/apisix/admin/plugin_metadata/example-plugin  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -i -X PUT -d '
{
    "skey": "val",
    "ikey": 1
}'
HTTP/1.1 201 Created
Date: Thu, 26 Dec 2019 04:19:34 GMT
Content-Type: text/plain

Back to TOC

Plugin

地址：/apisix/admin/plugins/{plugin_name}

说明: 插件

请求方法

body 请求参数

获取插件 ({plugin_name}) 数据结构的 json object 。

例子：

$ curl "http://127.0.0.1:9080/apisix/admin/plugins/list" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1'
["zipkin","request-id",...]
$ curl "http://127.0.0.1:9080/apisix/admin/plugins/key-auth" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1'
{"properties":{"disable":{"type":"boolean"}},"additionalProperties":false,"type":"object"}

地址：/apisix/admin/plugins?all=true

说明: 所有插件的所有属性，每个插件包括 name, priority, type, schema, consumer_schema 和 version。

默认情况下，这个接口只返回 http 插件。如果你需要 stream 插件，需要用 /apisix/admin/plugins?all=true&subsystem=stream。

请求方法

请求参数

Back to TOC

Stream Route

API：/apisix/admin/stream_routes/{id}

Description：Stream Route 是用于 TCP/UDP 动态代理的路由。参见 TCP/UDP 动态代理 一节。

请求方法

body 请求参数

点击 此处，了解更多有关过滤器如何工作的信息。

Back to TOC