diff options
Diffstat (limited to 'docs/OOM User Guide')
| -rw-r--r-- | docs/OOM User Guide/oom_user_guide.rst | 956 |
1 files changed, 0 insertions, 956 deletions
diff --git a/docs/OOM User Guide/oom_user_guide.rst b/docs/OOM User Guide/oom_user_guide.rst deleted file mode 100644 index 00ebccbfa3..0000000000 --- a/docs/OOM User Guide/oom_user_guide.rst +++ /dev/null @@ -1,956 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -OOM User Guide -############## -.. contents:: - :depth: 3 -.. - -Introduction -============ - -The ONAP Operations Manager (OOM) is responsible for life-cycle -management of the ONAP platform itself; components such as SO, SDNC, -etc. It is not responsible for the management of services, VNFs or -infrastructure instantiated by ONAP or used by ONAP to host such -services or VNFs. OOM uses the open source Kubernetes container -management system as a means to manage the Docker containers that -compose ONAP where the containers are hosted either directly on -bare-metal servers or on VMs hosted by a 3rd party management system. -OOM ensures that ONAP is easily deployable and maintainable throughout -its life cycle while using hardware resources efficiently. There are two -deployment options for OOM: - -- *A minimal deployment* where single instances of the ONAP components - are instantiated with no resource reservations, and - -- | *A production deployment* where ONAP components are deployed with - redundancy and anti-affinity rules such that single faults do not - interrupt ONAP operation. - | When deployed as containers directly on bare-metal, the minimal - deployment option requires a single host (32GB memory with 12 - vCPUs) however further optimization should allow this deployment to - target a laptop computer. Production deployments will require more - resources as determined by anti-affinity and geo-redundancy - requirements. - -**OOM deployments of ONAP provide many benefits:** - -- *Life-cycle management*. Kubernetes is a comprehensive system for - managing the life-cycle of containerized applications. Its use as a - platform manager will ease the deployment of ONAP, provide fault - tolerance and horizontal scalability, and enable seamless upgrades. - -- *Hardware Efficiency*. ONAP can be deployed on a single host using less - than 32GB of memory. As opposed to VMs that require a guest operating - system be deployed along with the application, containers provide - similar application encapsulation with neither the computing, memory - and storage overhead nor the associated long term support costs of - those guest operating systems. An informal goal of the project is to - be able to create a development deployment of ONAP that can be hosted - on a laptop. - -- *Rapid deployment*. With locally cached images, ONAP can be deployed from - scratch in 7 minutes. Eliminating the guest operating system results - in containers coming into service much faster than a VM equivalent. - This advantage can be particularly useful for ONAP where rapid - reaction to inevitable failures will be critical in production - environments. - -- *Portability*. OOM takes advantage of Kubernetes' ability to be hosted - on multiple hosted cloud solutions like Google Compute Engine, AWS - EC2, Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more. - -- *Minimal impact*. As ONAP is already deployed with Docker containers - minimal changes are required to the components themselves when - deployed with OOM. - -**Features of OOM:** - -- *Platform Deployment*. Automated deployment/un-deployment of ONAP - instance(s) / automated deployment/un-deployment of individual - platform components using Docker containers & Kubernetes. - -- *Platform Monitoring & Healing*. Monitor platform state, platform health - checks, fault tolerance and self-healing using Docker containers & - Kubernetes. - -- *Platform Scaling*. Platform horizontal scalability through using Docker - containers & Kubernetes. - -- *Platform Upgrades*. Platform upgrades using Docker containers & - Kubernetes. - -- *Platform Configurations*. Manage overall platform components - configurations using Docker containers & Kubernetes. - -- | *Platform migrations*. Manage migration of platform components using - Docker containers & Kubernetes. - | Please note that the ONAP Operations Manager does not provide - support for containerization of services or VNFs that are managed - by ONAP; the OOM orchestrates the life-cycle of the ONAP platform - components themselves. - -Container Background --------------------- - -Linux containers allow for an application and all of its operating -system dependencies to be packaged and deployed as a single unit without -including a guest operating system as done with virtual machines. The -most popular container solution -is \ `Docker <https://www.docker.com/>`__ which provides tools for -container management like the Docker Host (dockerd) which can create, -run, stop, move, or delete a container. Docker has a very popular -registry of containers images that can be used by any Docker system; -however, in the ONAP context, Docker images are built by the standard -CI/CD flow and stored -in \ `Nexus <https://nexus.onap.org/#welcome>`__ repositories. OOM uses -the "standard" ONAP docker containers and three new ones specifically -created for OOM. - -Containers are isolated from each other primarily via name spaces within -the Linux kernel without the need for multiple guest operating systems. -As such, multiple containers can be deployed with little overhead such -as all of ONAP can be deployed on a single host. With some optimization -of the ONAP components (e.g. elimination of redundant database -instances) it may be possible to deploy ONAP on a single laptop -computer. - -Life Cycle Management via Kubernetes -==================================== - -As with the VNFs deployed by ONAP, the components of ONAP have their own -life-cycle where the components are created, run, healed, scaled, -stopped and deleted. These life-cycle operations are managed by -the \ `Kubernetes <https://kubernetes.io/>`__ container management -system which maintains the desired state of the container system as -described by one or more deployment descriptors - similar in concept to -OpenStack Heat Orchestration Templates. The following sections describe -the fundamental objects managed by Kubernetes, the network these -components use to communicate with each other and other entities outside -of ONAP and the templates that describe the configuration and desired -state of the ONAP components. - -ONAP Components to Kubernetes Object Relationships --------------------------------------------------- - -Kubernetes deployments consist of multiple objects: - -- nodes - a worker machine - either physical or virtual - that hosts - multiple containers managed by Kubernetes. - -- services - an abstraction of a logical set of pods that provide a - micro-service. - -- pods - one or more (but typically one) container(s) that provide - specific application functionality. - -- persistent volumes - One or more permanent volumes need to be - established to hold non-ephemeral configuration and state data. - -The relationship between these objects is shown in the following figure: - -.. figure:: ../kubernetes_objects.png - -OOM uses these Kubernetes objects as described in the following -sections. - -Nodes -~~~~~ - -OOM works with both physical and virtual worker machines. - -- Virtual Machine Deployments - If ONAP is to be deployed onto a set of - virtual machines, the creation of the VMs is outside of the scope of - OOM and could be done in many ways, such as: - - - manually, for example by a user using the OpenStack Horizon - dashboard or `AWS - EC2 <https://wiki.onap.org/display/DW/ONAP+on+AWS#ONAPonAWS-Option0:DeployOOMKubernetestoaspotVM>`__, - or - - - automatically, for example with the use of a OpenStack Heat - Orchestration Template which builds an ONAP stack, or - - - orchestrated, for example with Cloudify creating the VMs from a - TOSCA template and controlling their life cycle for the life of - the ONAP deployment. - -- Physical Machine Deployments - If ONAP is to be deployed onto - physical machines there are several options but the recommendation is - to use - `Rancher <http://rancher.com/docs/rancher/v1.6/en/quick-start-guide/>`__ - along with `Helm <https://github.com/kubernetes/helm/releases>`__ to - associate hosts with a Kubernetes cluster. - -Pods -~~~~ - -A group of containers with shared storage and networking can be grouped -together into a Kubernetes pod. All of the containers within a pod are -co-located and co-scheduled so they operate as a single unit. Within -ONAP Amsterdam release, pods are mapped one-to-one to Docker containers -although this may change in the future. As explained in the Services -section below the use of Pods within each ONAP component is abstracted -from other ONAP components. - -Services -~~~~~~~~ - -OOM uses the Kubernetes service abstraction to provide a consistent -access point for each of the ONAP components independent of the pod or -container architecture of that component. For example, the SDNC -component may introduce OpenDaylight clustering as some point and change -the number of pods in this component to three or more but this change -will be isolated from the other ONAP components by the service -abstraction. A service can include a load balancer on its ingress to -distribute traffic between the pods and even react to dynamic changes in -the number of pods if they are part of a replica set (see the MSO -example below for a brief explanation of replica sets). - -Persistent Volumes -~~~~~~~~~~~~~~~~~~ - -As pods and containers are ephemeral, any data that must be persisted -across pod restart events needs to be stored outside of the pod in a -persistent volume(s). Kubernetes supports a wide variety of types of -persistent volumes such as: Fibre Channel, NFS, iSCSI, CephFS, and -GlusterFS (for a full list look -`here <https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes>`__) -so there are many options as to how storage is configured when deploying -ONAP via OOM. - -OOM Networking with Kubernetes ------------------------------- - -- DNS - -- Ports - Flattening the containers also expose port conflicts between - the containers which need to be resolved. - -Name Spaces -~~~~~~~~~~~ - -Within the namespaces are Kubernete's services that provide external -connectivity to pods that host Docker containers. The following is a -list of the namespaces and the services within: - -- onap-aai - - - aai-service - - - *hbase* - - - model-loader-service - - - aai-resources - - - aai-traversal - - - data-router - - - elasticsearch - - - gremlin - - - search-data-service - - - sparky-be - -- onap-appc - - - appc - - - *appc-dbhost* - - - appc-dgbuilder - -- clamp - - - clamp - - - clamp-mariadb - - -- onap-dcae - - - cdap0 - - - cdap1 - - - cdap2 - - - dcae-collector-common-event - - - dcae-collector-dmaapbc - - - dcae-controller - - - dcae-pgaas - - - dmaap - - - kafka - - - zookeeper - -- onap-message-router - - - dmaap - - - *global-kafka* - - - *zookeeper* - -- onap-mso - - - mso - - - *mariadb* - -- onap-multicloud - - - multicloud-vio - - - framework - -- onap-policy - - - brmsgw - - - drools - - - *mariadb* - - - *nexus* - - - pap - - - pdp - -- onap-portal - - - portalapps - - - *portaldb* - - - portalwidgets - - - vnc-portal - -- onap-robot - - - robot - -- onap-sdc - - - sdc-be - - - *sdc-cs* - - - *sdc-es* - - - sdc-fe - - - *sdc-kb* - -- onap-sdnc - - - sdnc - - - *sdnc-dbhost* - - - sdnc-dgbuilder - - - sdnc-portal - -- onap-vid - - - *vid-mariadb* - - - vid-server - -Note that services listed in \ *italics* are local to the namespace -itself and not accessible from outside of the namespace. - -Kubernetes Deployment Specifications for ONAP ---------------------------------------------- - -Each of the ONAP components are deployed as described in a deployment -specification. This specification documents key parameters and -dependencies between the pods of an ONAP components such that Kubernetes -is able to repeatably startup the component. The components artifacts -are stored here in the oom/kubernetes repo in \ `ONAP -gerrit <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes;h=4597d09dbce86d7543174924322435c30cb5b0ee;hb=refs/heads/master>`__. -The mso project is a relatively simple example, so let's start there. - -MSO Example -~~~~~~~~~~~ - -Within -the \ `oom/kubernetes/templates/mso <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/templates/mso;h=d8b778a16381d6695f635c14b9dcab72fb9fcfcd;hb=refs/heads/master>`__ repo, -one will find four files in yaml format: - -- `all-services.yaml <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob_plain;f=kubernetes/mso/templates/all-services.yaml;hb=refs/heads/master>`__ - -- `db-deployment.yaml <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob_plain;f=kubernetes/mso/templates/db-deployment.yaml;hb=refs/heads/master>`__ - -- `mso-deployment.yaml <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob_plain;f=kubernetes/mso/templates/db-deployment.yaml;hb=refs/heads/master>`__ - -- `mso-pv-pvc.yaml <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob_plain;f=kubernetes/mso/templates/mso-pv-pvc.yaml;hb=refs/heads/master>`__ - -The db-deployment.yaml file describes deployment of the database -component of mso. Here is the contents: - -**db-deployment.yaml**:: - - apiVersion: extensions/v1beta1 - kind: Deployment - metadata: - name: mariadb - namespace: "{{ .Values.nsPrefix }}-mso" - spec: - replicas: 1 - selector: - matchLabels: - app: mariadb - template: - metadata: - labels: - app: mariadb - name: mariadb - spec: - hostname: mariadb - containers: - - args: - image: {{ .Values.image.mariadb }} - imagePullPolicy: {{ .Values.pullPolicy }} - name: "mariadb" - env: - - name: MYSQL_ROOT_PASSWORD - value: password - - name: MARIADB_MAJOR - value: "10.1" - - name: MARIADB_VERSION - value: "10.1.11+maria-1~jessie" - volumeMounts: - - mountPath: /etc/localtime - name: localtime - readOnly: true - - mountPath: /etc/mysql/conf.d - name: mso-mariadb-conf - - mountPath: /docker-entrypoint-initdb.d - name: mso-mariadb-docker-entrypoint-initdb - - mountPath: /var/lib/mysql - name: mso-mariadb-data - ports: - - containerPort: 3306 - name: mariadb - readinessProbe: - tcpSocket: - port: 3306 - initialDelaySeconds: 5 - periodSeconds: 10 - volumes: - - name: localtime - hostPath: - path: /etc/localtime - - name: mso-mariadb-conf - hostPath: - path: /dockerdata-nfs/{{ .Values.nsPrefix }}/mso/mariadb/conf.d - - name: mso-mariadb-docker-entrypoint-initdb - hostPath: - path: /dockerdata-nfs/{{ .Values.nsPrefix }}/mso/mariadb/docker-entrypoint-initdb.d - - name: mso-mariadb-data - persistentVolumeClaim: - claimName: mso-db - imagePullSecrets: - - name: "{{ .Values.nsPrefix }}-docker-registry-key" - - -The first part of the yaml file simply states that this is a deployment -specification for a mariadb pod. - -The spec section starts off with 'replicas: 1' which states that only 1 -'replica' will be use here. If one was to change the number of replicas -to 3 for example, Kubernetes would attempt to ensure that three replicas -of this pod are operational at all times. One can see that in a -clustered environment the number of replicas should probably be more -than 1 but for simple deployments 1 is sufficient. - -The selector label is a grouping primitive of Kubernetes but this simple -example doesn't exercise it's full capabilities. - -The template/spec section is where the key information required to start -this pod is found. - -- image: is a reference to the location of the Docker image in nexus3 - -- name: is the name of the Docker image - -- env is a section supports the creation of operating system - environment variables within the container and are specified as a set - of key/value pairs. For example, MYSQL\_ROOT\_PASSWORD is set to - "password". - -- volumeMounts: allow for the creation of custom mount points - -- ports: define the networking ports that will be opened on the - container. Note that further in the all-services.yaml file ports - that are defined here can be exposed outside of ONAP component's name - space by creating a 'nodePort' - a mechanism used to resolve port - duplication. - -- readinessProbe: is the mechanism Kubernetes uses to determine the - state of the container. - -- volumes: a location to define volumes required by the container, in - this case configuration and initialization information. - -- imagePullSecrets: an key to access the nexus3 repo when pulling - Docker containers. - -As one might image, the mso-deployment.yaml file describes the -deployment artifacts of the mso application. Here are the contents: - -**mso-deployment.yaml**:: - - apiVersion: extensions/v1beta1 - kind: Deployment - metadata: - name: mso - namespace: "{{ .Values.nsPrefix }}-mso" - spec: - replicas: 1 - selector: - matchLabels: - app: mso - template: - metadata: - labels: - app: mso - name: mso - annotations: - pod.beta.kubernetes.io/init-containers: '[ - { - "args": [ - "--container-name", - "mariadb" - ], - "command": [ - "/root/ready.py" - ], - "env": [ - { - "name": "NAMESPACE", - "valueFrom": { - "fieldRef": { - "apiVersion": "v1", - "fieldPath": "metadata.namespace" - } - } - } - ], - "image": "{{ .Values.image.readiness }}", - "imagePullPolicy": "{{ .Values.pullPolicy }}", - "name": "mso-readiness" - } - ]' - spec: - containers: - - command: - - /docker-files/scripts/start-jboss-server.sh - image: {{ .Values.image.mso }} - imagePullPolicy: {{ .Values.pullPolicy }} - name: mso - volumeMounts: - - mountPath: /etc/localtime - name: localtime - readOnly: true - - mountPath: /shared - name: mso - - mountPath: /docker-files - name: mso-docker-files - env: - - name: JBOSS_DEBUG - value: "false" - ports: - - containerPort: 3904 - - containerPort: 3905 - - containerPort: 8080 - - containerPort: 9990 - - containerPort: 8787 - readinessProbe: - tcpSocket: - port: 8080 - initialDelaySeconds: 5 - periodSeconds: 10 - volumes: - - name: localtime - hostPath: - path: /etc/localtime - - name: mso - hostPath: - path: /dockerdata-nfs/{{ .Values.nsPrefix }}/mso/mso - - name: mso-docker-files - hostPath: - path: /dockerdata-nfs/{{ .Values.nsPrefix }}/mso/docker-files - imagePullSecrets: - - name: "{{ .Values.nsPrefix }}-docker-registry-key" - -Much like the db deployment specification the first and last part of -this yaml file describe meta-data, replicas, images, volumes, etc. The -template section has an important new functionality though, a deployment -specification for a new "initialization" container . The entire purpose -of the init-container is to allow dependencies to be resolved in an -orderly manner such that the entire ONAP system comes up every time. -Once the dependencies are met and the init-containers job is complete, -this container will terminate. Therefore, when OOM starts up ONAP one -is able to see a number of init-containers start and then disappear as -the system stabilizes. Note that more than one init-container may be -specified, each completing before starting the next, if complex startup -relationships need to be specified. - -In this particular init-container, the command '/root/ready.py' will be -executed to determine when mariadb is ready, but this could be a simple -bash script. The image/name section describes where and how to get the -Docker image from the init-container. - -To ensure that data isn't lost when an ephemeral container undergoes -life-cycle events (like being restarted), non-volatile or persistent -volumes can be attached to the service. The following pv-pvc.yaml -file defines the persistent volume as 2 GB storage claimed by the -mso namespace. - -**pv-pvc.yaml**:: - - apiVersion: v1 - kind: PersistentVolume - metadata: - name: "{{ .Values.nsPrefix }}-mso-db" - namespace: "{{ .Values.nsPrefix }}-mso" - labels: - name: "{{ .Values.nsPrefix }}-mso-db" - spec: - capacity: - storage: 2Gi - accessModes: - - ReadWriteMany - persistentVolumeReclaimPolicy: Retain - hostPath: - path: /dockerdata-nfs/{{ .Values.nsPrefix }}/mso/mariadb/data - --- - kind: PersistentVolumeClaim - apiVersion: v1 - metadata: - name: mso-db - namespace: "{{ .Values.nsPrefix }}-mso" - spec: - accessModes: - - ReadWriteMany - resources: - requests: - storage: 2Gi - selector: - matchLabels: - name: "{{ .Values.nsPrefix }}-mso-db" - -The last of the four files is the all-services.yaml file which defines -the Kubernetes service(s) that will be exposed in this name space. Here -is the contents of the file: - -**all-services.yaml**:: - - apiVersion: v1 - kind: Service - metadata: - name: mariadb - namespace: "{{ .Values.nsPrefix }}-mso" - labels: - app: mariadb - spec: - ports: - - port: 3306 - nodePort: {{ .Values.nodePortPrefix }}52 - selector: - app: mariadb - type: NodePort - --- - apiVersion: v1 - kind: Service - metadata: - name: mso - namespace: "{{ .Values.nsPrefix }}-mso" - labels: - app: mso - annotations: - msb.onap.org/service-info: '[ - { - "serviceName": "so", - "version": "v1", - "url": "/ecomp/mso/infra", - "protocol": "REST" - "port": "8080", - "visualRange":"1" - }, - { - "serviceName": "so-deprecated", - "version": "v1", - "url": "/ecomp/mso/infra", - "protocol": "REST" - "port": "8080", - "visualRange":"1", - "path":"/ecomp/mso/infra" - } - ]' - spec: - selector: - app: mso - ports: - - name: mso1 - port: 8080 - nodePort: {{ .Values.nodePortPrefix }}23 - - name: mso2 - port: 3904 - nodePort: {{ .Values.nodePortPrefix }}25 - - name: mso3 - port: 3905 - nodePort: {{ .Values.nodePortPrefix }}24 - - name: mso4 - port: 9990 - nodePort: {{ .Values.nodePortPrefix }}22 - - name: mso5 - port: 8787 - nodePort: {{ .Values.nodePortPrefix }}50 - type: NodePort - -First of all, note that this file is really two service specification in -a single file: the mariadb service and the mso service. In some -circumstances it may be possible to hide some of the complexity of the -containers/pods by hiding them behind a single service. - -The mariadb service specification is quite simple; other than the name -the only section of interest is the nodePort specification. When -containers require exposing ports to the world outside of a Kubernetes -namespace, there is a potential for port conflict. To resolve this -potential port conflict Kubernetes uses the concept of a nodePort that -is mapped one-to-one with a port within the namespace. In this case the -port 3306 (which was defined in the db-deployment.yaml file) is mapped -to 30252 externally thus avoiding the conflict that would have arisen -from deployment multiple mariadb containers. - -The mso service definition is largely the same as the mariadb service -with the exception that the ports are named. - -Customizing Deployment Specifications -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For each ONAP component deployed by OOM, a set of deployment -specifications are required. Use fortunately there are many examples to -use as references such that the previous -'`mso <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/mso;h=d8b778a16381d6695f635c14b9dcab72fb9fcfcd;hb=refs/heads/master>`__' -example, as well as: -`aai <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/aai;h=243ff90da714459a07fa33023e6655f5d036bfcd;hb=refs/heads/master>`__, -`appc <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/appc;h=d34eaca8a17fc28033a491d3b71aaa1e25673f9e;hb=refs/heads/master>`__, -`message-router <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/message-router;h=51fcb23fb7fbbfab277721483d01c6e3f98ca2cc;hb=refs/heads/master>`__, -`policy <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/policy;h=8c29597b23876ea2ae17dbf747f4ab1e3b955dd9;hb=refs/heads/master>`__, -`portal <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/portal;h=371db03ddef92703daa699014e8c1c9623f7994d;hb=refs/heads/master>`__, -`robot <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/robot;h=46445652d43d93dc599c5108f5c10b303a3c777b;hb=refs/heads/master>`__, -`sdc <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/sdc;h=1d59f7b5944d4604491e72d0b6def0ff3f10ba4d;hb=refs/heads/master>`__, -`sdnc <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/sdnc;h=dbaab2ebd62190edcf489b5a5f1f52992847a73a;hb=refs/heads/master>`__ -and -`vid <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/vid;h=e91788c8504f2da12c086e802e1e7e8648418c66;hb=refs/heads/master>`__. -If your components isn't already deployed by OOM, you can create your -own set of deployment specifications that can be easily added to OOM. - -Development Deployments -~~~~~~~~~~~~~~~~~~~~~~~ - -For the Amsterdam release, the deployment specifications represent a -simple simplex deployment of ONAP that may not have the robustness -typically required of a full operational deployment. Follow on releases -will enhance these deployment specifications as follows: - -- Load Balancers - Kubernetes has built in support for user defined or - simple 'ingress' load balances at the service layer to hide the - complexity of multi-pod deployments from other components. - -- Horizontal Scaling - replica sets can be used to dynamically scale - the number of pods behind a service to that of the offered load. - -- Stateless Pods - using concepts such as DBaaS (database as a service) - database technologies could be removed (where appropriate) from the - services thus moving to the 'cattle' model so common in cloud - deployments. - -Kubernetes Under-Cloud Deployments -================================== - -The automated ONAP deployment depends on a fully functional Kubernetes -environment being available prior to ONAP installation. Fortunately, -Kubenetes is supported on a wide variety of systems such as Google -Compute Engine, `AWS -EC2 <https://wiki.onap.org/display/DW/ONAP+on+AWS#ONAPonAWS-Option0:DeployOOMKubernetestoaspotVM>`__, -Microsoft Azure, CenturyLink Cloud, IBM Bluemix and more. If you're -setting up your own Kubernetes environment, please refer to \ `ONAP on -Kubernetes <file:///C:\display\DW\ONAP+on+Kubernetes>`__ for a walk -through of how to set this environment up on several platforms. - -ONAP 'OneClick' Deployment Walk-though -====================================== - -Once a Kubernetes environment is available and the deployment artifacts -have been customized for your location, ONAP is ready to be installed. - -The first step is to setup -the \ `/oom/kubernetes/config/onap-parameters.yaml <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/onap-parameters.yaml;h=7ddaf4d4c3dccf2fad515265f0da9c31ec0e64b1;hb=refs/heads/master>`__ file -with key-value pairs specific to your OpenStack environment. There is -a \ `sample <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/onap-parameters-sample.yaml;h=3a74beddbbf7f9f9ec8e5a6abaecb7cb238bd519;hb=refs/heads/master>`__\ that -may help you out or even be usable directly if you don't intend to -actually use OpenStack resources. Here is the contents of this file: - -**onap-parameters-sample.yaml**:: - - OPENSTACK_UBUNTU_14_IMAGE: "Ubuntu_14.04.5_LTS" - OPENSTACK_PUBLIC_NET_ID: "e8f51956-00dd-4425-af36-045716781ffc" - OPENSTACK_OAM_NETWORK_ID: "d4769dfb-c9e4-4f72-b3d6-1d18f4ac4ee6" - OPENSTACK_OAM_SUBNET_ID: "191f7580-acf6-4c2b-8ec0-ba7d99b3bc4e" - OPENSTACK_OAM_NETWORK_CIDR: "192.168.30.0/24" - OPENSTACK_USERNAME: "vnf_user" - OPENSTACK_API_KEY: "vnf_password" - OPENSTACK_TENANT_NAME: "vnfs" - OPENSTACK_REGION: "RegionOne" - OPENSTACK_KEYSTONE_URL: "http://1.2.3.4:5000" - OPENSTACK_FLAVOUR_MEDIUM: "m1.medium" - OPENSTACK_SERVICE_TENANT_NAME: "services" - DMAAP_TOPIC: "AUTO" - DEMO_ARTIFACTS_VERSION: "1.1.0-SNAPSHOT" - -Note that these values are required or the following steps will fail. - -In-order to be able to support multiple ONAP instances within a single -Kubernetes environment a configuration set is required. The -`createConfig.sh <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/createConfig.sh;h=f226ccae47ca6de15c1da49be4b8b6de974895ed;hb=refs/heads/master>`__ -script is used to do this. - -**createConfig.sh**:: - - > ./createConfig.sh -n onapTrial - -The bash -script \ `createAll.bash <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/oneclick/createAll.bash;h=5e5f2dc76ea7739452e757282e750638b4e3e1de;hb=refs/heads/master>`__ is -used to create an ONAP deployment with Kubernetes. It has two primary -functions: - -- Creating the namespaces used to encapsulate the ONAP components, and - -- Creating the services, pods and containers within each of these - namespaces that provide the core functionality of ONAP. - -**createAll.bash**:: - - > ./createAll.bash -n onapTrial - -Namespaces provide isolation between ONAP components as ONAP release 1.0 -contains duplicate application (e.g. mariadb) and port usage. As -such createAll.bash requires the user to enter a namespace prefix string -that can be used to separate multiple deployments of onap. The result -will be set of 10 namespaces (e.g. onapTrial-sdc, onapTrial-aai, -onapTrial-mso, onapTrial-message-router, onapTrial-robot, onapTrial-vid, -onapTrial-sdnc, onapTrial-portal, onapTrial-policy, onapTrial-appc) -being created within the Kubernetes environment. A prerequisite pod -config-init (\ `pod-config-init.yaml <https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=kubernetes/config/pod-config-init.yaml;h=b1285ce21d61815c082f6d6aa3c43d00561811c7;hb=refs/heads/master>`__) -may editing to match you environment and deployment into the default -namespace before running createAll.bash. - -Integration with MSB -==================== - -The \ `Microservices Bus -Project <https://wiki.onap.org/pages/viewpage.action?pageId=3246982>`__ provides -facilities to integrate micro-services into ONAP and therefore needs to -integrate into OOM - primarily through Consul which is the backend of -MSB service discovery. The following is a brief description of how this -integration will be done: - -A registrator to push the service endpoint info to MSB service -discovery. - -- The needed service endpoint info is put into the Kubernetes YAML file - as annotation, including service name, Protocol,version, visual - range,LB method, IP, Port,etc. - -- OOM deploy/start/restart/scale in/scale out/upgrade ONAP components - -- Registrator watch the Kubernetes event - -- When an ONAP component instance has been started/destroyed by OOM, - Registrator get the notification from Kubernetes - -- Registrator parse the service endpoint info from annotation and - register/update/unregister it to MSB service discovery - -- MSB API Gateway uses the service endpoint info for service routing - and load balancing. - -Details of the registration service API can be found at \ `Microservice -Bus API -Documentation <https://wiki.onap.org/display/DW/Microservice+Bus+API+Documentation>`__. - -How to define the service endpoints using annotation \ `ONAP Services -List#OOMIntegration <https://wiki.onap.org/display/DW/ONAP+Services+List#ONAPServicesList-OOMIntegration>`__ - -A preliminary view of the OOM-MSB integration is as follows: - -.. figure:: ../MSB-OOM-Diagram.png - -A message sequence chart of the registration process: - -.. figure:: ../MSB-OOM-MSC.png - -MSB Usage Instructions ----------------------- -MSB provides Kubernetes charts in OOM, so it can be spun up by oom oneclick command. - -Please note that Kubernetes authentication token must be set at *kubernetes/kube2msb/values.yaml* so the kube2msb registrator can get the access to watch the Kubernetes events and get service annotation by Kubernetes APIs. The token can be found in the kubectl configuration file *~/.kube/config* - -MSB and kube2msb can be spun up with all the ONAP components together, or separately using the following commands. - -**Start MSB services**:: - - createAll.bash -n onap -a msb - -**Start kube2msb registrator**:: - - createAll.bash -n onap -a kube2msb - -More details can be found here `MSB installation <http://onap.readthedocs.io/en/latest/submodules/msb/apigateway.git/docs/platform/installation.html>`__. - -FAQ (Frequently Asked Questions) -================================ - -Does OOM enable the deployment of VNFs on containers? - -- No. OOM provides a mechanism to instantiate and manage the ONAP - components themselves with containers but does not provide a - Multi-VIM capability such that VNFs can be deployed into containers. - The Multi VIM/Cloud Project may provide this functionality at some point. - -Configuration Parameters -======================== - -Configuration parameters that are specific to the ONAP deployment, for example -hard coded IP addresses, are parameterized and stored in a OOM specific -set of configuration files. - -More information about ONAP configuration can be found in the Configuration Management -section. - -References -========== - -- Docker - http://docker.com - -- Kubernetes - http://kubernetes.io - -- Helm - https://helm.sh |