Migrating workloads to Knative OSS

Use this guide to migrate your workloads to run on the open-source Knative offering with Google Kubernetes Engine. In general, migrating your workloads requires you to install the Knative Serving component in a new GKE cluster and then redeploy each of your services to that Knative cluster.

While the use, management, and support for open-source Knative is your choice and responsibility, migrating to Knative provides you with the opportunity to continue running you workloads on the Google Kubernetes Engine platform.

Notable differences:

• Support is limited to Google Kubernetes Engine. You can contact the Knative community for Knative support.
• Google Cloud CLI (gcloud) is supported by Google Kubernetes Engine only. Knative supports kubectl and kn commands. Learn how to install kn

Before you begin

• You must have access to a new GKE cluster.
  • You can create your new cluster in the same or a new Google Cloud project.
  • Your cluster must meet the Knative requirements.
  • Learn how to create a cluster:
    • Standard cluster
    • Private cluster
• You must manually port over any cluster configurations to your new Knative cluster, including but not limited to:
  • ConfigMaps
  • Secrets
  • NVIDIA GPUs
  • Multitenancy
  • Shared VPC
• You must create and configure new IAM and RBAC access controls:
  • Configure access control
  • Workload Identity

Installing Knative on Google Kubernetes Engine

Knative provides several installation options and networking layers that you can choose to use. The following Knative installation steps use the Knative Operator method and the Istio networking layer.

1. Install the Knative Operator:

   1. Deploy the Operator to your cluster:

      kubectl apply -f https://github.com/knative/operator/releases/download/knative-vVERSION/operator.yaml
      

      Replace VERSION with a version of the Knative Operator.

      Example:

      kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.3.1/operator.yaml
      

   2. Set the kubectl CLI to use the default namespace:

      kubectl config set-context --current --namespace=default
      

   3. Verify that the Operator was created successfully:

      kubectl get deployment knative-operator
      

      Result:

      NAME               READY   UP-TO-DATE   AVAILABLE   AGE
      knative-operator   1/1     1            1           6m43s
      

2. Install the Knative Serving component:

   1. Create a YAML file with the following, for example SERVING_FILENAME.yaml:

      apiVersion: v1
      kind: Namespace
      metadata:
        name: knative-serving
      ---
      apiVersion: operator.knative.dev/v1alpha1
      kind: KnativeServing
      metadata:
        name: knative-serving
        namespace: knative-serving
      

   2. Deploy your YAML file to your cluster:

      kubectl apply -f SERVING_FILENAME.yaml
      

      Replace SERVING_FILENAME with the YAML file that you created.

3. Install Istio with sidecar injection as the networking layer:

   You have the option to perform and configure an alternate Istio installation. See all Istio installation options on the Knative website. Note that this installation can take than 30 minutes or more.

   1. Download Istio from the release page.

   2. Install Istio by running the following command with the --set hub=gcr.io/istio-release flag to avoid Docker rate limiting:

      istioctl install --set hub=gcr.io/istio-release
      

   3. Run the following command to enable sidecar injection:

      kubectl label namespace default istio-injection=enabled
      

   4. Optional: By default, Istio is installed in the istio-system namespace. If you want to configure a different namespace, you can use the following steps:

      1. To configure a custom namespace for Istion, you append the spec.config.istio attributes to your SERVING_FILENAME.yaml configuration file. For example:

         apiVersion: operator.knative.dev/v1alpha1
         kind: KnativeServing
         metadata:
           name: knative-serving
           namespace: knative-serving
         spec:
           # ...
           config:
             istio:
               local-gateway.LOCAL_GATEWAY_NAMESPACE.knative-local-gateway: "knative-local-gateway.ISTIO_NAMESPACE.svc.cluster.local"
         

         Replace:

         • LOCAL_GATEWAY_NAMESPACE is the namespace where you installed Knative Serving. Default: knative-serving
         • ISTIO_NAMESPACE is the namespace where Istio is installed. Default: istio-system

      2. Deploy the updated SERVING_FILENAME.yaml service to your Knative cluster:

         kubectl apply -f SERVING_FILENAME.yaml
         

      3. Verify the Istio installation by confirming that istio-ingressgateway resides in your specified namespace:

         kubectl get svc istio-ingressgateway -n ISTIO_NAMESPACE
         

         Replace ISTIO_NAMESPACE with the namespace where you installed Istio. Default: istio-system

         Result:

         NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                                      AGE
         istio-ingressgateway   LoadBalancer   10.232.10.190   34.123.5.116   15021:30337/TCP,80:32549/TCP,443:31210/TCP   119m
         

Migrating a service

To migrate a service, you deploy your service's YAML configuration file to your Knative cluster.

Note: If you obtain and use the original YAML configuration file that you initially created for Knative serving, you can skip the export and modify steps. With the original YAML configuration file, you can simply deploy it directly to your Knative cluster to create your services.

1. Export your Knative serving service to a local YAML file by running the following command:

   gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml
   

   Replace:

   • SERVICE with the name of your Knative serving service.
   • NAMESPACE with the namespace where your service is running.
   • CLUSTER with the name of the cluster where your service is running.
   • FILENAME with a unique filename of your choice.

2. Modify the exported FILENAME.yaml file to remove unwanted Knative serving configurations by deleting any of the following attributes and their values:

   • metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
   • metadata.managedFields
   • spec.template.spec.containers.readinessProbes

   • spec.template.spec.enableServiceLinks

     For example, you might need to remove the following configuration from under the spec: > template: > spec: > containers: attributes:

     ...
      readinessProbe:
        successThreshold: 1
        tcpSocket: {}
     ...
     

3. Deploy the modified .yaml file to your Knative cluster:

   kubectl apply -f SERVICE.yaml
   

   Replace SERVICE with the name of your service's configuration file.

4. Access your deployed service using a test domain or cURL commands. You can use a wildcard DNS service to test external access to your service. See the configuring DNS section in the Knative docs for more options.

   To use Magic DNS (sslip.io), run the following command.

   Note that you can also directly use sslip.io.

   kubectl apply -f https://github.com/knative/serving/releases/download/knative-vVERSION/serving-default-domain.yaml
   

   Replace VERSION with your version of Knative Serving.

   Example:

   kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.3.0/serving-default-domain.yaml
   

Migrating traffic to your service

After you have tested your newly deployed services and are ready to migrate all of your production traffic, you can configure your custom domain and update your DNS records with your registrar. Follow the instructions at Configuring custom domains.