Eric Debeau | 993b77b | 2020-08-19 15:30:00 +0200 | [diff] [blame] | 1 | .. This work is licensed under a Creative Commons Attribution 4.0 |
| 2 | .. International License. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 3 | .. http://creativecommons.org/licenses/by/4.0 |
Eric Debeau | 993b77b | 2020-08-19 15:30:00 +0200 | [diff] [blame] | 4 | .. Copyright 2018-2020 Amdocs, Bell Canada, Orange, Samsung |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 5 | |
| 6 | .. Links |
| 7 | .. _Helm: https://docs.helm.sh/ |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 8 | .. _Helm Charts: https://github.com/kubernetes/charts |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 9 | .. _Kubernetes: https://Kubernetes.io/ |
| 10 | .. _Docker: https://www.docker.com/ |
Eric Debeau | c4e405f | 2020-12-07 14:49:52 +0100 | [diff] [blame] | 11 | .. _Nexus: https://nexus.onap.org/ |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 12 | .. _AWS Elastic Block Store: https://aws.amazon.com/ebs/ |
| 13 | .. _Azure File: https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction |
| 14 | .. _GCE Persistent Disk: https://cloud.google.com/compute/docs/disks/ |
| 15 | .. _Gluster FS: https://www.gluster.org/ |
| 16 | .. _Kubernetes Storage Class: https://Kubernetes.io/docs/concepts/storage/storage-classes/ |
| 17 | .. _Assigning Pods to Nodes: https://Kubernetes.io/docs/concepts/configuration/assign-pod-node/ |
| 18 | |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 19 | |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 20 | .. _developer-guide-label: |
| 21 | |
| 22 | OOM Developer Guide |
| 23 | ################### |
| 24 | |
efiacor | 1660a8c | 2022-05-03 16:24:13 +0100 | [diff] [blame^] | 25 | .. figure:: images/oom_logo/oomLogoV2-medium.png |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 26 | :align: right |
| 27 | |
| 28 | ONAP consists of a large number of components, each of which are substantial |
| 29 | projects within themselves, which results in a high degree of complexity in |
| 30 | deployment and management. To cope with this complexity the ONAP Operations |
| 31 | Manager (OOM) uses a Helm_ model of ONAP - Helm being the primary management |
| 32 | system for Kubernetes_ container systems - to drive all user driven life-cycle |
| 33 | management operations. The Helm model of ONAP is composed of a set of |
| 34 | hierarchical Helm charts that define the structure of the ONAP components and |
| 35 | the configuration of these components. These charts are fully parameterized |
| 36 | such that a single environment file defines all of the parameters needed to |
| 37 | deploy ONAP. A user of ONAP may maintain several such environment files to |
| 38 | control the deployment of ONAP in multiple environments such as development, |
| 39 | pre-production, and production. |
| 40 | |
| 41 | The following sections describe how the ONAP Helm charts are constructed. |
| 42 | |
| 43 | .. contents:: |
| 44 | :depth: 3 |
| 45 | :local: |
| 46 | .. |
| 47 | |
| 48 | Container Background |
| 49 | ==================== |
| 50 | Linux containers allow for an application and all of its operating system |
| 51 | dependencies to be packaged and deployed as a single unit without including a |
| 52 | guest operating system as done with virtual machines. The most popular |
| 53 | container solution is Docker_ which provides tools for container management |
| 54 | like the Docker Host (dockerd) which can create, run, stop, move, or delete a |
| 55 | container. Docker has a very popular registry of containers images that can be |
| 56 | used by any Docker system; however, in the ONAP context, Docker images are |
| 57 | built by the standard CI/CD flow and stored in Nexus_ repositories. OOM uses |
| 58 | the "standard" ONAP docker containers and three new ones specifically created |
| 59 | for OOM. |
| 60 | |
| 61 | Containers are isolated from each other primarily via name spaces within the |
| 62 | Linux kernel without the need for multiple guest operating systems. As such, |
| 63 | multiple containers can be deployed with little overhead such as all of ONAP |
| 64 | can be deployed on a single host. With some optimization of the ONAP components |
| 65 | (e.g. elimination of redundant database instances) it may be possible to deploy |
| 66 | ONAP on a single laptop computer. |
| 67 | |
| 68 | Helm Charts |
| 69 | =========== |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 70 | A Helm chart is a collection of files that describe a related set of Kubernetes |
| 71 | resources. A simple chart might be used to deploy something simple, like a |
| 72 | memcached pod, while a complex chart might contain many micro-service arranged |
| 73 | in a hierarchy as found in the `aai` ONAP component. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 74 | |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 75 | Charts are created as files laid out in a particular directory tree, then they |
| 76 | can be packaged into versioned archives to be deployed. There is a public |
| 77 | archive of `Helm Charts`_ on GitHub that includes many technologies applicable |
| 78 | to ONAP. Some of these charts have been used in ONAP and all of the ONAP charts |
| 79 | have been created following the guidelines provided. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 80 | |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 81 | The top level of the ONAP charts is shown below: |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 82 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 83 | .. code-block:: bash |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 84 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 85 | common |
| 86 | ├── cassandra |
| 87 | │ ├── Chart.yaml |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 88 | │ ├── resources |
| 89 | │ │ ├── config |
| 90 | │ │ │ └── docker-entrypoint.sh |
| 91 | │ │ ├── exec.py |
| 92 | │ │ └── restore.sh |
| 93 | │ ├── templates |
| 94 | │ │ ├── backup |
| 95 | │ │ │ ├── configmap.yaml |
| 96 | │ │ │ ├── cronjob.yaml |
| 97 | │ │ │ ├── pv.yaml |
| 98 | │ │ │ └── pvc.yaml |
| 99 | │ │ ├── configmap.yaml |
| 100 | │ │ ├── pv.yaml |
| 101 | │ │ ├── service.yaml |
| 102 | │ │ └── statefulset.yaml |
| 103 | │ └── values.yaml |
| 104 | ├── common |
| 105 | │ ├── Chart.yaml |
| 106 | │ ├── templates |
| 107 | │ │ ├── _createPassword.tpl |
| 108 | │ │ ├── _ingress.tpl |
| 109 | │ │ ├── _labels.tpl |
| 110 | │ │ ├── _mariadb.tpl |
| 111 | │ │ ├── _name.tpl |
| 112 | │ │ ├── _namespace.tpl |
| 113 | │ │ ├── _repository.tpl |
| 114 | │ │ ├── _resources.tpl |
| 115 | │ │ ├── _secret.yaml |
| 116 | │ │ ├── _service.tpl |
| 117 | │ │ ├── _storage.tpl |
| 118 | │ │ └── _tplValue.tpl |
| 119 | │ └── values.yaml |
| 120 | ├── ... |
| 121 | └── postgres-legacy |
| 122 | ├── Chart.yaml |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 123 | ├── charts |
| 124 | └── configs |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 125 | |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 126 | The common section of charts consists of a set of templates that assist with |
guillaume.lambert | f3319a8 | 2021-09-26 21:37:50 +0200 | [diff] [blame] | 127 | parameter substitution (`_name.tpl`, `_namespace.tpl` and others) and a set of |
| 128 | charts for components used throughout ONAP. When the common components are used |
| 129 | by other charts they are instantiated each time or we can deploy a shared |
| 130 | instances for several components. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 131 | |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 132 | All of the ONAP components have charts that follow the pattern shown below: |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 133 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 134 | .. code-block:: bash |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 135 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 136 | name-of-my-component |
| 137 | ├── Chart.yaml |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 138 | ├── component |
| 139 | │ └── subcomponent-folder |
| 140 | ├── charts |
| 141 | │ └── subchart-folder |
| 142 | ├── resources |
| 143 | │ ├── folder1 |
| 144 | │ │ ├── file1 |
| 145 | │ │ └── file2 |
| 146 | │ └── folder1 |
| 147 | │ ├── file3 |
| 148 | │ └── folder3 |
| 149 | │ └── file4 |
| 150 | ├── templates |
| 151 | │ ├── NOTES.txt |
| 152 | │ ├── configmap.yaml |
| 153 | │ ├── deployment.yaml |
| 154 | │ ├── ingress.yaml |
| 155 | │ ├── job.yaml |
| 156 | │ ├── secrets.yaml |
| 157 | │ └── service.yaml |
| 158 | └── values.yaml |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 159 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 160 | Note that the component charts / components may include a hierarchy of sub |
| 161 | components and in themselves can be quite complex. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 162 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 163 | You can use either `charts` or `components` folder for your subcomponents. |
| 164 | `charts` folder means that the subcomponent will always been deployed. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 165 | |
Eric Debeau | 993b77b | 2020-08-19 15:30:00 +0200 | [diff] [blame] | 166 | `components` folders means we can choose if we want to deploy the |
| 167 | subcomponent. |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 168 | |
| 169 | This choice is done in root `values.yaml`: |
| 170 | |
| 171 | .. code-block:: yaml |
| 172 | |
| 173 | --- |
| 174 | global: |
| 175 | key: value |
| 176 | |
| 177 | component1: |
| 178 | enabled: true |
| 179 | component2: |
| 180 | enabled: true |
| 181 | |
efiacor | 370c6dc | 2021-10-12 14:10:49 +0100 | [diff] [blame] | 182 | Then in `Chart.yaml` dependencies section, you'll use these values: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 183 | |
| 184 | .. code-block:: yaml |
| 185 | |
| 186 | --- |
| 187 | dependencies: |
| 188 | - name: common |
| 189 | version: ~x.y-0 |
| 190 | repository: '@local' |
| 191 | - name: component1 |
| 192 | version: ~x.y-0 |
| 193 | repository: 'file://components/component1' |
| 194 | condition: component1.enabled |
| 195 | - name: component2 |
| 196 | version: ~x.y-0 |
| 197 | repository: 'file://components/component2' |
| 198 | condition: component2.enabled |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 199 | |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 200 | Configuration of the components varies somewhat from component to component but |
| 201 | generally follows the pattern of one or more `configmap.yaml` files which can |
| 202 | directly provide configuration to the containers in addition to processing |
| 203 | configuration files stored in the `config` directory. It is the responsibility |
| 204 | of each ONAP component team to update these configuration files when changes |
| 205 | are made to the project containers that impact configuration. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 206 | |
Sylvain Desbureaux | 5b7440b | 2019-01-28 16:49:14 +0100 | [diff] [blame] | 207 | The following section describes how the hierarchical ONAP configuration system |
| 208 | is key to management of such a large system. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 209 | |
| 210 | Configuration Management |
| 211 | ======================== |
| 212 | |
| 213 | ONAP is a large system composed of many components - each of which are complex |
| 214 | systems in themselves - that needs to be deployed in a number of different |
| 215 | ways. For example, within a single operator's network there may be R&D |
| 216 | deployments under active development, pre-production versions undergoing system |
| 217 | testing and production systems that are operating live networks. Each of these |
| 218 | deployments will differ in significant ways, such as the version of the |
| 219 | software images deployed. In addition, there may be a number of application |
| 220 | specific configuration differences, such as operating system environment |
| 221 | variables. The following describes how the Helm configuration management |
| 222 | system is used within the OOM project to manage both ONAP infrastructure |
| 223 | configuration as well as ONAP components configuration. |
| 224 | |
| 225 | One of the artifacts that OOM/Kubernetes uses to deploy ONAP components is the |
| 226 | deployment specification, yet another yaml file. Within these deployment specs |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 227 | are a number of parameters as shown in the following example: |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 228 | |
| 229 | .. code-block:: yaml |
| 230 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 231 | apiVersion: apps/v1 |
| 232 | kind: StatefulSet |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 233 | metadata: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 234 | labels: |
| 235 | app.kubernetes.io/name: zookeeper |
| 236 | helm.sh/chart: zookeeper |
| 237 | app.kubernetes.io/component: server |
| 238 | app.kubernetes.io/managed-by: Tiller |
| 239 | app.kubernetes.io/instance: onap-oof |
| 240 | name: onap-oof-zookeeper |
| 241 | namespace: onap |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 242 | spec: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 243 | <...> |
| 244 | replicas: 3 |
| 245 | selector: |
| 246 | matchLabels: |
| 247 | app.kubernetes.io/name: zookeeper |
| 248 | app.kubernetes.io/component: server |
| 249 | app.kubernetes.io/instance: onap-oof |
| 250 | serviceName: onap-oof-zookeeper-headless |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 251 | template: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 252 | metadata: |
| 253 | labels: |
| 254 | app.kubernetes.io/name: zookeeper |
| 255 | helm.sh/chart: zookeeper |
| 256 | app.kubernetes.io/component: server |
| 257 | app.kubernetes.io/managed-by: Tiller |
| 258 | app.kubernetes.io/instance: onap-oof |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 259 | spec: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 260 | <...> |
| 261 | affinity: |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 262 | containers: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 263 | - name: zookeeper |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 264 | <...> |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 265 | image: gcr.io/google_samples/k8szk:v3 |
| 266 | imagePullPolicy: Always |
| 267 | <...> |
| 268 | ports: |
| 269 | - containerPort: 2181 |
| 270 | name: client |
| 271 | protocol: TCP |
| 272 | - containerPort: 3888 |
| 273 | name: election |
| 274 | protocol: TCP |
| 275 | - containerPort: 2888 |
| 276 | name: server |
| 277 | protocol: TCP |
| 278 | <...> |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 279 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 280 | Note that within the statefulset specification, one of the container arguments |
| 281 | is the key/value pair image: gcr.io/google_samples/k8szk:v3 which |
| 282 | specifies the version of the zookeeper software to deploy. Although the |
| 283 | statefulset specifications greatly simplify statefulset, maintenance of the |
| 284 | statefulset specifications themselves become problematic as software versions |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 285 | change over time or as different versions are required for different |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 286 | statefulsets. For example, if the R&D team needs to deploy a newer version of |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 287 | mariadb than what is currently used in the production environment, they would |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 288 | need to clone the statefulset specification and change this value. Fortunately, |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 289 | this problem has been solved with the templating capabilities of Helm. |
| 290 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 291 | The following example shows how the statefulset specifications are modified to |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 292 | incorporate Helm templates such that key/value pairs can be defined outside of |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 293 | the statefulset specifications and passed during instantiation of the component. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 294 | |
| 295 | .. code-block:: yaml |
| 296 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 297 | apiVersion: apps/v1 |
| 298 | kind: StatefulSet |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 299 | metadata: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 300 | name: {{ include "common.fullname" . }} |
| 301 | namespace: {{ include "common.namespace" . }} |
| 302 | labels: {{- include "common.labels" . | nindent 4 }} |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 303 | spec: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 304 | replicas: {{ .Values.replicaCount }} |
| 305 | selector: |
| 306 | matchLabels: {{- include "common.matchLabels" . | nindent 6 }} |
| 307 | # serviceName is only needed for StatefulSet |
| 308 | # put the postfix part only if you have add a postfix on the service name |
| 309 | serviceName: {{ include "common.servicename" . }}-{{ .Values.service.postfix }} |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 310 | <...> |
| 311 | template: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 312 | metadata: |
| 313 | labels: {{- include "common.labels" . | nindent 8 }} |
| 314 | annotations: {{- include "common.tplValue" (dict "value" .Values.podAnnotations "context" $) | nindent 8 }} |
| 315 | name: {{ include "common.name" . }} |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 316 | spec: |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 317 | <...> |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 318 | containers: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 319 | - name: {{ include "common.name" . }} |
| 320 | image: {{ .Values.image }} |
| 321 | imagePullPolicy: {{ .Values.global.pullPolicy | default .Values.pullPolicy }} |
| 322 | ports: |
| 323 | {{- range $index, $port := .Values.service.ports }} |
| 324 | - containerPort: {{ $port.port }} |
| 325 | name: {{ $port.name }} |
| 326 | {{- end }} |
| 327 | {{- range $index, $port := .Values.service.headlessPorts }} |
| 328 | - containerPort: {{ $port.port }} |
| 329 | name: {{ $port.name }} |
| 330 | {{- end }} |
| 331 | <...> |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 332 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 333 | This version of the statefulset specification has gone through the process of |
| 334 | templating values that are likely to change between statefulsets. Note that the |
| 335 | image is now specified as: image: {{ .Values.image }} instead of a |
| 336 | string used previously. During the statefulset phase, Helm (actually the Helm |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 337 | sub-component Tiller) substitutes the {{ .. }} entries with a variable defined |
| 338 | in a values.yaml file. The content of this file is as follows: |
| 339 | |
| 340 | .. code-block:: yaml |
| 341 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 342 | <...> |
| 343 | image: gcr.io/google_samples/k8szk:v3 |
| 344 | replicaCount: 3 |
| 345 | <...> |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 346 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 347 | |
| 348 | Within the values.yaml file there is an image key with the value |
| 349 | `gcr.io/google_samples/k8szk:v3` which is the same value used in |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 350 | the non-templated version. Once all of the substitutions are complete, the |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 351 | resulting statefulset specification ready to be used by Kubernetes. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 352 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 353 | When creating a template consider the use of default values if appropriate. |
| 354 | Helm templating has built in support for DEFAULT values, here is |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 355 | an example: |
| 356 | |
| 357 | .. code-block:: yaml |
| 358 | |
| 359 | imagePullSecrets: |
| 360 | - name: "{{ .Values.nsPrefix | default "onap" }}-docker-registry-key" |
| 361 | |
| 362 | The pipeline operator ("|") used here hints at that power of Helm templates in |
| 363 | that much like an operating system command line the pipeline operator allow |
| 364 | over 60 Helm functions to be embedded directly into the template (note that the |
| 365 | Helm template language is a superset of the Go template language). These |
| 366 | functions include simple string operations like upper and more complex flow |
| 367 | control operations like if/else. |
| 368 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 369 | OOM is mainly helm templating. In order to have consistent deployment of the |
| 370 | different components of ONAP, some rules must be followed. |
| 371 | |
| 372 | Templates are provided in order to create Kubernetes resources (Secrets, |
| 373 | Ingress, Services, ...) or part of Kubernetes resources (names, labels, |
| 374 | resources requests and limits, ...). |
| 375 | |
Sylvain Desbureaux | 88b2f92 | 2020-03-04 11:31:11 +0100 | [diff] [blame] | 376 | a full list and simple description is done in |
| 377 | `kubernetes/common/common/documentation.rst`. |
| 378 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 379 | Service template |
| 380 | ---------------- |
| 381 | |
| 382 | In order to create a Service for a component, you have to create a file (with |
| 383 | `service` in the name. |
| 384 | For normal service, just put the following line: |
| 385 | |
| 386 | .. code-block:: yaml |
| 387 | |
| 388 | {{ include "common.service" . }} |
| 389 | |
| 390 | For headless service, the line to put is the following: |
| 391 | |
| 392 | .. code-block:: yaml |
| 393 | |
| 394 | {{ include "common.headlessService" . }} |
| 395 | |
| 396 | The configuration of the service is done in component `values.yaml`: |
| 397 | |
| 398 | .. code-block:: yaml |
| 399 | |
| 400 | service: |
| 401 | name: NAME-OF-THE-SERVICE |
| 402 | postfix: MY-POSTFIX |
| 403 | type: NodePort |
| 404 | annotations: |
| 405 | someAnnotationsKey: value |
| 406 | ports: |
| 407 | - name: tcp-MyPort |
| 408 | port: 5432 |
| 409 | nodePort: 88 |
| 410 | - name: http-api |
| 411 | port: 8080 |
| 412 | nodePort: 89 |
| 413 | - name: https-api |
| 414 | port: 9443 |
| 415 | nodePort: 90 |
| 416 | |
| 417 | `annotations` and `postfix` keys are optional. |
| 418 | if `service.type` is `NodePort`, then you have to give `nodePort` value for your |
| 419 | service ports (which is the end of the computed nodePort, see example). |
| 420 | |
| 421 | It would render the following Service Resource (for a component named |
| 422 | `name-of-my-component`, with version `x.y.z`, helm deployment name |
| 423 | `my-deployment` and `global.nodePortPrefix` `302`): |
| 424 | |
| 425 | .. code-block:: yaml |
| 426 | |
| 427 | apiVersion: v1 |
| 428 | kind: Service |
| 429 | metadata: |
| 430 | annotations: |
| 431 | someAnnotationsKey: value |
| 432 | name: NAME-OF-THE-SERVICE-MY-POSTFIX |
| 433 | labels: |
| 434 | app.kubernetes.io/name: name-of-my-component |
| 435 | helm.sh/chart: name-of-my-component-x.y.z |
| 436 | app.kubernetes.io/instance: my-deployment-name-of-my-component |
| 437 | app.kubernetes.io/managed-by: Tiller |
| 438 | spec: |
| 439 | ports: |
| 440 | - port: 5432 |
| 441 | targetPort: tcp-MyPort |
| 442 | nodePort: 30288 |
| 443 | - port: 8080 |
| 444 | targetPort: http-api |
| 445 | nodePort: 30289 |
| 446 | - port: 9443 |
| 447 | targetPort: https-api |
| 448 | nodePort: 30290 |
| 449 | selector: |
| 450 | app.kubernetes.io/name: name-of-my-component |
| 451 | app.kubernetes.io/instance: my-deployment-name-of-my-component |
| 452 | type: NodePort |
| 453 | |
Eric Debeau | 993b77b | 2020-08-19 15:30:00 +0200 | [diff] [blame] | 454 | In the deployment or statefulSet file, you needs to set the good labels in |
| 455 | order for the service to match the pods. |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 456 | |
Eric Debeau | 993b77b | 2020-08-19 15:30:00 +0200 | [diff] [blame] | 457 | here's an example to be sure it matches (for a statefulSet): |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 458 | |
| 459 | .. code-block:: yaml |
| 460 | |
| 461 | apiVersion: apps/v1 |
| 462 | kind: StatefulSet |
| 463 | metadata: |
| 464 | name: {{ include "common.fullname" . }} |
| 465 | namespace: {{ include "common.namespace" . }} |
| 466 | labels: {{- include "common.labels" . | nindent 4 }} |
| 467 | spec: |
| 468 | selector: |
| 469 | matchLabels: {{- include "common.matchLabels" . | nindent 6 }} |
| 470 | # serviceName is only needed for StatefulSet |
| 471 | # put the postfix part only if you have add a postfix on the service name |
| 472 | serviceName: {{ include "common.servicename" . }}-{{ .Values.service.postfix }} |
| 473 | <...> |
| 474 | template: |
| 475 | metadata: |
| 476 | labels: {{- include "common.labels" . | nindent 8 }} |
| 477 | annotations: {{- include "common.tplValue" (dict "value" .Values.podAnnotations "context" $) | nindent 8 }} |
| 478 | name: {{ include "common.name" . }} |
| 479 | spec: |
| 480 | <...> |
| 481 | containers: |
| 482 | - name: {{ include "common.name" . }} |
| 483 | ports: |
| 484 | {{- range $index, $port := .Values.service.ports }} |
| 485 | - containerPort: {{ $port.port }} |
| 486 | name: {{ $port.name }} |
| 487 | {{- end }} |
| 488 | {{- range $index, $port := .Values.service.headlessPorts }} |
| 489 | - containerPort: {{ $port.port }} |
| 490 | name: {{ $port.name }} |
| 491 | {{- end }} |
| 492 | <...> |
| 493 | |
| 494 | The configuration of the service is done in component `values.yaml`: |
| 495 | |
| 496 | .. code-block:: yaml |
| 497 | |
| 498 | service: |
| 499 | name: NAME-OF-THE-SERVICE |
| 500 | headless: |
| 501 | postfix: NONE |
| 502 | annotations: |
| 503 | anotherAnnotationsKey : value |
| 504 | publishNotReadyAddresses: true |
| 505 | headlessPorts: |
| 506 | - name: tcp-MyPort |
| 507 | port: 5432 |
| 508 | - name: http-api |
| 509 | port: 8080 |
| 510 | - name: https-api |
| 511 | port: 9443 |
| 512 | |
| 513 | `headless.annotations`, `headless.postfix` and |
| 514 | `headless.publishNotReadyAddresses` keys are optional. |
| 515 | |
| 516 | If `headless.postfix` is not set, then we'll add `-headless` at the end of the |
| 517 | service name. |
| 518 | |
| 519 | If it set to `NONE`, there will be not postfix. |
| 520 | |
| 521 | And if set to something, it will add `-something` at the end of the service |
| 522 | name. |
| 523 | |
| 524 | It would render the following Service Resource (for a component named |
| 525 | `name-of-my-component`, with version `x.y.z`, helm deployment name |
| 526 | `my-deployment` and `global.nodePortPrefix` `302`): |
| 527 | |
| 528 | .. code-block:: yaml |
| 529 | |
| 530 | apiVersion: v1 |
| 531 | kind: Service |
| 532 | metadata: |
| 533 | annotations: |
| 534 | anotherAnnotationsKey: value |
| 535 | name: NAME-OF-THE-SERVICE |
| 536 | labels: |
| 537 | app.kubernetes.io/name: name-of-my-component |
| 538 | helm.sh/chart: name-of-my-component-x.y.z |
| 539 | app.kubernetes.io/instance: my-deployment-name-of-my-component |
| 540 | app.kubernetes.io/managed-by: Tiller |
| 541 | spec: |
| 542 | clusterIP: None |
| 543 | ports: |
| 544 | - port: 5432 |
| 545 | targetPort: tcp-MyPort |
| 546 | nodePort: 30288 |
| 547 | - port: 8080 |
| 548 | targetPort: http-api |
| 549 | nodePort: 30289 |
| 550 | - port: 9443 |
| 551 | targetPort: https-api |
| 552 | nodePort: 30290 |
| 553 | publishNotReadyAddresses: true |
| 554 | selector: |
| 555 | app.kubernetes.io/name: name-of-my-component |
| 556 | app.kubernetes.io/instance: my-deployment-name-of-my-component |
| 557 | type: ClusterIP |
| 558 | |
| 559 | Previous example of StatefulSet would also match (except for the `postfix` part |
| 560 | obviously). |
| 561 | |
| 562 | Creating Deployment or StatefulSet |
| 563 | ---------------------------------- |
| 564 | |
| 565 | Deployment and StatefulSet should use the `apps/v1` (which has appeared in |
| 566 | v1.9). |
| 567 | As seen on the service part, the following parts are mandatory: |
| 568 | |
| 569 | .. code-block:: yaml |
| 570 | |
| 571 | apiVersion: apps/v1 |
| 572 | kind: StatefulSet |
| 573 | metadata: |
| 574 | name: {{ include "common.fullname" . }} |
| 575 | namespace: {{ include "common.namespace" . }} |
| 576 | labels: {{- include "common.labels" . | nindent 4 }} |
| 577 | spec: |
| 578 | selector: |
| 579 | matchLabels: {{- include "common.matchLabels" . | nindent 6 }} |
| 580 | # serviceName is only needed for StatefulSet |
| 581 | # put the postfix part only if you have add a postfix on the service name |
| 582 | serviceName: {{ include "common.servicename" . }}-{{ .Values.service.postfix }} |
| 583 | <...> |
| 584 | template: |
| 585 | metadata: |
| 586 | labels: {{- include "common.labels" . | nindent 8 }} |
| 587 | annotations: {{- include "common.tplValue" (dict "value" .Values.podAnnotations "context" $) | nindent 8 }} |
| 588 | name: {{ include "common.name" . }} |
| 589 | spec: |
| 590 | <...> |
| 591 | containers: |
| 592 | - name: {{ include "common.name" . }} |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 593 | |
| 594 | ONAP Application Configuration |
| 595 | ------------------------------ |
| 596 | |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 597 | Dependency Management |
| 598 | --------------------- |
| 599 | These Helm charts describe the desired state |
| 600 | of an ONAP deployment and instruct the Kubernetes container manager as to how |
| 601 | to maintain the deployment in this state. These dependencies dictate the order |
| 602 | in-which the containers are started for the first time such that such |
| 603 | dependencies are always met without arbitrary sleep times between container |
| 604 | startups. For example, the SDC back-end container requires the Elastic-Search, |
| 605 | Cassandra and Kibana containers within SDC to be ready and is also dependent on |
| 606 | DMaaP (or the message-router) to be ready - where ready implies the built-in |
| 607 | "readiness" probes succeeded - before becoming fully operational. When an |
| 608 | initial deployment of ONAP is requested the current state of the system is NULL |
| 609 | so ONAP is deployed by the Kubernetes manager as a set of Docker containers on |
| 610 | one or more predetermined hosts. The hosts could be physical machines or |
| 611 | virtual machines. When deploying on virtual machines the resulting system will |
| 612 | be very similar to "Heat" based deployments, i.e. Docker containers running |
| 613 | within a set of VMs, the primary difference being that the allocation of |
| 614 | containers to VMs is done dynamically with OOM and statically with "Heat". |
| 615 | Example SO deployment descriptor file shows SO's dependency on its mariadb |
| 616 | data-base component: |
| 617 | |
| 618 | SO deployment specification excerpt: |
| 619 | |
| 620 | .. code-block:: yaml |
| 621 | |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 622 | apiVersion: apps/v1 |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 623 | kind: Deployment |
| 624 | metadata: |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 625 | name: {{ include "common.fullname" . }} |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 626 | namespace: {{ include "common.namespace" . }} |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 627 | labels: {{- include "common.labels" . | nindent 4 }} |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 628 | spec: |
| 629 | replicas: {{ .Values.replicaCount }} |
Sylvain Desbureaux | 60c7480 | 2019-12-12 14:35:01 +0100 | [diff] [blame] | 630 | selector: |
| 631 | matchLabels: {{- include "common.matchLabels" . | nindent 6 }} |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 632 | template: |
| 633 | metadata: |
| 634 | labels: |
| 635 | app: {{ include "common.name" . }} |
| 636 | release: {{ .Release.Name }} |
| 637 | spec: |
| 638 | initContainers: |
| 639 | - command: |
Sylvain Desbureaux | 1694e1d | 2020-08-21 09:58:25 +0200 | [diff] [blame] | 640 | - /app/ready.py |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 641 | args: |
| 642 | - --container-name |
| 643 | - so-mariadb |
| 644 | env: |
| 645 | ... |
| 646 | |
| 647 | Kubernetes Container Orchestration |
| 648 | ================================== |
| 649 | The ONAP components are managed by the Kubernetes_ container management system |
| 650 | which maintains the desired state of the container system as described by one |
| 651 | or more deployment descriptors - similar in concept to OpenStack HEAT |
| 652 | Orchestration Templates. The following sections describe the fundamental |
| 653 | objects managed by Kubernetes, the network these components use to communicate |
| 654 | with each other and other entities outside of ONAP and the templates that |
| 655 | describe the configuration and desired state of the ONAP components. |
| 656 | |
| 657 | Name Spaces |
| 658 | ----------- |
Sylvain Desbureaux | 5b7440b | 2019-01-28 16:49:14 +0100 | [diff] [blame] | 659 | Within the namespaces are Kubernetes services that provide external |
| 660 | connectivity to pods that host Docker containers. |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 661 | |
| 662 | ONAP Components to Kubernetes Object Relationships |
| 663 | -------------------------------------------------- |
| 664 | Kubernetes deployments consist of multiple objects: |
| 665 | |
| 666 | - **nodes** - a worker machine - either physical or virtual - that hosts |
| 667 | multiple containers managed by Kubernetes. |
| 668 | - **services** - an abstraction of a logical set of pods that provide a |
| 669 | micro-service. |
| 670 | - **pods** - one or more (but typically one) container(s) that provide specific |
| 671 | application functionality. |
| 672 | - **persistent volumes** - One or more permanent volumes need to be established |
| 673 | to hold non-ephemeral configuration and state data. |
| 674 | |
| 675 | The relationship between these objects is shown in the following figure: |
| 676 | |
| 677 | .. .. uml:: |
| 678 | .. |
| 679 | .. @startuml |
| 680 | .. node PH { |
| 681 | .. component Service { |
| 682 | .. component Pod0 |
| 683 | .. component Pod1 |
| 684 | .. } |
| 685 | .. } |
| 686 | .. |
| 687 | .. database PV |
| 688 | .. @enduml |
| 689 | |
efiacor | 1660a8c | 2022-05-03 16:24:13 +0100 | [diff] [blame^] | 690 | .. figure:: images/k8s/kubernetes_objects.png |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 691 | |
| 692 | OOM uses these Kubernetes objects as described in the following sections. |
| 693 | |
| 694 | Nodes |
| 695 | ~~~~~ |
| 696 | OOM works with both physical and virtual worker machines. |
| 697 | |
| 698 | * Virtual Machine Deployments - If ONAP is to be deployed onto a set of virtual |
| 699 | machines, the creation of the VMs is outside of the scope of OOM and could be |
| 700 | done in many ways, such as |
| 701 | |
| 702 | * manually, for example by a user using the OpenStack Horizon dashboard or |
| 703 | AWS EC2, or |
| 704 | * automatically, for example with the use of a OpenStack Heat Orchestration |
| 705 | Template which builds an ONAP stack, Azure ARM template, AWS CloudFormation |
| 706 | Template, or |
| 707 | * orchestrated, for example with Cloudify creating the VMs from a TOSCA |
| 708 | template and controlling their life cycle for the life of the ONAP |
| 709 | deployment. |
| 710 | |
| 711 | * Physical Machine Deployments - If ONAP is to be deployed onto physical |
| 712 | machines there are several options but the recommendation is to use Rancher |
| 713 | along with Helm to associate hosts with a Kubernetes cluster. |
| 714 | |
| 715 | Pods |
| 716 | ~~~~ |
| 717 | A group of containers with shared storage and networking can be grouped |
| 718 | together into a Kubernetes pod. All of the containers within a pod are |
| 719 | co-located and co-scheduled so they operate as a single unit. Within ONAP |
| 720 | Amsterdam release, pods are mapped one-to-one to docker containers although |
| 721 | this may change in the future. As explained in the Services section below the |
| 722 | use of Pods within each ONAP component is abstracted from other ONAP |
| 723 | components. |
| 724 | |
| 725 | Services |
| 726 | ~~~~~~~~ |
| 727 | OOM uses the Kubernetes service abstraction to provide a consistent access |
| 728 | point for each of the ONAP components independent of the pod or container |
| 729 | architecture of that component. For example, the SDNC component may introduce |
| 730 | OpenDaylight clustering as some point and change the number of pods in this |
| 731 | component to three or more but this change will be isolated from the other ONAP |
| 732 | components by the service abstraction. A service can include a load balancer |
| 733 | on its ingress to distribute traffic between the pods and even react to dynamic |
| 734 | changes in the number of pods if they are part of a replica set. |
| 735 | |
| 736 | Persistent Volumes |
| 737 | ~~~~~~~~~~~~~~~~~~ |
| 738 | To enable ONAP to be deployed into a wide variety of cloud infrastructures a |
| 739 | flexible persistent storage architecture, built on Kubernetes persistent |
| 740 | volumes, provides the ability to define the physical storage in a central |
| 741 | location and have all ONAP components securely store their data. |
| 742 | |
| 743 | When deploying ONAP into a public cloud, available storage services such as |
| 744 | `AWS Elastic Block Store`_, `Azure File`_, or `GCE Persistent Disk`_ are |
| 745 | options. Alternatively, when deploying into a private cloud the storage |
| 746 | architecture might consist of Fiber Channel, `Gluster FS`_, or iSCSI. Many |
| 747 | other storage options existing, refer to the `Kubernetes Storage Class`_ |
| 748 | documentation for a full list of the options. The storage architecture may vary |
| 749 | from deployment to deployment but in all cases a reliable, redundant storage |
| 750 | system must be provided to ONAP with which the state information of all ONAP |
| 751 | components will be securely stored. The Storage Class for a given deployment is |
| 752 | a single parameter listed in the ONAP values.yaml file and therefore is easily |
| 753 | customized. Operation of this storage system is outside the scope of the OOM. |
| 754 | |
| 755 | .. code-block:: yaml |
| 756 | |
| 757 | Insert values.yaml code block with storage block here |
| 758 | |
| 759 | Once the storage class is selected and the physical storage is provided, the |
| 760 | ONAP deployment step creates a pool of persistent volumes within the given |
| 761 | physical storage that is used by all of the ONAP components. ONAP components |
| 762 | simply make a claim on these persistent volumes (PV), with a persistent volume |
| 763 | claim (PVC), to gain access to their storage. |
| 764 | |
| 765 | The following figure illustrates the relationships between the persistent |
| 766 | volume claims, the persistent volumes, the storage class, and the physical |
| 767 | storage. |
| 768 | |
| 769 | .. graphviz:: |
| 770 | |
| 771 | digraph PV { |
| 772 | label = "Persistance Volume Claim to Physical Storage Mapping" |
| 773 | { |
| 774 | node [shape=cylinder] |
| 775 | D0 [label="Drive0"] |
| 776 | D1 [label="Drive1"] |
| 777 | Dx [label="Drivex"] |
| 778 | } |
| 779 | { |
| 780 | node [shape=Mrecord label="StorageClass:ceph"] |
| 781 | sc |
| 782 | } |
| 783 | { |
| 784 | node [shape=point] |
| 785 | p0 p1 p2 |
| 786 | p3 p4 p5 |
| 787 | } |
| 788 | subgraph clusterSDC { |
| 789 | label="SDC" |
| 790 | PVC0 |
| 791 | PVC1 |
| 792 | } |
| 793 | subgraph clusterSDNC { |
| 794 | label="SDNC" |
| 795 | PVC2 |
| 796 | } |
| 797 | subgraph clusterSO { |
| 798 | label="SO" |
| 799 | PVCn |
| 800 | } |
| 801 | PV0 -> sc |
| 802 | PV1 -> sc |
| 803 | PV2 -> sc |
| 804 | PVn -> sc |
| 805 | |
| 806 | sc -> {D0 D1 Dx} |
| 807 | PVC0 -> PV0 |
| 808 | PVC1 -> PV1 |
| 809 | PVC2 -> PV2 |
| 810 | PVCn -> PVn |
| 811 | |
| 812 | # force all of these nodes to the same line in the given order |
| 813 | subgraph { |
| 814 | rank = same; PV0;PV1;PV2;PVn;p0;p1;p2 |
| 815 | PV0->PV1->PV2->p0->p1->p2->PVn [style=invis] |
| 816 | } |
| 817 | |
| 818 | subgraph { |
| 819 | rank = same; D0;D1;Dx;p3;p4;p5 |
| 820 | D0->D1->p3->p4->p5->Dx [style=invis] |
| 821 | } |
| 822 | |
| 823 | } |
| 824 | |
| 825 | In-order for an ONAP component to use a persistent volume it must make a claim |
| 826 | against a specific persistent volume defined in the ONAP common charts. Note |
| 827 | that there is a one-to-one relationship between a PVC and PV. The following is |
| 828 | an excerpt from a component chart that defines a PVC: |
| 829 | |
| 830 | .. code-block:: yaml |
| 831 | |
| 832 | Insert PVC example here |
| 833 | |
| 834 | OOM Networking with Kubernetes |
| 835 | ------------------------------ |
| 836 | |
| 837 | - DNS |
Sylvain Desbureaux | 5b7440b | 2019-01-28 16:49:14 +0100 | [diff] [blame] | 838 | - Ports - Flattening the containers also expose port conflicts between the |
| 839 | containers which need to be resolved. |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 840 | |
| 841 | Node Ports |
| 842 | ~~~~~~~~~~ |
| 843 | |
| 844 | Pod Placement Rules |
| 845 | ------------------- |
| 846 | OOM will use the rich set of Kubernetes node and pod affinity / |
| 847 | anti-affinity rules to minimize the chance of a single failure resulting in a |
| 848 | loss of ONAP service. Node affinity / anti-affinity is used to guide the |
| 849 | Kubernetes orchestrator in the placement of pods on nodes (physical or virtual |
| 850 | machines). For example: |
| 851 | |
| 852 | - if a container used Intel DPDK technology the pod may state that it as |
| 853 | affinity to an Intel processor based node, or |
| 854 | - geographical based node labels (such as the Kubernetes standard zone or |
| 855 | region labels) may be used to ensure placement of a DCAE complex close to the |
| 856 | VNFs generating high volumes of traffic thus minimizing networking cost. |
| 857 | Specifically, if nodes were pre-assigned labels East and West, the pod |
| 858 | deployment spec to distribute pods to these nodes would be: |
| 859 | |
| 860 | .. code-block:: yaml |
| 861 | |
| 862 | nodeSelector: |
| 863 | failure-domain.beta.Kubernetes.io/region: {{ .Values.location }} |
| 864 | |
| 865 | - "location: West" is specified in the `values.yaml` file used to deploy |
| 866 | one DCAE cluster and "location: East" is specified in a second `values.yaml` |
| 867 | file (see OOM Configuration Management for more information about |
| 868 | configuration files like the `values.yaml` file). |
| 869 | |
| 870 | Node affinity can also be used to achieve geographic redundancy if pods are |
| 871 | assigned to multiple failure domains. For more information refer to `Assigning |
| 872 | Pods to Nodes`_. |
| 873 | |
| 874 | .. note:: |
| 875 | One could use Pod to Node assignment to totally constrain Kubernetes when |
| 876 | doing initial container assignment to replicate the Amsterdam release |
| 877 | OpenStack Heat based deployment. Should one wish to do this, each VM would |
| 878 | need a unique node name which would be used to specify a node constaint |
| 879 | for every component. These assignment could be specified in an environment |
| 880 | specific values.yaml file. Constraining Kubernetes in this way is not |
| 881 | recommended. |
| 882 | |
| 883 | Kubernetes has a comprehensive system called Taints and Tolerations that can be |
| 884 | used to force the container orchestrator to repel pods from nodes based on |
| 885 | static events (an administrator assigning a taint to a node) or dynamic events |
| 886 | (such as a node becoming unreachable or running out of disk space). There are |
| 887 | no plans to use taints or tolerations in the ONAP Beijing release. Pod |
| 888 | affinity / anti-affinity is the concept of creating a spacial relationship |
| 889 | between pods when the Kubernetes orchestrator does assignment (both initially |
| 890 | an in operation) to nodes as explained in Inter-pod affinity and anti-affinity. |
| 891 | For example, one might choose to co-located all of the ONAP SDC containers on a |
| 892 | single node as they are not critical runtime components and co-location |
| 893 | minimizes overhead. On the other hand, one might choose to ensure that all of |
| 894 | the containers in an ODL cluster (SDNC and APPC) are placed on separate nodes |
| 895 | such that a node failure has minimal impact to the operation of the cluster. |
| 896 | An example of how pod affinity / anti-affinity is shown below: |
| 897 | |
| 898 | Pod Affinity / Anti-Affinity |
| 899 | |
| 900 | .. code-block:: yaml |
| 901 | |
| 902 | apiVersion: v1 |
| 903 | kind: Pod |
| 904 | metadata: |
| 905 | name: with-pod-affinity |
| 906 | spec: |
| 907 | affinity: |
| 908 | podAffinity: |
| 909 | requiredDuringSchedulingIgnoredDuringExecution: |
| 910 | - labelSelector: |
| 911 | matchExpressions: |
| 912 | - key: security |
| 913 | operator: In |
| 914 | values: |
| 915 | - S1 |
| 916 | topologyKey: failure-domain.beta.Kubernetes.io/zone |
| 917 | podAntiAffinity: |
| 918 | preferredDuringSchedulingIgnoredDuringExecution: |
| 919 | - weight: 100 |
| 920 | podAffinityTerm: |
| 921 | labelSelector: |
| 922 | matchExpressions: |
| 923 | - key: security |
| 924 | operator: In |
| 925 | values: |
| 926 | - S2 |
| 927 | topologyKey: Kubernetes.io/hostname |
| 928 | containers: |
| 929 | - name: with-pod-affinity |
| 930 | image: gcr.io/google_containers/pause:2.0 |
| 931 | |
| 932 | This example contains both podAffinity and podAntiAffinity rules, the first |
| 933 | rule is is a must (requiredDuringSchedulingIgnoredDuringExecution) while the |
| 934 | second will be met pending other considerations |
| 935 | (preferredDuringSchedulingIgnoredDuringExecution). Preemption Another feature |
| 936 | that may assist in achieving a repeatable deployment in the presence of faults |
| 937 | that may have reduced the capacity of the cloud is assigning priority to the |
| 938 | containers such that mission critical components have the ability to evict less |
| 939 | critical components. Kubernetes provides this capability with Pod Priority and |
| 940 | Preemption. Prior to having more advanced production grade features available, |
| 941 | the ability to at least be able to re-deploy ONAP (or a subset of) reliably |
| 942 | provides a level of confidence that should an outage occur the system can be |
| 943 | brought back on-line predictably. |
| 944 | |
| 945 | Health Checks |
| 946 | ------------- |
| 947 | |
| 948 | Monitoring of ONAP components is configured in the agents within JSON files and |
| 949 | stored in gerrit under the consul-agent-config, here is an example from the AAI |
| 950 | model loader (aai-model-loader-health.json): |
| 951 | |
| 952 | .. code-block:: json |
| 953 | |
| 954 | { |
| 955 | "service": { |
| 956 | "name": "A&AI Model Loader", |
| 957 | "checks": [ |
| 958 | { |
| 959 | "id": "model-loader-process", |
| 960 | "name": "Model Loader Presence", |
| 961 | "script": "/consul/config/scripts/model-loader-script.sh", |
| 962 | "interval": "15s", |
| 963 | "timeout": "1s" |
| 964 | } |
| 965 | ] |
| 966 | } |
| 967 | } |
| 968 | |
| 969 | Liveness Probes |
| 970 | --------------- |
| 971 | |
| 972 | These liveness probes can simply check that a port is available, that a |
| 973 | built-in health check is reporting good health, or that the Consul health check |
| 974 | is positive. For example, to monitor the SDNC component has following liveness |
| 975 | probe can be found in the SDNC DB deployment specification: |
| 976 | |
| 977 | .. code-block:: yaml |
| 978 | |
| 979 | sdnc db liveness probe |
| 980 | |
| 981 | livenessProbe: |
| 982 | exec: |
| 983 | command: ["mysqladmin", "ping"] |
| 984 | initialDelaySeconds: 30 periodSeconds: 10 |
| 985 | timeoutSeconds: 5 |
| 986 | |
| 987 | The 'initialDelaySeconds' control the period of time between the readiness |
| 988 | probe succeeding and the liveness probe starting. 'periodSeconds' and |
| 989 | 'timeoutSeconds' control the actual operation of the probe. Note that |
| 990 | containers are inherently ephemeral so the healing action destroys failed |
| 991 | containers and any state information within it. To avoid a loss of state, a |
| 992 | persistent volume should be used to store all data that needs to be persisted |
| 993 | over the re-creation of a container. Persistent volumes have been created for |
| 994 | the database components of each of the projects and the same technique can be |
| 995 | used for all persistent state information. |
| 996 | |
| 997 | |
| 998 | |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 999 | Environment Files |
| 1000 | ~~~~~~~~~~~~~~~~~ |
| 1001 | |
| 1002 | MSB Integration |
| 1003 | =============== |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 1004 | |
| 1005 | The \ `Microservices Bus |
| 1006 | Project <https://wiki.onap.org/pages/viewpage.action?pageId=3246982>`__ provides |
| 1007 | facilities to integrate micro-services into ONAP and therefore needs to |
| 1008 | integrate into OOM - primarily through Consul which is the backend of |
| 1009 | MSB service discovery. The following is a brief description of how this |
| 1010 | integration will be done: |
| 1011 | |
| 1012 | A registrator to push the service endpoint info to MSB service |
Eric Debeau | 993b77b | 2020-08-19 15:30:00 +0200 | [diff] [blame] | 1013 | discovery. |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 1014 | |
| 1015 | - The needed service endpoint info is put into the kubernetes yaml file |
| 1016 | as annotation, including service name, Protocol,version, visual |
| 1017 | range,LB method, IP, Port,etc. |
| 1018 | |
| 1019 | - OOM deploy/start/restart/scale in/scale out/upgrade ONAP components |
| 1020 | |
| 1021 | - Registrator watch the kubernetes event |
| 1022 | |
| 1023 | - When an ONAP component instance has been started/destroyed by OOM, |
| 1024 | Registrator get the notification from kubernetes |
| 1025 | |
| 1026 | - Registrator parse the service endpoint info from annotation and |
| 1027 | register/update/unregister it to MSB service discovery |
| 1028 | |
| 1029 | - MSB API Gateway uses the service endpoint info for service routing |
| 1030 | and load balancing. |
| 1031 | |
| 1032 | Details of the registration service API can be found at \ `Microservice |
| 1033 | Bus API |
| 1034 | Documentation <https://wiki.onap.org/display/DW/Microservice+Bus+API+Documentation>`__. |
| 1035 | |
| 1036 | ONAP Component Registration to MSB |
| 1037 | ---------------------------------- |
| 1038 | The charts of all ONAP components intending to register against MSB must have |
| 1039 | an annotation in their service(s) template. A `sdc` example follows: |
| 1040 | |
| 1041 | .. code-block:: yaml |
| 1042 | |
| 1043 | apiVersion: v1 |
| 1044 | kind: Service |
| 1045 | metadata: |
| 1046 | labels: |
| 1047 | app: sdc-be |
| 1048 | name: sdc-be |
| 1049 | namespace: "{{ .Values.nsPrefix }}" |
| 1050 | annotations: |
| 1051 | msb.onap.org/service-info: '[ |
| 1052 | { |
| 1053 | "serviceName": "sdc", |
| 1054 | "version": "v1", |
| 1055 | "url": "/sdc/v1", |
| 1056 | "protocol": "REST", |
| 1057 | "port": "8080", |
| 1058 | "visualRange":"1" |
| 1059 | }, |
| 1060 | { |
| 1061 | "serviceName": "sdc-deprecated", |
| 1062 | "version": "v1", |
| 1063 | "url": "/sdc/v1", |
| 1064 | "protocol": "REST", |
| 1065 | "port": "8080", |
| 1066 | "visualRange":"1", |
| 1067 | "path":"/sdc/v1" |
| 1068 | } |
| 1069 | ]' |
| 1070 | ... |
| 1071 | |
| 1072 | |
| 1073 | MSB Integration with OOM |
| 1074 | ------------------------ |
| 1075 | A preliminary view of the OOM-MSB integration is as follows: |
| 1076 | |
efiacor | 1660a8c | 2022-05-03 16:24:13 +0100 | [diff] [blame^] | 1077 | .. figure:: images/msb/MSB-OOM-Diagram.png |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 1078 | |
| 1079 | A message sequence chart of the registration process: |
| 1080 | |
| 1081 | .. uml:: |
| 1082 | |
| 1083 | participant "OOM" as oom |
| 1084 | participant "ONAP Component" as onap |
| 1085 | participant "Service Discovery" as sd |
| 1086 | participant "External API Gateway" as eagw |
| 1087 | participant "Router (Internal API Gateway)" as iagw |
| 1088 | |
| 1089 | box "MSB" #LightBlue |
| 1090 | participant sd |
| 1091 | participant eagw |
| 1092 | participant iagw |
| 1093 | end box |
| 1094 | |
| 1095 | == Deploy Servcie == |
| 1096 | |
| 1097 | oom -> onap: Deploy |
| 1098 | oom -> sd: Register service endpoints |
| 1099 | sd -> eagw: Services exposed to external system |
| 1100 | sd -> iagw: Services for internal use |
| 1101 | |
| 1102 | == Component Life-cycle Management == |
| 1103 | |
| 1104 | oom -> onap: Start/Stop/Scale/Migrate/Upgrade |
| 1105 | oom -> sd: Update service info |
| 1106 | sd -> eagw: Update service info |
| 1107 | sd -> iagw: Update service info |
| 1108 | |
| 1109 | == Service Health Check == |
| 1110 | |
| 1111 | sd -> onap: Check the health of service |
| 1112 | sd -> eagw: Update service status |
| 1113 | sd -> iagw: Update service status |
| 1114 | |
| 1115 | |
| 1116 | MSB Deployment Instructions |
| 1117 | --------------------------- |
| 1118 | MSB is helm installable ONAP component which is often automatically deployed. |
| 1119 | To install it individually enter:: |
| 1120 | |
| 1121 | > helm install <repo-name>/msb |
| 1122 | |
| 1123 | .. note:: |
| 1124 | TBD: Vaidate if the following procedure is still required. |
| 1125 | |
| 1126 | Please note that Kubernetes authentication token must be set at |
| 1127 | *kubernetes/kube2msb/values.yaml* so the kube2msb registrator can get the |
| 1128 | access to watch the kubernetes events and get service annotation by |
| 1129 | Kubernetes APIs. The token can be found in the kubectl configuration file |
| 1130 | *~/.kube/config* |
| 1131 | |
Eric Debeau | c4e405f | 2020-12-07 14:49:52 +0100 | [diff] [blame] | 1132 | More details can be found here `MSB installation <https://docs.onap.org/projects/onap-msb-apigateway/en/latest/platform/installation.html>`_. |
Roger Maitland | ac64381 | 2018-03-28 09:52:34 -0400 | [diff] [blame] | 1133 | |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 1134 | .. MISC |
| 1135 | .. ==== |
| 1136 | .. Note that although OOM uses Kubernetes facilities to minimize the effort |
Sylvain Desbureaux | 5b7440b | 2019-01-28 16:49:14 +0100 | [diff] [blame] | 1137 | .. required of the ONAP component owners to implement a successful rolling |
| 1138 | .. upgrade strategy there are other considerations that must be taken into |
| 1139 | .. consideration. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 1140 | .. For example, external APIs - both internal and external to ONAP - should be |
Sylvain Desbureaux | 5b7440b | 2019-01-28 16:49:14 +0100 | [diff] [blame] | 1141 | .. designed to gracefully accept transactions from a peer at a different |
| 1142 | .. software version to avoid deadlock situations. Embedded version codes in |
| 1143 | .. messages may facilitate such capabilities. |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 1144 | .. |
Sylvain Desbureaux | 5b7440b | 2019-01-28 16:49:14 +0100 | [diff] [blame] | 1145 | .. Within each of the projects a new configuration repository contains all of |
| 1146 | .. the project specific configuration artifacts. As changes are made within |
| 1147 | .. the project, it's the responsibility of the project team to make appropriate |
Roger Maitland | 953b5f1 | 2018-03-22 15:24:04 -0400 | [diff] [blame] | 1148 | .. changes to the configuration data. |