nginx ingress的具体使用
一、ingress概述
1、概述
Kubernetes是一个拥有强大故障恢复功能的集群,当pod挂掉时,集群会重新创建一个pod出来,但是pod的IP也会随之发生变化,为了应对这种情况,引入了service,通过service的标签匹配,来进行后端的pod服务发现,并提供传输层的负载均衡。然后我们再通过service的nodeport模式将端口映射到宿主机,这样我们就完成了集群内的服务对外暴漏。
但是如果我们想配置基于http的负载均衡,怎么办呢?可能会想到,再部署一个nginx的pod,以daemonset的形式运行在集群内,绑定宿主机的80端口,后端直接配置对应的serivce就可以了,
但是当后端有新的服务的时候,就需要更新nginx pod的配置文件,会比较麻烦。这个时候,ingress就出现了。ingress就是原来你需要修改nginx配置文件,现在把它做成了一个ingress对象,可以通过yaml的形式进行创建,ingress controller的功能就是与apiesrver交互,发现ingress配置文件的变化,生成nginx可以理解的配置,在写到nginx 的配置文件中
2、功能
- 将Kubernetes内部的服务暴漏出去
- 提供基于http层的流量负载均衡(基于主机头或者URL)
- 提供TLS/SSL加密
ingress是通过service的服务发现功能来发现后端的pod,然后流量直接发给pod,而不经由service,所以要比nodeport的方式网络损耗更小。
3、核心概念
- host:未指定
host
,因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。 如果提供了host
(例如 foo.bar.com),则rules
适用于该host
- rules:用于定义当前Ingress资源的转发规则列表;由rules定义规则,或没有匹配到规则时,所有的流量会转发到由backend定义的默认后端。
- backend:默认的后端用于服务那些没有匹配到任何规则的请求;定义Ingress资源时,必须要定义backend或rules两者之一,该字段用于让负载均衡器指定一个全局默认的后端。
- tls:TLS配置,目前仅支持通过默认端口443提供服务,如果要配置指定的列表成员指向不同的主机,则需要通过SNI TLS扩展机制来支持该功能。
4、nginx-ingress工作原理
- ingress-controller通过和API server交互,动态的获取ingress的规则变化
- 当ingress发生变化时,按照固定格式生成nginxi可以识别的前后端配置文件
- 再将这段配置文件,写入到 ingress-controller中的nginx服务中,在reload一下,使配置文件生效
二、nginx-ingress使用
1、安装
官网地址:https://kubernetes.github.io/ingress-nginx/deploy/
#以yaml形式进行部署 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/baremetal/deploy.yaml #helm进行部署 helm upgrade --install ingress-nginx ingress-nginx \ --repo https://kubernetes.github.io/ingress-nginx \ --namespace ingress-nginx --create-namespace
2、ingress暴露服务的方式
方式一:Deployment+LoadBalancer模式的Service
如果要把ingress部署在公有云,那用这种方式比较合适。用Deployment部署ingress-controller,创建一个 type为 LoadBalancer 的 service 关联这组 pod。大部分公有云,都会为 LoadBalancer 的 service 自动创建一个负载均衡器,通常还绑定了公网地址。 只要把域名解析指向该地址,就实现了集群服务的对外暴露
方式二:DaemonSet+HostNetwork+nodeSelect
用DaemonSet结合nodeSelect把pod部署到固定节点上,再通过HostNetWork直接讲pod与宿主机的的网络打通,直接使用宿主机的80/443端口进行访问,这种方式整个请求链路更简单,性能相比较NodePort的方式更好,缺点是一个主机只能部署一个pod。
方式三:Deployment+NodePort模式的Service
用Deployment部署ingress-controller,创建一个 type为NodePort的service,这样就会暴露在集群节点的特定端口上面,由于NodePort暴露的端口不是80/443端口,一般前端还会加一个负载均衡,或者把域名解析到node节点的公网ip上。由于多了一层nat转发性能会不如方式二
3、基于主机名作负载均衡
注意:通配符匹配要求http host头部字段与通配符规则中的后缀部分相同。(例如:*.foo.com
匹配 bar.foo.com, 但不匹配 bar.bar.foo.com)
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-wildcard-host annotations: kubernetes.io/ingress.class: "nginx" ##指定Ingress Controller的类型 nginx.ingress.kubernetes.io/use-regex: "true" ##指定后面rules定义的path可以使用正则表达式 nginx.ingress.kubernetes.io/proxy-connect-timeout: "600" ##连接超时时间,默认为5s nginx.ingress.kubernetes.io/proxy-send-timeout: "600" ##后端服务器回转数据超时时间,默认为60s nginx.ingress.kubernetes.io/proxy-read-timeout: "600" ##后端服务器响应超时时间,默认为60s nginx.ingress.kubernetes.io/proxy-body-size: "10m" ##客户端上传文件,最大大小,默认为20m #nginx.ingress.kubernetes.io/rewrite-target: / ##URL重写 nginx.ingress.kubernetes.io/app-root: /index.html spec: rules: - host: "foo.bar.com" http: paths: - pathType: Prefix path: "/bar" backend: service: name: service1 port: number: 80 - host: "*.foo.com" http: paths: - pathType: Prefix path: "/foo" backend: service: name: service2 port: number: 80
4、基于URL做负载均衡
注意:如果路径的最后一个元素是请求路径中的最后一个元素的子字符串,则不会匹配,(例如:/foo/bar
匹配 /foo/bar/baz
, 但不匹配 /foo/barbaz
)
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: nginx-web annotations: kubernetes.io/ingress.class: "nginx" ##指定Ingress Controller的类型 nginx.ingress.kubernetes.io/use-regex: "true" ##指定后面rules定义的path可以使用正则表达式 nginx.ingress.kubernetes.io/proxy-connect-timeout: "600" ##连接超时时间,默认为5s nginx.ingress.kubernetes.io/proxy-send-timeout: "600" ##后端服务器回转数据超时时间,默认为60s nginx.ingress.kubernetes.io/proxy-read-timeout: "600" ##后端服务器响应超时时间,默认为60s nginx.ingress.kubernetes.io/proxy-body-size: "10m" ##客户端上传文件,最大大小,默认为20m #nginx.ingress.kubernetes.io/rewrite-target: / ##URL重写 nginx.ingress.kubernetes.io/app-root: /index.html spec: rules: - host: www.jiege.com http: paths: - path: /app1 backend: serviceName: magedu-tomcat-app1-service servicePort: 80 - path: /app2 backend: serviceName: magedu-tomcat-app2-service servicePort: 80
5、配置TLS加密
可以将证书先配置为secrt类型来做保护,ingress只支持单个TLS端口443
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: nginx-web spec: rules: - host: www.jiege.com http: paths: - path: /app1 backend: serviceName: magedu-tomcat-app1-service servicePort: 80 - path: /app2 backend: serviceName: magedu-tomcat-app2-service servicePort: 80
注意:默认规则上无法使用TLS,因为需要向所有可能的子域名发放证书,因此,TLS字段中,hosts的值需要与rules字段中hosts完全匹配。
示例:
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: nginx-web namespace: magedu annotations: kubernetes.io/ingress.class: "nginx" ##指定Ingress Controller的类型 nginx.ingress.kubernetes.io/ssl-redirect: 'true' ##开启重定向 spec: tls: - hosts: - www.jiege.com secretName: tls-secret - hosts: - mobile.jiege.com secretName: mobile-tls-secret rules: - host: www.jiege.com http: paths: - path: / backend: serviceName: magedu-tomcat-app1-service servicePort: 80 - host: mobile.jiege.com http: paths: - path: / backend: serviceName: magedu-tomcat-app2-service servicePort: 80
6、Annotations注解
注解用来配置当前ingress资源实例中的Nginx虚拟主机相关的配置,也就是通过Annotations来开启一些nginx功能
示例
注解 | 类型 | 功能描述 |
---|---|---|
nginx.ingress.kubernetes.io/enable-access-log | true 或 false | 对当前虚拟主机设置是否启用访问日志,默认为真 |
nginx.ingress.kubernetes.io/client-body-buffer-size | string | 同 Nginx 配置指令 client_body_buffer_size |
nginx.ingress.kubernetes.io/use-regex | true 或 false | 是否对当前虚拟主机的 Nginx 指令 location 使用正则方式进行路径匹配,默认值为 false |
nginx.ingress.kubernetes.io/custom-http-errors | []int | 根据响应码状态定义为错误状态并跳转到设置的默认后端 |
nginx.ingress.kubernetes.io/default-backend | string | 自定义默认后端的资源对象 Service 名称,当客户端的请求没有匹配的 Nginx 规则或响应错误时,将被转发到默认后端 |
nginx.ingress.kubernetes.io/permanent-redirect | string | 设置永久重定向的目标地址 |
nginx.ingress.kubernetes.io/permanent-redirect-code | number | 自定义永久重定向的响应码,默认为 301 |
nginx.ingress.kubernetes.io/rewrite-target | URI | 同 Nginx 配置指令 rewrite |
nginx.ingress.kubernetes.io/limit-rate | number | 访问流量速度限制,同 Nginx 配置指令 limit_rate |
nginx.ingress.kubernetes.io/limit-connections | number | 节并发连接数限制,同 Nginx 配置指令 limit_conn |
nginx.ingress.kubernetes.io/enable-global-auth | true 或 false | 如果 ConfigMap 的 global-auth-url 被设置,Nginx 会将所有的请求重定向到提供身份验证的 URL,默认为 true |
nginx.ingress.kubernetes.io/service-upstream | true 或 false | 默认 Nginx 以 Service 中 Pod 的 IP 和端口为 Upstream 中的成员列表,该参数为 true 时,将以 Service 的 ClusterIP 和端口为被代理入口,该功能避免了因 Pod 漂移带来的 Upstream 的配置变化 |
nginx.ingress.kubernetes.io/backend-protocol | НТТР 或 HTTPS 或 GRPC 或 GRPCS 或 AJP 或 FCGI | 设置代理后端服务器的代理协议类型,默认为 HTTP |
nginx.ingress.kubernetes.io/load-balance | round_robin 或 ewma | 设置负载均衡算法,基于 balancer_by_lua 模块实现,支持轮询和 Peak EWMA 两种负载算法 |
到此这篇关于nginx ingress的具体使用的文章就介绍到这了,更多相关nginx ingress内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
- nginx-ingress-controller日志持久化方案的解决
- k8s部署ingress-nginx的方法步骤
- nginx ingress代理websocket流量的配置方法
- 解决国内k8s的ingress-nginx镜像无法正常pull拉取问题
- k8s之ingress-nginx详解和部署方案
- 安装ingress-nginx遇到的一些坑实战记录
- nginx ingress限速那些事浅析
- 使用Nginx Ingress 优雅显示错误页面
- nginx-ingress-controller部署配置详解
- k8s部署ingress-nginx的详细步骤大全
- Nginx ingress controller高可用的实现
相关文章
Debian下搭建Nginx和Tomcat服务器实现负载均衡的方案
这篇文章主要介绍了Debian下搭建Nginx和Tomcat服务器实现负载均衡的方案,其主要思想依然是动静分离并且以Nginx来进行反向代理这样的路子,需要的朋友可以参考下2015-12-12nginx connect() to unix:/var/run/php-fpm.sock failed (11: Re
这篇文章主要介绍了nginx connect() to unix:/var/run/php-fpm.sock failed (11: Resource temporarily unavailable),需要的朋友可以参考下2015-01-01Nginx HTTP:413 Request Entity Too Large解决方法
这篇文章主要介绍了Nginx HTTP:413 Request Entity Too Large解决方法,这个问题需要修改PHP配置以及Nginx配置才可以解决,需要的朋友可以参考下2015-07-07Nginx根据url中的path动态转发到upstream的实现
这篇文章主要介绍了Nginx根据url中的path动态转发到upstream的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2020-01-01Nginx启动成功却无法访问网页的问题分析和解决方案(完整的排除方案)
我是用的阿里云的服务器,所以我的问题就在于阿里云服务器必须单独开端口,在找到这个问题之前,我已经把所有能试的方法试过了一遍都没有问题,在增加端口之后直接成功了,如果你也遇到了这样的问题,就和我一起排除吧2023-12-12
最新评论