Network Topologies in kOps

kOps supports a number of pre defined network topologies. They are separated into commonly used scenarios, or topologies.

Each of the supported topologies are listed below, with an example on how to deploy them.

AWS

kOps supports the following topologies on AWS

Topology	Value	Description
Public Cluster	public	All masters/nodes will be launched in a public subnet in the VPC
Private Cluster	private	All masters/nodes will be launched in a private subnet in the VPC

More information on Public and Private subnets in AWS

Notes on subnets

If a subnet’s traffic is routed to an Internet gateway, the subnet is known as a public subnet.

If a subnet doesn’t have a route to the Internet gateway, the subnet is known as a private subnet.

Private topologies will have public access via the Kubernetes API and an (optional) SSH bastion instance.

To specify a topology use the --topology or -t flag as in :

kops create cluster ... --topology public|private

In the case of a private cluster you must also set a networking option other than kubenet. Currently the supported options are:

More information about networking options can be found in our documentation.

To change the ELB that fronts the API server from Internet facing to Internal only there are a few steps to accomplish

The AWS ELB does not support changing from internet facing to Internal. However what we can do is have kOps recreate the ELB for us.

Edit the cluster: kops edit cluster $NAME
Change the api load balancer type from: Public to Internal… should look like this when done:
```
 spec:
    api:
      loadBalancer:
        type: Internal
```
Quit the edit
Run the update command to check the config: kops update cluster $NAME
BEFORE DOING the same command with the --yes option go into the AWS console and DELETE the api ELB
Now run: kops update cluster $NAME --yes
Finally execute a rolling update so that the instances register with the new internal ELB, execute: kops rolling-update cluster --cloudonly --force command. We have to use the --cloudonly option because we deleted the api ELB so there is no way to talk to the cluster through the k8s api. The force option is there because kOps / terraform doesn’t know that we need to update the instances with the ELB so we have to force it. Once the rolling update has completed you have an internal only ELB that has the master k8s nodes registered with it.