Difference between revisions of "Containerizing StarlingX Infrastructure"
| (3 intermediate revisions by the same user not shown) | |||
| Line 38: | Line 38: | ||
[[File:StarlingX Initial Containerized Infrastructure.png]] | [[File:StarlingX Initial Containerized Infrastructure.png]] | ||
| − | === OpenStack services === | + | === OpenStack and other services === |
* All OpenStack services currently integrated by StarlingX are planned to be containerized | * All OpenStack services currently integrated by StarlingX are planned to be containerized | ||
** Including dependencies such as MariaDB | ** Including dependencies such as MariaDB | ||
** Pike based | ** Pike based | ||
| − | * nova-api proxy from stx-nfv will be containerized | + | *** nova-api proxy from stx-nfv will be containerized |
| + | *** nova-compute will be containerized | ||
| + | *** Neutron will be containerized | ||
| + | *** cilometer-poller will be containerized | ||
| + | ** Keystone container will run in the 'openstack' namespace for the OpenStack services only | ||
* rbd-provisioner pod: enabling pvc's from the CEPH cluster | * rbd-provisioner pod: enabling pvc's from the CEPH cluster | ||
* An instance of the Fault Management service will be containerized for alarming in OpenStack | * An instance of the Fault Management service will be containerized for alarming in OpenStack | ||
| − | * | + | * Current StarlingX compute nodes are re-purposed as Kubernetes worker nodes |
| + | * OVS-DPDK is '''not''' containerized | ||
| + | ** No Helm chart is currently available | ||
| − | |||
| − | [[File: | + | [[File:StarlingX Initial Containerized Infrastructure 2.png]] |
| − | + | == Deployment/Lifecycle Management == | |
| − | + | * OpenStack Helm to be used as a starting point | |
| + | ** Extensions are required (e.g. CentOS support) with the plan of working with the OpenStack Helm team upstream | ||
| + | ** Airship Armada to orchestrate the set of Helm charts that comprise OpenStack | ||
| + | * Extensions to the StarlingX Configuration Management service | ||
| + | ** Generation of Helm chart overrides | ||
| + | ** Kubernetes node label assignments | ||
| + | ** Upload application | ||
| + | *** Push images to local docker registry | ||
| + | *** Install Helm charts and Armada manifests | ||
| + | ** Install application | ||
| + | *** Interface with Configuration Management for override generation and invoking Armada to deploy | ||
| + | ** Update application | ||
| + | *** Allow the end user to specify overrides to particular charts and the trigger an update via Armada | ||
| − | + | == Docker Images == | |
| − | + | * The build system will have to be enhanced to generate StarlingX based Docker images for the containerized services | |
| + | * Images to be hosted on a public repository | ||
| − | + | == Containerized OpenStack Network Architecture == | |
| − | [[File: | + | * Management network for platform services only and isolated from the cluster |
| + | * OpenStack services to be exposed on the cluster network via a Kubernetes ingress controller | ||
| + | ** Demarcation point for public APIs and TLS/SSL termination | ||
| + | * NFV-VIM APIs need to be accessible from both the OAM and cluster networks | ||
| + | ** Demarcation point for public APIs and TLS/SSL termination via ha-proxy | ||
| + | * Platform services need access to several OpenStack APIs | ||
| + | ** VIM: Neutron, Nova | ||
| + | ** Sysinv: Neutron, Nova | ||
| + | * CEPH service must be accessible from the cluster network | ||
| + | |||
| + | |||
| + | [[File:Containerized OpenStack Network Architecture.png]] | ||
| + | |||
| + | == Software Updates == | ||
| + | |||
| + | * Software updates for containerized services will drive change in strategy | ||
| + | * A software update will look like the following: | ||
| + | ** A new Docker image for a service(s) to be delivered to the system | ||
| + | ** An Armada update to be invoked to update the applicable charts | ||
| + | |||
| + | == Future Phases Planned == | ||
| + | |||
| + | * Infrastructure services | ||
| + | ** Containerize the "Flock" services | ||
| + | ** Containerize OVS-DPDK | ||
| + | ** Containerize CEPH | ||
| + | * Container infrastructure | ||
| + | ** Accelerated container networking with SR-IOV and DPDK | ||
| + | ** Multi-tenancy support for containers | ||
| + | ** Support for additional container runtimes including Kata Containers | ||
Latest revision as of 18:42, 1 March 2019
Contents
Initiative
Introduction
- The first release of StarlingX provided a hardened OpenStack platform
- Evolution plan to move to a cloud native (Kubernetes) platform was presented at the Vancouver Summit
- Run the infrastructure including OpenStack services as containerized applications on Kubernetes
- Containerization work is planned to be done in phases having OpenStack and dependencies the initial focus
Container Platform
- Kubernetes master configuration on two nodes with high availability (HA)
- Run on existing StarlingX nodes
- Deployed by StarlingX system configuration
- Calico CNI plugin
- Docker runtime
- CEPH as persistent storage backend
- Leverage existing bare metal CEPH cluster
- Extend CEPH support to one- and two-node configuration
- Authentication/authorization of Kubernetes APIs with Keystone
- Local Docker image registry, authentication with Keystone
- Helm as package manager
- Airship Armada for orchestrating the deployment of multiple Helm charts (ex. OpenStack)
- Initial Kubernetes hosting environment for applications, the infrastructure including OpenStack will also be containerized
Initial Infrastructure Containerization
Overview
- The "Flock" services with the exceptions called out later are not planned to be containerized for the initial phase
- An instance of Keystone, RabbitMQ, and PostgreSQL will remain on bare metal and will be used for the "Flock" service
- An instance of Horizon will remain on bare metal for the "Flock" services only
OpenStack and other services
- All OpenStack services currently integrated by StarlingX are planned to be containerized
- Including dependencies such as MariaDB
- Pike based
- nova-api proxy from stx-nfv will be containerized
- nova-compute will be containerized
- Neutron will be containerized
- cilometer-poller will be containerized
- Keystone container will run in the 'openstack' namespace for the OpenStack services only
- rbd-provisioner pod: enabling pvc's from the CEPH cluster
- An instance of the Fault Management service will be containerized for alarming in OpenStack
- Current StarlingX compute nodes are re-purposed as Kubernetes worker nodes
- OVS-DPDK is not containerized
- No Helm chart is currently available
Deployment/Lifecycle Management
- OpenStack Helm to be used as a starting point
- Extensions are required (e.g. CentOS support) with the plan of working with the OpenStack Helm team upstream
- Airship Armada to orchestrate the set of Helm charts that comprise OpenStack
- Extensions to the StarlingX Configuration Management service
- Generation of Helm chart overrides
- Kubernetes node label assignments
- Upload application
- Push images to local docker registry
- Install Helm charts and Armada manifests
- Install application
- Interface with Configuration Management for override generation and invoking Armada to deploy
- Update application
- Allow the end user to specify overrides to particular charts and the trigger an update via Armada
Docker Images
- The build system will have to be enhanced to generate StarlingX based Docker images for the containerized services
- Images to be hosted on a public repository
Containerized OpenStack Network Architecture
- Management network for platform services only and isolated from the cluster
- OpenStack services to be exposed on the cluster network via a Kubernetes ingress controller
- Demarcation point for public APIs and TLS/SSL termination
- NFV-VIM APIs need to be accessible from both the OAM and cluster networks
- Demarcation point for public APIs and TLS/SSL termination via ha-proxy
- Platform services need access to several OpenStack APIs
- VIM: Neutron, Nova
- Sysinv: Neutron, Nova
- CEPH service must be accessible from the cluster network
Software Updates
- Software updates for containerized services will drive change in strategy
- A software update will look like the following:
- A new Docker image for a service(s) to be delivered to the system
- An Armada update to be invoked to update the applicable charts
Future Phases Planned
- Infrastructure services
- Containerize the "Flock" services
- Containerize OVS-DPDK
- Containerize CEPH
- Container infrastructure
- Accelerated container networking with SR-IOV and DPDK
- Multi-tenancy support for containers
- Support for additional container runtimes including Kata Containers
