Spec: Deploy Kolla images using Kubernetes
related blueprint kolla-kubernetes Change-Id: Ib1023787fca096d22a21c583c1ef647ccf925f00
This commit is contained in:
Ryan Hallisey
parent
7f447eb354
commit
b9e6848c53
|
|
@ -0,0 +1,352 @@
|
|||
===================================
|
||||
Deploy Kolla images with Kubernetes
|
||||
===================================
|
||||
|
||||
https://blueprints.launchpad.net/kolla/+spec/kolla-kubernetes
|
||||
|
||||
Kubernetes was evaluated by the Kolla team in the first two months of the
|
||||
project and it was found to be problematic because it did not support net=host,
|
||||
pid=host, and --privileged features in docker. Since then, it has developed
|
||||
these features [1].
|
||||
|
||||
The objective is to manage the lifecycle of containerized OpenStack services by
|
||||
using Kubernetes container managment tools in order to obtain the self-healing
|
||||
and upgrade capabilities inherent in Kubernetes.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Kubernetes
|
||||
- life-cycle management: service monitoring, HA, loadbalancing, and
|
||||
health checks
|
||||
- upgrades: rolling
|
||||
|
||||
Kubernetes has services that provide kolla-kubernetes with service monitoring,
|
||||
health checks, service scaling, and upgrades. The community can use the
|
||||
scheduler and node affinity trait to assign work loads to appropriate nodes [2].
|
||||
Kubernetes also has built in health checks that monitors a container's status.
|
||||
Finally, kolla-kubernetes can use the replication controller to scale up and
|
||||
down the stack [3].
|
||||
|
||||
For upgrades, Kubernetes has an object called 'deployments'[4], which detects
|
||||
when a pod needs to change. It starts to scale down the current running
|
||||
pods and scale up the new pods.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
- Kubernetes as an underlay for OpenStack.
|
||||
- Kubernetes to handle container scheduling.
|
||||
- Feedback loop when using Kubernetes health checks during deployment and
|
||||
upgrade.
|
||||
- High Availability for individual containers
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
- Add a deployment specific git repo (kolla-kubernetes) under the kolla
|
||||
governance that contains the Kubernetes deployment code.
|
||||
|
||||
Orchestration
|
||||
-------------
|
||||
|
||||
OpenStack on Kubernetes will be orchestrated by outside tools in order to create
|
||||
a production ready OpenStack environment. The kolla-kubernetes repo is where
|
||||
any deployment tool can join the community and be a part of orchestrating a
|
||||
kolla-kubernetes deployment.
|
||||
|
||||
Service Config Management
|
||||
-------------------------
|
||||
|
||||
Config generation will be completely decoupled from the deployment. The
|
||||
containers only expect a config file to land in a specific directory in
|
||||
the container in order to run. With this decoupled model, any tool could be
|
||||
used to generate config files. The kolla-kubernetes community will evaluate
|
||||
any config generation tool, but will likely use Ansible for config generation
|
||||
in order to reuse existing work from the community. This solution uses
|
||||
customized Ansible and jinja2 templates to generate the config. Also, there will
|
||||
be a maintained set of defaults and a global yaml file that can override the
|
||||
defaults.
|
||||
|
||||
The config files will be injected into the kubernetes configmap and loaded into
|
||||
the containers. There will be one configmap per configuration file and there can
|
||||
be multiple config maps. The containers will configure themselves using the
|
||||
configuration files loaded into the appropriate directories [5][6].
|
||||
|
||||
Bootstrapping
|
||||
-------------
|
||||
|
||||
Bootstrapping the Kolla containers involves running a single task per service
|
||||
that will initialize the databases and create the users. The bootstrapping task
|
||||
will be a Kubernetes Job, which will run the task until completion then
|
||||
terminate the pods [7].
|
||||
|
||||
Each service will have a bootstrap task so that when the operator upgrades,
|
||||
the bootstrap tasks are reused to upgrade the database. This will allow
|
||||
deployment and upgrades to follow the same pipeline.
|
||||
|
||||
The Kolla containers will communicate with the Kubernetes API server to in order
|
||||
to be self aware of if any bootstrapping processes are occuring.
|
||||
|
||||
Alternative bootstrap approaches:
|
||||
|
||||
1) Create 2 pods per OpenStack service. One pod is designed to do the
|
||||
bootstrapping/db_sync while the other pod runs as the normal service. This will
|
||||
require some orchestration and the bootstrap pod will need to be setup to
|
||||
never restart or be replicated.
|
||||
|
||||
2) Use a sidecar container in the pod to handle the database sync with proper
|
||||
health checking to make sure the services are coming up healthy. The big
|
||||
difference between kolla's old docker-compose solution and Kubernetes, is that
|
||||
docker-compose would only restart the containers. Kubernetes will completely
|
||||
reschedule them. Which means, removing the pod and restarting it. The reason
|
||||
this would fix that race condition failure kolla saw from docker-compose is
|
||||
because glance would be rescheduled on failure allowing keystone to get a
|
||||
chance to sync with the database and become active instead of constantly being
|
||||
piled with glance requests. There can also be health checks around this to help
|
||||
determine order.
|
||||
|
||||
If kolla-kubernetes used this sidecar approach, it would regain the use of
|
||||
native Kubernetes upgrades [16].
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
- Kubernetes >= 1.3.0
|
||||
- Docker >= 1.10.0
|
||||
- Jinja2 >= 2.8.0
|
||||
|
||||
Kubernetes does not support dependencies between pods. The operator will launch
|
||||
all the services and use kubernetes health checks to bring the deployment to an
|
||||
operational state.
|
||||
|
||||
With orchestration around Kubernetes, the operator can determine what tasks are
|
||||
run and when the tasks are run. This way, dependencies are handled at the
|
||||
orchestration level, but they are not required because proper health checking
|
||||
will bring up the cluster in a healthy state.
|
||||
|
||||
Upgrades
|
||||
--------
|
||||
|
||||
Kubernetes has an object called a Deployment, where the operator defines a
|
||||
desired state for the pods and the deployment will move the cluster to the
|
||||
desired state when a change is detected.
|
||||
|
||||
Kolla-kubernetes will provide Jobs that will provide the operator with the
|
||||
flexibility needed to under go a step wise upgrade. In future releases,
|
||||
kolla-kubernetes will look to Kubernetes to provide a means for operators to
|
||||
plugin these jobs into a Deployment.
|
||||
|
||||
Reconfigure
|
||||
-----------
|
||||
|
||||
The operator generates a new config and loads it into the Kubernetes configmap
|
||||
by changing the configmap version in the service yaml file. Then, the operator
|
||||
will trigger a rolling upgrade, which will scale down old pods and bring up new
|
||||
ones that will run with the updated configuration files.
|
||||
|
||||
There's an open issue upstream in Kubernetes where the plan is to add support
|
||||
around detecting if a pod has a changed in the configmap [6]. Depending on what
|
||||
the solution is, kolla-kubernetes may or may not use it. The rolling
|
||||
upgrade feature will provide kolla-kubernetes with an elegant way to handle
|
||||
restarting the services.
|
||||
|
||||
HA Architecture
|
||||
---------------
|
||||
|
||||
Kubernetes uses health checks to bring up the services. Therefore,
|
||||
kolla-kubernetes will use the same checks when monitoring if a service is
|
||||
healthy. When a service fails, the replication controller will be responsible
|
||||
for bringing up a new container in its place [8][9].
|
||||
|
||||
However, Kubernetes does not cover all the HA corner cases, for instance,
|
||||
fencing. But, there are some operator known practices that can be used to get
|
||||
around this [10]. For example, to implement storage fencing, the operator can
|
||||
use ceph backed storage [11][12]. This is an option that the community can
|
||||
document in order to provide kolla-kubernetes with a production ready solution
|
||||
if Kubernetes cannot.
|
||||
|
||||
.. note:: There is a known issue in Kubernetes with releasing volumes from a
|
||||
node that disappeared from the cluster. This is expected to be fixed in the 1.3
|
||||
release [13].
|
||||
|
||||
Persistent Storage
|
||||
------------------
|
||||
|
||||
Kubernetes has many types of persistent storage [14]. Since Kubernetes doesn't
|
||||
guarantee a pod will always be scheduled to a host, it makes node based
|
||||
persistent storage unlikely, unless the community uses labels for every pod.
|
||||
|
||||
Persistent storage in kolla-kubernetes will come from volumes backed by
|
||||
different storage offerings to provide persistent storage. Kolla-kubernetes
|
||||
will provide a default solution using Ceph RBD, that the community will use to
|
||||
deploy multinode with. From there, kolla-kubernetes can add any additional
|
||||
persistent storage options as well as support options for the operator to
|
||||
reference an existing storage solution.
|
||||
|
||||
To deploy Ceph, the community will use the Ansible playbooks from Kolla to
|
||||
deploy a containerized Ceph at least for the 1.0 release. After Kubernetes
|
||||
deployment matures, the community can evaluate building its own Ceph deployment
|
||||
solution.
|
||||
|
||||
Existing external Ceph deployments will require additional documentation
|
||||
to describe how to integrate them with a Kubernetes deployment.
|
||||
|
||||
Service Roles
|
||||
-------------
|
||||
|
||||
At the broadest level, OpenStack can split up into two main roles, Controller
|
||||
and Compute. With Kubernetes, the role definition layer changes.
|
||||
Kolla-kubernetes will still need to define Compute nodes, but not Controller
|
||||
nodes. Compute nodes hold the libvirt container and the running vms. That
|
||||
service cannont migrate because the vms associated with it exist on the node.
|
||||
However, the Controller role is more flexible. The Kubernetes layer provides IP
|
||||
persistence so that APIs will remain active and abstracted from the operator's
|
||||
view [15]. kolla-kubernetes can direct Controller services away from the Compute
|
||||
node using labels, while managing Compute services more strictly.
|
||||
|
||||
The Kubernetes Label field will be configurable to allow the operator to
|
||||
define roles and direct where services will land.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Kolla-Kubernetes will run the containers as non root wherever possible.
|
||||
SELinux or AppArmor will be in place to limit the damage from container
|
||||
breakouts.
|
||||
|
||||
Kubernetes is planning to adding capabilities to the pod level that will enable
|
||||
the community to restrict container privileges even further [16].
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Since kolla-kubernetes is not using dependencies for the service deployment, the
|
||||
services will take a different amount of time to start up for each deployment
|
||||
because the order will always vary when the services become active.
|
||||
As such, it's hard to quantify the exact performance impact other than it is
|
||||
small.
|
||||
|
||||
Networking
|
||||
----------
|
||||
|
||||
Kolla-kubernetes will initially use 'net=host' everywhere to get the project
|
||||
going. As the project matures, 'net=host' needs to be reevaluated as to which
|
||||
services will run without 'net=host' in order to gain additional functionality.
|
||||
For example, controller services will float between nodes potentially landing
|
||||
two of the same pods on the same node. Those pods will be listening on the same
|
||||
ports in the hosts network stack, which could prevent the pods from working.
|
||||
|
||||
Logging & Monitoring
|
||||
--------------------
|
||||
|
||||
To reuse Kolla's containers, kolla-kubernetes will use elastic search, heka, and
|
||||
kibana as the default logging mechanism.
|
||||
|
||||
The community will implement centralized logging by using a 'side car' container
|
||||
in the Kubernetes pod [17]. The logging service will trace the logs from the
|
||||
shared volume of the running serivce and send the data to elastic search. This
|
||||
solution is ideal because volumes are shared amoung the containers in a pod.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Primary Assignee(s)
|
||||
-----------
|
||||
Ryan Hallisey (rhallisey)
|
||||
|
||||
Other contributor(s):
|
||||
kolla-core team [18]
|
||||
Alex Polvi (polvi)
|
||||
Andrew Battye
|
||||
Brandon Jozsa (v1k0d3n)
|
||||
Britt Houser (britthouser)
|
||||
Davanum Srinivas (dims)
|
||||
David Wang (dcwangmit01)
|
||||
Egor Guz (eghobo)
|
||||
Greg Herlein (gherlein)
|
||||
Hui Kang (huikang)
|
||||
Ian Main (Slower)
|
||||
Jinay Vora (jvora)
|
||||
Keith Byrne (kbyrne)
|
||||
Ken Wronkiewicz (wirehead)
|
||||
Kevin Fox (kfox1111)
|
||||
Marga Millet (fragatina)
|
||||
Marian Schwarz
|
||||
Mark Casey (mark-casey)
|
||||
Mauricio Lima (mlima)
|
||||
Md Nadeem (mail2nadeem92)
|
||||
Michael Schmidt
|
||||
Michal Rostecki (mrostecki)
|
||||
Qiu Yu (unicell)
|
||||
Rajath Agasthya (rajathagasthya)
|
||||
Rob Mason
|
||||
Sean Mooney (sean-k-mooney)
|
||||
Serguei Bezverkhi (sbezverk)
|
||||
Sidharth Surana (ssurana)
|
||||
Zdenek Janda (xdeu)
|
||||
<Please add your name here if you are getting involved in kolla-kubernetes>
|
||||
|
||||
Milestones
|
||||
----------
|
||||
|
||||
Target Milestone for tech-preview code:
|
||||
Newton
|
||||
|
||||
Work Items
|
||||
----------
|
||||
1. Create kolla-kubernetes repo
|
||||
2. Build yaml files for each service
|
||||
3. Build a CLI to handle templated yaml files
|
||||
4. Build an all in one environment
|
||||
5. Drop net=host on a set of services
|
||||
6. Write per service health checks
|
||||
7. Write startup docs
|
||||
8. Add orchestration tools around the pods
|
||||
9. All in one gating
|
||||
10. Convert each service to a 'Deployment'
|
||||
11. Build multinode environment
|
||||
12. Config generation tools
|
||||
13. Multinode docs
|
||||
14. Implement reconfigure by templating configmaps
|
||||
15. Centralized logging
|
||||
16. Implement upgrades
|
||||
17. Advanced deployment docs
|
||||
<Please add new work items that are worth mentioning in the spec>
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Functional tests will be implemented in the OpenStack check/gating system to
|
||||
automatically test that the Kubernetes deployment works for an AIO
|
||||
environment [19].
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
Add a quick start guide, which explains how to deploy kolla-kubernetes.
|
||||
Add a developer guide on how to contribute which also explains how the
|
||||
deployment works.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
- [1] https://github.com/kubernetes/kubernetes/releases/tag/v1.2.0
|
||||
- [2] http://kubernetes.io/docs/user-guide/node-selection/
|
||||
- [3] http://kubernetes.io/v1.0/docs/user-guide/managing-deployments.html
|
||||
- [4] https://cloud.google.com/container-engine/docs/replicationcontrollers/
|
||||
- [5] https://github.com/kubernetes/kubernetes/blob/master/docs/design/configmap.md
|
||||
- [6] https://github.com/kubernetes/kubernetes/issues/24957
|
||||
- [7] http://kubernetes.io/docs/user-guide/jobs/
|
||||
- [8] http://kubernetes.io/docs/user-guide/replication-controller/
|
||||
- [9] http://kubernetes.io/docs/user-guide/replicasets/
|
||||
- [10] http://kubernetes.io/docs/admin/high-availability/#master-elected-components
|
||||
- [11] http://kubernetes.io/docs/user-guide/volumes/#rbd
|
||||
- [12] http://docs.ceph.com/docs/master/cephfs/eviction/
|
||||
- [13] https://github.com/kubernetes/kubernetes/issues/20262
|
||||
- [14] http://kubernetes.io/docs/user-guide/volumes/
|
||||
- [15] http://kubernetes.io/docs/user-guide/node-selection/
|
||||
- [16] https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/pod-security-context.md
|
||||
- [17] http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html
|
||||
- [18] https://review.openstack.org/#/admin/groups/460,members
|
||||
- [19] https://etherpad.openstack.org/p/kolla-newton-summit-kolla-gate-walkthru
|
||||
- https://github.com/kubernetes/kubernetes
|
||||
Loading…
Reference in New Issue