forked from cloudfoundry/docs-cloudfoundry-concepts
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcf-routing-architecture.html.md.erb
65 lines (39 loc) · 8.46 KB
/
cf-routing-architecture.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
---
title: Cloud Foundry Routing Architecture
owner: CF Routing
---
This topic explains routing flow and architecture in Cloud Foundry. Cloud Foundry's routing tables must be updated before it can route external client requests to an app.
## <a id='routing-tables'></a> How Cloud Foundry Maintains Updated Routing Tables
Because each app can have many instances, one app route can go to multiple containers. As Diego moves and scales app instances, the route emitter on each cell sends messages to NATS or the Routing API to register and de-register routes to the cell's app instances.
The route emitter periodically emits the routes it discovers from Diego BBS to NATS and the Routing API as registration and unregistration messages every twenty seconds. By default, the Gorouter uses TLS to verify app identity and confirm that its routes are up-to-date. With TLS disabled, the Gorouter prunes any routes that the route emitters have not re-registered within the past two minutes. For more information about how CF maintains route consistency when TLS is or is not enabled, see the [Preventing Misrouting](./http-routing.html#consistency) section of the _HTTP Routing_ topic.
The following process describes how a router obtains information about routes for an app running on Cloud Foundry:
1. The Cloud Controller component sends app route information to Diego BBS. For HTTP routing, route information includes the host and path of an external URL, as shown in the format of the [`router.register` message](https://github.com/cloudfoundry/gorouter#registering-routes-via-nats) in the Gorouter documentation on GitHub. For TCP routing, route information includes the route port on which the TCP connection was received; for more information, see the [Routing API documentation on GitHub](https://github.com/cloudfoundry/routing-api/blob/master/docs/api_docs.md#create-tcp-routes).
1. Diego BBS coordinates the back end IP address and port where each instance of the app runs. When queried by the route emitter, the BBS sends this information along with Cloud Controller's app route information to the route emitter on the Diego cell where instances of the app are located.
1. If a route is HTTP, the route emitter on the Diego cells sends app route, IP, and port information to NATS, which then sends it to the Gorouter. If a route is TCP, the route emitter sends that information to the Routing API, which then sends it to the TCP router.
1. The Gorouter and TCP router use the route, IP, and port information from the route emitter to map incoming app requests to back end app instance locations.
### <a id='component-fail'></a> Routing Table Recovery After Component Failure
Cloud Controller and Diego BBS have their own databases, while NATS and the Gorouter only store their data in memory. If NATS or the Gorouter are restarted, they lose all of their data and must wait for the route emitter to send data to them again. If Diego BBS is restarted, it can retrieve its data from Cloud Controller.
If Cloud Controller is restarted, you must retrieve its data from a backup.
## <a id='ext-client'></a> External Client Request Flow
When Cloud Foundry's routing tables are updated, Cloud Foundry can process requests from external clients to an app. The following process describes how an external client makes a request to an app running on Cloud Foundry:
1. The external client sends its request.
1. Your DNS service sends the request to the HTTP or TCP load balancer based on the prefix of the DNS name in the client request, such as `http` in `http.example.com`.
1. The load balancer sends the request to the load balancer's corresponding router.
1. The router sends the request to the app.
<img src="images/external-client-call-app.png" alt="Diagram of external client request flow, with arrows pointing to each component. The top rounded box is labeled 'External Client' and has two arrows pointing away from it: one labeled 'http.cf-apps.com' that points to a rounded box labeled 'HTTP Load Balancer'; and one labeled 'tcp.cf-apps.com' that points to a rounded box labeled 'TCP Load Balancer'. 'HTTP Load Balancer' has an arrow pointing to a rounded box labeled 'Gorouter', which has an arrow pointing to a rounded box labeled 'HTTP Application'. 'TCP Load Balancer' has an arrow pointing to a rounded box labeled 'TCP Router', which has an arrow pointing to a rounded box labeled 'TCP Application'. 'Gorouter', 'TCP Router', 'HTTP Application', and 'TCP Application' are located within another rounded box labeled 'Cloud Foundry'." width="500">
## <a id='routing-components'></a> Routing Architecture Components
The following summarizes the roles and responsibilities of various components depicted in the Cloud Foundry routing architecture diagrams above. These summaries are limited to the roles and responsibilities these components have pertaining to routing. For more complete descriptions of these components, see [Cloud Foundry Concepts](https://docs.cloudfoundry.org/concepts/), [Cloud Foundry Components](https://docs.cloudfoundry.org/concepts/architecture/), and [Diego Components and Architecture](https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html).
| Component Name | Summary |
|----------------|---------|
| BOSH manifest | Used to configure route registrar with route(s) for system components such as UAA and Loggregator. |
| Cloud Controller | Contains route metadata, including whether they are HTTP or TCP. |
| Diego BBS | Contains IP and port metadata as well as route metadata from Cloud Controller, which route emitter discovers. |
| Diego cell | Manages app instances and tasks and long-running processes related to them. A route emitter runs on each cell. |
| Gorouter | Routes HTTP traffic coming into Cloud Foundry to the appropriate component. Receives route updates through NATS. Routes that have not been updated in two minutes are pruned from the Gorouter's database. |
| NATS | Receives routing configuration from route emitter and provides same to Gorouter. |
| Route registrar | Sends routing metadata described in BOSH manifest for system components such as UAA and Loggregator to NATS. This is because the Diego cell does not have information about system components, only about user spaces. |
| Route emitter | Periodically emits route, IP, and port metadata to NATS or Routing API as registration and unregistration messages. Does not know about app instances on Diego cell, but knows what cell it belongs to and learns about what app instances are running on its cell by asking Diego BBS for information about app instances on the same cell. |
| Routing API | Receives routing configuration from route emitter and other internal clients, and provides routing configuration for TCP router. |
| Routing database | Saves some routing data from Routing API. If the Gorouter misses a message about an unmapped route from NATS, it will not get it again, so TCP router and Routing API can consult routing database for current state of routes. |
| TCP router | Routes TCP traffic coming into Cloud Foundry to the appropriate component. Receives route updates through the routing API. |