diff --git a/site-src/concepts/api-overview.md b/site-src/concepts/api-overview.md index a46c1766ca..747f6430f3 100644 --- a/site-src/concepts/api-overview.md +++ b/site-src/concepts/api-overview.md @@ -7,7 +7,7 @@ This document provides an overview of Gateway API. There are 3 primary roles in Gateway API, as described in [roles and personas]: - **Ian** (he/him): Infrastructure Provider -- **Charlie** (they/them): Cluster Operator +- **Chihiro** (they/them): Cluster Operator - **Ana** (she/her): Application Developer [roles and personas]:/concepts/roles-and-personas @@ -176,7 +176,7 @@ different relationships that Gateways and Routes can have: ### Example -[Charlie] has deployed a Gateway `shared-gw` in the `infra` Namespace to be +[Chihiro] has deployed a Gateway `shared-gw` in the `infra` Namespace to be used by different application teams for exposing their applications outside the cluster. Teams A and B (in Namespaces `A` and `B` respectively) attach their Routes to this Gateway. They are unaware of each other and as long as @@ -190,7 +190,7 @@ Namespace. ![route binding](/images/gateway-route-binding.png) -[Charlie]:/concepts/roles-and-personas#charlie +[Chihiro]:/concepts/roles-and-personas#Chihiro ### How it Works diff --git a/site-src/concepts/roles-and-personas.md b/site-src/concepts/roles-and-personas.md index 68bbda9120..73da3744a9 100644 --- a/site-src/concepts/roles-and-personas.md +++ b/site-src/concepts/roles-and-personas.md @@ -37,9 +37,9 @@ The Gateway API defines three roles and personas: will often work for a cloud provider (AWS, Azure, GCP, ...) or for a PaaS provider. -* **Charlie** (they/them) is a _cluster operator_, +* **Chihiro** (they/them) is a _cluster operator_, responsible for managing clusters to ensure that they meet the needs of - their several users. Charlie will typically be concerned with policies, + their several users. Chihiro will typically be concerned with policies, network access, application permissions, etc. Again, they are beholden to no single user of any cluster; rather, they need to make sure that the clusters serve all users as needed. @@ -60,7 +60,7 @@ Depending on the environment, multiple roles can map to the same user: and may actually happen in a small startup running Kubernetes on bare metal. - A more typical small startup would use clusters from a cloud provider. In - this situation, Ana and Charlie may be embodied in the same person, with Ian + this situation, Ana and Chihiro may be embodied in the same person, with Ian being an employee (or automated process!) within the cloud provider. - In a much larger organization, we would expect each persona above to be diff --git a/site-src/concepts/security-model.md b/site-src/concepts/security-model.md index 2220b31e82..3774fc9867 100644 --- a/site-src/concepts/security-model.md +++ b/site-src/concepts/security-model.md @@ -18,7 +18,7 @@ Gateway API has 3 primary API resources: There are 3 primary roles in Gateway API, as described in [roles and personas]: - **Ian** (he/him): Infrastructure Provider -- **Charlie** (they/them): Cluster Operator +- **Chihiro** (they/them): Cluster Operator - **Ana** (she/her): Application Developer [roles and personas]:/concepts/roles-and-personas diff --git a/site-src/concepts/use-cases.md b/site-src/concepts/use-cases.md index f59492a470..7b5edae7e4 100644 --- a/site-src/concepts/use-cases.md +++ b/site-src/concepts/use-cases.md @@ -7,14 +7,15 @@ examples that can be helpful to demonstrate how the API can be used. In all cases, it's very important to bear in mind the [roles and personas] used in the Gateway API. The use cases presented here are deliberately -described in terms of [Ana], [Charlie], and [Ian]: they are the ones for whom the -API must be usable. (It's also important to remember that even though these -roles might be filled by the same person, especially in smaller organizations, -they all have distinct concerns that we need to consider separately.) +described in terms of [Ana], [Chihiro], and [Ian]: they are the ones for whom +the API must be usable. (It's also important to remember that even though +these roles might be filled by the same person, especially in smaller +organizations, they all have distinct concerns that we need to consider +separately.) [roles and personas]:/concepts/roles-and-personas [Ana]:/concepts/roles-and-personas#ana -[Charlie]:/concepts/roles-and-personas#charlie +[Chihiro]:/concepts/roles-and-personas#chihiro [Ian]:/concepts/roles-and-personas#ian ## The Use Cases @@ -39,21 +40,21 @@ Kubernetes. Her application will be used by clients outside the cluster, and while Ana has created the application, setting up the cluster is not in her wheelhouse. -1. Ana goes to Charlie to ask them to set up a cluster. Ana tells Charlie that +1. Ana goes to Chihiro to ask them to set up a cluster. Ana tells Chihiro that her clients will expect her APIs to be available using URLs rooted at `https://ana.application.com/`. -2. Charlie goes to Ian and requests a cluster. +2. Chihiro goes to Ian and requests a cluster. 3. Ian provisions a cluster running a gateway controller with a [GatewayClass] resource named `basic-gateway-class`. The gateway controller manages the infrastructure associated with routing traffic from outside the cluster to inside the cluster. -4. Ian gives Charlie credentials to the new cluster, and tells Charlie that +4. Ian gives Chihiro credentials to the new cluster, and tells Chihiro that they can use GatewayClass `basic-gateway-class` to set things up. -5. Charlie applies a [Gateway] named `ana-gateway` to the cluster, telling it +5. Chihiro applies a [Gateway] named `ana-gateway` to the cluster, telling it to listen on port 443 for TLS traffic, and providing it a TLS certificate with a Subject CN of `ana.application.com`. They associate this Gateway with the `basic-gateway-class` GatewayClass. @@ -63,10 +64,10 @@ wheelhouse. 443, and starts watching for routing resources associated with `ana-gateway`. -7. Charlie gets the IP address of `ana-gateway` and creates a DNS record +7. Chihiro gets the IP address of `ana-gateway` and creates a DNS record outside the cluster for `ana.application.com` to match. -8. Charlie tells Ana that she's good to go, using the Gateway named +8. Chihiro tells Ana that she's good to go, using the Gateway named `ana-gateway`. 9. Ana writes and applies [HTTPRoute] resources to configure which URL paths @@ -77,7 +78,7 @@ wheelhouse. 10. At this point, when requests arrive at the load balancer, they are routed to Ana's application according to her routing specification. -This allows Charlie to enforce centralized policies [such as +This allows Chihiro to enforce centralized policies [such as TLS](/guides/tls#downstream-tls) at the Gateway, while simultaneously allowing Ana and her colleagues control over the application's [routing logic](/guides/http-routing) and rollout plans (e.g. [traffic splitting @@ -98,20 +99,20 @@ Ana and her team are managing a storefront application in the `store` Namespace, while Allison and her team are managing a website in the `site` Namespace. -- Ian and Charlie work together to provide a cluster, `GatewayClass`, and +- Ian and Chihiro work together to provide a cluster, `GatewayClass`, and `Gateway`, as above. - Ana and Allison independently deploy workloads and HTTPRoutes bound to the same `Gateway` resource. -Again, this separation of concerns allows Charlie to enforce centralized +Again, this separation of concerns allows Chihiro to enforce centralized policies [such as TLS](/guides/tls#downstream-tls) can be enforced at the Gateway. Meanwhile, Ana and Allison run their applications [in their own Namespaces](/guides/multiple-ns), but attach their Routes to the same shared Gateway, allowing them to independently control their [routing logic](/guides/http-routing), [traffic splitting rollout](/guides/traffic-splitting), etc., while not worrying about the things -that Charlie and Ian are handling. +that Chihiro and Ian are handling. [HTTPRoute]:/api-types/httproute [GatewayClass]:/api-types/gatewayclass @@ -134,7 +135,7 @@ protect her workload by rejecting calls to her workload with incorrect URL paths, and by enforcing timeouts whenever anyone makes a request of her workload. -- Charlie and Ian have already provided a cluster with a running service mesh. +- Chihiro and Ian have already provided a cluster with a running service mesh. Ana doesn't need to make any requests of them. - Ana writes an HTTPRoute that defines acceptable routes and timeouts and has @@ -147,7 +148,7 @@ workload. In this case, the separation of concerns across roles allows Ana to take advantage of the service mesh, with custom routing logic, without any -bottlenecks in requests to Charlie or Ian. +bottlenecks in requests to Chihiro or Ian. [east/west]:/concepts/glossary#eastwest-traffic [GAMMA]:/concepts/gamma/ @@ -165,7 +166,7 @@ This is effectively a combination of the [multiple applications behind a single Gateway](#multiple-applications-behind-a-single-gateway) and [basic east/west](#basic-eastwest-use-case) use cases: -- Charlie and Ian will provision a cluster, a [GatewayClass], and a [Gateway]. +- Chihiro and Ian will provision a cluster, a [GatewayClass], and a [Gateway]. - Ana and Allison will deploy their applications in the appropriate Namespaces. @@ -175,7 +176,7 @@ east/west](#basic-eastwest-use-case) use cases: There are two very important changes in this scenario, though, since a mesh is involved: -1. If Charlie has deployed a [gateway controller] that defaults to [Service +1. If Chihiro has deployed a [gateway controller] that defaults to [Service routing], they will probably need to reconfigure it for [endpoint routing]. (This is an ongoing area of work for [GAMMA], but the expectation is that endpoint routing will be recommended.) @@ -186,7 +187,7 @@ involved: HTTPRoutes that bind to both the Gateway and a Service. As always, the ultimate point of separating concerns in this way is that it -permits Charlie to enforce centralized policies [such as +permits Chihiro to enforce centralized policies [such as TLS](/guides/tls#downstream-tls) at the Gateway, while allowing Ana and Allison to retain independent control of [routing logic](/guides/http-routing), [traffic splitting diff --git a/site-src/index.md b/site-src/index.md index 10cbdc3cba..d763face69 100644 --- a/site-src/index.md +++ b/site-src/index.md @@ -152,9 +152,9 @@ The roles used for the Gateway API's design are defined by three personas: to serve multiple tenants. He is not beholden to any single tenant; rather, he worries about all of them collectively. -- **Charlie** (they/them) is a _cluster operator_. Their role is to manage a +- **Chihiro** (they/them) is a _cluster operator_. Their role is to manage a single cluster, ensuring that it meets the needs of its several users. - Again, Charlie is beholden to no single user of their cluster; they need to + Again, Chihiro is beholden to no single user of their cluster; they need to make sure that the cluster serves all of them as needed. - **Ana** (she/her) is an _application developer_. Ana is in a unique position @@ -166,7 +166,7 @@ The roles used for the Gateway API's design are defined by three personas: (These three are discussed in more detail in [Roles and Personas](/concepts/roles-and-personas).) -It should be clear that while Ana, Charlie, and Ian do not necessarily see +It should be clear that while Ana, Chihiro, and Ian do not necessarily see eye-to-eye about everything, they need to work together to keep things running smoothly. This is the core challenge of the Gateway API in a nutshell. @@ -178,7 +178,7 @@ and implementations while remaining a portable and standard API. The use cases presented are deliberately cast in terms of the roles presented above. Ultimately the Gateway API is meant for use by humans, which means that -it must fit the uses to which each of Ana, Charlie, and Ian will put it. +it must fit the uses to which each of Ana, Chihiro, and Ian will put it. [use-cases]:/concepts/use-cases