Ingress:集群进出流量的总管

简介: 【2月更文挑战第14天】

Service 很有用,但也只能说是“基础设施”,它对网络流量的管理方案还是太简单,离复杂的现代应用架构需求还有很大的差距,所以 Kubernetes 就在 Service 之上又提出了一个新的概念:Ingress。


Service 还有一个缺点,它比较适合代理集群内部的服务。如果想要把服务暴露到集群外部,就只能使用 NodePort 或者 LoadBalancer 这两种方式,而它们都缺乏足够的灵活性,难以管控,这就导致了一种很无奈的局面:我们的服务空有一身本领,却没有合适的机会走出去大展拳脚。

这个 API 对象就顺理成章地被命名为 Ingress,意思就是集群内外边界上的入口。


Service 本身是没有服务能力的,它只是一些 iptables 规则,真正配置、应用这些规则的实际上是节点里的 kube-proxy 组件。如果没有 kube-proxy,Service 定义得再完善也没有用。


Ingress 也只是一些 HTTP 路由规则的集合,相当于一份静态的描述文件,真正要把这些规则在集群里实施运行,还需要有另外一个东西,这就是 Ingress Controller,它的作用就相当于 Service 的 kube-proxy,能够读取、应用 Ingress 规则,处理、调度流量。


Kubernetes 应该把 Ingress Controller 内置实现,作为基础设施的一部分,就像 kube-proxy 一样。

随着 Ingress 在实践中的大量应用,很多用户发现这种用法会带来一些问题,比如:

  • 由于某些原因,项目组需要引入不同的 Ingress Controller,但 Kubernetes 不允许这样做;
  • Ingress 规则太多,都交给一个 Ingress Controller 处理会让它不堪重负;
  • 多个 Ingress 对象没有很好的逻辑分组方式,管理和维护成本很高;
  • 集群里有不同的租户,他们对 Ingress 的需求差异很大甚至有冲突,无法部署在同一个 Ingress Controller 上。


Kubernetes 就又提出了一个 Ingress Class 的概念,让它插在 Ingress 和 Ingress Controller 中间,作为流量规则和控制器的协调人,解除了 Ingress 和 Ingress Controller 的强绑定关系。


Kubernetes 用户可以转向管理 Ingress Class,用它来定义不同的业务逻辑分组,简化 Ingress 规则的复杂度。比如说,我们可以用 Class A 处理博客流量、Class B 处理短视频流量、Class C 处理购物流量。


Ingress 也是可以使用 kubectl create 来创建样板文件的,和 Service 类似,它也需要用两个附加参数:

  • --class,指定 Ingress 从属的 Ingress Class 对象。
  • --rule,指定路由规则,基本形式是“URI=Service”,也就是说是访问 HTTP 路径就转发到对应的 Service 对象,再由 Service 对象转发给后端的 Pod。

Ingress 和 Service、Ingress Class 的关系画成了一张图。

image.png image.gif

部署 Ingress Controller 不需要我们自己从头编写 Deployment,Nginx 已经为我们提供了示例 YAML,但创建之前为了适配我们自己的应用还必须要做几处小改动:

  • metadata 里的 name 要改成自己的名字,比如 ngx-kic-dep。
  • spec.selector 和 template.metadata.labels 也要修改成自己的名字,比如还是用 ngx-kic-dep。
  • containers.image 可以改用 apline 版本,加快下载速度,比如 nginx/nginx-ingress:2.2-alpine。
  • 最下面的 args 要加上 -ingress-class=ngx-ink,也就是前面创建的 Ingress Class 的名字,这是让 Ingress Controller 管理 Ingress 的关键。
相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
计算机视觉
Google Earth Engine(GEE)——使用MODIS数据单点测试SG滤波和harmonics method 滤波的差异分析
Google Earth Engine(GEE)——使用MODIS数据单点测试SG滤波和harmonics method 滤波的差异分析
481 0
|
搜索推荐 数据可视化 数据挖掘
构建精准的目标客户群用户画像构建
构建精准的目标客户群用户画像
1181 6
|
机器学习/深度学习 人工智能 监控
人工智能中的图像识别
人工智能中的图像识别
466 1
|
12月前
|
应用服务中间件 Linux nginx
Linux下操作Nginx相关命令
Linux下操作Nginx相关命令
|
人工智能 Java 测试技术
开源上新|FunASR英文离线文件转写软件包发布
开源上新|FunASR英文离线文件转写软件包发布
macbookpro触摸板突然失灵按压无震动反馈和回弹感
macbookpro触摸板突然失灵按压无震动反馈和回弹感
922 0
|
JavaScript 前端开发 API
vue3没有this怎么办?
vue3没有this怎么办?
431 1
|
机器学习/深度学习 人工智能 算法
探索人工智能在图像识别领域的创新应用
【5月更文挑战第30天】 随着深度学习技术的飞速发展,人工智能(AI)在图像识别领域取得了革命性的进展。本文旨在探讨AI技术如何优化图像识别流程,提高识别精度,并分析其在多个行业中的实际应用。通过对比传统方法和最新的研究成果,我们展示了AI驱动的图像识别系统在处理速度、准确率和自动化水平方面的显著提升。此外,文章还将讨论当前面临的挑战和未来的发展趋势,为读者提供一个关于AI在图像识别领域内应用的全面视角。
|
存储 机器学习/深度学习 人工智能
RRAM机制、材料及其在神经形态计算中的应用
RRAM机制、材料及其在神经形态计算中的应用
|
JavaScript
oninput 和 onchange 事件有什么区别
oninput 和 onchange 事件有什么区别