This is the first publication in a series of materials dedicated to the changes, improvements, and additions in the upcoming update of the Red Hat OpenShift platform to version 4.0, which will help prepare for the transition to the new version.
Since the moment representatives of the still-forming Kubernetes community gathered in the Google office in Seattle in the fall of 2014, it was clear that the Kubernetes project was destined to fundamentally alter modern approaches to software development and deployment. Meanwhile, public cloud service providers continued to invest heavily in infrastructure and services, significantly easing the process of IT operations and software creation, making them incredibly accessible — something few could have imagined even at the beginning of the decade.
Of course, the announcement of each new cloud service was accompanied by extensive discussions among experts on Twitter, with debates covering a wide range of topics — including the end of the open-source era, the decline of on-premises IT, the inevitability of a new software monopoly in the cloud, and how the new paradigm X would replace all others.
It goes without saying that all these debates were rather foolish.
The reality is that nothing is going anywhere, and today we can observe exponential growth in end products and the methods of their development, which is tied to the constant emergence of new software in our lives. And even though everything around will change, the essence of it all will remain unchanged. Software developers will still code with errors, operations engineers and reliability specialists will still carry pagers and receive alerts in Slack, managers will continue to operate with concepts of OpEx and CapEx, and each time there’s a failure, the senior developer will sigh wistfully and say, 'I told you so'...
What truly should be discussed, this is about the tools we can access to create higher quality software products, and how they enhance security while making development easier and more reliable. As project complexity increases, new risks emerge, and today, people's lives are so dependent on software that developers must strive to improve their work.
Kubernetes is one such tool. Efforts are underway to integrate it with other tools and services within Red Hat OpenShift into a unified platform that makes software more reliable, easier to manage, and secure for users.
Given this, the OpenShift team asks a simple question:
How can we make working with Kubernetes easier and more convenient?
The answer is surprisingly obvious:
- automate complex aspects of deployment in the cloud or on-premises;
- focus on reliability while concealing complexity;
- continue the ongoing effort to release simple and secure updates;
- achieve traceability and auditability;
- strive to ensure high security from the outset, but not at the cost of usability.
The next OpenShift release must consider both the experiences of its creators and the experiences of other developers deploying software at scale in the world's largest companies. Additionally, it should take into account the accumulated knowledge of open ecosystems that form the foundation of our modern world today. At the same time, it needs to shift away from the previous mindset of amateur developers and embrace a new philosophy of an automated future. This should be a 'bridge' between the old and new methods of software deployment while fully utilizing all available infrastructure – regardless of whether it is maintained by a major cloud provider or run on tiny edge systems.
How can we achieve this?
At Red Hat, it is customary to undertake long, tedious, and thankless work to preserve the established community and to prevent the closure of projects in which the company participates. The open-source community is home to a vast number of talented developers who create the most extraordinary things—entertaining, educational, opening new possibilities, and simply beautiful. However, of course, no one expects that all participants will move in the same direction or pursue common goals. Sometimes, channeling this energy in the right direction is necessary for developing areas that would benefit our users, but at the same time, we must monitor the development of our communities and learn from them.
In early 2018, Red Hat acquired the CoreOS project, which shared similar views on the future—creating a more secure and reliable environment built on open-source principles. The company worked on further developing these ideas and implementing them, embodying our philosophy—striving for the safe operation of all software. This work is built on Kubernetes, Linux, public clouds, private clouds, and thousands of other projects that form the foundation of our modern digital ecosystem.
The new release of OpenShift 4 will be intuitive, automated, and more natural.
The OpenShift platform will work with the best and most reliable Linux operating systems, offering bare-metal hardware support, convenient virtualization, automated infrastructure provisioning, and, of course, containers (which are essentially just Linux images).
The platform must be secure from the start while also enabling convenient iterations for developers—meaning it should have enough flexibility and reliability, yet still allow administrators to conduct audits and ensure ease of management.
It should allow software to run "as a service" without leading to uncontrolled infrastructure growth for operators.
It will allow developers to focus on creating real products for users and clients. There will be no need to wade through the complexities of hardware and software settings, and all random complications will be a thing of the past.
OpenShift 4: A NoOps platform that requires no maintenance.
In The tasks that helped shape the company's vision regarding OpenShift 4 are described. The team is tasked with simplifying daily operational and maintenance tasks to make these processes easy and relaxed – both for the specialists involved in the implementation and for the developers. But how can we approach this goal? How can we create a software deployment platform that requires minimal intervention? What does NoOps even mean in this context?
If we try to abstract away, for developers, the concepts of 'serverless' or 'NoOps' represent tools and services that allow the 'operational' component to be hidden or minimized for the developer.
- Work with application interfaces (APIs), not with systems.
- Don't handle software deployment – let the provider take care of it for you.
- Don't rush into creating a large framework – start by writing small fragments that will serve as 'building blocks,' and ensure that this code works with data and events, not with disks and databases.
The goal, as before, is to accelerate iterations in software development, enable the creation of higher quality products, and allow the developer not to worry about the systems on which their software runs. An experienced developer understands well that if they focus on users, the landscape can change quickly, so one should not invest too much effort in writing software without absolute confidence in its necessity.
For professionals involved in maintenance and operations, the term 'NoOps' might sound a bit daunting. However, during discussions with operations engineers, it becomes clear that the patterns and methodologies they employ for ensuring reliability (Site Reliability Engineering, SRE) often resonate with the patterns described above:
- Don't manage systems – automate the management processes.
- Don't focus on deploying software – create a pipeline for its deployment.
- Avoid combining all your services together and ensure that the failure of one does not lead to the failure of the entire system – distribute them across the infrastructure using automation tools, and connect them with monitoring and oversight in mind.
SRE specialists understand that something can go wrong, and they will need to track down and resolve issues – that's why they automate routine tasks and pre-define acceptable deviations (error budgets) to be prepared for prioritization and decision-making when problems arise.
Kubernetes in OpenShift is a platform designed to address two main tasks: instead of forcing you to grapple with virtual machines or load balancer APIs, it works with higher-level abstractions – with deployment processes and services. Instead of installing software agents, you can run containers, and instead of writing your own monitoring stack, use the tools already available in the platform. Thus, the secret ingredient of OpenShift 4 is actually not a secret at all – it’s simply about adopting the principles of SRE and serverless concepts and bringing them to fruition to aid developers and operations engineers.
- Automate and standardize the infrastructure used by applications.
- Connect deployment and development processes together without restricting the developers themselves.
- Ensure that launching, auditing, and securing the hundredth service, function, application, or entire stack is no more complicated than the first.
But what is the difference between the OpenShift 4 platform and its predecessors, as well as the 'standard' approach to solving similar problems? How is scaling achieved for teams involved in deployment and operations? The answer lies in the fact that the king in this situation is the cluster. So,
- We make sure that the purpose of the clusters is clear (Expensive cloud, this cluster was created because I could)
- Machines and operating systems exist to serve the cluster (Your Majesty)
- Manage the state of hosts from the cluster, minimizing their drift.
- For every important element of the system, a caretaker (mechanism) is needed to monitor and resolve issues
- The failure of *every* aspect or element of the system is a normal part of life for the corresponding recovery mechanisms
- The entire infrastructure should be configured via API.
- Use Kubernetes to run Kubernetes. (Yes, this is not a typo)
- Updates should be installed easily and effortlessly. If updating requires more than one mouse click, then clearly we are doing something wrong.
- Monitoring and debugging any component should not be a problem, and tracking and reporting across the entire infrastructure should also be simple and convenient.
Want to see the platform's capabilities in action?
The preview version of OpenShift 4 has become available for developers. With an easy-to-use installer, you can launch a cluster on AWS atop Red Hat CoreOS. To take advantage of the preview version, you only need an AWS account to provide the infrastructure and a set of accounts to access the preview images.
- To get started, visit and click 'Get Started.'
- Log in to your Red Hat account (or create a new one) and follow the instructions to set up your first cluster.
After a successful installation, take a look at our training materials , to gain a more detailed understanding of the systems and concepts that make the OpenShift 4 platform such a simple and convenient tool for running Kubernetes.
Try the new OpenShift release and share your feedback. We aim to make working with Kubernetes as accessible and effortless as possible – the future of NoOps begins today.
And now, pay attention!
At the conference On April 20, one of the OpenShift developers, Vadim Rutkovsky, will conduct a master class — breaking ten clusters and getting them fixed. The conference is paid, but with the promo code #RedHat, you get a 37% discount.
The master class will run from 5:15 PM to 6:15 PM, and the booth will operate all day. T-shirts, hats, stickers — as usual!
Hall #2
‘The entire system needs to be changed: we are fixing broken k8s clusters together with certified technicians.’
Source: habr.com
