技术、生存、观念、原创。 原创群众号； 关键关注 Go、JVM、并发、散布式、网络等关系技术。
前两章中我们将运行部署到了 k8s 中，同时不同的服务之间也可以经过service启动调用，如今还有一个步骤就是将我们的运行泄露到公网，并提供域名的访问。
这一步相似于我们以前性能 Nginx 和绑定域名，提供这个才干的服务在 k8s 中成为 Ingress。
经过这个形容其实也能看出 Ingress 是偏运维的上班，但也不障碍我们作为研发去了解这局部的内容；了解整个系统是如何运行的也是研发应该把握的技艺。
在正式经常使用 Ingress 之前要求给 k8s 装置一个 Ingress 控制器，我们这里装置官网提供的 Ingress-nginx 控制器。
当然还有社区或许企业提供的各种控制器：
有两种装置模式: helm 或许是间接 apply 一个资源文件。
对于helm我们会在前面的章节独自解说。
这里就间接经常使用资源文件装置即可，我曾经上行到 GitHub 可以在这里访问：
其实这个文件也是间接从官网提供的复制上来的，也可以间接经常使用这个门路启动装置：
kubectl apply -f
不过要留意装置之后或许容器形态不时处于 Pending 形态，检查容器的事情时会发现镜像拉取失败。
k describe pod ingress-nginx-controller-7cdfb9988c-lbcst -n ingress-nginx
在刚才那份 yaml 文件中可以看到有几个镜像要求拉取，我们可以先在本地手动拉取镜像：
docker pull registry.k8s.io/ingress-nginx/controller:v1.8.2
假设依然不可拉取，可以尝试性能几个国际镜像源镜像拉取：
我这里经常使用的 docker-desktop 自带的 k8s，介绍读者好友也经常使用这个工具。
创立 Ingress
经常使用刚才的 yaml 装置成功之后会在ingress-nginx命名空间下创立一个 Pod，经过 get 命令检查形态为 Running 即为装置成功。
$ k get pod -n ingress-nginxNAMEREADYSTATUSRESTARTSAGEingress-nginx-controller-7cdf1/1Running2 (35h ago)3d
之后便可以创立 Ingress 资源了：
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: k8s-combat-ingressspec:ingressClassName: nginxrules:- host: www.service1.iohttp:paths:- backend:service:name: k8s-combat-serviceport:number: 8081path: /pathType: Prefix- host: www.service2.iohttp:paths:- backend:service:name: k8s-combat-service-2port:number: 8081path: /pathType: Prefix
看这个内容也很容易了解，创立了一个Ingress的对象，其中的重点就是这里的规定是如何定义的。
这里的ingressClassName: nginx 也是在刚开局装置的控制器里定义的名字，由这个资源定义。
apiVersion: networking.k8s.io/v1kind: IngressClassmetadata:labels:app.kubernetes.io/component: controllerapp.kubernetes.io/instance: ingress-nginxapp.kubernetes.io/name: ingress-nginxapp.kubernetes.io/part-of: ingress-nginxapp.kubernetes.io/version: 1.8.2name: nginx
我们这个规定很繁难，就是将两个不同的域名路由到两个不同的 service。
测试
也是为了繁难测试，我在运行镜像中新增了一个接口，用于前往 Pod 的 hostname。
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {name, _ := os.Hostname()fmt.Fprint(w, name)})
由于我实践并没有www.service1.io/www.service2.io这两个域名，所以只能在本地性能 host 启动模拟。
10.0.0.37 www.service1.io10.0.0.37 www.service2.io
当我们重复恳求两次这个接口，会拿到两个不同的 hostname，也就是将我们的恳求轮训负载到了这两个 service 所代理的两个 Pod 中。
❯ curl❯ curl❯ curl❯ curl
我们也可以间接经常使用 describe 检查我们的 ingress 定义以及路由规定：
$ k describe ingress k8s-combat-ingressName:k8s-combat-ingressLabels:<none>Namespace:defaultAddress:localhostIngress Class:nginxDefault backend:<default>Rules:HostPathBackends----------------www.service1.io/k8s-combat-service:8081 (10.1.0.65:8081,10.1.0.67:8081)www.service2.io/k8s-combat-service-2:8081 (10.1.0.63:8081,10.1.0.64:8081)Annotations:<none>Events:<none>
假设我们手动新增一个域名解析：
10.0.0.37 www.service3.io❯ curlNot Found</title></head><body><center><h1>404 Not Found</h1></center><hr><center>nginx</center></body></html>
会间接 404，这是由于没有找到这个域名的规定。
访问原理
整个的恳求门路如上图所示，其实我们的 Ingress 实质上也是一个 service（所以它也可以启动多个正原本启动负载），只是他的类型是LoadBalancer，通常这种类型的 service 会由云厂商绑定一个外部 IP，这样就可以经过这个外部 IP 访问 Ingress 了。
而我们运行的 service 是 ClusterIP，只能在运行外部访问。
经过 service 的消息也可以看到，我们 ingress 的 service 绑定的外部 IP 是localhost（本地的要素）。
总结
Ingress 通常是充任网关的作用，后续我们在经常使用 Istio 时，也可以经常使用 Istio 所提供的控制器来交流掉 Ingress-nginx，可以更繁难的治理内外网流量。
本文的一切源码在这里可以访问：
本网站的文章部分内容可能来源于网络和网友发布，仅供大家学习与参考，如有侵权，请联系站长进行删除处理，不代表本网站立场，转载联系作者并注明出处：https://duobeib.com/diannaowangluoweixiu/6468.html
咚波服务与支持