Kubernetes now available on Nectar!

We’ve just deploy OpenStack Magnum (Container Infrastructure as a Service) on Nectar cloud. This allows a user to spin up a container cluster (kubernetes or docker swarm) on Nectar.
We are in the process of coming out with official documentation, but in the meantime if you would like to test drive it, here are the steps to do so.
First of all, you need the following
  1. Quotas for
    • Floating IP
    • Network
    • Subnet
    If you have requested for floating IPs for your project, you will be fine. If not, request for floating ip quota.

Creating a Cluster

You can create a cluster using either the Dashboard or CLI tools.

Using Dashboard

  1. Log on to the dashboard
  2. Navigate to Container Infra.
  3. Click on Clusters, then Create Cluster.
  4. Give your cluster a name.
  5. Choose a cluster template. We have pre-defined global templates (in format kubernetes-{az}) to help you get started easier. Choose the template that you want your cluster to be in.
  6. Go to the Misc tab, and select your Keypair.
  7. Click Submit.

Using CLI

  1. Install python-magnumclient. You need python-magnumclient >= 2.9.0
    pip install python-magnumclient
  2. Create a template
    openstack coe cluster template create --coe kubernetes \
--image fedora-atomic-latest --external-network <floating-ip-network-id> \
--master-flavor m2.xsmall --flavor m2.small --dns-nameserver 172.26.21.141 \
--docker-storage-driver overlay --public mytemplate
  3. Boot a cluster
    openstack coe cluster create --cluster-template mytemplate \
--keypair <mykey> mycluster

Operating your Cluster

Once your cluster is up (NOTE: It takes about 20 mins for a cluster to build), you can control it using kubectl.
  2. Set up the credentials to connect to the cluster. Firstly, create an config dir
    mkdir ~/kubernetes/
cd ~/kubernetes/
  3. Create the config files
    openstack coe cluster config mycluster
  4. Set the ENV by copying the output from the previous command
    export KUBECONFIG=$HOME/kubernetes/config
  5. Use kubectl to connect to it
    kubectl get all
Please send feedback!

Comments

Post a Comment

Popular posts from this blog

Getting capacity and usage information out of Openstack Placement

Image
One of the problems we have in Nectar is reporting on capacity and usage of nova. We have ~1000 compute nodes and these come and go. The Openstack Placement service seems like a good place to extract capacity and usage information from nova so I thought I'd see what it could do. First problem is there is no placement client. I found the osc-placment project but this isn't that useful as it is just an openstack client plugin and not a python library like the other clients. I've written a custom client before for an internal project so I created a very simple client that can get resource provider usage and capacity. In placement a resource provider maps directly to a compute node in nova. Now we have the means to query this information I wrote a custom Ceilometer poller to collect this information periodically. Once this was collecting data I needed to configure Ceilometer and Gnocchi to ingest the notifications that my new poller was generating. In Ceilometer I ne...
Read more

Understanding telemetry services in Nectar cloud

Intro Openstack telemetry service is to reliably collect data on the utilization of the physical and virtual resources comprising deployed clouds, persist these data for subsequent retrieval and analysis, and trigger actions when defined criteria are met.  Ceilometer project was the only piece of telemetry services in openstack, but since it was dumped into too many functions, it got split into several subprojects: Aodh (alarm evaluation functionality), Panko (events storage) and Ceilometer (data collection - more about ceilometer  history  from ex-PTL). The original storage and API function of ceilometer had been deprecated and moved to the other projects. The latest telemetry architecture could refer to openstack  system architecture . In Nectar cloud, we are using the Ceilometer for the metric data collection, Aodh for the alarm services, Gnocchi for the metric API services, and Influxdb as the time series database backend of Gnocchi. Influxdb backend drive...
Read more