基本架構
首先簡單了解下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一樣的程度。差別不大。