Networking Operators
Managing networking-specific Operators in OpenShift Dedicated
Abstract
Chapter 1. DNS Operator in OpenShift Dedicated Copy linkLink copied to clipboard!
In OpenShift Dedicated, the DNS Operator deploys and manages a CoreDNS instance to provide a name resolution service to pods inside the cluster, enables DNS-based Kubernetes Service discovery, and resolves internal cluster.local names.
This Operator is installed on OpenShift Dedicated clusters by default.
1.1. Using DNS forwarding Copy linkLink copied to clipboard!
Configure DNS forwarding servers and upstream resolvers for the cluster.
You can use DNS forwarding to override the default forwarding configuration in the /etc/resolv.conf file in the following ways:
Specify name servers (
spec.servers) for every zone. If the forwarded zone is the ingress domain managed by OpenShift Dedicated, then the upstream name server must be authorized for the domain.ImportantYou must specify at least one zone. Otherwise, your cluster can lose functionality.
-
Provide a list of upstream DNS servers (
spec.upstreamResolvers). - Change the default forwarding policy.
A DNS forwarding configuration for the default domain can have both the default servers specified in the /etc/resolv.conf file and the upstream DNS servers.
During pod creation, Kubernetes uses the /etc/resolv.conf file that exists on a node. If you modify the /etc/resolv.conf file on a host node, the changes do not propagate to the /etc/resolv.conf file that exists in a container. You must re-create the container for changes to take effect.
Procedure
Modify the DNS Operator object named
default:$ oc edit dns.operator/defaultAfter you issue the previous command, the Operator creates and updates the config map named
dns-defaultwith additional server configuration blocks based onspec.servers.ImportantWhen specifying values for the
zonesparameter, ensure that you only forward to specific zones, such as your intranet. You must specify at least one zone. Otherwise, your cluster can lose functionality.If none of the servers have a zone that matches the query, then name resolution falls back to the upstream DNS servers.
Configuring DNS forwarding
apiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: cache: negativeTTL: 0s positiveTTL: 0s logLevel: Normal nodePlacement: {} operatorLogLevel: Normal servers: - name: example-server zones: - example.com forwardPlugin: policy: Random upstreams: - 1.1.1.1 - 2.2.2.2:5353 upstreamResolvers: policy: Random protocolStrategy: "" transportConfig: {} upstreams: - type: SystemResolvConf - type: Network address: 1.2.3.4 port: 53 status: clusterDomain: cluster.local clusterIP: x.y.z.10 conditions: ...where:
spec.servers.name-
Must comply with the
rfc6335service name syntax. spec.servers.zones-
Must conform to the
rfc1123subdomain syntax. The cluster domaincluster.localis invalid forzones. spec.servers.forwardPlugin.policy-
Specifies the upstream selection policy. Defaults to
Random; allowed values areRoundRobinandSequential. spec.servers.forwardPlugin.upstreams-
Must provide no more than 15
upstreamsentries perforwardPlugin. spec.upstreamResolvers.upstreams-
Specifies an
upstreamResolversto override the default forwarding policy and forward DNS resolution to the specified DNS resolvers (upstream resolvers) for the default domain. You can use this field when you need custom upstream resolvers; otherwise queries use the servers declared in/etc/resolv.conf. spec.upstreamResolvers.policy-
Specifies the upstream selection order. Defaults to
Sequential; allowed values areRandom,RoundRobin, andSequential. spec.upstreamResolvers.protocolStrategy-
Specify
TCPto force the protocol to use for upstream DNS requests, even if the request uses UDP. Valid values areTCPand omitted. When omitted, the platform chooses a default, normally the protocol of the original client request. spec.upstreamResolvers.transportConfig- Specifies the transport type, server name, and optional custom CA or CA bundle to use when forwarding DNS requests to an upstream resolver.
spec.upstreamResolvers.upstreams.type-
Specifies two types of
upstreams:SystemResolvConforNetwork.SystemResolvConfconfigures the upstream to use/etc/resolv.confandNetworkdefines aNetworkresolver. You can specify one or both. spec.upstreamResolvers.upstreams.address-
Specifies a valid IPv4 or IPv6 address when type is
Network. spec.upstreamResolvers.upstreams.port-
Specifies an optional field to provide a port number. Valid values are between
1and65535; defaults to 853 when omitted.
Chapter 2. Ingress Operator in OpenShift Dedicated Copy linkLink copied to clipboard!
The Ingress Operator implements the IngressController API and is the component responsible for enabling external access to OpenShift Dedicated cluster services.
This Operator is installed on OpenShift Dedicated clusters by default.
2.1. OpenShift Dedicated Ingress Operator Copy linkLink copied to clipboard!
When you create your OpenShift Dedicated cluster, pods and services running on the cluster are each allocated their own IP addresses. The IP addresses are accessible to other pods and services running nearby but are not accessible to outside clients.
The Ingress Operator makes it possible for external clients to access your service by deploying and managing one or more HAProxy-based Ingress Controllers to handle routing.
Red Hat Site Reliability Engineers (SRE) manage the Ingress Operator for OpenShift Dedicated clusters. While you cannot alter the settings for the Ingress Operator, you may view the default Ingress Controller configurations, status, and logs as well as the Ingress Operator status.
2.2. View the default Ingress Controller Copy linkLink copied to clipboard!
The Ingress Operator is a core feature of OpenShift Dedicated and is enabled out of the box.
Every new OpenShift Dedicated installation has an ingresscontroller named default. It can be supplemented with additional Ingress Controllers. If the default ingresscontroller is deleted, the Ingress Operator will automatically recreate it within a minute.
Procedure
View the default Ingress Controller:
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
2.3. View Ingress Operator status Copy linkLink copied to clipboard!
You can view and inspect the status of your Ingress Operator.
Procedure
View your Ingress Operator status:
$ oc describe clusteroperators/ingress
2.4. View Ingress Controller logs Copy linkLink copied to clipboard!
You can view your Ingress Controller logs.
Procedure
View your Ingress Controller logs:
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
2.5. View Ingress Controller status Copy linkLink copied to clipboard!
Your can view the status of a particular Ingress Controller.
Procedure
View the status of an Ingress Controller:
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
2.6. Management of default Ingress Controller functions Copy linkLink copied to clipboard!
The following table details the components of the default Ingress Controller managed by the Ingress Operator and whether Red Hat Site Reliability Engineering (SRE) maintains this component on OpenShift Dedicated clusters.
| Ingress component | Managed by | Default configuration? |
|---|---|---|
| Scaling Ingress Controller | SRE | Yes |
| Ingress Operator thread count | SRE | Yes |
| Ingress Controller access logging | SRE | Yes |
| Ingress Controller sharding | SRE | Yes |
| Ingress Controller route admission policy | SRE | Yes |
| Ingress Controller wildcard routes | SRE | Yes |
| Ingress Controller X-Forwarded headers | SRE | Yes |
| Ingress Controller route compression | SRE | Yes |
2.7. Set namespace exclusions for the default ingress when creating a cluster Copy linkLink copied to clipboard!
When you create an OpenShift Dedicated cluster, you can specify a namespace label selector so that namespaces matching those labels are excluded from the default application ingress. This allows you to exclude namespaces that host workloads through the default ingress, such as namespaces with sensitive data or internal services.
Do not exclude namespaces that host required platform routes (for example, openshift-console or openshift-authentication). Excluding them can break the web console, downloads, or OAuth flows.
2.7.1. Set namespace exclusions for the default ingress when creating a cluster in the CLI Copy linkLink copied to clipboard!
Use the ocm CLI to pass namespace exclusions for the default ingress while creating your cluster.
Prerequisites
-
You installed the
ocmCLI and logged in with credentials that can create clusters in Red Hat OpenShift Cluster Manager. -
You are using the noninteractive mode for
ocm create cluster. For interactive mode, use the prompts for ingress settings when they are available for yourocmversion.
Procedure
-
Run
ocm create cluster -hand confirm that yourocmversion lists the--exclude-namespace-selectorflag. Build your
ocm create clustercommand with the required parameters for your cloud provider and subscription model.The following example shows only the ingress-related fragment. Replace the rest of the flags with the values required for your environment.
$ ocm create cluster <cluster_name> \ --provider=<aws_or_gcp> \ <other_required_flags> \ --default-ingress-excluded-namespace-selectors '<key>=<value>,<key2>=<value2>'where:
<cluster_name>- Specifies the cluster name.
--provider=<aws_or_gcp>- Specifies the cloud provider.
<other_required_flags>- Required parameters such as region, version, Customer Cloud Subscription (CCS) settings, or billing flags, as described in the cluster creation documentation for your platform.
--default-ingress-excluded-namespace-selectors-
Specifies label selectors that exclude matching namespaces from the default application ingress. The service validates these exclusions. Replace
<key>=<value>with your labels. Do not include spaces around the=sign.
Verification
After the cluster reaches
readystate, confirm ingress settings and inspect the default ingress object for the configured exclusion data.$ ocm list ingress -c <cluster_name>
2.7.2. Changing namespace exclusions for the default ingress on your cluster in the CLI Copy linkLink copied to clipboard!
Use the ocm CLI to pass namespace exclusions for the default ingress to your OpenShift Dedicated cluster.
Prerequisites
-
You installed the
ocmCLI and logged in with credentials that can modify clusters in Red Hat OpenShift Cluster Manager. - You have configured a OpenShift Dedicated cluster.
Procedure
Run the following command to pass the namespace exclusions to your cluster:
$ ocm edit ingress <ingress_name> -c <cluster_id> \ --excluded-namespace-selectors "key1=val1,key2=val2,key1=val3,foo=bar" \ <cluster_name>where:
<ingress_name>- Specifies your ingress name.
<cluster_id>- Specifies your cluster ID.
--excluded-namespace-selectors "key1=val1,key2=val2,key1=val3,foo=bar"-
Specifies label selectors that exclude matching namespaces from the default application ingress. The service validates these exclusions. Replace
<key>=<value>with your labels. Do not include spaces around the=sign. <cluster_name>- Specifies the cluster name.
2.7.3. Set namespace exclusions for the default ingress when creating a cluster in Red Hat OpenShift Cluster Manager Copy linkLink copied to clipboard!
Specify a namespace label selector so that namespaces matching those labels are excluded from the default application ingress when creating an OpenShift Dedicated cluster in OpenShift Cluster Manager.
Procedure
On the Networking screen, select Custom Settings under Application ingress settings.
NoteAll of the custom settings are optional.
-
In Route selector, enter a comma-separated list of
key=valuepairs to limit which routes this ingress exposes. Leave the field empty if all routes should remain eligible based on your other choices. - In Excluded namespaces, enter a comma-separated list of namespace names whose routes must not use this ingress.
In Exclude namespace selectors, specify one or more label selectors. For each selector, provide a label key and a comma-separated list of label values. The default Ingress Controller does not apply to namespaces whose labels satisfy any of the configured selectors.
ImportantDo not include spaces around commas, for example, use
finance,HR,legal, and notfinance, HR, legal.- Set Namespace ownership policy for route admission when namespaces share hostnames, for example, select Strict for restrictive admission.
Set Wildcard policy to allow or disallow wildcard patterns in route hostnames, for example, select Disallowed to block wildcard host routes.
For more information about custom application ingress settings, click the information icon provided for each setting.
2.7.4. Change namespace exclusions for the ingress on a cluster in Red Hat OpenShift Cluster Manager Copy linkLink copied to clipboard!
Specify a namespace label selector so that namespaces matching those labels are excluded from the default application ingress on your configured OpenShift Dedicated cluster in OpenShift Cluster Manager.
Procedure
- From OpenShift Cluster Manager, navigate to the Cluster List page and select the cluster that you want to set namespace exclusions for.
- On the selected cluster, select the Networking tab.
Select Edit application ingress.
NoteAll of the custom settings are optional.
-
In Route selector, enter a comma-separated list of
key=valuepairs to limit which routes this ingress exposes. Leave the field empty if all routes should remain eligible based on your other choices. - In Excluded namespaces, enter a comma-separated list of namespace names whose routes must not use this ingress.
In Exclude namespace selectors, specify one or more label selectors. For each selector, provide a label key and a comma-separated list of label values. The default Ingress Controller does not apply to namespaces whose labels satisfy any of the configured selectors.
ImportantDo not include spaces around commas, for example, use
finance,HR,legal, and notfinance, HR, legal.- Set Namespace ownership policy for route admission when namespaces share hostnames, for example, select Strict for restrictive admission.
Set Wildcard policy to allow or disallow wildcard patterns in route hostnames, for example, select Disallowed to block wildcard host routes.
For more information about custom application ingress settings, click the information icon provided for each setting.
- Select Save to configure the ingress with your changes.
Legal Notice
Copy linkLink copied to clipboard!
Copyright © Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of the OpenJS Foundation.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.