kubernetes-核心资源之Ingress
1、Ingress
在Kubernetes中,服务和Pod的IP地址仅可以在集群网络内部使用,对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务,在Kubernetes中可以通过NodePort和LoadBalancer这两种类型的服务,或者使用Ingress。Ingress本质是通过http代理服务器将外部的http请求转发到集群内部的后端服务。Kubernetes目前支持GCE和nginx控制器;另外,F5网络为Kubernetes提供了F5 Big-IP控制器。通过Ingress,外部应用访问群集内容服务的过程如下所示。
Ingress控制器通常会使用负载均衡器来负责实现Ingress,尽管它也可以通过配置边缘路由器或其它前端以HA方式处理流量。
2、Ingress配置文件
下面是Ingress YAML配置文件的示例:
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80
- 1-6行:Ingress YAML文件中的1-6行与其它的Kubernetes配置文件一样,需要apiVersion, kind和metadata字段。此示例定义了名称为test-ingress的Ingress。
- 7-9行:Ingress规格具有配置负载均衡器或代理服务器所需的所有信息。最重要的是,它包含与所有传入请求相匹配的规则列表。目前,Ingress资源仅支持http规则。
- 10-11行:每个http规则都包含以下信息:一个主机(例如:foo.ba.com,在这个例子中为*),一个路径列表(例如:/testpath),每个路径都有一个相关的后端(test:80)。在负载均衡器将业务引导到后端之前,主机和路径都必须匹配传入请求的内容。
- 12-14行:后端是服务:端口(test:80)的组合。Ingress流量通常被直接发送到与后端相匹配的端点。
3、Ingress类型
3.1 代理单一服务
Kubernetes可以使用LoadBalancer和NodePort类型的服务暴露服务,也可以通过一个Ingress来实现。下面是名称为test-ingress的Ingress YAML文件,它将对外代理名称为testsvc的服务。
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: single-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: serviceName: s1 servicePort: 80
通过kubectl create -f创建上述的Ingress,在创建后可以通过kubectl get ing的命令获取Ingress的列表信息:
$ kubectl get ing
NAME RULE BACKEND ADDRESS
single-ingress –s1:80 107.178.254.228
3.2 代理多个服务
如前所述,在kubernetes 中Pod的IP地址只能对群集内的其它的应用可见。因此,如果需要接受集群外部的流量,并将其代理到集群中后端服务。在此示例中,通过foo.bar.com(IP地址为:178.91.123.132)主机作为代理服务器。当路径为http://foo.bar.cm:80/foo时,将会访问后端的s1服务;当路径为http://foo.bar.cm:80/bar时,将会访问后端的s2服务。
foo.bar.com -> 178.91.123.132 -> / foo s1:80 / bar s2:80
针对上述场景,Ingress的YAML配置文件如下所示:
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: mult-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: serviceName: s1 servicePort: 80 - path: /bar backend: serviceName: s2 servicePort: 80
通过kubctl create -f命令创建上述的Ingress:
$ kubectl get ing
NAME RULE BACKEND ADDRESS
mult-ingress – foo.bar.com /foo s1:80 /bar s2:80
默认后端:没有规则的入口,就像前一节中所示的那样,会将所有的流量发送到一个默认的后端。通过指定一组规则和默认后端,可以使用相同的技术来告诉负载均衡器,可以在哪里能够找到网站的404页。如果在Ingress中没有与请求头中主机相匹配的主机,并且/或者没有与请求的URL相匹配的路径,那么路由将被路由到默认的后端。
本文转自中文社区-kubernetes-核心资源之Ingress

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubernetes-基于RBAC的授权
1、RBAC介绍 在Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。从1.8开始,RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC,启用RABC。在RABC API中,通过如下的步骤进行授权:1)定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;2)绑定角色:将主体与角色进行绑定,对用户进行访问授权。 1.1 角色和集群角色 在RBAC API中,角色包含代表权限集合的规则。在这里,权限只有被授予,而没有被拒绝的设置。在Kubernetes中有两类角色,即普通角色和集群角色。可以通过Role定义在一个命名空间中的角色,或者可以使用ClusterRole定义集群范围的角色。一个角色只能被用来授予访问单一命令空间中的资源。下面是在“default”命令空间中定义了一个名为“pod-reader”的角色,此角色能够对在“defaul...
- 下一篇
Kubernetes 网络改进的三项实践分享
自研CNI IPAM插件 解决K8s功能问题 首先,在功能方面,Kubernetes 网络模型由于IP不固定,无法对IP资源进行精细管控,无法使用基于IP的监控和基于IP的安全策略,此外,一些IP发现的服务部署十分困难,给运维人员增加了很大的工作难度。例如由于IP不固定,令很多采用IP固定来做的传统监控和审计机制全部失效。此外,很多软件是对MAC地址进行授权,IP地址不固定无法购买授权,IP固定的需求在一定场景下客观存在。 为了解决这一问题,灵雀云把IP当做重要资源,进行单独管理。灵雀云自研的CNI IPAM 插件,实现了IP导入和IP权限管理功能,可以进行网段的添加和删除,可在Kubernetes进行网段的精细化配置。例如,给某个业务或者某几个用户分配一个网关,先对IP进行网关设置,路由设置以及DNS设置;有了网段之后,进行IP添加或删除,哪些IP可用都可以由管理员指定,经过权限和配额之后顺利创建服务。 IPVS解决K8S大流量下性能线性下降问题 其次,在性能方面,由于Kubernetes最早是基于Iptables来做的,Iptables 没有增量更新功能,更新一条规则需要整体flu...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS关闭SELinux安全模块
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS8安装Docker,最新的服务器搭配容器使用