Architecture on Joonlog

Kubernetes QoS Overview

Tue, 30 Sep 2025 09:00:00 +0900

kubernetes는 노드에 리소스가 부족할 때, Pod의 QoS 클래스에 따라 어떤 Pod를 우선적으로 Eviction(퇴출)할지를 결정

QoS 클래스 종류

Guaranteed
- Pod 내 모든 컨테이너의 CPU/Memory Request와 Limit 값이 동일한 경우
- 가장 높은 우선순위를 가짐 (Eviction 대상에서 가장 안전함)
Burstable
- Guaranteed와 BestEffort에 속하지 않는 모든 경우
- 예: Request < Limit 인 경우
- 우선순위는 중간
BestEffort
- 리소스 Request와 Limit을 전혀 지정하지 않은 경우
- 가장 낮은 우선순위 (Eviction 1순위)

Eviction 동작 원리

노드에 리소스가 부족해지면, kubelet은 다음과 같은 순서로 Pod를 Eviction

우선순위: Guaranteed > Burstable > BestEffort
BestEffort
- 항상 Eviction 대상에 포함됨
Burstable
- CPU/Memory Request보다 실제 사용량이 큰 경우 Eviction 대상
Guaranteed
- Eviction 대상에서 가장 안전

주의: Request와 Limit 차이를 너무 크게 잡으면 Burstable로 분류되어 Eviction 대상

따라서 Request와 Limit은 가급적 동일하게 잡는 것이 안정적

CPU vs Memory

CPU → 압축 가능한(compressible) 리소스
- Request보다 더 쓰더라도 kubelet이 throttle(스로틀링) 해서 CPU 사용량을 줄일 수 있음
- 즉, CPU 경합이 발생해도 프로세스가 죽지는 않음
Memory, Storage → 압축 불가능한(incompressible) 리소스
- Memory 사용이 Request를 초과하면, kubelet은 해당 Pod를 Eviction시켜야 함
- Storage도 마찬가지로 강제 종료가 필요할 수 있음

EX) Guaranteed Pod

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: v1
kind: Pod
metadata:
 name: guaranteed-pod
spec:
 containers:
 - name: nginx
 image: nginx
 resources:
 requests:
 memory: "512Mi"
 cpu: "500m"
 limits:
 memory: "512Mi"
 cpu: "500m"

Request = Limit 이므로 QoS = Guaranteed

EX) Burstable Pod

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: v1
kind: Pod
metadata:
 name: burstable-pod
spec:
 containers:
 - name: nginx
 image: nginx
 resources:
 requests:
 memory: "256Mi"
 cpu: "250m"
 limits:
 memory: "512Mi"
 cpu: "500m"

Request < Limit 이므로 QoS = Burstable

EX) BestEffort Pod

1
2
3
4
5
6
7
8


apiVersion: v1
kind: Pod
metadata:
 name: besteffort-pod
spec:
 containers:
 - name: nginx
 image: nginx

Request/Limit 미지정 → QoS = BestEffort

Pod QoS Class 확인 방법

1

kubectl get pod {POD_NAME} -o jsonpath='{ .status.qosClass}{"\n"}'

정리

QoS 클래스는 Pod의 리소스 보장 수준
Eviction 순서: Guaranteed > Burstable > BestEffort
CPU는 throttle 가능(죽지 않음), Memory/Storage는 Eviction 발생
안정적인 서비스 운영을 위해 Request와 Limit을 동일하게 설정하는 것이 가장 안전

참고 자료

Kubernetes 인증 / 권한 관리 Overview

Tue, 23 Sep 2025 09:00:00 +0900

kubernetes에서 kubectl 같이 클라이언트나 파드 내부에서 API 서버에 접근할 때는 인증과 권한이 필요

접근 제어

User/Group → 인증

인증서는 클라이언트 신원을 확인하는 데 사용
- ex) kubectl get nodes 실행 시 사용자 인증 필요
인증서(certificate)를 kubeconfig에 등록하여 사용

ServiceAccount → 권한

파드 내부에서 쿠버네티스 API를 호출할 때 사용
- Pod 실행 시 자동으로 토큰이 /var/run/secrets/kubernetes.io/serviceaccount/token 에 마운트
파드 내부에서 자동으로 마운트되거나 Secret을 통해 주입

사용자 생성 절차

개인키 생성
CSR 생성

CSR 요청 및 승인

1
2


kubectl apply -f csr.yaml
kubectl certificate approve myuser-csr

Role/RoleBinding 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: default
 name: pod-reader
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "list"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: read-pods
 namespace: default
subjects:
- kind: User
 name: myuser
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

kubeconfig에 사용자 추가

1

kubectl config set-credentials myuser --client-certificate=user.crt --client-key=user.key

context 변경

1
2


kubectl config set-context myuser-context --cluster=mycluster --namespace=default --user=myuser
kubectl config use-context myuser-context

서비스 어카운트 생성 절차

서비스 어카운트 생성

1

kubectl create serviceaccount mysa -n default

Rolebinding 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: sa-read-pods
 namespace: default
subjects:
- kind: ServiceAccount
 name: mysa
 namespace: default
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

pod 실행시 서비스 어카운트 지정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: v1
kind: Pod
metadata:
 name: test-pod
spec:
 serviceAccountName: mysa
 containers:
 - name: curl
 image: curlimages/curl
 command: ["sleep", "3600"]

권한 관리(RBAC)

Role
- 네임스페이스 단위 권한
  - ex) default namespace에서 pod 읽기
RoleBinding
- Role을 특정 User/Group/ServiceAccount에 바인딩
ClusterRole
- 클러스터 전체 권한
  - ex) 모든 namespace에서 pod 읽기
ClusterRoleBinding
- ClusterRole을 User/Group/ServiceAccount에 바인딩

Kubernetes Pod Scheduling Overview

Fri, 19 Sep 2025 09:00:00 +0900

k8s scheduler가 어떤 기준으로 파드를 노드에 배치하는지에 대한 정리

Node Affinity

지정된 조건에 맞는 노드에 파드를 배포

disktype=ssd label이 있는 노드에만 스케줄링

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: v1
kind: Pod
metadata:
 name: web-pod
spec:
 affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: disktype
 operator: In
 values:
 - ssd
 containers:
 - name: web
 image: nginx

Pod Affinity

pod를 가까이 배치(ex: 같은 노드에 배치)

app=db label이 붙은 파드와 같은 노드에 배치
- 반대로 podAntiAffinity를 쓰면 다른 노드에 배치 가능

1
2
3
4
5
6
7
8
9


podAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values:
 - db
 topologyKey: "kubernetes.io/hostname"

Taint & Toleration

nodeselector: 노드레이블이 지정된 노드에 파드를 배포할 때 사용
node taint: 노드에 파드를 배포되지 않도록 할 때 사용
- node taint 추가 명령어
1

kubectl taint nodes node1 key=value:NoSchedule
pod toleration: node taint가 설정된 노드에 배포하고 싶을 때 사용
- pod 매니페스트 내 toleration 설정
  - 이 파드는 위 node1에 배치 가능
1 2 3 4 5

tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule"

Cordon/Uncordon & Drain

cordon: 지정된 노드에 파드 배포 금지
1

kubectl cordon node1
uncordon: 지정된 노드에 파드 배포 금지 해제
1

kubectl uncordon node1
drain: 지정된 노드에 모든 파드 삭제
1

kubectl drain node1 --ignore-daemonsets

Kubernetes Autoscaling Overview

Fri, 22 Aug 2025 09:00:00 +0900

오토스케일링 종류

클러스터 레벨 오토스케일링
- 노드 풀의 VM 개수를 오토스케일링
- 클라우드 프로바이더와 같은 환경에서만 가능(EKS, GKE, AKS 등)
파드 레벨 오토스케일링
- 파드의 개수를 오토스케일링

수평적 파드 오토스케일링(HPA)

metrics-server 애드온이 필요
- 각 노드/파드가 사용하는 매트릭(CPU/MEM) 모니터링하고 데이터 수집하는 역할

동작원리

HPA 컨트롤러가 metrics-server에서 Pod 매트릭을 주기적으로 수집하고, 사전에 설정한 임계치 조건을 만족하면 파드의 개수를 자동으로 조정

HPA 동작 조건

기본값 30초 간격으로 Pod 사용량을 점검
임계값을 초과하면 Pod scale out
확장된 이후 3분 대기, scale in은 확장 이후 5분 대기

예시

myapp Deployment가 CPU 사용 평균 50%를 넘기면 Pod 개수가 늘어남
만약 CPU 사용률이 낮아지면, 5분 이후 Pod 개수를 줄임
Pod 개수는 최소 2개, 최대 10개 사이에서 조정됨

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: myapp-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: myapp
 minReplicas: 2
 maxReplicas: 10
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 50

애플리케이션 지표 기반 오토스케일링도 가능하지만, prometheus와 같은 툴과 연동 필요

Kubernetes Storage Overview

Thu, 21 Aug 2025 09:00:00 +0900

Pod에서 볼륨 선언 → 마운트가 기본 패턴
- spec.volumes에서 볼륨 선언 후 spec.containers.volumeMounts 에서 마운트

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


apiVersion: v1
kind: Pod
metadata:
 name: demo-pod
spec:
 containers:
 - name: app
 image: nginx:1.25
 volumeMounts:
 - name: html
 mountPath: /usr/share/nginx/html
 volumes:
 - name: html
 hostPath:
 path: /home/
 type: DirectoryOrCreate

볼륨 유형

타입	사용 용도	비고
emptyDir	Pod 수명=데이터 수명. 임시 공간	Pod 종료 시 데이터 없어짐
hostPath	노드 로컬 경로를 Pod에 마운트	데이터가 특정 워커노드에 종속됨
configMap / secret	변수를 파일로 주입	주로 읽기 전용으로 마운트
nfs	NAS 마운트	멀티 Pod 간 데이터 공유에 사용
CSI 기반 블록 / 파일	AWS EDB, GCE PD 등	대부분 CSI 드라이버로 제공
동적 프로비저닝 가능

예시: emptyDir / configMap / secret

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# emptyDir
volumes:
 - name: work
 emptyDir: {}

# configMap
volumes:
 - name: app-config
 configMap:
 name: my-config

# secret
volumes:
 - name: app-secret
 secret:
 secretName: db-cred

PV & PVC

PV(PersistentVolume): 클러스터에 영구 스토리지 리소스를 생성
PVC(PersistentVolumeClaim): 생성한 PV에서 자원 할당 요청

접근 모드

ReadWriteOnce(RWO): 한 노드에서 읽기/쓰기
ReadOnlyMany(ROX): 여러 노드에서 읽기 전용
ReadWriteMany(RWX): 여러 노드에서 읽기/쓰기
- ex) NFS, EFS
pv/pvc 예시
- persistentVolumeReclaimPolicy 기본값은 동적 프로비저닝이면 Delete인 경우가 많고, 중요한 데이터면 Retain 고려

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# 1) PV: NFS 예시
apiVersion: v1
kind: PersistentVolume
metadata:
 name: pv-nfs
spec:
 capacity:
 storage: 20Gi
 accessModes: [ReadWriteMany]
 persistentVolumeReclaimPolicy: Retain
 nfs:
 path: /export/apps
 server: 10.0.0.10

---
# 2) PVC: 위 PV에 바인딩될 요청
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-nfs
spec:
 accessModes: [ReadWriteMany]
 resources:
 requests:
 storage: 20Gi

StorageClass

디스크 타입, 복제/백업 정책, 토폴로지 등의 프로비저닝에 필요한 파라미터를 묶어서 제공
사용자는 PVC에서 StorageClassName에만 지정하면 볼륨이 동적 프로비저닝됨
사용을 위해선 NFS Provisioner, EBS Driver와 같은 툴 설치 필요

kube-proxy 모드(iptables vs IPVS)

Tue, 19 Aug 2025 09:00:00 +0900

Kubernetes kube-proxy: iptables vs IPVS

K8S에서 Service를 만들면, 클러스터 내부 Pod는 ClusterIP를 통해 접근 가능
- 이때 트래픽을 실제 Pod로 보내주는 역할을 하는 게 kube-proxy
kube-proxy는 iptables 모드와 IPVS 모드 두가지 모드 중 하나로 동작 가능

iptables 모드

K8S 초창기부터 기본으로 사용된 방식

동작 원리
- service/endpoint 정보를 iptables 규칙에 직접 기록
- 커널이 NAT 체인을 따라가면서 Pod로 트래픽을 전송
장점
- 별도 모듈 설치 없이 바로 사용 가능
- 오래 쓰여온 만큼 안정적이고, 문제 생겼을 때 iptables -t nat -L -n 으로 바로 확인 가능
단점
- 엔드포인트 수가 많아지면 규칙도 폭발적으로 늘어나 성능 저하가 생길 수 있음
- 규칙을 갱신할 때 전체 체인을 다시 써야 해서 순간 부하 발생

IPVS 모드

리눅스 커널의 IPVS 기능을 사용

동작 원리
- ip_vs 모듈을 이용해 L4 로드밸런서처럼 동작
- kube-proxy는 service/endpoint를 커널에 등록만 해두고, 실제 트래픽 처리는 커널이 빠르게 처리
장점
- 수천~수만 엔드포인트까지 안정적으로 처리 가능
- 엔드포인트 변경 시 필요한 부분만 업데이트 → 부하 적음
- 라운드로빈, 세션 해시 등 다양한 로드밸런싱 알고리즘 지원
단점
- 커널 모듈(ip_vs)과 유틸리티(ipvsadm, ipset) 설치 필요
- iptables에 비해 디버깅이 낯설 수 있음 (ipvsadm -Ln 확인 필요)

선택 기준

iptables 모드
- 수십~수백 노드, 수천 개 엔드포인트 수준
- 운영 단순성, 문제 대응 속도 중시
IPVS 모드
- 수천 노드 이상, 서비스 엔드포인트 수가 수만 단위
- 대규모 SaaS 환경, 트래픽이 매우 많은 서비스
- 고급 로드밸런싱(세션 어피니티 등) 필요한 경우

kubespray는 기본적으로 IPVS로 동작

Kubernetes ConfigMap과 Secret

Sun, 17 Aug 2025 09:00:00 +0900

Kubernetes에서 애플리케이션을 배포할 때 환경변수나 설정 등을 관리하는 방법
- Pod yaml에 직접 값을 적을수도 있지만 재사용/보안을 위해 ConfigMap/Secret을 사용

Configmap

key-value 쌍으로 정의
DB 호스트, 포트, 로그 레벨 등의 민감하지 않은 설정 값을 저장할 때 사용

예시 - 환경변수

ConfigMap

1
2
3
4
5
6
7
8


apiVersion: v1
kind: ConfigMap
metadata:
 name: app-config
 namespace: demo
data:
 APP_MODE: "production"
 LOG_LEVEL: "debug"

Pod

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: Pod
metadata:
 name: sample-pod
 namespace: demo
spec:
 containers:
 - name: sample-app
 image: nginx
 envFrom:
 - configMapRef:
 name: app-config

예시 - 파일 형태로 마운트

ConfigMap

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: v1
kind: ConfigMap
metadata:
 name: nginx-config
data:
 nginx.conf: |
 events {}
 http {
 server {
 listen 80;
 location / {
 return 200 'Hello ConfigMap!';
 }
 }
 }

Pod

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


volumes:
 - name: config-volume
 configMap:
 name: nginx-config
containers:
 - name: nginx
 image: nginx
 volumeMounts:
 - mountPath: /etc/nginx/nginx.conf
 subPath: nginx.conf
 name: config-volume

Secret

key-value 쌍으로 정의
Base64로 인코딩하여 저장
비밀번호, 인증 토큰, TLS 키 등 민감한 데이터를 저장할 때 사용
AWS Secrets Manager, Vault와 같은 Secret CSI Driver을 연동해서 사용 가능

예시 - 환경변수

ConfigMap

1
2
3
4
5
6
7
8


apiVersion: v1
kind: Secret
metadata:
 name: db-secret
type: Opaque
data:
 username: ZGJ1c2Vy # "dbuser" → base64 인코딩
 password: c2VjcmV0MTIz # "secret123"

Pod

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


containers:
 - name: db-client
 image: postgres
 env:
 - name: DB_USER
 valueFrom:
 secretKeyRef:
 name: db-secret
 key: username
 - name: DB_PASS
 valueFrom:
 secretKeyRef:
 name: db-secret
 key: password

예시 - 도커 레지스트리 인증 정보

Secret

1
2
3
4
5
6
7


apiVersion: v1
kind: Secret
metadata:
 name: regcred
type: kubernetes.io/dockerconfigjson
data:
 .dockerconfigjson: <Base64-encoded-json>

Kubernetes Label과 Annotation

Sun, 17 Aug 2025 09:00:00 +0900

LoadBalancer

L4 - NLB + Service의 LoadBalancer

웹서버가 아닌 백엔드 서비스(API, DB 프록시 등)에 대한 부하 분산에 적합

TCP/UDP 레벨에서 패킷을 라우팅
L7 - ALB + Ingress

웹 애플리케이션 HTTP/HTTPS 트래픽 부하 분산에 적합

URL 경로, 호스트명 등 애플리케이션 계층의 규칙 기반 라우팅 가능

Ingress

트래픽 부하 분산 (HTTP/HTTPS)
경로 기반 라우팅

예: /, /home, /pay, /login
도메인 기반 라우팅

예: www.example.com, www.test.com
SSL/TLS 인증서 처리

HTTPS 통신을 위한 인증서 설치 및 자동 갱신(Let’s Encrypt 등과 연계 가능)

경로 기반 라우팅 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: path-based-ingress
spec:
 ingressClassName: nginx
 rules:
 - host: shop.example.com
 http:
 paths:
 - path: /products
 pathType: Prefix
 backend:
 service:
 name: product-service
 port:
 number: 80
 - path: /orders
 pathType: Prefix
 backend:
 service:
 name: order-service
 port:
 number: 80

호스트 기반 라우팅 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: host-based-ingress
spec:
 ingressClassName: nginx
 rules:
 - host: api.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: api-service
 port:
 number: 80
 - host: admin.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: admin-service
 port:
 number: 80

Ingress Architecture

Client(HTTP/HTTPS) → Ingress Controller(Ingress Rules 라우팅) → Service(ClusterIP) → Pod

Ingress Controller
- Ingress 리소스에 정의된 Ingress Rules를 읽고 동작
  - Input:
  - Output: :80
- 실제 트래픽은 Service(ClusterIP)를 통해 Pod로 전달
Service (ClusterIP)
- Input: :80
- Output: <pod’s label>:80
Deployment(ReplicaSet, Pod)
- 여러 Pod를 레플리카로 생성해 무중단 운영 가능

Ingress Controller 종류

로컬(Kubernetes On-Prem, Minikube 등) → NGINX Ingress Controller 사용
AWS EKS → AWS Load Balancer Controller(ALB 기반) 사용
- ALB와 연동해 L7 라우팅 처리
- ACM(AWS Certificate Manager)로 TLS 인증서 관리 가능

Kubernetes Ingress Overview

Wed, 13 Aug 2025 09:00:00 +0900

LoadBalancer

L4 - NLB + Service의 LoadBalancer

웹서버가 아닌 백엔드 서비스(API, DB 프록시 등)에 대한 부하 분산에 적합

TCP/UDP 레벨에서 패킷을 라우팅
L7 - ALB + Ingress

웹 애플리케이션 HTTP/HTTPS 트래픽 부하 분산에 적합

URL 경로, 호스트명 등 애플리케이션 계층의 규칙 기반 라우팅 가능

Ingress

트래픽 부하 분산 (HTTP/HTTPS)
경로 기반 라우팅

예: /, /home, /pay, /login
도메인 기반 라우팅

예: www.example.com, www.test.com
SSL/TLS 인증서 처리

HTTPS 통신을 위한 인증서 설치 및 자동 갱신(Let’s Encrypt 등과 연계 가능)

경로 기반 라우팅 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: path-based-ingress
spec:
 ingressClassName: nginx
 rules:
 - host: shop.example.com
 http:
 paths:
 - path: /products
 pathType: Prefix
 backend:
 service:
 name: product-service
 port:
 number: 80
 - path: /orders
 pathType: Prefix
 backend:
 service:
 name: order-service
 port:
 number: 80

호스트 기반 라우팅 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: host-based-ingress
spec:
 ingressClassName: nginx
 rules:
 - host: api.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: api-service
 port:
 number: 80
 - host: admin.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: admin-service
 port:
 number: 80

Ingress Architecture

Client(HTTP/HTTPS) → Ingress Controller(Ingress Rules 라우팅) → Service(ClusterIP) → Pod

Ingress Controller
- Ingress 리소스에 정의된 Ingress Rules를 읽고 동작
  - Input:
  - Output: :80
- 실제 트래픽은 Service(ClusterIP)를 통해 Pod로 전달
Service (ClusterIP)
- Input: :80
- Output: <pod’s label>:80
Deployment(ReplicaSet, Pod)
- 여러 Pod를 레플리카로 생성해 무중단 운영 가능

Ingress Controller 종류

로컬(Kubernetes On-Prem, Minikube 등) → NGINX Ingress Controller 사용
AWS EKS → AWS Load Balancer Controller(ALB 기반) 사용
- ALB와 연동해 L7 라우팅 처리
- ACM(AWS Certificate Manager)로 TLS 인증서 관리 가능

Kubernetes Service Overview

Tue, 12 Aug 2025 09:00:00 +0900

Pod 그룹에 대해 단일 진입점(VIP) 제공
외부에서 클러스터 내에 파드 그룹에 접근할 수 있도록 기능 제공

서비스 종류

ClusterIP ⇒ (외부 → 내부) VIP
NodePort ⇒ (외부 → 내부) VIP + NodePort
LoadBalancer ⇒ (외부 → 내부) VIP + NodePort + LB IP
ExternalName ⇒ (내부 → 외부) 도메인 매핑

ClusterIP

Pod그룹에 대해 단일 진입점(VIP)을 제공
VIP는 사설 IP로 제공됨

~/root/kubespray/inventory/mycluster/group_vars/k8s_cluster

1
2


kube_service_addresses: 10.233.0.0/18
kube_pods_subnet: 10.233.64.0/

예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: Service
metadata:
 name: my-clusterip-service
spec:
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 type: ClusterIP

NodePort

Pod그룹에 대해 단일 진입점(VIP)을 제공
노드의 IP:Port(30000 ~ 32727)로 요청하면 Pod 그룹(같은 Label)에 대한 부하 분산을 제공

예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: Service
metadata:
 name: my-nodeport-service
spec:
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 nodePort: 30080
 type: NodePort

LoadBalancer

Pod그룹에 대해 단일 진입점(VIP)을 제공
노드의 IP:Port(30000 ~ 32727)로 요청하면 Pod 그룹(같은 Label)에 대한 부하 분산을 제공
클라우드 환경(AWS ELB, GCP LB, Azure LB) 또는 MetalLB/HAProxy 등의 On-premise LB 사용

예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: Service
metadata:
 name: my-lb-service
spec:
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 type: LoadBalancer

ExternalName - DNS CNAME 역할

(내부 → 외부/내부) DNS CNAME 등록 작업(서비스 이름 ← 매핑 → DNS 이름) (pod 예) .default.pod.cluster.local ← 매핑 → google.com (service 예) .default.svc.cluster.local ← 매핑 → google.com

예시

1
2
3
4
5
6
7


apiVersion: v1
kind: Service
metadata:
 name: my-external-service
spec:
 type: ExternalName
 externalName: google.com

헤드리스 서비스

단일 진입점이 필요 없는 경우에 사용 (clusterIP: None)
각 Pod의 IP가 DNS A 레코드로 직접 등록됨
주로 StatefulSet(DB, Kafka 등)에서 사용

예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: Service
metadata:
 name: my-headless-service
spec:
 clusterIP: None
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080

네트워크

kube-proxy
- worker node안에 pod에 연결할 때 사용하는 네트워크를 담당
- Masquerading (IP 변환)
- Load Balancing (포트포워딩)
kube-proxy 모드
- iptables 모드 ⇒ iptables CMD
- ipvs 모드 ⇒ ipvsadm CMD

Kubernetes Workload Overview

Mon, 11 Aug 2025 09:00:00 +0900

ReplicaSet

동일한 스펙의 Pod를 지정된 개수만큼 유지
집합 기반 셀렉터(Set-based selector)
rolling update 지원
직접 쓰기보다는 Deployment 내부에서 주로 사용됨

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: my-replicaset
spec:
 replicas: 3
 selector:
 matchExpressions:
 - key: app
 operator: In
 values: ["web", "api"]
 template:
 metadata:
 labels:
 app: web
 spec:
 containers:
 - name: nginx
 image: nginx:1.27

Deployment

ReplicaSet을 관리하며 Pod의 개수를 보장
Pod에 대한 rolling update/rollback 기능 지원
무중단 파드 배포를 위해 사용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-deployment
spec:
 replicas: 3
 selector:
 matchLabels:
 app: web
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxUnavailable: 1
 maxSurge: 1
 template:
 metadata:
 labels:
 app: web
 spec:
 containers:
 - name: nginx
 image: nginx:1.27

DaemonSet

하나의 노드당 1개의 Pod 실행(controlplane 제외)
Rolling Update / Rollback 기능 지원
데몬셋 용도: (관리) ex) 모니터링 Pod 실행

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: node-monitor
spec:
 selector:
 matchLabels:
 app: node-monitor
 template:
 metadata:
 labels:
 app: node-monitor
 spec:
 containers:
 - name: node-exporter
 image: prom/node-exporter:latest

StatefulSet

State가 필요한 워크로드에 사용(Pod 이름, 스토리지 고정)
고유 네트워크 ID, 안정적인 스토리지, 순차 배포/종료 보장
주로 DB, 메시지 큐, Zookeeper, Kafka 등에 사용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web-stateful
spec:
 serviceName: "web"
 replicas: 3
 selector:
 matchLabels:
 app: web
 template:
 metadata:
 labels:
 app: web
 spec:
 containers:
 - name: nginx
 image: nginx:1.27
 volumeClaimTemplates:
 - metadata:
 name: www
 spec:
 accessModes: ["ReadWriteOnce"]
 resources:
 requests:
 storage: 1Gi

Job

트랜잭션의 단위
잡이 성공적으로 종료 될 때 까지 지속적으로 파드 실행
잡이 성공하면 completed
잡은 실패하면 종료 후 다시 실행

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: batch/v1
kind: Job
metadata:
 name: data-migration
spec:
 backoffLimit: 3
 template:
 spec:
 containers:
 - name: migrate
 image: busybox
 command: ["sh", "-c", "echo Running migration... && sleep 10"]
 restartPolicy: OnFailure

CronJob

Job 컨트롤러를 사용하여 애플리케이션 파드를 주기적으로 반복해서 실행
Job이 종료되면 스케쥴링에 의해 주기적으로 실행
Job이 비정상 종료되면 다시 실행

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


apiVersion: batch/v1
kind: CronJob
metadata:
 name: db-backup
spec:
 schedule: "0 2 * * *" # 매일 새벽 2시
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: backup
 image: busybox
 command: ["sh", "-c", "echo Backing up DB... && sleep 5"]
 restartPolicy: OnFailure

Kubernetes Pod Overview

Wed, 06 Aug 2025 09:00:00 +0900

Pod

컨테이너를 추상화 시켜 놓은 단위
k8s에서 배포하는 최소 단위
하나의 Pod에는 여러 Container가 들어 갈 수 있다
Pod는 하나의 IP를 갖는다

Multi-Container Pod

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


Liveness Probe
- httpGet
 - livenessProbe:
 httpGet:
 path: /
 port: 80
- tcpSocket
 - livenessProbe:
 tcpSocket:
 port: 22
- exec:
 - livenessProbe:
 exec:
 command:
 - ls
 - /tmp/datafile

Liveness Probe Parameter
- initialDelaySeconds: 0
- periodSeconds: 5
- timeoutSeconds: 1
- successThreshold: 1
- failureThreshold: 2

initcontainer

앱 컨테이너가 동작하기 위한 전초 작업을 위한 컨테이너

(WEB-DB) 환경의 WEB 컨테이너에서 DB 컨테이너가 기동되었는지를 위한 작업
(Network) 네트워크 인프라 점검을 위한 전초 작업

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


spec:
 containers:
 - name: myapp-container
 image: busybox:1.28
 command: ['sh', '-c', 'echo The app is running! && sleep 3600']
 initContainers:
 - name: init-myservice
 image: busybox:1.28
 command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
 - name: init-mydb
 image: busybox:1.28
 command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

Infra/pause container

앱컨테이너의 인프라를 생성 및 삭제를 담당하는 컨테이너

Static Pod

/var/lib/kubelet/config.yaml
- staticPodPath: /etc/kubernetes/manifests

Pod 자원 할당

자원 할당

cpu(단위: 1core/1vCPU = 1000m)
mem(단위: 500Mi, 1Gi, ..)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


apiVersion: v1
kind: Pod
metadata:
 name: nginx-pod-resources
spec:
 containers:
 - name: nginx-container
 image: nginx:1.14
 ports:
 - containerPort: 80
 protocol: TCP
 resources:
 requests:
 cpu: 200m
 memory: 250Mi
 limits:
 cpu: 1
 memory: 1Gi

Pod 환경 변수

환경 변수 설정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


kind: Pod
apiVersion: v1
metadata:
 name: mysql-env-pod
spec:
 containers:
 - name: mysql-container
 image: mysql
 ports:
 - containerPort: 3306
 protocol: TCP
 env:
 - name: MYSQL_ROOT_PASSWORD
 value: "password"

디자인 패턴

사이드카 - 협업
어댑터 - 입력 표준화
앰버서더 - 출력 표준화

Kubernetes 아키텍쳐

Mon, 04 Aug 2025 09:00:00 +0900

Master Node

kube-apiserver

Kubernetes 클러스터의 프론트엔드입니다.
REST API를 통해 클러스터 상태를 읽고 조작하는 모든 요청을 처리합니다.

kubectl

kubectl은 kube-apiserver에 요청을 보냅니다. (예: kubectl get nodes)
또는, kubectl을 사용하지 않고도 직접 kube-apiserver에 요청을 보낼 수 있습니다.

controller-manager

클러스터의 상태를 지속적으로 모니터링하고, 원하는 상태를 유지합니다.
다양한 컨트롤러들(잡, 노드, 서비스 계정, 엔드포인트)을 관리하여 리소스의 상태를 조정합니다.

kube-scheduler

스케줄러는 새로 생성된 Pod를 워커 노드에 배치하는 역할을 합니다.
Pod의 리소스 요구사항과 각 노드의 리소스 가용성을 고려해 최적의 노드에 배치합니다.

ETCD

Kubernetes의 클러스터 데이터를 저장하는 분산 key-value 데이터베이스입니다.
클러스터의 현재 상태, 구성 정보, 시크릿, ConfigMap 등을 저장하는 데 사용됩니다.

Worker Node

kubelet

각 워커 노드에서 실행되며, API 서버와 통신하면서 Pod의 라이프사이클을 관리합니다.
kube-scheduler가 할당한 작업을 워커 노드에서 실행합니다.

kube-proxy

네트워크 트래픽을 라우팅하고 로드밸런싱하는 데 사용되는 기본 네트워크 프록시입니다.
Pod과 서비스 간의 통신 규칙을 설정합니다.

container runtime

실제 컨테이너를 실행하는 소프트웨어입니다.
Containerd, CRI-O 등이 Kubernetes에서 사용될 수 있으며, 컨테이너 이미지를 다운로드하고 실행, 관리하는 역할을 합니다.

Addons

CoreDNS

클러스터 내에서 서비스 디스커버리와 DNS 네임 리졸버를 제공합니다
이를 통해 서비스 이름을 클러스터 내부의 IP로 변환할 수 있습니다.

CNI

네트워크를 관리하기 위한 표준 인터페이스입니다.
각 Pod에 IP 주소를 할당해서, 다른 Pod와의 통신을 가능하게 만듭니다.
대표적인 플러그인으로는 Calico, Flannel 등이 있습니다.