Skipping stones on IBM Cloud Pak for Application deployment plan
Author: Sundaragopal Venkatraman,Venkatesh Kumaravel
IBM Cloud Pak for Applications is an enterprise-ready, containerized software solution for modernizing existing applications and developing new cloud-native apps that runs on Red Hat® OpenShift. IBM Cloud Pak for Application is getting widely adopted across client enterprises either on-premise or on public cloud platform.
Based on experiences in validating the plan for deploying the Cloud Pak for Applications, there were some common pain points that need to be addressed properly during planning stage else it may come haunting us later. This article will address the nuances of resolving those pain points.
Logging
There is a general presumption with customers that sizing for centralized logging framework such as ELK/EFK across workloads on their cluster has been duly considered with their master node sizing. It might have been earlier like that, however from OCP 4.3 onwards, there is no possibility of offloading any of the common framework(s) to Master nodes. Hence, it is imperative that the required infra sizing needs to be provisioned as infra nodes for logging. This helps in achieving the required workload segregation. Per se there is no infra nodes starting from OCP 4.x. You can mark some worker nodes as infra nodes to run these common frameworks.
As a rule of thumb, the ELK/EFK stack requires minimum 3 virtual machines for high availability which must be factored during the initial planning stage itself, from better planning perspective. There is also an option to provision the same post cluster deployment.
Monitoring
Prometheus/Grafana is used for analysing runtime utilization and monitoring of nodes, pods etc. To run these pods, necessary capacity must be factored in for the cluster based on cluster size. These monitoring stack can also be overlaid on infra nodes created on the cluster so that customer workload running on compute nodes do not get impacted.
Container Vulnerability Scanner
There are numerous tools available for container vulnerability scanning. Customers, who are running RH OCP cluster, have the liberty to use OpenSCAP for performing vulnerability assessment. Adequate sizing must be factored in for the scanner in order to avoid any costly overheads, during deployment timeframe. The scanner workloads can also be pushed to the infra nodes on the cluster. As Container Vulnerability itself is a huge topic, we will cover that in a follow up article
Conclusion:
In Summary, the sizing for common frameworks like logging, monitoring, Vulnerability scanning for the cluster must be planned and seggregated from the compute nodes requirement for the deployment. This will reduce the overhead on compute node as well as optimize the OCP entitlements. These infra nodes are not counted towards the total number of subscriptions that are required to run the environment.
