标签归档:Openresty

Kong 1.4 发布!自动检测Cassandra Topology 更改,自定义Host Header以及更多功能!

原文地址:https://konghq.com/blog/kong-gateway-1-4-released-auto-detect-cassandra-topology-changes-custom-host-header-much/

我们很高兴地宣布1.4系列的第一个版本已经发布! 我们的工程团队和出色的社区成员在此版本中添加了许多新功能,改进和修复。

请阅读以下内容,了解Kong Gateway 1.4中最相关的更改以及如何充分利用这些新增功能。 有关完整的详细信息,请参阅更改日志;有关如何从以前的Kong版本进行升级的说明,请参阅升级路径

自动检测Cassandra Topology 更改

从Kong Gateway 1.4开始,将自动检测对Apache Cassandra群集拓扑所做的任何更改,从而避免Kong重新启动。

如何利用此新功能:

新的配置cassandra_refresh_frequency设置在检查Cassandra集群拓扑结构更改之前,Kong必须等待多长时间。默认频率是每60秒检查一次,但是可以根据需要增加、减少甚至禁用这个值。

上游的Hostname属性

Kong中定义的任何上游现在都可以使用一个名为hostname的可选属性,该属性定义在通过Kong服务器代理连接时将使用的Host header。

主要优点:

服务器通常会监听与解析名称不同的服务器名称,并且此新属性可以保证Kong在代理连接和积极检查主机的运行状况时将使用正确的名称。

DAO属性的新变更

新的属性转换已添加到DAO模式中,使开发人员能够添加在插入或更新数据库条目时运行的函数

新的状态接口

通过新的状态接口,插件可以将端点添加到已经存在的/status端点,从而公开不敏感的健康数据,从而避免公开Kong的管理API。

主要优点

  • 用户可以同时公开Kong的健康数据并保护Kong的Admin API。
  • 对于使用禁用的管理界面运行的Kong节点,执行基于HTTP的运行状况检查更加容易。

Kong Gateway 1.4中的其他新功能

新的Admin API响应headerX-Kong-Admin-Latency

  • 这个新的响应header报告了对Kong的Admin API的每个请求处理了多长时间。

新的配置选项router_update_frequency

  • 这个新的配置选项允许设置检查路由器和插件更改的频率。
  • 这样可以避免在频繁更改Kong路由或插件时性能下降。
  • 此选项使管理员可以选择延迟路由器和插件配置更改的可用性,还是增加数据库负载。

限速插件中的Service-level 支持

  • 除了使用者,凭证和IP级别外,限速插件现在还具有服务级别的支持。

Kong Gateway 1.4中的其他改进和错误修复

Kong Gateway 1.4还改善了限速插件内存的使用,使用共享字典的TTL终止了其local策略计数器,以避免在内存中保留不必要的计数器。

此版本中存在一些重要的错误修复,例如服务网格弃用的开始,它将被替换为Kuma(kuma.io)向前发展。 已知服务网格会导致向上游的HTTPS请求忽略proxy_ssl *指令,因此在Kong Gateway的下一个主要版本中将停止使用该服务网格。 在此版本中,默认情况下禁用此功能,以避免出现此问题,并且仍可以使用新的配置选项service_mesh启用它。

另一个相关的修复与使用日志插件记录NGINX产生的错误有关,该错误过去曾错误地将某些请求属性报告为请求方法,并且现在可以正常工作。

我们还解决了一个问题,即在删除所有Kong workers时,目标不能在所有Kong员工中正确更新的情况下,在频繁使用情况下,将流量与这些被删除目标进行了平衡。

与往常一样,此处提供Kong Gateway 1.4的文档。 此外,我们将在后续帖子和社区电话中讨论1.4中的关键功能,敬请期待!

感谢我们的用户,贡献者和核心维护者社区,感谢您对Kong开源平台的持续支持。

请尝试一下Kong Gateway 1.4,并确保让我们知道您的想法

Kong社区

像往常一样,随时在我们的社区论坛Kong Nation上提问。 从您的反馈中吸取教训,将使我们能够更好地了解关键任务用例并不断改进Kong。

Happy Konging!

在 CentOS 安装 Kong

安装包

首先下载配置的相应软件包:

企业试用用户应从其欢迎电子邮件中下载其包,并在步骤1之后将其许可保存到/etc/kong/license.json

YUM Repositories

你也可以通过YUM安装Kong;按照下面“Set Me Up”部分中的说明进行操作。

注意:确保生成的.repo文件的baseurl字段包含您的CentOS版本;例如:

baseurl=https://kong.bintray.com/kong-rpm/centos/6

或者

baseurl=https://kong.bintray.com/kong-rpm/centos/7

安装

  1. 安装Kong 如果要下载程序包,请执行:
     $ sudo yum install epel-release
     $ sudo yum install kong-1.3.0.*.noarch.rpm --nogpgcheck
    

    如果您正在使用存储库,请执行:

      $ sudo yum update -y
      $ sudo yum install -y wget
      $ wget https://bintray.com/kong/kong-rpm/rpm -O bintray-kong-kong-rpm.repo
      $ export major_version=`grep -oE '[0-9]+\.[0-9]+' /etc/redhat-release | cut -d "." -f1`
      $ sed -i -e 's/baseurl.*/&\/centos\/'$major_version''/ bintray-kong-kong-rpm.repo
      $ sudo mv bintray-kong-kong-rpm.repo /etc/yum.repos.d/
      $ sudo yum update -y
      $ sudo yum install -y kong
    
  2. 准备数据库或声明性配置文件 无论是否有数据库,Kong都可以运行。使用数据库时,您将使用 kong.conf 配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

    不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

    使用数据库

    配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。

    如果您使用Postgres,请在开始Kong之前配置数据库和用户,即:

     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    
    然后执行Kong的数据迁移:
    
      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong 小于0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong 小于0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

    不使用数据库

    如果要在无DB模式下运行Kong,则应首先生成声明性配置文件。以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。

     $ kong config init
    

    填写kong.yml文件后,编辑您的kong.conf文件。将数据库选项设置为off,将declarative_config选项设置为kong.yml文件的路径:

     database = off
      declarative_config = /path/to/kong.yml
    
  3. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  4. 使用Kong Kong正在运行
      $ curl -i http://localhost:8001/

微服务 API 网关 Kong 插件 AWS Lambda 中文文档

从Kong调用 AWS Lambda函数。它可以与其他请求插件结合使用以保护,管理或扩展功能。

注意:此插件与0.14.0之前的Kong版本和0.34之前的Kong Enterprise捆绑在一起的功能与此处记录的功能不同。 有关详细信息,请参阅CHANGELOG

术语

  • plugin: 在请求被代理到上游API之前或之后,在Kong内部执行操作的插件。
  • Service: 表示外部 upstream API或微服务的Kong实体。
  • Route: 表示将下游请求映射到上游服务的方法的Kong实体。
  • Consumer: 代表使用API的开发人员或机器的Kong实体。当使用Kong时,Consumer 仅与Kong通信,其代理对所述上游API的每次调用。
  • Credential: 与Consumer关联的唯一字符串,也称为API密钥。
  • upstream service: 这是指位于Kong后面的您自己的 API/service,转发客户端请求。

配置

此插件与具有以下协议的请求兼容:

  • http
  • https

此插件与无DB模式兼容。

在 Service 上启用插件

使用数据库:

通过发出以下请求在Service上配置此插件:

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=aws-lambda"  \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在服务上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  service: {service}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,{service}是此插件配置将定位的RouteID或名称。

在 Route 上启用插件

使用数据库:

通过发出以下请求在 Route 上配置此插件:

$ curl -X POST http://kong:8001/routes/{route}/plugins \
    --data "name=aws-lambda"  \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在 Route 上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  route: {route}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,,{route}是此插件配置将定位的 route 的idname

在 Consumer 上启用插件

使用数据库:

您可以使用http://localhost:8001/plugins在特定的Consumers上启用此插件:

$ curl -X POST http://kong:8001/consumers/{consumer}/plugins \
    --data "name=aws-lambda" \
     \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在Consumer上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  consumer: {consumer}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,{consumer}都是此插件配置将定位的Consumeridusername
您可以组合consumer_idservice_id 。 在同一个请求中,进一步缩小插件的范围。

全局插件

  • 使用数据库:可以使用http://kong:8001/plugins/配置所有插件。
  • 不使用数据库:可以通过plugins:配置所有插件:声明性配置文件中的条目。

与任何 Service ,Route 或 Consumer (或API,如果您使用旧版本的Kong)无关的插件被视为“全局”,并将在每个请求上运行。有关更多信息,请阅读插件参考插件优先级部分。

参数

以下是可在此插件配置中使用的所有参数的列表:

参数 默认值 描述
name 要使用的插件的名称,在本例中为aws-lambda
service_id 此插件将定位的 Service 的ID。
route_id 此插件将定位的 Route 的ID。
enabled true 是否将应用此插件。
consumer_id 此插件将定位的Consumer的id
config.aws_key 调用功能时要使用的AWS密钥凭证。
config.aws_secret 调用功能时要使用的AWS秘密凭证
config.aws_region Lambda函数所在的AWS区域。支持的区域是:us-east-1,us-east-2, ap-northeast-1,ap-northeast-2, ap-southeast-1, ap-southeast-2, eu-central-1, eu-west-1
config.function_name 要调用的AWS Lambda函数名称
config.qualifier 
optional
调用功能时要使用的 Qualifier 
config.invocation_type 
optional
RequestResponse 调用函数时要使用的 InvocationType。可用类型为RequestResponseEventDryRun
config.log_type 
optional
Tail 调用函数时要使用的LogType。默认情况下,不支持noneTail
config.timeout 
optional
60000 调用该函数时的可选超时(以毫秒为单位)
config.keepalive 
optional
60000 可选值(以毫秒为单位),用于定义空闲连接在关闭之前将存活多长时间
config.unhandled_status 
optional
200,202  204 Unhandled Function Error时使用的响应状态代码(而不是默认的200202204
config.forward_request_body 
optional
false 一个可选值,用于定义是否在JSON编码请求的request_body字段中发送请求正文。如果可以解析正文参数,则将在请求的单独的request_body_args字段中发送它们。正文参数可以针对application/jsonapplication/x-www-form-urlencodedmultipart/form-data内容类型进行解析。
config.forward_request_headers
optional
false 一个可选值,用于定义是否将原始HTTP请求标头作为映射发送到JSON编码请求的request_headers字段中。
config.forward_request_method
optional
false 一个可选值,用于定义是否在JSON编码请求的request_method字段中发送原始HTTP请求方法动词。
config.forward_request_uri 
optional
false 一个可选值,用于定义是否在JSON编码请求的request_uri字段中发送原始HTTP请求URI。请求URI参数(如果有)将在JSON主体的单独的request_uri_args字段中发送。
config.is_proxy_integration 
optional
false 一个可选值,它定义是否将从Lambda接收的响应格式转换为此格式。请注意,未实现参数isBase64Encoded

提醒: 默认情况下,curl将发送带有application/x-www-form-urlencoded MIME类型的有效负载,该负载自然会由Kong进行URL解码。 为确保正确解码可能出现在您的AWS密钥或机密中的特殊字符(如+),您必须对其进行URL编码,因此如果使用curl,请使用--data-urlencode。 这种方法的替代方法是使用其他MIME类型(例如application/json)发送有效负载,或使用其他HTTP客户端。

发送参数

与请求一起发送的任何表单参数也将作为参数发送到AWS Lambda函数。

已知的问题

使用伪造的上游服务

使用AWS Lambda插件时,响应将由插件本身返回,而无需将请求代理到任何上游服务。 这意味着服务的host, port, path属性将被忽略,但仍必须为由Kong验证的实体指定。 主机属性尤其必须是IP地址,或者是由名称服务器解析的主机名。

响应插件

系统中存在一个已知限制,该限制会阻止执行某些响应插件。 我们计划将来删除此限制。

分步指南

步骤

  1. 以允许用户使用lambda函数操作以及创建用户和角色的用户身份访问AWS Console。
  2. 在AWS中创建执行角色
  3. 创建一个将通过Kong调用该功能的用户,对其进行测试。
  4. 在Kong中创建一个Service&Route,添加链接到我们的aws函数的aws-lambda插件并执行它。

配置

  1. 首先,让我们为lambda函数创建一个称为LambdaExecutor的执行角色。在IAM控制台中创建一个选择AWS Lambda服务的新角色,将没有任何策略,因为本示例中的函数将简单地执行自身,从而返回硬编码JSON作为响应,而无需访问其他AWS资源
  2. 现在,我们创建一个名为KongInvoker的用户,由我们的Kong API网关用来调用该函数。在IAM控制台中,创建一个新用户,必须通过访问和秘密密钥向其提供编程访问权限;然后将直接附加现有策略,尤其是预定义的AWSLambdaRole。确认用户创建后,将访问密钥和秘密密钥存储在安全的地方。
  3. 现在我们需要创建lambda函数本身,将在弗吉尼亚北部地区(代码us-east-1)进行。在Lambda Management中,创建一个新函数Mylambda,将没有蓝图,因为我们将在下面粘贴代码。对于执行角色,我们选择一个以前专门创建的LambdaExecutor角色使用下面的内联代码来返回简单的JSON响应,请注意,这是Python 3.6解释器的代码。
      import json
    def lambda_handler(event, context):
      """
        If is_proxy_integration is set to true :
        jsonbody='''{"statusCode": 200, "body": {"response": "yes"}}'''
      """
      jsonbody='''{"response": "yes"}'''
      return json.loads(jsonbody)
    

    从AWS控制台测试lambda函数,并确保执行成功。

  4. 最后,我们在Kong中设置了Service&Route,并将其链接到刚刚创建的功能。

使用数据库

curl -i -X POST http://{kong_hostname}:8001/services \
--data 'name=lambda1' \
--data 'url=http://localhost:8000' \

该Service并不需要真正的URL,因为我们不会对上游进行HTTP调用,而需要由函数生成的响应。

还要为 Service 创建一条 Route :

curl -i -X POST http://{kong_hostname}:8001/services/lambda1/routes \
--data 'paths[1]=/lambda1'

添加插件

curl -i -X POST http://{kong_hostname}:8001/services/lambda1/plugins \
--data 'name=aws-lambda' \
--data-urlencode 'config.aws_key={KongInvoker user key}' \
--data-urlencode 'config.aws_secret={KongInvoker user secret}' \
--data 'config.aws_region=us-east-1' \
--data 'config.function_name=MyLambda'

不使用数据库

将 Service, Route and Plugin 添加到声明性配置文件中:

services:
- name: lambda1
  url: http://localhost:8000

routes:
- service: lambda1
  paths: [ "/lambda1" ]

plugins:
- service: lambda1
  name: aws-lambda
  config:
    aws_key: {KongInvoker user key}
    aws_secret: {KongInvoker user secret}
    aws_region: us-east-1
    function_name: MyLambda

创建所有内容后,请调用服务并验证正确的调用,执行和响应:

curl http://{kong_hostname}:8000/lambda1

附加标题:

x-amzn-Remapped-Content-Length, X-Amzn-Trace-Id, x-amzn-RequestId

JSON响应:

{"response": "yes"}

充分利用AWS Lambda在Kong的强大功能,尽享乐趣!

使用源码安装 Kong

无论是否有数据库,Kong都可以运行。

使用数据库时,您将使用kong.conf配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

使用数据库

  1. 安装依赖项OpenResty 1.15.8.1。作为一个OpenResty应用程序,您必须遵循OpenResty安装说明。您将需要OpenSSL和PCRE来编译OpenResty,并至少使用以下编译选项:
      $ ./configure \
        --with-pcre-jit \
        --with-http_ssl_module \
        --with-http_realip_module \
        --with-http_stub_status_module \
        --with-http_v2_module
    

    您可能必须指定--with-openssl,并且可以添加任何其他您想要的选项,例如其他Nginx模块或自定义--prefix目录。

    OpenResty可以方便地捆绑LuaJITresty-cli,它们对于Kong来说是必不可少的。将nginx和resty可执行文件添加到$ PATH

      $ export PATH="$PATH:/usr/local/openresty/bin"
    

    Luarocks 3.1.3,使用与OpenResty捆绑的LuaJIT版本编译(请参阅--with-lua--with-lua-include配置选项)。例:

      ./configure \
        --lua-suffix=jit \
        --with-lua=/usr/local/openresty/luajit \
        --with-lua-include=/usr/local/openresty/luajit/include/luajit-2.1
    
  2. 安装 Kong现在已经安装了OpenResty,我们可以使用Luarocks来安装Kong的Lua源:
      $ luarocks install kong 1.3.0-0
    

    或者

      $ git clone git@github.com:Kong/kong.git
      $ cd kong
      $ [sudo] make install # this simply runs the `luarocks make kong-*.rockspec` command
    
  3. 添加kong.conf

    注意:如果您使用的是Cassandra,则需要执行此步骤;它是Postgres用户的可选项。

    默认情况下,Kong配置为与本地Postgres实例通信。 如果您使用的是Cassandra,或者需要修改任何设置,请下载kong.conf.default文件并根据需要进行调整。 然后,以root身份将其添加到/etc

      $ sudo mkdir -p /etc/kong
       $ sudo cp kong.conf.default /etc/kong/kong.conf
    
  4. 准备数据库配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。如果您使用的是Postgres,请在启动Kong之前配置数据库和用户:
     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    

    接下来,运行Kong迁移:

      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong < 0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong < 0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

  5. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  6. 使用KongKong正在运行
      $ curl -i http://localhost:8001/
    

不使用数据库

  1. 按照上面的列表中的步骤1和2(安装依赖项,安装Kong)。
  2. 写声明性配置文件以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。执行此操作时,请遵循[声明配置格式]:/1.3.x/db-less-and-declarative-config/#the-declarative-configuration-format说明。
      $ kong config init
    

    我们假设该文件名为kong.yml

  3. 添加kong.conf下载kong.conf.default文件并根据需要进行调整。特别是,确保将database配置选项设置为off,并将declarative_config选项设置为kong.yml的绝对路径
      database = off
      ...
      declarative_config = /path/to/kong.yml
    
  4. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  5. 使用KongKong正在运行
      $ curl -i http://localhost:8001/

在 Kubernetes 上安装 Kong 和 Kong Enterprise

Kubernetes Ingress Controller for Kong

使用官方Kubernetes Ingress控制器安装Kong或Kong Enterprise。

通过README文件了解更多信息。要运行本地概念证明,请按照Minikube和Minishift教程进行操作。

Kubernetes Ingress Controller for Kong发布公告在Kong Blog上。

如有问题和讨论,请访问Kong Nation。 有关错误报告,请在GitHub上打开一个新问题

通过 Google Cloud Platform Marketplace 安装 Kong

也许在Kubernetes上尝试Kong的最快方法是通过Google Cloud Platform Marketplace和Google Kubernetes Engine - 以及Google Cloud Platform的Free Tier 和 credit,,您可以免费使用。

  1. 访问 https://console.cloud.google.com/marketplace/details/kong/kong
  2. 单击“Configure”,然后按照屏幕上的提示进行操作
  3. 有关公开Admin API的重要详细信息,请参阅https://github.com/Kong/google-marketplace-kong-app/blob/master/README.md,以便您可以配置Kong。

如果您只是在尝试使用,请考虑在完成实验后删除Google云资源,以避免持续使用Google Cloud使用费。

通过 Helm 安装 Kong

使用官方Helm chart 安装Kong或Kong Enterprise。

如有问题和讨论,请访问 Kong Nation

通过 Manifest 文件安装 Kong

可以通过Kong Kubernetes存储库中提供的清单文件在Kubernetes集群上配置Kong或Kong Enterprise的试用版。

准备

  1. 下载或克隆Kong Kubernetes存储库
  2. 一个Kubernetes集群

安装步骤

Kong Kubernetes存储库包括 Make tasks run_cassandrarun_postgresrun_dbless 以便于使用,但我们将详细说明任务在此处使用的特定YAML文件。

对于所有变体,创建Kong命名空间:

$ kubectl apply -f kong-namespace.yaml

下一步取决于您是否要使用Kong与Cassandra,Postgres或没有数据存储区:

Cassandra Backed Kong

使用此存储库中的cassandra-service.yamlcassandra-statefulset.yaml文件在集群中部署Cassandra服务和StatefulSet

$ kubectl apply -f cassandra-service.yaml
$ kubectl apply -f cassandra-statefulset.yaml

使用此存储库中的kong-control-plane-cassandra.yaml文件运行所需的迁移并部署Kong控制平面节点,包括Kong admin api

$ kubectl -n kong apply -f kong-control-plane-cassandra.yaml

使用此存储库中的kong-ingress-data-plane-cassandra.yaml文件运行Kong数据平面节点

$ kubectl -n kong apply -f kong-ingress-data-plane-cassandra.yaml

PostgreSQL Backed Kong

使用存储库中的postgres.yaml文件在集群中部署postgreSQL服务和ReplicationController

$ kubectl create -f postgres.yaml

使用此存储库中的kong-control-plane-postgres.yaml文件运行所需的迁移并部署Kong控制平面节点,包括Kong Admin API:

$ kubectl -n kong apply -f kong-control-plane-postgres.yaml

使用此存储库中的kong-ingress-data-plane-postgres.yaml文件运行Kong数据平面节点

$ kubectl -n kong apply -f kong-ingress-data-plane-postgres.yaml

Using Datastore Backed Kong

首先,让我们确保Kong控制平面和数据平面成功运行

kubectl get all -n kong
NAME                           READY   STATUS
pod/kong-control-plane         1/1     Running
pod/kong-ingress-data-plane    1/1     Running

访问Kong Admin API端口(如果运行minikube,则以下内容应该有效):

$ export HOST=$(kubectl get nodes --namespace default -o jsonpath='{.items[0].status.addresses[0].address}')
$ export ADMIN_PORT=$(kubectl get svc --namespace kong kong-control-plane  -o jsonpath='{.spec.ports[0].nodePort}')

Using Kong without a Database

对于declarative / db-less,使用此存储库中的declarative.yaml示例文件创建配置映射

$ kubectl create configmap kongdeclarative -n kong --from-file=declarative.yaml

现在使用此存储库中的kong-dbless.yaml文件部署Kong数据平面

$ kubectl apply -f kong-dbless.yaml

Using Declarative / DB Less Backed Kong

要更新declarative / db-less Kong,请编辑声明性文件,然后替换配置映射

$ kubectl create configmap kongdeclarative -n kong --from-file=declarative.yaml -o yaml --dry-run | kubectl replace -n kong -f -

现在使用声明性Kong yaml文件的md5sum进行滚动部署

$ kubectl patch deployment kong-dbless -n kong -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"declarative\":\"`md5sum declarative.yaml | awk '{ print $$1 }'`\"}}}}}}"

访问Kong Admin API端口(如果运行minikube,则以下内容应该有效):

$ export HOST=$(kubectl get nodes --namespace default -o jsonpath='{.items[0].status.addresses[0].address}')=
$ export ADMIN_PORT=$(kubectl get svc --namespace kong kong-control-plane  -o jsonpath='{.spec.ports[0].nodePort}')

Kong Enterprise 试用用户的附加步骤

  1. 将Kong Enterprise Docker映像发布到容器注册表

    由于Kong Enterprise映像在公共Docker容器注册表中不可用,因此必须将其发布到私有存储库以与Kubernetes一起使用。虽然任何私有存储库都可以使用,但此示例使用Google Cloud Platform容器注册表,该注册表在其他步骤中自动与Google Cloud Platform示例集成。

    在下面的步骤中,将 <image ID> 替换为与docker images输出中已加载图像关联的ID。将 <project ID> 替换为您的Google Cloud Platform项目ID。

      $ docker load -i /tmp/kong-docker-enterprise-edition.tar.gz
      $ docker images
      $ docker tag <image ID> gcr.io/<project ID>/kong-ee
      $ gcloud docker -- push gcr.io/demo-cs-lab/kong-ee:latest
    
  2. 添加您的Kong Enterprise许可文件

    编辑kong_trial_postgres.yamlkong_trial_migration_postgres.yaml,将YOUR_LICENSE_HERE替换为您的Kong Enterprise License File字符串 – 它应如下所示:

      - name: KONG_LICENSE_DATA
      value: '{"license":{"signature":"alongstringofcharacters","payload":{"customer":"Test Company","license_creation_date":"2018-03-06","product_subscription":"Kong Only","admin_seats":"5","support_plan":"Premier","license_expiration_date":"2018-06-04","license_key":"anotherstringofcharacters"},"version":1}}'
    
  3. 使用Kong Enterprise图像

    编辑kong_trial_postgres.yamlkong_trial_migration_postgres.yaml并将image:kong替换为image:gcr.io/<project ID> / kong-ee,使用与上面相同的项目ID。

  4. 部署Kong Enterprise

    使用Kong Enterprise Trial目录中的kong_trial_* YAML文件,从上面的Manifest Files指令继续执行Kong或Kong Enterprise中的步骤4。 一旦Kong Enterprise运行,您应该能够通过<kong-admin-ip-address>:8002https:// <kong-ssl-admin-ip-address>:8445访问Kong Admin GUI。

 

Kong 无法使用 lua-openssl

目前在写一个kong的插件的时候想要使用一下 lua-openssl 的ecc加密功能,ecc是一个相对较新的加密算法(椭圆加密算法)。

lua-openssl 的项目地址为:https://github.com/zhaozg/lua-openssl 然后按照文档中的步骤,先安装:

luarocks install openssl

然后直接根据 https://github.com/zhaozg/lua-openssl/blob/master/test/ec.lua 中的例子来使用:

local openssl = require "openssl"
local pkey = require "openssl.pkey"

local nec = {'ec',"prime256v1"}
local ec = pkey.new(unpack(nec))
local k1 = pkey.get_public(ec)
print(k1)

执行然后发现报错:

/usr/local/share/lua/5.1/kong/plugins/init/handler.lua:33: bad argument #2 to 'new' (invalid option 'prime256v1')

发现这个是不支持这个算法,但是不对啊,分明已经按照文档上的来了为什么不可以,然后就怀疑,问题出在local openssl = require "openssl"这个上面。然后一顿google发现,原因是kong里面也有自带一个类似的项目,叫做 luaossl,然而,他们的包名称都叫做openssl,所以其实虽然我以为我引用了的是lua-openssl这个项目,但其实使用的还是kong自带的 luaossl(项目地址:https://github.com/wahern/luaossl) 。但是 luaossl 暂时还没有支持ecc这个比较新的算法,这个功能就用不了。

真相大白,原来是资源包名称相同导致的。详情可点击此链接:https://github.com/zhaozg/lua-openssl/issues/72 。目前暂时还没有很好的解决方案,lua-openssl的作者说联系 luaossl 商量改名的事宜,但暂还没有下文。

那么最后的解决方案就是先在lua中调用系统命令生成ecc相关密钥。

如何在 Kong 和 OpenResty 中使用环境变量 os.getenv()

在项目中有时会遇到使用系统环境变量的问题,但是直接使用 os.getenv() 是不可行的,不仅是在 Kong 中,在 OpenResty 也都是不可以的,原因是 Kong 是基于 OpenResty ,OpenResty 是基于 Nginx 的,而Nginx在启动的时候,会把环境中所有的环境变量都清除掉,我们可以从Nginx的官方文档中看到这段描述:http://nginx.org/en/docs/ngx_core_module.html#env 

By default, nginx removes all environment variables inherited from its parent process except the TZ variable.

具体可以参考春哥在这个issue下的回复:https://github.com/openresty/lua-nginx-module/issues/601

所以需要在你的nginx.conf文件中把你需要的环境变量声明一下:

events{
  ...
}

env PATH;
env USERNAME;

然后重启一下Nginx,就可以直接在你的 Lua 代码中使用 os.getenv("USERNAME") 获取环境变量。

在 Kong 中使用 os.getenv()

那如果我想在kong的插件中是使用os.getenv()要怎么操作呢?

在 Kong 里面,我们看到Kong生成的 Nginx配置文件是不可修改的,即使你修改了,Kong 还是会生成恢复成修改前,那么这个时候就要用到 Kong 的一个自定义 Nginx 配置文件功能。详情可以看这俩issue:

那么实际操作起来就很简单了,新建一个custom-nginx.conf文件,里面和上文一样,把你需要使用到的环境变量写到这个配置文件中。

events{
  ...
}

env PATH;
env USERNAME;

接着重启 Kong 即可。不过这里要注意的是,重启的时候,需要带上一个参数--nginx-conf。不过不要搞错的是-c参数是kong的配置文件参数,--nginx-conf 是自定义Nginx模板配置参数

 kong restart -c kong.conf --nginx-conf custom-nginx.conf

重启成功之后,就可以在 Kong 的插件中使用代码中使用 os.getenv("USERNAME") 来获取环境变量了。

在 Ubuntu 上安装 Kong

安装包

首先下载配置的相应软件包:

企业试用用户应从其欢迎电子邮件中下载其包,并在步骤1之后将其许可保存到/etc/kong/license.json

APT存储库

您也可以通过APT安装Kong; 按照下面页面上“Set Me Up”部分的说明,将分布设置为适当的值(lsb_release -sc)(例如,precise)和组件到main

安装

  1. 安装Kong 如果要下载程序包,请执行:
      $ sudo apt-get update
      $ sudo apt-get install openssl libpcre3 procps perl
      $ sudo dpkg -i kong-1.3.0.*.deb
    

    如果您正在使用apt存储库执行:

      $ sudo apt-get update
      $ sudo apt-get install -y apt-transport-https curl lsb-core
      $ echo "deb https://kong.bintray.com/kong-deb `lsb_release -sc` main" | sudo tee -a /etc/apt/sources.list
      $ curl -o bintray.key https://bintray.com/user/downloadSubjectPublicKey?username=bintray
      $ sudo apt-key add bintray.key
      $ sudo apt-get update
      $ sudo apt-get install -y kong
    
  2. 准备数据库或声明性配置文件无论是否有数据库,Kong都可以运行。

    使用数据库时,您将使用 kong.conf 配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

    不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

    使用数据库

    配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。

    如果您使用Postgres,请在开始Kong之前配置数据库和用户,即:

     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    
    然后执行Kong的数据迁移:
    
      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong 小于0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong 小于0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

    不使用数据库

    如果要在无DB模式下运行Kong,则应首先生成声明性配置文件。以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。

     $ kong config init
    

    填写kong.yml文件后,编辑您的kong.conf文件。将数据库选项设置为off,将declarative_config选项设置为kong.yml文件的路径:

     database = off
      declarative_config = /path/to/kong.yml
    
  3. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  4. 使用KongKong正在运行
      $ curl -i http://localhost:8001/

使用 Docker 安装 Kong

有关如何在Docker中使用Kong的详细信息可以在镜像图像的DockerHub存储库中找到:kong。 我们还有一个Docker Compose template,内置编排和可扩展性。

使用数据库

这是一个快速示例,显示如何将Kong容器连接到Cassandra或PostgreSQL容器。

  1. 创建一个Docker network

    您需要创建一个自定义网络,以允许容器相互发现和通信。在此示例中,kong-net是网络名称,您可以使用任何名称。

     $ docker network create kong-net
    
  2. 启动数据库

    如果您想使用Cassandra容器:

      $ docker run -d --name kong-database \
                --network=kong-net \
                -p 9042:9042 \
                cassandra:3
    

    如果您想使用PostgreSQL容器:

      $ docker run -d --name kong-database \
                --network=kong-net \
                -p 5432:5432 \
                -e "POSTGRES_USER=kong" \
                -e "POSTGRES_DB=kong" \
                postgres:9.6
    
  3. 准备数据库

    使用临时Kong容器运行迁移:

      $ docker run --rm \
      --network=kong-net \
      -e "KONG_DATABASE=postgres" \
      -e "KONG_PG_HOST=kong-database" \
      -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
      kong:latest kong migrations bootstrap
    

    在上面的示例中,配置了Cassandra和PostgreSQL,但您应该使用cassandrapostgres更新KONG_DATABASE环境变量。
    对于Kong 小于0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong 版本小于0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

  4. 启动Kong

    迁移运行并且数据库准备就绪后,启动一个将连接到数据库容器的Kong容器,就像临时迁移容器一样:

      $ docker run -d --name kong \
      --network=kong-net \
      -e "KONG_DATABASE=postgres" \
      -e "KONG_PG_HOST=kong-database" \
      -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
      -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
      -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
      -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
      -p 8000:8000 \
      -p 8443:8443 \
      -p 8001:8001 \
      -p 8444:8444 \
      kong:latest
    
  5. 使用Kong

    Kong正在运行:

      $ curl -i http://localhost:8001/
    

    通过5分钟的快速入门快速学习如何使用Kong。

无数据库模式

在无DB模式下启动Kong所涉及的步骤如下:

  1. 创建一个Docker network

    这与Pg / Cassandra指南中的相同。我们也使用kong-net作为网络名称,它也可以改为其他东西。

      $ docker network create kong-net
    

    在无DB模式下运行Kong并不严格需要此步骤,但如果您希望将来添加其他内容(如Redis群集备份的速率限制插件),这是一个很好的预防措施。

  2. 创建Docker volume

    对于本指南的目的,Docker卷是主机内的一个文件夹,可以将其映射到容器中的文件夹中。卷有一个名称。在这种情况下,我们将命名我们的kong-vol

      $ docker volume create kong-vol
    

    您现在应该能够检查volume:

      $ docker volume inspect kong-vol
    

    结果应该类似于:

      [
          {
              "CreatedAt": "2019-05-28T12:40:09Z",
              "Driver": "local",
              "Labels": {},
              "Mountpoint": "/var/lib/docker/volumes/kong-vol/_data",
              "Name": "kong-vol",
              "Options": {},
              "Scope": "local"
          }
      ]
    

    注意MountPoint条目。我们将在下一步中使用该路径。

  3. 准备声明性配置文件

    声明性配置格式指南中描述了语法和属性。

    添加您需要的任何核心实体(服务,路由,插件,消费者等)。

    在本指南中,我们假设您将其命名为kong.yml。

    将其保存在上一步中提到的MountPoint路径中。

    就本指南而言,这将是/var/lib/docker/volumes/kong-vol/_data/kong.yml

  4. 在无DB模式中启动Kong

    虽然可以仅使用KONG_DATABASE=off来启动Kong容器,但通常还需要通过KONG_DECLARATIVE_CONFIG变量名称将声明性配置文件作为参数包含在内。为此,我们需要从容器中使文件“visible”。我们使用-v标志来实现这一点,它将kong-vol卷映射到容器中的/usr/local/kong/declarative文件夹。

      $ docker run -d --name kong \
      --network=kong-net \
      -v "kong-vol:/usr/local/kong/declarative" \
      -e "KONG_DATABASE=off" \
      -e "KONG_DECLARATIVE_CONFIG=/usr/local/kong/declarative/kong.yml" \
      -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
      -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
      -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
      -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
      -p 8000:8000 \
      -p 8443:8443 \
      -p 8001:8001 \
      -p 8444:8444 \
      kong:latest
    
  5. 使用Kong

    Kong应该正在运行,它应该包含一些以Kong .yml添加的实体。

      $ curl -i http://localhost:8001/
    

    例如,获取服务列表:

      $ curl -i http://localhost:8001/services

 

Kong 1.3发布!支持原生gRPC代理,上游双向TLS认证,以及更多功能

原文地址:https://konghq.com/blog/kong-1-3-released/

今天,我们很高兴地宣布推出Kong 1.3!我们的工程团队和出色的社区为此版本提供了许多功能和改进。基于1.2版本的成功,Kong 1.3是Kong的第一个版本,它本身支持gRPC代理,上游相互TLS身份验证,以及一系列新功能和性能改进。

请阅读以下内容,了解有关Kong 1.3的新功能,改进和修复的更多信息,以及如何利用这些令人兴奋的变化。 请花几分钟时间阅读我们的更新日志以及升级路径以获取更多详细信息。

原生gRPC代理

我们观察到越来越多的用户转向微服务架构,并听到用户表达他们对本机gRPC代理支持的兴趣。Kong 1.3通过支持gRPC本地代理来解决这个问题,为支持gRPC的基础架构带来更多控制和可见性。

主要优点:

  • 简化运营流程。
  • 为gRPC服务添加A / B测试,自动重试和断路,以提高可靠性和正常运行时间。
  • 更多的可观测性
  • 针对gRPC服务的日志记录,分析或Prometheus集成?Kong让你满意。

主要功能:

  • 新协议:Route和Service实体的protocol属性现在可以设置为grpcgrpcs,这对应于通过明文HTTP/2(h2c)的gRPC和通过TLS HTTP/ 2(h2)的gRPC。

上游双向TLS认证

Kong长期以来一直支持与上游服务的TLS连接。 在1.3中,我们添加了对Kong的支持,以提供特定证书,同时与上游握手以提高安全性。

主要优点:

  • 能够使用证书与上游服务握手使得Kong在需要强大的身份验证保证的行业中更加出色,例如金融和医疗保健服务。
  • 安全性更好
  • 通过提供可信证书,上游服务将确定传入请求是由Kong转发的,而不是恶意客户端。
  • 对开发人员更友好
  • 您可以使用Kong将需要相互TLS身份验证的服务转换为与开发人员无关的方法(例如OAuth)。

主要功能:

  • 新配置属性:Service实体具有新字段client_certificate。如果设置,当Kong尝试与服务握手时将使用相应的证书。

Sessions 插件

在Kong 1.3中,我们开放了Sessions插件(之前仅在Kong Enterprise中提供)供所有用户使用。 结合其他身份验证插件,它允许Kong记住之前已经过身份验证的浏览器用户。 您可以在此处阅读详细的文档

NGINX CVE修复

Kong 1.3附带NGINX HTTP/2模块(CVE-2019-9511CVE-2019-9513CVE-2019-9516)的修复程序。 我们还发布了Kong 1.0.4,1.1.3,1.2.2来修补旧版Kong中的漏洞,以防不能立即升级到1.3。

OpenResty Version Bump

OpenResty的版本已经发布到最新的OpenResty版本 - 1.15.8.1,该版本基于Nginx 1.15.8。 此版本的OpenResty在关闭上游keepalive连接,ARM64架构支持和LuaJIT GC64模式时带来了更好的性能。 最引人注目的变化是,由于LuaJIT编译器生成更多本机代码,OpenResty更有效地存储请求上下文数据,因此使用密钥身份验证在基线代理基准测试中,Kong现在运行速度提高约10%。 

Kong 1.3的其他新功能

按任何请求 header 路由

  • Kong的路由器现在能够通过任何请求头(不仅是Host)匹配路由。
  • 这允许对服务之间路由传入流量的方式进行精细控制。
  • 参阅此处的文档

最少连接负载平衡

  • Kong现在可以将流量发送到连接数最少的上游服务。
  • 在某些用例中改善上游负载分配。
  • 参阅此处的文档

数据库导出

  • 新添加的kong config db_export CLI命令可用于创建数据库内容转储到YAML文件中,该文件适用于声明性配置或稍后导回数据库。
  • 这样可以更轻松地创建声明性配置文件。
  • 这使得Kong配置的备份和版本控制变得更加容易
  • 参阅此处的文档

主动关闭上游keepalive连接

  • 在旧版本的Kong中,上游连接永远不会被Kong关闭。这可能导致竞争条件,因为Kong可能会尝试重新使用keepalived连接,而上游尝试关闭它。
  • 如果您在Kong error.log中看到“upstream prematurely closed connection”错误,则此版本应显着减少甚至消除部署中的此错误。
  • 添加了新的配置指令来控制此行为,请阅读完整的更新日志以了解更多信息。

更多的监听标志支持

  • 特别是reuseport标志,如果Kong worker数量很大,可用于改善负载分配和延迟抖动。
  • 还添加了deferredbind标志支持。您可以查看NGINX listen指令文档以了解使用它们的效果。

其他改进和错误修复

Kong 1.3还包含有关存储CA证书(没有私钥的证书),Admin API接口和更多PDK功能的新实体的改进。 我们还修复了很多错误。由于此版本中有大量新功能,因此我们无法在此博客文章中介绍所有这些内容,而是鼓励您在此处阅读完整的更新日志

我们还在kong.conf模板中添加了一个新的部分,以更好地解释注入NGINX指令的功能。 对于具有仅添加几个NGINX指令的自定义模板的用户,我们建议切换使用注入的NGINX指令,以获得更好的可升级性。

与往常一样,Kong 1.3的文档可在此处获得。 此外,如上所述,我们将在后续帖子和社区电话中讨论1.3中的主要功能,敬请期待!

感谢我们的用户,贡献者和核心维护者社区,感谢您对Kong的开源平台的持续支持。 请试试Kong 1.3,一定要告诉我们您的想法

Kong社区

像往常一样,随时可以就我们的社区论坛Kong Nation提出任何问题。 从您的反馈中学习将使我们能够更好地理解任务关键用例并不断改进Kong。

微服务 API 网关 Kong 插件 Kubernetes Sidecar 注入插件中文文档

Kubernetes Sidecar 注入插件

该插件将注入Kong数据平面节点并在Kubernetes之上形成服务网格

介绍

Kong 0.15.0 / 1.0.0增加了代理和路由原始tcptls流的能力,并使用服务网格Sidecar模式和Kong节点之间的相互tls来部署Kong。本教程将引导您使用我们的 Kubernetes Sidecar 注入插件在Kubernetes上设置Kong服务网格。

准备条件

您需要在Kubernetes上运行Kong 1.0.0或更高版本,包括存储为可用于Kong控制平面的机密的SSL证书。来自Kong Kubernetes Repository的Make任务run_cassandrarun_postgres将完全配置必备数据存储,Kong控制平面,Kong数据平面和SSL机密。

或者,按照Kong Kubernetes Install Instructions页面中的任何设置说明进行操作,然后设置SSL证书/密码:

cd $(mktemp -d)

### Create a key+certificate for the control plane
cat <<EOF | kubectl create -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: kong-control-plane.kong.svc
spec:
  request: $(openssl req -new -nodes -batch -keyout privkey.pem -subj /CN=kong-control-plane.kong.svc | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF
kubectl certificate approve kong-control-plane.kong.svc
kubectl -n kong create secret tls kong-control-plane.kong.svc --key=privkey.pem --cert=<(kubectl get csr kong-control-plane.kong.svc -o jsonpath='{.status.certificate}' | base64 --decode)
kubectl delete csr kong-control-plane.kong.svc
rm privkey.pem

或使用以下简便脚本:

curl -fsSL https://raw.githubusercontent.com/Kong/kong-dist-kubernetes/master/setup_certificate.sh | bash

安装步骤

导出一些变量以访问Kong Admin API和Proxy:

$ export HOST=$(kubectl get nodes --namespace default -o jsonpath='{.items[0].status.addresses[0].address}')
$ export ADMIN_PORT=$(kubectl get svc --namespace kong kong-control-plane  -o jsonpath='{.spec.ports[0].nodePort}')

通过Kong Admin API启用Sidecar Injector插件:

curl $HOST:$ADMIN_PORT/plugins -d name=kubernetes-sidecar-injector -d config.image=kong

打开Kubernets Sidecar Injection:

cat <<EOF | kubectl create -f -
apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: kong-sidecar-injector
webhooks:
- name: kong.sidecar.injector
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations: [ "CREATE" ]
  failurePolicy: Fail
  namespaceSelector:
    matchExpressions:
    - key: kong-sidecar-injection
      operator: NotIn
      values:
      - disabled
  clientConfig:
    service:
      namespace: kong
      name: kong-control-plane
      path: /kubernetes-sidecar-injector
    caBundle: $(kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}')
EOF

或使用以下简便脚本:

curl -fsSL https://raw.githubusercontent.com/Kong/kong-dist-kubernetes/master/setup_sidecar_injector.sh | bash

使用

接下来,任何开始使用Kong Sidecar的pods都会自动注入,而来自该pods容器的所有数据都将通过Kong Sidecar。 例如,如果我们使用Istio中的bookinfo.yaml示例:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/platform/kube/bookinfo.yaml

我们看到所有pods都收到了Kong Sidecar:

kubectl get all
NAME                 READY   STATUS
pod/details-v1       2/2     Running
pod/productpage      2/2     Running
pod/ratings-v1       2/2     Running
pod/reviews-v1       2/2     Running
pod/reviews-v2       2/2     Running
pod/reviews-v3       2/2     Running

继续配置服务。

基于OpenResty 的 WEB 框架 Lor 安装初探

  • 项目介绍:
    • Lor是一个运行在OpenResty上的基于Lua编写的Web框架.
    • 路由采用Sinatra风格,Sinatra是Ruby小而精的web框架.
    • API基本采用了Express的思路和设计,Node.js跨界开发者可以很快上手.
    • 支持插件(middleware),路由可分组,路由匹配支持string/正则模式.
    • lor以后会保持核心足够精简,扩展功能依赖middleware来实现. lor本身也是基于middleware构建的.
    • 推荐使用lor作为HTTP API Server,lor也已支持session/cookie/html template等功能.
    • 框架简单示例项目lor-example
    • 框架全站示例项目openresty-china
  • 项目地址: https://github.com/sumory/lor
  • 文档地址: http://lor.sumory.com

安装lor框架

git clone https://github.com/sumory/lor
cd lor 
make install

此时可能会有报错如下:

/usr/bin/env: "resty": 没有那个文件或目录

原因为lor没有找到resty的执行目录,这个时候只需要找到resty的执行目录并软链过去即可:

sudo ln -s /usr/local/openresty/bin/resty /usr/bin/resty

框架自带一个示例项目,运行一下代码

lord new lor_demo

启动

然后就能在框架中看到lor_demo文件夹,执行如下命令

cd lor_demo
lord start

打开浏览器,输入http://localhost:8888/正常访问,即正常安装。