TripleO already deploys OpenStack into containers. Going forward we would like to integrate a container orchestration engine. We have been experimenting with Kubernetes and OpenShift. Let’s look at deploying vanilla Kubernetes in this blog post. We’ll deploy a Kubernetes cluster of 3 masters + 3 nodes, utilizing the TripleO composable services framework and the Kubespray installer, and drive the deployment using TripleO Quickstart.


First let’s skim through the architecture enhancement made to support external installers within the new Ansible deployment mechanism.

We now allow the composable service templates to emit external_deploy_tasks. These are Ansible tasks executed on the undercloud. They can read the full Ansible inventory of the deployment playbook when needed, which makes them fit for running complex out-of-tree (meaning out-of-tripleo-heat-templates) installers like Kubespray or Ceph-Ansible.

We had two options how to approach these external installers – either pull them in via a playbook include directly to the ansible-playbook process for overcloud deployment, or run a nested ansible-playbook subprocess (e.g. for Kubespray) from the outer ansible-playbook process. We went for the latter as it provides more control and can execute also non-Ansible installers. The summary of important differences between the approaches is in the following table:

  Playbook include Subprocess
Supported tools Ansible only Any
Inventory Inherited from outer playbook Separate, must be generated
Variables, tags Inherited from outer playbook Separate, must be generated
Progress logging Progressively each task Whole process output at once

The external_deploy_tasks are step-based, and are interleaved between the “normal” deployment steps which currently run Puppet and manage containers. This way we can decide in which particular step we want an external installer to be run. The situation is depicted (in a simplified way) in the following diagram:

Overcloud deployment workflow

Implementation for Kubespray

In Kubespray’s case specifically, we use the external_deploy_tasks to generate files needed by the Kubespray installer and then execute the installer. The files used by Kubespray that we generate are:

  • an inventory,

  • a simple playbook (including Kubespray’s cluster.yml),

  • a file with Ansible variables that configures Kubespray.

If you want to explore the code, see the service template kubernetes-master.yaml as of 20th November 2017. There’s also kubernetes-worker.yaml service template, which is just used for tagging nodes to be recognized by the inventory generator as workers, and for setting up worker node firewall rules.


Prepare the environment

The assumed starting point for deploying Kubernetes will be having a deployed undercloud with 6 virtual baremetal nodes defined and ready for use.

There are several paths to do this with TripleO Quickstart, the easiest one is probably to deploy full 3 controller + 3 compute environment using --nodes config/nodes/3ctlr_3comp.yml, and then delete the overcloud stack. If your virt host doesn’t have enough capacity for that many VMs, you can use a smaller configuration, e.g. 1ctlr_1comp.yml or just 1ctlr.yml.

For detailed information how to deploy with Quickstart, please refer to TripleO Quickstart docs.

Deploy the overcloud

Let’s prepare extra-oooq-vars.yml file. It’s a file with Quickstart variables, so it will have to be on the host where you run Quickstart. The contents will be as follows:

# use t-h-t with our cherry-picks
overcloud_templates_path: /home/stack/tripleo-heat-templates

# specify NTP server this way. Improved in
extra_tht_config_args: --ntp-server

# make validation errors non-fatal
validation_args: ''

# network config in the featureset is for CI, override it back to defaults
network_args: -e /home/stack/net-config-defaults.yaml

# deploy with config-download mechanism, we'll execute the actual
# software deployment via ansible subsequently
config_download_args: >-
  -e /home/stack/tripleo-heat-templates/environments/config-download-environment.yaml

# do not run the workflow
deploy_steps_ansible_workflow: false

And /home/stack/net-config-defaults.yaml will have to be on the undercloud, and it has these contents:

  OS::TripleO::Controller::Net::SoftwareConfig: /usr/share/openstack-tripleo-heat-templates/net-config-bridge.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /usr/share/openstack-tripleo-heat-templates/net-config-noop.yaml

Now let’s reuse the undercloud deployed previously by Quickstart, and deploy the overcloud Heat stack. This could be done with too, but personally i prefer running ansible-playbook for more direct control:

# run this where you run Quickstart (likely not the undercloud)

# VIRTHOST must point to the machine that hosts your Quickstart VMs,
# edit this if necessary
export VIRTHOST=$(hostname -f)
# WORKSPACE must point to your Quickstart workspace directory,
# edit this if necessary
export WORKSPACE=$HOME/.quickstart
source $WORKSPACE/bin/activate
export ANSIBLE_ROLES_PATH=$WORKSPACE/usr/local/share/ansible/roles:$WORKSPACE/usr/local/share/tripleo-quickstart/roles
export ANSIBLE_LIBRARY=$WORKSPACE/usr/local/share/ansible:$WORKSPACE/usr/local/share/tripleo-quickstart/library
export SSH_CONFIG=$WORKSPACE/ssh.config.ansible

ansible-playbook -v \
    -i $WORKSPACE/hosts \
    -e local_working_dir=$WORKSPACE \
    -e virthost=$VIRTHOST \
    -e @$WORKSPACE/config/release/tripleo-ci/master.yml \
    -e @$WORKSPACE/config/nodes/3ctlr_3comp.yml \
    -e @$WORKSPACE/config/general_config/featureset026.yml \
    -e @extra-oooq-vars.yml \

With the overcloud Heat stack created, we can now fetch the overcloud software config definition and deploy it with Ansible. In the future this will be neatly hidden behind CLI and WUI interface, but for now it’s another WIP feature, so we’ll take a bit more explicit approach:

# clean any previous config downloads
rm -rf ~/config-download/tripleo*

# produce Ansible playbooks from Heat stack outputs
tripleo-config-download -s overcloud -o ~/config-download

# skip this in case you want to manually check fingerprints

# deploy the software configuration of overcloud
ansible-playbook \
    -v \
    -i /usr/bin/tripleo-ansible-inventory \

This applied the software configuration, including installation of Kubernetes via Kubespray.

Hello Kubernetes in TripleO

For now it’s best to ssh to an overcloud controller node to manage Kubernetes with kubectl. External HA access to the Kubernetes API is being worked on.

After smoke testing with e.g. kubectl get nodes, you can try deploying something on the Kubernetes cluster, e.g. Use a Service to Access an Application in a Cluster tutorial from the Kubernetes docs is a nice one.