Ingress&Egress&Higress
Ingress和Egress的解析 - 不懂123 - 博客园 (cnblogs.com)
Ingress
介绍
每个Service都要有一个负载均衡，所以这个所发实际上既浪费成本又高。作为用户，更希望看到Kubernetes内置一个全局的负载均衡器。然后，通过我们访问的URL，把请求转发给不同的后端。这种全局的，为了代理不同后端Service而设置的负载均衡服务，就是Kubernetes里的Ingress服务。
所以Ingress的功能其实很容易理解：所谓Ingress就是Service的Service
Ingress和Service的区别
- Ingress负载均衡的后端应用是由众多Service组成的集合 本质是一个7层调度器（通过url，httl，https协议进行调度）
- Service负载均衡的后端应用是由众多Pod组成的集合 本质是一个4层调度器(iptables,ipvs进行IP包转发)
使用Kubernetes的Ingress来创建一个统一的负载均衡器，从而实现当用户访问不通过域名时，能够访问到不同的Deployment
最值得我们关注的是rules，在Kubernetes里这个字段叫做ingressRule
IngressRule的Key就叫做:host.它必须是一个标准的域名格式(Fully Qualified Domain Name)的字符串,而不能是IP地址
而host字段定义的值，就是这个Ingress的入口。这也就意味着当用户访问的时候，实际上访问到的是这个Ingress对象，这样Kubernetes就能使用IngressRule来对你的请求进行下一步的转发。
无头服务
在k8s中，service 是用于一组pod的负载均衡和服务发现的，比如后端6个跑着应用程序的pod，使用service就能实现对这6个pod的负载均衡分发客户端请求了，如果pod扩容了，service就会自动发现并把他们假如自己后端请求的endpoint列表中。
无头service就是在定义service时指定 service.spec.clusterIP：None，即没有clusterip,这就是headless service，简称无头service，无头service也有标签选择器，有标签选择器就说明有对应的endpoint。
apiVersion: v1
kind: Service
metadata:
name: kubia-headless
spec:
clusterIP: None #这使得服务成为headless
ports:
- port: 80
targetPort: 8080
selector:
app: kubia为什么要无头service呢？
平时的应用一般由这样2种情况，多个应用实例之间没有区别，比如最常见的nginx反向代理到后端服务器的多个应用上，这些后端应用是没有说明区别的。但是这样情况呢，比如Redis集群，每个Redis节点都是不同的，它们之间相互通行并组成一个集群，这时我们使用普通的service向nginx那样反向代理到多个后端应用就显得不合适了。
使用无头service。如果要搭建6个节点的redis集群（3主3从架构），我们定义service 并不是说要让servic将请求连接负载均衡分发到这6个pod，因为这6个pod的实例都是不同的，他们都跑着不同的应用。这时无头service就派上用场，无头service没有clusterip，直接绑定具体的podIP，无头service经常用于有状态部署。
简单来说可以直接通过dns解析访问pod，在有状态应用下很有用。但是没有clusterIP无法通过Kubernetes内部的负载均衡机制进行流量分发。因此，无头服务通常不适用于需要负载均衡的常规应用程序。它更适用于需要直接访问和发现后端Pod的特定应用场景。
Endpoints
Kubernetes中的Service，它定义了一组Pods的逻辑集合和一个用于访问它们的策略。一个Service的目标Pod通常是由Label Selector老决定的。
Endpoints是一组实际服务的端点集合。一个Endpoint是一个可被访问的服务端点，即一个状态为running的pod可以访问端点。一般pod都不是一个独立存在，所以一组pod的端点合在一起称为Endpoint。只有被Service Selector匹配选中的并且状态为Running的才会被加入到Service同名的Endpoint中。
只有配置了Selector的Service才会自动创建一个同名的endpoints，没有配置的service不会产生Endpoint资源对象
它会被存储在k8s的etcd中，代表一个service对应的所有pod副本的访问地址。当请求到达service时，k8s会根据策略从endpoints中的访问地址中选择一个pod并进行访问和操作。当对应地址发生变动时，k8s会基于监听机制发现变动，并根据变动对endpoints进行更新以便于endpoints资源对象实时代表着从service到pod的访问地址。
自动管理Endpoint对象
手工维护体系外的外部服务（下图）：
IngressController控制器
Ingress Controller会根据你定义的Ingress对象提供对应的代理能力。目前业界常用的反向代理项目Nginx、HAProxy、Envoy、Traefik 等都已经为Kubernetes专门维护了对应的Ingress Controller。
一个Nginx Ingress Controller为你提供服务，其实是一个可以根据Ingress对象和变化代理后端Service的变化，来自动进行更新的Nginx负载均衡器
ingress只能工作在7层，而Service只能工作在4层。所以当你需要再k8s理为应用进行TLS配置等HTTP相关的操作时都必须通过Ingress来进行。
Ingress Controller是一个拥有运行七层调度的应用程序的Pod(比如运行一个NGINX的服务的Pod) nginx pod通过url映射来把请求代理不同的Pod
外部用戶跟Ingress Controller管理的Pod采用https协议进行通信 Ingress Controller管理的Pod跟被它代理的其它Pod采用http协议通信
Ingress Controller管理的Pod实现了https会话卸载器的功能
Ingress资源
- 首先通过无头Service动态关联符合标签选择器选择的后端Pod
- Ingress动态的把service关联的pod地址注入到前端配置upstream中，同时触发主程序重新加载最新的配置文件
pod变化 > service变化 > Ingress变化 > Ingress Control注入配置
- pod的数量或者IP发生变化的时候通过selector选择Pod的service会自动更新
- 因为SErvice是无头Service类型，所以访问service的时候获取的不是VIP而是service被代理的pod地址集合
- Ingress自动更新配置文件 通知nginx主进程重载最新的配置文件
Egress
没有专门的Pod用于处理Egress流量。Egress流量是指从Kubernetes集群内部流出到集群外部的网络流量。
当Pod需要发送Egress流量时，它可以通过正常的网络连接来与外部资源进行通信。这意味着您可以在任何具有网络连接能力的Pod中处理Egress流量，而不需要专门的Pod。
istio访问外部服务
由于默认情况下，来自istio-enable pod的所有出站流量都会重定向到Sidecar代理，集群外部客房问下取决于代理的配置。默认情况下，istio将envoy代理配置为允许传递位置服务的请求。尽管中为入门istio带来了方便，但是，通常情况下，配置更严格的控制是更可取的。
这个任务向您展示了三种访问外部服务的方法：
- 允许 Envoy 代理将请求传递到未在网格内配置过的服务。
- 配置 Service Entry 以提供对外部服务的受控访问。
- 对于特定范围的 IP，完全绕过 Envoy 代理。
istio出口网关
控制Egress流量任务展示了如何配置Istio以允许网格内部的应用程序访问外部HTTP和HTTPS服务但那个任务实际上是通过sidecar直接调用外部服务。
Istio 使用 Ingress 和 Egress Gateway 配置运行在服务网格边缘的负载均衡。Ingress Gateway 允许您定义网格所有入站流量的入口。 Egress Gateway 是一个与 Ingress Gateway 对称的概念，它定义了网格的出口。 Egress Gateway 允许您将 Istio 的功能（例如，监视和路由规则）应用于网格的出站流量。
使用场景
设想一个对安全有严格要求的组织，要求服务网格所有的出站流量必须经过一组专用节点。 专用节点运行在专门的机器上，与集群中运行应用程序的其他节点隔离。 这些专用节点用于实施 Egress 流量的策略，并且受到比其余节点更严密地监控。
另一个使用场景是集群中的应用节点没有公有 IP，所以在该节点上运行的网格 Service 无法访问互联网。通过定义 Egress gateway，将公有 IP 分配给 Egress Gateway 节点，用它引导所有的出站流量，可以使应用节点以受控的方式访问外部服务。
注意事项
注意，Istio 中定义的 egress Gateway 本身并没有为其所在的节点提供任何特殊处理。 集群管理员或云提供商可以在专用节点上部署 Egress Gateway，并引入额外的安全措施， 从而使这些节点比网格中的其他节点更安全。
另外要注意的是，Istio 无法强制让所有出站流量都经过 Egress Gateway， Istio 只是通过 Sidecar 代理实现了这种流向。攻击者只要绕过 Sidecar 代理， 就可以不经 Egress Gateway 直接与网格外的服务进行通信，从而避开了 Istio 的控制和监控。 出于安全考虑，集群管理员和云供应商必须确保网格所有的出站流量都要经过 Egress Gateway。 这需要通过 Istio 之外的机制来满足这一要求。例如，集群管理员可以配置防火墙， 拒绝 Egress Gateway 以外的所有流量。 Kubernetes 网络策略 也能禁止所有不是从 Egress Gateway 发起的出站流量（下一节有一个这样的例子）。 此外，集群管理员和云供应商还可以对网络进行限制，让运行应用的节点只能通过 gateway 来访问外部网络。 要实现这一限制，可以只给 gateway Pod 分配公网 IP，并且可以配置 NAT 设备， 丢弃来自 Egress Gateway Pod 之外的所有流量。
Higress
简介
Higress是基于阿里内部Envoy Getway时间沉淀、以开源istio+Envoy为核心构建的下一个云原生网关，实现了流量网关+微服务网管+安全网管三合一的高集成能力，深度集成Dubbo、Nacos、Sentinel等微服务技术，能帮助用户极大的降低网关的部署及他运维成本且能力不打折；在标准上全面支持Ingress与Geteway API，积极拥抱云原生下的标准API规范；同时Higress Controller也支持Nginx Ingress平滑迁移，帮助用户零成本快速迁移到Higress
传统网关分类
行业中通常把网关分为俩个大类：流量网关与业务网关，流量网关主要提供全局的、与后端业务无关的策略配置，例如阿里内部的统一接入网关Tengine就是典型的流量网关；业务网关顾名思义主要是提供独立业务域级别的、与后端业务紧耦合的策略配置，随着应用架构模式从单体严谨到现在的分布式微服务，业务网关也有了新的叫法-微服务网管（图示说明如下）。在目前容器技术与K8s主导的云原生时代，下一代网关模式依然是这样吗？
Higress定位
在虚拟化时期的微服务架构下，业务通常采用流量网关+微服务网关的俩层架构，流量网关负责南北向流量调度和安全防护，微服务网管负责东西向流量的调度和服务治理，而在K8s主导的云原生时代，Ingress称为K8s生态的网关标准，赋予了网关新的使命，使得流量网关+微服务网关合二为一称为可能。
作为面向南北向的公网网关，使用Waf防护异常流量是很常规的请求，而且随着互联网环境变得越来越复杂，用户对防护的诉求是程序增强的，常规做法是将流量先接入Waf安全网关，过滤后再将流量转发给流量网关，最后到达微服务网关；Higress希望通过内置Waf模块，使得用户的请求链接只经过Higress就可以同时完成Waf防护、流量分发、微服务治理，既可以降低链路RT，也可以降低网关的运维复杂度。因为Higress实现了 流量网关+微服务网关+安全网关三合一的高集成能力。
RT：响应实际，就是从客户端请求发起到服务器响应结果的时间。RT这个参数是系统最重要的指标之一，它的大小直接反应了当前系统的响应状态。基本和咱们用户体验息息相关，现在好一点监控系统一般都有三个RT，即平均、最大、最小。
般系统RT 100ms 以内是比较正常的，300ms 勉强可以接受，1s的话再加上一些其他的外因，给用户的体验就是实实在在的不爽了。
Higresss什么选择以Envoy+Istio为内核构建
在容器化的云原生大背景下，Kubernetes已经成为了基础设施与上层应用的标准接口，Kubernetes集群天然的内外网络隔离环境，使得外部流量进入Kubernetes集群内部需要通过入口网关，因此Kubernetes通过Ingress来规范化入口网关的定义与标准，虽然Ingress标准存在一些如路由表达能力弱等不足之处，社区已经在积极推进Gateway API标准定义来解决，但不可否认的是目前Ingress标准仍然占据主流，CNCF年度报告中也单独统计了Ingress Provider（Ingress标准的实现方统称为Ingress Provider）的使用情况。
从上述统计报告中可以看到虽然目前Nginx Ingress仍然占据K8s Ingress Provider榜首，但Envoy的增长是最快的，已经从2019年的不足20%增长为2020年的37%，且仅在Nginx Ingress之后，增长势头非常迅猛，这说明选择以Envoy为内核是符合云原生发展趋势的；而且随着Service Mesh逐步被大众认可，Istio + Envoy的体系可以同时覆盖Mesh与Ingress领域，实现以一套技术架构调度东西向、南北向全域流量的目标，这对用户来说也是非常有意义的。
Higress在阿里巴巴内部介绍
Higress孵化自阿里巴巴内部2020年5月的"本地生活战役"，最初是为满足阿里巴巴集团与蚂蚁集团直接使用RPC请求互访的诉求而构建，而且借该项目也成功孵化了Dubbo 3.0的Triple协议，因此Higress也是内部第一个支持Triple协议的应用，同年Higress也成功支持了双11、双12等大促活动，后续随着业务范围的扩展，目前Higress在内部已经支持优酷、钉钉、达摩院、蚂蚁等业务，业务场景也扩展到了东西向、南北向的全域流量调度。
WAF
Web应用防火墙WAF简介 - 知乎 (zhihu.com)
Web(Web Application Firewall)应用防火墙可以防止Web应用免受各种常见攻击，比如SQL注入，跨站脚本漏洞（XSS）等。WAF也能够监测并过滤掉某些可能让应用遭受DOS（拒绝服务）攻击的流量。WAF会在HTTP流量抵达应用服务器之前检测可疑访问，同时，它们也能防止从Web应用获取某些未经授权的数据。
近年来，Web应用安全已经变得越来越重要，特别是在Verizon数据泄露调查报告中将Web应用攻击列为最常见的攻击之后，WAF已经变成Web安全最为关键的组件。Waf的某些功能是通过负载均衡来实现的
WAF也属于防火墙的一种，严格意义上来说是一款轻量级Web服务器。WAF就像高铁站的安检，对于进入的HTTP请求进行逐一排查，通过解析HTTP数据，在不同字段分别在规则、特征等方面进行检测，从而决定是否放行。