Lisa 大家好，关于ingress域名很多朋友都还不太明白，今天小编就来为大家分享关于ingress 域名的知识，希望对各位有所帮助！
本文目录
Rancher上发布服务-使用Ingressk8s ingress 外部域名(External Domains)ingress 不使用域名K8S Nginx Ingress 介绍Rancher上发布服务-使用Ingress模式2：使用Ingress发布服务
1、选择集群，点击资源-工作负载-负载均衡
2、点击添加规则
3、保存规则，并等待规则生效。
4、刷新规则
5、点击hello.default.192.168.3.95.xip.io，打开应用
疑问：
http://hello.default.192.168.3.95.xip.io/ 这个地址为什么能够访问，域名是不存在的，本机也没有在host中添加该域名与ip的映射。
解答：
xip.io类似代理服务器。
k8s ingress 外部域名(External Domains)这里涉及两个知识点。第一个是ingress，第二个是externaldomains。ingress大家可能比较熟悉，比如下面的配置，访问hello-world.info的域名，请求”/“目录，将会把请求转发到web这个服务。
externaldomains大家可能不经常使用，这个是k8s提供的CNAME能力，比如下面通过外部域名的功能，为my-service的域名增加一个my.database.example.com的CNAME，这样当我们在容器里面访问my-service域名的时候，域名解析到CNAMEmy.database.example.com，从而将请求转发到my.database.example.com。
但外部域名有个小问题，就是它只是重定向域名，并不会修改HTTPheader，这就导致一个问题：请求url里面域名和header中的域名不一致。而ingress大部分都是HTTP请求。比如下面service的定义。
当通过my-sample.com请求ingress的时候，ingress转发请求的时候，HTTPHOSTheader还是my-sample.com，但上面设置的外部域名是example.com，这就导致不一致了，nginx无法转发流量。
但我们还可以通过nginx.ingress.kubernetes.io/upstream-vhost这个annotation修改我们的请求header，如上面例子，我们将请求header的HOST修改成example.com就可以成功请求了。
ingress 不使用域名题主是否想询问“ingress不使用域名吗”？使用。
1、Ingress本身就是用于实现用域名的方式访问k8s集群的内部应用，所以不能不使用域名。
2、而且截止2022年6月8日，在网络上还没有关于Ingress不用域名的相关消息。
K8S Nginx Ingress 介绍一、Ingress介绍
Kubernetes暴露服务的方式目前只有三种：LoadBlancerService、NodePortService、Ingress；前两种估计都应该很熟悉，具体的可以参考下 这篇文章；下面详细的唠一下这个Ingress
1.1、Ingress是个什么玩意
可能从大致印象上Ingress就是能利用Nginx、Haproxy啥的负载均衡器暴露集群内服务的工具；那么问题来了，集群内服务想要暴露出去面临着几个问题：
1.2、Pod漂移问题
众所周知Kubernetes具有强大的副本控制能力，能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的，还可以动态扩容等，总之一句话，这个Pod可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着Pod的创建和销毁，PodIP肯定会动态变化；那么如何把这个动态的PodIP暴露出去？这里借助于Kubernetes的Service机制，Service可以以标签的形式选定一组带有指定标签的Pod，并监控和自动负载他们的PodIP，那么我们向外暴露只暴露ServiceIP就行了；这就是NodePort模式：即在每个节点上开起一个端口，然后转发到内部PodIP上，如下图所示
1.3、端口管理问题
采用NodePort方式暴露服务面临一个坑爹的问题是，服务一旦多起来，NodePort在每个节点上开启的端口会及其庞大，而且难以维护；这时候引出的思考问题是 “能不能使用Nginx啥的只监听一个端口，比如80，然后按照域名向后转发？” 这思路很好，简单的实现就是使用DaemonSet在每个node上监听80，然后写好规则，因为Nginx外面绑定了宿主机80端口(就像NodePort)，本身又在集群内，那么向后直接转发到相应ServiceIP就行了，如下图所示
1.4、域名分配及动态更新问题
从上面的思路，采用Nginx似乎已经解决了问题，但是其实这里面有一个很大缺陷：每次有新服务加入怎么改Nginx配置？总不能手动改或者来个RollingUpdate前端NginxPod吧？这时候“伟大而又正直勇敢的”Ingress登场，如果不算上面的Nginx，Ingress只有两大组件：IngressController和Ingress
Ingress这个玩意，简单的理解就是 你原来要改Nginx配置，然后配置各种域名对应哪个Service，现在把这个动作抽象出来，变成一个Ingress对象，你可以用yml创建，每次不要去改Nginx了，直接改yml然后创建/更新就行了；那么问题来了：”Nginx咋整？”
IngressController这东西就是解决“Nginx咋整”的；IngressControoler通过与KubernetesAPI交互，动态的去感知集群中Ingress规则变化，然后读取他，按照他自己模板生成一段Nginx配置，再写到NginxPod里，最后reload一下，工作流程如下图
当然在实际应用中，最新版本Kubernetes已经将Nginx与IngressController合并为一个组件，所以Nginx无需单独部署，只需要部署IngressController即可
二、怼一个NginxIngress
上面啰嗦了那么多，只是为了讲明白Ingress的各种理论概念，下面实际部署很简单
2.1、部署默认后端
我们知道 前端的Nginx最终要负载到后端service上，那么如果访问不存在的域名咋整？官方给出的建议是部署一个 默认后端，对于未知请求全部负载到这个默认后端上；这个后端啥也不干，就是返回404，部署如下
这个 default-backend.yaml 文件可以在 官方Ingress仓库 找到，由于篇幅限制这里不贴了，仓库位置如下
2.2、部署IngressController
部署完了后端就得把最重要的组件Nginx+IngresController(官方统一称为IngressController)部署上
注意：官方的IngressController有个坑，至少我看了DaemonSet方式部署的有这个问题：没有绑定到宿主机80端口，也就是说前端Nginx没有监听宿主机80端口(这还玩个卵啊)；所以需要把配置搞下来自己加一下 hostNetwork，截图如下
同样配置文件自己找一下，地址 点这里，仓库截图如下
当然它支持以deamonset的方式部署，这里用的就是(个人喜欢而已)，所以你发现我上面截图是deployment，但是链接给的却是daemonset，因为我截图截错了…..
2.3、部署Ingress
关于本次ingress域名和ingress 域名的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。
