Chapter 5. Networking


5.1. DNS configuration details

5.1.1. General DNS setup

The OpenShift cluster managed by CodeReady Containers uses 2 DNS domain names, crc.testing and apps-crc.testing. The crc.testing domain is for core OpenShift services. The apps-crc.testing domain is for accessing OpenShift applications deployed on the cluster.

For example, the OpenShift API server is exposed as api.crc.testing while the OpenShift console is accessed as console-openshift-console.apps-crc.testing. These DNS domains are served by a dnsmasq DNS container running inside the CodeReady Containers instance.

The crc setup command detects and adjusts your system DNS configuration so that it can resolve these domains. Additional checks are done to verify DNS is properly configured when running crc start.

5.1.2. Linux

On Linux, depending on your distribution, CodeReady Containers expects the following DNS configuration:

5.1.2.1. NetworkManager + systemd-resolved

This configuration is used by default on Fedora 33 or newer, and on Ubuntu Desktop editions.

  • CodeReady Containers expects NetworkManager to manage networking.
  • CodeReady Containers configures systemd-resolved to forward requests for the testing domain to the 192.168.130.11 DNS server. 192.168.130.11 is the IP of the CodeReady Containers instance.
  • systemd-resolved configuration is done with a NetworkManager dispatcher script in /etc/NetworkManager/dispatcher.d/99-crc.sh:

    #!/bin/sh
    
    export LC_ALL=C
    
    systemd-resolve --interface crc --set-dns 192.168.130.11 --set-domain ~testing
    
    exit 0
Note

systemd-resolved is also available as an unsupported Technology Preview on Red Hat Enterprise Linux and CentOS 8.3. After configuring the host to use systemd-resolved, stop any running clusters and rerun crc setup.

5.1.2.2. NetworkManager + dnsmasq

This configuration is used by default on Fedora 32 or older, on Red Hat Enterprise Linux, and on CentOS.

  • CodeReady Containers expects NetworkManager to manage networking.
  • NetworkManager uses dnsmasq with the /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf configuration file.
  • The configuration file for this dnsmasq instance is /etc/NetworkManager/dnsmasq.d/crc.conf:

    server=/crc.testing/192.168.130.11
    server=/apps-crc.testing/192.168.130.11
    • The NetworkManager dnsmasq instance forwards requests for the crc.testing and apps-crc.testing domains to the 192.168.130.11 DNS server.

5.2. Reserved IP subnets

The CodeReady Containers OpenShift cluster reserves IP subnets for internal use which should not collide with your host network. Ensure that the following IP subnets are available for use:

Reserved IP subnets

  • 10.217.0.0/22
  • 10.217.4.0/23
  • 192.168.126.0/24

Additionally, the host hypervisor may reserve another IP subnet depending on the host operating system. On Microsoft Windows, the hypervisor reserves a randomly generated IP subnet that cannot be determined ahead-of-time. No additional subnet is reserved on macOS. The additional reserved subnet for Linux is 192.168.130.0/24.

5.3. Starting CodeReady Containers behind a proxy

You can start CodeReady Containers behind a defined proxy using environment variables or configurable properties.

Note

SOCKS proxies are not supported by OpenShift Container Platform.

Prerequisites

  • To use an existing OpenShift CLI (oc) executable on your host machine, export the .testing domain as part of the no_proxy environment variable. The embedded oc executable does not require manual settings. For more information about using the embedded oc executable, see Accessing the OpenShift cluster with the OpenShift CLI.

Procedure

  1. Define a proxy using the http_proxy and https_proxy environment variables or using the crc config set command as follows:

    $ crc config set http-proxy http://proxy.example.com:<port>
    $ crc config set https-proxy http://proxy.example.com:<port>
    $ crc config set no-proxy <comma-separated-no-proxy-entries>
  2. If the proxy uses a custom CA certificate file, set it as follows:

    $ crc config set proxy-ca-file <path-to-custom-ca-file>
Note

Proxy-related values set in the configuration for CodeReady Containers have priority over values set with environment variables.

5.4. Setting up CodeReady Containers on a remote server

Configure a remote server to run a CodeReady Containers OpenShift cluster.

This procedure assumes the use of a Red Hat Enterprise Linux, Fedora, or CentOS server. Run every command in this procedure on the remote server.

Warning

Perform this procedure only on a local network. Exposing an insecure server on the internet has many security implications.

Prerequisites

Procedure

  1. Start the cluster:

    $ crc start

    Ensure that the cluster remains running during this procedure.

  2. Install the haproxy package and other utilities:

    $ sudo dnf install haproxy /usr/sbin/semanage
  3. Modify the firewall to allow communication with the cluster:

    $ sudo systemctl enable --now firewalld
    $ sudo firewall-cmd --add-service=http --permanent
    $ sudo firewall-cmd --add-service=https --permanent
    $ sudo firewall-cmd --add-service=kube-apiserver --permanent
    $ sudo firewall-cmd --reload
  4. For SELinux, allow HAProxy to listen on TCP port 6443 to serve kube-apiserver on this port:

    $ sudo semanage port -a -t http_port_t -p tcp 6443
  5. Create a backup of the default haproxy configuration:

    $ sudo cp /etc/haproxy/haproxy.cfg{,.bak}
  6. Configure haproxy for use with the cluster:

    $ export CRC_IP=$(crc ip)
    $ sudo tee /etc/haproxy/haproxy.cfg &>/dev/null <<EOF
    global
        log /dev/log local0
    
    defaults
        balance roundrobin
        log global
        maxconn 100
        mode tcp
        timeout connect 5s
        timeout client 500s
        timeout server 500s
    
    listen apps
        bind 0.0.0.0:80
        server crcvm $CRC_IP:80 check
    
    listen apps_ssl
        bind 0.0.0.0:443
        server crcvm $CRC_IP:443 check
    
    listen api
        bind 0.0.0.0:6443
        server crcvm $CRC_IP:6443 check
    EOF
  7. Start the haproxy service:

    $ sudo systemctl start haproxy

5.5. Connecting to a remote CodeReady Containers instance

Use dnsmasq to connect a client machine to a remote server running a CodeReady Containers OpenShift cluster.

This procedure assumes the use of a Red Hat Enterprise Linux, Fedora, or CentOS client. Run every command in this procedure on the client.

Important

Connect to a server that is only exposed on your local network.

Prerequisites

Procedure

  1. Install the dnsmasq package:

    $ sudo dnf install dnsmasq
  2. Enable the use of dnsmasq for DNS resolution in NetworkManager:

    $ sudo tee /etc/NetworkManager/conf.d/use-dnsmasq.conf &>/dev/null <<EOF
    [main]
    dns=dnsmasq
    EOF
  3. Add DNS entries for CodeReady Containers to the dnsmasq configuration:

    $ sudo tee /etc/NetworkManager/dnsmasq.d/external-crc.conf &>/dev/null <<EOF
    address=/apps-crc.testing/SERVER_IP_ADDRESS
    address=/api.crc.testing/SERVER_IP_ADDRESS
    EOF
    Note

    Comment out any existing entries in /etc/NetworkManager/dnsmasq.d/crc.conf. These entries are created by running a local instance of CodeReady Containers and will conflict with the entries for the remote cluster.

  4. Reload the NetworkManager service:

    $ sudo systemctl reload NetworkManager
  5. Log in to the remote cluster as the developer user with oc:

    $ oc login -u developer -p developer https://api.crc.testing:6443

    The remote OpenShift Web Console is available at https://console-openshift-console.apps-crc.testing.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.