Este contenido no está disponible en el idioma seleccionado.

Networking Operators


OpenShift Dedicated 4

Managing networking-specific Operators in OpenShift Dedicated

Red Hat OpenShift Documentation Team

Abstract

This document covers the installation, configuration, and management of various networking-related Operators in OpenShift Dedicated.

Chapter 1. DNS Operator in OpenShift Dedicated

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

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.

    Important

    You 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.

Important

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/default

    After you issue the previous command, the Operator creates and updates the config map named dns-default with additional server configuration blocks based on spec.servers.

    Important

    When specifying values for the zones parameter, 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 rfc6335 service name syntax.
    spec.servers.zones
    Must conform to the rfc1123 subdomain syntax. The cluster domain cluster.local is invalid for zones.
    spec.servers.forwardPlugin.policy
    Specifies the upstream selection policy. Defaults to Random; allowed values are RoundRobin and Sequential.
    spec.servers.forwardPlugin.upstreams
    Must provide no more than 15 upstreams entries per forwardPlugin.
    spec.upstreamResolvers.upstreams
    Specifies an upstreamResolvers to 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 are Random, RoundRobin, and Sequential.
    spec.upstreamResolvers.protocolStrategy
    Specify TCP to force the protocol to use for upstream DNS requests, even if the request uses UDP. Valid values are TCP and 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: SystemResolvConf or Network. SystemResolvConf configures the upstream to use /etc/resolv.conf and Network defines a Networkresolver. 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 1 and 65535; defaults to 853 when omitted.

Chapter 2. Ingress Operator in OpenShift Dedicated

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

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

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

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

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

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

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.

Expand
Table 2.1. Ingress Operator Responsibility Chart
Ingress componentManaged byDefault 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

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.

Note

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.

Use the ocm CLI to pass namespace exclusions for the default ingress while creating your cluster.

Prerequisites

  • You installed the ocm CLI 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 your ocm version.

Procedure

  1. Run ocm create cluster -h and confirm that your ocm version lists the --exclude-namespace-selector flag.
  2. Build your ocm create cluster command 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 ready state, confirm ingress settings and inspect the default ingress object for the configured exclusion data.

    $ ocm list ingress -c <cluster_name>

Use the ocm CLI to pass namespace exclusions for the default ingress to your OpenShift Dedicated cluster.

Prerequisites

  • You installed the ocm CLI and logged in with credentials that can modify clusters in Red Hat OpenShift Cluster Manager.
  • You have configured a OpenShift Dedicated cluster.

Procedure

  1. 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.

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

  1. On the Networking screen, select Custom Settings under Application ingress settings.

    Note

    All of the custom settings are optional.

  2. In Route selector, enter a comma-separated list of key=value pairs to limit which routes this ingress exposes. Leave the field empty if all routes should remain eligible based on your other choices.
  3. In Excluded namespaces, enter a comma-separated list of namespace names whose routes must not use this ingress.
  4. 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.

    Important

    Do not include spaces around commas, for example, use finance,HR,legal, and not finance, HR, legal.

  5. Set Namespace ownership policy for route admission when namespaces share hostnames, for example, select Strict for restrictive admission.
  6. 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.

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

  1. From OpenShift Cluster Manager, navigate to the Cluster List page and select the cluster that you want to set namespace exclusions for.
  2. On the selected cluster, select the Networking tab.
  3. Select Edit application ingress.

    Note

    All of the custom settings are optional.

  4. In Route selector, enter a comma-separated list of key=value pairs to limit which routes this ingress exposes. Leave the field empty if all routes should remain eligible based on your other choices.
  5. In Excluded namespaces, enter a comma-separated list of namespace names whose routes must not use this ingress.
  6. 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.

    Important

    Do not include spaces around commas, for example, use finance,HR,legal, and not finance, HR, legal.

  7. Set Namespace ownership policy for route admission when namespaces share hostnames, for example, select Strict for restrictive admission.
  8. 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.

  9. Select Save to configure the ingress with your changes.

Legal Notice

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.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de la documentación de Red Hat

Legal Notice

Theme

© 2026 Red Hat
Volver arriba