클러스터에 Kubernetes 기반 앱 배치
Kubernetes 기술을 사용하여 IBM Cloud® Kubernetes Service 에 컨테이너화된 앱을 배포합니다. 사용자에게 서비스 중단 없이 롤링 업데이트 및 롤백을 수행하세요.
구성 모범 사례 가이드에서 구성 파일 생성에 대해 자세히 알아보세요.
Kubernetes 대시보드 실행
Kubernetes 대시보드에 액세스하여 IBM Cloud 콘솔 또는 CLI를 통해 클러스터 및 워커 노드 정보를 확인합니다.
시작하기 전에 적절한 액세스 권한이 있는지 확인하세요. 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
IBM Cloud 콘솔에서 Kubernetes 대시보드 실행
- IBM Cloud 콘솔에 로그인하십시오.
- 메뉴 표시줄에서 사용할 계정을 선택하십시오.
- 메뉴에서
클릭하고, 컨테이너 > 클러스터를 클릭합니다.
- 클러스터 페이지에서 액세스하려는 클러스터를 클릭하십시오.
- 클러스터 세부사항 페이지에서 Kubernetes 대시보드 단추를 클릭하십시오.
CLI에서 Kubernetes 대시보드 실행
CLI 방식을 사용하면 자동화 및 CI/CD 통합이 가능합니다. 시작하기 전에 CLI를 설치하세요.
-
Kubernetes 자격증을 취득하세요.
kubectl config view -o jsonpath='{.users[0].user.auth-provider.config.id-token}' -
출력에서 아이디 토큰 값을 복사합니다.
-
프록시를 시작합니다.
kubectl proxy출력 예
Starting to serve on 127.0.0.1:8001 -
대시보드에 로그인하십시오.
- 브라우저에서 다음 주소 URL 로 이동하세요:
http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/ ``` 2. 로그인 페이지에서 **토큰** 인증 방법을 선택합니다. 3. **id-token** 값을 **‘Token’** 필드에 붙여넣고 **‘SIGN IN’을** 클릭하세요.
proxy 명령을 종료하려면 CTRL+C 을 사용합니다. kubectl proxy 을 다시 실행하여 대시보드를 다시 시작합니다.
Kubernetes 대시보드를 사용하여 앱 배치
대시보드에서 구성 세부 정보를 입력하거나 YAML 파일을 업로드하여 앱을 배포합니다.
시작하기 전에 대시보드를 열고 서비스 액세스 권한이 있는지 확인합니다. 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
앱을 배포하려면
-
+ 작성을 클릭하십시오.
-
배포 방법을 선택합니다:
- ‘앱 세부 정보 지정’을 선택하고 세부 정보를 입력하세요.
- ‘YAML 또는 JSON 파일 업로드’를 선택하여 앱 구성 파일을 업로드하세요.
-
배포를 클릭하여 앱이 성공적으로 배포되었는지 확인합니다.
CLI로 앱 배치
CLI 방식은 정밀한 제어를 제공하고 자동화를 가능하게 합니다. 앱의 리소스를 정의하고 버전을 관리할 수 있는 구성 파일을 만들게 됩니다.
시작하기 전에 CLI를 설치하고 서비스 액세스 권한이 있는지 확인합니다. 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
앱을 배포하려면
레이블을 사용하여 특정 작업자 노드에 앱 배치
앱을 배치할 때 앱 팟(Pod)은 클러스터의 여러 작업자 노드에 무작위로 배치됩니다. 일부 경우에는 사용자가 앱 팟(Pod)이 배치되는 작업자 노드를 제한하려고 할 수 있습니다. 예를 들면, 특정 작업자 풀의 작업자 노드는 베어메탈 머신에 있으므로 이러한 작업자 노드에만 앱 팟(Pod)을 배치하려 할 수 있습니다. 앱 팟(Pod)이 배치되어야 하는 작업자 노드를 지정하려면 앱 배치에 친화성 규칙을 추가하십시오.
시작하기 전에
- 계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
- 선택사항: 앱을 실행할 작업자 풀의 레이블을 설정하십시오.
특정 작업자 노드에 앱을 배치하려면 다음을 수행하십시오.
-
앱 팟(Pod)이 배치될 작업자 풀의 ID를 가져오십시오.
ibmcloud ks worker-pool ls --cluster CLUSTER_NAME_OR_ID -
작업자 풀에 있는 작업자 노드를 나열하고 사설 IP 주소 중 하나를 기록하십시오.
ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID -
작업자 노드에 대해 설명하십시오. 레이블 출력에서 작업자 풀 ID 레이블(
ibm-cloud.kubernetes.io/worker-pool-id)을 기록해 두십시오.이 주제의 단계는 작업자 풀 ID를 사용하여 해당 작업자 풀 내의 작업자 노드에만 앱 팟(Pod)을 배치합니다. 다른 레이블을 사용하여 특정 작업자 노드에 앱 팟(Pod)을 배치하려면 대신 이 레이블을 기록해 두십시오. 예를 들어, 특정 사설 VLAN에만 앱 팟(Pod)을 배치하려면
privateVLAN=레이블을 사용하십시오.kubectl describe node <worker_node_private_IP>출력 예
NAME: 10.xxx.xx.xxx Roles: <none> Labels: arch=amd64 beta.kubernetes.io/arch=amd64 beta.kubernetes.io/instance-type=b3c.4x16.encrypted beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=us-south failure-domain.beta.kubernetes.io/zone=dal10 ibm-cloud.kubernetes.io/encrypted-docker-data=true ibm-cloud.kubernetes.io/ha-worker=true ibm-cloud.kubernetes.io/iaas-provider=softlayer ibm-cloud.kubernetes.io/machine-type=b3c.4x16.encrypted ibm-cloud.kubernetes.io/sgx-enabled=false ibm-cloud.kubernetes.io/worker-pool-id=00a11aa1a11aa11a1111a1111aaa11aa-11a11a ibm-cloud.kubernetes.io/worker-version=1.36_1534 kubernetes.io/hostname=10.xxx.xx.xxx privateVLAN=1234567 publicVLAN=7654321 Annotations: node.alpha.kubernetes.io/ttl=0 ... -
앱 배포에 워커 풀 ID 레이블에 대한 어피니티 규칙을 추가합니다.
YAML 예제
apiVersion: apps/v1 kind: Deployment metadata: name: with-node-affinity spec: template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: ibm-cloud.kubernetes.io/worker-pool-id operator: In values: - <worker_pool_ID> ...예제 YAML의 affinity 섹션에서
ibm-cloud.kubernetes.io/worker-pool-id는key이고<worker_pool_ID>는value입니다. -
업데이트된 배치 구성 파일을 적용하십시오.
kubectl apply -f with-node-affinity.yaml -
앱 팟(Pod)이 올바른 작업자 노드에 배치되었는지 확인하십시오.
- 클러스터 내의 팟(Pod)을 나열하십시오.
kubectl get pods -o wide ``` 출력 예 ```sh {: screen} NAME READY STATUS RESTARTS AGE IP NODE cf-py-d7b7d94db-vp8pq 1/1 Running 0 15d 172.30.xxx.xxx 10.176.48.78 ``` 2. 출력에서 앱의 팟(Pod)을 식별하십시오. 해당 팟(Pod)이 있는 작업자 노드의 **NODE** 사설 IP 주소를 기록해 두십시오. 이전 예제 출력에서 앱 팟(Pod) `cf-py-d7b7d94db-vp8pq`는 IP 주소 `10.xxx.xx.xxx`의 작업자 노드에 있습니다. 3. 앱 배치에서 지정한 작업자 풀의 작업자 노드를 나열하십시오. ```sh {: pre} ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID ``` 출력 예 ```sh {: screen} ID Public IP Private IP Machine Type State Status Zone Version kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w7 169.xx.xxx.xxx 10.176.48.78 b3c.4x16 normal Ready dal10 1.8.6_1504 kube-dal10-crb20b637238bb471f8b4b8b881bbb4962-w8 169.xx.xxx.xxx 10.176.48.83 b3c.4x16 normal Ready dal10 1.8.6_1504 kube-dal12-crb20b637238bb471f8b4b8b881bbb4962-w9 169.xx.xxx.xxx 10.176.48.69 b3c.4x16 normal Ready dal12 1.8.6_1504 ``` 다른 요인을 기반으로 친화성 규칙을 작성한 경우에는 해당 값을 대신 가져오십시오. 예를 들어, 앱 팟(Pod)이 특정 VLAN의 작업자 노드에 배치되었는지 확인하려면 `ibmcloud ks worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID`를 실행하여 작업자 노드가 있는 VLAN을 보십시오. {: tip} 4. 출력에서, 이전 단계에서 식별한 사설 IP 주소의 작업자 노드가 이 작업자 풀에 배치되었는지 확인하십시오.
NVIDIA GPU 머신에 앱 배포하기
GPU 머신 유형이 있는 경우 AI, 머신 러닝, 추론 등과 같은 컴퓨팅 집약적 워크로드에 필요한 처리 시간을 가속화할 수 있습니다.
Kubernetes 버전부터 시작되는 중요한 드라이버 변경 사항 1.36 IBM Cloud Kubernetes Service 는 더 이상 버전 부터 시작하는 GPU를 사용하는 워커 노드에 GPU 드라이버를 설치하지 않습니다. Kubernetes 1.36 NVIDIA 버전 1.36 이상의 클러스터에서 GPU 워크로드를 실행하려는 경우, 자체 워커 노드에서 GPU 드라이버 설치 및 수명 주기를 관리해야 합니다. 버전 1.35 이하를 실행하는 클러스터의 경우 IBM-제공된 GPU 드라이버를 계속 사용할 수 있습니다. 마이그레이션 지침은 자체 관리형 NVIDIA GPU 드라이버로 마이그레이션하기를 참조하세요.
다음 단계에서는 GPU가 필요한 워크로드를 배치하는 방법에 대해 알아봅니다. 하지만 GPU와 CPU 모두에서 워크로드를 처리할 필요가 없는 앱도 배포할 수 있습니다.
이 Kubernetes 데모를 통해 머신 러닝 TensorFlow 프레임워크와 같은 수학적으로 집약적인 워크로드를 시도해 볼 수도 있습니다.
전제조건
시작하기 전에
-
GPU 특성을 사용하는 클러스터 또는 작업자 풀을 작성하십시오. 베어메탈 머신의 설정을 완료하는 데는 1일 이상의 영업일이 소요될 수 있다는 점에 유의하십시오. 사용 가능한 특징 목록은 다음 링크를 참조하십시오.
-
클러스터에서 Kubernetes 리소스 관련 작업을 수행할 수 있도록 적절한 Kubernetes RBAC 역할을 부여하는 서비스 액세스 역할이 지정되어 있는지 확인하십시오.
Kubernetes 버전 1.36 이상용: NVIDIA GPU 드라이버 스택을 직접 설치 및 관리해야 합니다. IBM Cloud Kubernetes Service 는 더 이상 워커 노드에 사전 설치된 GPU 드라이버를 제공하지 않습니다. NVIDIA GPU 운영자 설치 가이드에 따라 필요한 구성 요소를 설치하세요:
- NVIDIA 커널 드라이버
- 컨테이너 런타임 구성 요소(예: nvidia-container-toolkit)
- Kubernetes 장치 플러그인
드라이버가 설치될 때까지 GPU를 요청하는 파드는 Pending 상태로 유지됩니다. 노드에서 호환되는 드라이버를 사용할 수 있게 되면 Running 로 자동 전환됩니다.
Kubernetes 버전 1.35 및 이전 버전: IBM-제공된 GPU 드라이버는 GPU 워커 노드에 자동으로 설치됩니다. 추가 드라이버 설치가 필요하지 않습니다.
워크로드 배치
-
YAML 파일을 작성하십시오. 이 예시에서는 ‘
Job’ YAML이 명령어가 완료되고 정상적으로 종료될 때까지 실행되는 단기 포드를 생성하여 배치 방식의 워크로드를 관리합니다.GPU 워크로드의 경우, 작업 YAML에서 ‘
resources: limits: nvidia.com/gpu’ 필드를 반드시 지정해야 합니다.apiVersion: batch/v1 kind: Job metadata: name: nvidia-devicequery labels: name: nvidia-devicequery spec: template: metadata: labels: name: nvidia-devicequery spec: containers: - name: nvidia-devicequery image: nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04 imagePullPolicy: IfNotPresent resources: limits: nvidia.com/gpu: 2 restartPolicy: NeverYAML 컴포넌트 이해하기 컴포넌트 설명 메타데이터 및 레이블 이름 작업의 이름과 레이블을 입력하고 파일의 메타데이터와 spec template메타데이터에 동일한 이름을 사용하십시오. 예를 들어,nvidia-devicequery입니다.containers.image컨테이너가 실행 중인 인스턴스인 이미지를 제공하십시오. 이 예제에서 값은 DockerHub CUDA 디바이스 조회 이미지를 사용하도록 설정됩니다. nvcr.io/nvidia/k8s/cuda-sample:devicequery-cuda11.7.1-ubuntu20.04.containers.imagePullPolicy이미지가 현재 작업자 노드에 있지 않은 경우에만 새 이미지를 가져오려면 IfNotPresent를 지정하십시오.resources.limitsGPU 머신의 경우 리소스 한계를 지정해야 합니다. Kubernetes 장치 플러그인은 기본 리소스 요청량을 제한값에 맞게 설정합니다.
- 키를
nvidia.com/gpu로 지정해야 합니다. - 요청하는 GPU의 개수를 정수로 입력하십시오(예:
2). 컨테이너 팟(Pod)은 GPU를 공유하지 않으며 GPU가 초과 커미트될 수 없습니다. 예를 들어, 1개의mg1c.16x128머신만 있는 경우 해당 머신에는 2개의 GPU만 있으며 최대2를 지정할 수 있습니다.
- 키를
-
YAML 파일을 적용하십시오. 예를 들어, 다음과 같습니다.
kubectl apply -f nvidia-devicequery.yaml -
nvidia-devicequery레이블을 기준으로 포드를 필터링하여 작업 포드를 확인하세요. STATUS가 Completed인지 확인하십시오.kubectl get pod -A -l 'name in (nvidia-devicequery)'출력 예
NAME READY STATUS RESTARTS AGE nvidia-devicequery-ppkd4 0/1 Completed 0 36s -
GPU 디바이스 플러그인이 팟(Pod)을 스케줄한 방법을 알 수 있도록 팟(Pod)에 대해 설명하십시오.
Limits및Requests필드에서 사용자가 지정한 리소스 한계가 디바이스 플러그인에서 자동으로 설정한 요청과 일치하는지 확인하십시오.- 이벤트에서 팟(Pod)이 GPU 작업자 노드에 지정되었는지 확인하십시오.
kubectl describe pod nvidia-devicequery-ppkd4 ``` 출력 예 ```sh {: screen} NAME: nvidia-devicequery-ppkd4 Namespace: default ... Limits: nvidia.com/gpu: 1 Requests: nvidia.com/gpu: 1 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 1m default-scheduler Successfully assigned nvidia-devicequery-ppkd4 to 10.xxx.xx.xxx ... ``` -
로그를 확인하여 작업이 GPU를 사용하여 해당 워크로드를 계산했는지 확인할 수 있습니다.
kubectl logs nvidia-devicequery-ppkd4출력 예
/cuda-samples/sample Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 1 CUDA Capable device(s) Device 0: "Tesla P100-PCIE-16GB" CUDA Driver Version / Runtime Version 11.4 / 11.7 CUDA Capability Major/Minor version number: 6.0 Total amount of global memory: 16281 MBytes (17071734784 bytes) (056) Multiprocessors, (064) CUDA Cores/MP: 3584 CUDA Cores GPU Max Clock rate: 1329 MHz (1.33 GHz) Memory Clock rate: 715 Mhz Memory Bus Width: 4096-bit L2 Cache Size: 4194304 bytes Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384) Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total shared memory per multiprocessor: 65536 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 2048 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 2 copy engine(s) Run time limit on kernels: No Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Enabled Device supports Unified Addressing (UVA): Yes Device supports Managed Memory: Yes Device supports Compute Preemption: Yes Supports Cooperative Kernel Launch: Yes Supports MultiDevice Co-op Kernel Launch: Yes Device PCI Domain ID / Bus ID / location ID: 0 / 175 / 0 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 11.4, CUDA Runtime Version = 11.7, NumDevs = 1 Result = PASS이 예제에서 GPU가 작업자 노드에서 스케줄되었으므로 GPU가 작업을 실행하는 데 사용되었습니다. 한계가 2로 설정되면 2개의 GPU만 표시됩니다.
테스트용 GPU 워크로드를 배포했으니, 이제 GPU 처리에 의존하는 도구(예: IBM Maximo Visual Inspection.
자체 관리형 NVIDIA GPU 드라이버로 마이그레이션하기
Kubernetes 버전 1.36 으로 업그레이드할 때 IBM-제공 GPU 드라이버에서 자체 관리 드라이버로 마이그레이션하는 방법에 대한 자세한 지침은 Kubernetes 1.36 용 자체 관리 NVIDIA GPU 드라이버로 마이그레이션하기 를 참조하십시오.