쿠버네티스란
개요
- 컨테이너화된 애플리케이션을 배포, 관리, 확장하기 위한 오픈 소스 컨테이너 오케스트레이션 플랫폼
- 여러 서버에 걸쳐 컨테이너를 실행하고 관리하는 시스템
| 용어 | 뜻 |
| 컨테이너 | 앱이 구동되는 환경까지 감싸서 실행할 수 있도록 하는 격리 기술 |
| 컨테이너 런타임 | 컨테이너를 다루는 도구 |
| 도커 | 컨테이너를 다루는 도구 중 가장 유명한 것 |
| 쿠버네티스 | 컨테이너 런타임을 통해 컨테이너를 오케스트레이션 하는 도구 |
| 오케스트레이션 | 여러 서버에 걸친 컨테이너 및 사용하는 환경 설정을 관리하는 행위 |
쿠버네티스(컨테이너 오케스트레이션 필요성)
대규모 애플리케이션 관리
- 컨테이너 수가 많아질수록 컨테이너의 배포, 관리, 확장, 네트워킹이 복잡
- 오케스트레이션은 이를 자동화하여 효율적으로 관리
자동화
- 컨테이너 오케스트레이션은 컨테이너의 수명 주기를 관리하는 데 필요한 작업을 자동화
- 고장난 컨테이너를 감지, 교체l, 업데이트 및 롤백, 구성 관리 등
가용성 및 확장성
- 컨테이너 오케스트레이션은 컨테이너의 가용성을 높이고, 필요에 따라 애플리케이션을 확장할 수 있도록 지원
CI/CD 파이프라인 구축
- 컨테이너 오케스트레이션을 통해 CI/CD 파이프라인을 구축하여 소프트웨어 개발 과정을 자동화하고 효율적으로 개선
이식성 및 일관성
- 컨테이너는 어떤 환경에서도 동일하게 실행될 수 있기 때문에, 오케스트레이션은 컨테이너를 다양한 환경에 이식하고 일관성을 유지
리소스 관리
- 컨테이너 오케스트레이션은 여러 컨테이너의 리소스 할당 및 관리를 효율적으로 수행하여, 리소스 낭비를 줄이고 시스템의 안정성을 높임
아키텍처
쿠버네티스 클러스터 : Control Plane + 하나 이상의 작업 노드(Node)로 구성
Control Plane Components
클러스터의 전반적인 상태를 관리
kube-apiserver
쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트
etcd
모든 클러스터의 메타 데이터를 저장하는 쿠버네티스 저장하는 Key-Value 저장소
오직 API Server 와 통신, 다른 모듈은 API Server 를 통해 ETCD 접근
쿠버네티스 클러스터에서 etcd를 사용한다면, 이 데이터를 백업하는 계획은 필수적
공식문서
kube-scheduler
사용자의 요청에 따라 쿠버네티스의 작업 장비인 노드가 새로 생성된 Pod를 감지하고, 실행할 노트를 선택
kube-controller-manager
실행컨트롤러Kubernetes API 동작을 구현
API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤러 프로세스를 실행
cloud-controller-manager (선택 사항)
클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트
Node Components
동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작
Kubelet
클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리
Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하도록 진행
Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않음
kube-proxy
kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시
kube-proxy는 노드의 네트워크 규칙을 유지 관리
이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신
kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용
그렇지 않을 경우, kube-proxy는 트래픽 자체를 포워드(forward)
Container Runtime
컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어
쿠버네티스는 containerd, CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스) 구현체를 지원
쿠버네티스 실습 환경
KIND
Kubernetes IN Docker, docker in docker로 Kubernetes 클러스터(마스터/워커 노드)를 시뮬레이션하는 도구
Docker 컨테이너 "노드"를 사용하여 로컬 Kubernetes 클러스터를 실행하기 위한 도구
설치
필수 Tool 설치 후 버전 확인
# 설치
brew install kind
brew install kubernetes-cli
brew install helm

KIND 기본 사용 - 클러스터 배포 및 확인
# 클러스터 생성
kind create cluster
# 클러스터 배포 확인
kind get clusters
kind get nodes
kubectl cluster-info

# 노드 정보 확인
kubectl get node -o wide
# 파드 정보 확인
kubectl get pod -A
kubectl get componentstatuses
# 컨트롤플레인 (컨테이너) 노드 1대가 실행
docker ps
docker images

쿠버네티스 활용
kubectl
kubernetes + control : 쿠버네티스를 제어하는 명령을 API Server 로 전달
쿠버네티스 정보 확인
kubectl api-resources
- 쿠버네티스 클러스터에서 사용할 수 있는 API 리소스
- 각 리소스의 실행시 긴 명령어 대신 약어(SHORTNAMES) 확인 가능
kubectl api-resources
# 대표적인 쿠버네티스 리소스 약어
# pods - po
kubectl api-resources | grep pods
# deployments - deploy
kubectl api-resources | grep deployments
# namespaces - ns
kubectl api-resources | grep namespaces
# configmaps - cm
kubectl api-resources | grep configmaps

kubectl get <Resource>
쿠버네티스 클러스터 내부 리소스에 대한 조회 명령어
# 노드 조회
kubectl get node
kubectl get node -o wide

# 파드 조회
kubectl get pods
kubectl get pods -A

# 디플로이먼트 조회
kubectl get deployment
kubectl get deployment -A

kubectl describe <Resource>
쿠버네티스 클러스터 내부 리소스에 대한 상세 정보 조회
# 파드 상세 조회
kubectl describe pod -n kube-system <Pod이름>
# 디플로이먼트 조회
kubectl describe deployment -n kube-system coredns
# 네임스페이스 조회
kubectl describe namespace kube-system



쿠버네티스 컨텍스트 확인
- kubectl 명령어를 수행할 때 어떤 클러스터, 어떤 사용자, 어떤 네임스페이스를 대상으로 동작할 지 지정하는 설정
- 컨텍스트를 통해 쿠버네티스에 접근하는 과정을 인증(Authentication) 이라고 지칭
- 멀티 클러스터를 다룰 때 유용
구성 요소
- Cluster : 연결할 쿠버네티스 클러스터
- User: 클러스터 인증에 사용할 사용자 정보 (토큰, 인증서)
- Namespace: 기본으로 사용할 네임스페이스
Context 확인
# 현재 설정된 컨텍스트 확인
kubectl config current-context
# 모든 컨텍스트 확인
kubectl config get-contexts

Context 정보 저장된 위치
# Config 정보 확인
cat ~/.kube/config

Namespace
- 쿠버네티스 단일 클러스터 내에서 리소스 그룹을 격리 로직을 제공
- 리소스 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에는 유일할 필요 없음
- kube- 접두사는 k8s 시스템용으로 예약되어 있기에 Namespace 로 생성할 수 없음
- 모든 Object 가 Namespace 에 속하지는 않음 → 전체 클러스터 수준
# Namespace 에 속하는 리소스
kubectl api-resources --namespaced=true
# Namespace 에 속하지 않는 리소스
kubectl api-resources --namespaced=false


초기 네임스페이스
4개의 초기 Namespace를 가짐
| default | 쿠버네티스에는 이 네임스페이스가 포함되어 있으므로 먼저 네임스페이스를 생성하지 않고도 새 클러스터를 사용 가능 |
| kube-node-lease | 각 노드와 연관된 리스 오브젝트를 가짐 node-lease는 kubelet이 하트비트를 보내서 컨트롤 플레인이 노드의 장애를 탐지 |
| kube-public | 모든 클라이언트(인증되지 않은 클라이언트 포함)가 읽기 권한으로 접근 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약 |
| kube-system | 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스 |
namespace활용
# 네임스페이스 조회
kubectl get ns
# 네임스페이스 생성
kubectl create namespace knou
kubectl get ns
# 파트 생성
kubectl run nginx --image=nginx:alpine
#
kubectl get pods
kubectl describe pod nginx
kubectl describe pod nginx | grep Namespace
# knou 네임스페이스에 파드 생성
kubectl run nginx --image=nginx:alpine -n knou
#
kubectl get pods -n knou
kubectl get pods -A
# knou 네임스페이스에 다시 한 번 파드 배포
kubectl run nginx --image=nginx:alpine -n knou
# 테스트 파드 삭제
kubectl delete pods nginx
kubectl delete pods nginx -n knou




- 논리적으로 격리되어 있기 때문에 다른 네임스페이스에는 동일한 이름의 파드를 배포할 수 있지만, 같은 네임스페이스에는 동일한 파드를 배포 불가
- 쿠버네티스 사용 시 가장 많이 하는 실수 중 하나로 다른 네임스페이스에 배포하는 것

kubectl run은 명령형 커맨드일까, 선언형 커맨드일까?
kubectl run은 명령형 커맨드
CLI를 통해 직접 오브젝트를 관리하는 방식은 명령형 접근 방식에 해당
kubectl run은 YAML 파일 없이도 쿠버네티스 오브젝트를 생성하고 관리할 수 있도록 해주는 CLI 명령
특정 명령어를 실행하여 바로 Kubernetes에 오브젝트를 생성하거나 변경하는 방식을 사용
Pod
- k8s 에서 애플리케이션을 생성하고 관리할 수 있는 배포 가능한 가장 작은 단위
- 1개 이상의 컨테이너로 구성
- 동일한 파드 내의 컨테이너는 Storage, Network 를 공유
- 동일한 파드 내의 컨테이너는 항상 함께 실행
- 파드는 프로세스가 아닌 컨테이너를 실행하기 위한 환경
- 파드는 직접 생성하지 않는다! - Bare Pod
Pod 기본 사용
Pod 배포
apiVersion: v1
kind: Pod # Pod 리소스 선언
metadata:
name: nginx # Pod Name
spec:
containers:
- name: nginx # Container Name
image: nginx:alpine # Container Image
ports: # Container Port
- containerPort: 80
touch pod.yaml
# 위 yaml 파일 복사 붙여넣기
vim pod.yaml
cat pod.yaml
# 현재 pod 상태 확인
kubectl get pods -A
# pod 배포
kubectl apply -f pod.yaml
#
kubectl get pods
kubectl describe pods nginx
# 삭제
kubectl delete -f pod.yaml

?kubectl apply 는 선언형 커맨드인가?
쿠버네티스에서 리소스를 관리하기 위한 선언형 커맨드
kubectl apply는 리소스의 원하는 상태를 정의한 YAML 파일을 사용하여 리소스를 생성, 업데이트하거나 변경
Pod 로그 확인
apiVersion: v1
kind: Pod
metadata:
name: knou
namespace: knou
spec:
containers:
- name: knou
image: busybox
env: # Pod 내부 변수 선언
- name: NAME # 변수 Key
value: "gs hyung" # 변수 Value
command: ["/bin/sh"]
args: ["-c", "while true; do echo \"Hello My Name is $(NAME)\"; date; sleep 2; done"]
touch pod2.yaml
# 위 yaml 파일 복사 붙여넣기
vim pod2.yaml
cat pod2.yaml
# 현재 pod 상태 확인
kubectl get pods -A
# pod 배포
kubectl apply -f pod2.yaml
#
kubectl get pods
kubectl describe pods knou

# 로그 조회
kubectl logs knou
kubectl logs knou -f
# 삭제
kubectl delete -f pod2.yaml --force

Pod 심화 사용
컨테이너가 여러개인 Pod 배포
apiVersion: v1
kind: Pod
metadata:
name: knou-multi
spec:
containers:
- name: nginx
image: nginx
- name: redis
image: redis
touch multi.yaml
# 위 yaml 파일 복사 붙여넣기
vim multi.yaml
cat multi.yaml
# 현재 pod 상태 확인
kubectl get pods -A
# pod 배포
kubectl apply -f multi.yaml
#
kubectl get pods
kubectl describe pods knou-multi
#
kubectl delete -f multi.yaml

Side car 패턴 활용
apiVersion: v1
kind: Pod
metadata:
name: knou-mart
spec:
volumes:
- emptyDir: {}
name: varlog
containers:
- name: knou-mart
image: busybox
command:
- /bin/sh
- -c
- 'i=1; while :;do echo -e "$i: Price: $((RANDOM % 10000 + 1))" >> /var/log/knou-mart.log; i=$((i+1)); sleep 2; done'
volumeMounts:
- mountPath: /var/log
name: varlog
- name: price
image: busybox
args: [/bin/sh, "-c", 'tail -n+1 -f /var/log/knou-mart.log']
volumeMounts:
- mountPath: /var/log
name: varlog
touch sidecar.yaml
# 위 yaml 파일 복사 붙여넣기
vim sidecar.yaml
cat sidecar.yaml
# 현재 pod 상태 확인
kubectl get pods -A
# pod 배포
kubectl apply -f sidecar.yaml
#
kubectl get pods
kubectl describe pods knou-mart
# price 컨테이너 로그 조회
kubectl logs knou-mart -c price -f
#
kubectl delete -f sidecar.yaml


'끄적끄적 > IT공부' 카테고리의 다른 글
| [IT공부]Kubernetes Availablity (1) | 2025.05.11 |
|---|---|
| [IT공부]Docker-Docker Network (1) | 2025.04.17 |
