Networking considerations

Users will likely install Launchpad on a laptop or a VM with the intent of deploying MKE, MSR, or MCR onto VMs running on a public or private cloud that supports security groups for IP access control. Such an approach makes it fairly simple to configure networking in a way that provides adequate security and convenient access to the cluster for evaluation and experimentation.

The simplest way to configure the networking for a small, temporary cluster for evaluation:

  1. Create a new virtual subnet (or VPC and subnet) for hosts.

  2. Create a new security group called de_hosts (or another name of your choice) that permits inbound IPv4 traffic on all ports, either from the security group de_hosts, or from the new virtual subnet only.

  3. Create another new security group (for example, admit_me) that permits inbound IPv4 traffic from your deployer machine’s public IP address only (for instance, the website whatismyip.com) to determine your public IP.

  4. When launching hosts, attach them to the newly-created subnet and apply both new security groups.

  5. (Optional) Once you know the IPv4 addresses (public, or VPN-accessible private) of your nodes, unless you are using local DNS it makes sense to assign names to your hosts (for example, manager, worker1, worker2… and so on). Then, insert IP addresses and names in your hostfile, thus letting you (and Launchpad) refer to hosts by hostname instead of IP address.

Once the hosts are booted, SSH into them from your deployer machine with your private key. For example:

ssh -i /my/private/keyfile username@mynode

After that, determine whether they can access the internet. One method for doing this is by pinging a Google nameserver:

$ ping 8.8.8.8

Now, proceed with installing Launchpad and configuring an MKE, MSR, or MCR deployment. Once completed, use your deployer machine to access the MKE web UI, run kubectl (after authenticating to your cluster) and other utilities (for example, Postman, curl, and so on).

Use a VPN

A more secure way to manage networking is to connect your deployer machine to your VPC/subnet using a VPN, and to then modify the de_hosts security group to accept traffic on all ports from this source.

More deliberate network security

If you intend to deploy a cluster for longer-term evaluation, it makes sense to secure it more deliberately. In this case, a certain range of ports will need to be opened on hosts. Refer to Open ports to incoming traffic for details.

Pod CIDR and the Swarm overlay address pool

Swarm allocates the subnets for overlay networks, including ingress, from its default address pool. If no pool is set when the swarm is created, MCR uses 10.0.0.0/8 and allocates /24 subnets from it.

The Kubernetes pod network range, which you set with --pod-cidr in spec.mke.installFlags, must not overlap any Swarm default address pool. An overlap can leave the container runtime with a broken network configuration during MKE bootstrap. The SSH connection then drops, and Launchpad reports a connection timeout after 20 minutes or more.

Starting with Launchpad 1.5.17, the Validate Facts phase checks for this overlap before Launchpad installs anything. The check runs only if --pod-cidr is set. Starting with Launchpad 1.5.18, the result depends on whether the swarm already exists:

  • No swarm exists (new installation): Launchpad compares --pod-cidr with each --default-addr-pool value in spec.mcr.swarmInstallFlags, or with 10.0.0.0/8 if none is set. If the ranges overlap, launchpad apply fails. The --force flag does not bypass this check.

  • A swarm exists (for example, during an upgrade): Launchpad compares --pod-cidr with the pool of the running swarm, which it reads from the swarm leader. If the ranges overlap, Launchpad logs a warning and continues.

Error for a new cluster:

invalid pod CIDR configuration: --pod-cidr 10.0.0.0/16 overlaps with the Swarm overlay address pool 10.0.0.0/8; choose a non-overlapping range or set mcr.swarmInstallFlags --default-addr-pool to a non-conflicting pool

Warning for an existing swarm:

--pod-cidr 10.0.0.0/16 overlaps the overlay address pool 10.0.0.0/8 of the existing swarm, which can leave the container runtime with a broken network configuration during MKE bootstrap. The pool is fixed when a swarm is created, so mcr.swarmInstallFlags cannot resolve this on a running cluster: either choose a non-overlapping --pod-cidr, or dissolve and re-create the swarm with a non-overlapping pool

To resolve an overlap on a new cluster, choose a --pod-cidr outside the Swarm pool, or set a different Swarm pool:

spec:
  mke:
    installFlags:
      - --pod-cidr=10.0.0.0/16
  mcr:
    swarmInstallFlags:
      - --default-addr-pool=172.20.0.0/14
      - --default-addr-pool-mask-length=24

The Swarm pool is fixed when the swarm is created. Launchpad passes spec.mcr.swarmInstallFlags to docker swarm init, so these flags take effect only on the run that creates the swarm. If the swarm already exists and swarmInstallFlags is set, Launchpad logs:

<host>: swarm install flags only apply when a swarm is created, so "<flags>" has no effect on this cluster

If the configured --default-addr-pool differs from the pool of the running swarm, Launchpad also logs:

mcr.swarmInstallFlags sets --default-addr-pool <configured> but the existing swarm allocates overlay networks from <live>. A swarm's address pool is fixed when the swarm is created and cannot be changed on a running cluster, so this setting has no effect here and the cluster no longer matches its configuration. Changing the pool requires dissolving and re-creating the swarm, which destroys every overlay network and service

To read the pool of a running swarm, run the following command on a manager node:

docker info --format '{{.Swarm.LocalNodeState}}|{{if .Swarm.Cluster}}{{range .Swarm.Cluster.DefaultAddrPool}}{{.}} {{end}}{{end}}'

An empty list after active| indicates that the swarm uses the default 10.0.0.0/8 pool.

To resolve an overlap on an existing cluster, change the cluster pod CIDR. Refer to Configure cluster and service networking in an existing cluster. Changing the Swarm pool requires dissolving and re-creating the swarm, which destroys every overlay network and every service attached to one, including ingress.

Use DNS

Launchpad can deploy certificate bundles obtained from a certificate provider to authenticate your cluster. These can be used in combination with DNS to allow you to reach your cluster securely on a fully-qualified domain name (FQDN). Refer to Manage MKE certificate authorities for details.