2017.07.07

쿠버네티스 1.7의 새로운 기능 : 로컬 스토리지, 암호화 등

Serdar Yegulalp | InfoWorld
인기 컨테이너 오케스트레이션 및 관리 시스템 쿠버네티스(Kubernetes) 1.7은 보안, 스테이트풀(stateful) 애플리케이션, 확장성 기능 등 다양한 신기능을 갖추었다.

쿠버네티스 1.6은 주로 안정화에 관한 것이었고, ETCD 분산 키 값 저장소 3 사용 등과 같이 오랫동안 계획된 변화를 실행했다. 그러나 쿠버네티스 1.7의 새 기능은 아직 알파 단계인 것이 많다. 쿠버네티스가 보다 광범위한 시나리오에서 더욱 쓸모 있기 위해 노력 중임을 알 수 있다. 다른 새 기능은 종전에 컨테이너 생태계의 다른 부분에 이관되었던 기능을 가져온 것이다.

쿠버네티스 1.7 스토리지와 상태 : 로컬과 업데이트 유지
쿠버네티스 1.7은 지속적인 상태 관리와 관련된 몇 가지 기능이 업데이트되었다. 지속 상태 관리 방법 중 가장 흔한 것은 컨테이너 실행 그룹, 즉 쿠버네티스 용어로 팟(pod)을 여러 종류의 스토리지 볼륨에 연결하는 것이다. NFS 공유폴더나 iSCSI 타깃은 물론, AWS나 애저와 같은 클라우드 서비스의 스토리지도 포함된다.

쿠버네티스 1.7에는 로컬 스토리지 매핑 기능도 추가됐다. 쿠버네티스의 네이티브 API가 실행되는 시스템 상의 데이터에 팟 워크로드가 접근할 수 있는 편리한 방법이다.

그러나 로컬 스토리지 사용은 아직 많은 쿠버네티스 시나리오에서 현명한 선택이 아닌 것 같다. 로컬 스토리지가 가장 유용한 것은 임시 방편 애플리케이션이나 미니큐브(Minikube)와 함께 나온 것과 같은 단일 시스템 개발 노드일 것으로 보인다. 또한 현재로서는 쿠버네티스 1.7 로컬 스토리지의 많은 부분이 원시적이거나 신뢰할 수 없는 상태다. 예를 들면, 로컬 블록 디바이스를 볼륨 소스로 사용하는 것이 아직 허용되지 않는다.

그러나 장기적으로는 로컬 스토리지를 쿠버네티스의 다른 스토리지 솔루션 중 가장 우선적인 것으로 만들 계획이다.

쿠버네티스의 상태 처리에 또 한 가지 달라진 점은 지속 상태가 있는 애플리케이션 관리에 대한 것이다. 애플리케이션 팟 전체에 걸친 상태 처리에 사용되었던 스테이트풀세트(StatefulSets)에는 이제 업데이트 기능이 있다. 따라서 쿠버네티스의 자체 ETCD와 같은 스테이트풀 애플리케이션을 자동으로 업데이트할 수 있으며, 업데이트 절차가 상태에 영향을 주지 않는다.

쿠버네티스 1.7 보안 : 비밀 유지
애플리케이션은 “비밀”을 보관해야 할 때가 많다. 여기서 비밀이란 평문으로 전송되거나 저장되어서는 안 되는 데이터를 말한다. API 키 또는 서비스 암호는 흔히 비밀로 사용된다. 쿠버네티스 1.7은 이제 정지 상태에서 암호화된 정보를 네임스페이스에 저장할 수 있다. 새로운 노드 인가자가 추가되면서 어떤 팟이 어떤 기밀 정보를 다루는지도 통제할 수 있다.

유망한 기능이지만 현재로서는 완성도가 알파 단계에 머물러 있다. 현재 상태에서 기밀 정보를 맡긴다면 1.7 이후 버전의 쿠버네티스로 업그레이드하기 전까지는 아마도 복호화 후 재암호화 과정이 필요할 것이다.

도커 데이터센터(Docker Datacenter)와 같은 다른 제품들은 컨테이너에서 사용되는 기밀 정보를 저장할 수 있다. 쿠버네티스 1.7의 기밀 시스템을 대신 사용해도 되지만, 결국에는 대체 기술이 아닌 보완 기술이 될 가능성이 높다.

기밀 정보 저장을 위해 해시코프 볼트(Hashicorp Vault)와 사이버아크(Cyberark) 같은 다른 스토리지 제품과 쿠버네티스를 통합하거나 이를 강화하려는 노력이 진행 중이다.

쿠버네티스 1.7에서 종전의 일부 베타 보안 기능은 현재 안정적이다. 예를 들면 네트워크 정책 API는 쿠버네티스의 네트워킹 서브시스템용 플러그인을 통해 팟의 상호 통신 방식을 제어하는 규칙이 허용된다.

쿠버네티스 1.7 확장성 : 플러그인
쿠버네티스는 개발자가 자체 API를 추가할 수 있도록 “서드파티 리소스(Third Party Resource)”(TPR)라는 시스템을 오랫동안 사용해 왔다. 버전 1.7에는 같은 개념을 새롭게 구현한 커스텀 리소스 정의(Custom Resource Definition, CRD)가 있어 비교적 투박하지 않게 커스텀 API를 정의할 수 있다. 쿠버네티스 1.7로 마이그레이션할 때 기존의 TPR은 건드리지 않지만, 쿠버네티스 1.9에서는 수용되지 않을 것이다. 따라서 기존 TPR을 CRD로 당장 이주시키는 것이 최선이다.

쿠버네티스 1.7에서 또 하나의 중요한 확장성 관련 변화는 API 통합이다. 이를 통해 고급 쿠버네티스 개발자들은 CRD보다 심도 있고 규범적인 방식으로 자체 API를 클러스터에 추가할 수 있다.

코어OS의 소프트웨어 엔지니어 에릭 치앙은 두 기능의 차이점을 “CRD는 쿠버네티스로 하여금 기존 API에 커스텀 리소스를 위한 임시 저장 공간을 할당하게 해 주는 가벼운 방법이다. 반면, 통합은 코어 리소스에는 사용할 수 없는 ACL 필터링이나 특화 리소스 확인 등과 같은 쿠버네티스의 API 처리 방식을 원하는 대로 바꿀 수 있는 완벽히 플러그 가능한 방식이다”라고 설명했다. 치앙은 또 대다수의 쿠버네티스 네이티브 프로젝트들은 계속해서 CRD를 사용할 것인데 반해, “자기 의견을 고집하는” 몇몇 대형 프로젝트들은 통합을 사용할 것으로 예상하고 있다.

쿠버네티스 1.7에서 또 하나 개선된 것은 컨테이너 런타임 인터페이스(Container Runtime Interface)와 관련이 있다. 이 API는 도커와 같은 컨테이너 런타임이 큐브릿(Kubelet)에게 말을 걸 수 있게 해 준다. 큐브릿은 각 노드를 클러스터에서 실행하기 위해 쿠버네티스에서 사용하는 애플리케이션이다. 따라서 다른 여러 가지 런타임을 각각 쿠버네티스에 수동으로 통합시킬 필요가 없다.

도커는 사실상 여전히 컨테이너 런타임의 표준이라고 할 수 있다. 그러나 도커 제작자를 비롯한 다른 업체들은 런타임을 컨테이너 생태계 전체로부터 분리시키기 위해 많은 노력을 기울여 왔다. 이와 같은 쿠버네티스 1.7 기능들은 그러한 노력이 아직 멈추지 않았음을 보여준다.  editor@itworld.co.kr


2017.07.07

쿠버네티스 1.7의 새로운 기능 : 로컬 스토리지, 암호화 등

Serdar Yegulalp | InfoWorld
인기 컨테이너 오케스트레이션 및 관리 시스템 쿠버네티스(Kubernetes) 1.7은 보안, 스테이트풀(stateful) 애플리케이션, 확장성 기능 등 다양한 신기능을 갖추었다.

쿠버네티스 1.6은 주로 안정화에 관한 것이었고, ETCD 분산 키 값 저장소 3 사용 등과 같이 오랫동안 계획된 변화를 실행했다. 그러나 쿠버네티스 1.7의 새 기능은 아직 알파 단계인 것이 많다. 쿠버네티스가 보다 광범위한 시나리오에서 더욱 쓸모 있기 위해 노력 중임을 알 수 있다. 다른 새 기능은 종전에 컨테이너 생태계의 다른 부분에 이관되었던 기능을 가져온 것이다.

쿠버네티스 1.7 스토리지와 상태 : 로컬과 업데이트 유지
쿠버네티스 1.7은 지속적인 상태 관리와 관련된 몇 가지 기능이 업데이트되었다. 지속 상태 관리 방법 중 가장 흔한 것은 컨테이너 실행 그룹, 즉 쿠버네티스 용어로 팟(pod)을 여러 종류의 스토리지 볼륨에 연결하는 것이다. NFS 공유폴더나 iSCSI 타깃은 물론, AWS나 애저와 같은 클라우드 서비스의 스토리지도 포함된다.

쿠버네티스 1.7에는 로컬 스토리지 매핑 기능도 추가됐다. 쿠버네티스의 네이티브 API가 실행되는 시스템 상의 데이터에 팟 워크로드가 접근할 수 있는 편리한 방법이다.

그러나 로컬 스토리지 사용은 아직 많은 쿠버네티스 시나리오에서 현명한 선택이 아닌 것 같다. 로컬 스토리지가 가장 유용한 것은 임시 방편 애플리케이션이나 미니큐브(Minikube)와 함께 나온 것과 같은 단일 시스템 개발 노드일 것으로 보인다. 또한 현재로서는 쿠버네티스 1.7 로컬 스토리지의 많은 부분이 원시적이거나 신뢰할 수 없는 상태다. 예를 들면, 로컬 블록 디바이스를 볼륨 소스로 사용하는 것이 아직 허용되지 않는다.

그러나 장기적으로는 로컬 스토리지를 쿠버네티스의 다른 스토리지 솔루션 중 가장 우선적인 것으로 만들 계획이다.

쿠버네티스의 상태 처리에 또 한 가지 달라진 점은 지속 상태가 있는 애플리케이션 관리에 대한 것이다. 애플리케이션 팟 전체에 걸친 상태 처리에 사용되었던 스테이트풀세트(StatefulSets)에는 이제 업데이트 기능이 있다. 따라서 쿠버네티스의 자체 ETCD와 같은 스테이트풀 애플리케이션을 자동으로 업데이트할 수 있으며, 업데이트 절차가 상태에 영향을 주지 않는다.

쿠버네티스 1.7 보안 : 비밀 유지
애플리케이션은 “비밀”을 보관해야 할 때가 많다. 여기서 비밀이란 평문으로 전송되거나 저장되어서는 안 되는 데이터를 말한다. API 키 또는 서비스 암호는 흔히 비밀로 사용된다. 쿠버네티스 1.7은 이제 정지 상태에서 암호화된 정보를 네임스페이스에 저장할 수 있다. 새로운 노드 인가자가 추가되면서 어떤 팟이 어떤 기밀 정보를 다루는지도 통제할 수 있다.

유망한 기능이지만 현재로서는 완성도가 알파 단계에 머물러 있다. 현재 상태에서 기밀 정보를 맡긴다면 1.7 이후 버전의 쿠버네티스로 업그레이드하기 전까지는 아마도 복호화 후 재암호화 과정이 필요할 것이다.

도커 데이터센터(Docker Datacenter)와 같은 다른 제품들은 컨테이너에서 사용되는 기밀 정보를 저장할 수 있다. 쿠버네티스 1.7의 기밀 시스템을 대신 사용해도 되지만, 결국에는 대체 기술이 아닌 보완 기술이 될 가능성이 높다.

기밀 정보 저장을 위해 해시코프 볼트(Hashicorp Vault)와 사이버아크(Cyberark) 같은 다른 스토리지 제품과 쿠버네티스를 통합하거나 이를 강화하려는 노력이 진행 중이다.

쿠버네티스 1.7에서 종전의 일부 베타 보안 기능은 현재 안정적이다. 예를 들면 네트워크 정책 API는 쿠버네티스의 네트워킹 서브시스템용 플러그인을 통해 팟의 상호 통신 방식을 제어하는 규칙이 허용된다.

쿠버네티스 1.7 확장성 : 플러그인
쿠버네티스는 개발자가 자체 API를 추가할 수 있도록 “서드파티 리소스(Third Party Resource)”(TPR)라는 시스템을 오랫동안 사용해 왔다. 버전 1.7에는 같은 개념을 새롭게 구현한 커스텀 리소스 정의(Custom Resource Definition, CRD)가 있어 비교적 투박하지 않게 커스텀 API를 정의할 수 있다. 쿠버네티스 1.7로 마이그레이션할 때 기존의 TPR은 건드리지 않지만, 쿠버네티스 1.9에서는 수용되지 않을 것이다. 따라서 기존 TPR을 CRD로 당장 이주시키는 것이 최선이다.

쿠버네티스 1.7에서 또 하나의 중요한 확장성 관련 변화는 API 통합이다. 이를 통해 고급 쿠버네티스 개발자들은 CRD보다 심도 있고 규범적인 방식으로 자체 API를 클러스터에 추가할 수 있다.

코어OS의 소프트웨어 엔지니어 에릭 치앙은 두 기능의 차이점을 “CRD는 쿠버네티스로 하여금 기존 API에 커스텀 리소스를 위한 임시 저장 공간을 할당하게 해 주는 가벼운 방법이다. 반면, 통합은 코어 리소스에는 사용할 수 없는 ACL 필터링이나 특화 리소스 확인 등과 같은 쿠버네티스의 API 처리 방식을 원하는 대로 바꿀 수 있는 완벽히 플러그 가능한 방식이다”라고 설명했다. 치앙은 또 대다수의 쿠버네티스 네이티브 프로젝트들은 계속해서 CRD를 사용할 것인데 반해, “자기 의견을 고집하는” 몇몇 대형 프로젝트들은 통합을 사용할 것으로 예상하고 있다.

쿠버네티스 1.7에서 또 하나 개선된 것은 컨테이너 런타임 인터페이스(Container Runtime Interface)와 관련이 있다. 이 API는 도커와 같은 컨테이너 런타임이 큐브릿(Kubelet)에게 말을 걸 수 있게 해 준다. 큐브릿은 각 노드를 클러스터에서 실행하기 위해 쿠버네티스에서 사용하는 애플리케이션이다. 따라서 다른 여러 가지 런타임을 각각 쿠버네티스에 수동으로 통합시킬 필요가 없다.

도커는 사실상 여전히 컨테이너 런타임의 표준이라고 할 수 있다. 그러나 도커 제작자를 비롯한 다른 업체들은 런타임을 컨테이너 생태계 전체로부터 분리시키기 위해 많은 노력을 기울여 왔다. 이와 같은 쿠버네티스 1.7 기능들은 그러한 노력이 아직 멈추지 않았음을 보여준다.  editor@itworld.co.kr


X