Vanakkam all
Red Hat Openshift product is exceptionally doing well in the market. Different industries started adopting Openshift along with opensource kubernetes solution – Finance, Telco, Healthcare, Entertainment industries etc. We also, recently placed few of our students in middleeast on Red hat Openshift Job.
Regarding migration from Kubernetes to Openshift, I would like to share one of my recent client experience.
Got a chance to provide consultation for one of the Healthcare firm. Kubernetes is running on both onprem and cloud environment. Its a 7 member team including the lead from India and 2 resources from US.
Listing few Kubernetes day to day tasks being handled by them :
- Kubernetes cluster installation
- Kubernetes Cluster upgrade
- Deploy applications
- Helm chart creation
- Namespace resource quota & limit range management
- Setting up monitoring & alerting
- Configure PV,PVC as appropriate
- Security & Access control
Common issues, tickets raised by developers, end users would be on :
- Resource management : CPU,Memory,Storage bottlenecks
- Application performance issues
- Networking issues : Either issue from external source, network policy errors, DNS resolution issues
- Volume mount issues : Persistent storage issues
- Cluster upgrade issues
- Rollbacks
- Unavailability of proper documentation
Practical issues : Senior resource dependency
While my client has experts & architects in Kubernetes, retaining the experts in the organization would be a practical challenge and the senior resource knowing solution for all issues is not possible too . During migration from traditional to Containerization, every organization will go through several process, analysis, fine tuning, sophisticated architecture, tools to adopt that environment and requirement.
- Rely upon team experts incase of any downtime
- Lack of proper documentation, will lead to knowledge gap on environment and related tools
- Attrition of senior resource will also be a contributing factor. Because new members in team, will have limited idea/skills to troubleshoot the kubernetes issues and the entire account would rely upon their skills to solve the issue. The downtime might get prolonged until the resource fixes the issue
A quote from my friend :
“When an engineering team introduces a new architecture or tool, it should always consider how operations will support it once it hits production“
Engineering is not something you design or introduce new tool just to satisfy your technology curiosity or broadcast about a change in your environment rather understand the problem statement properly and then go for it which will benefit the org/customer. The reason for stating above is, most of the time, team ends up in creating a sophisticated architecture and tool inclusion, but fails to handle the issue when there is a downtime - Lack of skillset or missing the right resources
Kubernetes CNI, DNS, Network issues:
- Team faces several issues on Kubernetes network
- Issues getting reported on CNI, DNS which results in application downtime
- The current team with limited knowledge, limited documentation is unable to handle the issue and this runs for more than 72 hours across all environment
- Due to opensource limitation, no product level support
Decision being made to migrate from Kubernetes :
- After all possible discussions on technical way out, Leadership decides to switch from Kubernetes to Red Hat Openshift
- Resource dependency gets minimized : Redhat features include enterprise support, Openshift webconsole, Easy navigation, easy updates, operators, monitoring etc with proper documentation
- By migrating to Red Hat openshift, even when the senior resources/team struggles to fix a problem, we can always raise a redhat support ticket and rely on Red Hat support too
- Also Ops team can rely upon the detailed Red Hat documentation