Run 2 Knative serving versions in parallel

[hctung57]

Ask your question here:

Hello everyone, Currently my system is using knative v1.10, I want to update the system to v1.11 but still want to keep v1.10. Is there a way to run both knative versions in parallel (in two different knative-serving namespaces) and both versions control the same knative service at the default namespace? Thanks !

[Priyansurout]

yes there is ways to run both Knative versions in parallel in:

1---> Install Knative v1.11 in a separate Knative Serving namespace. 2----> Create a Knative service in the default namespace and config to split taffic to the both Knative Serving namespaces.

then just Update it

[hctung57]

yes there is ways to run both Knative versions in parallel in:

1---> Install Knative v1.11 in a separate Knative Serving namespace. 2----> Create a Knative service in the default namespace and config to split taffic to the both Knative Serving namespaces.

then just Update it

Hi Priyansurout, thank for your answer. Can you show me how to setup by editing the yaml file? I am testing installing two Knative serving clusters on two different namespaces. Specifically, I edited the namespace fields in the yaml file to place two knative clusters in two different namespaces (for example, one cluster in namespace knative-serving-1 and one cluster in knative-serving-2). But I'm having a problem that seems like some configs in the yaml file (serving-crds.yaml, serving-core.yaml and kourier.yaml) are being overwritten and a knative cluster is not working.

[Priyansurout]

okk let do it!!!! first create two new namespaces for Knative Serving :

kubectl create namespace knative-serving-1
kubectl create namespace knative-serving-2

Create two new YAML files for each Knative Serving

# knative-serving-1.yaml

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving-1
spec:
  version: v1.11

for knative-serving-2

# knative-serving-2.yaml

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving-2
spec:
  version: v1.11

Apply the YAML files to the kubernetes cluster

kubectl apply -f knative-serving-1.yaml
kubectl apply -f knative-serving-2.yaml

and lastly verify that both knative serving by:

kubectl get pods --namespace knative-serving-1
kubectl get pods --namespace knative-serving-2

then Create a Knative service in the default namespace and config to split taffic to the both Knative Serving namespaces.

create a new YAML file: This YAML file will create a new Knative service called my-service in the default namespace. The service will split traffic 50/50 between the two Knative Serving namespaces.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  traffic:
  - latestRevision: true
    percent: 50
    revisionName: knative-serving-1/my-service
  - latestRevision: true
    percent: 50
    revisionName: knative-serving-2/my-service

then apply the YAML file to the Kubernetes cluster: kubectl apply -f my-service.yaml

To deploy a revision to the first Knative Serving namespace: kn service deploy my-service --image gcr.io/knative-samples/helloworld-go --namespace knative-serving-1 and same for knative-serving-2

[husnialhamdani]

Check this one https://knative.dev/docs/serving/revisions/revision-admin-config-options/, to control or retain revision in a Knative.

[hctung57]

okk let do it!!!! first create two new namespaces for Knative Serving :

kubectl create namespace knative-serving-1
kubectl create namespace knative-serving-2

Create two new YAML files for each Knative Serving

# knative-serving-1.yaml

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving-1
spec:
  version: v1.11

for knative-serving-2

# knative-serving-2.yaml

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving-2
spec:
  version: v1.11

Apply the YAML files to the kubernetes cluster

kubectl apply -f knative-serving-1.yaml
kubectl apply -f knative-serving-2.yaml

and lastly verify that both knative serving by:

kubectl get pods --namespace knative-serving-1
kubectl get pods --namespace knative-serving-2

then Create a Knative service in the default namespace and config to split taffic to the both Knative Serving namespaces.

create a new YAML file: This YAML file will create a new Knative service called my-service in the default namespace. The service will split traffic 50/50 between the two Knative Serving namespaces.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  traffic:
  - latestRevision: true
    percent: 50
    revisionName: knative-serving-1/my-service
  - latestRevision: true
    percent: 50
    revisionName: knative-serving-2/my-service

then apply the YAML file to the Kubernetes cluster: kubectl apply -f my-service.yaml

To deploy a revision to the first Knative Serving namespace: kn service deploy my-service --image gcr.io/knative-samples/helloworld-go --namespace knative-serving-1 and same for knative-serving-2

Hi I have deployed two knative clusters with the below method. First I apply the first yaml file with the following content.

apiVersion: v1
kind: Namespace
metadata:
  name: knative-serving-1
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving-1
spec:
  # ...
  ingress:
    kourier:
      enabled: true
  config:
    network:
      ingress-class: "kourier.ingress.networking.knative.dev"

Then, i have setup DNS for my cluster (No DNS method ) follow this tutorial: https://knative.dev/docs/install/operator/knative-with-operators/#configure-dns

kubectl patch configmap/config-domain \
      --namespace knative-serving-1 \
      --type merge \
      --patch '{"data":{"example.com":""}}'

I do the same with the second cluster.

apiVersion: v1
kind: Namespace
metadata:
  name: knative-serving-2
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving-2
spec:
  # ...
  ingress:
    kourier:
      enabled: true
  config:
    network:
      ingress-class: "kourier.ingress.networking.knative.dev"

kubectl patch configmap/config-domain \
      --namespace knative-serving-2 \
      --type merge \
      --patch '{"data":{"example.com":""}}'

As a result, I get 2 services like this:

#knative-serving-1
NAME      TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
kourier   LoadBalancer   10.233.58.181   192.168.133.2   80:32454/TCP,443:31321/TCP   67s

#knative-serving-2
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
kourier   LoadBalancer   10.233.27.86   192.168.133.3   80:30138/TCP,443:30450/TCP   116s

I curled into those two services through the following command (192.168.101.58 is the IP address of a device in the cluster): curl -H "Host: hello.default.example.com" http://192.168.122.58:30138 curl -H "Host: hello.default.example.com" http://192.168.122.58:32454

The results show that both work but when I use wireshark to check the route of the packets it seems that all requests coming from both gateways on two knative clusters (1 and 2) go to the activator pod in knative-serving-2 cluster. I think there is a certain config causing this problem, is there any way I can reconfigure the route of requests to only go to pods at knative cluster at the same namespace (for example requests from gateway at knative cluster- serving-1 will go to the activator in that namespace)

Thank you a lot!

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[ReToCode]

It is not possible to do what you did:

• KnativeServing can not be installed in more than one namespace
• A KnativeService cannot target revisions which are in different namespaces