标签 yum 下的文章

通过实例理解API网关的主要功能特性

本文永久链接 – https://tonybai.com/2023/12/03/understand-api-gateway-main-functional-features-by-example

在当今的技术领域中,“下云”的概念正逐渐抬头,像David Heinemeier Hansson(37signals公司的联合创始人, Ruby on Rails的Creator)就直接将公司所有的业务都从公有云搬迁到了自建的数据中心中。虽说大多数企业不会这么“极端”,但随着企业对云原生架构采用的广泛与深入,不可避免地面临着对云服务的依赖。云服务在过去的几年中被广泛应用于构建灵活、可扩展的应用程序和基础设施,为企业提供了许多便利和创新机会。然而,随着业务规模的增长和数据量的增加,云服务的成本也随之上升。企业开始意识到,对云服务的依赖已经成为一个值得重新评估的议题。云服务的开销可能占据了企业可用的预算的相当大部分。为了保持竞争力并更好地控制成本,企业需要寻找方法来减少对云服务的依赖,寻找更经济的解决方案,同时确保仍能获得所需的性能、安全性和可扩展性。

在这样的背景下,我们的关注点是选择一款适宜的API网关,从主流功能特性的角度来评估候选者的支持。API网关作为现代云原生应用架构中的关键组件,扮演着连接前端应用和后端服务的中间层,负责管理、控制和保护API的访问。它的功能特性对于确保API的安全性、可靠性和可扩展性至关重要。

尽管API网关并不是一个新鲜事物了,但对于那些长期依赖于云供应商的服务的人来说,它似乎变得有些“陌生”。因此,本文旨在帮助我们重新理解API网关的主要特性,并获得对API网关选型的能力,以便在停止使用云供应商服务之前,找到一个合适的替代品^_^。

1. API网关回顾

API网关是现代应用架构中的关键组件之一,它的存在简化了应用程序的架构,并为客户端提供一个单一的访问入口,并进行相关的控制、优化和管理。API网关可以帮助企业实现微服务架构、提高系统的可扩展性和安全性,并提供更好的开发者体验和用户体验。

1.1 API网关的演化

随着互联网的快速发展和企业对API的需求不断增长,API网关作为一种关键的中间层技术逐渐崭露头角并经历了一系列的演进和发展。这里将API网关的演进历史粗略分为以下几个阶段:

  • API网关之前的早期阶段

在互联网发展的早期阶段,大多数应用程序都是以单体应用的形式存在。后来随着应用规模的扩大和业务复杂性的增加,单体应用的架构变得不够灵活和可扩展,面向服务架构(Service-Oriented Architecture,SOA)逐渐兴起,企业开始将应用程序拆分成一组独立的服务。这个时期,每个服务都是独立对外暴露API,客户端也是通过这些API直接访问服务,但这会导致一些安全性、运维和扩展性的问题。之后,企业也开始意识到需要一种中间层来管理和控制这种客户端到服务的通信行为,并确保服务的可靠性和安全性,于是开始有了API网关的概念。

  • API网关的兴起

早期的API网关,其主要功能就是单纯的路由和转发。API网关将请求从客户端转发到后端服务,并将后端服务的响应返回给客户端。在这个阶段,API网关的功能非常简单,主要用于解决客户端和后端服务之间的通信问题。

  • API网关的成熟

随着微服务架构的兴起和API应用的不断发展,企业开始将应用程序进一步拆分成更小的、独立部署的微服务。每个对外暴露的微服务都有自己的API,并通过API网关进行统一管理和访问。API网关在微服务架构中的作用变得更加重要,它的功能也逐渐丰富起来了。

在这一阶段,它不仅负责路由和转发请求,API网关还增加了安全和治理的功能,可以满足几个不同领域的微服务需求。比如:API网关可以通过身份认证、授权、访问控制等功能来保护API的安全;通过基于重试、超时、熔断的容错机制等来对API的访问进行治理;通过日志记录、基于指标收集以及Tracing等对API的访问进行观测与监控;支持实时的服务发现等。


API网关(图来自网络)

  • API网关的云原生化

随着云原生技术的发展,如容器化和服务网格(Service Mesh)等,API网关也在不断演进和适应新的环境。在云原生环境中,API网关实现了与容器编排系统(如Kubernetes)和服务网格集成,其自身也可以作为一个云原生服务来部署,以实现更高的可伸缩性、弹性和自动化。同时,新的技术和标准也不断涌现,如GraphQL和gRPC等,API网关也增加了对这些新技术的集成和支持。

1.2 API网关的主要功能特性

从上面的演化历史我们看到:API网关的演进使其从最初简单的请求转发角色,逐渐成为整个API管理和微服务架构中的关键组件。它不仅扮演着API管理层与后端服务层之间的适配器,也是云原生架构中不可或缺的基础设施,使微服务管理更加智能化和自动化。下面是现代API网关承担的主要功能特性,我们后续也会基于这些特性进行示例说明:

  • 请求转发和路由
  • 身份认证和授权
  • 流量控制和限速
  • 高可用与容错处理
  • 监控和可观测性

2. 那些主流的API网关

下面是来自CNCF Landscape中的主流API网关集合(截至2023.11月),图中展示了关于各个网关的一些细节,包括star数量和背后开发的公司或组织:

主流的API网关还有各大公有云提供商的实现,比如:Amazon的API GatewayGoogle Cloud的API Gateway以及上图中的Azure API Management等,但它们不在我们选择范围之内;虽然被CNCF收录,但多数API网关受到的关注并不高,超过1k star的不到30%,这些不是很受关注或dev不是那么active的项目也无法在生产环境担当关键角色;而像APISIXKong这两个受关注很高的网关,它们是建构在Nginx之上实现的,技术栈与我们不契合;而像EMISSARY INGRESS、Gloo等则是完全云原生化或者说是Kubernetes Native的,无法在无Kubernetes的基于VM或裸金属的环境下部署和运行。

好吧,剩下的只有几个Go实现的API Gateway了,在它们之中,我们选择用Tyk API网关来作为后续API功能演示的示例。

注:这并不代表Tyk API网关就要比其他Go实现的API Gateway优秀,只是它的资料比较齐全,适合在本文中作演示罢了。

3. API网关主要功能特性示例(Tyk API网关版本)

3.1 Tyk API网关简介

记得在至少5年前就知道Tyk API网关的存在,印象中它是使用Go语言开发的早期的那批API网关之一。Tyk从最初的纯开源项目,到如今由背后商业公司支持,以Open Core模式开源的网关,一直保持了active dev的状态。经过多年的演进,它已经一款功能强大的开源兼商业API管理和网关解决方案,提供了全面的功能和工具,帮助开发者有效地管理、保护和监控API。同时,Tyk API网关支持多种安装部署方式,即可以单一程序的方式放在物理机或VM上运行,也可以支持容器部署,通过docker-compose拉起,亦可以通过Kubernetes Operator将其部署在Kubernetes中,这也让Tyk API网关具备了在各大公有云上平滑迁移的能力。

关于Tyk API网关开源版本的功能详情,可以点击左边超链接到其官网查阅,这里不赘述。

3.2 安装Tyk API网关

下面我们就来安装一下Tyk API网关,我们直接在VM上安装,VM上的环境是CentOS 7.9。Tyk API提供了很多中安装方法,这里使用CentOS的yum包管理工具安装Tyk API网关,大体步骤如下(演示均以root权限操作)。

3.2.1 创建tyk gateway软件源

默认的yum repo中是不包含tyk gateway的,我们需要在/etc/yum.repos.d下面创建一个新的源,即新建一个tyk_tyk-gateway.repo文件,其内容如下:

[tyk_tyk-gateway]
name=tyk_tyk-gateway
baseurl=https://packagecloud.io/tyk/tyk-gateway/el/7/$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/tyk/tyk-gateway/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

[tyk_tyk-gateway-source]
name=tyk_tyk-gateway-source
baseurl=https://packagecloud.io/tyk/tyk-gateway/el/7/SRPMS
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/tyk/tyk-gateway/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

接下来我们执行下面命令来创建tyk_tyk-gateway这个repo的YUM缓存:

$yum -q makecache -y --disablerepo='*' --enablerepo='tyk_tyk-gateway'
导入 GPG key 0x5FB83118:
 用户ID     : "https://packagecloud.io/tyk/tyk-gateway (https://packagecloud.io/docs#gpg_signing) <support@packagecloud.io>"
 指纹       : 9179 6215 a875 8c40 ab57 5f03 87be 71bd 5fb8 3118
 来自       : https://packagecloud.io/tyk/tyk-gateway/gpgkey

repo配置和缓存完毕后,我们就可以安装Tyk API Gateway了:

$yum install -y tyk-gateway

安装后的tky-gateway将以一个systemd daemon服务的形式存在于主机上,程序意外退出或虚机重启后,该服务也会被systemd自动拉起。通过systemctl status命令可以查看服务的运行状态:

# systemctl status tyk-gateway
● tyk-gateway.service - Tyk API Gateway
   Loaded: loaded (/usr/lib/systemd/system/tyk-gateway.service; enabled; vendor preset: disabled)
   Active: active (running) since 日 2023-11-19 20:22:44 CST; 12min ago
 Main PID: 29306 (tyk)
    Tasks: 13
   Memory: 19.6M
   CGroup: /system.slice/tyk-gateway.service
           └─29306 /opt/tyk-gateway/tyk --conf /opt/tyk-gateway/tyk.conf

11月 19 20:34:54 iZ2ze18rmx2avqb5xgb4omZ tyk[29306]: time="Nov 19 20:34:54" level=error msg="Connection to Redis faile...b-sub
11月 19 20:35:04 iZ2ze18rmx2avqb5xgb4omZ tyk[29306]: time="Nov 19 20:35:04" level=error msg="cannot set key in pollerC...ured"
11月 19 20:35:04 iZ2ze18rmx2avqb5xgb4omZ tyk[29306]: time="Nov 19 20:35:04" level=error msg="Redis health check failed...=main
Hint: Some lines were ellipsized, use -l to show in full.

3.2.2 安装redis

我们看到tyk-gateway已经成功启动,但从其服务日志来看,它在连接redis时报错了!tyk gateway默认将数据存储在redis中,为了让tyk gateway正常运行,我们还需要安装redis!这里我们使用容器的方式安装和运行一个redis服务:

$docker pull redis:6.2.14-alpine3.18
$docker run -d --name my-redis -p 6379:6379 redis:6.2.14-alpine3.18
e5d1ec8d5f5c09023d1a4dd7d31d293b2d7147f1d9a01cff8eff077c93a9dab7

拉取并运行redis后,我们通过redis-cli验证一下与redis server的连接:

# docker run -it --rm redis:6.2.14-alpine3.18  redis-cli -h 192.168.0.24
192.168.0.24:6379>

我们看到可以正常连接!但此时Tyk Gateway仍然无法与redis正常连接,我们还需要对Tyk Gateway做一些配置调整!

3.2.3 配置Tyk Gateway

yum默认将Tyk Gateway安装到/opt/tyk-gateway下面,这个路径下的文件布局如下:

$tree -F -L 2 .
.
├── apps/
│   └── app_sample.json
├── coprocess/
│   ├── api.h
│   ├── bindings/
│   ├── coprocess_common.pb.go
│   ├── coprocess_mini_request_object.pb.go
│   ├── coprocess_object_grpc.pb.go
│   ├── coprocess_object.pb.go
│   ├── coprocess_response_object.pb.go
│   ├── coprocess_return_overrides.pb.go
│   ├── coprocess_session_state.pb.go
│   ├── coprocess_test.go
│   ├── dispatcher.go
│   ├── grpc/
│   ├── lua/
│   ├── proto/
│   ├── python/
│   └── README.md
├── event_handlers/
│   └── sample/
├── install/
│   ├── before_install.sh*
│   ├── data/
│   ├── init_local.sh
│   ├── inits/
│   ├── post_install.sh*
│   ├── post_remove.sh*
│   ├── post_trans.sh
│   └── setup.sh*
├── middleware/
│   ├── ottoAuthExample.js
│   ├── sampleMiddleware.js
│   ├── samplePostProcessMiddleware.js
│   ├── samplePreProcessMiddleware.js
│   ├── testPostVirtual.js
│   ├── testVirtual.js
│   └── waf.js
├── policies/
│   └── policies.json
├── templates/
│   ├── breaker_webhook.json
│   ├── default_webhook.json
│   ├── error.json
│   ├── monitor_template.json
│   └── playground/
├── tyk*
└── tyk.conf

其中tyk.conf就是tyk gateway的配置文件,我们先看看其默认的内容:

$cat /opt/tyk-gateway/tyk.conf
{
  "listen_address": "",
  "listen_port": 8080,
  "secret": "xxxxxx",
  "template_path": "/opt/tyk-gateway/templates",
  "use_db_app_configs": false,
  "app_path": "/opt/tyk-gateway/apps",
  "middleware_path": "/opt/tyk-gateway/middleware",
  "storage": {
    "type": "redis",
    "host": "redis",
    "port": 6379,
    "username": "",
    "password": "",
    "database": 0,
    "optimisation_max_idle": 2000,
    "optimisation_max_active": 4000
  },
  "enable_analytics": false,
  "analytics_config": {
    "type": "",
    "ignored_ips": []
  },
  "dns_cache": {
    "enabled": false,
    "ttl": 3600,
    "check_interval": 60
  },
  "allow_master_keys": false,
  "policies": {
    "policy_source": "file"
  },
  "hash_keys": true,
  "hash_key_function": "murmur64",
  "suppress_redis_signal_reload": false,
  "force_global_session_lifetime": false,
  "max_idle_connections_per_host": 500
}

我们看到:storage下面存储了redis的配置信息,我们需要将redis的host配置修改为我们的VM地址:

    "host": "192.168.0.24",

然后重启Tyk Gateway服务:

$systemctl daemon-reload
$systemctl restart tyk-gateway

之后,我们再查看tyk gateway的运行状态:

systemctl status tyk-gateway
● tyk-gateway.service - Tyk API Gateway
   Loaded: loaded (/usr/lib/systemd/system/tyk-gateway.service; enabled; vendor preset: disabled)
   Active: active (running) since 一 2023-11-20 06:54:07 CST; 41s ago
 Main PID: 20827 (tyk)
    Tasks: 15
   Memory: 24.8M
   CGroup: /system.slice/tyk-gateway.service
           └─20827 /opt/tyk-gateway/tyk --conf /opt/tyk-gateway/tyk.conf

11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Loading API configurations...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Tracking hostname" api_nam...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Initialising Tyk REST API ...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="API bind on custom port:0"...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Checking security policy: ...fault
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="API Loaded" api_id=1 api_n...ip=--
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Loading uptime tests..." p...k-mgr
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="Initialised API Definition...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=warning msg="All APIs are protected ...=main
11月 20 06:54:07 iZ2ze18rmx2avqb5xgb4omZ tyk[20827]: time="Nov 20 06:54:07" level=info msg="API reload complete" prefix=main
Hint: Some lines were ellipsized, use -l to show in full.

从服务日志来看,现在Tyk Gateway可以正常连接redis并提供服务了!我们也可以通过下面的命令验证网关的运行状态:

$curl localhost:8080/hello
{"status":"pass","version":"5.2.1","description":"Tyk GW","details":{"redis":{"status":"pass","componentType":"datastore","time":"2023-11-20T06:58:57+08:00"}}}

“/hello”是Tyk Gateway的内置路由,由Tyk网关自己提供服务。

到这里Tyk Gateway的安装和简单配置就结束了,接下来,我们就来看看API Gateway的主要功能特性,并借助Tyk Gateway来展示一下这些功能特性。

注:查看Tyk Gateway的运行日志,可以使用journalctl -u tyk-gateway -f命令实时follow最新日志输出。

3.3 功能特性:请求转发与路由

请求转发和路由是API Gateway的主要功能特性之一,API Gateway可以根据请求的路径、方法、查询参数等信息将请求转发到相应的后端服务,其内核与反向代理类似,不同之处在于API Gateway增加了“API”这层抽象,更加专注于构建、管理和增强API。

下面我们来看看Tyk如何配置API路由,我们首先创建一个新API。

3.3.1 创建一个新API

Tyk开源版支持两种创建API的方式,一种是通过调用Tyk的控制类API,一种则是通过传统的配置文件,放入特定目录下。无论哪种方式添加完API,最终都要通过Tyk Gateway热加载(hot reload)或重启才能生效。

注:Tyk Gateway的商业版本提供Dashboard,可以以图形化的方式管理API,并且商业版本的API定义会放在Postgres或MongoDB中,我们这里用开源版本,只能手工管理了,并且API定义只能放在文件中。

下面,我们就来在Tyk上创建一个新的API路由,该路由示例的示意图如下:

在未添加新API之前,我们使用curl访问一下该API路径:

$curl localhost:8080/api/v1/no-authn
Not Found

Tyk Gateway由于找不到API路由,返回Not Found。接下来,我们采用调用tyk gateway API的方式来添加路由:

$curl -v -H "x-tyk-authorization: {tyk gateway secret}" \
  -s \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
    "name": "no-authn-v1",
    "slug": "no-authn-v1",
    "api_id": "no-authn-v1",
    "org_id": "1",
    "use_keyless": true,
    "auth": {
      "auth_header_name": "Authorization"
    },
    "definition": {
      "location": "header",
      "key": "x-api-version"
    },
    "version_data": {
      "not_versioned": true,
      "versions": {
        "Default": {
          "name": "Default",
          "use_extended_paths": true
        }
      }
    },
    "proxy": {
      "listen_path": "/api/v1/no-authn",
      "target_url": "http://localhost:18081/",
      "strip_listen_path": true
    },
    "active": true
}' http://localhost:8080/tyk/apis | python -mjson.tool 

* About to connect() to localhost port 8080 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> POST /tyk/apis HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8080
> Accept: */*
> x-tyk-authorization: {tyk gateway secret}
> Content-Type: application/json
> Content-Length: 797
>
} [data not shown]
* upload completely sent off: 797 out of 797 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Wed, 22 Nov 2023 05:38:40 GMT
< Content-Length: 53
<
{ [data not shown]
* Connection #0 to host localhost left intact
{
    "action": "added",
    "key": "no-authn-v1",
    "status": "ok"
}

从curl返回结果我们看到:API已经被成功添加。这时tyk gateway的安装目录/opt/tyk-gateway的子目录apps下会新增一个名为no-authn-v1.json的配置文件,这个文件内容较多,有300行,这里就不贴出来了,这个文件就是新增的no-authn API的定义文件

不过此刻,Tyk Gateway还需热加载后才能为新的API提供服务,调用下面API可以触发Tyk Gateway的热加载:

$curl -H "x-tyk-authorization: {tyk gateway secret}" -s http://localhost:8080/tyk/reload/group | python -mjson.tool
{
    "message": "",
    "status": "ok"
}

注:即便触发热加载成功,但如果body中的json格式错,比如多了一个结尾逗号,Tyk Gateway是不会报错的!

API路由创建完毕并生效后,我们再来访问一下API:

$ curl localhost:8080/api/v1/no-authn
{
    "error": "There was a problem proxying the request"
}

我们看到:Tyk Gateway返回的已经不是“Not Found”了!现在我们创建一下no-authn这个API服务,考虑到适配更多后续示例,这里建立这样一个http server:

// api-gateway-examples/httpserver

func main() {
    // 解析命令行参数
    port := flag.Int("p", 8080, "Port number")
    apiVersion := flag.String("v", "v1", "API version")
    apiName := flag.String("n", "example", "API name")
    flag.Parse()                                         

    // 注册处理程序
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Println(*r)
        fmt.Fprintf(w, "Welcome api: localhost:%d/%s/%s\n", *port, *apiVersion, *apiName)
    })                                                                                     

    // 启动HTTP服务器
    addr := fmt.Sprintf(":%d", *port)
    log.Printf("Server listening on port %d\n", *port)
    log.Fatal(http.ListenAndServe(addr, nil))
}

我们启动一个该http server的实例:

$go run main.go -p 18081 -v v1 -n no-authn
2023/11/22 22:02:42 Server listening on port 18081

现在我们再通过tyk gateway调用一下no-authn这个API:

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn

我们看到这次路由通了!no-authn API返回了期望的结果!

3.3.2 负载均衡

如果no-authn API存在多个服务实例,Tyk Gateway也可以将请求流量负载均衡到多个no-authn服务实例上去,下图是Tyk Gateway进行请求流量负载均衡的示意图:

要实现负责均衡,我们需要调整no-authn API的定义,这次我们直接修改/opt/tyk-gateway/apps/no-authn-v1.json,变更的配置主要有三项:

// /opt/tyk-gateway/apps/no-authn-v1.json

  "proxy": {
    "preserve_host_header": false,
    "listen_path": "/api/v1/no-authn",
    "target_url": "",                  // (1) 改为""
    "disable_strip_slash": false,
    "strip_listen_path": true,
    "enable_load_balancing": true,     // (2) 改为true
    "target_list": [                   // (3) 填写no-authn服务实例列表
      "http://localhost:18081/",
      "http://localhost:18082/",
      "http://localhost:18083/"
    ],

修改完配置后,调用Tyk的控制类API使之生效,然后我们启动三个no-authn的API实例:

$go run main.go -p 18081 -v v1 -n no-authn
$go run main.go -p 18082 -v v1 -n no-authn
$go run main.go -p 18083 -v v1 -n no-authn

接下来,我们多次调用curl访问no-authn API:

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18083/v1/no-authn

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18083/v1/no-authn

我们看到:Tyk Gateway在no-authn API的各个实例之间做了等权重的轮询。如果我们停掉实例3,再来访问该API,我们将得到下面结果:

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Bad Request

$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Welcome api: localhost:18082/v1/no-authn
$curl localhost:8080/api/v1/no-authn
Bad Request

注:Tyk Gateway商业版通过Dashboard支持配置带权重的RR负载均衡算法

我们看到:实例3已经下线,但Tyk Gateway并不会跳过该已经下线的实例,这在生产环境会给客户端带来不一致的响应。

3.3.3 服务实例存活检测(uptime test)

Tyk Gateway在开启负载均衡的时候,也提供了对后端服务实例的存活检测机制,当某个服务实例down了后,负载均衡机制会绕过该实例将请求发到下一个处于存活状态的实例;而当down机实例恢复后,Tyk Gateway也能及时检测到服务实例上线,并将其加入流量负载调度。

支持存活检测(uptime test)的API定义配置如下:

// /opt/tyk-gateway/apps/no-authn-v1.json

"uptime_tests": {
    "disable": false,
    "poller_group":"",
    "check_list": [
      {
        "url": "http://localhost:18081/"
      },
      {
        "url": "http://localhost:18082/"
      },
      {
        "url": "http://localhost:18083/"
      }
    ],
    "config": {
      "enable_uptime_analytics": true,
      "failure_trigger_sample_size": 3,
      "time_wait": 300,
      "checker_pool_size": 50,
      "expire_utime_after": 0,
      "service_discovery": {
        "use_discovery_service": false,
        "query_endpoint": "",
        "use_nested_query": false,
        "parent_data_path": "",
        "data_path": "",
        "port_data_path": "",
        "target_path": "",
        "use_target_list": false,
        "cache_disabled": false,
        "cache_timeout": 0,
        "endpoint_returns_list": false
      },
      "recheck_wait": 0
    }
}

"proxy": {
    ... ...
    "enable_load_balancing": true,
    "target_list": [
      "http://localhost:18081/",
      "http://localhost:18082/",
      "http://localhost:18083/"
    ],
    "check_host_against_uptime_tests": true,
    ... ...
}

我们新增了uptime_tests的配置,uptime_tests的check_list中的url的值要与proxy中target_list中的值完全一样,这样Tyk Gateway才能将二者对应上。另外proxy的check_host_against_uptime_tests要设置为true。

这样配置并生效后,等我们将服务实例3停掉后,后续到no-authn的请求就只会转发到实例1和实例2了。而当恢复实例3运行后,Tyk Gateway又会将流量分担到实例3上。

3.3.4 动态负载均衡

上面负载均衡示例中target_list中的目标实例的IP和端口的手工配置的,而在云原生时代,我们经常会基于容器承载API服务实例,当容器因故退出,并重新启动一个新容器时,IP可能会发生变化,这样上述的手工配置就无法满足要求,这就对API Gateway提出了与服务发现组件集成的要求:通过服务发现组件动态获取服务实例的访问列表,进而实现动态负载均衡

Tyk Gateway内置了主流服务发现组件(比如Etcd、Consul、ZooKeeper等)的对接能力,鉴于环境所限,这里就不举例了,大家可以在Tyk Gateway的服务发现示例文档页面找到与不同服务发现组件对接时的配置示例。

3.3.5 IP访问限制

针对每个API,API网关还提供IP访问限制的特性,比如Tyk Gateway就提供了IP白名单IP黑名单功能,通常二选一开启一种限制即可。

以白名单为例,即凡是在白名单中的IP才被允许访问该API。下面是白名单配置样例:

// /opt/tyk-gateway/apps/no-authn-v1.json

  "enable_ip_whitelisting": true,
  "allowed_ips": ["12.12.12.12", "12.12.12.13", "12.12.12.14"],

生效后,当我们访问no-authn API时,会得到下面错误:

$curl localhost:8080/api/v1/no-authn
{
    "error": "access from this IP has been disallowed"
}

如果开启的是黑名单,那么凡是在黑名单中的IP都被禁止访问该API,下面是黑名单配置样例:

// /opt/tyk-gateway/apps/no-authn-v1.json

  "enable_ip_blacklisting": true,
  "blacklisted_ips": ["12.12.12.12", "12.12.12.13", "12.12.12.14", "127.0.0.1"],

生效后,当我们访问no-authn API时,会得到如下结果:

$curl 127.0.0.1:8080/api/v1/no-authn
{
    "error": "access from this IP has been disallowed"
}

到目前为止,我们的API网关和定义的API都处于“裸奔”状态,因为没有对客户端进行身份认证,任何客户端都可以访问到我们的API,显然这不是我们期望的,接下来,我们就来看看API网关的一个重要功能特性:身份认证与授权。

3.4 功能特性:身份认证和授权

在《通过实例理解Go Web身份认证的几种方式》一文中,我们提到过:建立全局的安全通道是任何身份认证方式的前提

3.4.1 建立安全通道,卸载TLS证书

Tyk Gateway支持在Gateway层面统一配置TLS证书,同时也起到在Gateway卸载TLS证书的作用:

这次我们要在tyk.conf中进行配置,才能在Gateway层面生效。这里我们借用《通过实例理解Go Web身份认证的几种方式》一文中生成的几个证书(大家可以在https://github.com/bigwhite/experiments/tree/master/authn-examples/tls-authn/make_certs下载),并将它们放到/opt/tyk-gateway/certs/下面:

$ls /opt/tyk-gateway/certs/
server-cert.pem  server-key.pem

然后,我们在/opt/tyk-gateway/tyk.conf文件中增加下面配置:

// /opt/tyk-gateway/tyk.conf 

  "http_server_options": {
    "use_ssl": true,
    "certificates": [
      {
        "domain_name": "server.com",
        "cert_file": "./certs/server-cert.pem",
        "key_file": "./certs/server-key.pem"
      }
    ]
  }

之后,重启tyk gateway服务,使得tyk.conf的配置修改生效。

注:在/etc/hosts中设置server.com为127.0.0.1。

现在我们用之前的http方式访问一下no-authn的API:

$curl server.com:8080/api/v1/no-authn
Client sent an HTTP request to an HTTPS server.

由于全局启用了HTTPS,采用http方式的请求将被拒绝。我们换成https方式访问:

// 不验证服务端证书
$curl -k https://server.com:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn

// 验证服务端的自签证书
$curl --cacert ./inter-cert.pem https://server.com:8080/api/v1/no-authn
Welcome api: localhost:18081/v1/no-authn

3.4.2 Mutual TLS双向认证

在《通过实例理解Go Web身份认证的几种方式》一文中,我们介绍的第一种身份认证方式就是TLS双向认证,那么Tyk Gateway对MTLS的支持如何呢?Tyk官方文档提到它既支持client mTLS,也支持upstream mTLS

我们更关心的是client mTLS,即客户端在与Gateway建连后,Gateway会使用Client CA验证客户端的证书!我最初认为这个Client CA的配置是在tyk.conf中,但找了许久,也没有发现配置Client CA的地方。

在no-authn API的定义文件(no-authn-v1.json)中,我们做如下配置改动:

  "use_mutual_tls_auth": true,
  "client_certificates": [
      "/opt/tyk-gateway/certs/inter-cert.pem"
  ],

但使用下面命令访问API时报错:

$curl --key ./client-key.pem --cert ./client-cert.pem --cacert ./inter-cert.pem https://server.com:8080/api/v1/no-authn
{
    "error": "Certificate with SHA256 bc8717c0f2ea5a0b81813abb3ec42ef8f9bf60da251b87243627d65fb0e3887b not allowed"
}

如果将”client_certificates”的配置中的inter-cert.pem改为client-cert.pem,则是可以的,但个人感觉这很奇怪,不符合逻辑,将tyk gateway的文档、issue甚至代码翻了又翻,也没找到合理的配置client CA的位置。

Tyk Gateway支持多种身份认证方式,下面我们来看一种使用较为广泛的方式:JWT Auth。

主要JWT身份认证方式的原理和详情,可以参考我之前的文章《通过实例理解Go Web身份认证的几种方式》。

3.4.3 JWT Token Auth

下面是我为这个示例做的一个示意图:

这是我们日常开发中经常遇到的场景,即通过portal用用户名和密码登录后便可以拿到一个jwt token,然后后续的访问功能API的请求仅携带该jwt token即可。API Gateway对于portal/login API不做任何身份认证;而对后续的功能API请求,通过共享的secret(也称为static secret)对请求中携带的jwt token进行签名验证。

portal/login API由于不进行authn,这样其配置与前面的no-authn API几乎一致,只是API名称、路径和target_list有不同:

// apps/portal-login-v1.json

{
  "name": "portal-login-v1",
  "slug": "portal-login-v1",
  "listen_port": 0,
  "protocol": "",
  "enable_proxy_protocol": false,
  "api_id": "portal-login-v1",
  "org_id": "1",
  "use_keyless": true,
  ... ...
  "proxy": {
    "preserve_host_header": false,
    "listen_path": "/api/v1/portal/login",
    "target_url": "",
    "disable_strip_slash": false,
    "strip_listen_path": true,
    "enable_load_balancing": true,
    "target_list": [
      "http://localhost:28084"
    ],
    "check_host_against_uptime_tests": true,
  ... ...
}

对应的portal login API也不复杂:

// api-gateway-examples/portal-login/main.go

package main

import (
    "log"
    "net/http"
    "time"

    "github.com/golang-jwt/jwt/v5"
)

func main() {
    // 创建一个基本的HTTP服务器
    mux := http.NewServeMux()

    username := "admin"
    password := "123456"
    key := "iamtonybai"

    // for uptime test
    mux.HandleFunc("/health", func(w http.ResponseWriter, req *http.Request) {
        w.WriteHeader(http.StatusOK)
    })

    // login handler
    mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
        // 从请求头中获取Basic Auth认证信息
        user, pass, ok := req.BasicAuth()
        if !ok {
            // 认证失败
            w.WriteHeader(http.StatusUnauthorized)
            return
        }

        // 验证用户名密码
        if user == username && pass == password {
            // 认证成功,生成token
            token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
                "username": username,
                "iat":      jwt.NewNumericDate(time.Now()),
            })
            signedToken, _ := token.SignedString([]byte(key))
            w.Write([]byte(signedToken))
        } else {
            // 认证失败
            http.Error(w, "Invalid username or password", http.StatusUnauthorized)
        }
    })

    // 监听28084端口
    err := http.ListenAndServe(":28084", mux)
    if err != nil {
        log.Fatal(err)
    }
}

运行该login API服务后,我们用curl命令获取一下jwt token:

$curl -u 'admin:123456' -k https://server.com:8080/api/v1/portal/login
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MDA3NTEyODEsInVzZXJuYW1lIjoiYWRtaW4ifQ.-wC8uPsLHDxSXcEMxIxJ8O2l3aWtWtWKvhtmuHmgIMA

现在我们再来建立protected API:

// apps/protected-v1.json

{
  "name": "protected-v1",
  "slug": "protected-v1",
  "listen_port": 0,
  "protocol": "",
  "enable_proxy_protocol": false,
  "api_id": "protected-v1",
  "org_id": "1",
  "use_keyless": false,    // 设置为false, gateway才会进行jwt的验证
  ... ...
  "enable_jwt": true,      // 开启jwt
  "use_standard_auth": false,
  "use_go_plugin_auth": false,
  "enable_coprocess_auth": false,
  "custom_plugin_auth_enabled": false,
  "jwt_signing_method": "hmac",        // 设置alg为hs256
  "jwt_source": "aWFtdG9ueWJhaQ==",    // 设置共享secret: base64("iamtonybai")
  "jwt_identity_base_field": "username", // 设置代表请求中的用户身份的字段,这里我们用username
  "jwt_client_base_field": "",
  "jwt_policy_field_name": "",
  "jwt_default_policies": [
     "5e189590801287e42a6cf5ce"        // 设置security policy,这个似乎是jwt auth必须的
  ],
  "jwt_issued_at_validation_skew": 0,
  "jwt_expires_at_validation_skew": 0,
  "jwt_not_before_validation_skew": 0,
  "jwt_skip_kid": false,
  ... ...
  "version_data": {
    "not_versioned": true,
    "default_version": "",
    "versions": {
      "Default": {
        "name": "Default",
        "expires": "",
        "paths": {
          "ignored": null,
          "white_list": null,
          "black_list": null
        },
        "use_extended_paths": true,
        "extended_paths": {
          "persist_graphql": null
        },
        "global_headers": {
          "username": "$tyk_context.jwt_claims_username" // 设置转发到upstream的请求中的header字段username
        },
        "global_headers_remove": null,
        "global_response_headers": null,
        "global_response_headers_remove": null,
        "ignore_endpoint_case": false,
        "global_size_limit": 0,
        "override_target": ""
      }
    }
  },
  ... ...
  "enable_context_vars": true, // 开启上下文变量
  "config_data": null,
  "config_data_disabled": false,
  "tag_headers": ["username"], // 设置header
  ... ...
}

这个配置就相对复杂许多,也是翻阅了很长时间资料才验证通过的配置。JWT Auth必须有关联的policy设置,我们在tyk gateway开源版中要想设置policy,需要现在tyk.conf中做如下设置:

// /opt/tyk-gateway/tyk.conf

  "policies": {
    "policy_source": "file",
    "policy_record_name": "./policies/policies.json"
  },

而policies/policies.json的内容如下:

// /opt/tyk-gateway/policies/policies.json
{
    "5e189590801287e42a6cf5ce": {
        "rate": 1000,
        "per": 1,
        "quota_max": 100,
        "quota_renewal_rate": 60,
        "access_rights": {
            "protected-v1": {
                "api_name": "protected-v1",
                "api_id": "protected-v1",
                "versions": [
                    "Default"
                ]
            }
        },
        "org_id": "1",
        "hmac_enabled": false
    }
}

上述设置完毕并重启tyk gateway生效后,且protected api服务也已经启动时,我们访问一下该API服务:

$curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MDA3NTEyODEsInVzZXJuYW1lIjoiYWRtaW4ifQ.-wC8uPsLHDxSXcEMxIxJ8O2l3aWtWtWKvhtmuHmgIMA" -k https://server.com:8080/api/v1/protected
invoke protected api ok

我们看到curl发出的请求成功通过了Gateway的验证!并且通过protected API输出的请求信息来看,Gateway成功解析出username,并将其作为Header中的字段传递给了protected API服务实例:

http.Request{Method:"GET", URL:(*url.URL)(0xc0002f6240), Proto:"HTTP/1.1", ProtoMajor:1, ProtoMinor:1, Header:http.Header{"Accept":[]string{"*/*"}, "Accept-Encoding":[]string{"gzip"}, "Authorization":[]string{"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3MDA3NTEyODEsInVzZXJuYW1lIjoiYWRtaW4ifQ.-wC8uPsLHDxSXcEMxIxJ8O2l3aWtWtWKvhtmuHmgIMA"}, "User-Agent":[]string{"curl/7.29.0"}, "Username":[]string{"admin"}, "X-Forwarded-For":[]string{"127.0.0.1"}}, Body:http.noBody{}, GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:0, TransferEncoding:[]string(nil), Close:false, Host:"localhost:28085", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:"[::1]:55583", RequestURI:"/", TLS:(*tls.ConnectionState)(nil), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc0002e34f0)}

如果不携带Authorization头字段或jwt的token是错误的,那么结果将如下所示:

$ curl -k https://server.com:8080/api/v1/protected
{
    "error": "Authorization field missing"
}

$ curl -k -H "Authorization: Bearer xxx" https://server.com:8080/api/v1/protected
{
    "error": "Key not authorized"
}

一旦通过API Gateway的身份认证,上游的API服务就会拿到客户端身份,有了唯一身份后,就可以进行授权操作了,其实policy设置本身也是一种授权访问控制。Tyk Gateway自身也支持RBAC等模型,也支持与OPA(open policy agent)等的集成,但更多是在商业版的tyk dashboard下完成的,这里也就不重点说明了。

下面的Gateway的几个主要功能特性由于试验环境受限以及文章篇幅考量,我不会像上述例子这么细致的说明了,只会简单说明一下。

3.5 功能特性:流量控制与限速

Tyk Gateway内置提供了强大的流量控制功能,可以通过全局级别和API级别的限速来管理请求流量。此外,Tyk Gateway 还支持请求配额(request quota)来限制每个用户或应用程序在一个时间周期内的请求次数。

流量不仅和请求速度和数量有关系,与请求的大小也有关系,Tyk Gateway还支持在全局层面和API层面设置Request的size limit,以避免超大包对网关运行造成不良影响。

3.6 功能特性:高可用与容错处理

在许多情况下,我们要为客户确保服务水平(service level),比如:最大往返时间、最大响应时延等。Tyk Gateway提供了一系列功能,可帮助我们确保网关的高可用运行和SLA服务水平。

Tyk支持健康检查,这对于确定Tyk Gateway的状态极为重要,没有健康检查,就很难知道网关的实际运行状态如何。

Tyk Gateway还内置了断路器(circuit breaker),这个断路器是基于比例的,因此如果y个请求中的x请求都失败了,断路器就会跳闸,例如,如果x = 10,y = 100,则阈值百分比为10%。当失败比例到达10%时,断路器就会切断流量,同时跳闸还会触发一个事件,我们可以记录和处理该事件。

当upstream的服务响应迟迟不归时,Tyk Gateway还可以设置强制超时,可以确保服务始终在给定时间内响应。这在高可用性系统中非常重要,因为在这种系统中,响应性能至关重要,这样才能干净利落地处理错误。

3.7 功能特性:监控与可观测性

微服务时代,可观测性对运维以及系统高可用的重要性不言而喻。Tyk Gateway在多年的演化过程中,也逐渐增加了对可观测的支持,

可观测主要分三大块:

  • log

Tyk Gateway支持设置输出日志的级别(log level),默认是info级别。Tyk输出的是结构化日志,这使得它可以很好的与其他日志收集查询系统集成,Tyk支持与主流的日志收集工具对接,包括:logstash、sentry、Graylog、Syslog等。

  • metrics

度量数据是反映网关系统健康状况、错误计数和类型、IT基础设施(服务器、虚拟机、容器、数据库和其他后端组件)及其他流程的硬件资源数据的重要参考。运维团队可以通过使用监控工具来利用实时度量的数据,识别运行趋势、在系统故障时设置警报、确定问题的根本原因并缓解问题。

Tyk Gateway内置了对主流metrics采集方案Prometheus+Grafana的支持,可以在网关层面以及对API进行实时度量数据采集和展示。

  • tracing

Tyk Gateway从5.2版本开始支持了与服务Tracing界的标准:OpenTelemetry的集成,这样你可以使用多种支持OpenTelemetry的Tracing后端,比如Jaeger、Datadog等。Tracing可在Gateway层面开启,也可以延展到API层面。

4. 小结

本文对已经相对成熟的API网关技术做了回顾,对API网关的演进阶段、主流特性以及当前市面上的主流API网关进行了简要说明,并以Go实现的Tyk Gateway社区开源版为例,以示例方式对API网关的主要功能做了介绍。

总体而言,Tyk Gateway是一款功能强大,社区相对活跃并有商业公司支持的产品,文档很丰富,但从实际使用层面,这些文档对Tyk社区版本的使用者来说并不友好,指导性不足(更多用商业版的Dashboard说明,与配置文件难于对应),就像本文例子中那样,为了搞定JWT认证,笔者着实花了不少时间查阅资料,甚至阅读源码。

Tyk Gateway的配置设计平坦,没有层次和逻辑,感觉是随着时间随意“堆砌”上去的。并且配置文件更新时,如果出现格式问题,Tyk Gateway并不报错,让人难于确定配置是否真正生效了,只能用Tyk Gateway的控制API去查询结果来验证,非常繁琐低效。

本文涉及的源码可以在这里下载,文中涉及的一些tyk gateway api和security policy的配置也可以在其中查看。

5. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

提高您的kubectl生产力(第三部分):集群上下文切换、使用别名减少输入和插件扩展

本文翻译自《Boosting your kubectl productivity》

第一部分:什么是kubectl?
第二部分:命令完成、资源规范快速查看和自定义列输出格式什么是kubectl?

4. 轻松切换集群和名称空间

当kubectl必须向Kubernetes API发出请求时,它会读取系统上所谓的kubeconfig文件,以获取它需要访问的所有连接参数并向API服务器发出请求。

默认的kubeconfig文件是~/.kube/config。此文件通常由某个命令自动创建或更新(例如,aws eks update-kubeconfig或者gcloud container clusters get-credentials,如果您使用托管Kubernetes服务)。

使用多个集群时,您的kubeconfig文件中配置了多个集群的连接参数。这意味着,您需要一种方法来告诉kubectl 您希望它连接到哪个集群。

在集群中,您可以设置多个名称空间(名称空间是物理集群中的一种“虚拟”集群)。Kubectl也会从kubeconfig文件确定用于请求的命名空间。因此,您需要一种方法来告诉kubectl 您希望它使用哪个命名空间。

本节将介绍kubectl切换集群上下文的原理以及它是如何轻松完成的。

请注意,您还可以在KUBECONFIG环境变量中列出多个kubeconfig文件。在这种情况下,所有这些文件将在执行时合并为单个有效配置。您还可以使用–kubeconfig指定kubectl命令的选项以覆盖默认的kubeconfig文件。请参阅官方文档

Kubeconfig文件

让我们看看kubeconfig文件实际包含的内容:

img{512x368}

如您所见,kubeconfig文件由一组上下文组成。上下文包含以下三个元素:

  • 集群(cluster):集群的API服务器的URL
  • 用户(user):集群的特定用户的身份验证凭据
  • 命名空间(namespace):连接到集群时使用的命名空间

实际上,人们经常在他们的kubeconfig文件中为每个集群的配置一个上下文。但是,你也可以为每个集群配置多个上下文,其用户或命名空间不同。但这似乎不太常见,因此通常在集群和上下文之间存在一对一的映射。

在任何给定时间,其中一个上下文被设置为当前上下文(通过kubeconfig文件中的专用字段):

img{512x368}

当kubectl读取kubeconfig文件时,它总是使用当前上下文中的信息。因此,在上面的例子中,kubectl将连接到Hare集群。

因此,要切换到另一个集群,您只需更改kubeconfig文件中的当前上下文:

img{512x368}

在上面的示例中,kubectl现在将连接到Fox集群。

要切换到同一集群中的另一个命名空间,您可以更改当前上下文的命名空间元素的值:

img{512x368}

在上面的示例中,kubectl现在将使用Fox群集中的Prod命名空间(而不是之前设置的Test命名空间)。

请注意,kubectl还提供了–cluster,–user和–namespace,以及–context允许您覆盖单个元素和当前上下文本身的选项,无论kubeconfig文件中设置了什么。见kubectl options。

理论上,您可以通过手动编辑kubeconfig文件来执行这些更改。但当然这很乏味。以下部分介绍了允许您自动执行这些更改的各种工具。

使用kubectx

kubectx是一种非常流行的用于在集群和命名空间之间切换的工具。

此工具提供允许您分别更改当前上下文和命名空间的命令kubectx和kubens命令。

如上所述,如果每个集群只有一个上下文,则更改当前上下文意味着更改集群。

在这里,您可以看到这两个命令:

img{512x368}

在表象之下,这些命令只是编辑kubeconfig文件,如上一节中所述。

要安装kubectx,只需按照GitHub页面上的说明操作即可

kubectx和kubens都通过完成交办提供命令完成(command completion)。这允许您自动完成上下文名称和名称空间,这样您就不必完全键入它们。您也可以在GitHub页面上找到设置完成的说明。

kubectx的另一个有用功能是交互模式。这与fzf工具结合使用,您必须单独安装(事实上,安装fzf,将自动启用kubectx交互模式)。交互模式允许您通过交互式模糊搜索界面(由fzf提供)选择目标上下文或命名空间。

使用shell别名

实际上,您并不需要单独的工具来更改当前上下文和命名空间,因为kubectl也提供了执行此操作的命令。特别是,该kubectl config命令提供了用于编辑kubeconfig文件的子命令。这里是其中的一些:

  • kubectl config get-contexts:列出所有上下文
  • kubectl config current-context:获取当前上下文
  • kubectl config use-context:更改当前上下文
  • kubectl config set-context:更改上下文的元素

但是,直接使用这些命令并不是很方便,因为它们很难输入。但是你可以做的是将它们包装成可以更容易执行的shell别名。

我基于这些命令创建了一组别名,这些命令提供了与kubectx类似的功能。在这里你可以看到他们的行动:

img{512x368}

请注意,别名使用fzf来提供交互式模糊搜索界面(如kubectx的交互模式)。这意味着,您需要安装fzf才能使用这些别名。

以下是别名的定义:

# Get current context
alias krc='kubectl config current-context'
# List all contexts
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;\|^  $(krc)$|s/ /*/"'
# Change current context
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Get current namespace
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print \$5}" | sed "s/^$/default/"'
# List all namespaces
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;\|^  $(krn)$|s/ /*/"'
# Change current namespace
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

要安装这些别名,你只需要在上面定义添加到您的~/.bashrc或~/.zshrc文件,并重新加载你的shell(source ~/.bashrc or source ~/.zshrc)!

使用插件

Kubectl允许安装可以像本机命令一样调用的插件。例如,您可以安装名为kubectl-foo的插件,然后将其调用为kubectl foo。

Kubectl插件将在本文的后续部分中详细介绍。

能够像这样更改当前上下文和命名空间不是很好吗?例如,运行kubectl ctx以更改上下文,kubectl ns更改名称空间?

我创建了两个允许这样做的插件:

在内部,插件构建在上一节的别名之上。

在这里你可以看到插件的实际效果:

img{512x368}

请注意,插件使用fzf来提供交互式模糊搜索界面。这意味着,您需要安装fzf才能使用这些插件。

要安装插件,你只需要将名为的shell脚本kubectl-ctxkubectl-ns的脚本下载以到PATH下的任何目录中,并使他们具备可执行权限(例如,使用chmod +x)。紧接着,你就应该能够使用kubectl ctx和kubectl ns!

5. 使用自动生成的别名减少输入

Shell别名通常是减少手工输入的好方法。该kubectl-aliases项目就是以这个想法为核心,并提供800多个kubectl命令别名。

您可能想知道如何记住800个别名?实际上,您不需要记住它们,因为它们都是根据一个简单的方案生成的,下面将显示一些示例别名:

img{512x368}

如您所见,别名由组件(component)组成,每个组件代表kubectl命令的特定元素。每个别名可以有一个用于基本命令,操作和资源的组件,以及用于选项的多个组件,您只需根据上述方案从左到右“填充”这些组件。

请注意,目前完全详细的方案在GitHub页面上。在那里,您还可以找到别名的完整列表

例如,别名kgpooyamlall代表命令kubectl get pods -o yaml –all-namespaces:

img{512x368}

请注意,大多数选项组件的相对顺序无关紧要。所以,kgpooyamlall相当于kgpoalloyaml。

您不需要将所有组件用于别名。例如k,kg,klo,ksys,或者kgpo是有效的别名也。此外,您可以在命令行中将别名与其他单词组合使用。

例如,您可以k proxy用于运行kubectl proxy:

img{512x368}

或者您可以kg roles用于运行kubectl get roles(目前不存在Roles资源的别名组件):

img{512x368}

要获取特定Pod,您可以使用kgpo my-pod以运行kubectl get pod my-pod:

img{512x368}

请注意,某些别名甚至需要在命令行上的进一步参数。例如,kgpol别名代表kubectl get pods -l。该-l选项需要一个参数(标签规范)。所以,你必须使用这个别名,例如,像这样:

img{512x368}

出于这个原因,你可以使用a,f以及l只在一个别名的结尾部分。

一般来说,一旦你掌握了这个方案,就可以直观地从你想要执行的命令中推断出别名,并节省大量的输入!

安装

要安装kubectl-别名,你只需要下载.kubectl-aliasesGitHub文件,并在你的~/.bashrc或~/.zshrc文件生效它:

source ~/.kubectl_aliases

重新加载shell后,您应该能够使用所有800个kubectl别名!

命令完成

如您所见,您经常在命令行上向别名添加更多单词。例如:

$kgpooyaml test-pod-d4b77b989

如果你使用kubectl命令完成,那么你可能习惯于自动完成资源名称之类的事情。但是当你使用别名时,你还可以这样做吗?

这是一个重要的问题,因为如果它不起作用,那将消除这些别名的一些好处!

答案取决于您使用的shell。

对于Zsh,完成对于别名是开箱即用的。

不幸的是,对于Bash,默认情况下,对于别名,完成功能不起作用。好消息是它可以通过一些额外的步骤来完成。下一节将介绍如何执行此操作。

在Bash中启用别名的完成

Bash的问题在于它尝试在别名上尝试完成(每当你按Tab键),而不是在别名命令(如Zsh)上。由于您没有所有800个别名的完成脚本,因此不起作用。

complete-alias项目提供了解决这个问题的通用解决方案。它使用别名的完成机制,在内部将别名扩展到别名命令,并返回扩展命令的完成建议。这意味着,它使别名的完成行为与别名命令完全相同。

在下文中,我将首先解释如何安装complete-alias,然后如何配置它以启用所有kubectl别名的完成。

安装complete-alias

首先,complete-alias依赖于bash-completion。因此,您需要确保在安装complete-alias之前安装了bash-completion。早先已经为Linux和macOS提供了相关说明。

对于macOS用户的重要注意事项:与kubectl完成脚本一样,complete-alias不适用于Bash 3.2,这是macOS上Bash的默认版本。特别是,complete-alias依赖于bash-completion v2(brew install bash-completion@2),它至少需要Bash 4.1。这意味着,要在macOS上使用complete-alias,您需要安装较新版本的Bash。

要安装complete-alias,您只需bash_completion.sh从GitHub存储库下载脚本,并将其在您的~/.bashrc文件中source:

source ~/bash_completion.sh

重新加载shell后,应正确安装complete-alias。

启用kubectl别名的完成

从技术上讲,complete-alias提供了_complete_aliasshell函数。此函数检查别名并返回别名命令的完成建议。

要将其与特定别名挂钩,您必须使用completeBash内置来设置别名_complete_alias的完成功能。

举个例子,我们k来看一下代表kubectl命令的别名。要设置_complete_alias此别名的完成功能,您必须执行以下命令:

$complete -F _complete_alias k

这样做的结果是,无论何时在k别名上自动完成,_complete_alias都会调用该函数,该函数检查别名并返回kubectl命令的完成建议。

作为另一个例子,让我们采用kg代表的别名kubectl get:

$complete -F _complete_alias kg

同样,这样做的结果是,当您自动完成时kg,您将获得与之相同的完成建议kubectl get。

请注意,可以以这种方式对系统上的任何别名使用complete-alias。

因此,要启用所有 kubectl别名的完成,您只需为每个别名运行上述命令。以下代码片段完全相同(假设您安装了kubectl-aliases ~/.kubectl-aliases):

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); do
  complete -F _complete_alias "$_a"
done

只需将此片段添加到您的~/.bashrc文件中,重新加载您的shell,现在您应该可以使用所有800 kubectl别名的完成!

6. 使用插件扩展kubectl

版本1.12开始,kubectl包含一个插件机制,允许您使用自定义命令扩展kubectl。

以下是kubectl插件的示例,可以调用为kubectl hello:

$ kubectl hello
Hello, I'm a kubectl plugin!

kubectl插件机制将严格遵循Git插件机制的设计。

本节将向您展示如何安装插件,您可以在哪里找到现有的插件,以及如何创建自己的插件。

安装插件

Kubectl插件作为简单的可执行文件分发,其名称的形式为kubectl-x。前缀kubectl-是必需的,接下来是允许调用插件的新kubectl子命令。

例如,上面显示的hello插件将作为名为的文件分发kubectl-hello。

安装插件,您只需将kubectl-x文件复制到您的任何目录中PATH并使其可执行(例如,使用chmod +x)。之后,您可以立即调用该插件kubectl x。

您可以使用以下命令列出系统上当前安装的所有插件:

$kubectl plugin list

如果您有多个具有相同名称的插件,或者存在不可执行的插件文件,则此命令还会显示警告。

使用krew查找和安装插件

Kubectl插件可以像软件包一样共享和重用。但是在哪里可以找到其他人共享的插件?

krew项目旨在提供一个统一的解决方案,共享,查找,安装和管理kubectl插件。该项目将自己称为“kubectl插件的包管理器”(名称krew是brew的提示)。

Krew 以kubectl插件索引为中心,您可以从中选择和安装。

$ kubectl krew search | less
$ kubectl krew search view
$ kubectl krew info view-utilization
$ kubectl krew install view-utilization
$ kubectl krew list

如您所见,krew本身是一个kubectl插件。这意味着,安装krew本质上就像安装任何其他kubectl插件一样。您可以在GitHub页面上找到krew的详细安装说明。

最重要的krew命令如下:

# Search the krew index (with an optional search query)
$ kubectl krew search [<query>]
# Display information about a plugin
$ kubectl krew info <plugin>
# Install a plugin
$ kubectl krew install <plugin>
# Upgrade all plugins to the newest versions
$ kubectl krew upgrade
# List all plugins that have been installed with krew
$ kubectl krew list
# Uninstall a plugin
$ kubectl krew remove <plugin>

请注意,使用krew安装插件并不妨碍以传统方式安装插件。即使你使用krew,你仍然可以通过其他方式安装你在其他地方找到的插件(或自己创建)。

请注意,该kubectl krew list命令仅列出已使用krew安装的插件,而该kubectl plugin list命令列出了所有插件,即使用krew安装的插件和以其他方式安装的插件。

在其他地方寻找插件

Krew仍然是一个年轻的项目,目前krew索引中只有大约30个插件。如果你在那里找不到你需要的东西,你可以在其他地方寻找插件,例如,在GitHub上。

我建议查看kubectl-plugins GitHub主题。你会发现有几十个可用的插件值得一看。

创建自己的插件

当然,您可以创建自己的kubectl插件,这很容易实现。

您只需创建一个可执行文件,执行您想要的操作,为其命名kubectl-x,然后按上述方法安装它。

可执行文件可以是任何类型,Bash脚本,编译的Go程序,Python脚本,它确实无关紧要。唯一的要求是它可以由操作系统直接执行。

我们现在创建一个示例插件。在上部分中,您使用kubectl命令列出每个pod的容器镜像。您可以轻松地将此命令转换为可以调用的插件,比如说kubectl img。

为此,只需创建一个名为kubectl-img以下内容的文件:

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

现在使文件可执行,chmod +x kubectl-img并将其移动到您的任何PATH中的目录。之后,您可以立即开始使用该插件kubectl img!

如上所述,kubectl插件可以用任何编程语言或脚本语言编写。如果使用shell脚本,则可以从插件轻松调用kubectl。但是,您可以使用实际编程语言编写更复杂的插件,例如,使用Kubernetes客户端库。如果使用Go,您还可以使用cli-runtime库,它专门用于编写kubectl插件。

分享你的插件

如果您认为其中一个插件可能对其他人有用,请随时在GitHub上分享。确保将其添加到kubectl-plugins主题中,以便其他人可以找到它。

您还可以请求将您的插件添加到krew索引中。您可以在krew GitHub存储库中找到有关如何执行此操作的说明。

命令完成

目前,插件机制遗憾的是还不支持命令完成。这意味着您需要完全键入插件名称以及插件的任何参数。

但是,在kubectl GitHub存储库中有一个处于open状态的功能请求issue。因此,此功能有可能在将来的某个时间得到实现。

以上就是有关kubectl高效使用的所有内容了!


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats