KR102114339B1 - 액티브/스탠바이 모델을 지원하는 쿠버네티스 시스템의 동작 방법 - Google Patents

Abstract

본 발명에 따른 액티브/스탠바이 모델을 지원하는 쿠버네티스 시스템의 동작 방법은, 모니터링 프로세서에서 복수의 포드(pod)들의 오류 상태를 점검하는 단계, 상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 액티브 포드(active pod)가 존재하는 지를 판별하는 단계, 및 상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 상기 액티브 포드가 존재하지 않을 때, 상기 오류 상태를 점검한 결과로써 상기 복수의 포드들 중에서 오류가 존재하지 않는 어느 하나의 포드를 액티브 포드로 설정 변경하도록 쿠버네티스 서버로 요청하는 단계를 포함할 수 있다.

Description

액티브/스탠바이 모델을 지원하는 쿠버네티스 시스템의 동작 방법{METHOD FOR OPERATING KUBERNETES SYSTEM SUPPORTING ACTIVE/STANDBY MODEL}

본 발명은 액티브/스탠바이 모델을 지원하는 쿠버네티스 시스템의 동작 방법에 관한 것이다.

Kubernetes는 대규모 컨테이너식 애플리케이션을 배포하고 관리할 수 있도록 지원하는 오픈 소스 소프트웨어이다. Kubernetes는 Amazon EC2 컴퓨팅 인스턴스의 클러스터를 관리하고 배포, 유지 관리 및 규모 조정의 프로세스를 통해 이러한 인스턴스에서 컨테이너를 실행한다. Kubernetes를 사용하면 온프레미스와 클라우드에서 같은 도구 세트를 사용하여 원하는 유형의 컨테이너식 애플리케이션을 실행할 수 있다.

Kubernetes 클러스터는 컨테이너를 실행하는 EC2 컴퓨팅 인스턴스의 논리적 그룹이다. 클러스터는 컨트롤 플레인(컨테이너가 언제, 어떻게, 어디에서 실행되는지 제어하는 인스턴스)과 데이터 플레인(컨테이너가 실행되는 인스턴스)으로 구성된다. Kubernetes로 컨테이너 또는 서비스를 실행하기 전에 클러스터를 정의해야 한다. Kubernetes 노드는 Kubernetes 클러스터의 일부인 단일 컴퓨팅 인스턴스(가상 머신)이다. 인스턴스에는 마스터와 작업자라는 두 가지 유형이 있다. 마스터는 Kubernetes API 서버를 호스팅하고 컨테이너가 언제, 어떻게, 어디에서 실행되는지 제어한다. 작업자는 컨테이너가 실제로 실행되고 데이터를 처리하는 컴퓨팅 인스턴스이다. Kubernetes 팟은 Kubernetes가 컴퓨팅 인스턴스에서 컨테이너를 실행하는 방법이다. 여기에는 컨테이너와 컨테이너가 어떻게 실행되고, 네트워킹되고, 저장되어야 하는지에 대한 사양이 포함되어 있다. 팟은 단일 컨테이너일 수도 있고 항상 함께 실행되는 다수의 컨테이너일 수도 있다. 일반적으로 단일 컨테이너를 실행한다면 팟을 실행 컨테이너로 생각한다. etcd는 머신의 분산 클러스터 전체에 걸쳐 데이터를 저장 및 공유할 수 있게 해주는 분산 키 값 스토어이다. Kubernetes는 etcd를 사용하여 클러스터에 대한 데이터를 저장하고 Kubernetes 컨트롤 플레인 전체에서 이를 공유한다.

본 발명의 목적은 신규한 쿠버네티스 시스템의 동작 방법을 제공하는데 있다.

본 발명의 실시 예에 따른 액티브/스탠바이 모델을 지원하는 쿠버네티스 시스템의 동작 방법은: 모니터링 프로세서에서 복수의 포드(pod)들의 오류 상태를 점검하는 단계; 상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 액티브 포드(active pod)가 존재하는 지를 판별하는 단계; 및 상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 상기 액티브 포드가 존재하지 않을 때, 상기 오류 상태를 점검한 결과로써 상기 복수의 포드들 중에서 오류가 존재하지 않는 어느 하나의 포드를 액티브 포드로 설정 변경하도록 쿠버네티스 서버로 요청하는 단계를 포함할 수 있다.

실시 예에 있어서, 상기 쿠버네티스 서버로부터 상기 복수의 포드들에 대한 상태 정보를 수신하는 단계를 더 포함할 수 있다.

실시 예에 있어서, 상기 모니터링 프로세서는 상기 쿠버네티스 서버로부터 상기 상태 정보를 주기적으로 전송 받는 것을 특징으로 한다.

실시 예에 있어서, 상기 오류 상태를 점검하는 단계는, 상기 복수의 포드들의 각각에 대하여 복수의 오류 검사를 수행하는 단계를 포함할 수 있다.

실시 예에 있어서, 상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 상기 액티브 포드가 하나 존재할 때, 상기 존재하는 액티브 포드의 오류를 검사하고, 상기 검사 결과로써 상기 존재하는 액티브 포드가 오류일 때, 대응하는 포드를 스탠바이 포드로 설정 변경하도록 상기 쿠버네티스 서버로 요청하는 단계를 더 포함할 수 있다.

실시 예에 있어서, 상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 상기 액티브 포드가 복수로 존재할 때, 상기 존재하는 복수의 포드들 중에서 어느 하나를 제외한 나머지 포드들을 스탠바이 포드로 설정 변경하도록 상기 쿠버네티스 서버로 요청하는 단계를 더 포함할 수 있다.

본 발명의 실시 예에 따른 쿠버네티스 시스템의 동작 방법은 kuberntes에서 지원하지 않는 active/standby 모델을 지원함으로써, 고가용성 서비스를 위한 기능을 제공하고, 사용자가 직접 관리하지 않아도 되어 작업 효율을 높일 수 있고, 또한 기존의 초단위로 체크하는 방식에서 밀리초 단위로 확장하여 고가용성을 증가시킬 수 있다.

이하에 첨부되는 도면들은 본 실시 예에 관한 이해를 돕기 위한 것으로, 상세한 설명과 함께 실시 예들을 제공한다. 다만, 본 실시예의 기술적 특징이 특정 도면에 한정되는 것은 아니며, 각 도면에서 개시하는 특징들은 서로 조합되어 새로운 실시 예로 구성될 수 있다.
도 1은 일반적인 마이크로서비스 시스템의 관심사를 예시적으로 보여주는 도면이다.
도 2는 쿠버네티스 가시화 메타 모델을 예시적으로 보여주는 도면이다.
도 3은 본 발명의 실시 예에 따른 쿠버네티스 시스템(10)을 예시적으로 보여주는 도면이다.
도 4는 본 발명의 실시 에에 따른 쿠버네티스 시스템(10)의 동작 방법을 예시적으로 보여주는 흐름도이다.

아래에서는 도면들을 이용하여 본 발명의 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있을 정도로 본 발명의 내용을 명확하고 상세하게 기재할 것이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 형태를 가질 수 있는바, 특정 실시 예들을 도면에 예시하고 본문에 상세하게 설명하고자 한다. 그러나 이는 본 발명을 특정한 개시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 제 1, 제 2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다.

상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로 사용될 수 있다. 예를 들어, 본 발명의 권리 범위로부터 이탈되지 않은 채 제 1 구성요소는 제 2 구성요소로 명명될 수 있고, 유사하게 제 2 구성요소도 제 1 구성요소로 명명될 수 있다. 어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 혹은 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

구성요소들 간의 관계를 설명하는 다른 표현들, 즉 "~사이에"와 "바로 ~사이에" 혹은 "~에 이웃하는"과 "~에 직접 이웃하는" 등도 마찬가지로 해석되어야 한다. 본 출원에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.

본 출원에서, "포함하다" 혹은 "가지다" 등의 용어는 실시된 특징, 숫자, 단계, 동작, 구성요소, 부분품 혹은 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 혹은 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부분품 혹은 이들을 조합한 것들의 존재 혹은 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다. 다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미이다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미인 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

도 1은 일반적인 마이크로서비스 시스템의 관심사를 예시적으로 보여주는 도면이다. 마이크로서비스 아키텍처(MSA)는 단일 응용 프로그램을 작은 서비스 단위로 나누어 각 개별 서비스가 독립적인 프로세스에서 실행하고 서로 경량 통신 메커니즘으로 통신하는 서비스의 조합을 구축하는 방법이라고 정의하였다. 마이크로서비스 시스템을 구축하는데 다루어야 하는 가장 일반적인 기술적 고려 사항은 도 1에 도시된 바와 같다.

쿠버네티스(Kubernetes)는 혹은 간단히 '큐브(kube)'는 구글 제품이 컨테이너에서 어떻게 작동하는지 공개된 것이다. 쿠버네티스는 리눅스 컨테이너 작업을 자동화하는 오픈 소스 플랫폼으로써 배치 자동화, 자동 스케일링 및 복구 등 마이크로서비스 시스템에서 다루어야 하는 작업들에 대하여 자동화 솔루션을 제공한다. 쿠버네티스는 쿠버네티스 리소스 오브젝트로 도 1에 도시된 작업들과 그들의 작동 방식을 정의한다.

예를 들면 RC 오브젝트를 통하여 애플리케이션의 복사본 개수를 지정할 수 있다. 쿠버네티스 리소스 오브젝트는 보통 YAML 문서로 정의된다. YAML는 사람에게 XML와 JSON보다 더욱 쉽게 읽을 수 있는 데이터 직렬화 양식이다. 마이크로서비스 아키텍처 스타일은 높은 확장성과 뛰어난 내결함성 등 이점을 가지고 있지만 보통 수백 개 서비스 또는 수천 개 서비스와 도 1에서 도시된 작업들을 수행하는 컴포넌트들을 포함하는 복잡한 구조로 구성되므로 시스템 전체 구조와 시스템의 각 컴포넌트 간의 관계를 파악하는데 상당히 어려워진다는 단점도 갖게 된다. 시스템 가시화는 이 단점을 극복하기 위하여 흔히 사용하는 방법이다.

쿠버네티스를 통하여 쉽게 마이크로서비스 시스템을 구축할 수 있지만 시스템을 가시화할 수 없다. 즉 UML과 같은 가시화된 모델로 시스템을 설계하는 방식과 기존 YAML 문서로 정의된 시스템을 가시화된 모델로 전환하는 기능을 지원하지 않았다. 최근에 쿠버네티스를 기반하는 마이크로서비스 시스템을 가시화하 방법을 제안되고 있다.

도 2는 쿠버네티스 가시화 메타 모델을 예시적으로 보여주는 도면이다. 도 2를 참조하면, 쿠버네티스 가시화 메타 모델을 기초로 시스템 가시화하는 방안 두 가지를 모두 구현되었다. 도 2에 도시된 메타 모델의 각 원소의 의미를 설명하기 위하여 아래 시나리오를 제시하였다. 사용자가 먼저 API 게이트웨이 역할을 하는 Ingress 오브젝트를 접근한다. Ingress가 사용자의 요청을 해당 서비스에게 포워딩 한다.

해당 서비스가 특정 규칙에 따라 묶인 pod들에게 사용자의 요청을 전달한다. 쿠버네티스의 pod는 MSA 시스템의 최소 단위인 마이크로서비스로 취급할 수 있으며 도커(docker)와 같은 컨테이너들의 집합이다. 즉 pod 속에서 동시에 여러 컨테이너들을 실행한다. 또한 이 컨테이너들은 서로 로컬 호스트로 통신한다. MSA 스타일 시스템에는 트랜잭션이 항상 여러 서비스에 걸쳐 있으며 pod가 다른 서비스와 통신하여야 하는 경우가 많다. 이럴 때에 pod는 Kube-dns 또는 CoreDNS가 제공하는 서비스 발견에 의하여 다른 서비스의 이름만 가지고 다른 서비스와 통신할 수 있다. 즉 다른 서비스와 통신하는데 다른 서비스의 IP 주소를 알 필요는 없다.

쿠버네티스 서비스 오브젝트는 본질적으로 pod들의 부하 분산(로드 밸런싱) 작업을 담당한다. 또한 서비스 발견의 플래그 역할도 한다. MSA 스타일 시스템에는 보통 하나의 서비스 오브젝트가 하나의 pod 또는 이 pod의 여러 개 복사본을 묶어서 서비스를 제공한다.

쿠버네티스에는 5가지 pod를 지정할 수 있는데 상태를 가지는 pod, 상태가 없는 pod, 데몬 pod, 주기적 pod, 일회용 pod이다. 이에 상응하여 관리자가 StatefulSets, Deployment, DeamonSet, CronJob, Job 오브젝트를 이용하여 새로운 pod를 생성할 수 있다.

관리자가 pod를 정의하는데 필요한 환경 변수, 배치 파일과 API 키는 ConfigMap와 Secret 오브젝트로 지정한다. 이를 테면 스프링 애플리케이션 구축할 때 필요한 XML 배치 파일들을 ConfigMap에서 정의할 수 있다. Secret은 자신에 정의된 데이터를 암호화하므로 주로 API 키 등 민감한 변수를 정의할 때 사용한다.

pod에는 데이터나 파일을 저장할 수 있지만 pod가 업그레이드되거나 다른 노드에 옮기게 되면 모두 데이터가 사라진다. MSA 스타일 시스템에는 서비스를 업그레이드하거나 부하에 따라 서비스를 다른 노드에 옮기는 것이 일반적이다. 이로 인하여 영구적 데이터 저장소가 필요하다. 쿠버네티스는 PV와 StorageClass 오브젝트를 제공한다. PV와 StorageClass는 모두 다 영구적 데이터 저장 공간을 정의할 수 있다. 하지만 PV는 미리 정적으로 필요한 데이터 공간을 지정해야 하고 StorageClass는 pod의 요청에 따라 동적으로 데이터 저장 공간을 확보하여야 한다. 또한 쿠버네티스에서 pod가 PV와 StorageClass를 접근하려면 PVC 오브젝트를 이용해야 한다. pod의 자원 요청은 PVC에서 정의한다.

관리자가 시스템을 정의하고 배치한 다음에는 Easyk8s가 EFK stack 플러그인을 이용하여 분산되어 있는 로그를 수집한다, 또한 Prometheus를 이용하여 시스템의 하드웨어를 모니터링하고 Zipkin를 이용하여 분산 추적 작업을 한다.

일반적으로 Kubernetes에서 실행되는 프로그램은　Linux 컨테이너로 패키지 된다.　컨테이너는 널리 인정되는 표준이므로 이미　Kubernetes에 배포 할 수 있는　미리 빌드 된 이미지　가 많이 있다. 컨테이너화를 통해 자체 포함된 Linux 실행 환경을 만들 수 있다.　모든 프로그램 및 모든 종속성을 단일 파일로 묶어 인터넷에서 공유 할 수 있다.　누구나 컨테이너를 다운로드 하여 인프라에 배포 할 수 있다.　컨테이너 작성은 프로그래밍 방식으로 수행 할 수 있으므로 강력한　CI 및 CD　파이프 라인을 구성 할 수 있다. Kubernetes는 컨테이너를 직접 실행하지 않는다.　대신 하나 이상의 컨테이너를　포드(pod)　라고 하는 상위 레벨 구조로 래핑 한다.　동일한 pod에 있는 모든 컨테이너는 동일한 자원과 로컬 네트워크를 공유한다.　컨테이너는 다른 컨테이너와 일정 수준의 격리 상태를 유지하면서 같은 머신에 있는 것처럼 동일한 포드의 다른 컨테이너와 쉽게 통신 할 수 있다.

포드는 Kubernetes에서 복제 단위로 사용된다.　응용 프로그램이 너무 많이 사용되고 단일 포드 인스턴스가 로드를 전달할 수 없는 경우, 필요에 따라 포드의 새 복제본을 클러스터에 배포하도록 Kubernetes를 구성 할 수 있습니다.　부하가 과중하지 않은 경우에도 생산 시스템에서 언제든지 로드 밸런싱 및 오류 방지를 위해 여러 개의 포드 사본을 실행하는 것이 표준이다.

앞에서 언급하였듯이, Kubernetes는 컨테이너 가상화와 클러스터 구성을 효율적으로 관리할 수 있는 오픈소스 플랫폼이다. 클러스터 환경에서는 노드의 고장 확인 및 복구 시스템이 중요한 기능 중 하나이다. Kubernetes는 컨테이너의 불량상태를 체크하고 불량을 확인하였을 시 복구하는 기능을 제공한다.

하지만 고가용성을 목표로 하는 서비스에서는 서비스 장애시 빠른 복구를 위해 예비 서비스를 미리 실행하여 현재 서비스의 장애시 예비 서비스로 대체하는 모델을 적용한다. 이를 active/standby 모델이라 하며 현재 서비스 되고 있는 컨테이너가 active 컨테이너, 예비 서비스를 실행하는 컨테이너가 standby 컨테이너가 된다. 하지만 일반적인 kubernetes는 active/standby 모델을 지원하지 않는다. 따라서 사용자는 active/standby 모델을 적용하기 위해 container 마다 직접 관련 소프트웨어를 설치 운영해야 하는 문제점을 갖는다. 또한, standby 컨테이너를 생성하기 위해선 kubernetes의 replication 기능을 사용하게 되는데, kubernetes에선 네트워크 트래픽을 replication 된 컨테이너끼리 분산하기 때문에 이를 막기 위해선 특정 조건하에서 네트워크를 차단하는 readiness probe 기능을 사용해야 문제점이 있다. 이러한 문제는 특정 조건을 체크하는 주기를 초단위로만 지원하여 가용성이 떨어지며, 이 설정을 위해 사용자가 추가적인 작업을 해주어야 한다.

도 3은 본 발명의 실시 예에 따른 쿠버네티스 시스템(10)을 예시적으로 보여주는 도면이다. 도 3을 참조하면, 쿠버네티스 시스템(10)은 kubernetes에 active/standby 모델 적용하기 위하여 kubernetes 서버(100)와 이를 모니터링 할 모니터링 프로세서(200)를 포함할 수 있다. 도 3에서는 설명의 편의를 위하여 kubernetes 서버(100)가 2개의 pod들(110, 120)을 포함하고 있다고 도시된다. 하지만, pod의 개수가 여기에 제한되지 않는다고 이해되어야 할 것이다.

일반적으로 Kubernetes는 pod을 이용하여 container를 생성할 수 있다. Pod은 pod의 이름과 label 속성으로 구분할 수 있다. 모니터링 프로세서(200)는 pod의 label을 검사하여 active/standby pod을 구분하고 active pod에 오류가 발생한 경우 새로운 active pod을 지정할 수 있다.

active/standby 모델을 적용하기 위해선 active pod에만 네트워크 통신이 가능해야 한다. 이는 kubernetes에서 selector 옵션을 설정하는 것으로 특정 label이 존재하는 pod에만 네트워크를 연결할 수 있도록 설정할 수 있다. 따라서 active label이 설정된 pod에 네트워크를 연결하도록 selector 옵션을 설정하고, 모니터링 프로세서를 통해 label을 관리함으로써 active/standby 모델의 적용이 완성될 수 있다.

모니터링 프로세서(200)는 pod의 label을 통해 active/standby pod을 구분할 수 있다. 여기서 pod의 Label에는 active나 standby에 해당하는 문자열이 지정되어 있다. active label이 설정된 pod은 active pod, standby label이 설정된 pod은 standby pod으로 불릴 수 있다. 한편, 어느 것도 설정되지 않은 pod은 active/standby 모델이 적용되지 않는 것으로 간주될 수 있다.

실시 예에 있어서, active/standby label이 확인된 pod의 경우 다음의 세 가지 상황을 처리할 수 있다.

첫째로, active pod이 존재하지 않는 경우, 임의의 준비된 pod는 active pod으로 설정될 수 있다. 여기서 준비된 pod는 3번의 오류 검사를 통해 오류가 없음이 확인된 pod일 수 있다. 한편, 본 발명이 3 번의 오류 검사에 제한되지 않는다고 이해되어야 할 것이다.

둘째로, active pod이 오류 체크를 통해 오류로 판명된 경우, 대응하는 pod는 standby pod으로 변경되고, 새로운 active pod가 설정될 수 있다.

셋째로, active pod이 복수 존재하는 경우 임의의 준비된 pod 하나를 제외한 나머지 pod는 standby pod으로 설정될 수 있다. 이런 상황은 pod의 초기 생성시 발생될 수 있다.

실시 예에 있어서, 모니터링 프로세서(200)는 kubernetes 서버(100)로부터 pod 상태를 주기적으로 전달받고, active/standby pod의 오류 상태를 검사할 수 있다. 실시 예에 있어서, 검사 간격은 밀리 초 단위로 이루어질 수 있다. 하지만, 본 발명의 검사 간격이 여기에 제한되지 않는다고 이해되어야 할 것이다.

실시 예에 있어서, 모니터링 프로세서(200)는 active/standby pod의 변동 사항이 발생할 경우 kubernetes 서버(100)에 pod label 설정의 변경을 요청할 수 있다.

실시 예에 있어서, 모니터링 프로세서(200)는 kubernetes 서버(100)로부터 pod 상태를 주기적으로 전달 받을 수 있다. 실시 예에 있어서, 사용자는 active/standby 모델이 적용된 pod을 생성하기 위해서 pod 생성시 active label을 지정해 줄 수 있다.

한편, active/standby 모델을 사용하기 위해선 최소 2개 이상의 replication pod이 필요하다. kubernetes에선 replication pod의 생성시 각 pod마다 다른 label을 부여할 수 없으므로 active label이 할당될 수 있다.

도 4는 본 발명의 실시 에에 따른 쿠버네티스 시스템(10)의 동작 방법을 예시적으로 보여주는 흐름도이다. 도 1 내지 도 4를 참조하면, 쿠버네티스 시스템(10)의 동작 방법은 다음과 같다.

모니터링 프로세서(200)는 쿠버네티스 서버(100)의 복수의 pod의 라벨을 읽고, 읽혀진 라벨로부터 pod 오류 상태를 검사 할 수 있다(S110). 모니터링 프로세서(200)는 검사 결과에 따라 적어도 하나의 pod의 active/standby 라벨을 설정할 수 있다(S120).

본 발명에 따른 단계들 및/또는 동작들은 기술분야의 통상의 기술자에 의해 이해될 수 있는 것과 같이, 다른 순서로, 또는 병렬적으로, 또는 다른 에포크(epoch) 등을 위해 다른 실시 예들에서 동시에 일어날 수 있다.

실시 예에 따라서는, 단계들 및/또는 동작들의 일부 또는 전부는 하나 이상의 비-일시적 컴퓨터-판독가능 매체에 저장된 명령, 프로그램, 상호작용 데이터 구조(interactive data structure), 클라이언트 및/또는 서버를 구동하는 하나 이상의 프로세서들을 사용하여 적어도 일부가 구현되거나 또는 수행될 수 있다. 하나 이상의 비-일시적 컴퓨터-판독가능 매체는 예시적으로 소프트웨어, 펌웨어, 하드웨어, 및/또는 그것들의 어떠한 조합일 수 있다. 또한, 본 명세서에서 논의된 "모듈"의 기능은 소프트웨어, 펌웨어, 하드웨어, 및/또는 그것들의 어떠한 조합으로 구현될 수 있다.

본 발명의 실시 예들의 하나 이상의 동작들/단계들/모듈들을 구현/수행하기 위한 하나 이상의 비-일시적 컴퓨터-판독가능 매체 및/또는 수단들은 ASICs(application-specific integrated circuits), 표준 집적 회로들, 마이크로 컨트롤러를 포함하는, 적절한 명령들을 수행하는 컨트롤러, 및/또는 임베디드 컨트롤러, FPGAs(field-programmable gate arrays), CPLDs(complex programmable logic devices), 및 그와 같은 것들을 포함할 수 있지만, 여기에 한정되지는 않는다.

본 발명의 실시 예에 따른 쿠버네티스 시스템 및 그것의 동작 방법은 kuberntes에서 지원하지 않는 active/standby 모델을 지원할 수 있다. 이를 통해 고가용성 서비스를 위한 기능이 제공되고, 사용자가 직접 관리하지 않아도 되어 작업 효율을 높일 수 있다. 또한 기존의 초단위로 체크하는 방식에서 밀리초 단위로 확장하여 고가용성이 증가될 수 있다.

한편, 상술 된 본 발명의 내용은 발명을 실시하기 위한 구체적인 실시 예들에 불과하다. 본 발명은 구체적이고 실제로 이용할 수 있는 수단 자체뿐 아니라, 장차 기술로 활용할 수 있는 추상적이고 개념적인 아이디어인 기술적 사상을 포함할 것이다.

0: 쿠버네티스 시스템
100: 쿠버네티스 서버
200: 모니터링 프로세서

Claims (6)

1. 액티브/스탠바이 모델을 지원하는 쿠버네티스 시스템의 동작 방법에 있어서:
   모니터링 프로세서에서 복수의 포드들의 오류 상태를 점검하는 단계;
   상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 액티브 포드가 존재하는지 판별하는 단계; 및
   상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 상기 액티브 포드가 존재하지 않을 때, 상기 오류 상태를 점검한 결과로써 상기 복수의 포드들 중에서 오류가 존재하지 않는 어느 하나의 포드를 액티브 포드로 설정 변경하도록 쿠버네티스 서버로 요청하는 단계를 포함하는 방법.
2. 제 1 항에 있어서,
   상기 쿠버네티스 서버로부터 상기 복수의 포드들에 대한 상태 정보를 수신하는 단계를 더 포함하는 방법.
3. 제 2 항에 있어서,
   상기 모니터링 프로세서는 상기 쿠버네티스 서버로부터 상기 상태 정보를 주기적으로 전송 받는 것을 특징으로 하는 방법.
4. 제 1 항에 있어서,
   상기 오류 상태를 점검하는 단계는, 상기 복수의 포드들의 각각에 대하여 복수의 오류 검사를 수행하는 단계를 포함하는 방법.
5. 제 1 항에 있어서,
   상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 상기 액티브 포드가 하나 존재할 때, 상기 존재하는 액티브 포드의 오류를 검사하고, 상기 검사 결과로써 상기 존재하는 액티브 포드가 오류일 때, 대응하는 포드를 스탠바이 포드로 설정 변경하도록 상기 쿠버네티스 서버로 요청하는 단계를 더 포함하는 방법.
6. 제 1 항에 있어서,
   상기 모니터링 프로세서에서 상기 복수의 포드들 중에서 상기 액티브 포드가 복수로 존재할 때, 상기 존재하는 복수의 포드들 중에서 어느 하나를 제외한 나머지 포드들을 스탠바이 포드로 설정 변경하도록 상기 쿠버네티스 서버로 요청하는 단계를 더 포함하는 방법.

Images