Kubernetes中的Ingress API对外提供简单而功能强劲的方法来管理与kubernetes集群内工作负载通信的入网流量。 在Kubernetes 1.18版本中,我们对Ingress API进行了以下3项重大改进:
- 新增pathType字段,可以指定应该匹配哪种Ingress路径
- 新增IngressClass资源,可以指定控制器应如何实现Ingress
- 支持主机名的通配符
路径匹配
新增的pathType字段,可以指定应该匹配哪种Ingress路径。 当前支持三种类型:
- ImplementationSpecific(默认): 使用此路径类型,匹配方式取决于实现IngressClass的控制器
- 完全匹配: 与URL完全匹配且区分大小写
- 前缀: 以/分隔的URL路径前缀进行匹配。 匹配区分大小写,并且在逐个路径的基础上进行匹配
Ingress配置增强
Ingress资源在设计时秉承简易性设计准则,从而提供了一组简易字段以满足绝大多数应用场景。 但随着时间的推移,以及使用场景的拓宽,开始依赖各种的自定义注释来进行进一步的配置。 因此新的Ingress资源提供了一种替换注释的方案。
在Ingress规范中添加了一个新的ingressClassName字段,该字段用于决定应用于该Ingress的具体IngressClass。
1 | apiVersion: networking.k8s.io/v1beta1 |
弃用Ingress注释
在Kubernetes 1.18发布(即添加IngressClass资源)之前,通常会在Ingress上使用kubernetes.io/ingress.class注释来指定某类Ingress。尽管从未正式定义此注释,但Ingress控制器已广泛支持此注释,现在正式弃用该字段。
设置默认的IngressClass
可以在集群中将特定的IngressClass标记为默认值。在IngressClass资源上将注释ingressclass.kubernetes.io/is-default-class
设置为true,就能够确保为未指定ingressClassName的新Ingress关联此默认IngressClass。
支持主机名通配符
许多Ingress提供程序都支持通配符主机名匹配,例如* .foo.com
和app1.foo.com
匹配,但是直到现在,规范都假定主机的FQDN完全匹配。当前,主机可以是精确匹配项(例如foo.bar.com
)或通配符(例如* .foo.com
)。精确匹配要求http主机头与主机设置匹配。通配符匹配要求http主机标头等于通配符规则的后缀。
| Host | Host header | Match |
| — | — | — | — |
|*.foo.com| .foo.com| Matches based on shared suffix|
|.foo.com| .foo.com| No match, wildcard only covers a single DNS label|
|.foo.com| foo.com| No match, wildcard only covers a single DNS label|
示例
这些新的Ingress功能可实现更多可配置性。 下面是一个同时使用pathType,ingressClassName和主机名通配符的Ingress示例:
1 | apiVersion: networking.k8s.io/v1beta1 |
Ingress Controller支持
由于这些功能是Kubernetes 1.18中的新增特性,因此每个Ingress控制器都需要一些时间来开发以完成对这些新功能的支持。首选查看Ingress控制器的相关文档,以了解它们何时将支持此新功能。
后续展望
在Kubernetes 1.19版本发布时,Ingress API有望从Beta变为GA。它将继续为用户管理Kubernetes工作负载的入网流量提供一种简单的方法。该API在保持简单和轻巧特性的同时希望为更复杂的用户场景提供更灵活的配置方案。
目前正在开发一套高度可配置的API,这些API在未来将成为Ingress的可选方案。这些API被称为新的“Service APIs”。当然其无意替代任何现有的API,而只是为复杂的用例提供了一种更灵活的配置方案。有关更多信息,请查看GitHub上的Service APIs。