Admin API

描述

Admin API 是一组用于配置 Apache APISIX 路由、上游、服务、SSL 证书等功能的 RESTful API。

你可以通过 Admin API 来获取、创建、更新以及删除资源。同时得益于 APISIX 的热加载能力，资源配置完成后 APISIX 将会自动更新配置，无需重启服务。如果你想要了解其工作原理，请参考 Architecture Design。

相关配置

当 APISIX 启动时，Admin API 默认情况下将会监听 9180 端口，并且会占用前缀为 /apisix/admin 的 API。

因此，为了避免你设计的 API 与 /apisix/admin 冲突，你可以通过修改配置文件 /conf/config.yaml 中的配置修改默认监听端口。

APISIX 支持设置 Admin API 的 IP 访问白名单，防止 APISIX 被非法访问和攻击。你可以在 ./conf/config.yaml 文件中的 deployment.admin.allow_admin 选项中，配置允许访问的 IP 地址。

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

deployment:
    admin:
        admin_key:
        - name: admin
            key: your-admin-key  # 设置安全的 Admin API Key；如果留空，APISIX 会在初始化时自动生成并写回此文件
            role: admin
        allow_admin:                    # http://nginx.org/en/docs/http/ngx_http_access_module.html#allow
            - 127.0.0.0/24
        admin_listen:
            ip: 0.0.0.0                 # Admin API 监听的 IP，如果不设置，默认为“0.0.0.0”。
            port: 9180                  # Admin API 监听的 端口，必须使用与 node_listen 不同的端口。

使用环境变量

要通过环境变量进行配置，可以使用 ${{VAR}} 语法。例如：

deployment:
  admin:
    admin_key:
    - name: admin
      key: ${{ADMIN_KEY}}
      role: admin
    allow_admin:
    - 127.0.0.0/24
    admin_listen:
      ip: 0.0.0.0
      port: 9180

然后在 make init 之前运行 export ADMIN_KEY=$your_admin_key.

如果找不到配置的环境变量，将抛出错误。

此外，如果要在未设置环境变量时使用默认值，请改用 ${{VAR:=default_value}}。例如：

deployment:
  admin:
    admin_key:
    - name: admin
      key: ${{ADMIN_KEY:=your-admin-key}}
      role: admin
    allow_admin:
    - 127.0.0.0/24
    admin_listen:
      ip: 0.0.0.0
      port: 9180

首先查找环境变量 ADMIN_KEY，如果该环境变量不存在，它将使用你在配置中提供的兜底值。

您还可以在 yaml 键中指定环境变量。这在 standalone 模式 中特别有用，您可以在其中指定上游节点，如下所示：

routes:
  -
    uri: "/test"
    upstream:
      nodes:
        "${{HOST_IP}}:${{PORT}}": 1
      type: roundrobin
#END

强制删除

默认情况下，Admin API 会检查资源间的引用关系，将会拒绝删除正在使用中的资源。

可以通过在删除请求中添加请求参数 force=true 来进行强制删除，例如：

admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')

$ curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -H "X-API-KEY: $admin_key" -X PUT -d '{
    "nodes": {
        "127.0.0.1:8080": 1
    },
    "type": "roundrobin"
}'
$ curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d '{
    "uri": "/*",
    "upstream_id": 1
}'
{"value":{"priority":0,"upstream_id":1,"uri":"/*","create_time":1689038794,"id":"1","status":1,"update_time":1689038916},"key":"/apisix/routes/1"}

$ curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -H "X-API-KEY: $admin_key" -X DELETE
{"error_msg":"can not delete this upstream, route [1] is still using it now"}
$ curl "http://127.0.0.1:9180/apisix/admin/upstreams/1?force=anyvalue" -H "X-API-KEY: $admin_key" -X DELETE
{"error_msg":"can not delete this upstream, route [1] is still using it now"}
$ curl "http://127.0.0.1:9180/apisix/admin/upstreams/1?force=true" -H "X-API-KEY: $admin_key" -X DELETE
{"deleted":"1","key":"/apisix/upstreams/1"}

v3 版本新功能

在 APISIX v3 版本中，Admin API 支持了一些不向下兼容的新特性，比如支持新的响应体格式、支持分页查询、支持过滤资源等。

支持新的响应体格式

APISIX 在 v3 版本对响应体做了以下调整：

• 移除旧版本响应体中的 action 字段；
• 调整获取资源列表时的响应体结构，新的响应体结构示例如下：

返回单个资源：

    {
    "modifiedIndex": 2685183,
    "value": {
        "id": "1",
        ...
    },
    "key": "/apisix/routes/1",
    "createdIndex": 2684956
    }

返回多个资源：

    {
    "list": [
        {
        "modifiedIndex": 2685183,
        "value": {
            "id": "1",
            ...
        },
        "key": "/apisix/routes/1",
        "createdIndex": 2684956
        },
        {
        "modifiedIndex": 2685163,
        "value": {
            "id": "2",
            ...
        },
        "key": "/apisix/routes/2",
        "createdIndex": 2685163
        }
    ],
    "total": 2
    }

支持分页查询

获取资源列表时支持分页查询，目前支持分页查询的资源如下：

• Consumer
• Consumer Group
• Global Rules
• Plugin Config
• Protos
• Route
• Service
• SSL
• Stream Route
• Upstream

参数如下：

示例如下：

curl "http://127.0.0.1:9180/apisix/admin/routes?page=1&page_size=10" \
-H "X-API-KEY: $admin_key" -X GET

{
  "total": 1,
  "list": [
    {
      ...
    }
  ]
}

支持过滤资源

在 APISIX v3 版本中，在获取资源列表时，你可以使用 name、label 和 uri 参数过滤资源。支持参数如下：

以下示例将返回一个路由列表，该路由列表中的所有路由需要满足以下条件：路由的 name 包含字符串 test；uri 包含字符串 foo；对路由的 label 没有限制，因为 label 为空字符串。

curl 'http://127.0.0.1:9180/apisix/admin/routes?name=test&uri=foo&label=' \
-H "X-API-KEY: $admin_key" -X GET

返回结果：

{
  "total": 1,
  "list": [
    {
      ...
    }
  ]
}

支持引用过滤资源

在获取资源列表时，你可以使用 filter 参数过滤资源。

它以以下方式编码：

filter=escape_uri(key1=value1&key2=value2)

以下是一个使用 service_id 进行路由列表过滤的例子。当同时设置了多个过滤条件，结果将为它们的交集。

curl 'http://127.0.0.1:9180/apisix/admin/routes?filter=service_id%3D1' \
-H "X-API-KEY: $admin_key" -X GET

{
  "total": 1,
  "list": [
    {
      ...
    }
  ]
}

Route

Route 也称之为路由，可以通过定义一些规则来匹配客户端的请求，然后根据匹配结果加载并执行相应的插件，并把请求转发给到指定 Upstream（上游）。

请求地址

路由资源请求地址：/apisix/admin/routes/{id}?ttl=0

请求方法

URI 请求参数

body 请求参数

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:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $admin_key" -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:9180/apisix/admin/routes/2?ttl=60' \
  -H "X-API-KEY: $admin_key" -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
  ...

• 在路由中新增一个上游节点：

  curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "upstream": {
          "nodes": {
              "127.0.0.1:1981": 1
          }
      }
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，上游节点将更新为：

  {
      "127.0.0.1:1980": 1,
      "127.0.0.1:1981": 1
  }

• 更新路由中上游节点的权重：

  curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "upstream": {
          "nodes": {
              "127.0.0.1:1981": 10
          }
      }
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，上游节点将更新为：

  {
      "127.0.0.1:1980": 1,
      "127.0.0.1:1981": 10
  }

• 从路由中删除一个上游节点：

  curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $admin_key" -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:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '{
      "methods": ["GET", "POST"]
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，methods 将不保留原来的数据，将更新为：

  ["GET", "POST"]

• 使用 sub path 更新路由中的上游节点：

  curl http://127.0.0.1:9180/apisix/admin/routes/1/upstream/nodes \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "127.0.0.1:1982": 1
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，nodes 将不保留原来的数据，整个更新为：

  {
      "127.0.0.1:1982": 1
  }

• 使用 sub path 更新路由中的 methods：

  curl http://127.0.0.1:9180/apisix/admin/routes/1/methods \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '["POST", "DELETE", "PATCH"]'

  HTTP/1.1 200 OK
  ...

  执行成功后，methods 将不保留原来的数据，更新为：

  ["POST", "DELETE", "PATCH"]

• 禁用路由

  curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "status": 0
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，status 将更新为：

  {
      "status": 0
  }

• 启用路由

  curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "status": 1
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，status 将更新为：

  {
      "status": 1
  }

应答参数

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

Service

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

请求地址

服务资源请求地址：/apisix/admin/services/{id}

请求方法

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:9180/apisix/admin/services/201  \
  -H "X-API-KEY: $admin_key" -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 中添加一个上游节点：

  curl http://127.0.0.1:9180/apisix/admin/services/201 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "upstream": {
          "nodes": {
              "127.0.0.1:1981": 1
          }
      }
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，上游节点将更新为：

  {
      "127.0.0.1:1980": 1,
      "127.0.0.1:1981": 1
  }

• 更新一个上游节点的权重：

  curl http://127.0.0.1:9180/apisix/admin/services/201 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "upstream": {
          "nodes": {
              "127.0.0.1:1981": 10
          }
      }
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，上游节点将更新为：

  {
      "127.0.0.1:1980": 1,
      "127.0.0.1:1981": 10
  }

• 删除 Service 中的一个上游节点：

  curl http://127.0.0.1:9180/apisix/admin/services/201 \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "upstream": {
          "nodes": {
              "127.0.0.1:1980": null
          }
      }
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，上游节点将更新为：

  {
      "127.0.0.1:1981": 10
  }

• 替换 Service 的上游节点：

  curl http://127.0.0.1:9180/apisix/admin/services/201/upstream/nodes \
  -H "X-API-KEY: $admin_key" -X PATCH -i -d '
  {
      "127.0.0.1:1982": 1
  }'

  HTTP/1.1 200 OK
  ...

  执行成功后，上游节点不再保留原来的数据，将更新为：

  {
      "127.0.0.1:1982": 1
  }

应答参数

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

Consumer

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

请求地址

Consumer 资源请求地址：/apisix/admin/consumers/{username}

请求方法

body 请求参数

Consumer 对象 JSON 配置示例：

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

当认证插件与 Consumer 一起使用时，需要提供用户名、密码等信息；当认证插件与 Route 或 Service 绑定时，则不需要任何参数，因为此时 APISIX 是根据用户请求数据来判断用户对应的是哪个 Consumer。

使用示例

• 创建 Consumer，并指定认证插件 key-auth，并开启指定插件 limit-count：

  curl http://127.0.0.1:9180/apisix/admin/consumers  \
  -H "X-API-KEY: $admin_key" -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
  ...
  
  {"key":"\/apisix\/consumers\/jack","value":{"username":"jack","update_time":1666260780,"plugins":{"limit-count":{"key_type":"var","count":2,"rejected_code":503,"show_limit_quota_header":true,"time_window":60,"key":"remote_addr","allow_degradation":false,"policy":"local"},"key-auth":{"key":"auth-one"}},"create_time":1666260780}}

应答参数

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

Credential

Credential 用以存放 Consumer 的认证凭证。当需要为 Consumer 配置多个凭证时，可以使用 Credential。

请求地址

Credential 资源请求地址：/apisix/admin/consumers/{username}/credentials/{credential_id}

请求方法

body 请求参数

Credential 对象 JSON 配置示例：

{
    "plugins": {
      "key-auth": {
        "key": "auth-one"
      }
    },
    "desc": "hello world"
}

使用示例

前提：已创建 Consumer jack。

创建 Credential，并启用认证插件 key-auth：

curl http://127.0.0.1:9180/apisix/admin/consumers/jack/credentials/auth-one  \
-H "X-API-KEY: $admin_key" -X PUT -i -d '
{
    "plugins": {
        "key-auth": {
            "key": "auth-one"
        }
    }
}'

HTTP/1.1 200 OK
Date: Thu, 26 Dec 2019 08:17:49 GMT
...

{"key":"\/apisix\/consumers\/jack\/credentials\/auth-one","value":{"update_time":1666260780,"plugins":{"key-auth":{"key":"auth-one"}},"create_time":1666260780}}

Upstream

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

请求地址

Upstream 资源请求地址：/apisix/admin/upstreams/{id}

请求方法

body 请求参数

APISIX 的 Upstream 除了基本的负载均衡算法选择外，还支持对上游做主被动健康检查、重试等逻辑。详细信息如下：

type 详细信息如下：

• roundrobin: 带权重的 Round Robin。
• chash: 一致性哈希。
• ewma: 选择延迟最小的节点，请参考 EWMA_chart。
• least_conn: 选择 (active_conn + 1) / weight 最小的节点。此处的 active connection 概念跟 NGINX 的相同，它是当前正在被请求使用的连接。
• 用户自定义的 balancer，需要可以通过 require("apisix.balancer.your_balancer") 来加载。

hash_on 详细信息如下：

• 设为 vars 时，key 为必传参数，目前支持的 NGINX 内置变量有 uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_***，其中 arg_*** 是来自 URL 的请求参数。详细信息请参考 NGINX 变量列表。
• 设为 header 时，key 为必传参数，其值为自定义的 Header name，即 “http_key”。
• 设为 cookie 时，key 为必传参数，其值为自定义的 cookie name，即 “cookie_key”。请注意 cookie name 是区分大小写字母的。例如：cookie_x_foo 与 cookie_X_Foo 表示不同的 cookie。
• 设为 consumer 时，key 不需要设置。此时哈希算法采用的 key 为认证通过的 consumer_name。

APISIX 支持两种不同的方式来代理 WebSocket 连接，二者不能混用：

• Route 或 Service 级别的 enable_websocket，配合 http/https 的 Upstream scheme。这是纯粹的协议升级：101 Switching Protocols 握手完成后，由 nginx 自身的 proxy_pass 转发原始 TCP 流，没有任何插件 phase 能看到单独的 WebSocket 帧。
• Upstream scheme: ws 或 scheme: wss。APISIX 会自己双向解析并代理 WebSocket 帧，插件可以通过 ws_handshake、ws_client_frame、ws_upstream_frame、ws_close 这几个 phase 在帧的转发过程中读取或改写它们，具体用法参考插件开发指南的 “extra phase” 一节。如果 Route 或 Service 所属的 Upstream 使用了这个 scheme，enable_websocket 会被忽略，因为连接根本不会走到它所配置的那条 proxy_pass 路径。

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

• 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 会被使用。

• tls.verify 设置为 true 时校验上游返回的证书；不设置时沿用 nginx 的行为，即只有开启了 proxy_ssl_verify 才会校验。校验使用 tls.ca_certs 中的 CA 证书，未设置 tls.ca_certs 时使用 config.yaml 中的 ssl_trusted_certificate：

  {
    "scheme": "https",
    "type": "roundrobin",
    "nodes": {
      "127.0.0.1:8443": 1
    },
    "tls": {
      "verify": true,
      "ca_certs": ["<content of ca.crt>"]
    }
  }

• keepalive_pool 允许 Upstream 有自己单独的连接池。它下属的字段，比如 requests，可以用于配置上游连接保持的参数。

• warm_up_conf 为 roundrobin 类型的 Upstream 开启节点慢启动。节点是否为新节点由网关根据自己观察到的节点集合判断，每次爬坡的起点记录在本地的 upstream-slow-start 共享字典中：

  • 网关首次为 Upstream 构建负载均衡器时已有的节点视为已完成预热，开启 warm_up_conf 时 Upstream 已有的节点同样如此。
  • 之后新增的节点从 min_weight_percent 开始，在 slow_start_time_seconds 内逐步恢复到配置的权重。被健康检查挡在负载均衡器之外的节点，从它首次可用时开始爬坡。
  • 节点离开 Upstream 后在 slow_start_time_seconds 内回来，会继续原来的爬坡；更晚回来，或被健康检查排除超过该时长，会重新开始爬坡。
  • 每个 APISIX 实例独立计时，起点为该实例观察到节点的时刻。
  • warm_up_conf 仅支持节点优先级一致的 roundrobin 类型 Upstream，traffic-split 插件中的 Upstream 每请求重建，不允许配置。与其他只对 HTTP 生效的 Upstream 字段一样，该字段在 stream route 使用的 Upstream 上会被忽略。爬坡只在节点之间调整流量：单节点 Upstream，或所有节点都是新节点时，请求仍会全部发往这些节点。

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 的数据进行修改

1. 创建 Upstream：

   curl http://127.0.0.1:9180/apisix/admin/upstreams/100  \
   -H "X-API-KEY: $admin_key" -i -X PUT -d '
   {
       "type":"roundrobin",
       "nodes":{
           "127.0.0.1:1980": 1
       }
   }'

   HTTP/1.1 201 Created
   ...

2. 在 Upstream 中添加一个节点：

   curl http://127.0.0.1:9180/apisix/admin/upstreams/100 \
   -H "X-API-KEY: $admin_key" -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
   }

3. 更新 Upstream 中单个节点的权重：

   curl http://127.0.0.1:9180/apisix/admin/upstreams/100 \
   -H "X-API-KEY: $admin_key" -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
   }

4. 删除 Upstream 中的一个节点：

   curl http://127.0.0.1:9180/apisix/admin/upstreams/100 \
   -H "X-API-KEY: $admin_key" -X PATCH -i -d '
   {
       "nodes": {
           "127.0.0.1:1980": null
       }
   }'

   HTTP/1.1 200 OK
   ...

   执行成功后，nodes 将更新为：

   {
       "127.0.0.1:1981": 10
   }

5. 更新 Upstream 的 nodes：

   curl http://127.0.0.1:9180/apisix/admin/upstreams/100/nodes \
   -H "X-API-KEY: $admin_key" -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:9180/apisix/admin/routes/1 \
   -H "X-API-KEY: $admin_key" -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 生效了。

   :::tip 提示

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

   :::

   由于上游节点的默认优先级是 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 交互后的结果。

SSL

你可以使用该资源创建 SSL 证书。

请求地址

SSL 资源请求地址：/apisix/admin/ssls/{id}

请求方法

body 请求参数

SSL 对象 JSON 配置示例：

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

更多的配置示例，请参考证书。

Global Rules

Global Rule 可以设置全局运行的插件，设置为全局规则的插件将在所有路由级别的插件之前优先运行。

请求地址

Global Rule 资源请求地址：/apisix/admin/global_rules/{id}

请求方法

body 请求参数

Consumer Group

你可以使用该资源配置一组可以在 Consumer 间复用的插件。

请求地址

Consumer Group 资源请求地址：/apisix/admin/consumer_groups/{id}

请求方法

body 请求参数

Plugin Config

你可以使用 Plugin Config 资源创建一组可以在路由间复用的插件。

请求地址

Plugin Config 资源请求地址：/apisix/admin/plugin_configs/{id}

请求方法

body 请求参数

Plugin Metadata

你可以使用 Plugin Metadata 资源配置插件元数据。

请求地址

Plugin Config 资源请求地址：/apisix/admin/plugin_metadata/{plugin_name}

请求方法

body 请求参数

根据插件 ({plugin_name}) 的 metadata_schema 定义的数据结构的 JSON 对象。

使用示例

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/example-plugin  \
-H "X-API-KEY: $admin_key" -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

Plugin

你可以通过该资源获取插件列表。

请求地址

Plugin 资源请求地址：/apisix/admin/plugins/{plugin_name}

请求参数

可以在子系统上过滤插件，以便在通过查询参数传递的子系统中搜索 ({plugin_name})

请求方法

使用示例

获取插件  ({plugin_name})  数据结构的 JSON 对象。

• 获取插件列表

  curl "http://127.0.0.1:9180/apisix/admin/plugins/list" \
  -H 'X-API-KEY: your-admin-key'

  ["zipkin","request-id",...]

• 获取指定插件的属性

  curl "http://127.0.0.1:9180/apisix/admin/plugins/key-auth?subsystem=http" \
  -H 'X-API-KEY: your-admin-key'

  {"$comment":"this is a mark for our injected plugin schema","properties":{"header":{"default":"apikey","type":"string"},"hide_credentials":{"default":false,"type":"boolean"},"_meta":{"properties":{"filter":{"type":"array","description":"filter determines whether the plugin needs to be executed at runtime"},"disable":{"type":"boolean"},"error_response":{"oneOf":[{"type":"string"},{"type":"object"}]},"priority":{"type":"integer","description":"priority of plugins by customized order"}},"type":"object"},"query":{"default":"apikey","type":"string"}},"type":"object"}

Stream Route

Stream Route 是用于 TCP/UDP 动态代理的路由。详细信息请参考 TCP/UDP 动态代理。

请求地址

Plugin 资源请求地址：/apisix/admin/stream_routes/{id}

请求方法

body 请求参数

你可以查看 Stream Proxy 了解更多过滤器的信息。

Secret

Secret 指的是 Secrets Management（密钥管理），可以使用任何支持的密钥管理器，例如 vault。

请求地址

Secret 资源请求地址：/apisix/admin/secrets/{secretmanager}/{id}

请求方法

body 请求参数

当 Secret Manager 是 Vault 时

配置示例：

{
    "uri": "https://localhost/vault",
    "prefix": "/apisix/kv",
    "token": "343effad"
}

使用示例：

curl -i http://127.0.0.1:9180/apisix/admin/secrets/vault/test2 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "uri": "http://xxx/get",
    "prefix" : "apisix",
    "token" : "apisix"
}'

HTTP/1.1 200 OK
...

{"key":"\/apisix\/secrets\/vault\/test2","value":{"id":"vault\/test2","token":"apisix","prefix":"apisix","update_time":1669625828,"create_time":1669625828,"uri":"http:\/\/xxx\/get"}}

当 Secret Manager 是 AWS 时

配置示例：

{
    "endpoint_url": "http://127.0.0.1:4566",
    "region": "us-east-1",
    "access_key_id": "access",
    "secret_access_key": "secret",
    "session_token": "token"
}

使用示例：

curl -i http://127.0.0.1:9180/apisix/admin/secrets/aws/test3 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "endpoint_url": "http://127.0.0.1:4566",
    "region": "us-east-1",
    "access_key_id": "access",
    "secret_access_key": "secret",
    "session_token": "token"
}'

HTTP/1.1 200 OK
...

{"value":{"create_time":1726069970,"endpoint_url":"http://127.0.0.1:4566","region":"us-east-1","access_key_id":"access","secret_access_key":"secret","id":"aws/test3","update_time":1726069970,"session_token":"token"},"key":"/apisix/secrets/aws/test3"}

当 Secret Manager 是 GCP 时

配置示例：

{
    "auth_config" : {
        "client_email": "email@apisix.iam.gserviceaccount.com",
        "private_key": "private_key",
        "project_id": "apisix-project",
        "token_uri": "https://oauth2.googleapis.com/token",
        "entries_uri": "https://secretmanager.googleapis.com/v1",
        "scope": ["https://www.googleapis.com/auth/cloud-platform"]
    }
}

使用示例：

curl -i http://127.0.0.1:9180/apisix/admin/secrets/gcp/test4 \
-H "X-API-KEY: $admin_key" -X PUT -d '
{
    "auth_config" : {
        "client_email": "email@apisix.iam.gserviceaccount.com",
        "private_key": "private_key",
        "project_id": "apisix-project",
        "token_uri": "https://oauth2.googleapis.com/token",
        "entries_uri": "https://secretmanager.googleapis.com/v1",
        "scope": ["https://www.googleapis.com/auth/cloud-platform"]
    }
}'

HTTP/1.1 200 OK
...

{"value":{"id":"gcp/test4","ssl_verify":true,"auth_config":{"token_uri":"https://oauth2.googleapis.com/token","scope":["https://www.googleapis.com/auth/cloud-platform"],"entries_uri":"https://secretmanager.googleapis.com/v1","client_email":"email@apisix.iam.gserviceaccount.com","private_key":"private_key","project_id":"apisix-project"},"create_time":1726070161,"update_time":1726070161},"key":"/apisix/secrets/gcp/test4"}

应答参数

当前的响应是从 etcd 返回的。