이 랩에서는 Minikube 를 사용하여 로컬 Kubernetes 클러스터를 시작하고, 샘플 NGINX 애플리케이션을 배포한 다음, 변화하는 요구 사항에 맞춰 스케일링하는 방법을 배우게 됩니다. 여러 Pod 간의 로드 밸런싱을 관찰하고, 클러스터 이벤트를 모니터링하며, 향후 자동 스케일링을 위한 Horizontal Pod Autoscaler (HPA) 에 대한 간략한 소개를 받게 됩니다. 이 랩은 Kubernetes 스케일링 및 로드 밸런싱을 이해하기 위한 포괄적이고 실질적인 경험을 제공하는 것을 목표로 합니다.
이 단계에서는 Minikube 를 사용하여 로컬 Kubernetes 클러스터를 시작하고 확인하는 방법을 배우게 됩니다. 이는 Kubernetes 환경에서 컨테이너화된 애플리케이션을 배포하고 관리하기 위한 필수적인 첫 번째 단계입니다.
먼저, Minikube 클러스터를 시작합니다:
minikube start예시 출력:
😄 minikube v1.29.0 on Ubuntu 22.04
✨ Automatically selected the docker driver
📌 Using Docker driver with root permissions
🔥 Creating kubernetes in kubernetes cluster
🔄 Restarting existing kubernetes cluster
🐳 Preparing Kubernetes v1.26.1 on Docker 20.10.23 ...
🚀 Launching Kubernetes ...
🌟 Enabling addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace여러 명령을 사용하여 클러스터 상태를 확인합니다:
minikube status
kubectl get nodesminikube status의 예시 출력:
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configuredkubectl get nodes의 예시 출력:
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.26.1이러한 명령은 다음을 확인합니다:
이 단계에서는 단일 레플리카 (replica) 를 가진 Kubernetes Deployment 를 사용하여 간단한 웹 애플리케이션을 배포하는 방법을 배우게 됩니다. NGINX 웹 서버용 YAML 매니페스트를 생성하고 이를 Minikube 클러스터에 적용할 것입니다. 애플리케이션을 배포하는 방법을 이해하는 것은 Kubernetes 를 사용하는 데 기본이 됩니다.
먼저, Kubernetes 매니페스트를 위한 디렉토리를 생성합니다:
mkdir -p ~/project/k8s-manifests
cd ~/project/k8s-manifests배포를 위한 새로운 YAML 파일을 생성합니다:
nano nginx-deployment.yaml다음 배포 구성을 추가합니다:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80파일을 저장합니다 (Ctrl+X, Y, Enter).
YAML 구성 설명:
apiVersion: apps/v1: Deployment 에 대한 API 버전을 지정합니다.kind: Deployment: 이것이 복제된 애플리케이션을 관리하는 데 사용되는 Deployment 객체임을 나타냅니다.metadata: Deployment 에 대한 메타데이터를 포함합니다.
name: nginx-deployment: 배포의 이름입니다.labels: app: nginx: 이 배포를 식별하는 데 사용되는 레이블입니다.spec: 배포 사양을 포함합니다.
replicas: 1: 원하는 Pod 인스턴스 수 (레플리카) 입니다. 이 초기 배포에서는 하나의 레플리카만 있습니다.selector: 배포가 관리할 Pod 를 선택하는 방법을 정의합니다.
matchLabels: app: nginx: app: nginx 레이블이 있는 Pod 는 이 배포에 의해 관리됩니다.template: Pod 템플릿입니다. 배포가 생성하는 Pod 의 구성을 지정합니다.
metadata.labels: app: nginx: 이 배포에 의해 관리되는 Pod 에 적용되는 레이블입니다.spec.containers: Pod 의 컨테이너를 정의합니다.
name: nginx: 컨테이너의 이름입니다.image: nginx:latest: 컨테이너에 대한 Docker 이미지 (최신 NGINX 이미지 사용).ports: containerPort: 80: 컨테이너에서 포트 80 을 노출합니다.Kubernetes 클러스터에 배포를 적용합니다:
kubectl apply -f nginx-deployment.yaml예시 출력:
deployment.apps/nginx-deployment created배포 상태를 확인합니다:
kubectl get deployments
kubectl get podskubectl get deployments의 예시 출력:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 1/1 1 1 30skubectl get pods의 예시 출력:
NAME READY STATUS RESTARTS AGE
nginx-deployment-xxx-yyy 1/1 Running 0 30s이 배포에 대한 주요 사항:
app: nginx 레이블을 가지고 있습니다.배포 세부 정보를 검사합니다:
kubectl describe deployment nginx-deployment예시 출력은 배포 구성, 이벤트 및 현재 상태를 보여줍니다.
이 단계에서는 더 많은 트래픽을 처리하도록 애플리케이션을 확장하는 방법을 배우게 됩니다. 실제 환경에서 애플리케이션이 더 인기를 얻게 되면 하나의 레플리카로는 부하를 처리하기에 충분하지 않을 수 있습니다. 이를 해결하기 위해 Kubernetes 는 Pod 인스턴스 (레플리카) 수를 늘려 애플리케이션을 쉽게 확장할 수 있도록 합니다.
확장하기 전에 여러 레플리카가 필요한 이유에 대해 간략하게 논의해 보겠습니다. 애플리케이션의 단일 레플리카는 특정 양의 동시 요청만 처리할 수 있습니다. 트래픽이 해당 용량을 초과하면 애플리케이션이 느려지거나 응답하지 않을 수 있습니다. 여러 레플리카를 사용하면 부하가 서로 다른 Pod 인스턴스에 분산되어 애플리케이션이 응답성을 유지하고 사용 가능하도록 보장합니다. 이 개념은 확장 가능한 애플리케이션을 만드는 데 필수적입니다.
이제 YAML 매니페스트의 replicas 필드를 수정하고 kubectl scale 명령을 사용하여 Kubernetes 배포를 확장하는 방법을 배우게 됩니다.
이전에 생성된 배포 매니페스트를 엽니다:
nano ~/project/k8s-manifests/nginx-deployment.yamlreplicas 필드를 1 에서 3 으로 수정합니다:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3 ## 1 에서 3 으로 변경됨
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80파일을 저장합니다 (Ctrl+X, Y, Enter).
업데이트된 배포를 적용합니다:
kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml예시 출력:
deployment.apps/nginx-deployment configured확장된 배포를 확인합니다:
kubectl get deployments
kubectl get podskubectl get deployments의 예시 출력:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 5mkubectl get pods의 예시 출력:
NAME READY STATUS RESTARTS AGE
nginx-deployment-xxx-yyy 1/1 Running 0 5m
nginx-deployment-xxx-zzz 1/1 Running 0 30s
nginx-deployment-xxx-www 1/1 Running 0 30skubectl scale을 사용한 대체 확장 방법:
kubectl scale deployment nginx-deployment --replicas=4예시 출력:
deployment.apps/nginx-deployment scaled새로운 레플리카 수를 확인합니다:
kubectl get deployments
kubectl get pods확장에 대한 주요 사항:
replicas를 수정하거나 kubectl scale 명령을 사용합니다.kubectl apply를 사용하여 배포를 업데이트합니다.이 단계에서는 Service 를 생성하고 여러 Pod 에서 응답을 확인하여 Kubernetes 에서 로드 밸런싱을 검증하는 방법을 배우게 됩니다. 로드 밸런싱은 여러 레플리카에 트래픽을 분산하여 단일 Pod 에 과부하가 걸리지 않도록 하는 데 중요합니다. Kubernetes Service 가 이 프로세스를 자동으로 처리합니다.
배포를 노출하기 위해 서비스를 생성합니다:
nano ~/project/k8s-manifests/nginx-service.yaml다음 서비스 구성을 추가합니다:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
type: ClusterIP
ports:
- port: 80
targetPort: 80파일을 저장합니다 (Ctrl+X, Y, Enter).
YAML 구성 설명:
apiVersion: v1: Service 에 대한 API 버전을 지정합니다.kind: Service: 이것이 Service 객체임을 나타냅니다.metadata: Service 에 대한 메타데이터를 포함합니다.
name: nginx-service: Service 의 이름입니다.spec: 서비스 사양을 포함합니다.
selector: 이 서비스가 트래픽을 라우팅할 Pod 를 정의합니다.
app: nginx: 이전 단계에서 생성된 Pod 와 일치하는 app: nginx 레이블이 있는 Pod 를 선택합니다.type: ClusterIP: 내부 통신에 사용되는 클러스터 IP 주소를 가진 내부 서비스를 생성합니다. 이 서비스 유형은 Kubernetes 클러스터 내에서만 접근할 수 있습니다.ports: 서비스가 트래픽을 매핑하는 방법을 정의합니다.
port: 80: 서비스가 노출하는 포트입니다.targetPort: 80: 컨테이너 내부의 애플리케이션이 수신 대기하는 포트입니다.서비스를 적용합니다:
kubectl apply -f ~/project/k8s-manifests/nginx-service.yaml예시 출력:
service/nginx-service created서비스를 확인합니다:
kubectl get services예시 출력:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 30m
nginx-service ClusterIP 10.96.xxx.xxx <none> 80/TCP 30s이제 로드 밸런싱을 실제로 검증하기 위해 임시 Pod 를 생성하고 서비스에 여러 요청을 보낼 것입니다. 이를 통해 요청이 서로 다른 NGINX Pod 에 분산되는 것을 확인할 수 있습니다.
로드 밸런싱을 테스트하기 위해 임시 Pod 를 생성합니다:
kubectl run curl-test --image=curlimages/curl --rm -it -- sh이 명령은 다음을 수행합니다:
kubectl run curl-test: curl-test라는 새 Pod 를 생성합니다.--image=curlimages/curl: curl이 설치된 Docker 이미지를 사용합니다.--rm: 완료되면 Pod 를 자동으로 제거합니다.-it: 가상 TTY 를 할당하고 stdin 을 열어 둡니다.-- sh: Pod 에서 셸 세션을 시작합니다.임시 Pod 내부에서 여러 요청을 실행합니다:
for i in $(seq 1 10); do curl -s nginx-service | grep -q "Welcome to nginx!" && echo "Welcome to nginx - Request $i"; done이 루프는 nginx-service에 10 개의 요청을 보냅니다. 각 요청은 사용 가능한 NGINX Pod 중 하나로 라우팅되어야 합니다. 출력은 각 성공적인 요청에 대해 Welcome to nginx - Request $i를 인쇄합니다.
예시 출력:
Welcome to nginx - Request 1
Welcome to nginx - Request 2
Welcome to nginx - Request 3
...임시 Pod 를 종료합니다:
exit로드 밸런싱에 대한 주요 사항:
ClusterIP 서비스 유형은 내부 로드 밸런싱을 제공합니다.이 단계에서는 kubectl scale 명령을 사용하여 변화하는 애플리케이션 수요를 충족하기 위해 Kubernetes 배포 규모를 동적으로 조정하는 연습을 할 것입니다. 이 단계는 YAML 파일을 직접 수정하지 않고 실행 중인 레플리카 수를 조정하는 실용적인 측면을 강조하며, 트래픽 급증에 대응하기 위한 신속한 조정에 유용할 수 있습니다.
먼저, 현재 배포 상태를 확인합니다:
kubectl get deployments예시 출력:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 4/4 4 4 45mkubectl 명령을 사용하여 배포 규모를 조정합니다:
kubectl scale deployment nginx-deployment --replicas=5예시 출력:
deployment.apps/nginx-deployment scaled새로운 레플리카 수를 확인합니다:
kubectl get deployments
kubectl get pods배포에 대한 예시 출력:
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 5/5 5 5 46mPod 에 대한 예시 출력:
NAME READY STATUS RESTARTS AGE
nginx-deployment-xxx-yyy 1/1 Running 0 1m
nginx-deployment-xxx-zzz 1/1 Running 0 1m
nginx-deployment-xxx-www 1/1 Running 0 1m
nginx-deployment-xxx-aaa 1/1 Running 0 1m
nginx-deployment-xxx-bbb 1/1 Running 0 1m이제, 지속적인 스케일링을 위해 배포 YAML 을 업데이트합니다:
nano ~/project/k8s-manifests/nginx-deployment.yamlreplicas 필드를 수정합니다:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 5 ## Updated from previous value
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80업데이트된 구성을 적용합니다:
kubectl apply -f ~/project/k8s-manifests/nginx-deployment.yaml예시 출력:
deployment.apps/nginx-deployment configured수요 감소를 위해 스케일 다운을 시뮬레이션합니다:
kubectl scale deployment nginx-deployment --replicas=2예시 출력:
deployment.apps/nginx-deployment scaled감소된 레플리카 수를 확인합니다:
kubectl get deployments
kubectl get pods스케일링에 대한 주요 사항:
kubectl scale을 사용합니다.이 단계에서는 다양한 kubectl 명령을 사용하여 Kubernetes 배포 및 Pod 를 모니터링하여 변경 사항을 추적하고, 문제를 해결하며, 애플리케이션의 수명 주기를 이해하는 방법을 배우게 됩니다. 관찰 가능성은 애플리케이션의 상태와 성능을 보장하는 데 매우 중요합니다.
자세한 정보를 얻기 위해 현재 배포를 설명합니다:
kubectl describe deployment nginx-deployment예시 출력:
Name: nginx-deployment
Namespace: default
CreationTimestamp: [timestamp]
Labels: app=nginx
Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:latest
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-xxx (2/2 replicas created)
Events: <some deployment events>개별 Pod 에 대한 자세한 정보를 얻습니다:
kubectl describe pods -l app=nginx예시 출력은 각 Pod 에 대한 세부 정보를 표시합니다. 여기에는 다음이 포함됩니다:
클러스터 전체 이벤트를 봅니다:
kubectl get events예시 출력:
LAST SEEN TYPE REASON OBJECT MESSAGE
5m Normal Scheduled pod/nginx-deployment-xxx-yyy Successfully assigned default/nginx-deployment-xxx-yyy to minikube
5m Normal Pulled pod/nginx-deployment-xxx-yyy Container image "nginx:latest" already present on machine
5m Normal Created pod/nginx-deployment-xxx-yyy Created container nginx
5m Normal Started pod/nginx-deployment-xxx-yyy Started container nginx특정 리소스에 대한 이벤트를 필터링합니다:
kubectl get events --field-selector involvedObject.kind=Deployment예시 출력은 배포 관련 이벤트만 표시합니다.
Pod 를 삭제하여 이벤트를 시뮬레이션합니다:
## Get a pod name
POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.name}')
## Delete the pod
kubectl delete pod $POD_NAME이벤트 및 Pod 재생성을 관찰합니다:
kubectl get events
kubectl get pods모니터링에 대한 주요 사항:
kubectl describe는 자세한 리소스 정보를 제공합니다.kubectl get events는 클러스터 전체 이벤트를 표시합니다.describe를 사용하고, 작업 추적에는 events를 사용합니다.이 단계에서는 리소스 사용률을 기반으로 애플리케이션을 자동으로 확장하는 강력한 Kubernetes 기능인 Horizontal Pod Autoscaler (HPA) 에 대한 소개를 받게 됩니다. HPA 를 사용하면 CPU 사용률, 메모리 사용량 또는 사용자 정의 메트릭과 같은 메트릭을 기반으로 확장 규칙을 정의할 수 있습니다.
HPA 이해:
HPA 는 관찰된 CPU 또는 메모리 사용량 또는 애플리케이션에서 제공하는 사용자 정의 메트릭을 기반으로 Deployment, ReplicaSet 또는 StatefulSet 에서 실행 중인 Pod 레플리카 수를 자동으로 조정합니다. 이를 통해 애플리케이션은 변화하는 트래픽 부하를 처리하도록 자동으로 확장되어 성능과 가용성을 향상시킬 수 있습니다.
Minikube 에서 metrics server 애드온을 활성화합니다:
minikube addons enable metrics-server예시 출력:
* The 'metrics-server' addon is enabledmetrics server 는 Kubernetes 에 리소스 사용량 데이터를 제공하며 HPA 가 작동하는 데 필수적입니다.
리소스 요청과 함께 배포를 생성합니다:
nano ~/project/k8s-manifests/hpa-example.yaml다음 내용을 추가합니다:
apiVersion: apps/v1
kind: Deployment
metadata:
name: php-apache
spec:
selector:
matchLabels:
run: php-apache
replicas: 1
template:
metadata:
labels:
run: php-apache
spec:
containers:
- name: php-apache
image: k8s.gcr.io/hpa-example
ports:
- containerPort: 80
resources:
limits:
cpu: 500m
requests:
cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
name: php-apache
labels:
run: php-apache
spec:
ports:
- port: 80
selector:
run: php-apache배포를 적용합니다:
kubectl apply -f ~/project/k8s-manifests/hpa-example.yamlYAML 구성 설명:
name: php-apache: 배포 및 Pod 컨테이너의 이름입니다.image: k8s.gcr.io/hpa-example: 컨테이너에 대한 Docker 이미지입니다.resources: 이 섹션은 컨테이너에 대한 리소스 요구 사항을 지정합니다.
limits.cpu: 500m: 컨테이너가 사용할 수 있는 최대 CPU 입니다.requests.cpu: 200m: 컨테이너에 할당된 보장된 CPU 양입니다.HPA 구성을 생성합니다:
nano ~/project/k8s-manifests/php-apache-hpa.yaml다음 HPA 매니페스트를 추가합니다:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50HPA 구성을 적용합니다:
kubectl apply -f ~/project/k8s-manifests/php-apache-hpa.yamlYAML 구성 설명:
apiVersion: autoscaling/v2: HorizontalPodAutoscaler 에 대한 API 버전을 지정합니다.kind: HorizontalPodAutoscaler: 이것이 HPA 객체임을 나타냅니다.metadata: HPA 에 대한 메타데이터를 포함합니다.
name: php-apache: HPA 의 이름입니다.spec: HPA 사양을 포함합니다.
scaleTargetRef: 확장될 대상 Deployment 를 정의합니다.
apiVersion: apps/v1: 대상 리소스의 API 버전입니다.kind: Deployment: 대상 리소스 유형으로, Deployment 입니다.name: php-apache: 확장할 대상 Deployment 의 이름입니다.minReplicas: 1: 실행을 유지할 최소 레플리카 수입니다.maxReplicas: 10: 확장할 최대 레플리카 수입니다.metrics: 확장 메트릭을 결정하는 방법을 정의합니다.
type: Resource: 리소스 메트릭을 기반으로 확장합니다.resource.name: cpu: CPU 사용량을 기반으로 확장합니다.resource.target.type: Utilization: Pod 가 요청한 CPU 의 백분율을 기반으로 확장합니다.resource.target.averageUtilization: 50: 모든 Pod 의 평균 CPU 사용량이 요청의 50% 를 초과하면 확장합니다.HPA 구성을 확인합니다:
kubectl get hpa예시 출력:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 0%/50% 1 10 1 30s높은 부하를 시뮬레이션하고 오토스케일러를 트리거하려면 한 터미널에서 부하 생성기를 실행하고 별도의 터미널에서 확장 활동을 모니터링합니다.
먼저, 부하 생성기를 위한 터미널을 엽니다:
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"부하 생성기가 있는 터미널을 닫지 마십시오. 다른 터미널을 열어 확장 활동을 모니터링합니다.
두 번째 터미널에서는 자동 스케일링을 실시간으로 관찰하기 위해 여러 명령을 사용할 수 있습니다:
kubectl get hpa -wkubectl get pods -wkubectl get events --sort-by='.lastTimestamp' -w이러한 명령 중 하나를 실행하여 자동 스케일링 프로세스의 다양한 측면을 관찰할 수 있습니다. 예를 들어, -w 플래그를 사용하여 Pod 를 관찰하면 시스템이 확장됨에 따라 Pod 가 실시간으로 생성되는 것을 볼 수 있습니다:
kubectl get pods -w의 예시 출력:
NAME READY STATUS RESTARTS AGE
php-apache-xxxxxxxxx-xxxxx 1/1 Running 0 2m
load-generator 1/1 Running 0 30s
php-apache-xxxxxxxxx-yyyyy 0/1 Pending 0 0s
php-apache-xxxxxxxxx-yyyyy 0/1 ContainerCreating 0 0s
php-apache-xxxxxxxxx-yyyyy 1/1 Running 0 3s
php-apache-xxxxxxxxx-zzzzz 0/1 Pending 0 0s
php-apache-xxxxxxxxx-zzzzz 0/1 ContainerCreating 0 0s
php-apache-xxxxxxxxx-zzzzz 1/1 Running 0 2sHPA 가 증가된 부하에 대응하여 Pod 수를 확장하는 것을 볼 수 있습니다. 메트릭 업데이트는 변경 사항을 반영하는 데 1 분 이상 걸릴 수 있습니다:
kubectl get hpa -w의 예시 출력:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache 0%/50% 1 10 1 30s
php-apache Deployment/php-apache 68%/50% 1 10 1 90s
php-apache Deployment/php-apache 68%/50% 1 10 2 90s
php-apache Deployment/php-apache 79%/50% 1 10 2 2m
php-apache Deployment/php-apache 79%/50% 1 10 4 2m15s관찰을 마치면 Ctrl+C를 눌러 모니터링 명령을 중지하고, 첫 번째 터미널로 돌아가 Ctrl+C를 눌러 부하 생성기를 중지합니다.
HPA 에 대한 주요 사항:
kubectl 명령과 함께 -w (watch) 플래그를 사용하면 클러스터 변경 사항을 실시간으로 모니터링할 수 있습니다.이 랩에서는 Kubernetes 에서 스케일링 및 로드 밸런싱에 대한 실질적인 경험을 얻었습니다. Minikube 를 사용하여 로컬 Kubernetes 클러스터를 생성하고 기본 NGINX 웹 애플리케이션을 배포하는 것으로 시작했습니다. 그런 다음, 배포 YAML 파일을 수정하고 kubectl scale을 사용하여 Pod 레플리카 수를 조정하는 등 다양한 스케일링 방법을 탐색했습니다. Kubernetes Service 와 임시 테스트 Pod 를 사용하여 로드 밸런싱을 확인하는 방법을 배웠습니다.
또한, kubectl describe 및 kubectl get events 명령을 통해 배포 및 Pod 를 모니터링하는 방법을 배웠습니다. 마지막으로, php-apache 이미지를 기반으로 한 예제를 사용하여 리소스 사용률에 따라 애플리케이션을 자동으로 확장할 수 있는 Horizontal Pod Autoscaler (HPA) 에 대한 기본적인 이해를 얻었습니다. 이 랩은 Kubernetes 스케일링, 로드 밸런싱, 모니터링 및 자동 스케일링 기술에 대한 포괄적인 소개를 제공하며, Kubernetes 에서 더 복잡한 애플리케이션을 관리하기 위한 기반을 마련합니다.
