Kubernetes学习之Ingress

最新推荐文章于 2024-10-03 13:33:13 发布

Micky_Yang

最新推荐文章于 2024-10-03 13:33:13 发布

阅读量785

点赞数

分类专栏： Kubernetes学习

本文链接：https://blog.csdn.net/Micky_Yang/article/details/108183467

版权

本文深入探讨了Kubernetes的Ingress资源，解释了其作为HTTP(S)负载均衡器的角色，以及如何通过Ingress控制器实现流量路由。内容包括Ingress的基本概念、创建Ingress资源的步骤、不同类型的Ingress资源、Ingress控制器的工作原理以及在阿里云环境下使用Ingress的实践。

摘要由CSDN通过智能技术生成

一、认识Ingress
　　Kubernetes提供了两种内建的负载均衡机制（cloud load balancing）用于发布公共应用，一种是工作于传输层的Service资源，它实现的是"TCP负载均衡器"，另一种是Ingress资源，它实现的是"HTTP(S)负载均衡器"。
　　Kubernetes中，Service资源和Pod资源的IP地址仅能用于集群网络内部的通信，所有的网络流量都无法穿透边界路由器（Edge Router）以实现集群内外通信。尽管可以为Service使用NodePort或者LoadBalancer类型通过节点引入外部流量，但它依然是四层流量转发，可用的负载均衡器也为传输层负载均衡机制。
　　Ingress是Kubernetes API标准资源类型之一，它其实就是一组基于DNS名称（host）或URL路径把请求转发至指定的Service资源的规则，用于将集群外部的请求流量转发至集群内部完成服务发布。然而，Ingress资源自身并不能进行"流量穿透"，它仅仅是一组路由规则的集合，这些规则要想真正发挥作用还需要其他功能的辅助，如监听某套接字，然后根据这些规则的匹配机制路由请求流量。这种能够为Ingress资源监听套接字并转发流量的组件被称为Ingress控制器（Ingress Controller）。
　　Ingress控制器可以由任何具有反向代理（HTTP/HTTPS）功能的服务程序实现，如Nginx、Envoy、HAProxy、Vulcand和Traefik等等。Ingress控制器自身也是运行于集群中的Pod资源对象，它与被代理的运行为Pod资源的应用运行于同一网络中。
　　在这里插入图片描述
　　另一方面，使用Ingress资源进行流量分发时，Ingress控制器可基于某Ingress资源定义的规则将客户端请求流量直接转发至与Service对于的后端Pod资源之上，这种转发机制会绕过Service资源，从而省去了由kube-proxy实现的端口代理开销。Ingress规则需要由一个Service资源对象辅助识别相关的所有Pod对象，但是ingress-nginx控制器可经由api.linux.io规则的定义直接将请求流量调度至pod3或pod4，而无须经由Servcie对象API的再次转发，WAP相关规则的作用方式与此类同。

二、创建Ingress资源
　　Ingress资源是基于HTTP虚拟主机或URL来转发规则，它在配置资源清单的spec字段中嵌套了rules、backend和tls等字段进行定义。Ingress Spec中的字段是定义Ingress资源的核心组成部分，它主要嵌套如下三个字段：
　　rules<Object>：用于定义当前Ingress资源的转发规则列表；未由rules定义的规则，或者没有匹配到的任何规则时，所有流量都会转发到由backend定义的默认后端Servcie上。
　　backend<Object>：默认的后端用于服务那些没有匹配到任何规则的请求；定义Ingress资源时，至少应该定义backend或者rules规则两者之一；此字段用于让负载均衡器指定一个全局默认的后端。
　　tls<Object>：TLS配置，目前仅仅支持通过默认端口443提供服务；如果要配置指定的列表成员指向了不同的主机，则必须通过SNI TLS扩展机制来支持此功能。

1）编写Ingress的yaml文件

]# cat ingress.yaml 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: www.ilinux.io
    http:
      paths:
      - backend:
          serviceName: myapp-svc
          servicePort: 80

]# kubectl apply -f ingress.yaml 
ingress.extensions/my-ingress created

2）查看Ingress资源

]# kubectl get ingress -o wide 
NAME         CLASS    HOSTS           ADDRESS   PORTS   AGE
my-ingress   <none>   www.ilinux.io             80      8s

]# kubectl describe ingress my-ingress
Name:             my-ingress
Namespace:        default
Address:          
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host           Path  Backends
  ----           ----  --------
  www.ilinux.io  
                    myapp-svc:80 (10.244.1.86:80,10.244.2.54:80)
Annotations:     kubernetes.io/ingress.class: nginx
Events:          <none>

三、Ingress资源类型
　　基于HTTP暴露的每个Servcie资源均可发布于一个独立的FQDN主机名之上，如"www.linux.io"；也可以发布于某主机的URL路径之上，从而将它们整合到同一个Web站点，如"www.linux.io/grafana"。至于是否需要发布为HTTPS类型的应用则取决于用户的业务需求。

1）单Servcie资源型Ingress
　　暴露单个服务的方法有很多种，如服务类型中的NodePort、LoadBalancer等，不过一样可以考虑使用Ingress资源来暴露服务，此时只需要为Ingress制定"default backend"即可。

]# cat ingress.yaml 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-svc
    servicePort: 80

]# kubectl apply -f ingress.yaml 
ingress.extensions/my-ingress created

]# kubectl describe ingress my-ingress
Name:             my-ingress
Namespace:        default
Address:          
Default backend:  my-svc:80 (10.244.1.87:80,10.244.2.55:80)
Rules:
  Host        Path     Backends
  ----        ----     --------
  *           *