As a solutions architect, I spend a lot of my time talking to my customers about Kubernetes. In every one of those conversations, it’s guaranteed that the topic of Kubernetes Operators will come up. Operators, and their relationship to Red Hat OpenShift, aren't always clear to those who are just starting out on their container adoption journey.
Kubernetes has allowed the deployment and management of distributed applications to be heavily automated. A lot of that automation comes out of the box but Kubernetes wasn’t designed to know about all application types. So sometimes it’s necessary to extend the understanding of a specific type of application that Kubernetes has. Otherwise you have to manage a large part of these applications manually that ultimately defeats the purpose of deploying on Kubernetes. Operators allow you to capture how you can write code to automate a task beyond what Kubernetes itself provides.
This post assumes you know what Kubernetes is and how it works and have some knowledge of OpenShift. So what are Operators and why are they so important in explaining what Red Hat OpenShift is?
What are Kubernetes Operators?
Operators are Kubernetes-native applications that add additional knowledge and automation to complex apps. Operators enable software vendors to build their applications to run on top of Kubernetes.
Not only is Red Hat a creator and contributor to some of these projects, but we curate and support a number of them to create a best-in-class container platform.
In OpenShift, these “out of the box” Operators are called cluster Operators. They are installed on Red Hat’s distribution of Kubernetes, Red Hat OpenShift, to provide the functionality and features an enterprise needs from its container platform. From the software-defined network to the console, it’s Operators all the way down.
Red Hat OpenShift has 30 Operators out of the box
Cluster operators allow Red Hat to automate installations of Red Hat OpenShift in public or private cloud environments and provide core Day 2 functionality from the outset, including an automated, in-place upgrade process.
OpenShift features 30 Operators, which run each major part of the platform such as version control, ingress, cluster autoscaling and many others. These are fundamental components to have a stable, more secure, and scalable platform to work on. Out of the box, Red Hat includes Operators that make using and operating OpenShift in supported deployment environments the same.
So far, we’ve mainly concentrated on discussing the cluster Operators that Red Hat provides as part of Red Hat OpenShift, allowing you to install and manage a platform going forward. But what about those services that you want to install on your existing clusters to provide operational, development and other services? These can be written in-house or by third-party vendors which require Kubernetes to understand specific domain knowledge about an application (for example, MongoDB, KongEE, Istio, serverless, security or others).
Red Hat’s resources for Operator best practices
In creating and managing a large number of Operators in OpenShift, Red Hat realized there was a need for some best practices for managing app installs and updates on Kubernetes. So the Operator Framework was created, and we use this to certify vendor Operators that Red Hat OpenShift supports.
The framework includes a set of tools to aid in the development of Operators using technologies and language frameworks such as Ansible, Helm, GO or Java and their management, including cluster-admin control on access and installs and upgrade paths. These tools are called the Operator SDK and the Operator Lifecycle Manager (OLM), respectively. The OLM is installed on Red Hat OpenShift out of the box.
To do this on Kubernetes, you need the proper foundations to start. Installing some key Operators on top of any Kubernetes distribution without understanding how they work through updates and different environments is only going to make the adoption in your organization harder. As is going to the effort to build and use an Operator from scratch without a framework to support it.
The OLM fundamentally takes the pain out of writing, developing and managing Operators across multi-tenant Kubernetes clusters. These are tried and tested approaches, and doing it from scratch is really for those people who enjoy doing Kubernetes the hard way.
Kubernetes without Operators? No, thanks.
Without the OLM and the domain knowledge of every layer of the platform, managing Operators and thus the cluster(s) stability becomes really hard to maintain through updates and scale. You do not want to be left debugging Operators on clusters. And without Operators - well, Kubernetes becomes real hard work as you manually do the things an Operator would do to keep service(s) healthy.
So that's why I keep going on about them and if you want to get into this a bit more, I highly recommend reading the Kubernetes Operators ebook.저자 소개
As a solutions architect at Red Hat, Mustafa Musaji works with with large UK public sector customers in areas around cloud native software adoption and application migrations to the cloud. This involves the technical side of container adoption and orchestration--using tools like Kubernetes--as well as looking at the people and processes involved in using such technology. He believes understanding teams and organisation setups are important to succeeding with automation and DevOps.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.