Ce contenu n'est pas disponible dans la langue sélectionnée.
Networking Operators
Managing networking-specific Operators in OpenShift Dedicated
Abstract
Chapter 1. DNS Operator in OpenShift Dedicated Copier lienLien copié sur presse-papiers!
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 Copier lienLien copié sur presse-papiers!
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/default
$ oc edit dns.operator/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow After 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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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 Copier lienLien copié sur presse-papiers!
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 Copier lienLien copié sur presse-papiers!
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 Copier lienLien copié sur presse-papiers!
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
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. View Ingress Operator status Copier lienLien copié sur presse-papiers!
You can view and inspect the status of your Ingress Operator.
Procedure
View your Ingress Operator status:
oc describe clusteroperators/ingress
$ oc describe clusteroperators/ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. View Ingress Controller logs Copier lienLien copié sur presse-papiers!
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>
$ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. View Ingress Controller status Copier lienLien copié sur presse-papiers!
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>
$ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. Management of default Ingress Controller functions Copier lienLien copié sur presse-papiers!
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 |
Legal Notice
Copier lienLien copié sur presse-papiers!
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.