kmesh-net / kmesh

High Performance ServiceMesh Data Plane Based on Programmable Kernel

Home Page:https://kmesh.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

In Kmesh v0.1.0, enable L7 Routing on Kubernetes 1.27 and Istio 1.19

tmodak27 opened this issue · comments

What would you like to be added:
We would like Kmesh to be compatible with Kubernetes 1.27 and Istio 1.19 for L7 routing.

Why is this needed:
our production environment is running Kubernetes 1.27 and Istio 1.19. Currently, the latest Kubernetes version for which L7 routing works is 1.20, and the latest Istio version is 1.14.5 (see table at the bottom of the issue for reference).

Steps To Reproduce Issue

Setup

  1. OS: OpenEuler 23.03
  2. Kubernetes Version: 1.27
  3. Istio Version: 1.19
  4. Kmesh Version: v0.1.0
  5. Backend Services: 2 HTTP Services httpecho-a and httpecho-b
  6. HTTP Client: Netutils

Step 1:
Deploy two backend services httpecho-a and httpecho-b using the below configs

  • Yaml for httpecho-a
# kubectl  apply -f service-a.yaml
apiVersion: v1
kind: Service
metadata:
  name: httpecho-a
  labels:
    app: httpecho-a
    service: httpecho-a
spec:
  ports:
  - port: 5000
    name: http
  selector:
    app: httpecho-a
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpecho-a
  labels:
    app: httpecho-a
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpecho-a
      version: v1
  template:
    metadata:
      labels:
        app: httpecho-a
        version: v1
    spec:
      containers:
      - name: httpecho-a
        image: docker.io/istio/examples-helloworld-v1
        resources:
          requests:
            cpu: "100m"
        imagePullPolicy: IfNotPresent #Always
        ports:
        - containerPort: 5000
  • Yaml for httpecho-b
# kubectly apply -f service-b.yaml
apiVersion: v1
kind: Service
metadata:
  name: httpecho-b
  labels:
    app: httpecho-b
    service: httpecho-b
spec:
  ports:
  - port: 5000
    name: httpb
  selector:
    app: httpecho-b
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpecho-b
  labels:
    app: httpecho-b
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpecho-b
      version: v2
  template:
    metadata:
      labels:
        app: httpecho-b
        version: v2
    spec:
      containers:
      - name: httpecho-b
        image: docker.io/istio/examples-helloworld-v1
        resources:
          requests:
            cpu: "100m"
        imagePullPolicy: IfNotPresent #Always
        ports:
        - containerPort: 5000

Step 2: Deploy netutils client for sending http requests

kubectl run --image=hwchiu/netutils netutils

Send requests to http-echo-a and httpecho-b with the netutils client. Note the difference in pod names in the response from each service

$ kubectl exec -it netutils -- curl httpecho-a:5000
Hello V1, routed from pod httpecho-a-gu83s


$ kubectl exec -it netutils -- curl httpecho-b:5000
Hello V1, routed from pod httpecho-b-t7wx5

Step 3: Deploy Virtual Service for L7 Url Routing

This rule should route all requests sent to httpecho-b to httpecho-a instead

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: route-b-to-a
spec:
  hosts:
  - httpecho-b
  http:
  - match:
    - port: 5000
    route:
    - destination:
        host: httpecho-a.default.svc.cluster.local
        port:
          number: 5000

Step 4: Send request to httpecho-b

Note the pod name in the response. If routing works, it should be httpecho-a-gu83s, and NOT httpecho-b-t7wx5.

$ kubectl exec -it netutils -- curl  httpecho-b:5000/hello
Hello V1, routed from pod httpecho-b-t7wx5

If you run the above reproduction steps on Kubernetes 1.20 and Istio 1.19 the request would get successfully routed to httpecho-a.

Additional Context

As a part of our investigation, we tried running the same tests on other versions of Istio and Kubernetes. Below is an overview of our findings

kmesh_matrix

cc @nlgwcy

@tmodak27 Any error from kmesh? Can you paste it here

cc @nlgwcy

@tmodak27 Any error from kmesh? Can you paste it here

There is no error from kmesh. The request just does not get routed to the intended destination when we use Kubernetes 1.27 and Istio 1.19 (ie it fails silently).

@tmodak27 Can we talk in slack or weChat

After attempting and reproducing the steps in the oe2303 environment, where I set up a Kubernetes 1.25 cluster with Istio 1.20 using kind, I successfully achieved the routing functionality as described in the issue. However, there are still some lingering issues:

If I start kmesh first and then apply vs.yaml, the configuration doesn’t get refreshed, and the functionality doesn’t work correctly. It’s similar to the situation described in this issue. Only by restarting kmesh or applying vs.yaml after kmesh has been applied does it work properly.

After attempting and reproducing the steps in the oe2303 environment, where I set up a Kubernetes 1.25 cluster with Istio 1.20 using kind, I successfully achieved the routing functionality as described in the issue. However, there are still some lingering issues:

If I start kmesh first and then apply vs.yaml, the configuration doesn’t get refreshed, and the functionality doesn’t work correctly. It’s similar to the situation described in this issue. Only by restarting kmesh or applying vs.yaml after kmesh has been applied does it work properly.

Thanks for sharing the detailed update.
Since the steps you listed are for Kmesh version v0.2.0, I have created a separate issue 144 for it.

Can we use this current issue to just track progress for v0.1.0 ? Also can you share the observations when you try to reproduce the issue for v0.1.0 ?