4 Routes

 

This chapter covers

  • Using kn to inspect Routes
  • Using kn to update Routes by updating Services
  • The anatomy of Routes

It seems like only pages ago that I was extolling the virtues of history and of Knative’s ability to juggle it a bit with Revisions. And I wasn’t wrong. But by itself, this is just an exercise in decorative bookkeeping. I need my Revisions to do something.

In Knative Serving, this brings us to Routes. These are the way you can describe to Knative how to map from an incoming HTTP request to a specific Revision. In this chapter, my focus is going to be on the business of what you can ask Knative to do. I’ll pay much less attention to how Knative does the network magic.

So what is a Route? Briefly, a Route is where you answer three questions:

  • At what public address or URL will traffic arrive from?
  • What targets can I send traffic to ?
  • What percentage of traffic goes to which targets?

The first two points (from and to) are pretty typical of generations of proxies, routers, traffic doodads, and thingamajiggers. The third, traffic splitting or weighting, isn’t universal, but it’s common. Everything you can do with a Route can be done some other way. You might, for example, already have some elaborate tooling built around using a Kubernetes Ingress controller. Or, you might just run Nginx by hand with a bit of spit and elbow polish.

4.1 Using kn to work with Routes

4.2 The anatomy of Routes

4.3 The anatomy of TrafficTargets

4.3.1 configurationName and revisionName

4.3.2 latestRevision

4.3.3 tag

Summary