k8s服务暴露之ingress与负载均衡

时间 2020-06-09

原文原文链接

k8s 对外暴露服务的方法

向 k8s 集群外部暴露服务的方式有三种： nodePort，LoadBalancer 和本文要介绍的 Ingress。每种方式都有各自的优缺点，nodePort 方式在服务变多的状况下会致使节点要开的端口愈来愈多，很差管理。而 LoadBalancer 更适合结合云提供商的 LB 来使用，可是在 LB 愈来愈多的状况下对成本的花费也是不可小觑。Ingress 是 k8s 官方提供的用于对外暴露服务的方式，也是在生产环境用的比较多的方式，通常在云环境下是 LB + Ingress Ctroller 方式对外提供服务，这样就能够在一个 LB 的状况下根据域名路由到对应后端的 Service，有点相似于 Nginx 反向代理，只不过在 k8s 集群中，这个反向代理是集群外部流量的统一入口。

Service 虽然解决了服务发现和负载均衡的问题，但对外访问的时候，NodePort类型须要在外部搭建额外的负载均衡，而LoadBalancer须要Kubernetes必须跑在支持的cloud provider上面。 Ingress就是为了解决这些限制的。

Ingress 是一个规则的集合，它容许集群外的流量经过必定的规则到达集群内的 Service 。 request--->ingress--->service.

Ingress由三个组件组成：

1.反向代理负载均衡器：即常见的负载均衡软件，如 nginx、Haproxy 等

2.Ingress Controller： kubernetes API 进行交互，实时的感知后端 service、pod 等变化， Ingress Controller 再结合下文的 Ingress 生成配置，而后更新反向代理负载均衡器，并刷新其配置，实现动态服务发现与更新

3.Ingress：规则集合；定义了域名与Kubernetes的service的对应关系;这个规则将与 Ingress Controller 结合， Ingress Controller 将其动态写入到负载均衡器配置中，从而实现总体的服务发现和负载均衡。

四：Service Load Balancer
在Ingress出现之前，Service Load Balancer谁推荐的解决Service局限性的方式。Service Load Balancer将haproxy跑在容器中，并监控service和endpoint的变化，经过容器IP对外提供4层和7层负载均衡服务。

五：Custom Load Balancer
自定义组件，代替kube-proxy来作负载均衡。如nginx plus, kube2haproxy等。

六：Endpoints
有几种状况须要用到没有selector的service
1.使用kubernetes集群外部的数据库时。
2.service中用到了其它namespace或kubernetes集群中的service
3.在kubernetes的工做负载与集群外的后端之间互相迁移。

1. kube-proxy 只容许本地访问node

2. NodePort 使用物理机端口和k8s service虚拟ip:端口映射nginx

3. LoadBalancer 使用NodeIp+Nodeport的方式实现，配合云环境GCE、aws提供的负载地址数据库

4. ingress 使用开源的反向代理负载均衡器来实现对外暴漏服务，好比 Nginx、Apache、Haproxy后端

做者：莫逐
连接： https://www.jianshu.com/p/b02dd40a16da
来源：简书
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

7层负载均衡

负载均衡（LB）在微服务架构演进中具备很是重要的意义，能够说的内容有不少，这里仅仅讨论四层和七层负载均衡的一些要点和区别，以便于对ingress的理解。所谓四层和七层负载均衡是按照网络层次OSI来划分的负载均衡类型（也能够按照其余的规则来分类，好比：应用的地理结构），简单来讲：四层负载均衡表示负载均衡器用ip+port接收请求，再直接转发到后端对应的服务上，工做在传输层( transport layer )；七层负载均衡表示负载均衡器根据虚拟的url或主机名来接收请求，通过处理后再转向相应的后端服务上，工做在应用层( application layer )。api

下图表示了4层和7层负载均衡在创建TCP链接上的区别，从图中能够看出，四层负载均衡须要创建的TCP链接其实之有一个，它只作一次转发，client直接和server链接；而7层负载均衡则须要创建两次TCP链接，client到LB，LB根据消息中的内容( 好比URL或者cookie中的信息 )来作出负载均衡的决定，接着创建LB到server的链接。浏览器

layer4VSlayer7_LB.pngbash

7层负载均衡有什么好处呢？服务器

由于存在解包/封包的过程，比4层LB更加CPU intensive，可是却极少下降性能；
能够编写更加智能的负载均衡策略，好比根据URL、cookie中的信息等，甚至对接收到的内容作一些优化和修改，好比加密、压缩；
使用buffer的方式来缓解服务器链接慢的问题，从而提升性能
具备7层负载均衡功能的设备一般也被称为反向代理服务器（reverse proxy server）

反向代理

举个例子：
正向代理：在使用VPS访问的时候，一般会使用一个本地的代理服务器，浏览器的网络包会先通过本地的代理服务器，代理服务器会经过远在异国它乡的电脑来访问并返回消息；这就比如去附近的咖啡店要先问一下手机咖啡店在哪里同样，手机就是一个正向代理服务器。
反向代理：当访问的请求到达时，那边也设置了一个代理服务器，它经过查看请求的URL，发现是想查找视频内容，于时把消息转给了视频搜索服务器（过程是我乱说的），这就比如你去朋友家作客，开门的倒是个管家，问你找谁？这时候管家就是一个反向代理了。cookie

其余OSI层也能够作反向代理网络

ingress

k8s 对外暴露服务（service）主要有两种方式：NotePort, LoadBalance，此外externalIPs也可使各种service对外提供服务，可是当集群服务不少的时候，NodePort方式最大的缺点是会占用不少集群机器的端口；LB方式最大的缺点则是每一个service一个LB又有点浪费和麻烦，而且须要k8s以外的支持；而ingress则只须要一个NodePort或者一个LB就能够知足全部service对外服务的需求。工做机制大体能够用下图表示：

实际上，ingress至关于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工做原理也确实相似于Nginx，能够理解成在 Ingress 里创建一个个映射规则 , ingress Controller 经过监听 Ingress这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 而后对外部提供服务。ingress包括：ingress controller和ingress resources

ingress controller：核心是一个deployment，实现方式有不少，好比nginx, Contour, Haproxy, trafik, Istio，须要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型能够是NodePort或者LoadBalancer。

ingress resources：这个就是一个类型为Ingress的k8s api对象了，这部分则是面向开发人员。

使用 Ingress 对外暴露服务

为了快速体验 Ingress，下面部署一个 nginx 服务，而后经过 Ingress 对外暴露 nginx service 进行访问。
首先部署 nginx 服务：
Deployment + Service：nginx.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: nginx
spec:
selector:
    app: nginx
ports:
    - port: 80
      targetPort: 80

kubectl create -f nginx.yml

接下来建立 Ingress 对外暴露 nginx service 80 端口：
ingress.yml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-nginx
annotations:
    # use the shared ingress-nginx
    kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: nginx.kube.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: 80

说明：
    kubernetes.io/ingress.class: "nginx"：Nginx Ingress Controller 根据该注解自动发现 Ingress；
    host: nginx.kube.com：对外访问的域名；
    serviceName: nginx：对外暴露的 Service 名称；
    servicePort: 80：nginx service 监听的端口；

注意：建立的 Ingress 必需要和对外暴露的 Service 在同一命名空间下！
将域名 nginx.kube.com 绑定到 k8s 任意节点 ip 便可访问：http://nginx.kube.com
上面的示例不支持 https 访问，下面举一个支持 https 的 Ingress 例子：经过 Ingress 访问 kubernetes dashboard 服务。
经过 Ingress 访问 kubernetes dashboard（支持 HTTPS 访问）
以前咱们使用 helm 以 nodePort 的方式部署了 kubernetes dashboard：「helm 部署 kubernetes-dashboard」，从集群外部只能经过 nodeIP:nodePort 端口号访问，接下来基于以前部署的 kubernetes-dashboard 配置如何经过 Ingress 访问，而且支持 HTTPS 访问，HTTP 自动跳转到 HTTPS。：
首先，练习使用，先用自签名证书来代替吧：

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout kube-dashboard.key -out kube-dashboard.crt -subj "/CN=dashboard.kube.com/O=dashboard.kube.com"

使用生成的证书建立 k8s Secret 资源，下一步建立的 Ingress 会引用这个 Secret：
kubectl create secret tls kube-dasboard-ssl --key kube-dashboard.key --cert kube-dashboard.crt -n kube-system
建立 Ingress 资源对象（支持 HTTPS 访问）：
kube-dashboard-ingress.yml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-kube-dashboard
annotations:
    # use the shared ingress-nginx
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
tls:
- hosts:
    - dashboard.kube.com
    secretName: kube-dasboard-ssl
rules:
- host: dashboard.kube.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubernetes-dashboard
          servicePort: 443
kubectl create -f kube-dashboard-ingress.yml -n kube-system

说明：
    kubernetes.io/ingress.class: "nginx"：Inginx Ingress Controller 根据该注解自动发现 Ingress；
    nginx.ingress.kubernetes.io/backend-protocol: Controller 向后端 Service 转发时使用 HTTPS 协议，这个注解必须添加，不然访问会报错，能够看到 Ingress Controller 报错日志：kubectl logs -f nginx-ingress-controller-mg8df

    2019/08/12 06:40:00 [error] 557#557: *56049 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: 192.168.26.10, server: dashboard.kube.com, request: “GET / HTTP/1.1”, upstream: “http://10.244.1.8:8443/”, host: “dashboard.kube.com”

报错缘由主要是 dashboard 服务后端只支持 https，可是 Ingress Controller 接到客户端的请求时日后端 dashboard 服务转发时使用的是 http 协议，解决办法就是给建立的 Ingress 设置：nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" 注解。解决方法参考自 StackOverflow：https://stackoverflow.com/questions/48324760/ingress-configuration-for-dashboard

    secretName: kube-dasboard-ssl：https 证书 Secret；
    host: dashboard.kube.com：对外访问的域名；
    serviceName: kubernetes-dashboard：集群对外暴露的 Service 名称；
    servicePort: 443：service 监听的端口；

    注意：建立的 Ingress 必需要和对外暴露的 Service 在同一命名空间下！
将域名 dashboard.kube.com 绑定到 k8s 任意节点 ip 便可访问：https://dashboard.kube.com

7层负载均衡

负载均衡（LB）在微服务架构演进中具备很是重要的意义，能够说的内容有不少，这里仅仅讨论四层和七层负载均衡的一些要点和区别，以便于对ingress的理解。所谓四层和七层负载均衡是按照网络层次OSI来划分的负载均衡类型（也能够按照其余的规则来分类，好比：应用的地理结构），简单来讲：四层负载均衡表示负载均衡器用ip+port接收请求，再直接转发到后端对应的服务上，工做在传输层( transport layer )；七层负载均衡表示负载均衡器根据虚拟的url或主机名来接收请求，通过处理后再转向相应的后端服务上，工做在应用层( application layer )。

layer4VSlayer7_LB.png

7层负载均衡有什么好处呢？

由于存在解包/封包的过程，比4层LB更加CPU‑intensive，可是却极少下降性能；
能够编写更加智能的负载均衡策略，好比根据URL、cookie中的信息等，甚至对接收到的内容作一些优化和修改，好比加密、压缩；
使用buffer的方式来缓解服务器链接慢的问题，从而提升性能
具备7层负载均衡功能的设备一般也被称为反向代理服务器（reverse‑proxy server）

反向代理

举个例子：
正向代理：在使用VPS访问的时候，一般会使用一个本地的代理服务器，浏览器的网络包会先通过本地的代理服务器，代理服务器会经过远在异国它乡的电脑来访问并返回消息；这就比如去附近的咖啡店要先问一下手机咖啡店在哪里同样，手机就是一个正向代理服务器。
反向代理：当访问的请求到达时，那边也设置了一个代理服务器，它经过查看请求的URL，发现是想查找视频内容，于时把消息转给了视频搜索服务器（过程是我乱说的），这就比如你去朋友家作客，开门的倒是个管家，问你找谁？这时候管家就是一个反向代理了。
关于反向代理的好处这里就很少介绍，感兴趣能够看这里

其余OSI层也能够作反向代理

ingress

k8s 对外暴露服务（service）主要有两种方式：NotePort, LoadBalance，此外externalIPs也可使各种service对外提供服务，可是当集群服务不少的时候，NodePort方式最大的缺点是会占用不少集群机器的端口；LB方式最大的缺点则是每一个service一个LB又有点浪费和麻烦，而且须要k8s以外的支持；而ingress则只须要一个NodePort或者一个LB就能够知足全部service对外服务的需求。工做机制大体能够用下图表示：

ingress.png

实际上，ingress至关于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工做原理也确实相似于Nginx，能够理解成在 Ingress 里创建一个个映射规则 , ingress Controller 经过监听 Ingress这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 而后对外部提供服务。ingress包括：ingress controller和ingress resources

ingress controller：核心是一个deployment，实现方式有不少，好比nginx, Contour, Haproxy, trafik, Istio，须要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型能够是NodePort或者LoadBalancer。

ingress resources：这个就是一个类型为Ingress的k8s api对象了，这部分则是面向开发人员。

假设已经有两个服务部署在了k8s集群内部：

$ kubectl get svc,deploy NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/coffee-svc ClusterIP <none> <none> 80/TCP 1m svc/tea-svc ClusterIP <none> <none> 80/TCP 1m NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/coffee 2 2 2 2 1m deploy/tea 1 1 1 1 1m

做者：MunCN
连接：https://www.jianshu.com/p/97dd4d59ac5a
来源：简书
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

对外服务方式

1. kube-proxy 只容许本地访问

2. NodePort 使用物理机端口和k8s service虚拟ip:端口映射

3. LoadBalancer 使用NodeIp+Nodeport的方式实现，配合云环境GCE、aws提供的负载地址