OpenShift 운영

9장. 클러스터 운영 자동화를 위한 사용자 지정 오퍼레이터 개발하기

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

마누엘 드발트

모든 OpenShift 클러스터의 핵심은 일련의 컨트롤러를 실행하여 클러스터가 관리하는 리소스의 원하는 상태를 실제 상태로 전환하기 위해 끊임없이 노력합니다.

제어 루프의 각 실행은 실제 상태를 원하는 상태에 가깝게 만드는 것을 목표로 합니다. 원하는 상태는 OpenShift 리소스에서 선언적으로 정의됩니다. 제어 루프는 실제 상태를 확인하고 원하는 상태에 한 걸음 더 가까이 가기 위해 어떤 작업이 필요한지 파악할 수 있습니다.

실제 상태는 다양한 소스에서 읽을 수 있으며, 리소스의 목적에 따라 많은 경우 API 서버를 쿼리하여 가져올 수 있습니다.

좋은 예는 레플리카셋과 파드 간의 관계이다. 레플리카셋은 지정된 사양의 파드 수를 정의합니다. 레플리카셋이 관리하는 모든 파드는 공통 레이블로 식별할 수 있습니다. 제어 루프는 이 레이블이 있는 실제 파드 수를 API 서버에 쿼리할 수 있습니다. 그 수가 레플리카셋 리소스에 정의된 원하는 수보다 낮으면, 그 수가 일치할 때까지 더 많은 파드를 시작할 수 있습니다.

레플리카셋이 축소되면, 제어 루프는 레플리카셋이 원하는 것보다 갑자기 더 많은 파드가 있다는 것을 파악하고 API 서버에 DELETE 호출을 통해 일부 파드를 삭제합니다.

제어 루프는 끝없이 실행되며 원하는 상태와 실제 상태를 비교하므로, 파드가 수동으로 삭제되더라도 제어 루프가 새 파드를 생성하여 레플리카셋의 원하는 상태가 실제 상태와 일치하도록 합니다.

제어 루프는 클러스터 내부 구성 요소와 통신하여 실제 상태를 쿼리하고 조작할 수 있을 뿐만 아니라 클라우드 공급자와 같은 외부 구성 요소와 통신할 수도 있습니다. 예를 들어, 클라우드 공급자에 배포된 클러스터에 LoadBalancer와 같은 서비스가 생성되면 일반적으로 컨트롤러는 클라우드 공급자와 통신하여 LoadBalancer 리소스를 생성합니다. 이 작업이 완료되면 서비스 리소스 상태가 업데이트되므로 다른 구성 요소가 클라우드 공급자에게 직접 쿼리하지 않아도 외부 IP 주소 등 LoadBalancer의 세부 정보를 조회할 수 있게 됩니다.

이 메커니즘은 필요한 인스턴스 수 결정, 컨테이너 이미지의 새 버전 롤아웃 등 운영자가 수동으로 수행해야 하는 작업을 자동화하는 데 도움이 되는 OpenShift와 Kubernetes의 강력한 측면입니다.

이 무궁무진한 컨트롤러를 통해 작업을 더 쉽게 만들어주는 오퍼레이터에게 경의를 표하기 위해 이 패러다임을 오퍼레이터 패턴이라고도 합니다.

OpenShift 클러스터의 인간 운영자는 Operator 패턴의 메커니즘을 활용하여 OpenShift 컨트롤 플레인에서 아직 자동화되지 않은 작업을 자동화할 수도 있습니다. 이를 위해 사용자 지정 운영자를 구축하여 OpenShift 클러스터에 배포할 수 있습니다.

이 책을 통해 이미 다양한 ...