KR102591865B1 - 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법 - Google Patents

컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법 Download PDF

Info

Publication number
KR102591865B1
KR102591865B1 KR1020230086902A KR20230086902A KR102591865B1 KR 102591865 B1 KR102591865 B1 KR 102591865B1 KR 1020230086902 A KR1020230086902 A KR 1020230086902A KR 20230086902 A KR20230086902 A KR 20230086902A KR 102591865 B1 KR102591865 B1 KR 102591865B1
Authority
KR
South Korea
Prior art keywords
container
processor
container image
definition
server
Prior art date
Application number
KR1020230086902A
Other languages
English (en)
Inventor
이용운
박인상
Original Assignee
주식회사 이글루코퍼레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 이글루코퍼레이션 filed Critical 주식회사 이글루코퍼레이션
Priority to KR1020230086902A priority Critical patent/KR102591865B1/ko
Application granted granted Critical
Publication of KR102591865B1 publication Critical patent/KR102591865B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/565—Static detection by checking file integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

본 개시는 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법에 관한 것으로, 컨테이너(Container)를 pod 내에 배치하고 노드에서 실행함으로써 워크로드를 구동하는 쿠버네티스(Kubernetes) 클러스터에서 발생하는 이벤트를 수집하고, 수집된 이벤트 중에서 제1 컨테이너 이미지를 다운로드하는 제1 이벤트가 감지하고, 감지된 제1 이벤트에 해당하는 제1 컨테이너 이미지에 대한 무결성을 검증할 수 있다.

Description

컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법 {Method for validating and managing cloud data for container orchestration}
본 개시는 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법에 관한 것이다.
4차 산업혁명 이후 커넥티드카, 가전제품 등 수많은 사물인터넷(IoT) 기기가 사용되면서 많은 양의 정보를 처리하게 되었다.
그러나, 수집된 정보를 처리하는데 물리적 서버의 리소스 제한이 있으며, 서버에서 실행되는 각 애플리케이션에 대해 격리된 리소스를 할당해야 한다.
이러한 요구 사항을 충족하기 위해 가상화된 애플리케이션이 있는 여러 서버에 대한 서비스 오케스트레이션이 현실적인 솔루션으로 간주되었으며, 구체적으로 서버의 각 애플리케이션은 VM(Virtual Machine) 및 컨테이너와 같은 가상화 기술로 추상화할 수 있다.
서비스 오케스트레이션은 여러 서버의 요구에 따라 더 많은 리소스를 동적으로 할당하여 각 서비스의 확장성을 제공할 수 있으며, 다양한 오케스트레이션 플랫폼 중에서 쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션의 자동 배포, 확장 및 관리를 허용하는 새로운 오픈 소스 기반 컨테이너 오케스트레이션 플랫폼 중 하나이다.
쿠버네티스는 컨테이너에서 애플리케이션을 쉽게 패키징하고 실행하며 분산 시스템을 탄력적으로 실행하기 위한 프레임워크를 제공한다.
이러한 다양한 장점에도 불구하고, 컨테이너 이미지가 위변조되어 오염되었거나 비인가자에 의해 수정된 경우 확인이 어렵다는 보안상의 문제점이 있다.
이러한 문제점을 개선하여 쿠버네티스의 장점을 최대한 활용해야 하지만, 현재로서는 이러한 기술이 공개되어 있지 않은 실정이다.
대한민국 등록특허 제10-2460416호
본 개시에 개시된 실시예는 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법을 제공하는데 그 목적이 있다.
본 개시가 해결하고자 하는 과제들은 이상에서 언급된 과제로 제한되지 않으며, 언급되지 않은 또 다른 과제들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
상술한 과제를 해결하기 위한 본 개시의 일 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버는, 통신부; 하나 이상의 인스트럭션을 저장하는 메모리; 및 상기 메모리에 저장된 상기 인스트럭션을 실행하는 하나 이상의 프로세서를 포함하며, 상기 프로세서는, 컨테이너(Container)를 pod 내에 배치하고 노드에서 실행함으로써 워크로드를 구동하는 쿠버네티스(Kubernetes) 클러스터에서 발생하는 이벤트를 상기 통신부를 통해 수집하고, 상기 수집된 이벤트 중에서 제1 컨테이너 이미지를 다운로드하는 제1 이벤트가 감지되는 경우, 상기 컨테이너 이미지에 대한 무결성을 검증할 수 있다.
또한, 상기 쿠버네티스 클러스터는, 마스터 노드와 상기 마스터 노드에 할당된 적어도 하나의 워커 노드가 포함하며, 상기 프로세서는, 상기 워커 노드의 Kubelet을 통해 상기 이벤트를 수집하며, 상기 제1 이벤트가 감지되는 경우, 상기 Kubelet을 통해 상기 마스터 노드의 API SERVER에 상기 제1 컨테이너 이미지의 무결성을 검증하기 위한 데이터를 요청할 수 있다.
또한, 상기 프로세서는, 상기 컨테이너 이미지가 생성되면 상기 생성된 컨테이너 이미지를 컨테이너 레지스트리에 저장하며, 상기 프로세서는, 상기 생성된 컨테이너 이미지가 상기 컨테이너 레지스트리에 저장될 때, 상기 컨테이너 레지스트리에 상기 생성된 컨테이너 이미지의 해시(Hash)가 저장되도록 제어할 수 있다.
또한, 상기 프로세서는, 상기 Kubelet이 상기 레지스트리에서 상기 제1 컨테이너 이미지에 대한 상기 제1 해시(Hash)를 가져오도록 요청하고, 상기 제1 컨테이너 이미지에 대한 현재 상태의 제2 해시 및 상기 Kubelet을 통해 획득한 상기 제1 해시를 기반으로 상기 제1 컨테이너 이미지에 대한 무결성을 검증할 수 있다.
또한, 상기 프로세서는, 상기 수집된 이벤트가 제2 컨테이너 이미지에 대한 변경사항을 포함하는 경우, 상기 변경사항에 포함된 정의를 확인하여 상기 정의가 미리 합의되어 있는 정의인지 여부를 확인할 수 있다.
또한, 상기 프로세서는, 상기 API SERVER에서 상기 제2 컨테이너 이미지의 기존 상태에 대한 제1 정의를 수집하도록 상기 Kubelet으로 요청하고, 상기 제2 컨테이너 이미지에 대한 상기 변경사항이 포함된 제2 정의와 상기 제1 정의를 기반으로 상기 제2 컨테이너 이미지에 대한 상기 변경사항을 확인할 수 있다.
또한, 상기 프로세서는, 상기 변경사항이 확인되면, 상기 확인된 변경사항이 미리 합의된 정의에 해당하는지 여부를 확인할 수 있다.
또한, 상기 프로세서는, 상기 Kubelet으로 상기 쿠버네티스 클러스터의 클러스터 정보가 저장되는 etcd에 저장되어 있는 상기 제2 컨테이너 이미지에 대한 yaml 파일을 요청하고, 상기 제2 컨테이너 이미지의 상기 yaml 파일을 통해 상기 제2 정의를 확인할 수 있다.
또한, 상술한 과제를 해결하기 위한 본 개시의 일 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법은, 서버에 의해 수행되는 방법으로, 컨테이너(Container)를 pod 내에 배치하고 노드에서 실행함으로써 워크로드를 구동하는 쿠버네티스(Kubernetes) 클러스터에서 발생하는 이벤트를 수집하는 단계; 상기 수집된 이벤트 중에서 제1 컨테이너 이미지를 다운로드하는 제1 이벤트가 감지하는 단계; 및 상기 감지된 제1 이벤트에 해당하는 상기 제1 컨테이너 이미지에 대한 무결성을 검증하는 단계를 포함한다.
이 외에도, 본 개시를 구현하기 위한 실행하기 위한 컴퓨터 판독 가능한 기록 매체에 저장된 컴퓨터 프로그램이 더 제공될 수 있다.
이 외에도, 본 개시를 구현하기 위한 방법을 실행하기 위한 컴퓨터 프로그램을 기록하는 컴퓨터 판독 가능한 기록 매체가 더 제공될 수 있다.
본 개시의 전술한 과제 해결 수단에 의하면, 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법을 제공하는 효과를 제공한다.
본 개시의 효과들은 이상에서 언급된 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버의 블록도이다.
도 2 및 도 3은 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법의 흐름도이다.
도 4는 쿠버네티스 클러스터의 예시도이다.
도 5는 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버와 쿠버네티스 클러스터의 동작을 예시한 도면이다.
도 6은 워커 노드에 레지스트리 pod을 설치한 것을 예시한 도면이다.
도 7은 워커 노드에 쿠버네티스 클러스터를 관리하기 위한 클라이언트를 설치한 것을 예시한 도면이다.
도 8은 워커 노드와 마스터 노드에 쿠버네티스 클러스터를 관리하기 위한 클라이언트를 설치한 것을 예시한 도면이다.
본 개시 전체에 걸쳐 동일 참조 부호는 동일 구성요소를 지칭한다. 본 개시가 실시예들의 모든 요소들을 설명하는 것은 아니며, 본 개시가 속하는 기술분야에서 일반적인 내용 또는 실시예들 간에 중복되는 내용은 생략한다. 명세서에서 사용되는 ‘부, 모듈, 부재, 블록’이라는 용어는 소프트웨어 또는 하드웨어로 구현될 수 있으며, 실시예들에 따라 복수의 '부, 모듈, 부재, 블록'이 하나의 구성요소로 구현되거나, 하나의 '부, 모듈, 부재, 블록'이 복수의 구성요소들을 포함하는 것도 가능하다.
명세서 전체에서, 어떤 부분이 다른 부분과 "연결"되어 있다고 할 때, 이는 직접적으로 연결되어 있는 경우뿐 아니라, 간접적으로 연결되어 있는 경우를 포함하고, 간접적인 연결은 무선 통신망을 통해 연결되는 것을 포함한다.
또한, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.
명세서 전체에서, 어떤 부재가 다른 부재 "상에" 위치하고 있다고 할 때, 이는 어떤 부재가 다른 부재에 접해 있는 경우뿐 아니라 두 부재 사이에 또 다른 부재가 존재하는 경우도 포함한다.
제1, 제2 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위해 사용되는 것으로, 구성요소가 전술된 용어들에 의해 제한되는 것은 아니다.
단수의 표현은 문맥상 명백하게 예외가 있지 않는 한, 복수의 표현을 포함한다.
각 단계들에 있어 식별부호는 설명의 편의를 위하여 사용되는 것으로 식별부호는 각 단계들의 순서를 설명하는 것이 아니며, 각 단계들은 문맥상 명백하게 특정 순서를 기재하지 않는 이상 명기된 순서와 다르게 실시될 수 있다.
이하 첨부된 도면들을 참고하여 본 개시의 작용 원리 및 실시예들에 대해 설명한다.
본 명세서에서 '본 개시에 따른 설계정보 투사 장치'는 연산처리를 수행하여 사용자에게 결과를 제공할 수 있는 다양한 장치들이 모두 포함된다. 예를 들어, 본 개시에 따른 설계정보 투사 장치는, 컴퓨터, 서버 장치 및 휴대용 단말기를 모두 포함하거나, 또는 어느 하나의 형태가 될 수 있다.
여기에서, 상기 컴퓨터는 예를 들어, 웹 브라우저가 탑재된 노트북, 데스크톱, 랩톱, 태블릿 PC, 슬레이트 PC 등을 포함할 수 있다.
상기 서버 장치는 외부 장치와 통신을 수행하여 정보를 처리하는 서버로써, 애플리케이션 서버, 컴퓨팅 서버, 데이터베이스 서버, 파일 서버, 게임 서버, 메일 서버, 프록시 서버 및 웹 서버 등을 포함할 수 있다.
상기 휴대용 단말기는 예를 들어, 휴대성과 이동성이 보장되는 무선 통신 장치로서, PCS, GSM, PDC(Personal Digital Cellular), PHS(Personal Handyphone System), PDA(Personal Digital Assistant), IMT(International Mobile Telecommunication)-2000, CDMA(Code Division Multiple Access)-2000, W-CDMA(W-Code Division Multiple Access), WiBro(Wireless Broadband Internet) 단말, 스마트폰(Smart Phone) 등과 같은 모든 종류의 핸드헬드(Handheld) 기반의 무선 통신 장치와 시계, 반지, 팔찌, 발찌, 목걸이, 안경, 콘택트 렌즈, 또는 머리 착용형 장치(head-mounted-device(HMD) 등과 같은 웨어러블 장치를 포함할 수 있다.
본 개시에 따른 인공지능과 관련된 기능은 프로세서와 메모리를 통해 동작된다. 프로세서는 하나 또는 복수의 프로세서로 구성될 수 있다. 이때, 하나 또는 복수의 프로세서는 CPU, AP, DSP(Digital Signal Processor) 등과 같은 범용 프로세서, GPU, VPU(Vision Processing Unit)와 같은 그래픽 전용 프로세서 또는 NPU와 같은 인공지능 전용 프로세서일 수 있다. 하나 또는 복수의 프로세서는, 메모리에 저장된 기 정의된 동작 규칙 또는 인공지능 모델에 따라, 입력 데이터를 처리하도록 제어한다. 또는, 하나 또는 복수의 프로세서가 인공지능 전용 프로세서인 경우, 인공지능 전용 프로세서는, 특정 인공지능 모델의 처리에 특화된 하드웨어 구조로 설계될 수 있다.
기 정의된 동작 규칙 또는 인공지능 모델은 학습을 통해 만들어진 것을 특징으로 한다. 여기서, 학습을 통해 만들어진다는 것은, 기본 인공지능 모델이 학습 알고리즘에 의하여 다수의 학습 데이터들을 이용하여 학습됨으로써, 원하는 특성(또는, 목적)을 수행하도록 설정된 기 정의된 동작 규칙 또는 인공지능 모델이 만들어짐을 의미한다. 이러한 학습은 본 개시에 따른 인공지능이 수행되는 기기 자체에서 이루어질 수도 있고, 별도의 서버 및/또는 시스템을 통해 이루어질 수도 있다. 학습 알고리즘의 예로는, 지도형 학습, 비지도 형 학습, 준지도형 학습 또는 강화 학습이 있으나, 전술한 예에 한정되지 않는다.
인공지능 모델은, 복수의 신경망 레이어들로 구성될 수 있다. 복수의 신경망 레이어들 각각은 복수의 가중치들을 갖고 있으며, 이전 레이어의 연산 결과와 복수의 가중치들 간의 연산을 통해 신경 망 연산을 수행한다. 복수의 신경망 레이어들이 갖고 있는 복수의 가중치들은 인공지능 모델의 학습 결과에 의해 최적화될 수 있다. 예를 들어, 학습 과정 동안 인공지능 모델에서 획득한 로스 값 또는 코스트 값이 감소 또는 최소화되도록 복수의 가중치들이 갱신될 수 있다. 인공 신경망은 심층 신경망(DNN: Deep Neural Network)를 포함할 수 있으며, 예를 들어, CNN (Convolutional Neural Network), DNN (Deep Neural Network), RNN (Recurrent Neural Network), RBM (Restricted Boltzmann Machine), DBN (Deep Belief Network), BRDNN(Bidirectional Recurrent Deep Neural Network) 또는 심층 Q-네트워크 등이 있으나, 전술한 예에 한정되지 않는다.
본 개시의 예시적인 실시예에 따르면, 프로세서는 인공지능을 구현할 수 있다. 인공지능이란 사람의 신경세포(biological neuron)를 모사하여 기계가 학습하도록 하는 인공신경망 기반의 기계 학습법을 의미한다. 인공지능의 방법론에는 학습 방식에 따라 훈련데이터로서 입력데이터와 출력데이터가 같이 제공됨으로써 문제(입력 데이터)의 해답(출력 데이터)이 정해져 있는 지도학습(supervised learning), 및 출력데이터 없이 입력데이터만 제공되어 문제(입력 데이터)의 해답(출력 데이터)이 정해지지 않는 비지도학습(unsupervised learning), 및 현재의 상태에서 어떤 행동을 취할 때마다 외부 환경에서 보상이 주어지는데, 이러한 보상을 최대화하는 방향으로 학습을 진행하는 강화학습(reinforcement learning)으로 구분될 수 있다. 또한, 인공지능의 방법론은 학습 모델의 구조인 아키텍처에 따라 구분될 수도 있는데, 널리 이용되는 딥러닝 기술의 아키텍처는, 합성곱신경망, 순환신경망, 트랜스포머, 생성적 대립 신경망 등으로 구분될 수 있다.
본 장치는 인공지능 모델을 포함할 수 있다. 인공지능 모델은 하나의 인공지능 모델일 수 있고, 복수의 인공지능 모델로 구현될 수도 있다. 인공지능 모델은 뉴럴 네트워크(또는 인공 신경망)로 구성될 수 있으며, 기계학습과 인지과학에서 생물학의 신경을 모방한 통계학적 학습 알고리즘을 포함할 수 있다. 뉴럴 네트워크는 시냅스의 결합으로 네트워크를 형성한 인공 뉴런(노드)이 학습을 통해 시냅스의 결합 세기를 변화시켜, 문제 해결 능력을 가지는 모델 전반을 의미할 수 있다. 뉴럴 네트워크의 뉴런은 가중치 또는 바이어스의 조합을 포함할 수 있다. 뉴럴 네트워크는 하나 이상의 뉴런 또는 노드로 구성된 하나 이상의 레이어를 포함할 수 있다. 예시적으로, 장치는 input layer, hidden layer, output layer를 포함할 수 있다. 장치를 구성하는 뉴럴 네트워크는 뉴런의 가중치를 학습을 통해 변화시킴으로써 임의의 입력으로부터 예측하고자 하는 결과를 추론할 수 있다.
프로세서는 뉴럴 네트워크를 생성하거나, 뉴럴 네트워크를 훈련(train, 또는 학습(learn)하거나, 수신되는 입력 데이터를 기초로 연산을 수행하고, 수행 결과를 기초로 정보 신호를 생성하거나, 뉴럴 네트워크를 재훈련할 수 있다. 뉴럴 네트워크의 모델들은 GoogleNet, AlexNet, VGG Network 등과 같은 CNN, R-CNN, RPN, RNN, S-DNN, S-SDNN, Deconvolution Network, DBN, RBM, Fully Convolutional Network, LSTM Network, Classification Network 등 다양한 종류의 모델들을 포함할 수 있으나 이에 제한되지는 않는다. 프로세서는 뉴럴 네트워크의 모델들에 따른 연산을 수행하기 위한 하나 이상의 프로세서를 포함할 수 있다. 예를 들어 뉴럴 네트워크는 심층 뉴럴 네트워크를 포함할 수 있다.
뉴럴 네트워크는 CNN, RNN, 퍼셉트, 다층 퍼셉트론, FF(Feed Forward), RBF(Radial Basis Network), DFF(Deep Feed Forward), LSTM(Long Short Term Memory), GRU(Gated Recurrent Unit), AE(Auto Encoder), VAE(Variational Auto Encoder), DAE(Denoising Auto Encoder), SAE(Sparse Auto Encoder), MC(Markov Chain), HN(Hopfield Network), BM(Boltzmann Machine), RBM(Restricted Boltzmann Machine), DBN(Depp Belief Network), DCN(Deep Convolutional Network), DN(Deconvolutional Network), DCIGN(Deep Convolutional Inverse Graphics Network), GAN(Generative Adversarial Network), LSM(Liquid State Machine), ELM(Extreme Learning Machine), ESN(Echo State Network), DRN(Deep Residual Network), DNC(Differentiable Neural Computer), NTM(Neural Turning Machine), CN(Capsule Network), KN(Kohonen Network) 및 AN(Attention Network)를 포함할 수 있으나 이에 한정되는 것이 아닌 임의의 뉴럴 네트워크를 포함할 수 있음은 통상의 기술자가 이해할 것이다.
본 개시의 예시적인 실시예에 따르면, 프로세서는 GoogleNet, AlexNet, VGG Network 등과 같은 CNN(Convolution Neural Network), R-CNN(Region with Convolution Neural Network), RPN(Region Proposal Network), RNN(Recurrent Neural Network), S-DNN(Stacking-based deep Neural Network), S-SDNN(State-Space Dynamic Neural Network), Deconvolution Network, DBN(Deep Belief Network), RBM(Restrcted Boltzman Machine), Fully Convolutional Network, LSTM(Long Short-Term Memory) Network, Classification Network, Generative Modeling, eXplainable AI, Continual AI, Representation Learning, AI for Material Design, 자연어 처리를 위한 BERT, SP-BERT, MRC/QA, Text Analysis, Dialog System, GPT-3, GPT-4, 비전 처리를 위한 Visual Analytics, Visual Understanding, Video Synthesis, ResNet 데이터 지능을 위한 Anomaly Detection, Prediction, Time-Series Forecasting, Optimization, Recommendation, Data Creation 등 다양한 인공지능 구조 및 알고리즘을 이용할 수 있으며, 이에 제한되지 않는다. 이하, 첨부된 도면을 참조하여 본 개시의 실시예를 상세하게 설명한다.
도 1은 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버(100)의 블록도이다.
도 1을 참조하면, 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버(100)는 프로세서(110), 통신부(120) 및 메모리(130)를 포함한다.
다만, 몇몇 실시예에서 서버(100)는 도 1에 도시된 구성요소보다 더 적은 수의 구성요소나 더 많은 구성요소를 포함할 수도 있다.
서버(100)는 메모리(130)에 저장된 인스트럭션을 실행하는 하나 이상의 프로세서(110)를 포함한다.
프로세서(110)는 본 장치 내의 구성요소들의 동작을 제어하기 위한 알고리즘 또는 알고리즘을 재현한 프로그램에 대한 데이터를 저장하는 메모리(130), 및 메모리(130)에 저장된 데이터를 이용하여 전술한 동작을 수행하는 적어도 하나의 프로세서(110)로 구현될 수 있다. 이때, 메모리(130)와 프로세서(110)는 각각 별개의 칩으로 구현될 수 있다. 또는, 메모리(130)와 프로세서(110)는 단일 칩으로 구현될 수도 있다.
또한, 프로세서(110)는 이하의 도면에서 설명되는 본 개시에 따른 다양한 실시 예들을 본 장치 상에서 구현하기 위하여, 위에서 살펴본 구성요소들을 중 어느 하나 또는 복수를 조합하여 제어할 수 있다.
프로세서(110)는 상기 응용 프로그램과 관련된 동작 외에도, 통상적으로 본 장치의 전반적인 동작을 제어할 수 있다. 프로세서(110)는 위에서 살펴본 구성요소들을 통해 입력 또는 출력되는 신호, 데이터, 정보 등을 처리하거나 메모리(130)에 저장된 응용 프로그램을 구동함으로써, 사용자에게 적절한 정보 또는 기능을 제공 또는 처리할 수 있다.
또한, 프로세서(110)는 메모리(130)에 저장된 응용 프로그램을 구동하기 위하여, 본 장치의 구성요소들 중 적어도 일부를 제어할 수 있다. 나아가, 프로세서(110)는 상기 응용 프로그램의 구동을 위하여, 본 장치에 포함된 구성요소들 중 적어도 둘 이상을 서로 조합하여 동작 시킬 수 있다.
통신부(120)는 서버(100)를 하나 이상의 네트워크에 연결하는 하나 이상의 모듈을 포함할 수 있다.
통신부(120)는 외부 장치와 통신을 가능하게 하는 하나 이상의 구성 요소를 포함할 수 있으며, 예를 들어, 방송 수신 모듈, 유선통신 모듈, 무선통신 모듈, 근거리 통신 모듈, 위치정보 모듈 중 적어도 하나를 포함할 수 있다.
유선 통신 모듈은, 지역 통신(Local Area Network; LAN) 모듈, 광역 통신(Wide Area Network; WAN) 모듈 또는 부가가치 통신(Value Added Network; VAN) 모듈 등 다양한 유선 통신 모듈뿐만 아니라, USB(Universal Serial Bus), HDMI(High Definition Multimedia Interface), DVI(Digital Visual Interface), RS-232(recommended standard232), 전력선 통신, 또는 POTS(plain old telephone service) 등 다양한 케이블 통신 모듈을 포함할 수 있다.
무선 통신 모듈은 와이파이(Wifi) 모듈, 와이브로(Wireless broadband) 모듈 외에도, GSM(global System for Mobile Communication), CDMA(Code Division Multiple Access), WCDMA(Wideband Code Division Multiple Access), UMTS(universal mobile telecommunications system), TDMA(Time Division Multiple Access), LTE(Long Term Evolution), 4G, 5G, 6G 등 다양한 무선 통신 방식을 지원하는 무선 통신 모듈을 포함할 수 있다.
무선 통신 모듈은 통신 신호를 송신하는 안테나 및 송신기(Transmitter)를 포함하는 무선 통신 인터페이스를 포함할 수 있다. 또한, 무선 통신 모듈은 프로세서(110)의 제어에 따라 무선 통신 인터페이스를 통해 프로세서(110)로부터 출력된 디지털 제어 신호를 아날로그 형태의 무선 신호로 변조하는 신호 변환 모듈을 더 포함할 수 있다.
근거리 통신 모듈은 근거리 통신(Short range communication)을 위한 것으로서, 블루투스(Bluetooth??), RFID(Radio Frequency Identification), 적외선 통신(Infrared Data Association; IrDA), UWB(Ultra-Wideband), ZigBee, NFC(Near Field Communication), Wi-Fi(Wireless-Fidelity), Wi-Fi Direct, Wireless USB(Wireless Universal Serial Bus) 기술 중 적어도 하나를 이용하여, 근거리 통신을 지원할 수 있다.
메모리(130)는 본 장치의 다양한 기능을 지원하는 데이터를 저장할 수 있다. 메모리(130)는 본 장치에서 구동되는 다수의 응용 프로그램(application program 또는 애플리케이션(application)), 본 장치의 동작을 위한 데이터들, 명령어들을 저장할 수 있다. 이러한 응용 프로그램 중 적어도 일부는, 본 장치의 기본적인 기능을 위하여 존재할 수 있다. 한편, 응용 프로그램은, 메모리(130)에 저장되고, 장치에 설치되어, 프로세서(110)에 의하여 동작(또는 기능)을 수행하도록 구동될 수 있다.
메모리(130)는 본 장치의 다양한 기능을 지원하는 데이터와, 프로세서(110)의 동작을 위한 프로그램을 저장할 수 있고, 입/출력되는 데이터들(예를 들어, 음악 파일, 정지영상, 동영상 등)이 저장될 수 있고, 본 장치에서 구동되는 다수의 응용 프로그램(application program 또는 애플리케이션(application)), 본 장치의 동작을 위한 데이터들, 명령어들을 저장할 수 있다. 이러한 응용 프로그램 중 적어도 일부는, 무선 통신을 통해 외부 서버로부터 다운로드 될 수 있다.
이러한, 메모리(130)는 플래시 메모리(130) 타입(flash memory type), 하드디스크 타입(hard disk type), SSD 타입(Solid State Disk type), SDD 타입(Silicon Disk Drive type), 멀티미디어 카드 마이크로 타입(multimedia card micro type), 카드 타입의 메모리(예를 들어 SD 또는 XD 메모리 등), 램(random access memory; RAM), SRAM(static random access memory), 롬(read-only memory; ROM), EEPROM(electrically erasable programmable read-only memory), PROM(programmable read-only memory), 자기 메모리, 자기 디스크 및 광디스크 중 적어도 하나의 타입의 저장매체를 포함할 수 있다. 또한, 메모리(130)는 본 장치와는 분리되어 있으나, 유선 또는 무선으로 연결된 데이터베이스가 될 수도 있다.
또한, 메모리(130)는 서버(100)를 위한 복수의 프로세스를 구비할 수 있다.
도 2 및 도 3은 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법의 흐름도이다.
도 4는 쿠버네티스 클러스터의 예시도이다.
도 5는 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버(100)와 쿠버네티스 클러스터의 동작을 예시한 도면이다.
도 6은 워커 노드에 레지스트리 pod을 설치한 것을 예시한 도면이다.
도 7은 워커 노드에 쿠버네티스 클러스터를 관리하기 위한 클라이언트를 설치한 것을 예시한 도면이다.
도 8은 워커 노드와 마스터 노드에 쿠버네티스 클러스터를 관리하기 위한 클라이언트를 설치한 것을 예시한 도면이다.
도 2 내지 도 8을 참조하여 본 개시의 실시예에 따른 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버(100) 및 방법에 관하여 보다 상세하게 설명하도록 한다.
먼저, 쿠버네티스 클러스터에 대하여 간략하게 설명하도록 한다.
도 3을 참조하면, 쿠버네티스 클러스터는 마스터 노드와 적어도 하나의 워커 노드를 포함한다.
마스터 노드(Master Node)는 쿠버네티스 클러스터 전체를 컨트롤하는 시스템(10)으로, 마스터 노드는 API SERVER를 통해 쿠버네티스를 관리하고, 모든 구성들은 API SERVER를 통해서 통신한다.
마스터 노드는 API SERVER, etcd, Kube-Scheduler, Kube-Controller를 포함한다.
API SERVER는 kubectl과 같은 클라이언트로부터 오는 요청을 받고, API 오브젝트를 구성한다.
API SERVER는 쿠버네티스 내부의 모든 구성들이 서로 호출하기 위해 사용하는 구성으로, kubectl의 요청 뿐만 아니라 내부 모듈의 요청을 처리하고 권한을 체크하고 요청을 거부할 수 있다. API SERVER는 노드에서 실행중인 컨테이너의 로그를 확인하는 디버거 역할도 가능하다.
etcd는 쿠버네티스 클러스터의 데이터베이스 역할을 하는 서버(100)로, 클러스터의 모든 설정, 상태에 관한 데이터를 저장할 수 있다.
etcd는 클러스터 안의 각 구성요소들에 대한 정보가 키-값 형태로 저장되는 데이터베이스이다.
Kube-Scheduler는 쿠버네티스의 스케쥴러이며, 새로 생성된 pod가 실행될 노드를 선택한다. 스케쥴링이란 pod를 실행할 노드를 정하는 것을 의미한다.
Kube-Scheduler는 pod(pod), 서비스 등 각 리소스들을 적절한 노드에 할당하는 역할을 담당하며, pod을 어떤 노드에서 실행할지 결정하고, 노드에 배치된 pod은 각 노드의 kubelet에 의해 컨테이너로 생성된다.
Kube-Controller는 쿠버네티스의 ReplicaSet, Deployment 등 컨트롤러를 관리하고 적절한 노드에 할당하는 역할을 담당하며, 각 컨트롤러에게 pod의 복제, 배포 등의 명령을 수행한다.
워커 노드(Worker Node)는 마스터 노드로부터 명령을 받고 실제 워크 로드를 생성하여 서비스하는 구성이다.
워커 노드는 실제 컨테이너들이 생성되는 가상 머신 또는 물리적인 서버로, 각각 서버에 라벨을 붙여서 사용 목적을 정의할 수도 있으며, API SERVER의 요청을 kubelet을 통해 수행할 수 있다.
워커 노드는 kubelet, kube-proxy, Container Runtime, Addons, cAdvisor를 포함할 수 있다.
Kubelet은 노드에 배포되는 agent로 마스터 노드의 API SERVER와 통신하는 역할을 담당한다.
Kubelet은 마스터 노드의 API SERVER로부터 수행할 명령을 받아서 워커 노드를 수행시키며, 워커 노드의 상태를 마스터 노드로 전달한다.
Kubelet은 해당 컨테이너가 정상적으로 동작하는지 지속적으로 모니터링하며, 주기적으로 API SERVER와 통신하며 마스터와 노드 간에 필요한 정보를 주고받는다. (예: 노드의 상태 정보, 리소스 사용량 등)
Kube-proxy는 노드에 할당된 pod로 연결되는 네트워크를 관리하며, 노드로 오는 트래픽을 적절한 컨테이너로 프록시하고 노드와 마스터 노드 간의 네트워크 통신을 관리한다.
Kube-proxy는 클러스터 내부에 별도의 가상 네트워크가 동작할 수 있도록 하며, TCP, UDP, SCTP 스트림을 포워딩하고, 여러 개의 pod를 라운드 로빈 형태로 묶어서 서비스를 제공할 수 있다.
Kube-proxy는 노드로 들어오는 트래픽을 적절한 컨테이너로 라우팅, 로드밸런싱, 프록시하며 통신을 관리할 수 있다.
Container Runtime은 pod를 통해서 배포된 컨테이너를 실제로 실행시키며, 컨테이너 런타임 중에서 대표적인 예로 도커(Docker)가 있고, 그 외에 갓, runc 같은 런타임도 지원한다.
Addons는 클러스터 내부에서 필요한 기능을 실행시키기 위한 pod이다.
cAdvisor는 노드의 모니터링 agent로 노드에서 가동되는 컨테이너들의 상태정보를 수집하여 마스터 노드의 API SERVER로 전달한다.
쿠버네티스에서 kubectl은 쿠버네티스 클러스터를 조작하기 위한 커맨드 라인 인터페이스(CLI)이다.
pod는 쿠버네티스 클러스터에서 컨테이너를 실행하는 최소 단위이며, pod는 하나 혹은 여러 개의 컨테이너를 포함한다.
그리고, 특정 pod에 속하는 컨테이너들은 같은 노드에서 작동한다. 즉, pod는 서로 다른 노드에 설쳐서 존재하지는 않고 하나의 노드에 존재한다.
이와 같은 쿠버네티스 클러스터는 컨테이너 오케스트레이션 플랫폼으로, 컨테이너화되어 있는 어플리케이션을 배포, 스케일링, 관리하는데 사용되며, 쿠버네티스는 대규모 분산 시스템(10)에서 확장성, 신뢰성 및 유연성을 제공하므로 보안관제 시스템(10) 등에서도 매우 유용하게 사용될수 있다.
도 2는 컨테이너 이미지에 대한 무결성을 검증하는 프로세스를 예시한 흐름도이다.
프로세서(110)가 쿠버네티스 클러스터에서 발생하는 이벤트를 수집한다. (S100)
프로세서(110)는 컨테이너(Container)를 pod 내에 배치하고 노드에서 실행함으로써 워커로드를 구동하는 쿠버네티스(Kubernetes) 클러스터에서 발생하는 이벤트를 통신부(120)를 통해 수집한다.
보다 상세하게는, 쿠버네티스 클러스터는 마스터 노드와 마스터 노드에 할당된 적어도 하나의 워커 노드를 포함하며, 각각의 워커 노드는 Kubelet을 포함한다.
보다 상세하게는, 프로세서(110)는 워커 노드의 Kubelet을 통해 쿠버네티스 클러스터에서 발생하는 이벤트를 수집한다.
메모리(130)는 이벤트 분류 알고리즘이 저장될 수 있으며, 프로세서(110)는 이벤트 분류 알고리즘을 이용하여 쿠버네티스 클러스터로부터 수집되는 이벤트를 자동으로 분류할 수 있다.
프로세서(110)가 수집된 이벤트에서 제1 컨테이너 이미지를 다운로드하는 제1 이벤트를 감지한다. (S200)
프로세서(110)가 S200에서 감지된 제1 이벤트에 해당하는 제1 컨테이너 이미지에 대한 무결성을 검증한다. (S300)
프로세서(110)는 수집된 이벤트 중에서 제1 컨테이너 이미지를 다운로드(Download, Pull)하는 제1 이벤트가 감지되는 경우, 제1 컨테이너 이미지에 대한 무결성 검증을 수행한다.
일 실시예로, 프로세서(110)는 제1 이벤트가 감지되는 경우 Kubelet을 통해 마스터 노드의 API SERVER에 제1 컨테이너 이미지의 무결성을 검증하기 위한 데이터를 요청한다.
본 개시의 실시예에서 서버(100)는 컨테이너 이미지의 무결성 검증 수단으로 해시(Hash)를 이용할 수 있다.
도 6을 참조하여 컨테이너 레지스트리를 활용하는 것을 설명하도록 한다.
프로세서(110)는 컨테이너 이미지가 생성되면, 생성된 컨테이너 이미지를 컨테이너 레지스트리에 저장한다.
일 실시예로, 프로세서(110)는 워커 노드에 컨테이너 레지스트리를 포함하는 레지스트리 pod를 생성할 수 있다. 그리고, 프로세서(110)는 생성된 컨테이너 이미지가 컨테이너 레지스트리에 저장될 때, 컨테이너 레지스트리에 상기 생성된 컨테이너 이미지의 해시(hash)가 저장되도록 제어한다.
프로세서(110)는 Kubelet이 컨테이너 레지스트리에서 제1 컨테이너 이미지에 대한 제1 해시를 가져오도록 요청하고, 제1 컨테이너 이미지에 대한 현재 상태의 제2 해시 및 Kubelet을 통해 획득한 제1 해시를 기반으로 제1 컨테이너 이미지에 대한 무결성을 검증할 수 있다.
일 실시예로, 프로세서(110)는 Kubelet을 제어하여 컨테이너 레지스트리에 HostPath Volume을 마운트하여 pod(Pod)가 재시작 하더라도 레지스트리에 저장된 컨테이너 이미지 데이터가 보존되도록 할 수 있다.
일 실시예로, 프로세서(110)는 컨테이너 레지스트리를 포함하는 레지스트리 pod를 생성하고, HostPath Volume을 사용하는 레플리카셋 컨트롤러를 생성한 후, 레지스트리 pod에 HostPath Volume을 마운트할 수 있다.
이러한 HostPath Volume의 특징을 이용하여 서버는 pod가 재시작하더라도 컨테이너 이미지, 컨테이너 이미지에 대한 해시가 삭제되지 않도록 할 수 있다.
Pod가 죽어서 재생성되는 경우, 재성성되는 pod가 기존 노드가 아닌 다른 노드에 재생성되는 경우 Volume을 이용할 수 없게 된다.
일 실시예로, 위와 같은 문제점을 해결하기 위해서 프로세서(110)는 pod의 라이프 사이클(Life Cycle)과 현재 상태를 주기적으로 모니터링하는 kubelet으로부터 기 설정된 시간마다 pod의 생명 주기와 현재 상태(status: Pending, Running, Succeeded, Failed or Unknown)를 수신하고, pod의 재시작이 필요한 시점을 판단할 수 있다.
프로세서(110)는 pod의 재시작이 필요한 시점이라고 판단되면, 해당 pod를 기존 노드에서 생성하여 pod가 재시작되고 데이터가 삭제되지 않고 HostPath Volume을 사용할 수 있도록 할 수 있다.
[정의 확인에 관한 실시예]
도 3은 컨테이너 이미지의 변경을 감지하는 경우, 변경 내역을 확인하는 프로세스를 예시한 흐름도이다.
프로세서(110)가 쿠버네티스 클러스터에서 발생하는 이벤트를 수집한다. (S100)
프로세서(110)가 이벤트를 수집하는 방법은 전술하였으므로 중복되는 설명을 생략하도록 한다.
프로세서(110)가 수집된 이벤트를 통해 제2 컨테이너 이미지에 대한 변경을 감지한다. (S400)
프로세서(110)가 S400에서 감지된 변경 내역을 확인하고, 확인한 변경 내역이 미리 합의되어 있는 정의인지 여부를 확인한다. (S500)
프로세서(110)는 수집된 이벤트를 통해서 제2 컨테이너 이미지에 데이터 변경이 발생한 이벤트를 감지할 수 있다.
프로세서(110)는 변경 사항에 포함된 정의를 확인하고, 확인된 정의가 미리 합의되어 있는 정의인지 여부를 확인할 수 있다.
보다 상세하게는, 프로세서(110)는 API SERVER에서 제2 컨테이너 이미지의 기존 상태에 대한 제1 정의를 수집하도록 Kubelet에 요청하고, Kubelet으로부터 수집된 상기 제1 정의를 수신할 수 있다.
다음으로, 프로세서(110)는 제2 컨테이너 이미지에 대한 상기 변경 사항이 포함된 제2 정의와 상기 제1 정의를 기반으로 제2 컨테이너 이미지에 대한 변경 사항을 확인할 수 있다.
제2 정의는 제2 컨테이너 이미지가 변경된 후 제2 컨테이너 이미지의 변경된 내용에 관한 정의이고, 제1 정의는 제2 컨테이너 이미지가 변경되기 전의 정의이다.
보다 상세하게는, 프로세서(110)는 Kubelet으로 쿠버네티스 클러스터의 클러스터 정보가 저장되는 etcd에 저장되어 있는 제2 컨테이너 이미지에 대한 yaml 파일을 요청한다.
그리고, 프로세서(110)는 제2 컨테이너 이미지의 yaml 파일을 통해 제2 정의를 확인할 수 있다.
프로세서(110)는 컨테이너 이미지에 대한 yaml을 저장할 때, revision을 저장 또는 업데이트 한다.
보다 상세하게는, 프로세서(110)는 컨테이너 이미지에 대한 yaml을 최초 저장할 때 Revision을 저장하고 그 후 해당 컨테이너 이미지에 대한 데이터 변경이 발생할 때마다 Revision을 업데이트 한다.
즉, 서버(100)는 위와 같은 프로세스를 통해서 컨테이너 이미지의 모든 데이터 변경을 감지할 수 있고, 변경 내역/사항을 체크할 수 있게 된다.
도 7을 참조하면, 서버(100)가 쿠버네티스에 제어 신호를 전달하고 상태 정보를 수신하기 위하여 쿠버네티스의 워커 노드 내부에 클라이언트를 설치하여 운용하는 것이 예시되어 있다.
프로세서(110)는 클라이언트를 통해서 kubelet과 통신하고, kubelet은 API SERVER와 통신하여 쿠버네티스 클러스터를 동작시키거나 동작 상태를 감시할 수 있다.
도 8을 참조하면, 서버(100)가 쿠버네티스에 제어 신호를 전달하고 상태 정보를 수신하기 위하여 쿠버네티스의 워커 노드와 마스터 노드 내부에 클라이언트를 설치하여 운용하는 것이 예시되어 있다.
프로세서(110)는 클라이언트를 통해서 kubelet과 통신할 수도 있고, API SERVER와 직접 통신하여 쿠버네티스 클러스터를 동작시키거나 동작 상태를 감시할 수 있다.
쿠버네티스의 pod는 MSA 시스템의 최소 단위인 마이크로서비스로 취급할 수 있으며 도커(docker)와 같은 컨테이너들의 집합이다. 즉 pod 속에서 동시에 여러 컨테이너들을 실행한다.
또한 이 컨테이너들은 서로 로컬 호스트로 통신한다. MSA 스타일 시스템(10)에는 트랜잭션이 항상 여러 서비스에 걸쳐 있으며 pod가 다른 서비스와 통신하여야 하는 경우가 많다.
이럴 때에 pod는 Kube-dns 또는 CoreDNS가 제공하는 서비스 발견에 의하여 다른 서비스의 이름만 가지고 다른 서비스와 통신할 수 있다.
즉 다른 서비스와 통신하는데 다른 서비스의 IP 주소를 알 필요는 없다.
쿠버네티스 서비스 오브젝트는 본질적으로 pod들의 부하 분산(로드 밸런싱) 작업을 담당한다. 또한 서비스 발견의 플래그 역할도 한다. MSA 스타일 시스템(10)에는 보통 하나의 서비스 오브젝트가 하나의 pod 또는 이 pod의 여러개 복사본을 묶어서 서비스를 제공한다.
쿠버네티스에는 5가지 pod를 지정할 수 있는데 상태를 가지는 pod, 상태가 없는 pod, 데몬 pod, 주기적 pod, 일회용 pod이다.
이에 상응하여 관리자가 StatefulSets, Deployment, DeamonSet, CronJob, Job 오브젝트를 이용하여 새로운 pod를 생성할 수 있다.
쿠버네티스 클러스터 내 pod는 레플리카셋(ReplicaSet), 디플로이먼트(Deployment), 스테이트풀셋(StatefulSet), 데몬셋(DaemonSet)와 같은 컨트롤러로 운용될 수 있다.
쿠버네티스 클러스터에서 컨트롤러는 pod를 관리하는 역할을 하며, pod를 어떻게 관리하느냐에 따라서 쿠버네티스에서 제공하는 컨트롤러를 사용한다.
간략하게는, 상태를 유지하지 않아도 되는 pod(Stateless)를 관리하는 경우 레플리카셋, 디플로이먼트를 사용하고, 상태를 유지해야 하는 pod(Stateful)를 관리하는 경우 스테이트풀셋을 사용하고, 클러스터 전체에 배포가 필요한 pod를 관리하는 경우 데몬셋을 사용하고, 배치성 작업을 진행하는 pod를 관리하는 경우 job을 사용할 수 있다.
디플로이먼트는 상태가 없는 애플리케이션을 배포할 때 사용하는 가장 기본적인 컨트롤러이다. Deployment는 ReplicaSet을 관리하면서 좀 더 애플리케이션 배포에 관련된 자세한 작업이 가능하며, 단순 Pod의 배포뿐만 아니라 배포 방식, 버전 롤백등이 가능하다.
레플리카셋은 실행할 pod의 개수를 지정할 수 있고, 지정한 개수만큼 pod가 유지되도록 관리할 수 있다. 집합 기반의 셀렉터(Selector)를 지원하며, 셀렉터는 in, notin, exists와 같은 연산을 제공하며 조건에 따라 필요로 하는 레이블을 선택할 수 있다. 레플리카셋은 pod 업데이트시 rolling-update를 지원하지 않는다.
데몬셋은 클러스터 전체 노드에 특정 pod를 실행할 때 사용한다. 주로 로그 수집기나, 노드를 모니터링하는 데몬 등에 사용이 된다. 데몬셋이란 레플리카셋의 특수한 형태라고 할 수 있는 리소스이다. 레플리카셋은 각 쿠버네티스 노드에 총 N개의 pod를 노드의 리소스 상황에 맞게 배치할 수 있다.
스테이트풀셋은 ReplicaSet, Deployment가 상태가 없는 Pod를 관리하는 용도였다면, StatefulSet은 상태가 있는 Pod를 관리하는 컨트롤러이다.
상태가 있다는 의미는, 컨테이너가 종료되어도 컨테이너에서 필요로 하는 데이터가 남게되어 Pod를 재시작 하더라도 데이터를 보존할 수 있다.
Job은 배치성 작업을 진행하기 위해 사용하는 컨트롤러이다.
Job은 계속 실행되어야 하는 성격이 아니라, 실행되고나서 종료되어야 하는 성격을 지니고 있는 컨트롤러이다.
프로세서(110)는 마스터 노드 및 워커 노드로부터 설정된 항목의 정보를 수집할 수 있으며, 수집된 정보를 분석하여 보안 취약점을 진단할 수 있다.
상세하게는, 프로세서(110)는 스케쥴러, 마스터 노드의 Configuration file, API SERVER 및 Controller Manager의 설정 항목에 대한 보안 취약점을 분석할 수 있다.
서버(100)는 보안 취약점과 관련된 빅데이터가 저장되어 있으며, 복수의 카테고리와 관련된 보안 취약점은 누적된 보안 취약 사례와 관련된 데이터가 카테고리, 위험도가 설정되어 저장되어 있다.
또한, 서버(100)는 보안 취약점과 관련된 빅데이터를 기반으로 학습된 취약점 판단 모델을 포함한다. 서버(100)는 각 보안 취약 사례에 대하여 설정된 카테고리, 위험도를 모델에 학습시키고 테스트하여 모델의 성능을 시험할 수 있다.
일 실시예로, 프로세서(110)는 kube-Scheduler로부터 pod가 생성되는 것은 감지하고, 생성된 pod가 할당된 노드의 정보를 분석할 수 있다.
또한, 프로세서(110)는 마스터 노드에서 기본 계정과 API의 접근 토큰의 생성 정보와 접근 권한에 대한 정보를 분석할 수 있다.
또한, 프로세서(110)는 API SERVER의 액세스 정보 및 트래픽 정보, 노드 컨트롤러의 응답 정보, 라이트 컨트롤러의 인프라 경로 설정 정보, 서비스 컨트롤러의 업데이트 및 삭제 정보를 분석할 수 있다.
또한, 프로세서(110)는 RBAC(Role-based access control), 서비스 어카운트(Service account)와, Pod 보안 정책, 네트워크 및 CNI 정책과 관련된 이벤트의 발생과, 정보의 변경 및 삭제 여부를 분석한다. 특히 폴리시 분석 모듈은 대쉬보드(Dashboard)에 부여된 관리자 권한의 설정이나 변경에 정보를 분석하여 허가되지 않은 사용자에게 대쉬보드의 관리자 권한이 부여될 가능성을 분석한다.
또한, 프로세서(110)는 워커 노드의 Configuration 파일과 kubelet의 컨테이너 동작 관리 정보를 분석하여 허가되지 않은 사용자가 클러스터에서 kubelet API로 접근하는 가능성을 분석할 수 있다.
일 실시예로, 프로세서(110)는 클러스터에 대응되는 클러스터 설정 정보를 저장 및 관리하고, 복수 개의 컨테이너 각각에 탑재되어 실행되며 코디네이터 데몬으로부터 클러스터 설정 정보를 제공받아 해당 컨테이너에 탑재된 분산 애플리케이션을 초기 구동할 수 있다.
이때, 클러스터 설정 정보는 클러스터에 포함된 복수 개의 분산 애플리케이션의 식별 정보 중 적어도 하나를 포함할 수 있다.
일 실시예로, 서버(100)는 코디네이터 데몬, 복수 개의 에이전트 데몬을 더 포함할 수 있다.
코디네이터 데몬은 상기 클러스터에 대응되는 클러스터 설정 정보를 저장 및 관리하는 모듈이다. 이때 상기 클러스터 설정 정보는 클러스터를 구성하는 각 분산 애플리케이션의 구성 정보 및 상기 각 분산 애플리케이션의 식별 정보를 포함할 수 있다. 예를 들어, 상기 각 분산 애플리케이션의 식별 정보는 각 분산 애플리케이션의 고유 ID, 각 분산 애플리케이션이 구동되는 컨테이너의 네트워크 주소(IP address 등) 또는 컨테이너의 이름(고유 ID) 등이 될 수 있다.
코디네이터 데몬은 오케스트레이션(orchestration) 모듈이 탑재되는 외부 하드웨어와 동일한 하드웨어 내에 탑재될 수 있다. 본 발명의 실시예들에서, 오케스트레이션 모듈은 복수 개의 분산 애플리케이션과는 구별되는 별도의 외부 하드웨어에 설치되어 상기 복수 개의 분산 애플리케이션에 대한 스케일-인/아웃, 및 장애 복구(fail-over)를 수행할 수 있다. 이 경우 코디네이터 데몬은 상기 오케스트레이션 모듈과 동일한 하드웨어 내에 구비될 수 있다. 다만, 이는 예시적인 것으로서, 실시예에 따라 분산 애플리케이션 관리 시스템(10)은 코디네이터 데몬의 구동을 위한 별도의 하드웨어를 구비하는 것도 가능하다.
복수 개의 에이전트 데몬은 복수 개의 컨테이너 각각에 탑재되어 실행되며, 상기 코디네이터 데몬으로부터 상기 클러스터 설정 정보를 제공받아 해당 컨테이너에 탑재된 분산 애플리케이션을 초기 구동한다. 전술한 바와 같이 상기 클러스터 설정 정보는, 상기 클러스터에 포함된 복수 개의 분산 애플리케이션의 식별 정보 중 적어도 하나를 포함할 수 있다. 복수 개의 에이전트 데몬은, 각각 대응되는 컨테이너의 신규 생성시 함께 생성될 수 있다.
또한 각 에이전트 데몬은 복수 개의 분산 애플리케이션 중 적어도 하나의 이상 발생 여부를 모니터링한다. 만약 이상 발생이 감지되는 경우, 이를 감지한 에이전트 데몬은 이상 발생이 감지된 분산 애플리케이션을 상기 클러스터에서 제거한다. 이후 오케스트레이션 모듈은 제거된 분산 애플리케이션을 대체할 신규 분산 애플리케이션을 생성하게 된다.
일 실시예에서, 코디에니터 데몬, 에이전트 데몬, 오케스트레이션 모듈, 분산 애플리케이션 및 컨테이너는 하나 이상의 프로세서(110) 및 그 프로세서(110)와 연결된 컴퓨터 판독 가능 기록 매체를 포함하는 컴퓨팅 장치 상에서 구현될 수 있다. 컴퓨터 판독 가능 기록 매체는 프로세서(110)의 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(110)와 연결될 수 있다. 컴퓨팅 장치 내의 프로세서(110)는 각 컴퓨팅 장치로 하여금 본 명세서에서 기술되는 예시적인 실시예에 따라 동작하도록 할 수 있다.
예를 들어, 프로세서(110)는 컴퓨터 판독 가능 기록 매체에 저장된 명령어를 실행할 수 있고, 컴퓨터 판독 가능 기록 매체에 저장된 명령어는 프로세서(110)에 의해 실행되는 경우 컴퓨팅 장치로 하여금 본 명세서에 기술되는 예시적인 실시예에 따른 동작들을 수행하도록 구성될 수 있다.
일 실시예로, 프로세서(110)는 쿠버네티스 클러스터 내 노드에 포함된 복수의 pod들에 클라우드 컴퓨팅 자원을 설정할 수 있다.
프로세서(110)는 복수의 pod들에 대한 요청량(request) 및 복수의 pod들에 대한 제한량(limit)를 수신하고, 클라우드 컴퓨팅 자원 중에서 복수의 pod들 중 상기 요청량 및 상기 제한량에 기초하여 상기 요청량 및 상기 제한량이 0인 Best-effort QoS(Quality of Service) 클래스로 분류한 또 다른 복수의 pod들에 설정할 잔여 자원을 결정하고, 상기 클라우드 컴퓨팅 자원 설정 장치가 상기 제2 복수의 pod들에서 pod 전체 개수에 대한 pod 하나의 비율(ratio)에 따라, 상기 잔여 자원을 상기 제2 복수의 pod들 각각에 설정할 수 있다.
프로세서(110)는 제1 복수의 pod들에 대한 요청량(request) 및 제1 복수의 pod들에 대한 제한량(limit)을 수신할 수 있다. 예를 들어, 제1 복수의 pod들은 쿠버네티스의 QoS 클래스가 분류되지 않은 pod들을 의미할 수 있다.
프로세서(110)는 클라우드 컴퓨팅 자원 중에서, 제1 복수의 pod들 중 요청량 및 제한량에 기초하여 Besteffort QoS(Quality of Service) 클래스로 분류한 제2 복수의 pod들에 설정할 잔여 자원을 결정할 수 있다.
예를 들어, 클라우드 컴퓨팅 자원은 CPU 자원을 의미할 수 있다.
프로세서(110)는 요청량 및 제한량에 기초하여 제1 복수의 pod들을 요청량에 대해 최대한의 자원 사용을 보장하는 Guaranteed QoS 클래스, 요청량 만큼의 최소 자원 사용을 보장하는 Burstable QoS 클래스 및 Best-effort QoS(Quality of Service) 클래스로 분류할 수 있다. 예를 들어, 프로세서(110)는 제1 복수의 pod들 중에서 요청량 및 제한량이 동일한 pod를 Guaranteed QoS 클래스로 분류할 수 있다. 프로세서(110)는 제1 복수의 pod들 중에서 요청량이 제한량 미만인 pod를 Burstable QoS 클래스로 분류할 수 있다. 프로세서(110)는 제1 복수의 pod들 중에서 요청량 및 제한량이 0인 pod를 Best-effort QoS 클래스로 분류할 수 있다.
프로세서(110)는 Guaranteed QoS 클래스로 분류한 pod에 대응하는 요청량에 따라, Guaranteed QoS 클래스로 분류한 pod에 클라우드 컴퓨팅 자원을 설정할 수 있다.
프로세서(110)는 Burstable QoS 클래스로 분류한 pod에 대응하는 요청량에 따라, Burstable QoS 클래스로 분류한 pod에 클라우드 컴퓨팅 자원을 설정할 수 있다.
프로세서(110)는 클라우드 컴퓨팅 자원 중에서 Guaranteed QoS 클래스로 분류한 pod에 설정한 자원 및 Burstable QoS 클래스로 분류한 pod에 설정한 자원을 뺀 나머지를 Best-effort QoS(Quality of Service) 클래스로 분류한 pod에 설정할 잔여 자원으로 결정할 수 있다.
프로세서(110)는 제2 복수의 pod들 중에서 어느 하나의 제2 복수의 pod들에 대한 비율(ratio)에 따라, 제2 복수의 pod들 중에서 어느 하나에 잔여 자원을 설정할 수 있다. 예를 들어, 제2 복수의 pod들은 Best-effort QoS(Quality of Service) 클래스로 분류된 pod들을 의미할 수 있다. 프로세서(110)는 제2 복수의 pod들 중에서 어느 하나의 제2 복수의 pod들(n)에 대한 비율(ratio)을 계산할 수 있다. 제2 복수의 pod들 중에서 어느 하나의 제2 복수의 pod들(n)에 대한 비율은 1/n을 의미할 수 있다. 프로세서(110)는 제2 복수의 pod들 중에서 어느 하나에 잔여 자원을 계산한 비율에 따라 설정할 수 있다. 프로세서(110)는 제2 복수의 pod들의 갯수가 10이라고 가정하면 비율은 1/10으로 계산할 수 있다. 프로세서(110)는 잔여 자원이 100이면, pod 하나에 10의 자원을 설정할 수 있다.
메모리(130)는 휘발성 및/또는 비휘발성 메모리(130)를 포함할 수 있다. 메모리(130)는 자원 설정 장치의 적어도 하나의 다른 구성요소에 관계된 명령 및/또는 데이터를 저장할 수 있다.
메모리(130)는 소프트웨어(software) 및/또는 프로그램(program) 등을 저장할 수 있다. 예를 들어, 메모리(130)는 쿠버네티스 내 노드에 포함된 복수의 pod들에 클라우드 컴퓨팅 자원을 설정하기 위한 어플리케이션 및 소프트웨어 등을 저장할 수 있다.
추가적인 실시예로, 메모리(130)는 오버레이 네트워크가 적용된 쿠버네티스 클러스터 내 계층적 구조를 갖는 구성들 각각에 대한 정보와 계층적 구조 및 상기 계층적 구조에 따른 구성들 간의 접속 경로가 저장될 수 있다.
프로세서(110)는 쿠버네티스 클러스터에서 발생하는 이벤트를 통신부를 통해 수집하고, 수집된 이벤트를 보안 정책을 기반으로 모니터링하고, 모니터링 결과 이상 징후가 판단되면, 메모리(130)에 저장된 접속 경로를 기반으로 상기 이상 징후에 대한 공격 출발지로부터 공격 목적지의 접속 경로를 추적할 수 있다.
프로세서(110)는 상기 이상 징후가 감지된 제1 pod 내 제1 구성에 대한 포트를 공격 출발지로 식별하고, 상기 이상 징후가 감지된 제2 pod 내 제2 구성에 대한 포트를 상기 공격 목적지로 식별하고, 상기 메모리(130)에 저장된 쿠버네티스 클러스터 내 구성들의 계층적 구조에 따른 접속 경로를 기반으로, 상기 제1 pod로부터 Router의 제1 경로에 포함된 구성들을 식별하고, 상기 식별된 구성들 간의 접속 경로를 식별하고, 상기 Router로부터 상기 제2 pod의 제2 경로에 포함된 구성들을 식별하고, 상기 식별된 구성들 간의 접속 경로를 식별할 수 있다.
상기 제1 경로에 포함된 구성들은 제1 pod가 속한 제1 veth(Virtual Ethernet Devices), 제1 CNI, 제1 NAT(Network Address Translation) 및 제1 eth0를 포함하고, 상기 제2 경로에 포함된 구성들은 제2 pod가 속한 제2 veth(Virtual Ethernet Devices), 제2 CNI, 제2 NAT(Network Address Translation) 및 제2 eth0를 포함할 수 있다.
프로세서(110)는 상기 저장부에 저장된 접속 경로를 기반으로, 상기 제1 pod가 속한 제1 veth(Virtual Ethernet Devices)로부터 제1 CNI의 접속 경로, 상기 제1 CNI로부터 제1 NAT(Network Address Translation)의 접속 경로, 상기 제1 NAT로부터 제1 eth0의 접속 경로, 상기 제1 eth0로부터 Router의 접속 경로, 상기 Router로부터 제2 eth0의 접속 경로, 상기 제2 eth0로부터 제2 NAT의 접속 경로, 상기 제2 NAT로부터 제2 CNI의 접속 경로, 상기 제2 CNI로부터 제2 pod이 속한 제2 veth의 접속 경로를 식별할 수 있다.
메모리(130)는 상기 쿠버네티스 클러스터 내 파드, 컨테이너 및 네임스페이스에 관한 정보와 상기 쿠버네티스 클러스터 내 구성들의 정보를 확인하기 위해 미리 결정된 명령어가 저장되어 있으며, 프로세서(110)는 기 설정된 시간마다 상기 미리 결정된 명령어를 이용하여 상기 쿠버네티스 클러스터 내 구성들의 정보를 확인하고, 상기 저장부에 저장된 정보를 업데이트할 수 있다.
프로세서(110)는 상기 미리 결정된 명령어를 이용하여 상기 쿠버네티스 클러스터 내 eth0, flannel 및 cni의 정보(예: 위치, 주소)를 확인할 수 있다.
프로세서(110)는 상기 수집된 이벤트를 기반으로 상기 쿠버네티스 클러스터 내 기존 pod의 삭제 또는 신규 pod의 생성을 감지하고, 상기 감지된 결과를 기반으로 상기 저장부 내 데이터를 업데이트할 수 있다.
프로세서(110)는 상기 쿠버네티스 클러스터 내 기존 pod가 삭제되거나 신규 pod가 생성되는 경우, 상기 저장부에 저장되어 있는 계층적 구조 및 상기 계층적 구조에 따른 구성들 간의 접속 경로에 관한 정보를 기반으로 상기 저장부 내 데이터를 업데이트할 수 있다.
프로세서(110)는 상기 쿠버네티스 클러스터 내 접속 경로 또는 구성에 대한 기 설정된 제1 횟수를 초과하는 접속 시도가 감지되는 경우, 상기 접속 시도를 이상 징후로 판단할 수 있다.
상기 제1 횟수는 상기 쿠버네티스 클러스터 내 계층적 구조를 갖는 상기 구성들 간의 접속 경로마다 설정될 수 있으며, 프로세서(110)는 상기 접속 경로마다 설정되어 있는 제1 횟수를 기반으로 상기 접속 시도를 이상 징후로 판단할 수 있다.
프로세서(110)는 상기 이상 징후에 대하여 식별된 공격 출발지, 공격 목적지 및 상기 공격 출발지로부터 상기 공격 목적지에 포함된 접속 경로 상의 구성들과 상기 접속 시도의 횟수를 기반으로 보안 위험도를 산출할 수 있다.
이상에서 전술한 본 개시의 일 실시예에 따른 방법은, 하드웨어인 서버와 결합되어 실행되기 위해 프로그램(또는 어플리케이션)으로 구현되어 매체에 저장될 수 있다.
상기 전술한 프로그램은, 상기 컴퓨터가 프로그램을 읽어 들여 프로그램으로 구현된 상기 방법들을 실행시키기 위하여, 상기 컴퓨터의 프로세서(CPU)가 상기 컴퓨터의 장치 인터페이스를 통해 읽힐 수 있는 C, C++, JAVA, 기계어 등의 컴퓨터 언어로 코드화된 코드(Code)를 포함할 수 있다. 이러한 코드는 상기 방법들을 실행하는 필요한 기능들을 정의한 함수 등과 관련된 기능적인 코드(Functional Code)를 포함할 수 있고, 상기 기능들을 상기 컴퓨터의 프로세서가 소정의 절차대로 실행시키는데 필요한 실행 절차 관련 제어 코드를 포함할 수 있다. 또한, 이러한 코드는 상기 기능들을 상기 컴퓨터의 프로세서가 실행시키는데 필요한 추가 정보나 미디어가 상기 컴퓨터의 내부 또는 외부 메모리의 어느 위치(주소 번지)에서 참조되어야 하는지에 대한 메모리 참조관련 코드를 더 포함할 수 있다. 또한, 상기 컴퓨터의 프로세서가 상기 기능들을 실행시키기 위하여 원격(Remote)에 있는 어떠한 다른 컴퓨터나 서버 등과 통신이 필요한 경우, 코드는 상기 컴퓨터의 통신 모듈을 이용하여 원격에 있는 어떠한 다른 컴퓨터나 서버 등과 어떻게 통신해야 하는지, 통신 시 어떠한 정보나 미디어를 송수신해야 하는지 등에 대한 통신 관련 코드를 더 포함할 수 있다.
상기 저장되는 매체는, 레지스터, 캐쉬, 메모리 등과 같이 짧은 순간 동안 데이터를 저장하는 매체가 아니라 반영구적으로 데이터를 저장하며, 기기에 의해 판독(reading)이 가능한 매체를 의미한다. 구체적으로는, 상기 저장되는 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있지만, 이에 제한되지 않는다. 즉, 상기 프로그램은 상기 컴퓨터가 접속할 수 있는 다양한 서버 상의 다양한 기록매체 또는 사용자의 상기 컴퓨터상의 다양한 기록매체에 저장될 수 있다. 또한, 상기 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장될 수 있다.
본 개시의 실시예와 관련하여 설명된 방법 또는 알고리즘의 단계들은 하드웨어로 직접 구현되거나, 하드웨어에 의해 실행되는 소프트웨어 모듈로 구현되거나, 또는 이들의 결합에 의해 구현될 수 있다. 소프트웨어 모듈은 RAM(Random Access Memory), ROM(Read Only Memory), EPROM(Erasable Programmable ROM), EEPROM(Electrically Erasable Programmable ROM), 플래시 메모리(Flash Memory), 하드 디스크, 착탈형 디스크, CD-ROM, 또는 본 개시가 속하는 기술 분야에서 잘 알려진 임의의 형태의 컴퓨터 판독가능 기록매체에 상주할 수도 있다.
이상, 첨부된 도면을 참조로 하여 본 개시의 실시예를 설명하였지만, 본 개시가 속하는 기술분야의 통상의 기술자는 본 개시가 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로, 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며, 제한적이 아닌 것으로 이해해야만 한다.
10: 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법 시스템
100: 서버
110: 프로세서
120: 통신부
130: 메모리

Claims (10)

  1. 통신부;
    하나 이상의 인스트럭션을 저장하는 메모리; 및
    상기 메모리에 저장된 상기 인스트럭션을 실행하는 하나 이상의 프로세서를 포함하며,
    상기 프로세서는,
    컨테이너(Container)를 pod 내에 배치하고 노드에서 실행함으로써 워크로드를 구동하는 쿠버네티스(Kubernetes) 클러스터에서 발생하는 이벤트를 상기 통신부를 통해 수집하고,
    상기 수집된 이벤트 중에서 컨테이너 이미지를 다운로드하는 제1 이벤트가 감지되는 경우, 상기 컨테이너 이미지에 대한 무결성을 검증하고,
    상기 수집된 이벤트가 상기 컨테이너 이미지에 대한 변경사항을 포함하는 경우, 상기 변경사항에 포함된 정의를 확인하여 상기 정의가 미리 합의되어 있는 정의인지 여부를 확인하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버.
  2. 제1항에 있어서,
    상기 쿠버네티스 클러스터는, 마스터 노드와 상기 마스터 노드에 할당된 적어도 하나의 워커 노드가 포함하며,
    상기 프로세서는,
    상기 워커 노드의 Kubelet을 통해 상기 이벤트를 수집하며,
    상기 제1 이벤트가 감지되는 경우, 상기 Kubelet을 통해 상기 마스터 노드의 API SERVER에 상기 컨테이너 이미지의 무결성을 검증하기 위한 데이터를 요청하는 것을 특징으로 하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버.
  3. 제2항에 있어서,
    상기 프로세서는, 상기 컨테이너 이미지가 생성되면 상기 생성된 상기 컨테이너 이미지를 컨테이너 레지스트리에 저장하며,
    상기 프로세서는, 상기 생성된 상기 컨테이너 이미지가 상기 컨테이너 레지스트리에 저장될 때, 상기 컨테이너 레지스트리에 상기 생성된 상기 컨테이너 이미지의 제1 해시(Hash)가 저장되도록 제어하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버.
  4. 제3항에 있어서,
    상기 프로세서는,
    상기 Kubelet이 상기 레지스트리에서 상기 컨테이너 이미지에 대한 상기 제1 해시(Hash)를 가져오도록 요청하고,
    상기 컨테이너 이미지에 대한 현재 상태의 제2 해시 및 상기 Kubelet을 통해 획득한 상기 제1 해시를 기반으로 상기 컨테이너 이미지에 대한 무결성을 검증하는 것을 특징으로 하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버.
  5. 삭제
  6. 제2항에 있어서,
    상기 프로세서는,
    상기 API SERVER에서 상기 컨테이너 이미지의 기존 상태에 대한 제1 정의를 수집하도록 상기 Kubelet으로 요청하고,
    상기 컨테이너 이미지에 대한 상기 변경사항이 포함된 제2 정의와 상기 제1 정의를 기반으로 상기 컨테이너 이미지에 대한 상기 변경사항을 확인하는 것을 특징으로 하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버.
  7. 제6항에 있어서,
    상기 프로세서는,
    상기 변경사항이 확인되면, 상기 확인된 변경사항이 미리 합의된 정의에 해당하는지 여부를 확인하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버.
  8. 제7항에 있어서,
    상기 프로세서는,
    상기 Kubelet으로 상기 쿠버네티스 클러스터의 클러스터 정보가 저장되는 etcd에 저장되어 있는 상기 컨테이너 이미지에 대한 yaml 파일을 요청하고,
    상기 컨테이너 이미지의 상기 yaml 파일을 통해 상기 제2 정의를 확인하는 것을 특징으로 하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 서버.
  9. 서버에 의해 수행되는 방법으로,
    컨테이너(Container)를 pod 내에 배치하고 노드에서 실행함으로써 워크로드를 구동하는 쿠버네티스(Kubernetes) 클러스터에서 발생하는 이벤트를 수집하는 단계;
    상기 수집된 이벤트 중에서 컨테이너 이미지를 다운로드하는 제1 이벤트가 감지하는 단계; 및
    상기 감지된 제1 이벤트에 해당하는 상기 컨테이너 이미지에 대한 무결성을 검증하는 단계를 포함하며,
    상기 서버는,
    상기 수집된 이벤트가 상기 컨테이너 이미지에 대한 변경사항을 포함하는 경우, 상기 변경사항에 포함된 정의를 확인하여 상기 정의가 미리 합의되어 있는 정의인지 여부를 확인하는,
    컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법.
  10. 하드웨어인 컴퓨터와 결합되어, 제9항의 방법을 실행시키기 위한 프로그램이 저장된 컴퓨터 판독 가능한 기록매체.
KR1020230086902A 2023-07-05 2023-07-05 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법 KR102591865B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020230086902A KR102591865B1 (ko) 2023-07-05 2023-07-05 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020230086902A KR102591865B1 (ko) 2023-07-05 2023-07-05 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법

Publications (1)

Publication Number Publication Date
KR102591865B1 true KR102591865B1 (ko) 2023-10-24

Family

ID=88515137

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020230086902A KR102591865B1 (ko) 2023-07-05 2023-07-05 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법

Country Status (1)

Country Link
KR (1) KR102591865B1 (ko)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170133120A (ko) * 2016-05-25 2017-12-05 삼성에스디에스 주식회사 컨테이너 이미지 관리 시스템 및 방법
KR20220080427A (ko) * 2020-12-07 2022-06-14 주식회사 앰진시큐러스 컨테이너 기반 배포 이미지의 동적 무결성 확인 방법 및 장치
KR102460416B1 (ko) 2016-10-24 2022-10-28 삼성에스디에스 주식회사 컨테이너 기반의 분산 애플리케이션 관리 시스템 및 방법
KR102518980B1 (ko) * 2022-11-17 2023-04-06 에스지에이솔루션즈 주식회사 컨테이너 이미지에 대한 악성 코드를 분석 및 처리하는 방법, 장치 및 컴퓨터-판독 가능 기록 매체

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170133120A (ko) * 2016-05-25 2017-12-05 삼성에스디에스 주식회사 컨테이너 이미지 관리 시스템 및 방법
KR102460416B1 (ko) 2016-10-24 2022-10-28 삼성에스디에스 주식회사 컨테이너 기반의 분산 애플리케이션 관리 시스템 및 방법
KR20220080427A (ko) * 2020-12-07 2022-06-14 주식회사 앰진시큐러스 컨테이너 기반 배포 이미지의 동적 무결성 확인 방법 및 장치
KR102518980B1 (ko) * 2022-11-17 2023-04-06 에스지에이솔루션즈 주식회사 컨테이너 이미지에 대한 악성 코드를 분석 및 처리하는 방법, 장치 및 컴퓨터-판독 가능 기록 매체

Similar Documents

Publication Publication Date Title
CA3151312C (en) Model building architecture and smart routing of work items
US10606739B2 (en) Automated program code analysis and reporting
US9612765B2 (en) Context aware dynamic composition of migration plans to cloud
US8166552B2 (en) Adaptive configuration management system
US11720826B2 (en) Feedback loop learning between artificial intelligence systems
US11356324B2 (en) Chaos engineering in microservices using a service mesh
US20200311600A1 (en) Method and system for prediction of application behavior
Dehraj et al. A review on architecture and models for autonomic software systems
Forti et al. Simulating fogdirector application management
CN114667507A (zh) 使用基于应用的剖析的机器学习工作负载的弹性执行
Faraji Mehmandar et al. A dynamic fog service provisioning approach for IoT applications
Naik Applying computational intelligence for enhancing the dependability of multi-cloud systems using docker swarm
Chaterji et al. Resilient cyberphysical systems and their application drivers: A technology roadmap
Aleti Designing automotive embedded systems with adaptive genetic algorithms
US11392821B2 (en) Detecting behavior patterns utilizing machine learning model trained with multi-modal time series analysis of diagnostic data
da Silva et al. Online machine learning for auto-scaling in the edge computing
KR102591865B1 (ko) 컨테이너 오케스트레이션을 위한 클라우드 데이터 검증 및 관리 방법
Abro et al. Artificial intelligence enabled effective fault prediction techniques in cloud computing environment for improving resource optimization
Al-Hashimi et al. Fog-cloud scheduling simulator for reinforcement learning algorithms
US20230237366A1 (en) Scalable and adaptive self-healing based architecture for automated observability of machine learning models
US11765043B2 (en) Data driven chaos engineering based on service mesh and organizational chart
Dehraj et al. An approach to design and develop generic integrated architecture for autonomic software system
KR102606713B1 (ko) 쿠버네티스 클러스터의 모니터링을 위한 통합 보안관제 시스템, 장치, 방법 및 프로그램
Tran et al. Optimized resource usage with hybrid auto-scaling system for knative serverless edge computing
Gulenko et al. Anomaly Detection and Levels of Automation for AI-Supported System Administration

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
A107 Divisional application of patent
GRNT Written decision to grant