Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

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
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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

2.7. Set namespace exclusions for the default ingress when creating a cluster
Copia collegamento

When you create an OpenShift Dedicated cluster in noninteractive mode, you can pass 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.

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

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, CCS settings, or billing flags, as described in the cluster creation documentation for your platform.
    --default-ingress-excluded-namespace-selectors
    Specifies label selectors; namespaces whose labels match are excluded from the default application ingress, subject to validation by the service. 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>

2.8. Configure excluded namespaces for the default ingress controller
Copia collegamento

As a cluster administrator, you can use the OpenShift Cluster Manager CLI (ocm) to set which namespaces are excluded from the default application ingress on an existing cluster. Excluded namespaces do not have routes served by that ingress.

Prerequisites

  • You installed the ocm CLI and logged in with credentials that can modify cluster ingress settings in Red Hat OpenShift Cluster Manager.
  • You have the cluster name, cluster ID, or external ID of your cluster.
Important

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.

Procedure

  1. Optional: Set your cluster name in a variable: 

    $ export CLUSTER_NAME=<cluster_name>

  2. List ingress endpoints for the cluster and note the id of the default ingress: 

    $ ocm list ingress -c ${CLUSTER_NAME}

  3. Optional: To store the default ingress ID in a variable: 

    $ export INGRESS_ID=$(ocm list ingress -c ${CLUSTER_NAME}| jq -r '.[] | select(.default == true) | .id')

  4. Edit the default ingress and set excluded namespaces as a comma-separated list of namespace names: 

    $ ocm edit ingress -c ${CLUSTER_NAME} ${INGRESS_ID} \
    --excluded-namespaces 'namespace-one,namespace-two'

    Substitute namespace-one, namespace-two, and any additional entries with the metadata names of the namespaces to exclude.

Verification

  • After the command completes, verify that the updated ingress object reflects your excluded namespace settings. 

    $ ocm list ingress -c <cluster_name>

Legal Notice
Copia collegamento

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

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima