The hardware utilization for an ASAP cloud native deployment is approximately the same as that of the ASAP traditional deployment.

Consider the following when sizing for your cloud native deployment:

• For ASAP cloud native, ensure that the database is sized to account for work orders residing in the database. For details, see "ASAP Oracle Database Tablespace Sizing Requirements" in ASAP Installation Guide.

• Oracle recommends sizing using a configuration as a building block by adjusting the ASAP.cfg file to meet target order volumes.

  Note:

  Update the ASAP.cfg file when you build the ASAP image.

  For more details, see "Installing a Pre-tuned Configuration", in ASAP System Administrator's Guide.

• In addition to planning hardware for a production instance, Oracle recommends planning for a Disaster Recovery size and key non-production instances to support functional, integration, and performance tests. The Disaster Recovery instance can be created against an Active Data Guard Standby database when needed and terminated when no longer needed to improve hardware utilization.

• Non-production instances can likewise be created when needed, either against new or existing database instances.

Contact Oracle Support for further assistance with sizing.

This section describes how to secure the operations of ASAP and Order Balancer cloud native users in a Kubernetes cluster. A well-organized deployment of ASAP and Order Balancer cloud native ensures that individual users have specific privileges that are limited to the requirements for their approved actions. The Kubernetes objects concerned are service accounts and RBAC objects.

All ASAP and Order Balancer cloud native users fall into the following three categories:

• Infrastructure Administrator
• Project Administrator
• ASAP User

Infrastructure Administrator

Infrastructure Administrators perform the following operations:

• Create a project for ASAP and Order Balancer cloud native and configure the projects
• After creating a new project, run the register-namespace.sh script provided with the ASAP cloud native toolkit
• Before deleting the ASAP and Order Balancer cloud native projects, run the unregister-namespace.sh script
• Delete the ASAP and Order Balancer cloud native projects

Project Administrator

Project Administrators can perform all the tasks related to an instance level ASAP and Order Balancer cloud native deployments within a given project. This includes creating and updating ASAP and Order Balancer cloud native instances. A project administrator can work on one specific project. However, a given human user may be assigned Project Administrator privileges on more than one project.

RBAC Requirements

The RBAC requirements for Traefik is documented in its user guide. The Infrastructure Administrator must be able to create and delete name spaces and Traefik name space (if Traefik is used as the ingress controller). Depending on the specifics of your Kubernetes cluster and RBAC environment, this may require cluster-admin privileges.

The Project Administrator has limited RBAC privileges. For a start, it would be limited to only that project's name space. Further, it would be limited to the set of actions and objects that the instance-related scripts manipulate when run by the Project Administrator. This set of actions and objects is documented in the ASAP and Order Balancer cloud native toolkit sample located in the samples/charts/traefik/traefik-rbac directory.

Structuring Permissions Using the RBAC Sample Files

There are many ways to structure permissions within a Kubernetes cluster. There are clustering applications and platforms that add their own management and control of these permissions. Given this, the ASAP and Order Balancer cloud native toolkit provides a set of RBAC files as a sample. You will have to translate this sample into a configuration that is appropriate for your environment. These samples are in the samples/charts/traefik/traefik-rbac directory within the toolkit.

The key files are role.yaml and rolebinding.yaml. These files govern the basic RBAC for a Project Administrator.

Do the following with these files:

1. Make a copy of both these files for each particular project, renaming them with the project/namespace name in place of "project". For example, for a project called "biz", these files would be biz-admin-role.yaml and biz-admin-rolebinding.yaml.

2. Edit both the files, replacing all occurrences of project with the actual project/namespace name.

   For the rolebinding.yaml file, replace the contents of the "subjects" section with the list of users who will act as Project Administrators for this particular project.

   Alternatively, replace the contents with reference to a group that contains all users who will act as Project Administrators for this project.

3. Once both files are ready, they can be activated in the Kubernetes cluster by the cluster administrator using kubectl apply -f filename.

   It is strongly recommended that these files be version controlled as they form part of the overall ASAP cloud native configuration.