When troubleshooting KFserving https://medium.com/@billtcheng2013/hello-world-to-kfserving-1058c303b25b, there are lots of new concepts (Route, Revision, Configuration, Istio RBAC, policy, etc.), since KFserving is built on Knative and Istio. The natural next step is to get familiar with these concepts.
Note: Knative is still new, there are different apiVersions: v1, v1alpha1, v1beta1. Not every version is compatible. It is best to rely on official doc for sample.
Knative eventing requires K8S 1.15
Create GKE
export PROJECT=<project>
export clustername=<cluster name>
export ZONE=us-central1-a
gcloud beta container — project $PROJECT clusters create $clustername — zone $ZONE — no-enable-basic-auth — cluster-version “1.15.9-gke.8” — machine-type “n1-standard-8” — image-type “COS” — disk-type “pd-standard” — disk-size “100” — scopes “https://www.googleapis.com/auth/cloud-platform" — num-nodes “2” — enable-stackdriver-kubernetes — enable-ip-alias — default-max-pods-per-node “110” — addons HorizontalPodAutoscaling,HttpLoadBalancing,CloudRun,Istio — istio-config auth=MTLS_PERMISSIVE — enable-autoupgrade — enable-autorepair
Install Knative
https://knative.dev/docs/install/knative-with-gke/
Deploy helloworld-go app
https://knative.dev/docs/serving/getting-started-knative-app/
By default, Knative uses Istio ingress gateway
export INGRESSGATEWAY=istio-ingressgateway
if kubectl get configmap config-istio -n knative-serving &> /dev/null; then
export INGRESSGATEWAY=istio-ingressgateway
fi
export GATEWAY_IP=`kubectl get svc $INGRESSGATEWAY — namespace istio-system — output jsonpath=”{.status.loadBalancer.ingress[*][‘ip’]}”`
curl -H “Host: helloworld-go.default.example.com” http://$GATEWAY_IP
https://knative.dev/docs/serving/using-a-custom-domain/
you can set default domain other than the default example.com
Result: Hello Go Sample v1!
https://medium.com/google-cloud/hands-on-knative-part-1-f2d5ce89944e
serving.knative.dev/v1alpha1, runLatest is deprecated
Let’s see what resources are created.
kubectl get ksvc,configuration,revision,route
The most important resource is Revision.
Revision
NAME CONFIG NAME K8S SERVICE NAME GENERATION READY REASON
revision.serving.knative.dev/helloworld-go-dwrv7 helloworld-go helloworld-go-dwrv7 1 True
Route (you can see by default all traffic is directed to this only Revision)
kubectl get route helloworld-go -o yaml
traffic:
— latestRevision: true
percent: 100
revisionName: helloworld-go-dwrv7
Now update application, update service.yaml (change TARGET to “Go Sample v2”), and redeploy
kubectl apply -f service.yaml
Added a new Revision
NAME CONFIG NAME K8S SERVICE NAME GENERATION READY REASON
revision.serving.knative.dev/helloworld-go-24vv6 helloworld-go helloworld-go-24vv6 2 True
revision.serving.knative.dev/helloworld-go-dwrv7 helloworld-go helloworld-go-dwrv7 1 True
Route changes to latest Revision
traffic:
— latestRevision: true
percent: 100
revisionName: helloworld-go-24vv6
curl -H “Host: helloworld-go.default.example.com” http://$GATEWAY_IP
Result: Hello Go Sample v2!
Split traffic (we can direct 50% traffic to each Revision)
kind: Service
metadata:
name: helloworld-go # The name of the app
namespace: default # The namespace the app will use
spec:
template:
spec:
containers:
— image: gcr.io/knative-samples/helloworld-go # The URL to the image of the app
env:
— name: TARGET # The environment variable printed out by the sample app
value: “Go Sample v2”
traffic:
— tag: current
revisionName: helloworld-go-24vv6
percent: 50
— tag: candidate
revisionName: helloworld-go-dwrv7
percent: 50
— tag: latest
latestRevision: true
percent: 0
curl -H “Host: helloworld-go.default.example.com” http://$GATEWAY_IP
Result: 50% Hello Go Sample v2!, 50% Hello Go Sample v1!
The Knative official overview document is pretty clear. So just my additional understanding.
https://github.com/knative/serving/blob/master/docs/spec/overview.md
Revision: immutable snapshot of code and configuration. Any update of service.template.spec creates a new Revision
Configuration: Track the desired state of the same application (all Revisions of the same application will roll up to the same Configuration)
Route: provide network endpoint for user service, can point to one or multiple Revisions (e.g. supporting canary rollout, A/B testing)
Service: abstraction of a single software component
Next it will be Istio, which is very powerful but more complex.
