[번역] INITIAL PLACEMENT OF A VSPHERE POD

출처 : https://frankdenneman.nl/2020/03/06/initial-placement-of-a-vsphere-native-pod/

Project Pacific은 vSphere를 통합 애플리케이션 플랫폼으로 전환 이 새로운 플랫폼은 기본 워크로드가 구축될 때 가상 시스템과 리눅스 컨테이너를 모두 실행한다. Linux 컨테이너를 새로운 워크로드 개체로 도입하는 것만으로는 충분하지 않다. 용기를 제대로 관리하려면 합법적인 조정자(legitimate orchestrator)가 필요하다. 그 위에 DRS와 같은 기존 서비스가 이러한 서로 다른 개체의 다양한 라이프사이클을 처리할 수 있도록 해야 한다. 컨테이너는 일반적으로 VM이 수년 동안 "살아 있는" 가상 머신보다 라이프사이클이 짧으며, 컨테이너의 기대 수명은 짧다. 그리고 이와 같이 크게 다른 변화는 자원 관리 서비스의 초기 배치 및 로드 밸런싱 운영에 영향을 미친다.

VMkernel에서 컨테이너를 1등 시민으로 운영할 수 있다는 것 자체가 몇 가지 매력적인 도전을 만들어낸다. VMworld 2018 세션에서 Michael Gasch가 강조했듯이 "Running Kubernetes on vSphere Deep Dive: The Value of Running Kubernetes on vSphere (CNA1553BU)" 컨테이너는 별도의 엔티티가 아니라 Linux 프로세스와 오브젝트의 모음입니다.

Linux-Container-Task_struct.png

ESXi에 대한 컨테이너 런타임

ESXi VMkernel은 Linux 운영 체제가 아니다. VMkernel 하드웨어와 프로세스 추상화는 Linux 프로세스를 직접 지원하는 것이 아니라 가상 시스템을 서비스할 목적으로 구축되었다. 이를 위해 Project Pacific은 ESXi(CRX)에 대한 컨테이너 런타임을 도입한다. CRX는 Linux 애플리케이션(컨테이너)이 VMkernel에서 직접 실행 중일 경우 이를 실행할 수 있는 Linux ABI(애플리케이션 바이너리 인터페이스)를 제공한다. CRX의 장점은 ESXi 호스트에서 실행되는 다른 프로세스 또는 UserWorld와 완전히 격리된다는 것이다. 어떻게 그것이 가능한가요? 우리의 오랜 친구, VM-construct를 사용한다.

CRX 인스턴스의 가상 시스템 측면은 VMM(virtual machine monitor)의 사용과 VMX(virtual hardware)의 구성이다. VMM은 VM에 대한 예외 및 인터럽트 처리를 제공한다. CRX 인스턴스 내부에서는 CRX 인스턴스와 VMkernel 서비스 간의 통신을 제공하기 위한 CRX 초기화 프로세스가 활성화되어 있다.

하지만 우리는 리눅스 커널을 가지고 있어야 컨테이너가 실행되도록 리눅스 ABI를 제공할 수 있다. 우리 것을 사용하는 것보다 더 나은 리눅스 커널이 뭐가 있을까? VMware Photon은 VMware 지원 및 유지 관리 LTS Linux 커널로 선택되었다. Photon은 VCSA 및 기타 VMware 제품의 기반으로 사용되며 설치 공간이 매우 가볍다. 흥미로운 부분은 이 커널가 별도의 디스크에 저장되어 있지 않다는 겁니다. 베어 리눅스 커널(bare linux kernel)은 인스턴스화되면 CRX 인스턴스의 메모리 공간에 직접 로드된다. 또한 CRX 인스턴스는 제거된다. CRX와 커널을 최대한 가볍고 빠르게 만들기 위해 필요한 장치와 기능만 사용할 수 있다. 예를 들어 CRX는 Photon 커널에 반가상화된 장치만 노출한다.

ContainerRuntimeforESXi-1.png

이 베이스 위에 CRX 인스턴스 내에서 OCI 호환 컨테이너를 스핀업(spin up)시킬 수 있는 컨테이너 런타임이 활성화되어 있다.

VMkernel 안에서 우리는 스피어렛(Spherelet)고 불리는 큐브렛(Kubelet)의 구현을 소개했다. 즉, Sparelet은 ESXi 호스트를 Kubernetes 워커 노드로 변환하고 Sparelet은 Kubernetes 제어 평면의 확장 역할을 한다. CRX 인스턴스 내부의 컨테이너 런타임에는 스피어렛과 컨테이너 런타임 간의 통신을 허용하는 스피어렛 에이전트가 포함되어 있다. 스피어렛 에이전트는 쿠버네티스가 포드로부터 기대하는 기능을 제공한다. 상태 점검, 스토리지 마운트, 네트워킹 설정, 포드 내부의 용기 상태 제어, kubectl에 인터랙티브 엔드포인트 제공한다. Spherelet 에이전트는 libcontainer와 연결되어 있으며, 이 방법을 사용하여 컨테이너를 발사하는 방법을 이해한다. 일단 컨테이너가 CRX 인스턴스 안에서 실행되면 우리는 이 개체 그룹을 네이티브 포드라고 부른다.

한 척의 배에 두명의 선장

이제 ESXi가 컨테이너를 실행하는 방법을 이해하게 되었으므로, 우리는 누가 자원 관리 관점에서 무엇을 제어하는지 생각해 볼 필요가 있다. 프로젝트 퍼시픽은 VMkernel 내부에서 고유하게 컨테이너를 실행하는 방법을 소개할 뿐만 아니라, 컨테이너의 오케스트라로 쿠버네티스를 소개한다. 본질적으로 VM 워크로드에 대한 제어 기준면이 이미 있는 플랫폼(vCenter+Hostd)에 제어 기준면을 추가하고, DRS와 같은 추가 서비스로 리소스 관리를 간소화 한다.

첫눈에 쿠버네티스가 VM을 관리하고 제어하지 않으므로, 오버랩이 발생하지 않아 이 문제가 어렵지 않다. 하지만, 실행(play)에는 이중성이 있다는 것을 눈치챘을 것이다. vSphere 포드는 VM과 컨테이너 그룹의 조합이다. 그리고 더욱 흥미롭게 하기 위해, 두 제어 플랫폼은 행동과 배치를 제어하는 유사한 구조를 가지고 있다. Kubernetes에서는 레이블 및 배포 정책을 사용하여 작업자 노드의 컨테이너 배치를 제어한다. DRS에서 선호도 규칙을 사용하는 경우 쿠버네티스에서는 요청과 제한을 사용하여 리소스 사용 권한을 지정하고 vSphere에서는 vSphere Reservation, Share, Limits(RLS) 설정을 사용한다. 또한 단일 CRX 인스턴스 내에서 실행되는 여러 컨테이너의 개별 요청과 제한이 VM의 RLS 설정으로 변환되는 방법에 대해서도 생각해야 한다. 다음 글에서 리소스 사용 권한 고려 사항을 다룰 예정이며, 이 기사에서 살펴보고자 하는 것은 두 개의 제어 영역이 활성화되어 있을 때 컨테이너와 VM의 배치다.

CRX 인스턴스의 초기 배치

개발자가 애플리케이션을 전개할 때 쿠버넷 API 서버와 상호작용을 하며, API 서버는 쿠버넷 아키텍처에 존재하는 다양한 컴포넌트에 대해 모든 종류의 이벤트를 촉발한다. Project Pacific은 Kubernetes의 API를 확장하고 vSphere 플랫폼과 상호 작용하기 위해 여러 컨트롤러를 도입했다. 따라서 쿠베르네스가 책임지고 있는 것 같다. 그러나 우리는 DRS와 HostD의 자원 관리 능력의 순수함을 무시할 수 없다. 반면에 쿠버네티스는 자원 소비자(컨테이너)와 자원 공급자(워커 노드)를 혼용하고 일치시키기 위해 요청(예약에 상당하는)을 사용하는 매우 퉁명스럽고 거친 심피 방식을 사용한다. vSphere는 리소스 활동을 이해하는 능력, 나태함을 임시 우선 순위 조정으로 변환하는 능력, 단일 호스트를 넘어 리소스 사용 권한의 정렬을 통해 훨씬 우아하다. 그리고 이를 더욱 향상시키기 위해 Project Pacific은 vSphere 네임스페이스에 새로운 워크로드(즉, 컨테이너)를 추가하면 리소스 풀의 우선순위를 즉시 재조정할 수 있는 확장 가능한 공유 기능을 사용하고 있다. Duncan Epping과 나는 2013년 DRS 엔지니어링 팀과 함께 자랑스럽게 만들었다. 그러나 쿠버네츠 건축은 매우 우아한 방식으로 비즈니스 논리를 표현하고, 라벨, 페인트, 관용에 기초한 컨테이너 배치를 쉽게 지시한다. 따라서 양쪽 제어면의 기능 매쉬(mesh)를 통합하거나 만드는 것이 타당하다.

DRS-Pacific-Integration-vSphere-Pod-1536x1162.png

초기 배치 순서
  1. 개발자는 Kubernetes API 서버와 협력하여 애플리케이션을 배포한다. 일반적으로 이러한 배포는 포드 사양이 포함된 YAML 파일을 사용하여 API 서버에 제출된다.
  2. 배포 및 포드 사양은 etcd 서버에 저장되고 API 서버는 이 이벤트를 kube-scheduler가 구독하는 감시 목록에 게시한다. 이벤트 기반 아키텍처에 대한 자세한 내용은 이 문서를 참조하십시오.
  3. kube-scheduler는 적절한 호스트의 선택 프로세스를 시작한다. 선호도, 포드 및 노드 레이블 및 기타 노드 선택기 제약 조건을 기반으로 사용 가능한 워커 노드(ESXi 호스트) 목록을 필터링한다.
  4. DRS로 처리된 목록을 전송하여 노드를 선택한다. DRS는 해당 결정 트리(VM 리소스 사용 권한, 호스트 상태, 호스트 호환성)를 기반으로 노드를 선택한다.
  5. 호스트를 선택하면 vCenter API 서버를 통해 Pacific Scheduler로 정보가 반환된다.
  6. 스케줄러는 etcd 데이터베이스에 이벤트로 저장된다.
  7. 이벤트가 etcd 데이터베이스에 저장되는 동안 vCenter는 선택한 ESXi 호스트에서 HostD 프로세스에 명령을 실행하여 가상 시스템의 전원을 켠다.
  8. HostD는 VM(VMX, VMM)의 전원을 켜고 이 가상 시스템의 메모리 주소 공간에 Photon 커널을 로드한다.
  9. HostD는 새로 생성된 VM의 VM ID를 Pacific Scheduler Extension에 반환한다.
  10. VM ID는 etcd 데이터베이스에 저장되고 이제 제어부 노드에 Sparelet이 포드를 구성할 수 있는 충분한 데이터가 있다.
  11. 이벤트에 대해 vSphere Pod Lifecycle Controller가 업데이트되고 vSpherelet을 실행하여 포드를 구성한다.
  12. 스피릿은 HostD와 연결하여 포드의 개성을 구성하고 네트워킹 및 스토리지 요소를 구성한다.
  13. CRX 컨테이너 런타임은 포드 사양에 따라 컨테이너의 시작을 개시한다.
  14. 스피렛은 컨테이너의 상태를 다시 쿠베르네테스 마스터에게 반환하여 etcd 데이터베이스에 이벤트로 저장한다.

이 아키텍처를 통해 vSphere 리소스 관리 기능의 저력을 누리면서 쿠버네티스 제어판의 표현력과 두 가지 장점을 모두 누릴 수 있다. 이 항목의 다음 글은 컨테이너 리소스 구성 설정에 기반한 리소스 할당으로 이동한다. Pacific 프로젝트는 아직 베타 단계에 있으며 최종 제품으로 사용할 수 없는 상태(예)라는 점에 유의한다. 채널 고정!