研究下istio对kubernetes gateway api的支持程度（一）

背景介绍

本文其实是因为openkruise/rollouts的原因而起，这里先简单介绍下背景

openkruise/rollouts与argo rollout是非常相似的项目，都是支持Canary Release的CD项目

多少是因为由于argo rollout在处理workload上的不便导致了openkruise/rollouts项目的诞生。

具体来说，argo rollout定义了一个Rollout的CRD作为唯一的workload，

而这个Rollout可以看做是Deployment语法的拓展。实际用起来就需要将原来的Deployment全部重写一遍转换成Rollout相当不方便。

但是作为后起之秀openkruise/rollouts，巧妙的使用了objectRef语法支持kube 原生的workload。

这样可以引用原来的Deployment，而不是重写CRD。

那么带来了另外一个问题，两者对istio的支持怎么样？

已知argo rollout是直接修改istio CRD，这方面完全不用担心。

而openkruise/rollouts则没有实现istio逻辑，而是使用了kubernetes gateway api进行控制

那么问题终于来到了本文的主题：

istio对kube gateway api的支持程度究竟怎么样？能完全替代吗？

环境配置

根据官方提供的例子

https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/

部署httpbin

kubectl apply -f samples/httpbin/httpbin.yaml

gateway api的具体配置

kubectl create namespace istio-ingress
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: gateway
  namespace: istio-ingress
spec:
  gatewayClassName: istio
  listeners:
  - name: default
    hostname: "*.example.com"
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: http
  namespace: default
spec:
  parentRefs:
  - name: gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
EOF

完了会自动生成一个新的独立的gateway controller。

验证底层envoy xds配置

接下来根据前几篇文章的方法，使用istioctl看一下envoy的配置到底有什么不一样。

查看全局状态

# istioctl proxy-status
NAME                                                  CLUSTER        CDS        LDS        EDS        RDS          ECDS         ISTIOD                      VERSION
gateway-57d696448d-vrml2.istio-ingress                Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-7cd55d9dc4-pw4x4     1.15.0
istio-egressgateway-775cf5d9b5-h24dz.istio-system     Kubernetes     SYNCED     SYNCED     SYNCED     NOT SENT     NOT SENT     istiod-7cd55d9dc4-pw4x4     1.15.0
istio-ingressgateway-ffbcc4c7f-9rw9j.istio-system     Kubernetes     SYNCED     SYNCED     SYNCED     NOT SENT     NOT SENT     istiod-7cd55d9dc4-pw4x4     1.15.0

新增加的gateway

# kubectl get gateway -n istio-ingress gateway
NAME      CLASS   ADDRESS          READY   AGE
gateway   istio   43.132.195.185   True    74s

一样的gateway

# istioctl proxy-config listeners gateway-57d696448d-vrml2.istio-ingress
ADDRESS PORT  MATCH DESTINATION
0.0.0.0 80    ALL   Route: http.80
0.0.0.0 15021 ALL   Inline Route: /healthz/ready*
0.0.0.0 15090 ALL   Inline Route: /stats/prometheus*

继续看route

# istioctl proxy-config routes gateway-57d696448d-vrml2.istio-ingress --name  http.80 
NAME        DOMAINS                 MATCH     VIRTUAL SERVICE
http.80     httpbin.example.com               http-0-istio-autogenerated-k8s-gateway.default

完整详细配置

# istioctl proxy-config routes gateway-57d696448d-vrml2.istio-ingress --name  http.80 -o json
[
    {
        "name": "http.80",
        "virtualHosts": [
            {
                "name": "httpbin.example.com:80",
                "domains": [
                    "httpbin.example.com"
                ],
                "routes": [
                    {
                        "match": {
                            "pathSeparatedPrefix": "/get",
                            "caseSensitive": true
                        },
                        "route": {
                            "cluster": "outbound|8000||httpbin.default.svc.cluster.local",
部分省略…………
                        "metadata": {
                            "filterMetadata": {
                                "istio": {
                                    "config": "/apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/http-0-istio-autogenerated-k8s-gateway"
                                }
                            }
                        },
                        "decorator": {
                            "operation": "httpbin.default.svc.cluster.local:8000/*"
                        }
部分省略…………

乍一看，根据之前的经验看这是一个istio规则生成的route，而不是根据kube service生成的（然而情况并不是这样）

具体分析请往后看

再看clusters

# istioctl proxy-config clusters gateway-57d696448d-vrml2.istio-ingress --fqdn httpbin.default.svc.cluster.local -o json
[
部分省略…………
        "name": "outbound|8000||httpbin.default.svc.cluster.local",
        "type": "EDS",
        "edsClusterConfig": {
            "edsConfig": {
                "ads": {},
                "initialFetchTimeout": "0s",
                "resourceApiVersion": "V3"
            },
            "serviceName": "outbound|8000||httpbin.default.svc.cluster.local"
        },
部分省略…………
        "metadata": {
            "filterMetadata": {
                "istio": {
                    "default_original_port": 8000,
                    "services": [
                        {
                            "host": "httpbin.default.svc.cluster.local",
                            "name": "httpbin",
                            "namespace": "default"
                        }
                    ]
                }
            }
        },
部分省略…………

这部分看上去也是istio规则生成的clusters，然而也并不是。

根本就没有定义过DestinationRule哪里来的对应的clusters？

最后看看endpoints

没有什么悬念，因为只有一个后端，也不存在subset。这部分没什么特别。

# istioctl proxy-config endpoints gateway-57d696448d-vrml2.istio-ingress --cluster "outbound|8000||httpbin.default.svc.cluster.local"
ENDPOINT          STATUS      OUTLIER CHECK     CLUSTER
172.16.0.8:80     HEALTHY     OK                outbound|8000||httpbin.default.svc.cluster.local

看到这里肯定会产生一些疑惑

gateway api定义了类似istio gateway和VirtualService的规则。

那么具体执行的时候是直接生成envoy配置还是中间转了一层到istio？

这里backendRefs用的是kube service那么是不是支持别的object呢？能不能直接支持istio VirtualService

如果能直接支持VirtualService，那么istio那套东西就都串起来可以正常使用了。

如果只能支持kube service，那局限还是很大的。

具体的分析，请看第二部分