Ingress介绍
Ingress概念和原理介绍
服务访问
内部访问方式 ClusterIP
ClusterIP 服务是 Kubernetes 的默认服务。它给你一个集群内的服务,集群内的其它应用都可以访问该服务。集群外部无法访问它。在某些场景下我们可以使用 Kubernetes 的 Proxy 模式来访问服务,比如调试服务时。
外部访问方式
三种外部访问方式
1. NodePort
NodePort 服务是引导外部流量到你的服务的最原始方式。NodePort,正如这个名字所示,在所有节点(虚拟机)上开放一个特定端口,任何发送到该端口的流量都被转发到对应服务。
NodePort 服务特征如下:
- 每个端口只能是一种服务
- 端口范围只能是在apiserver配置的端口范围内:30000-32767(可调)
- 不在 YAML 配置文件中指定则会分配一个默认端口
2. LoadBalancer
LoadBalancer 服务是暴露服务到 Internet 的标准方式。所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件,没有路由等。这意味着你几乎可以发送任何种类的流量到该服务,像 HTTP,TCP,UDP,WebSocket,gRPC 或其它任意种类。
3. Ingress
通常情况下,Service 和 Pod 的 IP 仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到 Service 在 Node 上暴露的 NodePort 上,然后再由 kube-proxy 通过边缘路由器 (edge router) 将其转发给相关的 Pod 或者丢弃。而 Ingress 就是为进入集群的请求提供路由规则的集合
Ingress原理
Ingress是一种对象(资源)存在于API Server(ETCD)上,它的整个生命周期(创建、更新、销毁)可以被实时的监听 Ingress是对外(公网)服务到集群内的Service之间规则的集合:允许进入集群的请求被转发至集群内的Service Ingress能把Service(Kubernetes的服务)配置成外网能够访问的URL,流量负载均衡,终止SSL,提供于域名访问的虚拟主机等,用户通过访问URL(API资源服务的形式,例如:caas.one/kibana)进入和请求Service,一个Ingress控制器负责处理所有Ingress的请求流量
详细请看Ingress说明
- 所谓Ingress对象,其实就是k8s 对“反向代理”的一种抽象。
- Ingress 的实现分为两个部分 Ingress Controller 和 Ingress。
- Ingress Controller 是流量的入口,是一个实体软件, 一般是Nginx 和 Haproxy(较少使用)。
- Ingress 描述具体的路由规则。
- Ingress Controller 会监听 api server上的 /ingresses 资源 并实时生效。
- Ingerss 描述了一个或者多个 域名的路由规则,以 ingress 资源的形式存在。
简单说: Ingress 描述路由规则, Ingress Controller 实时实现规则。
Ingress Controller
Ingress Controller 实际上是一个监听 Ingress 对象以及它所代理的后端 Service 变化的控制器。
以ingress-nginx-controller为例说明
当一个新的 Ingress 对象由用户创建后,nginx-ingress-controller 就会根据 Ingress 对象里定义的内容,生成一份对应的 Nginx 配置文件(/etc/nginx/nginx.conf),并使用这个配置文件启动一个 Nginx 服务。
而一旦 Ingress 对象被更新,nginx-ingress-controller 就会更新这个配置文件。需要注意的是,如果这里只是被代理的 Service 对象被更新,nginx-ingress-controller 所管理的 Nginx 服务是不需要重新加载(reload)的。这当然是因为 nginx-ingress-controller 通过Nginx Lua方案实现了 Nginx Upstream 的动态配置。
此外,nginx-ingress-controller 还允许你通过 Kubernetes 的 ConfigMap 对象来对上述 Nginx 配置文件进行定制。这个 ConfigMap 的名字,需要以参数的方式传递给 nginx-ingress-controller。而你在这个 ConfigMap 里添加的字段,将会被合并到最后生成的 Nginx 配置文件当中。
一个 Nginx Ingress Controller 提供的服务,其实是一个可以根据 Ingress 对象和被代理后端 Service 的变化,来自动进行更新的 Nginx 负载均衡器。
Core Sync Logics:
Ingress-nginx has an internal model of the ingresses, secrets and endpoints in a given cluster. It maintains two copy of that (1) currently running configuration model and (2) the one generated in response to some changes in the cluster.
The sync logic diffs the two models and if there’s a change it tries to converge the running configuration to the new one.
There are static and dynamic configuration changes.
All endpoints and certificate changes are handled dynamically by posting the payload to an internal NGINX endpoint that is handled by Lua.
Ingress Controller 注意事项
- 一个集群中可以有多个 Ingress Controller, 在Ingress 中可以指定使用哪一个Ingress Controller
- 多个Ingress 规则可能出现竞争
- Ingress Controller 本身需要以hostport 或者 service形式暴露出来。 云端可以使用云供应商lb 服务。
- Ingress 可以为多个命名空间服务
- Ingress只能通过Annotations 进行设置。并且需要确保 Ingress Controller 启动时, 启用了 Annotations 选项
- Ingress Controller 放在独立命名空间中, 由管理员来管理。
- Ingress 放在各应用的命名空间中, 由应用运维来设置。
Ingress 相关代码
IngressSpec
|
|
store
store处理资源有:
- Ingress
- Endpoint
- Secret
- ConfigMap
- Service
|
|
NGINXController
NGINXController构造
|
|
Start()
- store.Run
- n.syncStatus.Run
- start(cmd) NGINX启动命令
- syncQueue.Run(time.Second, n.stopCh)
- syncQueue.EnqueueTask(task.GetDummyObject(“initial-sync”))
- 每5分钟 cleanTempNginxCfg()
- 监听n.updateCh.Out(),进行syncQueue.EnqueueTask处理
|
|
syncIngress
queue sync函数为syncIngress,遍历queue未同步的task进行sync处理,主要内容:
- ings := n.store.ListIngresses()
- hosts, servers, pcfg := n.getConfiguration(ings), servers是按host来构建的server配置
- OnUpdate(*pcfg),进行nginx config更新,实际上就是比较/etc/nginx/nginx.conf和 new-nginx-cfg是否一样,如果不一样,则按new-nginx-cfg最新的内容更新/etc/nginx/nginx.conf,并执行nginx reload
|
|
Server
- Hostname
- Locations
- SSLPassthrough
- …
|
|
部署
ingress是k8s内置资源类型,只需再安装ingress controller,以ingress-nginx-controller为例
ingress.yaml
注意:
- 不同版本k8s的apiVersion不同
- ingress的namespace要与其关联的service的namespace一致
|
|
deploy.yaml
官方安装ingress-nginx-controller例子
|
|
也可先把deploy.yaml下载下来
|
|
demo-example
|
|
ingress-nginx-controller打印信息,如下:
|
|