安装

https://kubernetes.github.io/ingress-nginx/deploy/

  1. kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/cloud/deploy.yaml

上面命令中的 YAML 清单是使用 生成的helm template，因此您最终将获得几乎与使用 Helm 安装控制器相同的资源。

我这边在部署过程中镜像一直拉不下来，更换一下镜像地址。修改deploy.yaml文件。

 image: k8s.gcr.io/ingress-nginx/controller:v1.1.0@sha256:f766669fdcf3dc26347ed273a55e754b427eb4411ee075a53f30718b4499076a

   image: k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660

    image: k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1@sha256:64d8c73dca984af206adf9d6d7e46aa550362b1d7a01f3a0a91b20cc67868660

这三个镜像地址改为：

  image: willdockerhub/ingress-nginx-controller:v1.0.0  
  image: liangjw/kube-webhook-certgen:v1.1.1
  image: liangjw/kube-webhook-certgen:v1.1.1

镜像是我在docker.com中找的

https://hub.docker.com/r/willdockerhub/ingress-nginx-controller/tags

https://hub.docker.com/r/liangjw/kube-webhook-certgen/tags

他们同步至 k8s.gcr.io

修改文件中的 kind: Deployment 部分

      nodeSelector:
        kubernetes.io/os: linux

      tolerations:
        - operator: "Exists"
      nodeSelector:
        kubernetes.io/hostname: master
      hostNetwork: true

tolerations 因为master节点设置了污点，所以需要该配置 使pod容忍该节点的污点

nodeSelector 节点选择器，设置了master节点的标签。

可以通过kubectl label node node-1 isIngress="true" 给节点设置标签，通过 kubectl get nodes --show-labels查看节点所拥有的标签

hostNetwork: true 开启 hostnetwork

这里涉及到了几个修改，都不是必要的。tolerations 和 nodeSelector 完全不用配置也可以，hostNetwork 完全可以使用 nodeport 的方式。

这里涉及到了nginx-ingress的部署方式：

ingress的部署

ingress的部署，需要考虑两个方面：
    1、ingress-controller是作为pod来运行的，以什么方式部署比较好
    2、ingress解决了把如何请求路由到集群内部，那它自己怎么暴露给外部比较好

下面列举一些目前常见的部署和暴露方式，具体使用哪种方式还是得根据实际需求来考虑决定。

Deployment+LoadBalancer模式的Service
如果要把ingress部署在公有云，那用这种方式比较合适。用Deployment部署ingress-controller，创建一个type为LoadBalancer的service关联这组pod。大部分公有云，都会为LoadBalancer的service自动创建一个负载均衡器，通常还绑定了公网地址。只要把域名解析指向该地址，就实现了集群服务的对外暴露。

Deployment+NodePort模式的Service
同样用deployment模式部署ingress-controller，并创建对应的服务，但是type为NodePort。这样，ingress就会暴露在集群节点ip的特定端口上。由于nodeport暴露的端口是随机端口，一般会在前面再搭建一套负载均衡器来转发请求。该方式一般用于宿主机是相对固定的环境ip地址不变的场景。
NodePort方式暴露ingress虽然简单方便，但是NodePort多了一层NAT，在请求量级很大时可能对性能会有一定影响。

DaemonSet+HostNetwork+nodeSelector
用DaemonSet结合nodeselector来部署ingress-controller到特定的node上，然后使用HostNetwork直接把该pod与宿主机node的网络打通，直接使用宿主机的80/433端口就能访问服务。这时，ingress-controller所在的node机器就很类似传统架构的边缘节点，比如机房入口的nginx服务器。该方式整个请求链路最简单，性能相对NodePort模式更好。缺点是由于直接利用宿主机节点的网络和端口，一个node只能部署一个ingress-controller pod。比较适合大并发的生产环境使用。
————————————————
版权声明：本文为CSDN博主「GavinYCF」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/yucaifu1989/article/details/106898901

修改完后执行apply,并检查服务
1640244838759.png

看下本地端口
1640244383943.png
由于配置了hostnetwork，nginx已经在node主机本地监听80/443/8181端口。其中8181是nginx-controller默认配置的一个default backend。这样，只要访问node主机有公网IP，就可以直接映射域名来对外网暴露服务了。如果要nginx高可用的话，可以在多个node上部署，并在前面再搭建一套LVS+keepalive做负载均衡。用hostnetwork的另一个好处是，如果lvs用DR模式的话，是不支持端口映射的，这时候如果用nodeport，暴露非标准的端口，管理起来会很麻烦。

配置ingress资源

我的k8s集群是 v1.21.5 yaml 文件的编写有一些改变，参考 Kubernetes 升级后 ingress api 变化带来的问题

kind: Ingress
metadata:
  name: argo-server
  namespace: argo
spec:
  ingressClassName: nginx 
  rules:
    - host: argo.xiamu.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argo-server
                port: 
                  number: 2746

参考文档

k8s ingress原理及ingress-nginx部署测试

图解 Kubernetes Ingress

nginx-ingress 的安装使用

https://kubernetes.github.io/ingress-nginx/deploy/

https://kubernetes.io/docs/concepts/services-networking/ingress/

https://github.com/nginxinc/kubernetes-ingress

https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-manifests/