Getting Started with kOps on OpenStack

In order to deploy a kops-managed cluster on OpenStack, you need the following OpenStack services:

  • Nova (compute)
  • Neutron (networking)
  • Glance (image)
  • Cinder (block storage)

In addition, kOps can make use of the following services:

  • Swift (object store)
  • Dvelve (dns)
  • Octavia (loadbalancer)

The OpenStack version should be Ocata or newer.

Source your openstack RC

The Cloud Config used by the kubernetes API server and kubelet will be constructed from environment variables in the openstack RC file.

We recommend using when authenticating to OpenStack.

Note The authentication used locally will be exported to your cluster and used by the kubernetes controller components. You must avoid using personal credentials used for other systems,

Environment Variables

kOps stores its configuration in a state store. Before creating a cluster, we need to export the path to the state store:

If your OpenStack does not have Swift you can use any other VFS store, such as S3. See the for alternatives.

  1. # to see your etcd storage type
  2. openstack volume type list
  3. # coreos (the default) + flannel overlay cluster in Default
  4. kops create cluster \
  5. --cloud openstack \
  6. --name my-cluster.k8s.local \
  7. --state ${KOPS_STATE_STORE} \
  8. --zones nova \
  9. --network-cidr 10.0.0.0/24 \
  10. --image <imagename> \
  11. --master-count=3 \
  12. --node-count=1 \
  13. --node-size <flavorname> \
  14. --master-size <flavorname> \
  15. --etcd-storage-type <volumetype> \
  16. --api-loadbalancer-type public \
  17. --topology private \
  18. --bastion \
  19. --ssh-public-key ~/.ssh/id_rsa.pub \
  20. --networking weave \
  21. --os-ext-net <externalnetworkname>
  22. # to update a cluster
  23. kops update cluster my-cluster.k8s.local --state ${KOPS_STATE_STORE} --yes
  24. # to delete a cluster

Optional flags

  • --os-kubelet-ignore-az=true Nova and Cinder have different availability zones, more information
  • --os-octavia=true If Octavia Loadbalancer api should be used instead of old lbaas v2 api.
  • --os-dns-servers=8.8.8.8,8.8.4.4 You can define dns servers to be used in your cluster if your openstack setup does not have working dnssetup by default
  • --os-octavia-provider You can define the Octavia Loadbalancer provider to use. To get the list of providers available in your environment, run openstack loadbalancer provider list. Default: octavia.

Compute and volume zone names does not match

Some of the openstack users do not have compute zones named exactly the same than volume zones. Good example is that there are several compute zones for instance zone-1, zone-2 and zone-3. Then there is only one volumezone which is usually called nova. By default this is problem in kOps, because kOps assumes that if you are deploying things to zone-1 there should be compute and volume zone called zone-1.

Create cluster using your compute zones:

  1. kops create cluster \
  2. --zones zone-1,zone-2,zone-3 \
  3. ...

After you have initialized the configuration you need to edit configuration

Edit ignore-volume-az to true and override-volume-az according to your cinder az name.

Example (volume zone is called ):

  1. spec:
  2. cloudConfig:
  3. openstack:
  4. blockStorage:
  5. ignore-volume-az: true
  6. override-volume-az: nova

Finally execute update cluster

  1. kops update cluster my-cluster.k8s.local --state ${KOPS_STATE_STORE} --yes

kOps should create instances to all three zones, but provision volumes from the same zone.

Using external cloud controller manager

If you want use External CCM in your installation, this section contains instructions what you should do to get it up and running.

Create cluster without --yes flag (or modify existing cluster):

  1. kops edit cluster <cluster>

Add following to clusterspec:

  1. kops update cluster --name <cluster> --yes

Using OpenStack without lbaas

Some OpenStack installations does not include installation of lbaas component. To launch a cluster without a loadbalancer, run:

  1. kops create cluster \
  2. --cloud openstack \
  3. ... (like usually)
  4. --api-loadbalancer-type=""

In clusters without loadbalancer, the address of a single random master will be added to your kube config.

Using existing OpenStack network

You can have kOps reuse existing network components instead of provisioning one per cluster. As OpenStack support is still beta, we recommend you take extra care when deleting clusters and ensure that kOps do not try to remove any resources not belonging to the cluster.

Use an existing network by using --network <network id>.

If you are provisioning the cluster from a spec file, add the network ID as follows:

  1. spec:
  2. networkID: <network id>

Use existing networks

Instead of kOps creating new subnets for the cluster, you can reuse an existing subnet.

When you create a new cluster, you can specify subnets using the --subnets and --utility-subnets flags.

Example

Using with self-signed certificates in OpenStack

kOps can be configured to use insecure mode towards OpenStack. However, this is not recommended as OpenStack cloudprovider in kubernetes does not support it. If you use insecure flag in kOps it might be that the cluster does not work correctly.

  1. spec:
  2. cloudConfig:

Next steps

Now that you have a working kOps cluster, read through the to learn more about how to configure kOps for production workloads.