diff --git a/data/data/bootstrap/baremetal/README.md b/data/data/bootstrap/baremetal/README.md index a3fd19af6ad..843fa788099 100644 --- a/data/data/bootstrap/baremetal/README.md +++ b/data/data/bootstrap/baremetal/README.md @@ -22,8 +22,6 @@ internal to the cluster as possible. There is a DNS VIP managed by `keepalived` in a manner similar to the API VIP discussed above. -`coredns` runs with a custom `mdns` plugin (`coredns-mdns`). - Relevant files: * **[files/etc/dhcp/dhclient.conf](files/etc/dhcp/dhclient.conf)** - Specify that the bootstrap VM should use `localhost` as its primary DNS server. diff --git a/data/data/bootstrap/files/usr/local/bin/bootkube.sh.template b/data/data/bootstrap/files/usr/local/bin/bootkube.sh.template index cf52414f06d..f7cf30539fb 100755 --- a/data/data/bootstrap/files/usr/local/bin/bootkube.sh.template +++ b/data/data/bootstrap/files/usr/local/bin/bootkube.sh.template @@ -63,7 +63,6 @@ CLUSTER_BOOTSTRAP_IMAGE=$(image_for cluster-bootstrap) KEEPALIVED_IMAGE=$(image_for keepalived-ipfailover || echo "no-keepalived-image") COREDNS_IMAGE=$(image_for coredns) -MDNS_PUBLISHER_IMAGE=$(image_for mdns-publisher) HAPROXY_IMAGE=$(image_for haproxy-router) BAREMETAL_RUNTIMECFG_IMAGE=$(image_for baremetal-runtimecfg) @@ -299,7 +298,6 @@ then --infra-image="${MACHINE_CONFIG_INFRA_IMAGE}" \ --keepalived-image="${KEEPALIVED_IMAGE}" \ --coredns-image="${COREDNS_IMAGE}" \ - --mdns-publisher-image="${MDNS_PUBLISHER_IMAGE}" \ --haproxy-image="${HAPROXY_IMAGE}" \ --baremetal-runtimecfg-image="${BAREMETAL_RUNTIMECFG_IMAGE}" \ --release-image="${RELEASE_IMAGE_DIGEST}" \ diff --git a/data/data/openstack/topology/sg-master.tf b/data/data/openstack/topology/sg-master.tf index 8355069356c..807f8e57898 100644 --- a/data/data/openstack/topology/sg-master.tf +++ b/data/data/openstack/topology/sg-master.tf @@ -62,17 +62,6 @@ resource "openstack_networking_secgroup_rule_v2" "master_ingress_dns_udp" { description = local.description } -resource "openstack_networking_secgroup_rule_v2" "master_ingress_mdns_udp" { - direction = "ingress" - ethertype = "IPv4" - protocol = "udp" - port_range_min = 5353 - port_range_max = 5353 - remote_ip_prefix = var.cidr_block - security_group_id = openstack_networking_secgroup_v2.master.id - description = local.description -} - resource "openstack_networking_secgroup_rule_v2" "master_ingress_https" { direction = "ingress" ethertype = "IPv4" diff --git a/data/data/openstack/topology/sg-worker.tf b/data/data/openstack/topology/sg-worker.tf index 35dc5c0ee40..641c38d9b24 100644 --- a/data/data/openstack/topology/sg-worker.tf +++ b/data/data/openstack/topology/sg-worker.tf @@ -29,17 +29,6 @@ resource "openstack_networking_secgroup_rule_v2" "worker_ingress_ssh" { description = local.description } -resource "openstack_networking_secgroup_rule_v2" "worker_ingress_mdns_udp" { - direction = "ingress" - ethertype = "IPv4" - protocol = "udp" - port_range_min = 5353 - port_range_max = 5353 - remote_ip_prefix = var.cidr_block - security_group_id = openstack_networking_secgroup_v2.worker.id - description = local.description -} - resource "openstack_networking_secgroup_rule_v2" "worker_ingress_http" { direction = "ingress" ethertype = "IPv4" diff --git a/docs/design/baremetal/networking-infrastructure.md b/docs/design/baremetal/networking-infrastructure.md index 2624bb5f428..906c9a3ca0e 100644 --- a/docs/design/baremetal/networking-infrastructure.md +++ b/docs/design/baremetal/networking-infrastructure.md @@ -94,12 +94,8 @@ before starting the installation process. In a `baremetal` environment, we do not know the IP addresses of all hosts in advance. Those will come from an organization’s DHCP server. Further, we can not rely on being able to program an organization’s DNS infrastructure in all -cases. We address these challenges in two ways: - -1. Self host some DNS infrastructure to provide DNS resolution for records only - needed internal to the cluster. -2. Make use of mDNS (Multicast DNS) to dynamically discover the addresses of - hosts that we must resolve records for. +cases. We address these challenges by self hosting a DNS server to provide DNS +resolution for records internal to the cluster. ### api-int hostname resolution @@ -107,41 +103,22 @@ The CoreDNS server performing our internal DNS resolution includes configuration to resolve the `api-int` hostname. `api-int` will be resolved to the API VIP. -### mdns-publisher - -https://github.com/openshift/mdns-publisher - -The `mdns-publisher` is the component that runs on each host to make itself -discoverable by other hosts in the cluster. Control plane hosts currently -advertise `master-NN` names, and the worker nodes advertise -`worker-NN` names. *Note: The `master-NN` and `worker-NN` names were based on records -previously published on AWS clusters, but may no longer be necessary.* - -On masters and workers it is run by the `machine-config-operator`. - -`mdns-publisher` is not run on the bootstrap node, as there is no need for any -other host to discover the IP address that the bootstrap VM gets from DHCP. - -### coredns-mdns - -https://github.com/openshift/coredns-mdns/ +### nodes hostname resolution -The `mdns` plugin for `coredns` was developed to perform DNS lookups -based on discoverable information from mDNS. The plugin will resolve the -`master-NN` and `worker-NN` records in the cluster domain. +The same CoreDNS server also resolves the `master-NN` and `worker-NN` records +in the cluster domain. -The IP addresses that the `master-NN` host records resolve to comes from the -mDNS advertisement sent out by the `mdns-publisher` on that control plane node. +The IP addresses that the `master-NN` and `worker-NN` host records resolve to +comes from querying the OpenShift API. ### DNS Resolution Because the baremetal platform does not have a cloud DNS service available to -provide internal DNS records, it instead uses a coredns static pod configured -with the `coredns-mdns` plugin discussed above. There is one of these pods -running on every node in a deployment, and a NetworkManager dispatcher script -is used to configure resolv.conf to point at the node's public IP address. -`localhost` can't be used because `resolv.conf` is propagated into some -containers where that won't resolve to the actual host. +provide internal DNS records, it instead uses a coredns static pod. There is +one of these pods running on every node in a deployment, and a NetworkManager +dispatcher script is used to configure resolv.conf to point at the node's +public IP address. `localhost` can't be used because `resolv.conf` is +propagated into some containers where that won't resolve to the actual host. ### Bootstrap Asset Details diff --git a/docs/design/openstack/networking-infrastructure.md b/docs/design/openstack/networking-infrastructure.md index 2e332bd8c59..2bd6d7de3bd 100644 --- a/docs/design/openstack/networking-infrastructure.md +++ b/docs/design/openstack/networking-infrastructure.md @@ -1,7 +1,7 @@ # OpenStack IPI Networking Infrastructure -The `OpenStack` platform installer uses an internal networking solution that -is based heavily on the [baremetal networking infrastructure](../baremetal/networking-infrastructure.md). +The `OpenStack` platform installer uses an internal networking solution identical to +the [baremetal networking infrastructure](../baremetal/networking-infrastructure.md). For an overview of the quotas required, and the entrypoints created when you build an OpenStack IPI cluster, see the [user docs](../../user/openstack/README.md). @@ -15,21 +15,6 @@ These services are initially hosted by the bootstrap node until the control plane is up. Then, control is pivoted to the control plane machines. We will go into further detail on that process in the [Virtual IPs section](#virtual-ips). -## CoreDNS-mDNS - -https://github.com/openshift/CoreDNS-mdns/ - -The `mDNS` plugin for `CoreDNS` was developed to perform DNS lookups -based on discoverable information from mDNS. This plugin will resolve both the -`etcd-NNN` records, as well as the `_etcd-server-ssl._tcp.` SRV record. It is also -able to resolve the name of the nodes. - -The list of `etcd` hosts included in the SRV record is based on the list of -control plane nodes currently running. - -The IP addresses that the `etcd-NNN` host records resolve to comes from the -mDNS advertisement sent out by the `mDNS-publisher` on that control plane node. - ## Virtual IPs We use virtual IP addresses, VIPs, managed by Keepalived to provide high @@ -61,9 +46,9 @@ The bootstrap node is responsible for running temporary networking infrastructur nodes are still coming up. The bootstrap node will run a CoreDNS instance, as well as Keepalived. While the bootstrap node is up, it will have priority running the API VIP. -The Master nodes run dhcp, HAProxy, CoreDNS, mDNS-publisher, and Keepalived. Haproxy loadbalances incoming requests +The Master nodes run dhcp, HAProxy, CoreDNS, and Keepalived. Haproxy loadbalances incoming requests to the API across all running masters. It also runs a stats and healthcheck server. Keepalived manages both VIPs on the master, where each master has an equal chance of being assigned one of the VIPs. Initially, the bootstrap node has the highest priority for hosting the API VIP, so they will point to addresses there at startup. Meanwhile, the master nodes will try to get the control plane, and the OpenShift API up. Keepalived implements periodic health checks for each VIP that are used to determine the weight assigned to each server. The server with the highest weight is assigned the VIP. Keepalived has two seperate healthchecks that attempt to reach the OpenShift API and CoreDNS on the localhost of each master node. When the API on a master node is reachable, Keepalived substantially increases it's weight for that VIP, making its priority higher than that of the bootstrap node and any node that does not yet have the that service running. This ensures that nodes that are incapable of serving DNS records or the OpenShift API do not get assigned the respective VIP. The Ingress VIP is also managed by a healthcheck that queries for an OCP Router HAProxy healthcheck, not the HAProxy we stand up in static pods for the API. This makes sure that the Ingress VIP is pointing to a server that is running the necessary OpenShift Ingress Operator resources to enable external access to the node. -The Worker Nodes run dhcp, CoreDNS, mDNS-publisher, and Keepalived. On workers, Keepalived is only responsible for managing +The Worker Nodes run dhcp, CoreDNS, and Keepalived. On workers, Keepalived is only responsible for managing the Ingress VIP. It's algorithm is the same as the one run on the masters. diff --git a/docs/user/openstack/known-issues.md b/docs/user/openstack/known-issues.md index fb6ea565a8c..2ef36421653 100644 --- a/docs/user/openstack/known-issues.md +++ b/docs/user/openstack/known-issues.md @@ -2,10 +2,6 @@ We have been tracking a few issues and FAQs from our users, and are documenting them here along with the known workarounds and solutions. For issues that still have open bugs, we have attached the links to where the engineering team is tracking their progress. As changes occur, we will update both this document and the issue trackers with the latest information. -## Long Cluster Names - -If the mDNS service name of a server is too long, it will exceed the character limit and cause the installer to fail. To prevent this from happening, please restrict the `metadata.name` field in the `install-config.yaml` to 14 characters. The installer validates this in your install config and throws an error to prevent you from triggering this install time bug. This is being tracked in this [github issue](https://github.com/openshift/installer/issues/2243). - ## Resources With Duplicate Names Since the installer requires the *Name* of your external network and Red Hat Core OS image, if you have other networks or images with the same name, it will choose one randomly from the set. This is not a reliable way to run the installer. We highly recommend that you resolve this with your cluster administrator by creating unique names for your resources in openstack. diff --git a/upi/openstack/security-groups.yaml b/upi/openstack/security-groups.yaml index 8ebcc593917..b767ed3a70c 100644 --- a/upi/openstack/security-groups.yaml +++ b/upi/openstack/security-groups.yaml @@ -63,14 +63,6 @@ port_range_min: 53 port_range_max: 53 - - name: 'Create master-sg rule "mDNS"' - os_security_group_rule: - security_group: "{{ os_sg_master }}" - remote_ip_prefix: "{{ os_subnet_range }}" - protocol: udp - port_range_min: 5353 - port_range_max: 5353 - - name: 'Create master-sg rule "OpenShift API"' os_security_group_rule: security_group: "{{ os_sg_master }}" @@ -202,14 +194,6 @@ port_range_min: 22 port_range_max: 22 - - name: 'Create worker-sg rule "mDNS"' - os_security_group_rule: - security_group: "{{ os_sg_worker }}" - protocol: udp - remote_ip_prefix: "{{ os_subnet_range }}" - port_range_min: 5353 - port_range_max: 5353 - - name: 'Create worker-sg rule "Ingress HTTP"' os_security_group_rule: security_group: "{{ os_sg_worker }}"