基本架构
首先简单了解下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都写在这里了
"config": "/apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/http-0-istio-autogenerated-k8s-gateway"
然而的确没有,无论是kubectl get,还是直接curl apiserver查询,都查不到。
然而的然而,这里到底有没有转换已经并不重要了。
回到最初
最后谈一下最初使用openkruise/rollouts的疑惑。
究竟能使用istio到何种程度?
现在看就是跟nginx ingress一样的程度。区别不大。