Ingress是Kubernetes集群中的一个对象，用于将外部流量路由到集群内部的服务。它充当了进入Kubernetes集群的API网关，负责接收外部请求，并将其转发到正确的目标服务上。
在Kubernetes中，Pod的IP地址和service的ClusterIP仅可以在集群网络内部做用，对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务，Kubernetes目前提供了以下几种方案：
对于基于HTTP的服务来说，不同的URL地址经常对应不同的后端服务或者虚拟服务器，通常的做法是在应用前添加一个反向代理服务器Nginx，进行请求的负载转发，在Spring Cloud这个微服务框架中，使用zuul网关实现此功能。
对于基于HTTP的服务来说，不同的URL地址经常对应到不同的后端服务（RS）或者虚拟服务器（ Virtual Host），这些应用层的转发机制仅通过Kubernetes的Service机制是无法实现的。
Hello folks，我是 Luga，今天我们来聊一下云原生生态核心技术之流量管理—— Kubernetes Ingress Controller。
通常情况下，集群中的service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。
使用 TKE 的内部和外部客户，经常会遇到因 CLB 回环问题导致服务访问不通或访问 Ingress 几秒延时的现象，本文就此问题介绍下相关背景、原因以及一些思考与建议。
有这样一种场景，当我们有一个使用java写的项目，比如这个时候做了前后端分离，由一个服务变成了俩服务，这个时候前端访问地址比如说是：www.a.com，这个服务需要掉后端接口，比如www.b.com，这个时候倒是可以，但是使用了两个不同的域名，并且这本来就是一个项目，所以正常来说应该使用一个域名，即www.a.com/api，类似这种。 但是这样会有一个问题，在进行请求时，由于使用了一个域名，而后面的URI是不一样的，所以要么修改代码，加上这么一层路径，要么修改nginx的location，在转发时把携带的路径给去掉。 第一种方式可行，但是如果项目非常多，几十个项目，这种情况协调起来都费劲，所以通过nginx，把路径去掉，这种方式不需要研发做任务调整，还是非常灵活的。
Ingress 是 Kubernetes 的一种 API 对象，将集群内部的 Service 通过 HTTP/HTTPS 方式暴露到集群外部，并通过规则定义 HTTP/HTTPS 的路由。Ingress 具备如下特性：集群外部可访问的 URL、负载均衡、SSL Termination、按域名路由（name-based virtual hosting）。
简单的说，ingress就是从kubernetes集群外访问集群的入口，将用户的URL请求转发到不同的service上。Ingress相当于nginx、apache等负载均衡反向代理服务器，其中还包括规则定义，即URL的路由信息。
NodePort Service存在太多缺陷，不适合生产环境。LoadBlancer Service则不太灵活，比如针对微服务架构，那么不同服务是否需要多个负载均衡服务呢？那么，我们还有其他选择么？那就是Ingress。
简单的说，Ingress 就是从 Kubernetes 集群外访问集群的入口，将用户的 URL 请求转发到不同的 Service上。Ingress 相当于 Nginx、Apache 等负载均衡反向代理服务器，其中还包括规则定义，即 URL 的路由信息。
由于最近服务迁移，进行了各种调整，调整的过程中也顺便修改了 ingress 的相关配置，发现这块之前没有写过，于是今天就来看看 ingress 的基本使用。
在业务使用Kubernetes进行编排管理时，针对业务的南北流量的接入，在Kuberentes中通常有几种方案，本文就接入的方案进行简单介绍。
kubernetes Ingess 是有2部分组成，Ingress Controller 和Ingress服务组成，常用的Ingress Controller 是ingress-nginx，工作的原理是：
k8s 我们已经从 NameSpace、Pod、PodController到Volumn都介绍过了，相信看完的小伙伴们也会很有收获的~那么今天我们继续来到k8s的课堂，这节我们将要来说下 k8S 搭建完服务后如何访问！
我们这个系列的文章一直都在学习和掌握K8S各种组成部分在集群里的角色、作用和使用场景，那么针对今天这个主题任务「给K8S上的Web服务做域名解析」你觉得应该使用什么组件来完成呢？
3、在config/index.js文件修改build属性下面的assetsPublicPath: '/xxx/'（用Cli3搭建的项目，应该是在vue.config.js文件修改publicPath: '/xxx/'）;
可以简单的认为 Ingress 是 k8s 中提出的流量入口转发的一个 标准定义规范（只是认为）。怎么实现， 需要根据不同的 IngressController 的逻辑。
集群对外暴露了一个公网IP作为流量入口(可以是 Ingress 或 Service)，DNS 解析配置了一个泛域名指向该IP（比如 *.test.imroc.io），现希望根据请求中不同 Host 转发到不同的后端 Service。比如 a.test.imroc.io 的请求被转发到 my-svc-a，b.test.imroc.io 的请求转发到 my-svc-b
我们要将kubernetes集群内的服务发布到集群外使用，之前使用的方法都是 NodePort、LoadBalancer的 Service，或者是给 Service 配置 ExternalIP，也可以通过 Pod 的 HostPort 进行配置。但是这些方式都存在一些问题，几乎都是通过节点端口的形式向外暴露服务的，了解 Service 的人应该知道，通过 Service 向外暴露端口，实际是在集群中的所有节点上监听同一个端口，如果 Service 非常多，那每个节点上开启的端口就会变得很多，这样维护起来很复杂，而且也非常不安全。
有时候需要多域名指向同一个 ingress 路由规则，比如 a.com a.cn 指向同一个 server
预备知识 1. K8S 上 Service 类型 平台相关基础知识 2. TKE 上四层网络流量暴露方式 3. TKE 上七层网络流量暴露方式 4. TKE 上的 VPC-CNI 5. TKE 上 CLB 直通 Pod 6. TKE 使用已有负载均衡器 7. TKE 使用内网负载均衡器 8. TKE 部署 Nginx Ingress 实际业务场景中最佳实践 1. 对集群内暴露流量 1.1 四层协议 1.2 七层协议 2. 对集群外暴露流量 2.1 七层协议 2.2 四层协议 2.3 端口段规则 2.4 使用Istio
作者刘飞鸿，腾讯游戏高级工程师，热衷于开源、云计算相关技术。目前主要负责腾讯游戏后台架构设计和运维工作。 预备知识 1. K8S 上 Service 类型 ClusterIP 通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 ServiceType。 NodePort 通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求:，可以从集群的外部访问
service是k8s中的一个重要概念，主要是提供负载均衡和服务自动发现。 Service 是由 kube-proxy 组件，加上 iptables 来共同实现的。
Service 是 k8s 网络部分的核心概念，在 k8s 中，Service 主要担任了四层负载均衡的职责。本文从负载均衡、外网访问、DNS 服务的搭建及 Ingress 七层路由机制等方面，讲解 k8s 的网络相关原理。
Kubernetes Dashboard 是一个可以可视化查看和操作 Kubernetes 集群的一个插件
简单服务路由，将 Node 的入站流量从 80 端口转发到服务 blog-anoyi， 查看 ingress 规则：
Kubernetes Ingress是Kubernetes中的一种资源类型，用于管理对Kubernetes集群中服务的访问。在Kubernetes中，可以使用Ingress资源对象实现HTTP和HTTPS流量的路由、负载均衡、TLS终止等功能。
服务接收到流量请求后，从0自动扩容为N，以及没有流量时自动缩容为0，是一个Serverless平台最本的特征。 可以说，自动扩缩容机制是那颗皇冠，戴上之后你才能被称之为Serverless。 当然了解Kubernetes的人会有疑问，HPA不就是用来干自动扩缩容的事儿的吗？难道我用了HPA就可以摇身一变成为Serverless了。 这里最关键的区别在于，Serverless语义下的自动扩缩容是可以让服务从0到N的，但是HPA不能。HPA的机制是检测服务Pod的metrics数据（例如CPU等）然后把Deployment扩容，但当你把Deployment副本数置为0时，流量进不来，metrics数据永远为0，此时HPA也无能为力。 所以HPA只能让服务从1到N，而从0到1的这个过程，需要额外的机制帮助hold住请求流量，扩容服务，再转发流量到服务，这就是我们常说的冷启动。 可以说，冷启动是Serverless皇冠中的那颗明珠，如何实现更好、更快的冷启动，是所有Serverless平台极致追求的目标。 Knative作为目前被社区和各大厂商如此重视和受关注的Serverless平台，当然也在不遗余力的优化自动扩缩容和冷启动功能。 不过，本文并不打算直接介绍Knative自动扩缩容机制，而是先探究一下Knative中的流量实现机制，流量机制和自动扩容密切相关，只有了解其中的奥秘，才能更好的理解Knative autoscale功能。 由于Knative其实包括Building(Tekton)、Serving和Eventing，这里只专注于Serving部分。另外需要提前说明的是，Knative并不强依赖Istio，Serverless网关的实际选择除了集成Istio，还支持Gloo、Ambassador。同时，即使使用了Istio，也可以选择是否使用envoy sidecar注入。本文介绍的时候，我们默认使用的是Istio和注入sidecar的部署方式。
● 在kubernetes中，Pod是应用程序的载体，我们可以通过Pod的IP来访问应用程序，但是Pod的IP地址不是固定的，这就意味着不方便直接采用Pod的IP对服务进行访问。
服务接收到流量请求后，从0自动扩容为N，以及没有流量时自动缩容为0，是一个Serverless平台最本质的特征。
Service 是由 kube-proxy 组件，加上 iptables 来共同实现的。
项目经常会出现多个迭代并行开发测试的场景，因此需要后台的存储资源共享但后台服务并存多个版本多个测试环境，以方便进行多迭代版本的并行开发测试。
但 Ingerss 实际上是由 Ingress Rules 和 Ingress Controller 的组合而成的。在使用上， K8S 通过 Rules 的管理， 隐藏 Controller。
An API object that manages external access to the services in a cluster, typically HTTP.
使用tke的接入层组件时候，很多时候会用到nginx-ingress，并且为了网站安全，很多时候会需要将域名接入到waf，但是waf只支持clb的7层监听接入https://cloud.tencent.com/document/product/627/40765
从前面的学习，我们可以了解到Kubernetes暴露服务的方式目前只有三种：LoadBlancer Service、ExternalName、NodePort Service、Ingress；而我们需要将集群内服务提供外界访问就会产生以下几个问题：
上一节，我们分享了如何对外暴露服务，今天我们再来看另外一种对外暴露服务的方式：ingress。那什么是ingress呢？它跟我们之前接触的暴露服务又有什么不同？
在 Kubernetes 集群中，Ingress 是一种资源对象，可以将外部请求路由到 Kubernetes 集群内部的 Service 中。Ingress 允许您在不更改服务代码的情况下，动态地管理路由规则，从而实现更加灵活的服务部署和管理。
不多BB,直接上yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-dm spec: selector: matchLabels: name: nginx replicas: 2 template: metadata: labels: name: nginx spec: containers: - name: nginx
Ingress规则是很灵活的，可以根据不同域名，不同path转发请求到不同的service，并且支持https/http.
在当前的汽车行业，大多数公司都在向自动驾驶和新能源方向转型，而对于自动驾驶方面，每家企业都投入了大量的资源来完成自动驾驶模型的开发与训练，其中出现了很多明星企业，比如汽车智能计算平台引领者地平线。地平线主要从事汽车智能计算平台的研发，具有领先的深度学习算法和芯片设计能力，致力于通过底层技术赋能，推动汽车产业的创新发展。
由于网站并行加载的资源比较多，HTTP 2 相比 HTTP 1.1 来说，所有的连接共享一个 TCP 连接，同时一个域名下还没有最多同时连接数的限制，加载速度会比 1.1 好一些。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
