[번역] vSphere 7 – vSphere Pods Explained

출처 : https://blogs.vmware.com/vsphere/2020/05/vsphere-7-vsphere-pods-explained.html

이 블로그 게시물에서 "vSphere Pod"를 구성하는 요소에 대해 자세히 알아보려고 한다. 이전 vSphere Pod Service 를 읽어보셨다면, 서비스를 구성하는 여러 구성 요소에 대해 알수 있다. 이러한 구성 요소 중 하나는 vSphere Pod 자체였다. 뛰어들자!

vSphere Pod란? 무슨 말을 하고 있는지 솔직하게 설명하는 것이 항상 최선이다. 앞의 블로그에서 다음과 같이 말했다.

vSphere Pod Service 서비스는 게스트 내에서 컨테이너 실행을 담당하는 특수 제작된 경량 Linux 커널을 제공한다.

잠깐만? ESXi? Linux? 속에 뭐가 있어? ESXi Linux? (NO! IT NOT!) 아마도 그래픽이 시작하기에 좋은 장소일 것이다.

components-of-a-vsphere-pod-esxi-vmx-linux-kerne.gif

비디오에 ESXi 서버가 표시된다.

컨테이너 실행를 지원하기 위해 코드 변경으로 커스터마이즈된 VMX에서 실행한다. VMX는 ESXi에서 제공하는 리눅스 커널이다. 커널에서 실행되는 것은 Container Engine(crx-init)이다. 이 세 가지 구성요소를 함께 "CRX"라고 한다.

마지막으로 하나 이상의 컨테이너가 포드 위에서 실행되고 있다. 좋아, 이 모든게 너한테 무슨 의미야? VM인가? VM이 아닌가? 왜 리눅스가 있을까? 자세한 얘기 좀 합시다.

CRX

CRX는 "Container Runtime for ESXi"을 의미한다. 간단히 말해, 컨테이너를 실행하는 데 최적화되어 있는 리눅스 커널을 실행하기 위해 고도로 최적화된 가상 머신이다. 위에서 언급했듯이, 커스터마이즈된 VMX, 리눅스 커널, 컨테이너 엔진 등 세 가지 구성 요소는 "CRX"로 간주된다. VMX 프로세스를 살펴봐야 하는 이유를 이해할 수 있다. ESXi에서 실행 중인 프로세스를 살펴보면 여러 프로세스가 "VMX" 프로세스로 표시되어 있는 것을 볼 수 있다. 예를 들면 다음과 같다.

word-image.png

VMX 프로세스가 VM "mgt-dc-01.cpbu.lab"을 실행 중임을 볼 수 있을 것이다. 이 프로세스와 관련하여 2개의 vCPU, SVGA 장치, VMRC 또는 웹 콘솔과 같은 용도로 사용되는MKS 장치가 있다.

VMX의 어떤 부분이 "수정"되었는가? 이러한 수정 사항 중 일부는 "svga.present = "FALSE"와 같은 기본 VMX 설정일 뿐이다. CRX를 지원하기 위한 코드 변경도 있었다. CRX를 지원하기 위한 몇 가지 변경 사항은 다음과 같다.

  1. 직접 부팅 지원. 일반적으로 VM은 VMDK(가상 디스크)에서 OS를 부팅한다. 이를 위해서는 BIOS가 필요하다. 하지만 포드(pod)를 더 빨리 부팅할 뿐만 아니라 컨테이너처럼 만들기를 원했다. 따라서 CRX는 BIOS를 우회하여 미리 로드된 리눅스 커널을 직접 실행하는 등 필요한 코드를 변경했다.
  2. VM는 몇 가지 사항이 있을 것으로 예상한다. 데이터스토어의 "홈" 디렉토리는 로그, VMX 및 VM 스왑 파일을 쓸 수 있는 공간을 제공한다. 또한 VMDK, ISO 파일, PXE 부팅 등 부팅할 운영 체제가 필요하다. CRX가 우리가 해야 할 일을 하게 하기 위해서 우리는 이러한 가정들 중 일부를 바꿔야 했다. 이를 위해서는 VMX에 대한 코드를 변경해야 한다.
  3. CRX는 원하지 않는 드라이버를 받지 않는다. 좋은 예는 CRX가 키보드, 마우스, 비디오와 같은 것을 필요로 하지 않는다는 것이다. 그것은 이제 코드에서 금지(forbidden)되어 있다.

보안 기본 제공

자, 미리 탑재된 리눅스 커널에 대해 언급했었습니다. 일반적으로, 그것은 많은 사람들이 "이 커널을 어떻게 업데이트하는가?"라는 질문을 던질 것이다. 글쎄, 당신은 할 수 없다. 직접. CRX가 컨테이너를 지원하기 위해 사용하는 커널은 VIB로 사전 포장되어 ESXi 배포의 일부로 배포된다. 이 커널에 대한 패치 및 업데이트는 ESXi로 업데이트/업그레이드의 일부로 제공된다. 사실, CRX는 VIB 파일을 통해 제공되는 Linux 커널만 받아들이도록 하드 코딩되어 있다. 이것은 당신이 커널을 수정할 수 없다는 것을 의미한다. 또한 7년간 vSphere Security를 지원하는 저를 따라오신 분들을 위해, 이는 커널이 변조 방지가 될 뿐만 아니라 Secure Boot 및 TPM 2.0을 사용하도록 설정하면 vSphere Pod가 "클린" 부팅 중임을 증명할 수 있다는 것을 의미한다는 것을 알게 되셨다면 기뻐하실 겁니다.

이러한 매우 멋진 기능 외에도 CRX에 훨씬 더 많은 제어 기능이 탑재되어 있다. 예를 들어 VM이 "CRX 모드"에 있을 경우 구성에 적용할 수 있는 변경 사항을 제한한다. 많은 VMware Tools 작업이 사용되지 않도록 설정된다. CRX 모드는 "숨겨진" 게스트 OS 유형이다. UI나 API를 통해서는 이용할 수 없다. 이러한 "수동" 방법으로는 CRX를 만들 수 없다. VM(CRX)이 적절한(숨겨진) 게스트로 설정된 경우, 그러면 OS 타입은 적절한 설정과 제한이 시행된다.

이 낟알은 전에 언급했듯이 매우 최적화되어 있다. 그것은 최소한의 드라이버를 포함하고 있다. 당신은 "Just Enough Kernel"이라고 말할지도 모른다. vSCSI 및 VMXNET3와 같은 반가상화 디바이스를 사용한다.

일단 커널이 "부팅"되면 최소한의 "초기" 프로세스를 시작한다. 이것은 /dev 계층을 채우고 루프백 네트워크 장치를 초기화한다. 그 후에 응용 프로그램이 시작된다.

운영 효율성 및 보안

하나의 vSphere Pod에서 5개의 컨테이너를 실행하는 것이 더 나은가, 아니면 다섯 개의 별도 vSphere Pods에서 컨테이너를 실행하는 것이 더 나은가? 자, 여러분이 상상하실 수 있듯이, 그 답은 "상황에 따라 달라진다(It depends)" 다. 고려해야 할 많은 설계 결정이 있다. 그 중 하나가 보안 대 라이프사이클 관리다. 한 포드에 있는 5개의 컨테이너는 설계에 의해 서로 약하게 격리되고 협업하여 라이프사이클을 하나의 개체로 관리하는 단일 서비스를 제공한다.

스펙트럼의 반대편에는 보안이 주로 자리 잡고 있는 곳이 있다. 그들은 전형적으로 많은 수준의 고립을 주장한다. 만약 그 컨테이너 중 하나에 버그가 있다면, 다른 컨테이너를 손상시킬 수도 있다.

중간 어딘가에 비즈니스 요구사항이 있다. 만약 저 컨테이너가 손상되면 그 컨테이너는 격리될거야 그러나 여러 컨테이너는 보통 하나의 실체, 하나의 서비스로 보여진다. 그래서 격리되어 있는 동안에도 여전히 "up" 않는다.

포드에서 5개의 컨테이너를 실행할 때의 장점 중 하나는 각 컨테이너에 1GB의 메모리(총 5GB)를 제공하면 해당 메모리가 "공유"될 수 있다는 것이다. 한 컨테이너가 더 많은 메모리를 필요로 하고 다른 컨테이너가 할당량을 소비하지 않았다면, 그 메모리는 해당 컨테이너에 사용할 수 있다.

리소스 관점에서, 만약 우리가 각각 하나의 컨테이너와 1GB의 메모리를 가진 5개의 개별 포드를 실행하고, 컨테이너가 더 많은 메모리를 필요로 한다면, 공유 메모리 풀에 접근할 수 없을 것이다. 이것은 병목 현상을 일으킬 수 있다. 그러나 각 컨테이너가 자체 Pod에서 실행되고, vSphere Pod가 VM이기 때문에 이미 검증된 가상 시스템 및 NSX 네트워킹의 격리를 확보한다. VM 성능 병목 현상을 모니터링할 수 있는 툴이 이미 존재한다는 것은 말할 것도 없다.

이것들은 당신과 당신의 개발팀이 만들어야 할 디자인 트레이드오프들 중 몇 가지 입니다. 어떤 시나리오가 귀사의 보안 및 운영 요구를 충족하는지 확인하기 위해 두 가지 시나리오를 모두 시도해 보기 바란다. vSphere with Kubernetes는 이러한 옵션을 제공한다.

보안 강화

보안과 고립에 대해 말하자면 vSphere Pods는 여기에서 단연 돋보인다. 오늘은 컨테이너가 어떻게 베어메탈 속에서 작동하는지 살펴보자. 다음 이미지를 참조한다.

bare-metal-containers.png

완전한 메타 환경에서는 모든 컨테이너가 공유 파일 시스템, 공유 스토리지, 공유 메모리 및 공유 네트워킹을 갖춘 단일 커널에서 실행된다. 격리는 소프트웨어에서 리눅스 커널 원시성에 의존한다.

아래 이미지를 보면 비즈니스 요구사항이 필요한 경우 포드당 하나의 컨테이너를 사용하여 CPU, 메모리 및 네트워킹을 최적으로 격리할 수 있는 vSphere Pod 사용시 이미 강력한 가상 시스템 분리를 활용하고 있는 경우 Bare Metal 설치 시 100대의 컨테이너가 사용하는 것과 동일한 Linux 커널 인스턴스가 아닌 포드 고유의 Linux 커널을 부팅하고 VMware NSX를 통해 엔터프라이즈급 네트워킹 격리를 사용할 수 있는 기능 제공한다. 모두 성능 저하가 없다.

a-screenshot-of-a-cell-phone-description-automati.png

성능

위에서 성능에 대해 언급했다. 2019년 8월에 우리는 당시 "Native Pod" 성능이라고 불리던 것에 대해 블로그에 글을 올렸다. (Native Pod는 일종의 코드명이었다; 실제 이름은 현재 "vSphere Pod"다). 이 글에서 우리의 엔지니어 중 한 명인 Kartik Ganesanesan과 vSphere with Kubernetes의 PM인 Jared Rooff가 베어메탈 상의 리눅스에 비해 vSphere Pod가 최대 8%의 성능 향상을 보여주었다. 블로그 글을 읽으면 ESXi 스케줄러와 vSphere Pods가 독립된 엔터티라는 사실 때문에 이러한 성능 향상이 상당 부분 발생한다는 것을 알 수 있을 것이다. 스케줄러는 각 포드가 해당 CPU의 메모리에 가장 가까운 CPU에 있는지 확인하기 위해 최선을 다한다. 자세한 내용은 블로그 게시물을 읽어 보기 바란다! 이것은 매혹적인 작품이다. 8월 이후 새로운 소식이 있는지 물어봐도 된다. 내가 말하고자 하는 것은 우리는 항상 최적화 작업을 하고 있다는 것이다. 우리가 발표할 좋은 소식이 더 있을 때 우리는 여기서 그럴 것이다.

마치면서

이 문제를 마무리하기 위해 "언제 vSphere Pods를 사용하는가?"라는 질문을 던질 수 있다. 그것에 대한 답은, 당신이 상상할 수 있는 것처럼, 다시 말하지만, "상황에 따라 달라진다(It depends)"다. 좀 더 명확하게 하기 위해 분해해 보자.

  • 완전히 업스트림된 Kubernetes 환경이 필요하십니까? vSphere Pod 서비스와 규정 준수에 대한 자세한 내용은 다른 블로그 기사를 통해 곧 제공될 예정이다. 이것은 너의 결정에 도움이 될 것이다.
  • Helm과 같은 써드파티 통합이 필요한가?
    그러면 vSphere with Kubernetes에서 실행되는 TKG 클러스터를 사용한다. 이것은 당신에게 가장 융통성을 준다. 이 시나리오에서 컨테이너는 표준 VM에서 실행될 것이다. 오늘날 VM은 VMware Photon을 기반으로 한다.
  • 절대 네트워크, CPU, 메모리, 파일 시스템 분리가 필요하십니까?
  • vSphere Pod에서 테스트한 애플리케이션이 있고 작동 가능하십니까?
  • vSphere Pod에서 충족되는 성능 요구 사항이 있으십니까?

질문에 대답한 것 같다. 결론은 선택권이 있다는 것이다. 애플리케이션을 가장 잘 실행하는 곳에서 실행할 수 있는 유연성을 확보하자.

vSphere Pod 대 Tanzu Kubernetes 클러스터를 사용하는 시기에 대한 자세한 정보와 지침은 이 주제에 대한 설명서 페이지를 참조하기 바란다. 이 공간의 모든 것이 그렇듯이, 이러한 지침은 시간이 지남에 따라 바뀔 수 있도록 빠르게 움직인다.

이 글이 도움이 되었기를 바란다. 나는 얼마 전에 쿠베르네테스 세계에 들어왔는데, 머지않아 시스템이 어떻게 관리될지에 변화가 일어나는 것을 보게 되어 정말 흥분된다. 이 여정에 함께 동참해 주길 바란다. 재미있는 놀이기구가 될 거야!