instruction: Create a Kubernetes configuration with IngressParameter, StorageBucket, IngressParameters, IngressClass, Ingress, ClusterIngressParameter resources
output: ```dockerfile
  from a number of Ingress controllers.Ideally, all Ingress controllers should fit the reference specification. In reality, the various Ingress
  controllers operate slightly differently.Note:Make sure you review your Ingress controller's documentation to understand the caveats of choosing it.The Ingress resourceA minimal Ingress resource example:service/networking/minimal-ingress.yaml
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
   name: minimal-ingress
   annotations:
   nginx.ingress.kubernetes.io/rewrite-target: /
  spec:
   ingressClassName: nginx-example
   rules:
   - http:
   paths:
   - path: /testpath
   pathType: Prefix
   backend:
   service:
   name: test
   port:
   number: 80
  An Ingress needs apiVersion, kind, metadata and spec fields.
  The name of an Ingress object must be a valid
  DNS subdomain name.
  For general information about working with config files, see
  deploying applications,
  configuring containers,
  managing resources.
  Ingress frequently uses annotations to configure some options depending on the Ingress controller, an example of which
  is the rewrite-target annotation.
  Different Ingress controllers support different annotations.
  Review the documentation for your choice of Ingress controller to learn which annotations are supported.The Ingress spec
  has all the information needed to configure a load balancer or proxy server. Most importantly, it
  contains a list of rules matched against all incoming requests. Ingress resource only supports rules
  for directing HTTP(S) traffic.If the ingressClassName is omitted, a default Ingress class
  should be defined.There are some ingress controllers, that work without the definition of a
  default IngressClass. For example, the Ingress-NGINX controller can be
  configured with a flag
  --watch-ingress-without-class. It is recommended though, to specify the
  default IngressClass as shown below.Ingress rulesEach HTTP rule contains the following information:An optional host. In this example, no host is specified, so the rule applies to all inbound
  HTTP traffic through the IP address specified. If a host is provided (for example,
  foo.bar.com), the rules apply to that host.A list of paths (for example, /testpath), each of which has an associated
  backend defined with a service.name and a service.port.name or
  service.port.number. Both the host and path must match the content of an
  incoming request before the load balancer directs traffic to the referenced
  Service.A backend is a combination of Service and port names as described in the
  Service doc or a custom resource backend
  by way of a CRD. HTTP (and HTTPS) requests to the
  Ingress that match the host and path of the rule are sent to the listed backend.A defaultBackend is often configured in an Ingress controller to service any requests that do not
  match a path in the spec.DefaultBackendAn Ingress with no rules sends all traffic to a single default backend and .spec.defaultBackend
  is the backend that should handle requests in that case.
  The defaultBackend is conventionally a configuration option of the
  Ingress controller and
  is not specified in your Ingress resources.
  If no .spec.rules are specified, .spec.defaultBackend must be specified.
  If defaultBackend is not set, the handling of requests that do not match any of the rules will be up to the
  ingress controller (consult the documentation for your ingress controller to find out how it handles this case).If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is
  routed to your default backend.Resource backendsA Resource backend is an ObjectRef to another Kubernetes resource within the
  same namespace as the Ingress object. A Resource is a mutually exclusive
  setting with Service, and will fail validation if both are specified. A common
  usage for a Resource backend is to ingress data to an object storage backend
  with static assets.service/networking/ingress-resource-backend.yaml
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
   name: ingress-resource-backend
  spec:
   defaultBackend:
   resource:
   apiGroup: k8s.example.com
   kind: StorageBucket
   name: static-assets
   rules:
   - http:
   paths:
   - path: /icons
   pathType: ImplementationSpecific
   backend:
   resource:
   apiGroup: k8s.example.com
   kind: StorageBucket
   name: icon-assets
  After creating the Ingress above, you can view it with the following command:kubectl describe ingress ingress-resource-backend
  Name: ingress-resource-backend
  Namespace: default
  Address:
  Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
  Rules:
   Host Path Backends
   ---- ---- --------
   *
   /icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
  Annotations: <none>
  Events: <none>
  Path typesEach path in an Ingress is required to have a corresponding path type. Paths
  that do not include an explicit pathType will fail validation. There are three
  supported path types:ImplementationSpecific: With this path type, matching is up to the
  IngressClass. Implementations can treat this as a separate pathType or treat
  it identically to Prefix or Exact path types.Exact: Matches the URL path exactly and with case sensitivity.Prefix: Matches based on a URL path prefix split by /. Matching is case
  sensitive and done on a path element by element basis. A path element refers
  to the list of labels in the path split by the / separator. A request is a
  match for path p if every p is an element-wise prefix of p of the
  request path.Note:If the last element of the path is a substring of the last
  element in request path, it is not a match (for example: /foo/bar
  matches /foo/bar/baz, but does not match /foo/barbaz).ExamplesKindPath(s)Request path(s)Matches?Prefix/(all paths)YesExact/foo/fooYesExact/foo/barNoExact/foo/foo/NoExact/foo//fooNoPrefix/foo/foo, /foo/YesPrefix/foo//foo, /foo/YesPrefix/aaa/bb/aaa/bbbNoPrefix/aaa/bbb/aaa/bbbYesPrefix/aaa/bbb//aaa/bbbYes, ignores trailing slashPrefix/aaa/bbb/aaa/bbb/Yes, matches trailing slashPrefix/aaa/bbb/aaa/bbb/cccYes, matches subpathPrefix/aaa/bbb/aaa/bbbxyzNo, does not match string prefixPrefix/, /aaa/aaa/cccYes, matches /aaa prefixPrefix/, /aaa, /aaa/bbb/aaa/bbbYes, matches /aaa/bbb prefixPrefix/, /aaa, /aaa/bbb/cccYes, matches / prefixPrefix/aaa/cccNo, uses default backendMixed/foo (Prefix), /foo (Exact)/fooYes, prefers ExactMultiple matchesIn some cases, multiple paths within an Ingress will match a request. In those
  cases precedence will be given first to the longest matching path. If two paths
  are still equally matched, precedence will be given to paths with an exact path
  type over prefix path type.Hostname wildcardsHosts can be precise matches (for example “foo.bar.com”) or a wildcard (for
  example “*.foo.com”). Precise matches require that the HTTP host header
  matches the host field. Wildcard matches require the HTTP host header is
  equal to the suffix of the wildcard rule.HostHost headerMatch?*.foo.combar.foo.comMatches based on shared suffix*.foo.combaz.bar.foo.comNo match, wildcard only covers a single DNS label*.foo.comfoo.comNo match, wildcard only covers a single DNS labelservice/networking/ingress-wildcard-host.yaml
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
   name: ingress-wildcard-host
  spec:
   rules:
   - host: "foo.bar.com"
   http:
   paths:
   - pathType: Prefix
   path: "/bar"
   backend:
   service:
   name: service1
   port:
   number: 80
   - host: "*.foo.com"
   http:
   paths:
   - pathType: Prefix
   path: "/foo"
   backend:
   service:
   name: service2
   port:
   number: 80
  Ingress classIngresses can be implemented by different controllers, often with different
  configuration. Each Ingress should specify a class, a reference to an
  IngressClass resource that contains additional configuration including the name
  of the controller that should implement the class.service/networking/external-lb.yaml
  apiVersion: networking.k8s.io/v1
  kind: IngressClass
  metadata:
   name: external-lb
  spec:
   controller: example.com/ingress-controller
   parameters:
   apiGroup: k8s.example.com
   kind: IngressParameters
   name: external-lb
  The .spec.parameters field of an IngressClass lets you reference another
  resource that provides configuration related to that IngressClass.The specific type of parameters to use depends on the ingress controller
  that you specify in the .spec.controller field of the IngressClass.IngressClass scopeDepending on your ingress controller, you may be able to use parameters
  that you set cluster-wide, or just for one namespace.ClusterNamespacedThe default scope for IngressClass parameters is cluster-wide.If you set the .spec.parameters field and don't set
  .spec.parameters.scope, or if you set .spec.parameters.scope to
  Cluster, then the IngressClass refers to a cluster-scoped resource.
  The kind (in combination the apiGroup) of the parameters
  refers to a cluster-scoped API (possibly a custom resource), and
  the name of the parameters identifies a specific cluster scoped
  resource for that API.For example:---
  apiVersion: networking.k8s.io/v1
  kind: IngressClass
  metadata:
   name: external-lb-1
  spec:
   controller: example.com/ingress-controller
   parameters:
   # The parameters for this IngressClass are specified in a
   # ClusterIngressParameter (API group k8s.example.net) named
   # "external-config-1". This definition tells Kubernetes to
   # look for a cluster-scoped parameter resource.
   scope: Cluster
   apiGroup: k8s.example.net
   kind: ClusterIngressParameter
   name: external-config-1
  FEATURE STATE:
  Kubernetes v1.23 [stable]If you set the .spec.parameters field and set
  .spec.parameters.scope to Namespace, then the IngressClass refers
  to a namespaced-scoped resource. You must also set the namespace
  field within .spec.parameters to the namespace that contains
  the parameters you want to use.The kind (in combination the apiGroup) of the parameters
  refers to a namespaced API (for example: ConfigMap), and
  the name of the parameters identifies a specific resource
  in the namespace you specified in namespace.Namespace-scoped parameters help the cluster operator delegate control over the
  configuration (for example: load balancer settings, API gateway definition)
  that is used for a workload. If you used a cluster-scoped parameter then either:the cluster operator team needs to approve a different team's changes every
  time there's a new configuration change being applied.the cluster operator must define specific access controls, such as
  RBAC roles and bindings, that let
  the application team make changes to the cluster-scoped parameters resource.The IngressClass API itself is always cluster-scoped.Here is an example of an IngressClass that refers to parameters that are
  namespaced:---
  apiVersion: networking.k8s.io/v1
  kind: IngressClass
  metadata:
   name: external-lb-2
  spec:
   controller: example.com/ingress-controller
   parameters:
   # The parameters for this IngressClass are specified in an
   # IngressParameter (API group k8s.example.com) named "external-config",
   # that's in the "external-configuration" namespace.
   scope: Namespace
   apiGroup: k8s.example.com
   kind: IngressParameter
   namespace: external-configuration
   name: external-config
  Deprecated annotationBefore the IngressClass resource and ingressClassName field were added in
  Kubernetes 1.18, Ingress classes were specified with a
  kubernetes.io/ingress.class annotation on the Ingress. This annotation was
  never formally defined, but was widely supported by Ingress controllers.The newer ingressClassName field on Ingresses is a replacement for that
  annotation, but is not a direct equivalent. While the annotation was generally
  used to reference the name of the Ingress controller that should implement the
  Ingress, the field is a reference to an IngressClass resource that contains
  additional Ingress configuration, including the name of the Ingress controller.Default IngressClassYou can mark a particular IngressClass as default for your cluster. Setting the
  ingressclass.kubernetes.io/is-default-class annotation to true on an
  IngressClass resource will ensure that new Ingresses without an
  ingressClassName field specified will be assigned this default IngressClass.Caution:If you have more than one IngressClass marked as the default for your cluster,
  the admission controller prevents creating new Ingress objects that don't have
  an ingressClassName specified. You can resolve this by ensuring that at most 1
  IngressClass is marked as default in your cluster.There are some ingress controllers, that work without the definition of a
  default IngressClass. For example, the Ingress-NGINX controller can be
  configured with a flag
  --watch-ingress-without-class. It is recommended though, to specify the
  default IngressClass:service/networking/default-ingressclass.yaml
  apiVersion: networking.k8s.io/v1
  kind: IngressClass
  metadata:
   labels:
   app.kubernetes.io/component: controller
   name: nginx-example
   annotations:
   ingressclass.kubernetes.io/is-default-class: "true"
  spec:
   controller: k8s.io/ingress-nginx
  Types of IngressIngress backed by a single ServiceThere are existing Kubernetes concepts that allow you to expose a single Service
  (see alternatives). You can also do this with an Ingress by specifying a
  default backend with no rules.service/networking/test-ingress.yaml
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
   name: test-ingress
  spec:
   defaultBackend:
   service:
   name: test
   port:
   number: 80
  If you create it using kubectl apply -f you should be able to view the state
  of the Ingress you added:kubectl get ingress test-ingress
  NAME CLASS HOSTS ADDRESS PORTS AGE
  test-ingress external-lb * 203.0.113.123 80 59s
  Where 203.0.113.123 is the IP allocated by the Ingress controller to satisfy
  this Ingress.Note:Ingress controllers and load balancers may take a minute or two to allocate an IP address.
  Until that time, you often see the address listed as <pending>.Simple fanoutA fanout configuration routes traffic
  ```