21｜Ingress：集群进出流量的总管

四层架构简单，无需解析消息内容，在网络吞吐量及处理性能上高于七层。 而七层负载优势在于功能多，控制灵活强大。

老师，我在安装文档里找到了大多数同学遇到的问题的解决方法： https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-manifests/ Create Custom Resources 这一节 注意：默认情况下，需要为 VirtualServer, VirtualServerRoute, TransportServer and Policy 创建自定义资源的定义。否则，Ingress Controller Pod 将不会变为 Ready 状态。如果要禁用该要求，请将 -enable-custom-resources 命令行参数配置为 Readyfalse 并跳过此部分。 也就是说可以 kubectl apply -f 下面几个文件： $ kubectl apply -f common/crds/k8s.nginx.org_virtualservers.yaml $ kubectl apply -f common/crds/k8s.nginx.org_virtualserverroutes.yaml $ kubectl apply -f common/crds/k8s.nginx.org_transportservers.yaml $ kubectl apply -f common/crds/k8s.nginx.org_policies.yaml 然后就启动成功了。 也可以将 -enable-custom-resources 命令行参数配置为 Readyfalse

文末的kic.yml是来自 https://github.com/nginxinc/kubernetes-ingress/blob/main/deployments/deployment/nginx-ingress.yaml

一个小问题老师，service基于四层转发，会暴露ip。基于这些缺点我们引入了ingress，基于七层网络协议转发，但是为了外部服务访问，需要在ingress前再暴露一个nodeport类型的service，那我们这么做的意义在哪里捏，最外层的入口处不还是service吗。

最后ingress-controller运行起来的pod 可以看作是一个pod的nginx反向代理的VIP， 由于pod网络隔离的原因，需要还套娃一个service, 对外提供统一的管理入口，是否可以换种思路， 在启动这种ingress-controller运行起来的pod的，设置pod的网络为host，就是公用宿主机网卡，这样就不用套娃service了.

Nginx Ingress Controller 只用那4个不行，看了23节，跟着老师用bash脚本全部弄进去了才把kic起了起来

老师，请问 Ingress 工作在7层协议中，指针对http(s)应用层协议进行控制，那如果 我的应用是需要长链接的 不如IM通讯相关，那是不是Ingress就无法满足了，只能通过service 定义吗？

为ingres-controller设置Service: ➜ ingress kubectl expose deploy nginx-kic-dep -n nginx-ingress --port=80 --target-port=80 $=out>ingress-svc.yml ➜ ingress cat ingress-svc.yml apiVersion: v1 kind: Service metadata: name: nginx-kic-svc namespace: nginx-ingress spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx-kic-dep type: NodePort ➜ ingress kubectl get svc -n nginx-ingress NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-kic-svc NodePort 10.105.174.176 <none> 80:32519/TCP 3m41s ➜ ingress kubectl get node -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME ubuntu Ready control-plane,master 4d v1.23.3 10.211.55.5 <none> Ubuntu 22.04 LTS 5.15.0-58-generic docker://20.10.12 worker Ready <none> 4d v1.23.3 10.211.55.6 <none> Ubuntu 22.04 LTS 5.15.0-58-generic docker://20.10.12 ➜ ingress curl --resolve ngx.test:32519:10.211.55.5 http://ngx.test:32519 srv : 10.10.1.10:80 host: ngx-dep-6796688696-867dm uri : GET ngx.test / date: 2023-02-09T15:10:48+00:00 ➜ ingress curl --resolve ngx.test:32519:10.211.55.5 http://ngx.test:32519 srv : 10.10.1.11:80 host: ngx-dep-6796688696-psp5v uri : GET ngx.test / date: 2023-02-09T15:10:50+00:00

service方式如下： apiVersion: v1 kind: Service metadata: name: ingress-svc namespace: nginx-ingress spec: selector: app: ngx-kic-dep ports: - port: 80 targetPort: 80 type: NodePort 请求 后面的端口要根据kubectl get svc -n nginx-ingress 查看 curl --resolve ngx.test:31967:127.0.0.1 http://ngx.test:31967

我发现了一个问题，我是用了最新版的yml，从github拉的，没有直接用老师的，但是kic.yml文件就是使用老师贴出来的，然后运行起来，pod一直都是未READY和AVAILABLE，查看日志logs，报错： Failed to watch *v1.Endpoints: failed to list *v1.Endpoints: endpoints is forbidden: User "system:serviceaccount:nginx-ingress:nginx-ingress" cannot list resource "endpoints" in API group "" at the cluster scope 我排查了很久，最后发现rabc文件规则异同，导致版本不兼容，不知道我猜测的对不对？ 把老师的镜像文件 nginx/nginx-ingress:2.2-alpine更换为nginx/nginx-ingress:3.0.2 再次apply后，就一切正常OK了，没问题了。 总结：因没有拉老师提供的yml清单生成对应的对象，而是自己去github拉最新版本的yml生成对象，而镜像文件使用了老师提供，导致pod起不来。目测是版本对rabc规则的不兼容导致，不知道老师可以解答下吗？