Skip to content

Commit c1af8d4

Browse files
author
Tim Bannister
committed
Present scope for IngressClass params using tabs
Use tabs for the two different options that an IngressClass can use to refer to another object, in order to specific parameters that relate to that IngressClass: - namespaced scope - cluster scope (the default / historical behavior)
1 parent 793c08e commit c1af8d4

File tree

1 file changed

+86
-13
lines changed
  • content/en/docs/concepts/services-networking

1 file changed

+86
-13
lines changed

content/en/docs/concepts/services-networking/ingress.md

Lines changed: 86 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -219,25 +219,98 @@ of the controller that should implement the class.
219219

220220
{{< codenew file="service/networking/external-lb.yaml" >}}
221221

222-
IngressClass resources contain an optional parameters field. This can be used to
223-
reference additional implementation-specific configuration for this class.
222+
The `.spec.parameters` field of an IngressClass lets you reference another
223+
resource that provides configuration related to that IngressClass.
224224

225-
#### Namespace-scoped parameters
225+
The specific type of parameters to use depends on the ingress controller
226+
that you specify in the `.spec.controller` field of the IngressClass.
226227

228+
### IngressClass scope
229+
230+
Depending on your ingress controller, you may be able to use parameters
231+
that you set cluster-wide, or just for one namespace.
232+
233+
{{< tabs name="tabs_ingressclass_parameter_scope" >}}
234+
{{% tab name="Cluster" %}}
235+
The default scope for IngressClass parameters is cluster-wide.
236+
237+
If you set the `.spec.parameters` field and don't set
238+
`.spec.parameters.scope`, or if you set `.spec.parameters.scope` to
239+
`Cluster`, then the IngressClass refers to a cluster-scoped resource.
240+
The `kind` (in combination the `apiGroup`) of the parameters
241+
refers to a cluster-scoped API (possibly a custom resource), and
242+
the `name` of the parameters identifies a specific cluster scoped
243+
resource for that API.
244+
245+
For example:
246+
```yaml
247+
---
248+
apiVersion: networking.k8s.io/v1
249+
kind: IngressClass
250+
metadata:
251+
name: external-lb-1
252+
spec:
253+
controller example.com/ingress-controller
254+
parameters:
255+
# The parameters for this IngressClass are specified in an
256+
# ClusterIngressParameter (API group k8s.example.net) named
257+
# "external-config-1". This definition tells Kubernetes to
258+
# look for a cluster-scoped parameter resource.
259+
scope: Cluster
260+
apiGroup: k8s.example.net
261+
kind: ClusterIngressParameter
262+
name: external-config
263+
```
264+
{{% /tab %}}
265+
{{% tab name="Namespaced" %}}
227266
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
228267
229-
`Parameters` field has a `scope` and `namespace` field that can be used to
230-
reference a namespace-specific resource for configuration of an Ingress class.
231-
`Scope` field defaults to `Cluster`, meaning, the default is cluster-scoped
232-
resource. Setting `Scope` to `Namespace` and setting the `Namespace` field
233-
will reference a parameters resource in a specific namespace:
268+
If you set the `.spec.parameters` field and set
269+
`.spec.parameters.scope` to `Namespace`, then the IngressClass refers
270+
to a namespaced-scoped resource. You must also set the `namespace`
271+
field within `.spec.parameters` to the namespace that contains
272+
the parameters you want to use.
234273

235-
Namespace-scoped parameters avoid the need for a cluster-scoped CustomResourceDefinition
236-
for a parameters resource. This further avoids RBAC-related resources
237-
that would otherwise be required to grant permissions to cluster-scoped
238-
resources.
274+
The `kind` (in combination the `apiGroup`) of the parameters
275+
refers to a namespaced API (for example: ConfigMap), and
276+
the `name` of the parameters identifies a specific resource
277+
in the namespace you specified in `namespace`.
278+
279+
Namespace-scoped parameters help the cluster operator delegate control over the
280+
configuration (for example: load balancer settings, API gateway definition)
281+
that is used for a workload. If you used a cluster-scoped parameter then either:
282+
283+
- the cluster operator team needs to approve a different team's changes every
284+
time there's a new configuration change being applied.
285+
- the cluster operator must define specific access controls, such as
286+
[RBAC](/docs/reference/access-authn-authz/rbac/) roles and bindings, that let
287+
the application team make changes to the cluster-scoped parameters resource.
288+
289+
The IngressClass API itself is always cluster-scoped.
290+
291+
Here is an example of an IngressClass that refers to parameters that are
292+
namespaced:
293+
```yaml
294+
---
295+
apiVersion: networking.k8s.io/v1
296+
kind: IngressClass
297+
metadata:
298+
name: external-lb-2
299+
spec:
300+
controller example.com/ingress-controller
301+
parameters:
302+
# The parameters for this IngressClass are specified in an
303+
# IngressParameter (API group k8s.example.com) named "external-config",
304+
# that's in the "external-configuration" configuration namespace.
305+
scope: Namespace
306+
apiGroup: k8s.example.com
307+
kind: IngressParameter
308+
namespace: external-configuration
309+
name: external-config
310+
```
239311

240-
{{< codenew file="service/networking/namespaced-params.yaml" >}}
312+
{{% /tab %}}
313+
{{< /tabs >}}
241314

242315
### Deprecated annotation
243316

0 commit comments

Comments
 (0)