共计 5023 个字符，预计需要花费 13 分钟才能阅读完成。
Apache APISIX Ingress 概览
Apache APISIX Ingress 定义
在 K8s 生态中，Ingress 作为示意 K8s 流量入口的一种资源，想要让其失效，就须要有一个 Ingress Controller 去监听 K8s 中的 Ingress 资源，并对这些资源进行相应规定的解析和理论承载流量。在当下趋势中，像 Kubernetes Ingress Nginx 就是应用最宽泛的 Ingress Controller 实现。
而 APISIX Ingress 则是另一种 Ingress Controller 的实现。跟 Kubernetes Ingress Nginx 的区别次要在于 APISIX Ingress 是以 Apache APISIX 作为理论承载业务流量的数据面。如下图所示，当用户申请到具体的某一个服务 /API/ 网页时，通过内部代理将整个业务流量 / 用户申请传输到 K8s 集群，而后通过 APISIX Ingress 进行后续解决。
从上图能够看到，APISIX Ingress 分成了两局部。一部分是 APISIX Ingress Controller，作为管制面它将实现配置管理与散发。另一部分 APISIX Proxy Pod 负责承载业务流量，它是通过 CRD(Custom Resource Definitions) 的形式实现的。Apache APISIX Ingress 除了反对自定义资源外，还反对原生的 K8s Ingress 资源。
Apache APISIX 简述
前边咱们提到了 APISIX Ingress 是采纳 Apache APISIX 作为理论承载业务流量的数据面，那么 Apache APISIX 我的项目又是做什么的呢？
Apache APISIX 是 Apache 基金会旗下的顶级开源我的项目，也是以后最沉闷的开源网关我的项目。作为一个动静、实时、高性能的开源 API 网关，Apache APISIX 提供了负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。
Apache APISIX 能够帮忙企业疾速、平安地解决 API 和微服务流量，比方限流认证、日志平安性能，以及反对丰盛的自定义插件。目前也与很多开源我的项目如 Apache SkyWalking、Prometheus 等之类的组件进行了相干集成。
APISIX Ingress vs K8s Ingress Nginx
因为自己同时参加到了 APISIX Ingress 与 K8s Ingress Nginx 两个我的项目的开发和保护，所以很多人也会问我，这两个我的项目做比拟的话，到底该如何抉择？或者说为什么有了 K8s Ingress Nginx 还要再做 APISIX Ingress。
配置层面
在 APISIX Ingress 中，咱们减少了一些丰盛且灵便的配置，比方通过单个配置文件去实现灰度部署。但在 K8s Ingress Nginx 中去实现如上成果的话，起码也须要有两个 Ingress 资源文件才能够实现。
丰盛度
在丰盛度上，因为 Apache APISIX 自身的自带功能丰富且容许多种插件扩大应用，所以应用 APISIX Ingress 就能够省去本人额定配置性能的繁琐步骤，能够将更多的工夫投入到理论开发中。
架构拆散
APISIX Ingress 采纳了数据面与管制面的拆散架构，所以用户能够抉择将数据面部署在 K8s 集群外部 / 内部。但 K8s Ingress Nginx 是将管制面和数据面放在了同一个 Pod 中，如果 Pod 或管制面呈现一点闪失，整个 Pod 就会挂掉，进而影响到业务流量。
这种架构拆散，给用户提供了比拟不便的部署抉择，同时在业务架构调整场景下，也不便进行相干数据的迁徙与应用。
APISIX Ingress 个性详解
因为 Apache APISIX 是一个全动静的高性能网关，所以在 APISIX Ingress 本身就反对了全动静，包含路由、SSL 证书、上游以及插件等等。
同时 APISIX Ingress 还具备以下个性：
- 反对 CRD，更容易了解申明式配置；同时状态查看可保障疾速把握申明配置的同步状态
- 反对高级路由匹配规定以及自定义资源，可与 Apache APISIX 官网 50 多个插件 & 客户自定义插件进行扩大应用
- 反对 K8s 原生 Ingress 配置
- 反对流量切分
- 反对 gRPC plaintext 与 TCP 4 层代理
- 服务主动注册发现，无惧扩缩容
- 更灵便的负载平衡策略，自带健康检查性能
以下咱们将从 CRD 与自定义资源层面进行具体的介绍。
CRD 扩大
在后面的介绍中咱们提到了 CRD，那么 APISIX Ingress 是如何应用 CRD 扩大的？
从用户层面来看，当 Client 发动申请，达到 Apache APISIX 后，会间接把相应的业务流量传输到后端（如 Service Pod），从而实现转发过程。此过程不须要通过 Ingress Controller，这样做能够保障一旦有问题呈现，或者是进行变更、扩缩容或者迁徙解决等，都不会影响到用户和业务流量。
同时在配置端，用户通过 kubectl apply，可将自定义 CRD 配置利用到 K8s 集群。Ingress Controller 会继续 watch 这些资源变更，来将相应配置利用到 Apache APISIX。
自定义资源
APISIX Ingress 目前曾经反对的自定义资源次要是以下 5 类，波及到路由、上游、消费者、证书相干和集群公共配置的相干类别。
APISIX Route（路由）
自定义资源 APISIX Route 中 spec 属性的顶级配置是 http。但其实 spec 是同时反对两种配置的，一种是下图示例的 spec.http，次要用于 7 层代理；另一种是 spec.stream，用于 4 层代理。在配置文件中，咱们首先为其自定义了一项规定，即 match 下的相干参数。
如上图后端配置示例应用了同一个 Service，理论应用中大家依据场景进行调整即可。须要留神的是，weight 属性是用来配置相干 Service 权重。通过以上配置，从而实现一套残缺的路由自定义资源。
APISIX Upstream（上游）
在配置 APISIX Upstream 时，须要留神 name 的内容要与 K8s 集群的 Service 保持一致，这样能够保障后续 APISIX Ingress Controller 精确匹配其相应流量。
在配置文件中，sspec.loadbalancer 次要负责负载平衡策略的设置，有多种策略模式可供选择。spec.scheme 则是协定类型的配置，目前只反对 HTTP 和 gRPC 协定。spec.healthCheck 次要是对健康检查性能进行设置，比方设置其沉闷状态、失效协定与门路和最终反馈等参数配置。
APISIX Consumer（消费者）
在 APISIX Consumer 配置中，次要是减少了认证相干的性能，比方 spec.authParameter，目前该配置参数反对 BasicAuth 与 KeyAuth 这两种比拟常见的认证类型。
通过 value 可间接去配置相干的 username 和 password，或者间接应用 secret 进行配置，相比前者的明文配置会更平安一些。
APISIX TLS（证书）
APISIX TLS 次要是为了进行证书的治理。如示例所示，用户能够通过 hosts 来配置多个域名，secret 下的参数就是对应的配置证书。
同时 APISIX TLS 还配有 spec.client，用于进行 mTLS 双向认证的配置。
APISIX Config 相干
对于自定义资源反对的 Config 类型咱们会从两个方面进行形容。
一种是 APISIX Cluster Config，它次要用于一些通用配置。目前反对在 K8s 或者 Apache APISIX 中全局应用 Prometheus 插件 / 全局配置 SkyWalking，后续开发中也会去减少一些其余的通用配置。
另一种就是咱们当初正在 PR 中的 APISIX Plugin Config。大家如果感兴趣的话，也能够点击链接来一起参加探讨。Plugin Config 次要是将通用的插件配置对立汇合在一起，比方一些同样的配置，用户就能够通过 APISIX Plugin Config 同时利用在多个路由当中，省去了额定多项独立配置的繁琐步骤。
APISIX Ingress 上手实际
目前大家能够通过 Helm Charts 的形式来进行 APISIX Ingress 的部署。通过一条命令，就能够同时把 Apache APISIX 以及 APISIX Ingress，包含 Apache APISIX 所须要用到的 etcd 全副部署好，步骤非常简单。
实际场景一：流量切分
通过应用 APISIX Ingress 能够实现按比例进行流量切分的成果，具体操作如下：
步骤一：配置 APISIX Upstream
步骤二：配置 APISIX Route
通过在 backends 中去配置 subset 和 weight，来实现用户申请流量进入时的分流。如下图示例就是 90% 的流量会进入到 v1 中，10% 的流量进入到 v2 中。
通过以上两步，就能够非常不便地按比例进行流量切分，实现相似灰度公布等场景需要。
实际场景二：配置认证
如果想在 APISIX Ingress 中为某些路由配置 Basic Auth，能够参考如下操作：
步骤一：创立 APISIX Consumer 资源
如前文所提到的，能够在 APISIX Consumer 配置中减少 basicAuth，并为其指定用户名和明码。
步骤二：配置 APISIX Route，减少相干参数
在自定义资源 APISIX Route 中，通过在后端增加 authentication，将其开启并指定认证类型即可。
通过以上步骤，就能够实现应用 Consumer 去实现相干配置认证。
实际场景三：K8s 资源扩大
正如咱们在结尾提到过的，APISIX Ingress 不仅反对自定义资源，还同时反对 K8s 原生的 Ingress 资源。
如上图是 K8s Ingress 资源。通常状况下如果想要在资源上做 rewrite，能够通过减少 annotation 配置属性。这样当用户携带 httpbin.org 申请时，就能够通过门路 /sample 将它重定向到 /ip。
当上述需要应用 APISIX Ingress 时，只需在 Ingress 减少一个 kubernetes.io/ingress.class:apisix，去指定 APISIX Ingress Controller 去监听这个资源，同时通过配置 k8s.apisix.apache.org/rewrite-target:"/ip"，就能够实现重定向到 /ip 门路。
以上示例只是目前 APISIX Ingress 对于原生 K8s Ingress 反对的一种形式，更多示例大家能够查看具体文档
(https://apisix.apache.org/doc…) 进行参考应用。
将来布局
之后 APISIX Ingress 将会持续在性能与生态上进行更新，目前阶段曾经实现了 APISIX Ingress 与 Cert-manager 集成，后续将逐渐实现以下指标：
- 实现 Kubernetes V1.22+ 与 CRD V1 版本的适配反对（曾经实现，行将在 APISIX Ingress V1.3 版本 中公布）
- 反对 Gateway API（预计在 Q4 阶段实现）
- 扩大新架构，以便于用户在不须要应用 etcd 的状况下，能够失常应用 APISIX Ingress
- 丰盛产品生态，扩大 APISIX Ingress 社区
最初也心愿大家可能多多地参加到我的项目中来，比方每两周的周三下午 2 点都会有一次 APISIX Ingress 社区会议，会跟大家同步一下以后的我的项目停顿或者遇到的问题。大家能够继续关注 Apache APISIX 视频号，届时能够直接参与社区会议直播。
对于作者
张晋涛，Apache APISIX Committer、Kubernetes Ingress Nginx Reviewer，多个云原生开源我的项目的贡献者。
对于 Apache APISIX
Apache APISIX 是一个动静、实时、高性能的开源 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。Apache APISIX 能够帮忙企业疾速、平安的解决 API 和微服务流量，包含网关、Kubernetes Ingress 和服务网格等。
Apache APISIX 落地用户（仅局部）
- Apache APISIX GitHub：https://github.com/apache/apisix
- Apache APISIX 官网：https://apisix.apache.org/
- Apache APISIX 文档：https://apisix.apache.org/zh/…
