오토에버 클라우드 2기 41일차

쿠버네티스 클러스터(Cluster) 구성 방법

쿠버네티스를 사용하기 위해서는 먼저 클러스터 환경이 필요하다

1. 구성 방법의 종류

• 로컬 쿠버네티스 (Local Kubernetes): 학습이나 개발 목적으로 개인 PC(물리 머신 1대)에 구축하는 방식
• 구축 도구 이용: 온프레미스(사내 서버)나 클라우드 환경에 직접 클러스터를 구축할 때 사용하는 전문 도구를 이용하는 방식
• 관리형 쿠버네티스 (Managed Kubernetes): AWS(EKS), GCP(GKE), Azure(AKS) 등 퍼블릭 클라우드 업체가 제공하는 완전 관리형 서비스를 사용하는 방식 운영 부담이 적어 실제 서비스 환경에서 많이 사용된다

 

2. 로컬 쿠버네티스 구축 도구

개인 PC에서 쿠버네티스를 체험하기 위한 대표적인 도구

• Docker Desktop: 가장 간단한 방법으로, Docker Desktop 설정에서 쿠버네티스를 활성화하면 최소한의 환경이 자동으로 구성

• Minikube: 단일 노드 또는 다중 노드 클러스터를 로컬 환경에 쉽게 구축해주는 도구 VirtualBox, Docker 등 다양한 드라이버를 지원

  • 클러스터 생성: minikube start
  • 다중 노드 클러스터 생성: minikube start --nodes 3 -p multi-cluster
  • 클러스터 중지/삭제: minikube stop / minikube delete

• k3s: 경량화된 쿠버네티스로, IoT나 엣지 컴퓨팅 환경처럼 저사양 시스템에서도 쉽게 설치하고 운영할 수 있습니다.

• Kind (Kubernetes IN Docker): 도커 컨테이너를 ‘노드’로 사용하여 로컬에 다중 노드 쿠버네티스 클러스터를 빠르고 손쉽게 구축할 수 있는 도구 CI/CD 파이프라인에서 테스트용 클러스터를 생성할 때 많이 사용

  • 기본 클러스터 생성: kind create cluster

  • 설정 파일을 이용한 다중 노드 클러스터 생성:

    # kind-config.yaml
    kind: Cluster
    apiVersion: kind.x-k8s.io/v1alpha4
    nodes:
    - role: control-plane
    - role: worker
    - role: worker
    

    kind create cluster --config kind-config.yaml --name my-multi-cluster
    

 

3. 여러 머신을 이용한 클러스터 구축 도구: kubeadm

kubeadm은 온프레미스 환경에 쿠버네티스 클러스터를 구축할 때 가장 널리 사용되는 공식 도구 최소한의 구성 요소만 설치해주므로, 사용자는 CNI(네트워크 플러그인) 등 필요한 부분을 직접 선택하고 구성해야 한다 학습 곡선은 높지만, 쿠버네티스의 내부 동작을 이해하고 유연하게 클러스터를 구성할 수 있다는 장점 존재

 

쿠버네티스 클러스터 사용하기

1. 네임스페이스 (Namespace): 논리적 분리

네임스페이스는 하나의 물리적 클러스터를 여러 개의 논리적인 가상 클러스터로 나누어 사용하는 기능

• 용도:
  • 여러 팀이 하나의 클러스터를 공유할 때 리소스를 격리
  • 개발(dev), 스테이징(staging), 운영(production) 환경을 분리
• 기본 네임스페이스:
  • default: 사용자가 네임스페이스를 지정하지 않으면 모든 리소스는 여기에 생성
  • kube-system: API 서버, 스케줄러 등 쿠버네티스 시스템 컴포넌트들이 실행되는 공간
  • kube-public: 모든 사용자가 접근 가능한 리소스를 배치하는 공간
• 분리성 강화: 네임스페이스만으로는 완벽한 격리가 어렵다 RBAC(역할 기반 접근 제어)를 통해 네임스페이스별 사용자 권한을 제어하고, 네트워크 정책(Network Policy)을 통해 네임스페이스 간 통신을 제어하면 분리성을 크게 높일 수 있다

 

2. kubectl: 클러스터와 대화하는 도구

kubectl은 쿠버네티스 클러스터의 API 서버에 명령을 전달하기 위한 공식 커맨드 라인 인터페이스(CLI) 도구 클러스터의 모든 조작은 kubectl을 통해 이루어진다

 

3. 인증 정보와 컨텍스트 (Context)

kubectl은 어떤 클러스터에 접속해야 할지 kubeconfig 파일의 정보를 참조 이 파일은 보통 ~/.kube/config 경로에 위치

• kubeconfig 파일의 구조:
  • clusters: 접속할 클러스터들의 정보(API 서버 주소 등) 목록
  • users: 클러스터에 접근할 사용자들의 인증 정보(인증서, 토큰 등) 목록
  • contexts: 위 cluster와 user를 조합하여 “어떤 유저가 어떤 클러스터에 접속할 것인가”를 정의한 설정의 집합
• 컨텍스트 관리:
  • 현재 컨텍스트 확인: kubectl config current-context
  • 컨텍스트 목록 보기: kubectl config get-contexts
  • 컨텍스트 전환: kubectl config use-context <컨텍스트이름>
  • 명령 실행 시 임시로 컨텍스트 지정: kubectl get pods --context minikube

 

3. 리소스 관리: 생성, 갱신, 삭제

쿠버네티스의 모든 것은 ‘리소스(오브젝트)’이며, 이 리소스들은 주로 YAML 형식의 ‘매니페스트(Manifest)’ 파일로 정의

1. 리소스 생성: create vs apply

kubectl run (비권장)

• 가장 간단하게 Pod를 만드는 방식 kubectl run nginx --image=nginx
• 단점: 명령 실행 기록이 남지 않아 재현 및 관리가 어렵다 간단한 테스트 용도 외에는 사용을 권장하지 않음

kubectl create -f <파일경로>

• YAML 파일에 정의된 리소스를 생성
• 단점: 해당 리소스가 이미 존재하면 에러가 발생

kubectl apply -f <파일경로> (권장)

• YAML 파일의 내용과 클러스터의 현재 상태를 비교하여, 없으면 생성하고, 변경된 부분이 있으면 업데이트

• 장점: 동일한 명령어로 생성과 업데이트를 모두 처리할 수 있어 자동화(CI/CD) 환경에 매우 유리 조건 분기 없이 스크립트를 단순하게 유지할 수 있다

  • 주의: create와 apply를 섞어 사용하면, apply가 변경 사항을 제대로 감지하지 못하는 문제가 발생할 수 있음 리소스 관리는 apply로 통일하는 것을 강력히 권장

• YAML 파일 예시 (sample-pod.yaml):

  apiVersion: v1
  kind: Pod
  metadata:
    name: sample-pod
  spec:
    containers:
    - name: nginx-container
      image: nginx:1.16
  

• 실행:

  # 처음 실행: 리소스가 없으므로 생성됨
  kubectl apply -f sample-pod.yaml
  # pod/sample-pod created
    
  # 다시 실행: 변경 사항이 없으므로 아무 일도 일어나지 않음
  kubectl apply -f sample-pod.yaml
  # pod/sample-pod unchanged
    
  # YAML 파일 수정 (예: nginx:1.17로 변경) 후 실행: 변경된 부분만 업데이트됨
  kubectl apply -f sample-pod.yaml
  # pod/sample-pod configured
  

   

2. 리소스 삭제: kubectl delete

• 파일로 삭제: kubectl delete -f sample-pod.yaml
• 타입과 이름으로 삭제: kubectl delete pod sample-pod
• 특정 타입의 모든 리소스 삭제: kubectl delete pods --all
• 강제 즉시 삭제: --force 와 --grace-period=0 옵션을 함께 사용하면 정상 종료 대기 시간 없이 리소스를 즉시 강제로 삭제합니다. (주의해서 사용해야 함)

 

3. Server-Side Apply: 충돌 방지

쿠버네티스에서는 kubectl 뿐만 아니라 여러 컨트롤러가 리소스를 수정할 수 있다 여러 주체가 동시에 같은 리소스를 수정하려 할 때 충돌이 발생할 수 있는데, Server-Side Apply는 이러한 충돌을 서버 측에서 감지하고 관리하는 기능

• 문제 상황 예시:
  1. kubectl apply -f sample-pod.yaml 로 nginx:1.16 이미지를 가진 Pod를 배포
  2. kubectl set image pod sample-pod nginx-container=nginx:1.17 명령으로 급하게 이미지만 1.17로 변경 (이 변경은 YAML 파일이 아닌 서버에만 기록됨)
  3. 이후 다시 kubectl apply -f sample-pod.yaml (여전히 1.16으로 정의된 파일)을 실행하면, apply는 set image로 변경된 내용을 모르기 때문에 이미지를 다시 1.16으로 되돌려버림
• 해결: kubectl apply --server-side -f sample-pod.yaml 와 같이 --server-side 옵션을 사용하면, 다른 주체에 의한 변경 사항이 있을 경우 충돌을 감지하고 에러를 발생시켜 의도치 않은 롤백을 막을 수 있다

 

4. 파드 재시작: rollout restart

Deployment와 같은 컨트롤러에 의해 관리되는 Pod 그룹 전체를 순차적으로 재시작하는 명령어 ConfigMap이나 Secret의 변경 내용을 적용하고 싶을 때 유용

# sample-deployment 라는 이름의 Deployment를 재시작
kubectl rollout restart deployment sample-deployment

중요: 이 명령어는 Deployment, StatefulSet, DaemonSet 등 컨트롤러에 의해 관리되는 리소스에만 사용할 수 있다 kubectl run이나 apply로 생성한 단독 Pod는 재시작할 수 없다 (error: pods "sample-pod" restarting is not supported)

 

5. generateName: 동적 리소스 이름 생성

매니페스트 파일에서 metadata.name 대신 metadata.generateName을 사용하면, 리소스 생성 시 쿠버네티스가 지정된 접두사 뒤에 임의의 난수를 붙여 고유한 이름을 자동으로 생성해 줌 Job이나 동적으로 생성되는 리소스의 이름 충돌을 방지할 때 유용

• YAML 파일 예시 (sample-generatename.yaml):

  apiVersion: v1
  kind: Pod
  metadata:
    generateName: sample-generatename-
  spec:
    containers:
    - name: nginx-container
      image: nginx
  

• 실행: kubectl create -f sample-generatename.yaml

• 결과: sample-generatename-abcde 와 같은 이름의 Pod가 생성