최신 버전의 컨테이너 오케스트레이션 시스템 쿠버네티스(Kubernetes) 1.11에는 새로운 로드밸런싱 방법이 추가됐고 커스텀 리소스 정의를 제공한다.
쿠버네티스 다운로드 위치
깃허브(GitHub) 저장소의 릴리즈 페이지에서 쿠버네티스 소스를 다운로드할 수 있다. 또한 쿠버네티스 배포판을 공급하는 다양한 업체가 제공하는 업그레이드 프로세스를 통해서도 얻을 수 있다.
현 버전: 쿠버네티스 1.11의 새 기능
2018년 7월 초에 공개된 쿠버네티스 1.11에는 IPVS(IP Virtual Server)가 추가되어 일반적으로 iptables 시스템이 사용하던 것보다 덜 복잡한 인커널(In-kernel) 기술을 이용한 고성능 클러스터 로드밸런싱을 제공한다. 결국 쿠버네티스는 IPVS를 기본 로드밸런서(Load Balancer)로 사용하겠지만 지금은 옵션이다.
표준화를 준수하면서 쿠버네티스에 사용자 정의 구성 변경사항을 적용하는 방법이라고 설명하는 커스텀 리소스 정의는 이제 시간이 지나면서 커스텀 리소스 세트를 다른 세트로 원활하게 전환할 수 있게 변형할 수 있다. 또한 ‘상태’와 ‘범위’를 정의하는 새로운 방법인 서브리소스(Subresources)는 한 클러스터 안에서 모니터링 및 고가용성 프레임워크와 통합할 수 있다.
기타 변경사항:
• 1.10부터 도입된 CoreDNS는 이제 클러스터 DNS 부가기능으로 사용할 수 있으며 kubeadm 관리 툴에서 기본으로 사용된다.
• 쿠빌렛(Kubelet) 구성 변경사항은 이제 클러스터를 다운시키지 않고도 실시간 클러스터에서 롤 아웃(Roll Out)할 수 있다.
• CSI(Container Storage Interface)는 현재 미가공 블록 볼륨(Volume)을 지원하며 쿠빌렛 플러그인 등록 시스템과 통합되며 secret을 CSI 플러그인으로 좀 더 손쉽게 전달할 수 있다.
• 상시 볼륨의 온라인 크기 조정, 노드의 최대 볼륨 카운트 지정 기능, 사용 중인 저장소 객체가 제거되지 않도록 보호하는 지원 강화 등 저장소에 많은 변경사항이 적용되었다.
이전 버전: 쿠버네티스 1.10의 새로운 점
2018년 3월, 쿠버네티스 1.10 프로덕션 릴리즈에는 예전에는 쿠버네티스 바이너리(Binary)를 재 컴파일링 해야 했지만 이제는 쿠버네티스에 볼륨 플러그인을 더욱 쉽게 추가할 수 있는 CSI (쿠버네티스 1.9 당시 알파(Alpha))가 포함되어 있다. 쿠버네티스에서 공통 유지보수 및 관리 작업을 수행하기 위해 사용하던 Kubectl CLI는 이제 클라우드 제공자와 액티브 디렉토리 등의 제 3자 서비스에 대한 인증을 수행하는 바이너리 플러그인을 수용할 수 있다.
‘비공유 저장소’ 또는 로컬 저장소 볼륨을 상시 쿠버네티스 볼륨으로 마운트 할 수 있는 기능도 이제 베타다. 상시 볼륨을 위한 API는 이제 사용 중인 상시 볼륨이 삭제되지 않게 하려고 추가 확인을 수행한다. 쿠버네티스의 네이티브DNS 제공자는 이제 모듈식 아키텍처를 가진 CNCF 관리형 DNS 프로젝트인 CoreDNS와 스왑(Swap)할 수 있다. 단, 스왑은 쿠버네티스 클러스터가 첫 번째 구성인 경우에만 가능하다.
또한 쿠버네티스 프로젝트는 이제 오래된 문제들이 너무 오랫동안 방치되지 않게 하려고 자동화된 문제 라이프 사이클 관리 프로젝트로 이동한다.
이전 버전: 쿠버네티스 1.9의 새로운 점
쿠버네티스 1.9는 2017년 12월에 공개되었다.
워크로드API의 프로덕션 버전
쿠버네티스 1.8에서 베타로 승격되었으며 현재 쿠버네티스 1.9에서 프로덕션 릴리즈 상태인 앱스 워크로드API는 행동에 기초하여 상시 상태가 필요한 장기 운영 앱 등의 작업 부하를 정의하는 수단을 제공한다.
앱스 워크로드API의 버전 1은 4개의 API를 공개했다.
• Deployment. ReplicaSet.을 포함하여 작동 중인 애플리케이션에 대해 원하는 상태를 설명하는 기본적인 수단이다.
• ReplicaSet. Deployment의 구성을 통해 앱에 정의를 충족하기에 충분한 작동 컨테이너 인스턴스(‘replicas’)가 있는지 확인한다.
• Daemonset. 로깅 또는 모니터링 솔루션처럼 다른 앱이 실행하고 있을 수 있는 대상에 상관없이 연속적으로 작동하는 앱을 위한 배치이다.
• StatefulSet. 컨테이너를 죽이고 재시작하더라도 상시 상태가 필요한 작업 부하에 사용된다. StatefulSet는 또한 컨테이너를 위한 네트워크 식별 또는 컨테이너가 시작하고 정지하는 순서 등을 위한 지속성을 제공한다.
또 다른 워크로드API, Job, CronJob(배치 워크로드(Batch Workloads) API) 세트는 예열 기반으로 작동한 후 종료되는 작업 부하에 사용된다. 배치 워크로드API는 아직 베타 상태다.
윈도우 서버 베타 지원
마이크로소프트가 윈도우에 도커(Docker) 컨테이너 지원을 추가한 후 쿠버네티스처럼 도커를 사용하던 다른 앱들은 이를 따르는 것이 당연했다. 쿠버네티스 1.9는 현재 임시로 윈도우 서버에서 쿠버네티스 사용을 지원한다.
윈도우 서버에서 쿠버네티스를 시험하려면 윈도우 서버 2016과 도커 1.12가 필요하다. 현재 쿠버네티스 제어 영역은 리눅스에서만 작동할 수 있다. 즉, 리눅스 컨트롤러에서 컨테이너가 윈도우 서버에서 작동하도록 예약할 수 있지만 리눅스 대신에 윈도우 서버를 컨트롤러로 사용할 수는 없다.
CSI의 첫 알파
쿠버네티스가 등장한 이래로 애플리케이션으로부터의 (저장소를 포함한) 자원 추상화가 핵심 기능이었다. 안타깝게도 컨테이너 저장소는 제대로 된 표준이 없었다. 쿠버네티스를 포함한 거의 모든 컨테이너 솔루션은 자체적인 방식으로 저장소를 처리했다.
CNCF(Cloud Native Computing Foundation)의 하위 그룹인 CNCF SWG(Storage Working Group)가 컨테이너 클러스터에서 저장소를 위한 자체 표준인 CSI 표준을 고안했다. 쿠버네티스 1.9에는 CSI 플러그인의 알파 버전이 있기 때문에 저장소 볼륨 플러그인을 쿠버네티스 자체와 완전히 독립적으로 개발할 수 있다. 이 프로젝트는 여전히 초기 단계이지만 쿠버네티스의 개발자들은 적절한 방향으로 나아가고 있다는 자신감을 보인다.
쿠버네티스 1.9의 기타 새 기능
기타 추가 및 수정사항은 다음과 같다.
• 쿠버네티스에 알파 버전의 하드웨어 가속이 추가되어 GPU를 하나의 자원으로 사용할 수 있다. 이를 통해 쿠버네티스는 머신러닝(ML) 작업 부하를 위한 기초로써 더욱 잘 기능할 수 있다.
• IPv6 주소 지정 알파 지원.
• 더욱 신속한 CRD(Custom Resource Definition) 데이터 검증. CRD를 통해 관리자는 새 버전의 쿠버네티스가 공개되더라도 호환성을 저해하지 않으면서 주어진 쿠버네티스 설치를 사용자 정의 및 확장할 수 있다.
이전 버전: 쿠버네티스 1.8의 새로운 점
쿠버네티스 1.8은 2017년 10월에 공개되었다.
쿠버네티스 1.8의 새 보안 기능
이전 버전의 쿠버네티스에서 RBAC(Role-Based Access Control)를 베타 기능으로 도입했다. RBAC를 통해 관리자는 pod 나 secret 등의 쿠버네티스 자원에 대한 액세스 권한을 정의한 후 이것들을 1명 이상의 사용자에게 부여(바인딩(Binding))할 수 있다. 권한은 변경(‘create’, ‘update’, ‘patch’)이나 이에 대한 정보 획득(‘get’, ‘list’, ‘watch’)에 대한 것일 수 있다. 역할은 2개의 API를 통해 단일 명칭 공간에서 또는 클러스터 전체에 적용할 수 있다.
쿠버네티스는 이미 pod로의 유입 트래픽 필터링을 포함하여 네트워킹을 위한 정책 시스템이 있었다. 쿠버네티스 1.8은 유출 트래픽에 대한 베타 지원도 추가한다. 현재 양방향 필터링은 대상 포트 및 피어(Peer) 목록으로 제한되기 때문에 속도 제한 등은 아직 쿠버네티스의 인터페이스를 통해 제공되지 않는다. (이런 것들은 사용자 정의 네트워크 브리지를 사용해 컨테이너에서 직접 달성할 수 있다.)
베타로 승격된 또 다른 네트워킹 기능은 각 쿠버네티스 노드에서 구동하는 에이전트 소프트웨어인 쿠빌렛을 위한 자동 TLS 인증서 회전이다. 쿠버네티스가 내부적으로 사용하는 TLS 인증서는 수명이 1년이며 인증서 재생성을 잊기 십상이다. 새 기능이 활성화되면 쿠빌렛의 현재 인증서가 거의 만료되었을 때 새 인증서가 자동으로 생성된다.
쿠버네티스 1.8의 감사 기능
쿠버네티스 1.7에서 알파 기능으로 도입된 감사 기능은 쿠버네티스 1.8에서 베타 상태로 승격되었다. 여기에는 감사 로그 형식 지정, 기록할 수 있는 클러스터의 엘리먼트(Element)와 그 기록 주체를 제어하는 정책, 이벤트를 외부 서비스에 연계시키는 웹후크(Webhook)가 포함된다.
감사 기능이 베타로 승격되었기 때문에 감사 이벤트 형식은 하위 호환 변경사항만 가능하다. 즉, 쿠버네티스 개발자는 이 기능을 통해 프로덕션 기능 구축을 시작할 수 있다는 뜻이다. 감사 프레임워크를 위한 이런 하위 호환성의 예는 감사 이벤트로부터 RBAC 프로필을 생성할 수 있는 audit2rbac 툴이다.
쿠버네티스 1.8의 작업 부하 기능
쿠버네티스 1.8에서는 작업 부하 API도 알파에서 베타로 승격되었다. 이를 통해 배치(Batch) 작업 또는 실행되고 종료되는 크론(Cron) 스타일 작업 대비 지속해서 실행되는 대몬(Daemon) 등 전반적인 동작에 기초하여 애플리케이션을 조정할 수 있다.
일부 작업 부하 API는 다른 것들보다 먼저 베타 상태에서 승격된다. 대표적인 예로 Deployment, DaemonSet, ReplicaSet, StatefulSet는 쿠버네티스 1.9부터 완전 프로덕션 상태이다. 배치 API(Job 및 CronJob)도 나중에 그렇게 되겠지만 쿠버네티스 1.8은 개발자들에게 의도된 작동 방식에 대한 아이디어를 제공한다.
일부 애플리케이션은 이미 작업 부하 API를 사용하고 있지만 아직 임시적인 수준이다. 예를 들어, 아파치 스파크는 쿠버네티스에서 직접 동작하는 포크(Fork)가 있지만 이런 기능은 스파크나 쿠버네티스에서 한동안 공식적으로 제공되지 않을 것이다.
쿠버네티스 1.8의 기타 새 알파 및 베타 기능
이 외에도 아직 완성되지 않은 기능이 쿠버네티스 1.8에 알파 또는 베타 추가로 포함되어 있다.
• cri-containerd(베타)를 통해 도커 대몬 대신에 컨테이너드(Containerd)를 사용할 수 있어 도커에 대한 직접 의존성을 줄일 수 있다.
• 볼륨 스냅샷(Snapshot)(알파)을 통해 쿠버네티스 API 호출을 이용해 쿠버네티스 볼륨의 스냅샷을 찍을 수 있다. 분명 당장 프로덕션에 적용할 수는 없다. 왜냐하면 스냅샷을 찍었을 때 일관성이 있는지도 확인하지 않기 때문이다.
• 볼륨 크기 조정(알파)으로 쿠버네티스 API 호출을 이용해 볼륨의 크기를 조정할 수 있다. 볼륨 크기 조정으로 기본 볼륨 크기만 변경될 뿐 해당 볼륨의 파일 시스템은 아무런 영향을 받지 않는다. 왜냐하면 파일 시스템은 고정되어 있지 않기 때문이다.dl-ciokorea@foundryco.com
