Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

쿠버네티스

IDG 블로그 | 멀티클라우드 2.0 시대를 여는 쿠버네티스

슬슬 2.0이란 말에도 지치는 시절이다. 이 용어는 업계가 시장의 판도를 바꿀 수 있는 무언가를 지칭하는 용어로 사용하지만, 조금 더 혁신적이고 창의적일 필요가 있지 않을까? 멀티클라우드의 경우, 1.0 버전은 수많은 퍼블릭 클라우드 브랜드를 대부분 기업이 사용하면서 부상했다. 기업은 보통 전용 CMP(Cloud Management Platform)나 CSB(Cloud Service Broker)에 의존해 수많은 클라우드 네이티브 서비스를 관리한다.    오늘날 대부분 멀티클라우드 배치 환경을 관리하는 방식이다. CMP나 CSB가 없다면, 각각의 클라우드 네이티브 서비스를 각 클라우드 서비스 업체가 제공하는 클라우드 네이티브 콘솔 같은 것을 사용해 다루어야 한다. 이 경우 멀티클라우드 환경에 세 곳의 퍼블릭 클라우드를 사용한다면, 서로 다른 세 개의 관리 인터페이스와 기술이 있어야 한다. 이 방식은 너무 복잡해 장기적으로 운영 가능한 환경을 만들기 어렵다. 현재 떠오르는 멀티클라우드 2.0은 다른 방식의 멀티클라우드이다. 바로 연합된 쿠버네티스를 사용해 컨테이너화된 애플리케이션과 데이터를 관리하는 것으로, 워크로드는 서로 다른 퍼블릭 클라우드 서비스 업체에서 구동하지만 서로를 인지하고 있다. 이 아키텍처는 멀티클라우드 상에서 구동하는 다중 클러스터를 다루기 쉽다. 주요 구성 요소는 두 가지로, 하나는 여러 클러스터에 걸쳐서 자원을 동기화하는 역량이다. 예상하는 것처럼 멀티클라우드 쿠버네티스 배치의 핵심 과제이다. 쿠버네티스 내의 메커니즘은 자동으로 멀티클라우드 상에서 구동하는 여러 클러스터 배치를 동기화할 수 있다. 두번째는 클러스터 내의 디스커버리이다. 이는 자동으로 DNS 서버와 로드밸런서를 구성해 수많은 퍼블릭 클라우드에 걸쳐 구동하는 모든 클러스터를 지원하는 역량이다. 멀티클라우드와 쿠버네티스를 활용하는 이점에는 고가용성도 포함되는데, 액티브/액티브 클러스터를 여러 곳의 퍼블릭 클라우드에 걸쳐 복제할 수 있기 때문이다. 따라...

클러스터 멀티클라우드 쿠버네티스 2019.09.23

VM웨어, 쿠버네티스 네이티브 전략 발표…관리자와 개발자 모두를 위한 vSphere 환경

VM웨어가 자사의 기존 vSphere 고객이 좀 더 쉽게 쿠버네티스 컨테이너를 구축하고 관리할 수 있도록 돕는 새로운 구상인 VM웨어 탄주(Tanzu)를 발표했다. 수많은 신기술과 VM웨어의 기존 기술로 구성된 탄주 플랫폼은 쿠버네티스 컨테이너 환경에서 신속하게 소프트웨어를 구축하고자 하는 기업을 대상으로 한 일군의 제품과 서비스를 생성한다. VM웨어는 쿠버네티스가 애플리케이션의 다양성을 수용할 수 있는 인프라 계층으로 부상했다고 본다. 2018년부터 2023년까지 5억 개의 새로운 논리 앱이 만들어져 모든 환경에 걸쳐 다양한 애플리케이션의 필요에 부응할 것이며, 새로운 툴과 플랫폼, 더 많은 개발자, 민첩한 개발 방법론, 그리고 더 코드 재사용이 이루어질 것으로 보고 있다.   CEO 팻 겔싱어는 “우리는 탄주를 개발 세상과 운영 세상을 이으려는 고객을 위한 포괄적인 환경으로 본다. 초강력 엔터프라이즈급 쿠버네티스 플랫폼이 될 것이다. 쿠버네티스는 이런 변화에서 중심 툴이며, VM웨어는 이를 위해 많은 작업을 하고 있다”고 밝혔다. 겔싱어는 VM웨어가 쿠버네티스 기술에 투자한 것을 강조했는데, 헵티오(Heptio), 비트나미(Bitnami)에 이어 피보탈(Pivotal)까지 인수했다. 이로써 VM웨어는 세 손가락에 드는 쿠버네티스 오픈소스 기여자가 됐다. 원대한 탄주 계획의 핵심은 프로젝트 퍼시픽(Project Pacific)이란 기술로, 쿠버네티스를 VM웨어의 주력 가상화소프트웨어인 vSphere에 추가해준다. 쿠버네티스를 vSphere 제어판에 내장함으로써 컨테이너와 가상머신의 융합을 단일 플랫폼에서 구현할 수 있다. 프로젝트 퍼시픽은 또한 컨테이너 런타임을 하이퍼바이저에 추가해 준다. 이렇게 쿠버네티스를 내장함으로써 VM웨어의 베어메탈 하이퍼바이저인 ESXi는 쿠버네티스 팟의 가장 뛰어난 특성과 가상머신을 결합해 핵심 워크로드를 위한 고성능 런타임을 제공할 수 있다. 여기에 더해 프로젝트 퍼시픽은 가상머신과 컨테이너 전체에 가상 네트...

VMworld vSphere 쿠버네티스 2019.08.27

시스코, 애저 클라우드와 손잡고 하이브리드 쿠버네티스 전략 확장

시스코가 자사 솔루션 기반의 온프레미스 환경과 마이크로소프트 애저 클라우드에 걸쳐 컨테이너화된 애플리케이션을 실행할 수 있는 서비스를 출시했다.    이제 기업 고객은 온프레미스 환경과 AKS(Azure Kubernetes Service)의 쿠버네티스 클러스터 배치와 관리를 하나의 툴로 더욱 단순화할 수 있다. 특히 AKS는 기존에도 시스코 컨테이너 플랫폼(Cisco Container Platform)에 통합할 수 있는 쿠버네티스 매니지드 서비스에 추가되어 있었다. 시스코는 2018년 1월 쿠버네티스 기반의 컨테이너 플랫폼을 도입했으며, 컨테이너 클러스터의 셀프서비스 배치와 관리를 지원했다. 시스코는 이 플랫폼에 여러 솔루션 업체에 대한 지원을 추가했는데, 예를 들어 SAP 데이터 허브를 AWS나 마이크로소프트, 구글과 같은 퍼블릭 클라우드에 있는 대규모 데이터 세트와 통합하고, 이를 또 프라이빗 클라우드나 SAP S/4 HANA와 같은 엔터프라이즈 애플리케이션과 통합할 수 있도록 지원한다. 구글이 처음 개발한 쿠버네티스는 컨테이너화된 애플리케이션의 개발과 오케스트레이션을 위한 오픈소스 기반 시스템이다. 컨테이너를 여러 대의 서버 호스트에 걸쳐 배치할 수 있는데, 쿠버네티스 오케스트레이션이 여러 컨테이너에 걸쳐 배치되는 애플리케이션 서비스를 구축할 수 있도록 해 준다. 클러스터 전반에 걸쳐 이들 컨테이너의 스케줄을 조정하고 컨테이너와 확장과 상태 관리까지 맡아준다. 시스코는 한동안 애저 서비스와의 통합을 강화해 왔다. 예를 들어 애저 스택용 CIS(Cisco Integrated System)는 기업이 개발 툴과 데이터 저장소 및 관련 애저 서비스에 액세스해 애플리케이션을 새단장하거나 안전한 데이터로부터 새로운 정보를 얻을 수 있다. 애저 스택은 애저 퍼블릭 클라우드와 같은 API와 사용자 인터페이스를 제공한다. 시스코 컨테이너 플랫폼은 앞으로 마이크로소프트 윈도우 컨테이너 애플리케이션을 지원하는 더 많은 기능을 통합할 계획이다. 특...

컨테이너 시스코 애저 2019.08.05

AWS·애저·구글 클라우드의 '관리형' 쿠버네티스 서비스 비교

첫 번째는 컨테이너, 그 다음이 쿠버네티스였다. 세상은 컨테이너화된 애플리케이션을 배포, 관리, 스케일링(축소 및 확장)하는 지겹고 복잡한 작업을 도와줄 구원 투수를 원했다. 그리고 마침내 쿠버네티스가 도움의 손길을 내밀었다. 쿠버네티스의 성장 이유 중 하나는 온프레미스, 클라우드 모두에서 쿠버네티스 클라우드를 실행할 수 있다는 점이다. 나아가 둘 모두를 오갈 수 있다. 즉 환경 간 컨테이너 앱을 이식할 수 있다. 이런 장점 때문에 주요 유명 퍼블릭 클라우드 업체가 모두 관리형 쿠버네티스 서비스를 제공한다. 회사 컨테이너를 클라우드로 옮기기만 하면 클라우드 업체가 나머지를 알아서 처리한다. 그러나 각 클라우드에 고유의 특징이 존재하듯, 쿠버네티스 서비스에도 이런 고유의 특징이 있다. 여기서는 쿠버네티스 플러그인 생태계를 통해 클라우드 스토리지 및 기타 서비스를 지원하는 방식을 중심으로, 아마존과 구글, 마이크로소프트의 호스팅 쿠버네티스 서비스의 특징을 비교, 분석해보자. 아마존 EKS(Elastic Kubernetes Service) AWS는 2014년 말 아마존 일래스틱 컨테이너 서비스(ECS)로 컨테이너를 지원하기 시작했다. 이후 AWS EC2 인스턴스에서 도커를 실행할 수 있게 됐다. 지금은 ECS를 통해 EC2나 서버리스 상품인 AWS 파게이트(AWS Fargate) 중 하나에 도커를 배포할 수 있다. 그리고 몇 년 뒤(일반에 공식 배포된 시기는 2018년 6월) EKS로 쿠버네티스를 지원하기 시작했다. EKS 도입 이전에 AWS에서 쿠버네티스를 실행하는 유일한 방법은 많은 EC2 인스턴스를 스핀업해 수동으로 클러스터를 구성하는 것이었다. 그러나 EKS 도입 이후 쿠버네티스 클러스터를 더 쉽게 실행할 수 있게 됐다. 이제 EC2에 워커 노드를 배포한 후 관리 노드로 연결하면 된다. 아마존은 사용자가 여러 다양한 EC2 인스턴스에서 작업 노드를 실행할 수 있도록 지원한다. 예를 들어, 비용을 절약하기 위해 수요가 낮은 백그라운드 작업은 EC2...

컨테이너 애저 AWS 2019.07.24

와탭랩스-아콘소프트, 쿠버네티스 활성화 위한 업무 협약

와탭랩스(www.whatap.io)는 아콘소프트와 전략적 업무 협약을 체결했다고 밝혔다. 와탭랩스는 클라우드 기반의 IT 통합 모니터링 서비스를 제공하는 기업으로, 최근 쿠버네티스를 위한 APM 서비스를 발표했다.  전통적인 IT 환경과 클라우드를 모두 지원하는 와탭 IT 모니터링 서비스는 멀티 클라우드뿐만 아니라 하이브리드 클라우드 환경에서도 통합 모니터링이 가능하며, 서비스형 소프트웨어(Public SaaS) 방식과 설치형(On-Premise/Private SaaS) 방식 2가지로 이용할 수 있다.  와탭 통합 모니터링에서 지원하는 클라우드 환경에는 ▲아마존웹서비스(AWS) ▲마이크로소프트 애저(Azure) ▲구글컴퓨트엔진(GCE) ▲케이티 u클라우드 ▲G-클라우드 ▲네이버 NBP ▲엔에이치엔 TOAST 등이 있다. 아콘소프트는 애플리케이션의 지속적인 개발·배포·운영 환경을 제공하는 컨테이너 기반의 애플리케이션 관리 솔루션인 칵테일 클라우드를 개발해 국내외 기업의 쿠버네티스 도입 컨설팅을 지원하고 있다. 와탭랩스와 아콘소프트는 이번 협약을 통해 기업에게 쿠버네티스 도입에서 완성까지 지원해 기업의 쿠버네티스 도입을 활성화할 계획이다. 그리고 양사의 세일즈와 마케팅에 대한 협력도 지속해 나갈 예정이다. 와탭랩스 이동인 대표는 “아콘소프트의 칵테일 클라우드는 쿠버네티스 기반의 클라우드 도입에 꼭 필요한 솔루션”이라며, “와탭랩스는 아콘소프트와의 긴밀한 협력을 통해 쿠버네티스를 도입하는 개발자와 운영자들이 더 쉽고 안정적으로 IT 서비스를 운영할 수 있도록 지원하고자 한다”고 말했다. editor@itworld.co.kr

쿠버네티스 와탭랩스 아콘소프트 2019.07.23

서비스 메시의 의미와 서비스 메시 프로젝트들

IT에서 디지털 트랜스포메이션이라는 깃발 아래에 일어나고 있는 변화 가운데 하나는 대규모의 모놀리식 애플리케이션을 마이크로서비스(microservices)로 쪼개는 일이다. 마이크로서비스는 격리 가능하고 한 서버에서 다른 서버로 손쉽게 이동이 가능한, 모든 서비스 코드와 종속성이 포함된 소프트웨어 패키지인 컨테이너에서 실행되는 작은 개별적 기능 단위다.   이와 같이 컨테이너화된 아키텍처는 손쉽게 확장이 가능하고 클라우드에서 실행할 수 있으며 개별 마이크로서비스는 신속한 롤아웃과 반복이 가능하다. 그러나 애플리케이션이 커지고 동일한 서비스의 여러 인스턴스가 동시에 실행되면 이러한 마이크로소프트 간의 통신은 점점 더 복잡해진다. 서비스 메시(service mesh)는 최근 부상하는 아키텍처 형식으로, 관리 및 프로그래밍 오버헤드를 낮추는 방식으로 마이크로서비스를 동적으로 연결하는 데 목표를 둔다. 서비스 메시란 무엇인가 가장 넓은 의미에서 레드 햇(Red Hat)의 설명을 옮기자면 "서비스 메시는 애플리케이션의 여러 부분에서 상호 데이터를 공유하는 방법을 통제하는 수단"이다. 그러나 이 설명은 지나치게 포괄적이기도 하다. 설명만 보면 대부분의 개발자가 클라이어언트-서버 애플리케이션에서 익숙한 미들웨어와 거의 비슷하다. 서비스 메시의 고유한 부분은 분산 마이크로서비스 환경의 특성을 포용한다는 점이다. 마이크로서비스로 빌드된 대규모 애플리케이션에는 특정 서비스의 여러 인스턴스가 다양한 로컬 또는 클라우드 서버에서 실행될 수 있다. 움직이는 부분이 많은 만큼 개별 마이크로서비스가 통신야 하는 상대방 서비스를 찾기도 당연히 더 어렵다. 서비스 메시는 매 순간 서비스를 찾고 연결하는 과정을 자동으로 처리하므로 인간 개발자와 개별 마이크로서비스에서 직접 이 작업을 할 필요가 없다. 서비스 메시는 OSI 네트워킹 모델 7계층을 위한 SDN(Software-Defined Networking)과 같다고 생각하면 된다. 네트워크 관리자가 물리적 네트워크 연결을 ...

쿠버네티스 서비스메시 2019.06.18

IDG 블로그 | “컨테이너 세금”에 주의하라

컨테이너는 애플리케이션을 클라우드에 배치하는 참신하고 편리한 방법이지만, 추가 비용이 있다는 것을 잊어서는 안된다.   컨테이너는 애플리케이션 개발에서 있어서 몇 가지 기본적인 특징과 이점이 있다. 이점은 다음과 같다. -    컨테이너 추상화를 통해 복잡성을 줄여준다. 애플리케이션의 기반 플랫폼이 아니라 컨테이너를 다루면 된다. -    자동화를 통해 이식성을 극대화한다. 한 번 작성해서 여러 곳에서 실행할 수 있는 것이다. -    컨테이너 외부에 대해 더 나은 보안과 거버넌스를 제공한다. -    컨테이너의 핵심 아키텍처 양식이 분산화이기 때문에 분산 컴퓨팅 역량을 개선할 수 있다. -    정책 기반의 최적화를 제공하는 자동화 서비스를 제공한다. -    쿠버네티스 같은 컨테이너 오케스트레이션을 사용할 수 있다. -    컨테이너를 지원하는 수많은 서비스 및 솔루션 업체의 생태계를 이용할 수 있다. 컨테이너의 문제는 모두가 컨테이너를 사용하고자 하지만, 아무도 컨테이너를 구축하고 배치하는 데 드는 추가 비용을 모른다는 것이다. 실제로 필자는 새 애플리케이션이나 기존 애플리케이션을 컨테이너로 옮기거나 구축하는 데 평균 35% 추가 비용이 드는 것으로 보고 있다. 도대체 어디에 이런 비용이 드는 것일까? 주요 항목은 다음과 같다. 첫째, 컨테이너 설계에 손이 많이 간다. 따라서 초기 설계나 컨테이너로 옮기고자 하는 기존 애플리케이션의 리팩터링에 더 많은 시간을 사용하는 것이 합리적이다. 둘째, 툴 비용이 더 든다. 컨테이너 기반의 툴은 무료 툴 외에 데이터베이스 액세스나 보안, 거버넌스를 제공하는 툴이 전통적인 툴보다 50% 정도 더 비싸다. 물론 유용한 툴은 중요하지만, 비용도 고려해야 할 것이다. 마지막, 컨테이너는 운영과 유지보수 비용이 더 든...

아키텍처 컨테이너 추가비용 2019.06.05

"쿠버네티스와 컨테이너의 변화를 이끈다" 가장 믿음직한 쿠버네티스 배포판 10선

쿠버네티스(Kubernetes)는 대규모 컨테이너 오케스트레이션이 필요한 경우 최적의 프로젝트로 꼽힌다. 구글이 만들어낸 오픈소스 컨테이너 시스템 쿠버네티스는 업게의 인정과 지원을 통해 빠르게 발전하고 있다. 쿠버네티스는 또한, 제멋대로 뻗쳐 나가며 복잡하고 설정 및 구성이 어렵다. 그 뿐만 아니라 최종 사용자가 많은 힘든 일을 처리해야 한다. 따라서 최고의 접근방식은 혼자서 시도하는 것이 아니라 쿠버네티스가 지원되고 유지보수되는 구성요소에 포함된 완전한 컨테이너 솔루션을 찾는 것이다. 리눅스 커널과 유저랜드의 배포판을 제공하는 것과 같은 방식으로 쿠버네티스와 컨테이너 도구를 통합하는 가장 유명한 쿠버네티스 서비스 9개를 모았다. 아마존 EKS나 구글 쿠버네티스 엔진 같은 전용 클라우드 서비스는 포함되어 있지 않고, 로컬이나 클라우드 방식으로 운용할 수 있는 소프트웨어 배포판에 초점을 맞췄다.   코어OS 테크토닉/레드햇 코어OS 코어OS는 도커와 호환되면서 독선적인 이미지 포맷과 자체적인 런타임을 갖추고 있는 컨테이너 지향적인 리눅스 배포판과 "기업용 쿠버네티스" 배포판의 제공 기업이다. 코어OS 테크토닉 스택의 근간을 이룬다.  코어OS 운영체제인 컨테이너 리눅스는 일련의 컨테이너화된 구성요소로 제공되기 때문에 확실히 다르다. 실행 중인 애플리케이션을 종료하지 않고도 자동화된 OS 업데이트를 생산에 배치할 수 있다. 또한 코어OS는 "원클릭" 쿠버네티스 업데이트를 자랑한다. 코어OS 테크토닉은 AWS, 마이크로소프트 애저, 베어 메탈에서 구동한다.  레드햇은 최근 코어OS를 인수해 레드햇 오픈시프트에 통합할 계획이다. 컨테이너 리눅스는 레드햇 코어OS로 브랜드 이미지를 쇄신할 것이다. 이 움직임은 2020년까지 끝나지 않을 것으로 예상되지만 컨테이너 리눅스는 그때까지도 계속 지원될 것이다. 레드햇에 따르면 통합 후에도 "거의 모든" 코어OS 테크토닉의 기능을 사용할 수 있...

레드햇 컨테이너 도커 2019.05.17

새로운 애저 서비스의 핵심은 쿠버네티스와 코스모스 DB

마이크로소프트는 스스로 세 클라우드 회사라고 지칭하기 시작했다. 엑스박스 게이밍 클라우드, 마이크로소프트 365 업무 생산성 서비스, 그리고 가장 중요한 애저가 바로 그 세 클라우드이다. 아마존 웹 서비스(AWS)에 이은 업계 2위의 애저는 초거대 규모의 클라우드로, 미처 따라잡기 힘든 속도로 서비스를 속속 출시하고 있다. 이 속도는 마이크로소프트 3대 개발자 행사에서 더욱 잘 드러나는데, 개발자라면 쏟아져 나오는 발표 내용을 철저히 살펴 봐야 핵심 요소들을 파악할 수 있다.   마이크로소프트가 확실히 주력하고 있는 것은 서버리스 애플리케이션 구축 플랫폼으로서의 애저이다. 이를 통해, 가상머신을 지정할 필요가 없고 초 단위 CPU 사용 시간 별로 비용을 청구하는 인프라 서비스를 제공한다. 애플리케이션에는 머신러닝, 분석, 저장, 연산 등이 가능하도록 매우 다양한 플랫폼 서비스가 자리하고 있다.  상황이 흥미로워지는 곳은 2가지가 만나는 지점이다. 즉, 단일 애저 리전 내에서나 애저 퍼블릭 클라우드 전체에 걸쳐 코드의 확장성을 개선하기 시작하는 지점이다. 분산 애플리케이션은 수작업 구축이 쉽지 않다. 마이크로소프트는 익숙한 도구와 새로운 기능을 모두 활용하여 확장성 자동화 방식을 더 많이 제공한다.   쿠버네티스에서의 이벤트 주도 규모 조정  애저는 다른 대형 퍼블릭 클라우드처럼 쿠버네티스에 크게 의존한다. 하이퍼스케일 연산 작업 시에는 분산 애플리케이션의 관리와 조율이 필수적이다. 이 때, 애플리케이션을 고립된 컨테이너로 제공하면 구축 시스템으로부터 완전한 인프라를 제공하는 절차가 단순해진다. 단, 쿠버네티스는 복잡할 수 있다. 간단한 이벤트 주도 애플리케이션용으로 사용할 때 특히 그렇다. 자바스크립트로 조율되는 쿠버네티스를 갖춘 브리게이드(Brigade)를 쓰는 방법이 있다. 단, 이벤트를 트리거시키거나 요구에 따라 새로운 서버리스 기능을 시작하기 위해 애저의 이벤트그리드(EventGrid)와 같은 도구를 사용 중이...

컨테이너 애저 코스모스 2019.05.10

IDG 블로그 | 쿠버네티스로 클라우드 복잡성 줄이는 방법

쿠버네티스는 보안이나 인프라용으로는 너무 과하게 사용하지만, 자동화용으로는 너무 적게 사용한다. 정말 필요한 사람들이 그 잠재력을 제대로 알지 못한다. 한참 전에 필자는 쿠버네티스가 컨테이너 오케스트레이션 전쟁의 승자라고 선언한 바 있다. 물론 필자의 예견이 맞아서 좋지만, 클라우드 업계의 많은 사람이 쿠버네티스를 모든 문제를 해결하는 최종 병기 기술의 틀에 끼워 넣고 있다. 이 때문에 모든 보안 문제, 모든 인프라 문제를 해결하는 데 쿠버네티스를 과용하고 있으며, 심지어 차기 전략 아이템을 찾고 있는 IT 업체를 위한 완결판 전략이 되기도 한다. 모든 것이 쿠버네티스인 것이다.   클라우드 컴퓨팅 실전 전문가로서, 그리고 쿠버네티스를 온프레미스 환경에서 퍼블릭 클라우드에서 이용하는 사람으로 필자는 쿠버네티스의 장점은 모두 사실이라고 말할 수 있다. 하지만 마찬가지로 필자는 사람들이 쿠버네티스를 2020년에 직면하게 될 핵심적인 문제, 즉 클라우드 복잡성을 해결하는 데 도움이 되는 기술로 고려하지 않는다는 사실도 말할 수 있다. 클라우드 복잡성을 유발하는 원인은 크게 두 가지이다. 첫 번째는 클라우드 플랫폼을 선택할 때 이기종 기술의 과용하는 것이다. 멀티클라우드는 좋은 개념이긴 하지만, 수천 가지 네이티브 API를 두세 가지 인수로 하나의 통일된 플랫폼으로 넣는 것은 개발자는 물론 운영팀의 일을 몹시 힘들게 만든다. 두 번째, 적절한 계획없이 클라우드 솔루션을 배치하는 것이다. 최소한의 위험으로 멀티클라우드 솔루션을 배치하는 데는 최소한의 이해가 필요하다. 현재 무엇을 하고 있고 어떤 방법으로 어디로 가려는지 잘 알고 있어야 한다. 대부분 기업은 이런 질문에 대답하지 못하고 반동적인 상태에서 계속 운영한다. 이런 클라우드 복잡성에 대한 해결책도 두 가지이다. 우선, 추상화가 있다. 최소 공통분모 접근법으로 추상화 계층을 사용해 클라우드 네이티브 툴과 인터페이스를 직접 처리하는 복잡성을 제거하는 것이다. 두 번째는 자동화이다. 인터페...

복잡성 컨테이너 쿠버네티스 2019.05.03

도커 엔터프라이즈 3.0, 안전한 쿠버네티스 스택 통합

도커는 안전한 쿠버네티스 스택을 통합한 도커 엔터프라이즈 3.0을 베타 버전으로 발표했다. 또한 도커 엔터프라이즈의 매니지스 서비스 옵션도 공개했다. 도커 엔터프라이즈는 컨테이너 기반 애플리케이션을 구축하고 실행하고 공유하는 엔드 투 엔드 플랫폼으로 자리 잡고 있다. 새 버전의 도커 쿠버네티스 서비스(Docker Kubernetes Service, DKS)는 쿠버네티스 컨테이너 오케스트레이션을 개발자의 데스크톱에서 프로덕션 서버로 통합한다.   DKS는 쿠버네티스 YAML, 헬름 차트, 도커 컴포즈 툴을 이용해 멀티컨테이너 애플리케이션을 생성할 수 있다. 또한 쿠버네티스 애플리케이션을 하이브리드 및 멀티클라우드 배치 환경에 설치하고 환경을 구성하는 자동화된 방법을 제공한다. 이외에도 보안, 액세스 제어, 라이프사이클 관리 등의 기능을 갖추었다. 도커 엔터프라이즈 고객은 오케스트레이션을 위해 도커 스웜을 사용할 수도 있다. 매지니드 서비스 옵션인 Docker Enterprise-as-a-Service는 캡제미니(CapGemini)와 협력관계를 통해 도커 엔터프라이즈를 온프레미스 또는 퍼블릭 클라우드에 서비스로 배치할 수 있다. 매니지드 서비스는 온디맨드 방식의 확장과 사용량 기반의 과금을 이용한다. 이외에 도커 엔터프라이즈 3.0의 주요 특징은 다음과 같다. - 도커 데스크톱 엔터프라이즈(Docker Desktop Enterprise)는 도커 허브 생태계 액세스와 통합된 이미지 레지스트리를 제공하는 일련의 자동화 툴이 특징이다. 기업용 쿠버네티스 환경으로의 배치도 지원한다. - 도커 애플리케이션(Docker Applications)는 어떤 인프라에도 배치할 수 있는 단일 패키지로 멀티컨테이너 애플리케이션을 정의한다. 개발자와 운영팀은 관련 컨테이너 그룹을 정의해 특정 애플리케이션 상에서 협업할 수 있다. 이 기능은 CNAB(Cloud Native Application Bundle) 표준을 기반으로 한다. 도커 컴포즈, 헬름 차트, 쿠버네티스...

컨테이너 도커 쿠버네티스 2019.05.02

“클라우드 파운드리에 쿠버네티스 통합” 이리니 프로젝트 테크 프리뷰

이제 이리니(Eirini)를 IBM의 테크 프리뷰 형식으로 이용할 수 있다. 이리는 클라우드 애플리케이션 플랫폼인 클라우드 파운드리(Cloud Foundry)에 쿠버네티스 컨테이너 관리 플랫폼을 통합하는 오픈소스 프로젝트이다.   클라우드 파운드리 재단 내의 육성 프로젝트인 이리니는 클라우드 파운드리 애플리케이션 런타임(Cloud Foundry Application Runtime)용 플러그인 방식 스케줄링을 지원한다. 이리니를 사용해 클라우드 파운드리 사용자는 애플리케이션 컨테이너 인스턴스의 오케스트레이션에 디에고(Diego)와 쿠버네티스 중 선택할 수 있다. 쿠버네티스를 선택하면 클라우드 파운드리 애플리케이션이 OCI 이미지와 쿠버네티스 디플로이먼트(Kubernetes Deployments)를 사용해 쿠버네티스 백엔드에 배치된다. 그동안 클라우드 파운드리 애플리케이션 런타임의 기본 스케줄러는 디에고였다. 이리니 프로젝트의 목표는 사용자가 어떤 스케줄러를 선택하더라도 같은 경험을 얻을 수 있도록 하는 것이다. IBM 클라우드의 IBM 이리니 프리뷰는 이 기술의 상용 구현물에 대한 초기 액세스를 제공한다. 구성요소는 다음과 같다. - OPI(Orchestrator Provider Interface). 다중 스케줄러에 대한 선언적 추상화를 제공한다. OPI는 디에고 LRP/Task 모델과 보시 CPI 개념에 영향을 받았다. - Bifrost. 애플리케이션 전용 클라우드 컨트롤러 요청을 변환해 쿠버네티스에서 구동하는 OPI 전용 객체로 전송한다. - Stager. 쿠버네티스/OPI 일회성 태스크를 구동해 스테이징을 구현한다. 이리니는 깃허브에서 다운로드할 수 있다. IBM의 클라우드 파운드리용 쿠버네티스 스케줄러는 IBM 클라우드에서 이용할 수 있다.  editor@itworld.co.kr

컨테이너 클라우드파운드리 IBM 2019.04.12

구글, 안토스로 하이브리드 전략 강화…인텔•HPE•레노버와 협력

클라우드 사업이 아직 한자릿수 점유율을 넘지 못하고 있는 구글이 하이브리드 클라우드 전략을 강화하기 위해 레노버, 인텔과 맺은 새로운 협력관계를 소개했다. 두 업체와의 협력관계는 모두 구글의 쿠버네티스 컨테이너 기술을 기반으로 한다.   이번 주 열린 구글의 넥스트 ’19 행사에서 인텔과 구글은 구글 안토스(Anthos)를 기반으로 협업하기로 했다고 밝혔다. 안토스는 퍼블릭 클라우드와 프라이빗 클라우드 환경 간의 워크로드 이식성을 높이기 위한 새로운 레퍼런스 디자인으로, 최근 발표된 인텔의 2세대 제온 스케일러블 프로세서와 최적화된 쿠버네티스 소프트웨어 스택을 기반으로 한다.  안토스 발표의 일환으로 HPE 역시 자사 프로라이언트 서버 제품군에서 안토스의 유효성을 확인했다고 밝혔다. 레노버도 자사 씽크애자일 플랫폼 상의 안토스를 인증했다. 이 솔루션은 고객이 구글 클라우드와 온프레미스 HPE 서버나 레노버 서버 간의 일관성 있는 쿠버네티스 경험을 제공한다. 델 EMC는 아직 공식적인 발표가 없지만, 조만간 뒤를 따를 것으로 보인다. 사용자는 퍼블릭 클라우드와 온프레미스 모두에 걸친 여러 환경의 쿠버네티스 클러스터를 관리하고 정책을 일관성 있게 적용할 수 있다. 또한 안토스는 구글이 검증을 마친 운영체제와 컨테이너 런타임을 포함하는 완전히 통합된 소프트웨어 스택을 제공해 사용자는 안심하고 클러스터를 업그레이드할 수 있으며, 다운타임을 최소화할 수 있다. 안토스는 기존 클라우드 서비스 플랫폼(Cloud Service Platform)으로, 사용자가 쿠버네티스 클러스터를 구축하고 관리하고 운영하는 데 시간을 들이지 않고 컨테이너화된 애플리케이션을 구동할 수 있다. 구글 클라우드 플랫폼과 구글 쿠버네티스 엔진은 물론 데이터센터의 GKE 온프렘에서도 구동할 수 있다. 안토스는 또한 AWS나 애저 같은 서드파티 클라우드에서 구동하는 워크로드도 관리할 수 있다. 구글은 안토스 마이그레이트(Anthos Migrate)의 베타 버전도 발...

인텔 컨테이너 구글 2019.04.11

구글 클라우드 런, "컨테이너의 이식성과 서버리스의 속도 결합"

구글 클라우드 런은 스테이트리스 컨테이너를 매니지드 컴퓨트 서비스나 구글 쿠버네티스 엔진에 배치할 수 있도록 해준다. 구글이 클라우드 런(Cloud Run) 서비스를 추가하며 서버리스 컴퓨트 옵션을 확장했다. 클라우드 런은 매니지드 컴퓨트 서비스의 하나로, HTTP 요청으로는 기동할 수 있는 스테이트리스 컨테이너를 구동할 수 있다. 또한 구글 쿠버네티스 엔진에서도 이용할 수 있는데, 이를 통해 컨테이너화된 HTTP 워크로드를 매니지드 쿠버네티스 클러스터에서 구동할 수 있다.   클라우드 런이 개발자에게 가져다 주는 장점은 컨테이너의 이식성과 서버리스 컴퓨팅의 속도이다. 현재 베타인 클라우드 런은 자동화된 프로비저닝 및 워크로드 확장 기능을 제공하며, 사용자는 컨테이너가 실제로 사용한 자원에 대해서만 비용을 내면 된다. GKE에서는 스테이트리스 HTTP 워크로드를 기존 쿠버네티스 클러스터에서 구동할 수 있으며, 사용자는 맞춤 머신 종류와 구글 컴퓨트 엔진 네트워크에 액세스할 수 있다. 같은 클러스터에서 서로 다른 워크로드를 나란히 구동할 수도 있다. 개발자는 어떤 개발언어라도 사용할 수 있으며, 툴과 의존성도 사용자의 선택에 달렸다. 클라우드 런은 케이네이티브(Knative)를 기반으로 하는데, 케이네이티브는 사용자가 서버리스 워크로드를 쿠버네티스 플랫폼에 걸쳐 옮길 수 있ㄴ느 오픈 API 및 소프트웨어 계층이다. 구글 클라우드 플랫폼과 GKE는 물론 쿠버네티스를 구동하는 어떤 플랫폼이라도 상관없다. 클라우드 런의 핵심 기능은 다음과 같다. - 서비스 배치 및 관리를 위한 명령어줄 및 사용자 인터페이스 - 배수 기반의 트래픽 자동 확장. GKE 상에서 구동할 때는 자동 확장이 클러스터 내로 제한된다. - 개발 언어와 운영체제 라이브러리를 선택할 수 있고 자체 라이브러리도 사용할 수 있다. - 컨테이너 워크플로우와 표준을 이용할 수 있다. 클라우드 런은 클라우드 빌드, 컨테이너 레지스트리, 도커 등과 짝을 지을 수 있다. - 리던던시 제공. 서...

컨테이너 구글 서버리스 2019.04.10

“클라우드도 진화한다” 컨테이너 기반 플랫폼으로 혁신해야 하는 이유 - IDG Summary

클라우드 아키텍처는 계속 변화하고 있다. 클라우드로의 마이그레이션을 완료한 기업도 예외는 아니다. 기업 역시 더욱 빠르게 서비스를 배포하고 전문 기술자 없이도 방대한 데이터를 손쉽게 관리해야 한다는 요구에 직면한 상태다. 컨테이너와 쿠버네티스가 클라우드 가상화 환경 전반의 표준으로 자리잡은 지금, 클라우드를 통해 한 번 더 혁신하고 싶은 기업을 위한 컨테이너 기반 클라우드 전략을 제시한다. 또한, 복잡한 관리와 운영 부담에서 벗어나고 싶은 현업의 고민을 해결할 수 있는 플랫폼 선택 기준도 알아본다. 주요 내용 - 클라우드를 둘러싼 비즈니스 환경 변화 - 컨테이너와 쿠버네티스에서 답을 찾아야 하는 이유 - 기업 환경 변화, 멀티클라우드로 대응하라 - 쿠버네티스 기반 PaaS 플랫폼 선택 기준 - “애드온까지 원스톱 서비스” 제공하는 SK 클라우드Z

paas 클라우드 쿠버네티스 2019.04.05

새 쿠버네티스 프로젝트 '텍톤'··· CI/CD용 '네이티브' 빌딩 블록

쿠버네티스 같은 클라우드 네이티브 기술은 클라우드 록인을 방지하는 역할을 한다. 이 쿠버네티스를 활용한 새로운 오픈소스 프로젝트 텍톤(Tekton)이 주목받고 있다. 텍톤은 CI/CD 시스템을 빠르게 만들 수 있는 쿠버네티스 네이티브 프레임워크다. 쿠버네티스가 실행되는 어떤 시스템에서든 사용할 수 있다. 젠킨스(Jenkins) 같은 기존 CI/CD 서버와 함께 쓸 수 있는 것도 장점이다. 이 프로젝트는 구글이 이끌고 다른 기업의 공헌으로 유지되고 있다. 클라우드 네이티브 CI/CD 파이프라인용 빌딩 블록 세트 공유할 수 있다. 개발자는 소프트웨어를 개발한 후 텍톤을 이용해 여러 클라우드는 물론 온프레미스 시스템에 배포할 수 있다. 이밖에 텍톤의 주요 기능은 다음과 같다. - 쿠버네티스 컨테이너 오케스트레이션 플랫폼에서 실행 가능하며 빌딩 블록으로 컨테이너를 활용할 수 있다. 텍톤 파이프라인을 이용하면 개발자가 컨테이너를 결합해 복잡한 파이프라인을 만들 수 있다. 쿠버네티스 클러스터는 텍톤 파이프라인과 함께 작동하는 퍼스트클래스 타입이다. - 저장, 관리 보안 툴 지원 - 테스트와 빌드 결과에 통찰력을 제공하는 결과 저장 API 지원 텍톤을 이용하면 개발자가 변경할 수 없는 이미지를 배포하고 인프라의 버전 제어를 관리하고 롤백할 수 있다. 언어와 배포 환경을 가리지 않고 표준 CI/CD 툴로 제공되며, 쿠버네티스와 파이프 자동화를 지원하는 CI/CD용 클라우드를 활용하는 다양한 CI/CD 툴, 예를 들면 젠킨스, 스카폴드(Skaffold), 케이네이티브(Knative), 젠킨스 X 등과 함께 사용할 수 있다. 또한, 텍톤은 구글 클라우드 플랫폼에서 특정 쿠버네티스 툴과 함께 잘 작동하도록 설계됐다. 구글 쿠버네티스 엔진에 적용할 수 있고, 구글 컨테이너 레지스트리를 이용해 스캔할수 있다. VM와 서버리스 플랫폼, 파이어베이스 등 다양한 환경에 배포할 수 있는 것도 특징이다. 최근 텍톤은 새로 결성한 CDF(Continuous Delivery...

쿠버네티스 CI/CD Tekton 2019.03.22

IDG 블로그 | 잘 알려지지 않은 컨테이너의 장점과 단점

성능부터 확장성, 이식성을 추구하는 기업의 전투 구호는 “우리는 컨테이너를 사용한다”이다. 물론 일부는 실제로 그렇게 되기도 하지만, 한계도 있다. 컨테이너가 실제로 기업에 가져다주는 가치와 그렇지 않은 것을 살펴보자.   컨테이너의 장점 여러 기술적 이점을 넘어서 컨테이너는 많은 기업이 잘 알지 못하는 이점을 제공한다. 컨테이너는 추상화를 통해 복잡성을 줄여준다. 컨테이너는 사용하는 주된 이유는 컨테이너는 애플리케이션의 클라우드 네티이브화 작업을 요구하지 않는다는 것이다. 컨테이너 자체는 플랫폼일 뿐이다. 이는 컨테이너가 복잡한 네이티브 인터페이스를 관리하지 않아도 되고, 그래서 특정 클라우드 플랫폼에 종속되지 않아서 다른 환경으로 이식할 수 있다는 것을 의미한다. 컨테이너는 자동화에 좋다. 자동화는 수작업 스크립트를 대체하며, 더 나은 이식성을 제공한다. 컨테이너는 더 나은 보안과 거버넌스를 제공한다. 보안과 거버넌스는 플랫폼에 특화된 것으로 밝혀졌고, 컨테이너 밖에서도 최고 수준을 유지한다. 전체적인 복잡성을 줄이면서도 보안과 거버넌스를 중앙집중화할 수 있다는 의미이다. 컨테이너는 분산 컴퓨팅에도 뛰어나다. 컨테이너를 사용하면, 애플리케이션을 컨테이너 및 컨테이너 클러스터, 도메인으로 나눌 수 있다. 인트라클라우드(Intracloud)와 인터클라우드(Intercloud)를 포함해 애플리케이션을 구동할 플랫폼을 선택할 수 있는데, 이는 비용과 성능을 최적화할 수 있다는 의미이다.  컨테이너는 정책 기반 최적화를 지원한다. 자동화 계층을 사용하면, 최적의 플랫폼을 골라 실행하는 것은 물론 자동으로 해당 플랫폼으로 이전할 수도 있다. 또한 환경 설정 변경도 자동으로 처리할 수 있다. 컨테이너 오케스트레이션은 생각보다 유용하다. 쿠버네티스는 컨테이너를 클러스터로 확장하고 관리할 수 있도록 해준다. 또한 생태계가 되어 툴과 기술을 제공해 컨테이너 개발과 배치도 더 쉬워진다.   컨테이너의 단점 그렇지...

클러스터 복잡성 컨테이너 2019.02.26

IDG 설문조사

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.