본문 바로가기
개발/k8s

[k8s] 쿠버네티스 기초

by parkkingcar 2023. 12. 19.

 

쿠버네티스란?

쿠버네티스는 구글이 내부적으로 사용하던 컨테이너 클러스터 관리도구에서 아이디어를 얻어서 만든 오픈소스 소프트웨어입니다. 쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장을 관리하는 것을 자동화하기 위한 컨테이너 오케스트레이션 엔진입니다.

 

최근 도커를 비롯한 컨테이너 기술이 화두가 되면서 실제 서비스 환경에 컨테이너를 적용하는 사례가 늘어나는데, 도커 자체로는 여러 호스트 구성 또는 큰 규모의 서비스 환경에서 사용하는 시스템을 구축하기 어렵습니다. 그래서 쿠버네티스와 같은 컨테이너 오케스트레이션 엔진을 사용해 이러한 시스템을 구축합니다. 쿠버네티스에서 실제 컨테이너가 기동하는 노드는 쿠버네티스 노드라 하고, 그 쿠버네티스 노드를 관리하는 노드는 쿠버네티스 마스터라 합니다.

 

쿠버네티스(Kubernetes)에서 클러스터는 여러 구성 요소로 구성되어 있습니다. 각 구성 요소는 클러스터의 다양한 측면을 관리하고 조율하는 역할을 합니다. 

 

 

- 클러스터 마스터 노드 (Cluster Master Node): 클러스터를 제어하고 관리하는 중심 노드입니다. 마스터 노드는 API 서버, 스케줄러, 컨트롤러 매니저 등의 핵심 컴포넌트를 실행합니다. 

 

API 서버 (API Server) : 클러스터 내의 모든 작업을 제어하고 관리하는 컴포넌트입니다. 사용자와 다양한 클라이언트들이 API 서버를 통해 클러스터와 상호작용합니다. 

스케줄러 (Scheduler) : 새로운 파드의 배치 결정을 담당합니다. 새로운 파드를 어떤 워커 노드에 스케줄할지 결정하여 최적의 자원 활용을 유도합니다. 

컨트롤러 매니저 (Controller Manager) : 클러스터의 상태를 모니터링하고 필요에 따라 클러스터의 원하는 상태로 조정하는 역할을 합니다. Replication Controller, Replica Set, StatefulSet 등과 같은 리소스의 상태를 유지합니다. 

etcd : 클러스터의 모든 상태를 안전하게 저장하는 분산형 키-값 저장소입니다. 클러스터의 상태 정보를 모든 마스터 노드에 저장하고, 필요할 때에는 갱신합니다. 

 

 

- 워커 노드 (Worker Node) : 실제로 파드가 실행되는 노드로, 클러스터의 계산 리소스를 제공합니다. 워커 노드는 컨테이너 실행을 담당하는 Kubelet과 네트워크 및 로드 밸런싱을 담당하는 Kube Proxy를 포함합니다. 

 

Kubelet : 워커 노드에서 실행되는 에이전트로, 마스터 노드의 명령에 따라 노드 상태를 보고하고 파드를 실행합니다. Kubelet은 또한 컨테이너 런타임과 통신하여 파드를 시작하고 관리합니다. 

Kube Proxy : 워커 노드에서 실행되는 네트워크 프록시로, 서비스의 네트워크 규칙을 관리하고 클러스터 내에서 서비스에 접근할 수 있도록 합니다. Kube Proxy는 iptables 또는 IPVS와 같은 도구를 사용하여 네트워크 트래픽을 로드 밸런싱합니다. 

Pod : 쿠버네티스에서 가장 작은 배포 단위입니다. 하나 이상의 컨테이너로 구성되어 있으며, 네트워크, 스토리지, 컨테이너 관리 및 환경 변수와 같은 리소스를 공유합니다. 이러한 구성 요소들은 함께 작동하여 쿠버네티스 클러스터를 관리하고, 컨테이너화된 어플리케이션을 효과적으로 배포하고 실행할 수 있도록 합니다.

 

 

 

쿠버네티스 리소스

쿠버네티스를 관리하기 위해 등록하는 리소스는 컨테이너의 실행과 로드 밸런서 생성 등 많은 종류가 있습니다. 리소스는 크게 다섯 가지 카테고리로 분류됩니다.

 

1. 워크로드 API 카테고리

2. 서비스 API 카테고리

3. 컨피그 & 스토리지 API 카테고리

4. 클러스터 API 카테고리

5. 메타데이터 API 카테고리

 

 

1. 워크로드 API 카테고리

워크로드 API 카테고리는 클러스터 위에서 컨테이너를 기동하기 위해 사용되는 리소스입니다. 

 

- 파드

워크로드 리소스의 최소 단위는 '파드'라고 불리는 리소스입니다. 파드는 한 개 이상의 컨테이너로 구성되며, 같은 파드에 포함된 컨테이너끼리는 네트워크적으로 격리되어 있지 않고 IP 주소를 공유합니다.

 

- 레플리카셋 / 레플리카셋 컨트롤러

파드의 레플리카를 생성하고 지정된 파드 수를 유지하는 리소스입니다. 

 

- 디플로이먼트

여러 레플리카셋을 관리하여 롤링 업데이트나 롤백 등을 구현하는 리소스입니다. 즉, 디플로이먼트가 레플리카셋을 관리하고 레플리카셋이 파드를 관리하는 관계입니다.

 

- 데몬셋

데몬셋은 레플리카셋의 특수한 형태라고 할 수 있는 리소스입니다. 레플리카셋은 각 쿠버네티스 노드에 총 N개의 파드를 노드의 리소스 상황에 맞게 배치합니다. 이와 다르게 데몬셋은 각 노드에 파드를 하나씩 배치하는 리소스입니다. 

 

- 스테이트풀셋

스테이트풀셋은 스테이트풀한 워크로드에 사용하기 위한 리소스입니다. 전통적인 웹 서비스와는 다르게, 상태를 가지는 애플리케이션은 각각의 인스턴스가 고유한 식별자와 상태를 가져야 하는데, 대표적으로 데이터베이스가 해당됩니다.

 

-

잡은 컨테이너를 사용하여 한 번만 실행되는 리소스입니다. N개의 병렬로 실행하면서 지정한 횟수의 컨테이너 실행을 보장하는 리소스입니다.

 

- 크론잡

크론잡은 잡과 비슷한 리소스로 스케줄링된 시간에 잡을 생성합니다. 크론잡이 잡을 관리하고 잡이 파드를 관리하는 3계층 구조라고 할 수 있습니다.

 

 

2. 서비스 API 카테고리

서비스 API 카테고리는 컨테이너 서비스 디스커버리와 클러스터 외부에서도 접속이 가능한 엔드포인트 등을 제공하는 리소스입니다. 내부적으로 사용되는 것을 제외하고 사용자가 직접 관리할 수 있는 리소스로 서비스와 인그레스라는 두 종류의 서비스 API 카테고리가 있습니다.

 

- ClusterIP

ClusterIP는 쿠버네티스의 가장 기본이 되는 서비스입니다. 쿠버네티스 클러스터 외부에서 트래픽을 수신할 필요가 없는 환경에서 클러스터 내부 로드 밸런서로 사용됩니다.

 

- ExternamIP

ExternamIP는 특정 쿠버네티스 노드 IP:Port에서 수신한 트래픽을 컨테이너로 전송하는 형태로 외부와 통신할 수 있도록 하는 서비스입니다.

 

- NodePort

ExternamIP와 비슷하지만 NodePort는 모든 쿠버네티스 노드의 IP:Port에서 수신한 트래픽을 컨테이너에 전송하는 형태로 외부와 통신할 수 있습니다.

 

- LoadBalancer

LoadBalancer는 서비스 환경에서 클러스터 외부로부터 트래픽을 수신할 때 가장 실용적이고 사용하기 편리한 서비스입니다. LoadBalancer는 쿠버네티스 클러스터 외부의 로드밸런서에 외부 통신이 가능한 가상 IP를 할당할 수 있습니다.

 

- Headless(None)

Headless는 ClusterIP가 없거나 "None"으로 설정된 서비스를 의미합니다. Headless는 기본적으로 DNS에 엔트리를 생성하지 않으며, 각각의 엔드포인트에 대한 클러스터 내부 DNS 레코드를 생성하지 않습니다.


- ExternalName

ExternalName은 외부에 있는 서비스나 호스트에 대한 DNS 이름을 사용하여 클러스터 내부에서 해당 서비스를 사용할 수 있게 하는 기능을 제공합니다.

 

- 세션 어피니티 (Session Affinity)

쿠버네티스에서 서비스 세션 어피니티는 클라이언트 요청이 특정 파드에 대한 지속적인 연결을 유지하도록 하는 메커니즘입니다. 서비스 세션 어피니티는 주로 스테이트풀셋과 함께 사용되어 세션 상태를 유지해야 하는 애플리케이션에 유용합니다.

 

- None-Selector

None-Selector는 서비스명으로 이름 해석을 하면 자신이 설정한 멤버에 대해 로드 밸런싱을 합니다.

 

 

 

인그레스

위 서비스들은 L4 로드밸런싱을 제공하는 리소스이지만, 인그레스는 L7로드밸런싱을 제공하는 리소스입니다. 인그레스는 서비스들을 묶는 서비스들의 상위 객체로, 서비스 종류의 하나로서가 아닌 독립된 리소스로 구현되어 있습니다. 인그레스는 HTTP 및 HTTPS 트래픽을 관리하며, 특정 경로 또는 도메인을 기반으로 서비스에 대한 라우팅 규칙을 정의할 수 있습니다. 인그레스를 사용하면 여러 서비스에 대한 단일 진입점을 만들고, 동적인 경로 기반 라우팅, SSL 종단 감지, 기본 인증 등과 같은 기능을 사용할 수 있습니다.

 

인그레스는 클라우드 공급자(Kubernetes Ingress Controller와 통합된 형태로) 또는 자체 호스팅된 클러스터에서 사용할 수 있습니다. Ingress Controller는 클러스터 외부 트래픽을 관리하고 내부 서비스로 라우팅하는 역할을 합니다.

 

 

 

3. 컨피그 & 스토리지 API 카테고리

컨피그 & 스토리지 API 카테고리는 설정과 기밀 데이터를 컨테이너에 담거나 영구 볼륨을 제공하는 리소스입니다. 

 

- 시크릿

시크릿은 암호화된 정보나 민감한 데이터를 안전하게 저장하는 데 사용되는 리소스입니다. 시크릿은 일반적으로 애플리케이션에서 사용하는 비밀키, 패스워드, OAuth 토큰, API 키, 인증서 등과 같은 민감한 정보를 안전하게 보호하는 데에 활용됩니다. 예를들어 데이터베이스에 접속하려면 사용자명이나 패스워드 등의 기밀정보가 필요합니다. 이때 기밀정보를 노출하지않고 컨테이너로 비교적 안전하게 전달할 수 있습니다.

 

- 컨피그맵

컨피그맵은 설정 정보 등을 키-밸류 값으로 저장할 수 있는 데이터 저장 리소스입니다. 이 데이터는 Pod의 환경 변수, 커맨드 라인 인자, 볼륨 등을 통해 애플리케이션에 주입되어 사용됩니다. 주로 환경변수로 전달하기 위해 사용됩니다. 

 

- 영구 볼륨 클레임

영구 볼륨 클레임은 영구 볼륨을 사용하기 위한 리소스입니다. 먼저 볼륨과 영구볼륨, 영구볼륨클레임의 차이를 이해해야 합니다. 볼륨은 미리 준비된 사용 가능한 불륨등을 매니패스트에 직접 지정하여 사용할 수 있게 합니다.  영구볼륨은 영속성 영역으로 확보된 볼륨입니다. 볼륨은 파드 정의 안에 직접 지정하는 형태로 연결하지만 영구 볼륨은 개별 리소스로 생성한 후 사용합니다. 영구볼륨클레임은 영구 볼륨을 요청하는 리소스입니다. 영구 볼륨 클레임을 사용하는 이유는 애플리케이션 데이터의 지속성과 관리를 위해입니다. 스토리지 클래스를 활용하여 동적 프로비저닝도 가능합니다. 볼륨을 직접 명시하지 않고도 스토리지 리소스를 유연하게 활용할 수 있습니다.

 

 

4. 클러스터 API 카테고리

클러스터 API 카테고리는 클러스터 자체 동작을 정의하는 리소스입니다.

 

- 노드

클러스터 내에서 워커 머신 또는 노드로 알려진, 컨테이너화된 애플리케이션을 실행하는 시스템입니다. 쿠버네티스 클러스터는 하나 이상의 노드로 구성되며, 각 노드는 클러스터에서 컨테이너화된 애플리케이션을 실행하고 관리하는 역할을 합니다.

 

- 네임스페이스

쿠버네티스에는 네임스페이스라고 불리는 가상적인 쿠버네티스 클러스터 분리 기능이 있습니다. 하나의 쿠버네티스를 여러 팀에서 사용하거나 서비스 환경/스테이징 환경/개발 환경으로 구분하는 경우 사용합니다. 

 

- 영구 볼륨

영구볼륨은 위에 설명한것과 같이 클러스터에서 파드 간에 데이터를 유지하고 공유하기 위한 스토리지 리소스를 나타냅니다.

 

- 리소스 쿼터

네임스페이스 단위로 할당되는 자원의 한도를 설정하는 정책입니다. 이를 통해 클러스터의 자원 사용을 제한하고, 과도한 리소스 소비를 방지하며 다중 테넌시 환경에서 각 네임스페이스에게 적절한 자원을 할당할 수 있습니다.

 

- 서비스 어카운트

파드와 같은 워크로드가 쿠버네티스 클러스터 내에서 자원에 접근할 때 사용하는 계정입니다. 서비스 어카운트는 해당 계정의 권한을 관리하며, 쿠버네티스 API 서버와 통신할 때 인증 정보를 제공합니다.

 

-

네임스페이스 내에서 특정 자원에 대한 액세스 권한을 정의합니다.

 

- 클러스터 롤

클러스터 전체에서 특정 자원에 대한 액세스 권한을 정의합니다.

 

- 롤바인딩

롤을 특정 사용자, 그룹 또는 서비스 어카운트와 결합하여 액세스 권한을 부여합니다.

 

- 클러스터롤바인딩

클러스터 롤 바인딩은 클러스터 전체에서 클러스터 롤(ClusterRole)을 사용자, 그룹, 또는 서비스 어카운트에 바인딩합니다. 이를 통해 클러스터 전반에 걸쳐 특정 권한을 가진 사용자나 서비스 어카운트를 정의할 수 있습니다.

 

- 네트워크 정책

네트워크 정책은 쿠버네티스 클러스터 내에서 파드 간의 트래픽을 제어하는 데 사용됩니다. 네트워크 정책을 사용하면 특정 파드 간의 통신을 허용하거나 차단하고, 특정 포트 또는 IP 주소에 대한 접근을 제한할 수 있습니다.

 

 

5. 메타데이터 API 카테고리

메타데이터 API 카테고리는 클러스터 내부의 다른 리소스 동작을 제어하기 위한 리소스입니다.

 

- LimitRange

파드 등에 대해 CPU나 메모리 리소스의 최솟값과 최댓값, 기본값 등을 설정합니다.

 

- Horizontal Pod Autoscaler

HPA는 디플로이먼트, 레플리카셋, 레플리케이션 컨트롤러의 레플리카 수를 CPU 부하 등에 따라 자동으로 스케일하는 리소스입니다.

 

- Pod Disruption Budget

PDB는 쿠버네티스에서 파드의 안정성과 가용성을 유지하기 위해 사용되는 정책 중 하나입니다. PDB는 클러스터 내 파드 갱신 및 제거 작업에 대한 제한을 설정하여, 서비스 중단을 방지하고 안전한 업데이트를 가능하게 합니다.

 

- 커스텀 리소스 데피니션

커스텀 리소스 데피니션(Custom Resource Definition, CRD)은 쿠버네티스에서 사용자 정의 자원을 정의하는 확장 메커니즘입니다. 이를 통해 사용자는 쿠버네티스 API에 자신만의 리소스 유형을 도입하고 이를 관리할 수 있습니다.

 

 

 

매니페스트(yaml)와 리소스 생성/삭제/갱신

 

kubectl을 사용하여 하나의 컨테이너를 가진 파드를 생성합니다. 아래는 pod.yaml 파일입니다. 리소스생성에는 kubectl create와 kubectl apply를 사용할 수 있는데 조건 분기와 변경사항에 대한 검출 등의 이유로 kubectl apply를 사용합니다. yaml 파일을 수정하고 갱신의 역할도 동일한 명령을 통해 수행합니다.

$ kubectl apply -f pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  containers:
  - name: myapp
    image: nginx
    ports:
      - containerPort: 80

 

 

이후 get pod 명령을 통해 생성한 파드를 확인할 수 있습니다.

$ kubectl get pods

 

get svc 명령을 통해 생성한 서비스를 확인할 수 있습니다.

$ kubectl get svc

 

get ep 명령을 통해 생성한 앤드포인트를 확인할 수 있습니다.

$ kubectl get ep

 

get svc 명령을 통해 생성한 네임스페이스를 확인할 수 있습니다.

$ kubectl get ns

 

get svc 명령을 통해 생성한 자격증명을 확인할 수 있습니다.

$ kubectl get managedcertificates

 

get svc 명령을 통해 생성한 인그레스를 확인할 수 있습니다.

$ kubectl get ingress

 

exec 명령을 통해 pod내부의 컨테이너에 접속할 수 있습니다.

$ kubectl exec -it <pod이름> /bin/bash

 

kubectl describe 명령을 통해 리소스의 상세 정보를 확인합니다.

$ kubectl describe pod <pod이름>

 

kubectl logs 명령을 통해 컨테이너에서 기동하는 애플리케이션의 로그를 출력합니다.

kubectl logs <pod이름>

 

 

 

 

댓글