Cormac Hogan
이 게시물에서는 이제 vSphere with Tanzu에서 VM 서비스라고 하는 새로운 서비스를 살펴보겠습니다. 개발자는 이 새로운 서비스를 통해 TKG 서비스를 통해 Tanzu Kubernetes 클러스터를 생성하거나 Pod 서비스를 통해 PodVM을 생성할 때와 마찬가지로 vSphere Infrastructure에서 가상 시스템을 생성할 수 있습니다. 이 두 가지 서비스 모두 vSphere with Tanzu에서 이미 사용할 수 있습니다. 많은 애플리케이션이 컨테이너와 VM으로 구성될 것으로 예상되므로, 이는 개발자가 Kubernetes CLI, Kubetl을 통해 이러한 다면 애플리케이션을 생성할 수 있도록 지원하는 첫 번째 단계입니다. 이 게시물에서는 vSphere Administrator의 권한 또는 책임에 해당하는 단계와 인프라가 구축되면 개발자에게 전달하는 단계에 대해 설명합니다.
vSphere Admin – 요구 사항 검토
먼저 요구 사항을 살펴보겠습니다. vSphere 관리자는 모든 것이 올바른 버전인지 확인해야 합니다. 이 기능은 2021년 4월 27일에 출시된 vSphere 7.0 U2a에서만 사용할 수 있습니다. vCenter Server를 업그레이드한 후에는 vSphere 관리자가 Tanzu Supervisor 클러스터를 버전 v1.19.1+vmware.2-vsc0.0.9-17882987로 전환하여 vSphere with Tanzu Supervisor 클러스터의 롤링 업그레이드를 구현해야 합니다. NSX-T에서는 이 기능을 사용할 필요가 없습니다. 설치 시 NSX ALB와 함께 vSphere Distributed Switch를 사용하여 클러스터 및 애플리케이션에 로드 밸런싱 서비스를 제공하고 있습니다. 이 게시물을 만드는 데 사용한 버전은 다음과 같습니다.
- vCenter 7.0 U2a, 빌드 17920168
- ESXi – VMware ESXi, 7.0 U2, 빌드 17630552
- VMware NSX 고급 로드 밸런서 버전 2.0.1.4(빌드 9087)
- vSphere with Tanzu 슈퍼바이저 클러스터 버전 v1.19.1+VMware.2-30.0.9-178882987.
워크로드 관리의 새로운 서비스 기능
위의 버전을 업그레이드(또는 처음 설치)한 후 vSphere 관리자가 가장 먼저 알아차릴 수 있는 것은 vSphere 클라이언트 UI의 워크로드 관리 섹션에서 사용할 수 있는 새 Services 탭이 있다는 것입니다.
기존 네임스페이스가 있는 경우 vSphere 관리자는 VM Service라는 네임스페이스 요약의 새 섹션도 확인합니다. 다음은 이미 Tanzu Kubernetes 클러스터가 실행되고 있는 기존 네임스페이스의 예입니다.
vSphere Admin – VM Service 관리
앞에서 본 워크로드 관리 보기에는 VM Service 관리에 대한 링크가 있습니다. 여기서 vSphere 관리자는 VM Service와 관련된 두 항목, 즉 VM Classes 및 Content Libraries를 관리하고 모니터링할 수 있습니다. VM Class는 VM Service가 프로비저닝한 가상 시스템에 할당된 리소스와 이러한 리소스를 예약된 리소스(예: CPU 및 메모리) 또는 유사한 리소스가 필요한 다른 개체와 공유해야 하는지 여부를 정의합니다. vSphere 관리자는 개발자가 시스템을 오버로드하여 과도한 VM 프로비저닝으로 인해 발생할 수 있는 잠재적 충돌을 고려하여 VM 서비스를 통해 개발자가 프로비저닝한 VM에 리소스를 할당하는 방법을 신중하게 고려해야 합니다. 나중에 더 얘기해요.
컨텐츠 라이브러리는 VM 서비스에 의해 가상 시스템에 설치될 게스트 운영 체제의 이미지를 저장하는 데 사용됩니다. 이번 VM 서비스 초기 릴리스에서는 Centos 8 배포판이라는 단일 게스트 OS만 지원됩니다. VMware는 이러한 이미지를 제공합니다. VMware 클라우드 마켓플레이스에서 다운로드하여 VM 서비스 컨텐츠 라이브러리에 추가할 수 있습니다. 다음은 VM 서비스용 Centos 이미지에 대한 직접 링크입니다. 앞으로 추가 배포가 추가될 것으로 예상합니다.
동료 Myles가 여기에서 찾을 수 있는 이러한 단계에 대해 훌륭하게 기록했기 때문에 VM 클래스 또는 컨텐츠 라이브러리에 더 많은 시간을 할애하지 않을 것입니다. 맞춤형 VM 클래스를 만들고자 한다면 다른 동료 Frank는 블로그에서 프로세스에 대한 멋진 개요를 제공합니다. 또한 여기서 이용 가능한 과정에 대한 상당한 양의 공식 문서도 있다. 현재 제 환경에서는 VM Service > Manage에서 개요, VM 클래스 및 컨텐츠 라이브러리 보기가 이와 같습니다.
개요에서 사용할 수 있는 16개의 VM 클래스는 기본 제공 클래스입니다. 그러나 앞서 언급한 바와 같이 vSphere 관리자는 필요한 경우 자체 맞춤형 클래스를 생성할 수 있습니다. VM 클래스를 실행하는 3개의 VM이 하나의 제어부 노드와 두 개의 작업자 노드로 구성된 이 네임스페이스에 이미 배포된 Tanzu Kubernetes 클러스터를 참조하고 있습니다. 환경에서 Tanzu Kubernetes 클러스터를 실행하고 있지 않으면 이 필드에 0이 표시됩니다.
VM 클래스 보기에는 클래스에 대한 자세한 내용과 새 클래스를 생성하는 방법이 표시됩니다. 각 클래스에는 클래스를 편집하거나 삭제할 수 있는 관리 드롭다운이 연결되어 있습니다. 기존 클래스를 편집하지 말고 앞에서 참조한 Frank의 블로그에 따라 이름이 잘 알려진 새 VM 클래스를 생성하는 것이 좋습니다.
컨텐츠 라이브러리 보기에는 TKG 클러스터를 배포하기 위해 네임스페이스와 연결된 컨텐츠 라이브러리가 있을 수 있지만 VM 서비스 목적으로 연결된 네임스페이스가 없습니다. 또한 이 보기에서 새 내용 라이브러리를 작성할 수 있습니다.
vSphere Admin – 컨텐츠 라이브러리 생성, 이미지 추가, 네임스페이스와 연결
이 때 vSphere 관리자가 컨텐츠 라이브러리를 생성하고 여기에 Centos용 VM 서비스 이미지를 추가할 수 있습니다. 이 버전은 이 블로그를 위해 컨텐츠 라이브러리에 다운로드 및 추가한 버전입니다.
이제 vSphere 관리자가 개발자를 위해 새 네임스페이스를 생성해야 하는지 또는 개발자에게 네임스페이스가 이미 있는지 여부를 결정할 수 있습니다. 그런 다음 vSphere 관리자가 VM 서비스를 이 기존 네임스페이스에 추가하도록 결정할 수 있습니다. vSphere with Tanzu를 처음 배포할 때 vSphere 관리자는 TKG 서비스와 같은 여러 vSphere with Tanzu 서비스에서 사용할 수 있는 “워크로드” 네트워크를 결정할 책임이 있습니다. 이러한 노드를 일반적으로 워크로드 네트워크라고 하며, 이 네트워크에서는 Tanzu Kubernetes 클러스터의 노드가 프로비저닝됩니다. vSphere 관리자는 네임스페이스를 생성할 때 네임스페이스와 연결된 워크로드 네트워크를 선택할 책임이 있습니다. 이 워크로드 네트워크는 VM 서비스가 가상 시스템을 프로비저닝할 수 있는 네트워크이기도 합니다.
네임스페이스 보기 요약 탭의 VM 서비스 창을 통해 vSphere 관리자는 VM 서비스 컨텐츠 라이브러리 및 필요한 VM 클래스를 네임스페이스에 추가해야 합니다. 그러면 이 네임스페이스의 개발자가 이러한 VM 클래스 및 VM 이미지를 사용할 수 있으므로 가상 시스템을 생성할 수 있습니다. 다음은 내 네임스페이스 cormac-ns에 추가된 컨텐츠 라이브러리 및 단일 VM 클래스(best-effort-small)의 예입니다.
vSphere 관리자의 중요한 단계는 VM 서비스에서 프로비저닝된 VM의 가상 디스크를 백업하는 데 사용할 스토리지를 결정하는 것입니다. 현재 생성된 스토리지 정책이 없으므로 이 네임스페이스의 개발자가 사용할 수 있는 스토리지 클래스를 결정하는 것은 vSphere 관리자의 몫입니다. 정책은 기본 vSphere 스토리지(vSAN, vVol, VMFS 또는 NFS)에 다시 매핑됩니다. 한 가지 요구 사항은 vSphere with Tanzu 제어부 노드를 호스팅하는 모든 ESXi 호스트 간에 스토리지를 “공유”해야 한다는 것입니다.
vSphere 관리자의 또 다른 역할은 이 네임스페이스의 CPU 사용량, 메모리 사용량 및 디스크 사용량에 대한 제한이 있어야 하는지 여부를 결정하는 것입니다. VM 서비스를 통해 매우 많은 VM을 생성함으로써 이 네임스페이스의 개발자가 “시끄러운 개발자”가 되어 인프라를 잠식할 위험이 있습니까? 그렇다면 네임스페이스의 용량 및 사용량 섹션에서 제한을 설정하는 것이 중요합니다.
이 때 vSphere 관리자의 초기 설정 및 구성 작업이 완료되면 개발자가 전체 애플리케이션 개발 작업의 일부로 일부 가상 시스템을 생성하려고 한다고 가정하고 개발자에게 전달할 수 있습니다. 개발자의 요구에 맞게 맞춤형 환경을 구축하기 위해 vSphere 관리자가 상당한 양의 심의를 거쳐야 하며, 여기에는 vSphere 관리자와 DevOps 및 개발자 간의 수많은 대화가 포함될 수 있습니다.
개발자 – VM 서비스 세부 정보 쿼리
개발자가 취할 첫 번째 단계는 이미 익숙한 도구를 사용하여 환경을 쿼리하는 것일 수 있습니다. VM 서비스의 일부로 여러 kubectl 확장이 제공됩니다. 무언가를 만들기 전에 그것들부터 살펴보자. 개발자가 이미 kubectl을 사용하여 vSphere with Tanzu Supervisor Cluster에 로그인하고 액세스 권한이 있는 네임스페이스로 컨텍스트를 전환했다고 가정합니다. 먼저 노드와 컨텍스트를 살펴보겠습니다.
chogan@chogan-a01 ~ % kubectl get nodes
NAME STATUS ROLES AGE VERSION
42251e991e49bed98fd2e34b00d7b5ce Ready master 65m v1.19.1+wcp.3
4225906fc5ac685e2be389d861826958 Ready master 32m v1.19.1+wcp.3
4225bd0fcbb647ebab9b659b6813d5da Ready master 47m v1.19.1+wcp.3
chogan@chogan-a01 ~ % kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
10.202.112.152 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local
* cormac-ns 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local cormac-ns이제 개발자가 올바른 클러스터에 로그인하고 컨텍스트가 올바른 네임스페이스로 설정되었으므로 VM 서비스 옵션을 검토할 수 있습니다.
개발자 – 가상 시스템 클래스 가져오기
VM 클래스 하나를 이 네임스페이스에 할당했으므로 다음과 같이 VM 클래스를 쿼리하면 반환됩니다.
chogan@chogan-a01 ~ % kubectl get vmclass NAME CPU MEMORY AGE best-effort-small 2 4Gi 3m30s
개발자 – 가상 시스템 이미지 가져오기
VM 서비스 컨텐츠 라이브러리가 네임스페이스와 연결된 경우 개발자는 사용 가능한 이미지를 쿼리할 수 있어야 합니다. 이 네임스페이스에는 Tanzu Kubernetes 클러스터도 있으므로 TKG 서비스에도 연결된 컨텐츠 라이브러리가 있으며 해당 컨텐츠 라이브러리의 이미지도 나열됩니다. 센트VM 서비스 컨텐츠 라이브러리의 OS 이미지가 맨 위에 나열됩니다.
chogan@chogan-a01 ~ % kubectl get vmimage NAME VERSION OSTYPE FORMAT AGE centos-stream-8-vmservice-v1alpha1-1619529007339 centos8_64Guest ovf 2m33s ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd v1.16.8+vmware.1-tkg.3.60d2ffd vmwarePhoton64Guest ovf 103m ob-16466772-photon-3-k8s-v1.17.7---vmware.1-tkg.1.154236c v1.17.7+vmware.1-tkg.1.154236c vmwarePhoton64Guest ovf 103m ob-16545581-photon-3-k8s-v1.16.12---vmware.1-tkg.1.da7afe7 v1.16.12+vmware.1-tkg.1.da7afe7 vmwarePhoton64Guest ovf 103m ob-16551547-photon-3-k8s-v1.17.8---vmware.1-tkg.1.5417466 v1.17.8+vmware.1-tkg.1.5417466 vmwarePhoton64Guest ovf 103m ob-16897056-photon-3-k8s-v1.16.14---vmware.1-tkg.1.ada4837 v1.16.14+vmware.1-tkg.1.ada4837 vmwarePhoton64Guest ovf 103m ob-16924026-photon-3-k8s-v1.18.5---vmware.1-tkg.1.c40d30d v1.18.5+vmware.1-tkg.1.c40d30d vmwarePhoton64Guest ovf 103m ob-16924027-photon-3-k8s-v1.17.11---vmware.1-tkg.1.15f1e18 v1.17.11+vmware.1-tkg.1.15f1e18 vmwarePhoton64Guest ovf 103m ob-17010758-photon-3-k8s-v1.17.11---vmware.1-tkg.2.ad3d374 v1.17.11+vmware.1-tkg.2.ad3d374 vmwarePhoton64Guest ovf 103m ob-17332787-photon-3-k8s-v1.17.13---vmware.1-tkg.2.2c133ed v1.17.13+vmware.1-tkg.2.2c133ed vmwarePhoton64Guest ovf 103m ob-17419070-photon-3-k8s-v1.18.10---vmware.1-tkg.1.3a6cd48 v1.18.10+vmware.1-tkg.1.3a6cd48 vmwarePhoton64Guest ovf 103m ob-17654937-photon-3-k8s-v1.18.15---vmware.1-tkg.1.600e412 v1.18.15+vmware.1-tkg.1.600e412 vmwarePhoton64Guest ovf 103m ob-17658793-photon-3-k8s-v1.17.17---vmware.1-tkg.1.d44d45a v1.17.17+vmware.1-tkg.1.d44d45a vmwarePhoton64Guest ovf 103m ob-17660956-photon-3-k8s-v1.19.7---vmware.1-tkg.1.fc82c41 v1.19.7+vmware.1-tkg.1.fc82c41 vmwarePhoton64Guest ovf 103m ob-17861429-photon-3-k8s-v1.20.2---vmware.1-tkg.1.1d4f79a v1.20.2+vmware.1-tkg.1.1d4f79a vmwarePhoton64Guest ovf 103m
개발자 – 스토리지 클래스/스토리지 정책 가져오기
앞에서 언급한 바와 같이 vSphere 관리자가 담당하는 단계 중 하나는 네임스페이스에 스토리지 정책을 할당하는 것입니다. 그런 다음 개발자는 네임스페이스에서 스토리지 클래스로 인스턴스화된 이러한 정책을 쿼리할 수 있습니다. 이 예에서는 두 가지 정책을 사용할 수 있습니다. 하나는 vSAN 기본 정책이고 다른 하나는 r5라고 하며, RAID-5의 줄임말로 vSAN에서도 사용할 수 있는 공간 절약 정책입니다. 개발자가 r5 스토리지 클래스를 VM용 가상 디스크를 구축하는 정책으로 사용하는 방법을 잠시 살펴보겠습니다.
chogan@chogan-a01 ~ % kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE r5 csi.vsphere.vmware.com Delete Immediate true 22h vsan-default-storage-policy csi.vsphere.vmware.com Delete Immediate true 42d
개발자 – 가상 시스템 네트워크 가져오기
개발자에게 필요한 마지막 정보는 가상 시스템에 연결할 수 있는 네트워크를 확인하는 것입니다. 이전에 vSphere 관리자가 네임스페이스에 대한 워크로드 네트워크를 선택한다고 언급했습니다. 개발자는 kubectl을 통해 네트워크를 쿼리할 수 있는 수단을 가지고 있다.
chogan@chogan-a01 ~ % kubectl get network NAME AGE workload-network-1 41d
개발자 – cloud-init 사용자 지정
YAML 매니페스트에서 가상 머신을 배포하는 것은 좋게 들리지만, 이미지를 사용자 지정할 수 없다면 그다지 유용하지 않을 것입니다. VM 이미지를 쉽게 사용자 지정할 수 있도록 cloud-init을 사용합니다. 이것은 리눅스 이미지를 사용자 정의하는 가장 일반적인 메커니즘 중 하나가 되었으며, 여기에는 풍부한 설명서가 있습니다. 우리는 사용자 데이터라고 알려진 것을 제공하여 사용자 지정 작업을 간편하게 수행할 수 있는 #cloud-config를 사용하고 있습니다.
다시 말씀드리지만, Myles는 이미 자신의 블로그에 올린 글에서 이 내용을 훌륭하게 다루었기 때문에 클라우드 인트나 사용자 데이터에 대한 자세한 기록은 하지 않겠습니다. 대신 개발자가 데스크톱에서 VM으로 사용자 센토(centos)로 ssh할 수 있는 몇 가지 간단한 항목이 포함된 간단한 사용자 데이터 파일을 생성하겠습니다. 개발자는 VM에서 DHCP도 사용하도록 설정할 예정입니다. 이 VM을 배포할 워크로드 네트워크에서 사용할 수 있는 DHCP 서버가 있다고 가정합니다. 마지막 단계는 /etc/motd 파일을 업데이트하는 명령을 실행하여 개발자가 VM에 로그인할 때 메시지가 표시되도록 하는 것입니다.
#cloud-config
ssh_pwauth: yes
users:
- default
- name: centos
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1...xxxxxxxxxx
sudo: ALL=(ALL) NOPASSWD:ALL
groups: sudo
shell: /bin/bash
network:
version: 2
ethernets:
ens192:
dhcp4: true
runcmd:
- "echo -e 'Centos VM built by VM Operator on '`date` >> /etc/motd"ssh_authorized_keys 항목은 개발자 자신의 데스크톱에 있는 ~/.ssh/id_pub.rsa에서 가져옵니다. cloud-init에서 user_data를 사용하려면 base64 형식으로 렌더링해야 합니다. 실제 출력은 여기서 단락시켰지만, 보통은 많은 라인을 커버할 수 있습니다.
chogan@chogan-a01 ~% base64 < centos-user-data I2Nsb3VkLWNvbmZpZwpzc2hfcHdhdXRoO...xxxxxxxxxx
이제 이 출력은 다음에 살펴볼 VM YAML 매니페스트에 포함되어야 합니다.
개발자 – VM 매니페스트
이것은 개발자가 kubectl을 통해 가상 시스템을 배포하기 위해 생성할 수 있는 매니페스트의 예입니다. 이것은 YAML로 쓰여졌지만 또 다른 마크업 언어로 쓰여졌다. 이 시스템에는 VirtualMachine과 ConfigMap이라는 두 개의 개체가 생성됩니다. ConfigMap에는 이전 단계에서 생성한 cloud-init 사용자 지정을 위한 base64의 user-data가 저장되어 있습니다. 이제 이 매니페스트의 다른 흥미로운 분야를 살펴보겠습니다.
apiVersion: vmoperator.vmware.com/v1alpha1
kind: VirtualMachine
metadata:
name: centos-vm
namespace: cormac-ns
spec:
networkInterfaces:
- networkName: "workload-network-1"
networkType: vsphere-distributed
className: best-effort-small
imageName: centos-stream-8-vmservice-v1alpha1-1619529007339
powerState: poweredOn
storageClass: r5
vmMetadata:
configMapName: centos-vm-cfm
transport: OvfEnv
---
apiVersion: v1
kind: ConfigMap
metadata:
name: centos-vm-cfm
namespace: cormac-ns
data:
user-data: |
I2Nsb3VkLWNvbmZpZwpzc2hfcHdhdXRoO...xxxxxxxxxx+IC9ldGMvbW90ZCIK
hostname: centos-vm네임스페이스부터 시작하겠습니다. 이 가상 시스템은 cormac-ns 네임스페이스에서 프로비저닝되고 있습니다. 개발자는 몇 개의 네임스페이스에만 액세스할 수 있으며, 한 개만 액세스할 수 있습니다. 그들은 이것을 적절히 설정해야 할 것이다. 사양 섹션에서 네트워킹에는 네트워크 이름, workload-network-1 및 네트워크 유형(vsphere-distributed)에 대한 항목이 있습니다. 이 배포에는 NSX-T가 없습니다. 소개에서 언급한 바와 같이 이 환경은 로드 밸런서에 NSX ALB를 사용하는 vSphere Distributed Switch 환경입니다.
이미 이 네임스페이스에 추가된 VM 클래스는 best-effort-small이며 컨텐츠 라이브러리의 유일한 이미지는 Centos 8 이미지였습니다. 이 두 항목은 모두 매니페스트에 추가됩니다. 스토리지 클래스는 vSphere 관리자가 네임스페이스에 추가한 스토리지 정책을 참조합니다. 이 예에서는 개발자가 vSAN용 RAID-5 정책인 r5 사용을 결정했습니다. 스토리지 클래스를 구성하는 네임스페이스에 스토리지 정책을 할당하는 것은 앞에서 설명한 것처럼 vSphere 관리자가 담당했습니다. user-data는 이전 단계에서 생성된 base64 인코딩 데이터입니다. 마지막으로 흥미로운 부분은 ConfigMap의 hostname입니다. 개발자가 VM을 배포할 수 있는 모든 것이 갖추어져 있습니다.
개발자 – 배포 및 테스트
먼저 VM 및 ConfigMap과 함께 매니페스트를 배포하겠습니다.
chogan@chogan-a01 ~% kubectl apply -f centos-vm.yaml virtualmachine.vmoperator.vmware.com/centos-vm created configmap/centos-vm-cfm created
개발자는 곧 kubectl에서 가상 시스템을 쿼리할 수 있어야 합니다. 이미 Tanzu Kubernetes 클러스터를 배포했으므로 이러한 VM도 나열됩니다.
chogan@chogan-a01 ~% kubectl get vm NAME POWERSTATE AGE centos-vm poweredOn 4m42s tkg-cluster-1-19-7-control-plane-psktw poweredOn 42d tkg-cluster-1-19-7-workers-x28f7-746966b6f7-jjcrn poweredOn 42d tkg-cluster-1-19-7-workers-x28f7-746966b6f7-zblpw poweredOn 42d
다음 단계는 새로 프로비저닝된 VM으로 ssh하는 것입니다. 워크로드 네트워크의 DHCP 서버에 의해 성공적으로 IP 주소를 할당받았다고 가정하는 것입니다. VM의 IP 주소는 몇 가지 다른 방법으로 검색할 수 있습니다. 여기 그런 방법이 하나 있다.
chogan@chogan-a01 ~% kubectl get vm centos-vm -o jsonpath='{.status.vmIp}'
10.202.112.174%개발자는 해당 IP 주소에 대해 SSH할 수 있어야 하며, 개발자의 공개 키를 사용자 데이터의 일부로 제공했기 때문에 암호를 제공할 필요가 없습니다. 다른 사항으로는 업데이트된 /etc/motd에서 로그인 메시지가 표시되고, 이 사용자가 sudo를 수행할 수 있어야 하며, 호스트 이름을 centos-vm으로 설정해야 합니다. 이게 효과가 있는지 확인해 봅시다.
chogan@chogan-a01 ~% ssh centos@10.202.112.169 The authenticity of host '10.202.112.169 (10.202.112.169)' can't be established. ECDSA key fingerprint is SHA256:80Mx2li6CNDouvD0vpuSmrEbSdjOgJz1QleE71oddb0. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.202.112.169' (ECDSA) to the list of known hosts. Centos VM built by VM Operator on Wed May 5 06:14:04 EDT 2021 [centos@centos-vm ~]$ sudo su - Last login: Tue Feb 23 16:03:20 EST 2021 on tty1 [root@centos-vm ~]# hostname centos-vm [root@centos-vm ~]#
모든 것이 예상대로 돌아가고 있는 것 같다. 개발자는 상당히 행복해야 합니다. vSphere with Tanzu의 멋진 기능이라는 데 동의하실 것 같습니다.
vSphere 관리 – 관리 및 모니터링
이제 vSphere 관리자의 역할로 돌아가 보겠습니다. vSphere 관리자는 리소스 사용량을 포함하여 인프라를 관리하고 모니터링할 책임이 분명하며, 개발자가 인프라를 어떻게 사용하고 있는지(또는 잘못 사용하고 있는지) 알고 싶어할 것입니다. 가장 먼저 강조해야 할 사항은 vSphere 관리자가 개발자의 네임스페이스를 완벽하게 파악하고 vSphere 클라이언트 UI를 통해 VM의 리소스를 확인할 수 있다는 점입니다(여기에 표시됨).
이 작업은 Developer Managed VM이며, 전원 켜기/끄기, 마이그레이션 등 VM과 관련된 대부분의 작업은 vSphere 클라이언트에서 금지됩니다. VM의 라이프사이클은 개발자가 관리합니다.
또한 워크로드 관리 관점에서 vSphere 관리자가 VM 클래스, 컨텐츠 라이브러리 및 VM도 볼 수 있습니다. 이 필드는 이제 개발자가 클러스터에서 이 기능을 사용하는 방식을 반영하여 업데이트되었습니다.
이제 이 게시물을 통해 vSphere with Tanzu가 어떻게 발전하고 있으며 VM Service가 개발자가 VM 및 컨테이너 워크로드로 구성된 애플리케이션을 생성할 수 있는 방법을 확장할 수 있는 방법에 대해 자세히 알아보았기를 바랍니다.
