ingress.exe怎么卸载

这是一款网络管理软件，一般在公司、单位中使用， 此类软件多数具有进程保护、结束重建等功能，用户虽然不能直接卸载，但是可以参考如下方法以实现”曲线救国“。

应用程序在windows系统上运行，除了运行、等待外，还有两种状态——挂起和释放，一旦将一个应用程序挂起，它将不会发挥任何作用，相当于把一个进程”麻醉“了，从而阻挡恶意老板的”监控“，具体作法：

1、下载sysinternals工具包。

2、解压工具包后，找到procexp.exe的程序，运行它，在ingress.exe上右键，选择”suspend"（挂起）即可。

K8S Ingress通过管理集群中的外部服务用的Service，把流量从Nginx转到对应部署的容器中，提供7层负载均衡能力。

在我们公司存在混合部署的情况，有业务同时在容器和物理机、云主机上部署服务实例，但是也需要通过K8S Ingress把外部流量转入进行，由于Ingress不支持流量转到物理机上的实例，所以我们需要做一些扩展来支持这种场景。

在 Ingress Nginx主流程 一文中，已经介绍了Ingress Nginx的驱动流程，系统的主要驱动逻辑是监控API Server中相关资源的变化，并通过事件回调去驱动系统的运行。

我们可以通过适当改造Ingress Nginx Controller来让他支持物理机实例。

ingress-nginx-controller的实现是通过k8s中的资源发现，把Server或Pod的变化，实时更新配置到Nginx中，基于Nginx的反向代理服务，基于vhost子域名以及URL路由到后端的Pod中。

K8S原生的资源无法发现物理部署的服务，所以我们需要利用K8S的资源扩展机制，给K8S添加一种新的资源：PhysicalDeployment资源，下面是一个对应的物理资源例子：

phyendpoint-example有两个实例，分别是10.0.0.1:10001和10.0.0.2:1001，由于ingress中的nginx使用的lua功能来实现upstream，没有使用nginx原生的upstream，所以它暂时不具备被动探测服务不可用的功能，也就是说，当一个endpoint故障或者不能工作时，ingress无法做到想nginx原生upstream那样，先隔离该实例，10秒后重试这种被动探测能力。

ingress主要依赖于k8s原生的pod的主动探测能力来发现不可用服务，当主动探测一个endpoint不可用时，ingress能够及时（当然也不够实时）发现问题，并隔离该pod。

所以，这里还需要针对PhysicalEndpoint实现自己的控制器，在控制器中定期对PhysicalEndpoint管理的Endpoint进行探测，并及时更新它的状态。

ingress主要基于service来发现Endpoints，这里需要增加对PhysicalEndpoint的事件侦听服务，并与Service服务一起订阅合并Endpoints后，通过nginx的API更新到对应的upstream服务列表中。

为了合并容器与物理部署，需要对Service也做稍许扩展，增加annotation，让我们在服务发现时除了发现该service的容器Endpoint之外，还去发现对应的annotation中的PhysicalEndpoint中的Endpoint。

如下图是一个例子：

通过简单的扩展，就可以让Ingress同时把流量向容器和物理机部署的服务进行转发，不仅能够解决部分业务确实存在物理机部署的需求，同时对于我们公司的现状的容器化推广有很大帮助，排除了不少阻力。

原文地址： https://alphahinex.github.io/2021/07/11/ingress-ingress-controller-ingress-class/

description: "集群内外沟通的桥梁"

date: 2021.07.11 10:26

categories:

- Cloud Native

tags: [K8s]

keywords: K8s, Cloud Native, Ingress, Nginx, Ingress Controller, Ingress Class

将 k8s 集群中服务暴露给集群外访问，最简单的方式莫过于使用 NodePort，好比在 docker 环境下为容器的服务端口绑定宿主机的端口，定义 NodePort 类型的 Service 后，即可通过集群中任意节点的 IP 加 nodePort 指定的端口访问到 k8s 集群中的服务。

但随着服务的增多，使用 NodePort 访问的问题也会逐渐显现出来：可用作 NodePort 的端口是一个有限的范围、不容易记忆、不好管理……

有没有更优雅的方式访问集群内的服务呢？

可以在集群内部署一个 Nginx 服务，NodePort 暴露 Nginx 的端口，再由 Nginx 代理访问集群内的服务。emm，没错，这种方式的确更好。在 k8s 中也有这样的一个资源，能够起到与这个 Nginx 类似的作用，即 Ingress 。

Ingress 在 k8s 集群中的作用，是定义外部对集群内服务的访问路由，例如：

上面这个 Ingress 资源的定义，配置了一个路径为 /testpath 的路由，所有 /testpath/** 的入站请求，会被 Ingress 转发至名为 test 的服务的 80 端口的 / 路径下。

可以将 Ingress 狭义的理解为，Nginx 中的配置文件，如： nginx.conf 。

很显然，只有 Nginx 的配置文件，是起不到转发请求的作用的，必须还要有 Nginx 程序。

同样，仅创建 Ingress 资源本身是没有任何作用的，还需要部署 Ingress Controller 。Ingress Controller 的作用就相当于是 Nginx 服务，实际上，k8s 官方支持和维护的三个 Ingress Controller 里，就有基于 nginx 实现的 ingress-nginx ，另外两个是 AWS 和 GCE 。

除此之外，还有很多 三方实现 ，例如：

既然有这么多类型的实现，我们就有可能会有需要部署多个 Ingress Controller 的场景。当集群中部署了多个 Ingress Controller 的时候，如何知道 Ingress 中的规则应该使用哪个 Controller 呢？这时就需要用到 Ingress Class 了。

不同类型的 Ingress Controller 对应的 Ingress 配置通常也是不同的，当集群中存在多于一个的 Ingress Controller 时，就需要为 Ingress 指定对应的 Controller 是哪个。

在 Kubernetes 1.18 之前，通常是在 Ingress 资源上通过 kubernetes.io/ingress.class 注解来指定使用的 Ingress Controller。虽然这个注解从未被正式定义过，但确是被各个 Ingress Controller 所广泛支持的。

这个注解的值，一般是具体 Ingress Controller 所提供的默认值，如 nginx 、 gce 、 traefik 、 kong 等，可使用约定关键字，或查阅对应文档获得此默认值，如 Kong 的 Kubernetes Ingress Controller 文档中 Configuring the controller ingress class 部分。

在创建 Ingress Controller 部署对象时，我们也可以通过 --ingress-class 来指定此 Ingress Controller 具体 Deployment 的对应 class，如：

Ingress 中指定使用的 Ingress Controller 时，可参考如下方式：

Kubernetes 1.18 起，正式提供了一个 IngressClass 资源，作用与 kubernetes.io/ingress.class 注解类似，例如：

其中重要的属性是 metadata.name 和 spec.controller ，前者是这个 IngressClass 的名称，需要设定在 Ingress 中，后者是 Ingress Controller 的名称。

Ingress 中的 spec.ingressClassName 属性，可以用来指定对应的 IngressClass，并进而由 IngressClass 关联到对应的 Ingress Controller，如：

注意， spec.ingressClassName 与 metadata.annotations.kubernetes.io/ingress.class 的作用并不完全相同，因为 ingressClassName 字段引用的是 IngressClass 资源的名称，IngressClass 资源中，除了指定了 Ingress Controller 的名称之外，还可能会通过 spec.parameters 属性定义一些额外的配置。

在集群中，我们可以设定一个默认的 Ingress Class，以便处理所有没有指定 Ingress Class 的 Ingress 资源。

在 IngressClass 资源上，我们可以通过将 ingressclass.kubernetes.io/is-default-class 注解的值设定为 true ，来使没有设置 ingressClassName 的 Ingress 使用此默认的 IngressClass 。

除了可能会有多个不同类型的 Ingress Controller 之外，还可能存在多个相同类型的 Ingress Controller，比如部署了两个 NGINX Ingress Controller，一个负责处理外网访问，一个负责处理内网访问。

此时也可以通过上面的方式，为每个 Controller 设定唯一的一个 class。

当多个 controller 的 class 不唯一，或者 controller 和 Ingress 都没有指定 class 又没有默认的 class 时，会导致所有符合条件的 Ingress Controller 竞争满足 Ingress 配置，可能会导致不可预测的结果。

---