[번역] vSphere 7 – Introduction to the vSphere Pod Service

출처 : https://blogs.vmware.com/vsphere/2020/04/vsphere-7-vsphere-pod-service.html

Cloud-Native-Apps-Icon-2020.png

지금은 vSphere 관리자가 되기 위한 신나는 시간이다! vSphere 7은 현재 사용 가능하며 여기에는 정말 멋진 것들이 많이 포함되어 있다. 이 글에서 소개할 것은 vSphere 파드 서비스 입니다. VMworld 2019의 Project Pacific 발표와 컨텐츠를 따라 했다면 이 중 일부는 익숙할 것이다. 이 글은 개발자 쪽이 아닌 vSphere 관리자 입장에서 Kubernetes와 vSphere를 논의하는 글 중 하나다.

가장 먼저 이야기할 내용은 vSphere 파드 서비스다. 이에 대해 자세히 알아보기 전에 쿠버네티스가 무엇인지, vSphere Pod Service가 어떻게 적합한지에 대해 간략히 설명하겠다.

Kubernetes는 컨테이너형 워크로드와 서비스를 관리하기 위한 플랫폼이다. 쿠버네티스를 배치하면 클러스터가 생긴다. 그 과정의 일부로 몇 가지 구성요소가 인스턴스화된다.

  • 노드: 모든 클러스터에는 하나 이상의 작업자 노드가 있다.
  • 파드: 작업자 노드에서 실행되는 애플리케이션 워크로드의 구성 요소
  • 콘트롤 플레인: 이 기능은 클러스터의 작업자 노드와 파드를 관리하고 클러스터를 가로질러 실행되므로 내결함성 및 고가용성을 제공한다.

vSphere 포드 서비스란?

vSphere Pod Service는 ESXi 클러스터를 통해 VMware 관리 Kubernetes 콘트롤 플레인에서 실행되는 서비스다. ESXi에서 네이티브 쿠버네티스 워크로드를 직접 실행할 수 있게 해 준다. ESXi 호스트가 노드가 되고, vSphere 파드가 애플리케이션 워크로드의 구성 요소를 실행한다.

내가 왜 그걸 하고 싶어하지? 이런 식으로 운영하면 어떤 장점이 있는 겁니까? 잠시 후에 그 일에 착수할 겁니다.

vSphere 포드 서비스 배경

vSphere Pod Service는 ESXi의 기본 재설계. ESXi에서 실행되는 쿠버네티스 및 컨테이너 워크로드의 요구사항을 해결할 수 있는 방법은 여러 가지가 있었다. 예를 들어 이전에 vSphere Integrated Containers를 출시한 적이 있다. VM에서 컨테이너가 실행되고 컨테이너 관리 플랫폼인 VMware Admiral에 의해 관리되었다. 하지만 쿠베르네테스는 아니었고 우리는 vSphere와 더 좋고, 더 깊고, 기본적인 통합을 할 수 있다고 생각했다.

운영상, 앞으로 나아갈 방법은 원하는 것을 선언하고 인프라가 공급하도록 하는 것이다. 개발자 입장뿐만 아니라 관리자 입장에서도 그렇다. 그러나 이를 달성하기 위해 우리는 바퀴를 다시 발명하는 것을 원하지 않았다. 우리는 vSphere라는 훌륭한 플랫폼을 가지고 있다. 그 모든 것을 버리고 다시 시작하는 것은 매우 비싸고 파괴적일 뿐만 아니라, 그것에 의존하는 고객들도 같은 일을 하고 처음부터 새로운 모든 것을 배워야 한다는 것을 의미한다. 우리는 vSphere에 의존하는 많은 고객이 있다. 그들은 그들의 사업에 필수적인 프로세스를 가지고 있다. 또한 보안 감사를 통과하거나 백업을 수행하는 등의 작업을 수행해야 한다!

우리가 가진 것을 활용하고, 동등하거나 더 나은 성능과 확장성을 제공하며, 이 여정에 고객을 참여시키는 것이 더 말이 되지 않을까? 35년 이상 IT에 몸담아 온 사람으로서 나는 충분히 이해가 간다.

vSphere Pod Service 구성요소

vSphere Pod Service Spherelet

Spearlet은 쿠버네티스 "Kubelet"을 기반으로 하며 ESXi 하이퍼바이저가 쿠버네티스 워커 노드 역할을 할 수 있도록 한다. Spearlet은 쿠버네티스 콘트롤 플레인에 대한 확장자 역할을 하는 ESXi UserWorld 에이전트다. 그것의 주요 기능은 파드 구성, 볼륨, 서비스, 구성맵 및 비밀에 대한 변경사항에 대해 쿠버네티스 콘트롤 플레인의 API 서버를 폴링한 후 그것들이 인스턴스화되도록 필요한 작업을 수행하는 것이다.

vsphere-pod-service-devops-connects-to-the-k8s-c.gif

CRX(""Container Runtime for ESXi") 에이전트

내 생각에, 이 부분은 기초 건축에서 가장 멋진 부분 중 하나이다. ESXi는 리눅스가 아님을 기억하자. vSphere 파드 서비스는 게스트 내에서 컨테이너를 실행하는 것을 담당하는 전용 경량 Linux 커널을 제공한다. 리눅스 애플리케이션을 실행하는 데 필요한 ABI(Linux Application Binary Interface)를 제공한다. 이 Linux 커널은 하이퍼바이저에서 제공되기 때문에 VMware는 성능과 효율성을 높이기 위해 수많은 최적화를 실현할 수 있었다. 또한 CRX 커널이 전체 Linux 게스트 OS를 로드하지 않기 때문에 새로운 vSphere 파드의 인스턴스화가 매우 빠르다.

그렇다. 우리는 전체 Linux 게스트 OS를 로드하지 않는다. CRX Init라고 하는 매우 최적화된 커널 및 초기화 프로세스. 사용되는 Linux 커널은 일반적인 수명 관리를 통해 ESXi를 업데이트할 때 업데이트된다.

ESXi의 모든 것과 마찬가지로, 이것은 VIB로 배송될 것이다. ESXi용 Secure Boot에 대한 이전 글를 살펴보셨다면 이 Linux 커널이 디지털 서명 패키지에 포함되어 있으므로 Secure Boot를 설정할 때 변경되지 않았음이 확인됨을 의미합니다. 따라서 CRX는 컨테이너를 실행하는 좋은 방법일 뿐만 아니라 본질적으로 더 안전하다!

CRX 에이전트는 VMX와 매우 유사해 보인다. 왜냐하면 거기서부터 시작했기 때문이다. 핵심 차이점은 게스트 운영체제(OS)와 관련된 모든 것이 뽑혔다는 점이다.

  • USB 연결? 사라졌다
  • 비디오 디스플레이 하드웨어? 사라졌다
  • 필요하지 않은 것은 모두 제거한다.

이 모든 변화들은 CRX를 초경량화한다. "성능을 갖추려면 베어 메탈 위에 있어야 한다!" 또는 "VM에서 실행되는 것은 너무 많은 오버헤드를 도입한다!"라는 과용된 격언이 이제 고대사다. vSphere에게 vSphere 파드는 기본적으로 특수 가상 시스템처럼 보인다. 이는 vSphere Admin의 관점에서 "친숙하다"고 느끼고 있는 것을 의미한다. 완전히 새로운 것을 배우지 않는다. 우리는 미래의 블로그 기사에서 CRX에 대해 더 자세히 살펴볼 것이다.

hostd

"hostd"는 Spearlet과 통신하여 vSphere Pod의 하드웨어 속성을 쿼리하고 컨테이너 이미지 VMDK 또는 NIC를 연결하도록 재구성하는 ESX 호스트의 UserWorld 에이전트다. hostd와의 통신 채널은 로컬 티켓을 사용하여 인증된 localhost HTTPS 연결을 통해 이루어진다. 이 세션은 잠금 모드에서도 VM 재구성 작업을 수행할 수 있도록 보장되는 DCUI 사용자를 사용하여 인증된다.

이미지 서비스

이미지 서비스는 컨테이너 이미지 레지스트리에 연결하여 Spearlet에 의해 vSphere Pod에 부착될 VMDK에 컨테이너 이미지를 스테이징하는 역할을 한다. 그것은 하버를 활용하고 각 팀은 그들만의 프로젝트를 공유한다.

쿠버네티스 콘트롤 플레인 API

Kubernetes Control Plane API는 포드, 서비스, 볼륨, 컨트롤러 등을 포함하여 Kubernetes 클러스터의 엔티티를 대표하는 모든 API 객체를 검증하고 구성하는 중앙 엔드포인트다. 이것은 API 객체에 대한 요청을 하기 위해 kubectl이 연결되는 REST 엔드포인트를 노출시킨다. 또한 클러스터의 다른 모든 구성요소가 상호 작용하는 클러스터의 공유 상태에 대한 프런트엔드를 제공한다. API는 클러스터 상태에 변경사항을 전파할 수 있도록 클러스터 내의 다른 컨트롤러(예: Kubelet)에 의해 API 객체에 대한 변경사항을 폴링한다.

Ephemeral VMDK

각 vSphere Pod는 컨테이너 로그, 빈 Dir 볼륨 및 구성 맵을 스테이징하는 데 사용되는 VMDK로 프로비저닝된다. 이 VMDK의 수명은 vSphere Pod의 수명과 연계되어 있다. 이 VMDK에 기록된 모든 데이터는 포드 실행이 완료되면 손실된다. Ephemeral VMDK는 DRS 스케줄러 확장에 의해 프로비저닝되지만, Spherelet의 지시에 따라 Spherelet 에이전트가 사용하도록 포맷되고 스테이징된다. 이것은 VMDK이기 때문에 스토리지에 구애받지 않는다. vSphere에서 지원하는 모든 스토리지에서 작동한다.

컨테이너 이미지

파드를 구성하는 컨테이너는 컨테이너 이미지를 VMDK 이미지로 vSphere Pod에 탑재한다. 컨테이너 이미지는 이미지 서비스에 의해 VMDK에 미리 입력되며 파드 시동 시퀀스에 앞서 프로비저닝되어야 한다.

vSphere Pod Service를 사용하는 경우

vSphere 파드 서비스는 쿠버네티스를 사용하지만, 순응적인 쿠버네티스 클러스터는 아니다. 이는 vSphere를 Kubernetes 클론으로 전환하려는 것이 아니라 Kubernetes를 사용하여 vSphere를 개선하려는 의도인 설계에 의한 것이다. Joe Beda의 말처럼 플랫폼이다. 개발자가 표준 기반이며 업스트림 쿠베르네테스 클러스터에 완전히 부합해야 하는 경우, "게스트" 클러스터라고도 하는 Tanzu Kubernetes 클러스터를 사용할 수 있다.

vSphere Pod Service의 몇 가지 사용 사례는 ESXi 라이프사이클에 적합할 수 있는 경우를 들 수 있다. vSphere Pods는 개발 중에 사용되는 모든 타사 툴과 최신의 가장 뛰어난 Kubernetes를 실행하고 싶은 곳이 아니다. vSphere Pods는 현재 일부 고유 워크로드에 관심을 가질 수 있는 검증된 ESXi 분리 기술을 활용하는 것과 같은 고유한 보안 및 운영상의 이점을 제공한다. vSphere 파드에서는 하드웨어에 직접 액세스할 수 없으며, 이는 또 다른 보안 이점이다.

vsphere-pod-service-advanced-security-and-perfor.png

대부분의 개발자와 사용자에게 TKG 클러스터는 쿠버네티스에 완전히 부합하고 쿠버네티스에 연결되는 제3자 확장 및 도구를 통합할 수 있기 때문에 가야 할 길이다.

마무리

vSphere 관리자(administrator)에게 vSphere 파드 서비스에 대한 유용한 개요가 제공되었기를 바란다.  Kubernetes가 포함된 vSphere와 관련하여 vSphere 관리자가 관심을 가질 만한 콘텐츠에 대한 질문이나 아이디어가 있으면 Twitter로 문의하기 바란다. 나는 @mikefoley이고 내 DM은 열려있다.

고마워,

마이크