A Knative Service defines a containerized application service through Knative Serving. It sits above Kubernetes Services, Deployments, and ReplicaSets, reducing the resources a team must manage directly. Unlike a Kubernetes Service alone, it also tracks application revisions and provides traffic rules and autoscaling. section 8.2.1 section 8.2
For the Conference application's Notifications service, the definition names the service and supplies a container image and Kafka connection setting. Knative Serving must be installed in the cluster before creating it. section 8.2.1
Listing 8.1 Knative Service definition
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: notifications-service #1
spec:
template:
spec:
containers:
- image: salaboy/notifications-service:v1.0.0 #2
Env: #3
- name: KAFKA_URL
value: <URL>
Inspect the resource's API version, kind, name, and container template. The definition replaces separate application-facing Deployment and Service definitions with one Knative Service. section 8.2.1
After deployment, the service has a URL and a latest created revision. A request to the Notifications service's `/service/info` endpoint returns details including its running version. Inspect the resource with `kubectl get ksvc notifications-service -oyaml`; when no traffic rules were specified, `spec.traffic` sends 100% of requests to the latest revision. section 8.2.1 section 8.2.2
Change `spec.traffic` to control a release without manually creating resources for each version:
- For a canary release, assign percentages to an existing revision and the latest revision—for example, 50% each. Repeated requests can then reach either version. Increase the new version's share after validation, or return traffic to the stable revision if needed. section 8.2.2
- For A/B testing, give a revision a tag and route testers to its tagged URL. Header-based routing is another option when the corresponding Knative feature is enabled. section 8.2.2
- For a blue/green deployment, keep 100% of ordinary traffic on the first revision while the tagged second revision receives 0%; switch the percentages when ready. section 8.2.2
Listing 8.9 Using tags to define blue and green revisions
...
traffic:
- revisionName: <blue-revision-name>
percent: 100 # All traffic is still being routed to the first revision
- revisionName: <green-revision-name>
percent: 0 # 0% of traffic routed to the second revision
tag: green # A named route
The traffic rules show a blue/green starting state: the first revision serves ordinary requests, while the second has a named route for testing. section 8.2.2
Knative creates the supporting Kubernetes resources and scales the revisions needed to serve requests; its autoscaler can also scale a service down to zero replicas. That makes revision traffic a practical release control rather than a sequence of coordinated edits to several Kubernetes resources. section 8.2 section 8.2.2
