基本架构
首先简单了解下kubernetes gateway api这个东东
https://github.com/kubernetes-sigs/gateway-api
顾名思义是个api,所以只定义了api,并不负责实现。它这个controller只负责validate CRD,然后什么也不干。
从语法来看目前只支持如下几种
This version of the API is has beta level support for the following resources:
-
v1beta1.GatewayClass
-
v1beta1.Gateway
-
v1beta1.HTTPRoute
具体从
gatewayClassName
可以看出,设置了谁家的实现,需要谁家自己来认领实现。
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: gateway
namespace: istio-ingress
spec:
gatewayClassName: istio
可以说写了istio就是由istio controller自身来reconcile这个额外的CRD
最终的谜底将会在istio的代码中解答
那么gateway-api controller不干活,只有istio controller干活,去istio代码找实现就对了
找到具体实现的代码在这里
https://github.com/istio/istio/blob/master/pilot/pkg/config/kube/gateway/conversion.go
func buildDestination(ctx ConfigContext, to k8s.BackendRef, ns string) (*istio.Destination, *ConfigError) {
部分省略…………
if nilOrEqual((*string)(to.Group), "") && nilOrEqual((*string)(to.Kind), gvk.Service.Kind) {
// Service
if nilOrEqual((*string)(to.Group), features.MCSAPIGroup) && nilOrEqual((*string)(to.Kind), "ServiceImport") {
// Service import
if nilOrEqual((*string)(to.Group), gvk.ServiceEntry.Group) && nilOrEqual((*string)(to.Kind), "Hostname") {
// Hostname synthetic type
部分省略…………
return &istio.Destination{}, &ConfigError{
Reason: InvalidDestinationKind,
Message: fmt.Sprintf("referencing unsupported backendRef: group %q kind %q", emptyIfNil((*string)(to.Group)), emptyIfNil((*string)(to.Kind))),
}
显然
backendRefs
就实现了三种gvk
- 原生kube
对象Service
- Multi-Cluster Service APIs 的
对象ServiceImport
- 原生kube
对象ServiceEntry
当你在
backendRefs
没有显式地写
kind
,默认就是
Service
类型。
至此谜底揭晓。那么有没有可能实现
VirtualService
呢?
也不是没有可能。有时没事关注下这个函数就可以了。
剩下的一点疑惑
至于istio controller有没有产生中间转换的
VirtualService
呢?
毕竟你都已经把引用的gvr都写在这里了
然而的确没有,无论是kubectl get,还是直接curl apiserver查询,都查不到。
然而的然而,这里到底有没有转换已经并不重要了。
回到最初
最后谈一下最初使用openkruise/rollouts的疑惑。
究竟能使用istio到何种程度?
现在看就是跟nginx ingress一样的程度。区别不大。