Google은 Kubernetes 응용 프로그램을 지속적으로 개발할 수있는 오픈 소스 명령 줄 도구 인 Skaffold 를 출시 했습니다 .
Skaffold는 Azure의 Draft, Datawire의 Forge 및 Weavework 's Flux를 비롯하여 점점 더 혼잡해진 Kubernetes 개발 자동화 도구 공간에 들어서고 있습니다.
Skaffold는 Kubernetes 클러스터에 응용 프로그램을 작성, 배포 및 배포하기위한 워크 플로를 자동화합니다.
Skaffold를 사용하면 개발자는 로컬 또는 원격 Kubernetes 클러스터에서 지속적으로 업데이트되고 검증 또는 테스트 준비가되면서 응용 프로그램 소스 코드를 로컬에서 반복 할 수 있습니다. 개발자는 Skaffold를 코드를 개발하는 동안 백그라운드 프로세스로 실행할 수 있으며 CI / CD 파이프 라인과 같은 일회성 또는 자동 컨텍스트에서도 사용할 수 있습니다. 따라서 개발자는 로컬 개발에서 프로덕션 환경으로 응용 프로그램을 이동할 때 동일한 워크 플로와 도구를 활용할 수 있습니다.
Google Cloud Platform 블로그에는 Kubernetes가 운영자 / 시스템 관리자 에게 민첩성을 높이고 소프트웨어 응용 프로그램의 안정적인 배포를 용이하게하는 API 및 방법 을 제공한다고 명시되어 있습니다. Kubernetes는 맞춤형 배포 방법론을 채택하고 "더 강력하지 않은 절차를 구현하기위한 프로그래밍 방식을 제공합니다". 따라서 운영자는 조직의 가장 중요한 인프라 관리 부분에 집중할 수 있습니다. 즉, 릴리스 속도와 서비스 안정성을 유지하는 것입니다.
Automatic binpacking 가용성을 희생하지 않는 범위안에서 물리적 리소스를 충분히 활용해서 Pod을 (자동) 배치한다. 여기서 binpacking이란 컨테이너가 호스트의 물리적 리소스를 충분히 활용할 수 있도록 효율적으로 고르게 배치해서 불필요한 물리적 리소스의 낭비를 줄이는 것을 의미한다.
Self-healing Container의 실행 실패, Node(K8s에서 Pod을 실행하는 슬레이브 호스트)가 죽거나 반응이 없는 경우, health check에 실패한 경우에 해당 Container를 자동으로 복구한다. Kubernetes가 관리하는 가장 작은 배포단위인 Pod은 언젠가는 반드시 죽는(mortal) 것으로 정의되어 있으며 Contianer, Node의 장애 상황발생 시에도 운영자가 기대하는 상태로 서비스가 무사히 실행될 수 있도록 Self-healing을 지원한다.
Horizontal scaling Pod의 CPU 사용량 혹은 app이 제공하는 metric을 기반으로 ReplicaSet (동일한 Pod을 몇 개 띄울지 정의) 을 scailing할 수 있다.
Service discovery and load balancing 익숙하지 않는 Service Discovery 매커니즘을 위해 Application을 수정할 필요가 없다. K8s는 내부적으로 Pod에 고유 IP, 단일 DNS를 제공하고 이를 이용해 load balancing 한다.
Automated rollouts and rollbacks application, configuration의 변경이 있을 경우 전체 인스턴스의 중단이 아닌 점진적으로 Container에 적용(rolling update) 가능하다. Release revision이 관리되고 새로운 버전의 배포시점에 문제가 발생할 경우 자동으로 이전의 상태로 Rollback을 진행할 수 있다.
Secret and configuration management Secret key, Configuation을 관리하기 위해 Secret, ConfigMaps Object가 제공되기 때문에 이미지의 변경없이 키/설정을 업데이트할 수 있고, 이를 외부에 노출(expose)하지 않고 관리/사용할 수 있다. Secret은 데이터를 binary 형태로, ConfigMap은 text 형태로 저장한다.
Storage orchestration local storage를 비롯해서 Public Cloud(GCP, AWS), Network storage등을 구미에 맞게 자동 mount할 수 있다.
시스코는 최근 구글과 협력해 구글의 오픈소스 플랫폼인 '쿠버네티스'를 이용해 구현한 컨테이너 솔루션인 '시스코 컨테이너 플랫폼(CCP)'을 출시했다.
쿠버네티스는 구글이 리눅스 기반의 '도커 컨테이너'를 사내에서 자동 관리하기 위해 개발한 오픈소스 소프트웨어다. 도커는 컨테이너 플랫폼 중 대표적인 오픈소스 솔루션으로, 애플리케이션 가상화와 배포에 활용된다. CCP를 이용하면 사용자가 클라우드 환경에서 애플리케이션을 효율적으로 개발하고 관리할 수 있다
그동안 가상화 솔루션 시장은 VM웨어, 시트릭스, 마이크로소프트(MS) 등 하이퍼바이저 기반 솔루션을 공급하는 기업들이 주도해 왔다. 하이퍼바이저 기반 VM(가상머신)은 하나의 시스템에서 운영체제(OS)를 논리적으로 분리해 사용하는 것으로, 컴퓨팅 자원 소모가 클 수밖에 없다.
반면 컨테이너 기반 가상화는 단일 운영체제를 공유하면서 애플리케이션 구동 환경만 가상화해 쪼개 쓸 수 있게 하는 방식이다. 기존 VM 방식에 비해 최소한의 컴퓨팅 자원만으로 SW를 빠르고 쉽게 설치할 수 있어 더 많은 마이크로서비스를 개발·운영할 수 있는 강점이 있다. 단 여러 개의 컨테이너를 일일이 세팅하고 적용·관리해야 하는 복잡성이 단점이었으나, 최근 쿠버네티스 같은 자동화 도구가 선보이면서 이런 문제점까지 해결된 상황이다.
하나의 k8s 클러스터는 하나의 master 와 여러개의 node 로 구성되어 있습니다. 개발자는 kubectl 을 이용해서 master 에 명령을 내리고, node 를 관리하는 반면 사용자 (endpoint user) 는 node 에 접속해 서비스를 이용합니다. 위 그림을 조금 더 자세히 보겠습니다.
master 에는 (현재는 master 가 단일 노드이지만 추후 multi-node master 가 지원될 예정)
host 머신 한대라면 docker run 이나 docker-compose 등 무엇으로 container 를 실행해도 상관 없습니다. 그러나 사용자가 많아지면 하나의 host 에서 모든 container 를 실행할 수 없습니다. (host 에서 fail 이라도 발생하면..) 그러나 여러대의 host 에서 container 를 실행하려면 inter-host container 네트워킹과, host machine 의 리소스를 고려한 container 분배 등을 고려해야 합니다. 이런 문제들을 해결해주는 것이 바로 container orchestration 툴입니다. 요즘은 여러 container orchestration 툴을 골라 쓸 수 있게 해주는 rancher 와 같은 플랫폼도 나오고 있습니다.
캐노니컬의 베이커는 또한 기업들이 서버 프로비저닝에 대한 걱정 없이 애플리케이션을 구축하고 실행할 수 있는 서버리스 컴퓨팅의 인기가 2018년에도 지속될 것으로 전망했다.
그러나 그는 서버리스에 관심 있는 기업 고객에 대한 경고도 잊지 않았다.
“문제는 AWS 람다와 같은 외부 제품을 사용하면 기능을 빨리 개발할 수 있는 장점이 있지만 누구나 다 사용 준비가 된 것은 아니다. 무서버를 사용하려면 전혀 다른 사고 방식이 필요하다. 인프라 전체, 사실상 응용프로그램 자체를 제외한 모든 것을 외주 처리하는 것이나 마찬가지이기 때문이다”라고 그는 말했다.
쿠버네티스를 중심으로 한 통합
대담한 전망은 아닐지 모르지만 쿠버네티스(Kubernetes)는 기업 내 컨테이너 관리(orchestration) 경쟁에서 승리한 것으로 보인다. AWS가 마침내 이 오픈소스 기술을 지원하기로 11월 리인벤트(re:Invent) 회의에서 발표했기 때문이다. 이제 주요 퍼블릭 클라우드 업체는 모두 쿠버네티스를 완전히 지원한다.
지속적인 전달 및 컨테이너 기술에 의지하는 대기업이 늘어남에 따라 컨테이너 관리 플랫폼은 기업 클라우드 전략 내 주요 핵심으로 자리잡을 전망이다. 이에 따라 포레스터는 2018년에는 쿠버네티스 기술 인력과 시범 운영 투자할 것을 권장하면서 다음과 같이 적었다.
“먼저 컨테이너 관리 계획을 세워라. 무엇을 배워야 하고 누구를 교육시켜야 하며 개발 및 인프라 팀이 어떤 결과를 얻기 바라는지 파악하라.”
오픈 소스 오케스트레이션 프레임워크 쿠버네티스(Kubernetes)의 최신 버전인 쿠버네티스 1.9가 공개됐다. 주요 신기능은 다음과 같다.
- 워크로드 API의 일반 가용성
- 윈도우 서버용 베타 지원
- 신형 컨테이너 스토리지 API의 알파 버전
쿠버네티스 1.8의 신규 보안 기능
쿠버네티스는 이전 버전을 통해 역할 기반 접근 통제(RBAC, Role-Based Access Control)를 베타 기능으로 선보여왔다. RBAC를 통해 관리자는 팟(pod), 시크릿(secret) 등의 쿠버네티스 자원에 대한 접근 허용권을 정의할 수 있으며, 더불어 그 권한을 개별 혹은 복수 사용자에게 부여할 수 있다.
그간 쿠버네티스의 네트워킹 정책 시스템이 팟에 대한 진입 트래픽만을 필터링할 수 있던 데에서 나아가 쿠버네티스 1.8에서는 유출 트래픽에 대한 필터링의 베타 지원이 추가됐다. 단, 양방향 필터링 지원 대상은 일련의 종착 포트와 피어로 제한되고 있다. 비율 제한(rate limiting)과 같은 대상을 쿠버네티스의 인터페이스에서 이용하려면 앞으로도 시간이 더 필요할 것으로 보인다(물론, 커스텀 네트워킹 브릿지를 이용하는 컨테이너에서는 이 해당 작업을 바로 수행할 수 있다).
쿠버네티스 1.8 감사 기능
쿠버네티스 1.7의 알파 기능으로 처음 도입된 감사(audit) 기능은 1.8에서 베타(beta status)로 한 단계 업그레이드 됐다. 감사 로그에 대한 포맷팅은 물론 클러스터의 어떤 요소를 누가 로깅할 수 있는가에 대한 정책, 그리고 외부 서비스로 이벤트를 릴레이하는 웹훅 등이 추가됐다.
쿠버네티스 1.8의 워크로드 기능
일련의 워크로드 API 역시 쿠버네티스 1.8에서 베타로 승격된 또 다른 기능이다. 워크로드 API는 애플리케이션의 전반적 행동에 기반해 이들을 오케스트레이션하는 방법을 찾아낸다. 예를 들어 일괄 작업이나 크론 스타일 작업과 계속해서 진행되는 데몬(daemon) 작업 간 오케스트레이션을 가능케 하는 것이다.
쿠버네티스 1.8의 기타 알파/베타 기능
이외에도 쿠버네티스 1.8에는 다음과 같은 알파, 베타 기능이 추가됐다.
- (베타) 크라이-컨테이너드(cri-containerd)는 사용자가 도커 데몬을 대신해 컨테이너드를 사용할 수 있도록 지원해 도커에 대한 직접 의존도를 낮춰준다.
- (알파) 볼륨 스냅샷은 쿠버네티스 API 콜을 사용해 쿠버네티스 볼륨의 스냅샷을 저장하는 기능이다. 다만 이 기능은 스냅샷 촬영 시점의 일관성을 보장하기 어려워 아직 정확한 생산 배포 일정이 확정되지 않았다.
- (알파) 볼륨 리사이징 기능은 쿠버네티스 API 콜을 이용해 볼륨 사이즈를 조정할 수 있다. 단, 볼륨 사이즈를 조정한다고 해서 볼륨상의 파일 시스템이 변하는 것은 아니며, 오직 기저의 볼륨 사이즈만 변한다는 것을 잊지 말자. 파일 시스템은 무엇이든 될 수 있기 때문이다.
바이두는 기계 번역, 검색 결과 순위 계산 등의 작업을 위한 모델을 클러스터를 통해 교육시키기 위해 패들(PArallel Distributed Deep LEarning, PADDLE, 즉 병렬 분산 딥 러닝)을 만들었다. 그리고 쿠버네티스 기여 업체인 코어OS(CoreOS)의 도움을 받아 이러한 클러스터를 관리하기 위해 쿠버네티스를 도입했다.
쿠버네티스는 수요에 따른 확장 또는 리소스 기반의 할당이 가능하므로 리소스 요구에 따라 작업을 클러스터로 묶거나 분산시켜 패들패들의 효율성을 높여준다. 바이두는 이번 변화에 대한 블로그 글에서 "GPU가 필요한 패들패들 작업과 큰 메모리 또는 디스크 I/O 처리량 등 다른 리소스가 필요한 작업을 동일한 물리적 컴퓨터 집합에서 조합할 수 있다"고 전했다.
바이두의 패들패들 기술 책임자인 위 왕은 쿠버네티스가 내고장성(fault tolerance)도 제공한다고 강조했다. 왕은 "스케일링 가운데 일부 작업의 컨테이너/프로세스에 장애가 발생하더라도 이런 작업이 보류되거나 멈추지 않도록 하고자 했다. 우리가 원하는 것은 속도가 느려지더라도 계속 실행되는 것"이라고 말했다.
