apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
name: cluster
spec:
trustedCA:
name: ""
status:
After installing OpenShift Container Platform, you can further expand and customize your network to your requirements.
The configuration for the cluster network is specified as part of the Cluster Network Operator (CNO) configuration and stored in a custom resource (CR) object that is named cluster
. The CR specifies the fields for the Network
API in the operator.openshift.io
API group.
The CNO configuration inherits the following fields during cluster installation from the Network
API in the Network.config.openshift.io
API group and these fields cannot be changed:
clusterNetwork
IP address pools from which pod IP addresses are allocated.
serviceNetwork
IP address pool for services.
defaultNetwork.type
Cluster network provider, such as OpenShift SDN or OVN-Kubernetes.
After cluster installation, you cannot modify the fields listed in the previous section. |
The Proxy
object is used to manage the cluster-wide egress proxy. When a cluster is installed or upgraded without the proxy configured, a Proxy
object is still generated but it will have a nil spec
. For example:
apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
name: cluster
spec:
trustedCA:
name: ""
status:
A cluster administrator can configure the proxy for OpenShift Container Platform by modifying this cluster
Proxy
object.
Only the |
Cluster administrator permissions
OpenShift Container Platform oc
CLI tool installed
Create a config map that contains any additional CA certificates required for proxying HTTPS connections.
You can skip this step if the proxy’s identity certificate is signed by an authority from the RHCOS trust bundle. |
Create a file called user-ca-bundle.yaml
with the following contents, and provide the values of your PEM-encoded certificates:
apiVersion: v1
data:
ca-bundle.crt: | (1)
<MY_PEM_ENCODED_CERTS> (2)
kind: ConfigMap
metadata:
name: user-ca-bundle (3)
namespace: openshift-config (4)
1 | This data key must be named ca-bundle.crt . |
2 | One or more PEM-encoded X.509 certificates used to sign the proxy’s identity certificate. |
3 | The config map name that will be referenced from the Proxy object. |
4 | The config map must be in the openshift-config namespace. |
Create the config map from this file:
$ oc create -f user-ca-bundle.yaml
Use the oc edit
command to modify the Proxy
object:
$ oc edit proxy/cluster
Configure the necessary fields for the proxy:
apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
name: cluster
spec:
httpProxy: http://<username>:<pswd>@<ip>:<port> (1)
httpsProxy: https://<username>:<pswd>@<ip>:<port> (2)
noProxy: example.com (3)
readinessEndpoints:
- http://www.google.com (4)
- https://www.google.com
trustedCA:
name: user-ca-bundle (5)
1 | A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be http . |
2 | A proxy URL to use for creating HTTPS connections outside the cluster. The URL scheme must be either http or https . Specify a URL for the proxy that supports the URL scheme. For example, most proxies will report an error if they are configured to use https but they only support http . This failure message may not propagate to the logs and can appear to be a network connection failure instead. If using a proxy that listens for https connections from the cluster, you may need to configure the cluster to accept the CAs and certificates that the proxy uses. |
3 | A comma-separated list of destination domain names, domains, IP addresses or other network CIDRs to exclude proxying.
Preface a domain with This field is ignored if neither the |
4 | One or more URLs external to the cluster to use to perform a readiness check before writing the httpProxy and httpsProxy values to status. |
5 | A reference to the config map in the openshift-config namespace that contains additional CA certificates required for proxying HTTPS connections. Note that the config map must already exist before referencing it here. This field is required unless the proxy’s identity certificate is signed by an authority from the RHCOS trust bundle. |
Save the file to apply the changes.
After you deploy a cluster, you can modify its DNS to use only a private zone.
Review the DNS
custom resource for your cluster:
$ oc get dnses.config.openshift.io/cluster -o yaml
apiVersion: config.openshift.io/v1
kind: DNS
metadata:
creationTimestamp: "2019-10-25T18:27:09Z"
generation: 2
name: cluster
resourceVersion: "37966"
selfLink: /apis/config.openshift.io/v1/dnses/cluster
uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
spec:
baseDomain: <base_domain>
privateZone:
tags:
Name: <infrastructure_id>-int
kubernetes.io/cluster/<infrastructure_id>: owned
publicZone:
id: Z2XXXXXXXXXXA4
status: {}
Note that the spec
section contains both a private and a public zone.
Patch the DNS
custom resource to remove the public zone:
$ oc patch dnses.config.openshift.io/cluster --type=merge --patch='{"spec": {"publicZone": null}}'
dns.config.openshift.io/cluster patched
Because the Ingress Controller consults the DNS
definition when it creates Ingress
objects, when you create or modify Ingress
objects, only private records are created.
DNS records for the existing Ingress objects are not modified when you remove the public zone. |
Optional: Review the DNS
custom resource for your cluster and confirm that the public zone was removed:
$ oc get dnses.config.openshift.io/cluster -o yaml
apiVersion: config.openshift.io/v1
kind: DNS
metadata:
creationTimestamp: "2019-10-25T18:27:09Z"
generation: 2
name: cluster
resourceVersion: "37966"
selfLink: /apis/config.openshift.io/v1/dnses/cluster
uid: 0e714746-f755-11f9-9cb1-02ff55d8f976
spec:
baseDomain: <base_domain>
privateZone:
tags:
Name: <infrastructure_id>-int
kubernetes.io/cluster/<infrastructure_id>-wfpg4: owned
status: {}
OpenShift Container Platform provides the following methods for communicating from outside the cluster with services running in the cluster:
If you have HTTP/HTTPS, use an Ingress Controller.
If you have a TLS-encrypted protocol other than HTTPS, such as TLS with the SNI header, use an Ingress Controller.
Otherwise, use a load balancer, an external IP, or a node port.
Method | Purpose |
---|---|
Allows access to HTTP/HTTPS traffic and TLS-encrypted protocols other than HTTPS, such as TLS with the SNI header. |
|
Automatically assign an external IP by using a load balancer service |
Allows traffic to non-standard ports through an IP address assigned from a pool. |
Allows traffic to non-standard ports through a specific IP address. |
|
Expose a service on all nodes in the cluster. |
As a cluster administrator, you can expand the available node port range. If your cluster uses of a large number of node ports, you might need to increase the number of available ports.
The default port range is 30000-32767
. You can never reduce the port range, even if you first expand it beyond the default range.
Your cluster infrastructure must allow access to the ports that you specify within the expanded range. For example, if you expand the node port range to 30000-32900
, the inclusive port range of 32768-32900
must be allowed by your firewall or packet filtering configuration.
You can expand the node port range for the cluster.
Install the OpenShift CLI (oc
).
Log in to the cluster with a user with cluster-admin
privileges.
To expand the node port range, enter the following command. Replace <port>
with the largest port number in the new range.
$ oc patch network.config.openshift.io cluster --type=merge -p \
'{
"spec":
{ "serviceNodePortRange": "30000-<port>" }
}'
You can alternatively apply the following YAML to update the node port range:
|
network.config.openshift.io/cluster patched
To confirm that the configuration is active, enter the following command. It can take several minutes for the update to apply.
$ oc get configmaps -n openshift-kube-apiserver config \
-o jsonpath="{.data['config\.yaml']}" | \
grep -Eo '"service-node-port-range":["[[:digit:]]+-[[:digit:]]+"]'
"service-node-port-range":["30000-33000"]