k8s 对外服务之 Ingress

将service暴露在节点网络上，NodePort背后就是Kube-Proxy，Kube-Proxy是沟通service网络、Pod网络和节点网络的桥梁。
测试环境使用还行，当有几十上百的服务在集群中运行时，NodePort的端口管理就是个灾难。因为每个端口只能是一种服务，端口范围只能是 30000-32767。

1.2.2 LoadBalancer

通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置 Service 的场景。受限于云平台，且通常在云平台部署LoadBalancer还需要额外的费用。
在service提交后，Kubernetes就会调用CloudProvider在公有云上为你创建一个负载均衡服务，并且把被代理的Pod的IP地址配置给负载均衡服务做后端。

1.2.3 externalIPs

service允许为其分配外部IP，如果外部IP路由到集群中一个或多个Node上，Service会被暴露给这些externalIPs。通过外部IP进入到集群的流量，将会被路由到Service的Endpoint上。

示例：

① 创建控制器定义容器，并对外暴露端口

[root@master01 ingress]# kubectl create deployment app01 --image=nginx:1.14 --replicas=1 --port=80
deployment.apps/app01 created
[root@master01 ingress]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
app01-68d9b5486f-d6s4x   1/1     Running   0          3s
[root@master01 ingress]# kubectl expose deployment app01 --port=80 --target-port=80
service/app01 exposed

② 编辑 "app01" 的 Service 的配置文件

[root@master01 ingress]# kubectl edit svc app01 
  externalIPs:
  - 192.168.190.88

③ 查看 Service 列表

[root@master01 ingress]# kubectl get svc
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP      PORT(S)           AGE
app01              ClusterIP   10.96.82.195    192.168.190.88   80/TCP            8m43s

④ 访问页面

1.2.4 Ingress

只需一个或者少量的公网IP和LB，即可同时将多个HTTP服务暴露到外网，七层反向代理。
可以简单理解为service的service，它其实就是一组基于域名和URL路径，把用户的请求转发到一个或多个service的规则。

原始架构与 Ingress 对比：

原来ens33是service端去暴露端口的，安全性低、不易管理，会面临k8s端口不够用的问题。

NodePort 和 Ingress 是 Kubernetes 中用于公开服务的两种不同方式：

NodePort:

NodePort 允许从集群外部访问您的服务。它会在每个节点上打开一个端口，并将该端口映射到 Service 的端口上。这意味着可以通过节点的 IP 地址和 NodePort 来访问 Service。
通常用于需要直接暴露到外部的服务，但不适合大规模使用，因为需要管理大量的端口映射。

Ingress:

Ingress 是一种对外暴露服务的高级方式，它允许您将 HTTP 和 HTTPS 路由流量到集群中的服务。通过定义规则，Ingress 可以将传入的请求路由到适当的服务，实现灵活的流量控制。
Ingress 需要配合 Ingress Controller 使用，通常基于反向代理实现。它提供了更复杂的路由、负载均衡和 SSL 终止等功能。

1.3.Ingress 组成

1.3.1 Ingress-nginx 资源规则

可以理解为 nginx 的配置文件。ingress是一个API对象，通过yaml文件来配置，ingress对象的作用是定义请求如何转发到service的规则，可以理解为配置模板。

ingress通过http或https暴露集群内部service，给service提供外部URL、负载均衡、SSL/TLS以及基于域名的反向代理。ingress要依靠 ingress-controller 来具体实现以上功能。

1.3.2 ingress-controller

可以当做反向代理或者说是转发器。ingress-controller是具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发。

实际上负责实现 Ingress 规则并处理外部流量的组件。Ingress Controller 监视 Kubernetes API 中的 Ingress 资源变化，并根据这些资源的配置来配置后端负载均衡器、反向代理或其它网络设备，以实现外部访问服务的目的。

Ingress-Nginx github 地址：https://github.com/kubernetes/ingress-nginx
Ingress-Nginx 官方网站：https://kubernetes.github.io/ingress-nginx/

总结：

ingress-controller才是负责具体转发的组件，通过各种方式将它暴露在集群入口，外部对集群的请求流量会先到 ingress-controller；
而ingress对象是用来告诉ingress-controller该如何转发请求，比如哪些域名、哪些URL要转发到哪些service等等。

1.4. Ingress 工作原理

（1）ingress-controller通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化；
（2）然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置；
（3）再写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中；
（4）然后reload一下使配置生效。以此达到域名区分配置和动态更新的作用。

1.5. ingress 暴露服务的方式

1.5.1 方式一：Deployment+LoadBalancer 模式的 Service

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

1.5.2 方式二：DaemonSet+HostNetwork+nodeSelector

用DaemonSet结合nodeselector来部署ingress-controller到特定的node上，然后使用HostNetwork直接把该pod与宿主机node的网络打通，直接使用宿主机的80/433端口就能访问服务。这时，ingress-controller所在的node机器就很类似传统架构的边缘节点，比如机房入口的nginx服务器。该方式整个请求链路最简单，性能相对NodePort模式更好。缺点是由于直接利用宿主机节点的网络和端口，一个node只能部署一个ingress-controller pod。比较适合大并发的生产环境使用。

1.5.3 方式三：Deployment+NodePort模式的Service

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

二、部署 nginx-ingress-controller

2.1. 方式二：DaemonSet+HostNetwork+nodeSelector

2.1.1 部署 ingress-controller pod 及相关资源

[root@master01 ~]# mkdir /opt/ingress;cd /opt/ingress
[root@master01 ingress]# ls
mandatory.yaml

官方下载地址：
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.25.0/deploy/static/mandatory.yaml

上面可能无法下载，可用国内的 gitee
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.25.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml

mandatory.yaml文件中包含了很多资源的创建，包括namespace、ConfigMap、role，ServiceAccount等等所有部署ingress-controller需要的资源。

2.1.2 修改 ClusterRole 资源配置

[root@master01 ingress]# vim mandatory.yaml
 84   - apiGroups:
 85       - "extensions"
 86       - "networking.k8s.io"  #（0.25版本）增加networking.k8s.io Ingress资源的api 
 
100   - apiGroups:
101       - "extensions"
102       - "networking.k8s.io"  #（0.25版本）增加networking.k8s.io/v1 Ingress资源的api

2.1.3 指定 nginx-ingress-controller 运行在 node02 节点

采用方式二：DaemonSet+HostNetwork+nodeSelector

[root@master01 ingress]# kubectl label node node02 nj=zs
 
[root@master01 ingress]# kubectl get nodes --show-labels
NAME       STATUS     ROLES                  AGE   VERSION    LABELS
master01   Ready      control-plane,master   18d   v1.20.11   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master01,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=
node01     NotReady   <none>                 18d   v1.20.11   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,fql=a,kubernetes.io/arch=amd64,kubernetes.io/hostname=node01,kubernetes.io/os=linux
node02     NotReady   <none>                 18d   v1.20.11   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,fql=b,kubernetes.io/arch=amd64,kubernetes.io/hostname=node02,kubernetes.io/os=linux,nj=zs

最低0.47元/天解锁文章