公有云托管K8S的对外服务之Ingress

  之前搭建并使用了微软云Azure托管的K8S平台AKS,最近又在华为云上搭建了CCE,加上测试使用的AWS和阿里云的K8S平台,逐渐掌握了一些主流公有云厂商基于K8S原生服务的使用方式,学而不思则罔,如果实践是检验真理的唯一标准,那实践后的总结就是在创造真理,K8S涉及的内容太多,其中网络最为复杂,而网络又分集群入口、出口网络,以及Pod间的Networkpolicy等等,光是Calico网络模型估计就能连载几篇,本文主要针对公有云托管模式下的K8S集群对外暴露服务的Ingress,废话少说,开整

  我们都知道K8S中工作负载有很多种,最常用的是无状态负载(Depolyment),其他还包括有状态负载(StatetfulSet),守护进程(DaemonSet)以及各种任务(Job和CronJob),不同的工作负载适合不同的场景,这里不过多赘述,工作负载调用的最小单元是Pod,负载通过副本数量控制Pod数量,而工作负载需要被访问或者访问别的负载,这时候就引入了Service的概念,K8S集群内部可以直接通过Service名称进行访问,但Service是基于四层TCP和UDP协议转发的,而在实际使用场景中,四层Service无法满足应用层存在的大量HTTP/HTTPS访问需求,因此又引入了Ingress的概念来暴露服务,使用方式如下:

公有云托管K8S的对外服务之Ingress_第1张图片

对于自建K8S集群来说,负载均衡器可能需要自己实现,比如F5、Nginx、LVS等,而负载均衡作为公有云最常见的PaaS服务,显然只要和托管的K8S平台结合一下就OK了,你能想到,K8S官方和公有云厂商显然早就看穿一切了,于是K8S官方的Service类型从Nodeport,ClusterIP,又加入了Loadbalancer类型,而公有云厂商也支持通过YAML创建云上服务,比如Azure的beta版service.beta.kubernetes.io/azure-load-balancer-internal: "true",这样一来事情就变得简单了,不过好像上图有个概念忘记说明了,那就是Ingress Controller,这是一个抽象的概念,你可以这样理解:Ingress资源:一组基于域名或URL把请求转发到指定Service实例的访问规则,是Kubernetes的一种资源对象,Ingress实例被存储在对象存储服务etcd中,通过接口服务实现增、删、改、查的操作。

Ingress Controller:请求转发的执行器,用以实时监控资源对象Ingress、Service、End-point、Secret(主要是TLS证书和Key)、Node、ConfigMap的变化,解析Ingress定义的规则并负责将请求转发到相应的后端Service。

这个Ingress Controller需要借助一些插件实现,比如最常用的NGINX Ingress Controller,HAProxy也是一种,而公有云厂商大都会自研网络插件,说是自研,其实就是在托管的K8S集群上帮你实现了很多插件的功能,这样一来,大多云厂商的托管平台就会出现两种服务的暴露方式,一种是使用开源Ingress-controller插件

公有云托管K8S的对外服务之Ingress_第2张图片

第二种是使用自研的网络插件:

公有云托管K8S的对外服务之Ingress_第3张图片

 这两种模式云厂商给的区别都模棱两可,通过使用大概总结如下:

1.Ingress-controller高可用:

  1.ELB类型的高可用由厂商负责,因为会保证ELB的SLA以及Master节点的性能

  2.Nginx类型的服务插件需要自己保证服务高可用,可以使用node污点或者守护进程的方式实现

2.ELB和Service类型兼容:

  1.ELB类型的ELB(有点绕)其实是七层的负载均衡,因为是直接调用Service,所以这种类型调用的Service需要是Nodeport或者Loadbalancer类型,ClusterIp类型是不可以的,而Nodeport类型的服务只要节点能被访问,就意味着这个服务也能被访问,那也就是说Node如果绑定了公网IP,它上面的服务还用啥ingress了,直接都可以访问了,所以这种模式需要配合权限控制来使用

  2.Nginx类型的ELB是四层的,它只需把请求透传过来就可以,真正起作用的是部署的Nginx-Ingress,所以这种类型调用的service任何类型都可以

补充:华为的四层和七层的ELB都是一个服务,主要看你怎么用,而Azure的四层叫ALB,七层却叫Application gateway,这可不是注册API的那个服务,那个服务它叫API Management service,真是马虎不得啊,AWS七层的叫ALB,四层的叫NLB(是不有又涨知识了)

3.日志Log:

  1.网安法最常见的两个要求,日志保存六个月和保留访问的源IP,ELB类型的主要日志都在PaaS级别的ELB服务,实现这两个要求简直小case

  2.Nginx类型的就麻烦了,四层的负载均衡几乎没有任何有意义的日志,而且它还会做NAT,使后端的应用捕获不到访问源IP,所以你需要对它进行设置,而且这还不算完,你还要把这个源ip在集群安全组下放行,要不然根本进不来集群

补充:监控等metric指标同样适用,根本区别就是公有云PaaS服务和自建负载的区别

4.路由规则配置:

   1.ELB类型的捕获日志是很方便,但是配置规则就是基于ELB服务本身,不支持路由重定向

   2.Nginx类型的就方便多了,你只要会配置Nginx.conf就可以了,nginx本身的那些规则都支持

5.其他区别:

  1.ELB类型一个集群支持多个ELB实例,Nginx类型一个集群只支持一个ELB实例

  2.ELB类型占用Master节点,不占用工作节点,Nginx类型占用Worker节点,需要Nginx组件运行成本

  如果你使用主流公有云托管的K8S平台,同时又要暴露你的服务,那你大概率会遇到同样的问题,但是服务网格Istio使用Istio Gateway,可以理解它是Ingress的加强版,比如灰度发布的流量比例控制就是靠它实现的(有时间再细讲,这都是后话了),K8S复杂又强大,这只是它的冰山一角,如果你管理的核心应用(几千台节点)正运行在K8S上,那你一定幸运的发现了很多细微的问题,时间总是把一部分人推向海边,使他们成为最早看见太阳的那一批人。

你可能感兴趣的:(网络,ingress,k8s)