Skip to content

Instantly share code, notes, and snippets.

@dcwangmit01

dcwangmit01/How Kolla and Kolla-Kubernetes Work.md

Created June 15, 2016 21:29
Show Gist options
  • Save dcwangmit01/553645bc018f5bc4a36a78a5f786dee2 to your computer and use it in GitHub Desktop.
Save dcwangmit01/553645bc018f5bc4a36a78a5f786dee2 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
How Kolla and Kolla-Kubernetes Work.md

How Kolla and Kolla-Kubernetes Work

Let's consider how the mariadb kolla container is configured and run in both kolla and kolla-kubernetes, as of today 2016/06/08.

Common Steps:

  • Operator edits /etc/kolla/globals.yml and sets the interface to which API services will bind. By default, the setting is: network_interface: "eth0".
  • Operator edits the ansible inventory file within ./ansible/inventory/{inventory_file}, and sets the target hostgroups which will run the mariadb kolla container.
  • Operator runs 'kolla-ansible genconfig' which gathers networking facts on each host and resolves the 'network_interface' setting as the IP address to which the service to bind. This IP address is hard-coded within configuration files deposited on each host in the directory '/etc/kolla/{component}'.

The kolla (non-Kubernetes) process continued:

  • Upon kolla container start, the mariadb process reads the IP from which it must bind from the configs in '/etc/kolla/{component}'
  • The end result is a successful start.

The kolla-kubernetes process continued:

  • Operator executes 'kolla-kubernetes run mariadb' which loads each file from the operator's machine under '/etc/kolla/{component}' as individual configmaps, and schedules one or more pods for Kubernetes to run.
  • Kubernetes schedules the kolla mariadb container to run on one or more nodes (i.e. machines).
  • Docker on each node is successful in pulling the image, mounting the configmaps, and even starting the container, but the mariadb process fails on startup and the container dies.
  • The mariadb processes crashes because mariadb is attempting to bind to an IP in the configuration that the pod does not own. Kubernetes pods receive random routable network addresses, allocated at runtime.

Relevant Blueprints

This issue is related to sbezverk's blueprint, but not the same. They are two sides of the same coin. The difference is:

  • Sbezverk’s blueprint covers how containers discover the openstack services that other kolla containers provide.
  • This document covers how a kolla container must discover it's own IP for binding, so that it may start an openstack API process.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment