行至水穷处 坐看“云”起时

☁️时代应用交付

K8s nginx ingress controller 原理及测试

k8s version: 1.6.7 无CNI

1. 创建Service Account

kubectl create -f nginx-ingress-sa.yaml

 

2. 绑定sa到role

注意这里随意给了一个较高的角色

kubectl create -f nginx-ingress-sa-role-binding.yaml

上述工作是为了保证nginx controller pod获得权限与api server通信:

 

3. 创建nginx controller pod需要使用的缺省tls 证书及key

kubectl create -f default-server-secret.yaml
相关yaml文件从https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example 获取

4. 部署nginx ingress controller

注意这里使用的是daemonset方式部署,为了保证每个node上都存在一个nginx pod

5. 创建相关测试用APP pod及其相关service

6. 创建nginx 提供应用ssl访问时候所需的证书及key

7. 创建k8s中的ingress 资源

8. 验证测试

注意系统本没有显示 ingress 的 address,这可能是由于我的环境没有使用CNI缘故?但从node节点的主机IP上是可以访问到相关nginx发布的应用的.

测试环境为了节省资源,只设置coffee,tea应用分别只其一个pod.

docker inspect 某个具体ingress controller pod:

 

访问某个具体的ingress controller所在node的宿主IP:访问coffee目录获得如下应用显示请求被分往coffee pod

《K8s nginx ingress controller 原理及测试》

访问/tea目录,请求被分往tea pod:

《K8s nginx ingress controller 原理及测试》

当创建ingress resource时, ingress controller上日志显示:

说明nginx controller获得相关ingress指定的配置更新.

Ingress原理

Ingress (resource)是k8s中配置controller的具体规则实现,可以理解为k8s具备L7 LB实现(比如基于host,基于uri)。

Ingress controller监控ingress resource配置,并对LB进行配置。一般来说controller会和具体的software LB作为一个pod被部署,不同的SW LB需要不同的controller实现。真正执行这些规则来分发请求的是 SW LB,所以controller里可以是nginx也可以其它比如traefik。下图描述了ingress的原理(注意图中错误: nginx实际直接将请求发送给pod,不经过service):《K8s nginx ingress controller 原理及测试》

nginx controller通过监视api server获取相关ingress、service、endpoint、secret、node、configmap对象,并在程序内部不断循环监视相关service是否有新的endpoints变化,一旦发生变化则自动更新nginx.tmpl 模板配置并产生新的配置文件进行reload

ingress resource里配置的是service名称,但nginx controller是直接将请求发送到相关pods.

《K8s nginx ingress controller 原理及测试》

nginx自动产生的一个配置示例:

ingress的一些问题

还不能支持较为复杂的LB特性,例如会话保持,nginx controller扩展了ingress可以做会话保持但必须使用nginx plus。

业务规则发生变化,会导致频繁修改ingress配置,且所变化都会引起nginx reload配置,这在大并发,复杂系统环境下可能会产生较大问题

外部访问的入口依赖使用controller所在node的宿主IP,且端口暴露在node IP上,对于多个应用需要同时使用相同端口时候会导致端口冲突

外部访问入口分散在多个node IP上,使得外部统一访问变得困难,且存在潜在的单点故障,一个node 失败,客户端只有重新发起到新的node节点的访问(虽然可以使用dns来轮询这些IP),因此有必要为这些入口访问点构建统一的虚拟IP(漂移IP),这可以通过在k8s环境外部使用其它高级LB来实现,比如F5。或者将多个提供访问的node节点构建为一个集群(比如使用keepalived),可参考 https://jimmysong.io/kubernetes-handbook/practice/edge-node-configuration.html

所以基本上ingress的方案还得需要一个外部LB来做统一的高容量请求入口,ingress只能作为k8s内部的二级LB(且功能有限)。与其这样,不如直接通过将pod暴露给外部LB来直接做负载均衡,可参考:https://www.myf5.net/post/2334.htm

其它缺点:

nginx无图形界面统一管理,nginx plus有 但是是商业版本。

ingress没有业务监控检查功能

只支持http L7

不能混合支持L4/L7 LB

不支持TLS的SNI,以及SSL re-encrypt

 

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注