IT모저모

JWT 구조 및 Token 발급 과정

얀타호수 — Wed, 12 Nov 2025 10:40:49 +0900

JWT(JSON Web Token)는 “JSON 형태로 표현된 웹 토큰” 입니다.

JWT는 인증(Authentication)과 인가(Authorization)를 위해 사용되는 토큰 기반 인증 방식입니다ㅓ.
사용자가 로그인하면 서버가 “이 사용자는 인증된 사용자임”을 증명하는 서명된 토큰을 만들어 주고
이 토큰을 클라이언트가 이후 요청마다 들고 다니면서 인증을 대신합니다.

출처: Google

1️⃣ JWT 구조 이해

JWT는 세 부분으로 나뉩니다.

Header: 토큰 타입(JWT)과 해시 알고리즘(예: HS256) 정의
Payload: 토큰에 담길 정보(claims) — 보통 sub, iat, exp, role 등
Signature: Header와 Payload를 합쳐 비밀키로 서명한 값, 토큰 변조 방지용

HEADER.PAYLOAD.SIGNATURE

2️⃣ 사용자 인증

JWT 발급의 첫 단계는 사용자 인증입니다.

클라이언트가 로그인 요청을 보냅니다.
서버에서 전달받은 username과 password를 DB에서 조회 후 검증합니다.

패스워드는 일반적으로 BCrypt 등으로 암호화 되어 있어, passwordEncoder.matches(rawPassword, encodedPassword)로 비교합니다.
인증 실패 시 401을 반환합니다.

POST /login
Content-Type: application/json

{
  "username": "user1",
  "password": "1234"
}

3️⃣ JWT 토큰 생성

사용자 인증이 성공하면 서버가 JWT를 발급합니다.

JWT 생성 흐름:

Header: 토큰 타입과 해시 알고리즘 지정
Payload: 사용자 정보 및 토큰 만료 시간 등 정의
Signature: Header + Payload를 비밀키로 서명

4️⃣ 클라이언트에 토큰 전달

서버는 생성된 JWT를 HTTP 응답으로 반환합니다.
또는 Authorization 헤더에 포함시켜 반환 가능

{
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

HTTP/1.1 200 OK
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

5️⃣ 서버 내부 처리 요약

서버 관점에서 JWT 발급 과정은 다음과 같습니다:

로그인 요청 수신
사용자 인증 (DB 조회 + 비밀번호 검증)
JWT 토큰 생성
- Header, Payload 구성
- 비밀키로 서명
클라이언트에 JWT 반환

서블릿 컨테이너 로드 순서

얀타호수 — Wed, 12 Nov 2025 10:30:50 +0900

“서블릿 로드(loading)” 과정은 서블릿 컨테이너(Tomcat, Jetty 등)가

서블릿 클래스를 메모리에 올리고 초기화하는 전 과정을 말합니다.
즉, “클라이언트 요청을 처리하기 전에 서블릿이 어떻게 준비되는가”에 대한 과정이다.

클라이언트 요청
   ↓
웹 서버 (ex: Tomcat)
   ↓
서블릿 컨테이너
   ↓
서블릿 로드 → 인스턴스 생성 → 초기화(init)
   ↓
요청 처리(service → doGet/doPost)
   ↓
종료(destroy)

1️⃣ 서블릿 클래스 로드 (Class Loading)

Servlet Container가 web.xml 또는 @WebServlet 어노테이션을 보고 해당 서블릿 클래스를 식별합니다.
아직 요청이 오지 않은 상태에서는 클래스를 메모리에 올리지 않을 수도 있음.
- load-on-startup 설정이 없으면, 첫 요청이 들어올 때 로드됨 (lazy loading).
- load-on-startup 설정이 있으면, 컨테이너가 서버 시작 시점에 미리 로드함 (eager loading).

2️⃣ 인스턴스 생성 (Instantiation)

클래스가 로드되면, 컨테이너는 서블릿 객체를 1회만 생성(new) 합니다.
서블릿 인스턴스는 일반적으로 싱글톤(1개만 존재) 형태로 관리됩니다.

HelloServlet servlet = new HelloServlet();

3️⃣ 초기화 (Initialization)

인스턴스가 생성되면, 컨테이너가 init() 메서드를 호출합니다.
서블릿의 초기 설정(예: DB 연결, 설정 로드 등)은 여기서 수행합니다.
이 단계는 서블릿 생명주기에서 단 한 번만 호출됩니다.

public void init() throws ServletException {
    // 초기화 코드
    System.out.println("서블릿 초기화 완료");
}

4️⃣ 요청 처리 (Service 단계)

초기화가 완료된 후 클라이언트 요청이 들어오면 컨테이너는 service() 메서드를 호출합니다.
HttpServlet의 경우 내부에서 자동으로 **doGet() / doPost()**로 분기됩니다.

public void service(ServletRequest req, ServletResponse res) {
    // 요청 방식(GET, POST 등)에 따라 분기
}

5️⃣ 종료 (Destroy)

컨테이너가 종료되거나 서블릿이 언로드될 때 destroy() 호출.
리소스 해제, 연결 종료 등 정리 작업을 수행합니다.

public void destroy() {
    System.out.println("서블릿 종료");
}

⚙️ 정리 요약표

단계메서드실행 시점호출 횟수

1	Class Loading	첫 요청 시 또는 서버 시작 시(load-on-startup 설정 시)	1회
2	Instantiation	클래스 로드 후	1회
3	init()	인스턴스 생성 직후	1회
4	service()	매 요청 시	요청마다
5	destroy()	서버 종료 또는 서블릿 제거 시	1회

서버 로그로 본다면 이런 순서로 나타납니다

[INFO] HelloServlet 클래스 로드됨
[INFO] HelloServlet 인스턴스 생성됨
[INFO] init() 호출 - 초기화 수행
[INFO] service() 호출 - 클라이언트 요청 처리
[INFO] destroy() 호출 - 종료 처리

[Kubernetes] deployment 전략, rolling update, blue/green 정책

얀타호수 — Mon, 15 Sep 2025 09:38:35 +0900

deployment 전략은 주로 애플리케이션이 변경될 때 사용한다.

이전 버전의 애플리케 이션에서 업데이트가 필요한 경우에 주로 사용되며, 배포 방법으로는 롤링, 재생성, blue/green 정책, 카나리가 있다.

Rolling update
롤링(rolling) 업데이트는 새 버전의 애플리케이션(파드)을 배포할 때 새 버전의 애플리케이 션은 하나씩 늘려가고 기존 버전의 애플리케이션은 하나씩 줄여나가는 방식으로, 쿠버네티스 에서 사용하는 표준 배포 방식이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%				#업데이트 중에 만들 수 있는 파드의 최대 개수
      maxUnavailable: 25%		#업데이트 중에 사용할 수 없는 파드의 개수, 
      							#0보다 큰 정수를 지정할 수 있고 퍼센트로 지정할 수도 있다.
  selector:
    matchLabels:
      app: rolling
  template:
    metadata:
      labels:
        app: rolling
    spec:
      containers:
        - name: rolling
          image: myimage
          ports:
            - containerPort: 8080

Blue/Green 정책
블루/그린(blue/green) 업데이트는 애플리케이션의 이전 버전(블루, V1 파드)과 새 버전(그 린, V2 파드)이 동시에 운영된다. 하지만 서비스 목적으로 접속할 수 있는 것은 새 버전의 파드만 가능하며 이전 버전의 파드는 테스트 목적으로만 접속할 수 있다.

장점: 새로운 버전의 파드에 문제가 발생했을 때 빠르게 대응할 수 있으며 안정적으로 배포할 수 있다.
단점: 많은 파드가 필요하므로 그만큼 많은 자원(CPU, 메모리)이 필요하다.

Canary 정책
카나리(canary)는 블루/그린과 비슷하지만 새 버전에는 조금씩 트래픽을 증가시켜 새로운 기 능등을 테스트한다. 기능 테스트가 끝나고 새 버전에 문제가 없다고 판단하면 이전 버전은 모두 종료시키고 새 버전으로만 서비스한다.

[Kubernetes] Replicaset 레플리카셋 생성, 삭제, 정보 확인하기

얀타호수 — Tue, 9 Sep 2025 15:41:23 +0900

https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicaset/

레플리카셋

레플리카셋의 목적은 레플리카 파드 집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 레플리카셋은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다. 레플리카셋의

kubernetes.io

Replicaset 이란?

일정한 개수의 동일한 파드가 항상 실행되도록 관리한다. 이러한 기능이 필요한 이유는 서비스의 지속성 때문!

이미지상 맨 좌측에 레플리카셋 안에 파드1, 파드2는 -replicas=2 라는 옵션입니다.

제가 replicas:3 옵션을 주어서 이 yaml파일을 통해 레플리카셋을 생성한다면

같은 이미지로 3개의 파드가 생기겠죠? 테스트해보겠습니다.

$ cat replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: 3-replicaset
spec:
  template:
    metadata:
      name: 3-replicaset
      labels:
        app: 3-replicaset
    spec:
      containers:
      - name: 3-replicaset
        image: nginx
        ports:
        - containerPort: 80
  replicas: 3 #레플리카 개수 3개
  selector:
    matchLabels:
      app: 3-replicaset

레플리카셋을 생성해봅니다.

$ kubectl apply -f replicaset.yaml

해당 이미지 보시면 3-replicaset라는 label을 달고 3개의 파드가 생성되었습니다.

나머지 두개는 아직 컨테이너가 만들어지는 중이네요!!

레플리카셋의 정보를 확인하는 방법도 있습니다.

yaml 파일을 기초로 만들어져있겠네요.

제가 만약 하나의 파드를 삭제한다면 어떻게 될까요?

삭제한 후에, 파드 목록을 다시 확인해보겠습니다.

엇,!! 파드를 삭제했는데도 새 파드가 생성되어있네요.

실시간으로 파드를 관리하는거 같습니다.

레플리카셋과 파드 정보를 가져오는 명령어를 통해 아래와같이 한 번에 확인하실 수 있습니다.

여러가지 방법을 통해 파드를 생성해보았는데요.

다음을 위해 깨끗하게 지워보겠습니다.

아래 명령어를 참고해주세요.

* --cascade=orphan: 레플리카셋만 삭제하고 파드는 남기고 싶다면 해당 명령어 사용.

$ kubectl get replicaset,pods

$ kubectl delete -f [이름] --cascade=orphan

$ kubectl delete pods -l app=[앱 이름]

감사합니다.

[Kubernetes] yaml 파일을 통해 pod 생성, 관리하기

얀타호수 — Tue, 9 Sep 2025 15:24:03 +0900

Pod 관리하기
...

생성된 컨테이너나 파드에 접속할 때는 kubectl exec 명령어를 사용

Pod 로그 확인
...

지금까지 마스터 노드에서 실행해왔구요.

워커노드에서 yaml을 생성해 pod 을 생성해보겠습니다.

명령으로 yaml을 생성하기
--dry-run 옵션을 이용해서 yaml 생성

yaml 파일로 선언적으로 Pod 생성하기

kubectl create -f [yaml 파일] # 처음 생성할 때만 사용하는 명령어
kubectl apply -f [yaml 파일] # 생성 + 수정 둘다 가능

위와 같이 명령어를 입력한 후, get pod 를 해보니 nginx pod 이 생성되었습니다 :)

워크 노드에서 포트포워딩을 한 후, 마스터 노드에서 8080으로 접속하면 nginx 파일이 출력된답니다.

[Kubernetes] 쿠버네티스 파드 Pod 개념 / Pod 생성, 삭제하기

얀타호수 — Tue, 9 Sep 2025 11:31:04 +0900

Pod란?
...

쿠버네티스에서 가장 작은 배포 단위
하나 이상의 컨테이너(Container)를 포함
컨테이너들은 같은 네트워크 네임스페이스, 볼륨, 환경 변수를 공유
Pod는 단일 IP를 가지고, 그 안 컨테이너들은 서로 localhost 로 통신 가능

e.g. my-httpd-7547bdb59f-s5mnv Pod 안에는 httpd 컨테이너 1개가 있고,

IP는 10.244.2.3Pod 안 컨테이너는 localhost:80 로 httpd 접근 가능

Pod 밖에서 직접 접근하려면 IP(10.xxx.xx.x) 사용해야 함, 단 내부 네트워크에서만 가능

Pod 생성하기 (Create, Apply 명령어)
...

파드는 create 또는 apply 명령어를 사용해 생성한다.
kubectl create: 클러스터에 새로운 리소스를 생성한다.
kubectl apply: create와 replace(생성된 오브젝트를 삭제하고 새로운 오브젝트를 생성) 의 혼합이다.

e.g.

1개의 Pod를 가진 Deployment를 만들고, Pod 안에서 httpd 컨테이너가 80번 포트를 열도록 설정
Deployment는 Pod를 관리하고, Pod가 죽으면 자동으로 재생성.,

# kubectl create deployment [deployment name] --image=[컨테이너 이미지] --replicas=[생성 pod수] --port=[컨테이너 노출포트]
# create deployment
# Deployment 리소스 생성 명령어
# Deployment는 Pod를 관리하고, 지정한 수의 복제본(replicas) 유지
# Pod가 죽으면 자동으로 다시 생성해주는 역할
$ kubectl create deployment my-httpd --image=httpd --replicas=1 --port=80

$ kubectl get deployment

$ kubectl get pod

$ kubectl get pod -o wide

Pod 삭제하기
...

$ kubectl delete deployment my-httpd
$ kubectl create deployment my-httpd --image=httpd --replicas=1 --port=80
$ kubectl edit deployment my-httpd

[AI] 구글 AI 나노바나나 gemini-2.5-flash-image 알아보기

얀타호수 — Mon, 8 Sep 2025 11:14:21 +0900

안녕하세요. 오늘은 Google 의 Nano Banana라고 불리는

gemini-2.5-flash-image 을 한 번 알아보겠습니다.

개발 단계에서의 이름은 나노 바나나였지만

발표한 정식이름은 gemini-2.5-flash-image-preview 입니다.

공식적인 논문과 코드가 공개되지 않았지만 간단한 특징에 대해 설명해보겠습니다.

1. 캐릭터 일관성 유지

우선 AI를 사용하며 가장 불편한 점이었던 디자인 일관성 이슈가 해결되었습니다.

기존 diffusion 모델은 반복 편집시 점차 얼굴, 의상, 색감이 변하는 identity drift 문제가 있었습니다.

하지만 나노바나나의 DCL(Design Consistency Layer) 은 수정이 필요한 부분과 유지되어야 할 부분을 명시적으로 분리하여,

의도하지 않은 변경을 방지합니다.

이 기술은 정말 혁신적이네요 ^^

2. 정밀한 편집

자연어 기반의 편집이 가능하며, "특정 부분만 변경하고 나머지는 그대로 유지"하는 식의 프롬프트로 섬세한 조정이 가능합니다.

예를 들어, "이 이미지에서 셔츠의 얼룩만 제거해 주세요"처럼 입력하면 해당 부분만 바뀝니다.
대화형(Iterative) 멀티 턴 편집도 지원됩니다. 즉, 한 번의 프롬프트로 끝나는 게 아니라, "배경을 좀 더 밝게 해줘" -> "이번엔 빨간색으로 바꿔줘"처럼 계속 자연어로 수정할 수 있어 창작 프로세스가 유연합니다.
얼굴이나 캐릭터의 일관성 유지도 뛰어나며, 복잡한 스타일이나 구성에서도 원본의 특징—예를 들어 인물의 얼굴—을 흐트러뜨리지 않고 유지할 수 있습니다.

3. 멀티 모달 기능

텍스트+이미지를 한 번에 입력해도 처리가 가능하며, 단일 모델이 텍스트 이해와 이미지 생성/수정을 모두 수행하는 네이티브 멀티모달 아키텍처를 갖추고 있습니다.
여러 이미지를 조합해 하나의 새로운 장면을 만드는 멀티 이미지 퓨전(multi-image fusion)도 지원되며, 예컨대 제품을 여러 장 합쳐 새로운 광고 이미지로 구성하는 식의 활용이 가능합니다.
세계 지식을 반영한 시맨틱 이해가 포함되어 있어, 단순한 스타일 변경을 넘어서 상황에 맞는 맥락 이해와 편집이 가능합니다.

4. 가용 플랫폼

Gemini 앱에서 바로 사용 가능하며, 일반 사용자도 “Gemini 챗봇” 등으로 접근할 수 있습니다.
Google AI Studio 내 “빌드 모드(build mode)”를 통해 예제 템플릿을 활용하거나 직접 앱을 만들어 GitHub에 배포할 수 있습니다.
Vertex AI (Google Cloud) 플랫폼에서도 Preview 형태로 사용 가능하며, 콘솔이나 Python SDK, REST API 등 다양한 방식으로 통합 활용할 수 있습니다.
OpenRouter.ai, fal.ai와 같은 외부 플랫폼과도 연동되어, 더 넓은 개발자 커뮤니티에서도 사용할 수 있습니다.
Adobe Creative Cloud(Firefly, Express), Poe (by Quora), WPP Open, Freepik 등 다양한 파트너 플랫폼에서도 이미 통합되어 사용 중입니다.
모든 생성/편집된 이미지에는 SynthID 디지털 워터마크가 **보이지 않는 형태(invisible watermark)**로 자동 포함되어, 책임 있는 AI 사용과 추적이 가능합니다.

추후 포스팅에서 간단한 사용법과 후기 알려드릴게요

[Kubernetes] 쿠버네티스 개발 환경 구축하기 (클러스터 생성)

얀타호수 — Thu, 4 Sep 2025 13:01:08 +0900

TL;DR

클러스터 = 여러 서버를 묶어 한 번에 관리하고, Pod 실행을 분산시키는 단위
- 마스터 노드: 전체 관리
- 워커 노드: 애플리케이션 실행
생성 이유
- 장애 나도 서비스 지속(고가용성)
- 트래픽 늘면 노드 추가 가능(확장성)
- 자원 효율적 사용
- 배포/스케일링/헬스 체크 자동화

쿠버네티스 클러스터란?

**클러스터(Cluster)**란, 여러 대의 서버(노드)를 하나로 묶어 하나의 논리적 시스템처럼 동작하게 만든 환경을 말합니다.

구성 요소

마스터 노드 (Control Plane)
- 클러스터 전체를 관리
- 주요 컴포넌트:
  - kube-apiserver: API 요청 처리
  - etcd: 상태 저장소 (클러스터 상태)
  - kube-scheduler: 어떤 노드에 Pod을 배치할지 결정
  - kube-controller-manager: 상태를 원하는 상태로 유지
워커 노드 (Worker Node)
- 실제 애플리케이션(Pod) 실행
- 주요 컴포넌트:
  - kubelet: 노드에서 Pod 실행/상태 관리
  - kube-proxy: 네트워크 트래픽 라우팅
  - 컨테이너 런타임 (Docker, containerd 등)

즉, 클러스터 = 관리하는 서버 + 애플리케이션 실행 서버들의 집합

클러스터를 생성하는 이유

고가용성(High Availability)
- 서버 한 대가 다운되어도 다른 노드가 서비스를 계속 제공
- 즉, 장애 대비
확장성(Scalability)
- 트래픽이 늘어나면 노드를 추가하여 Pod 수를 늘릴 수 있음
- 클러스터 하나로 여러 서버를 묶어 수평 확장 가능
리소스 효율화
- 여러 애플리케이션을 하나의 클러스터에서 관리
- CPU, 메모리, 네트워크 등 자원을 효율적으로 사용
자동화된 관리
- 배포(Deployment), 롤백, 스케일링, 헬스 체크 등을 자동화 가능
- 사람이 일일이 서버 상태를 관리할 필요 없음

# pod-network-cidr: 파드 네트워크의 IP 주소 범위
# apiserver-advertise-address: 수신 대기 중임을 알릴 IP주소로 마스터 노드의 IP를 설정
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.127.128

# 1. 현재 로그인 사용자 확인
whoami
# - 현재 터미널에서 사용 중인 계정 이름 출력
# - 쿠버네티스 config 설정 시 어떤 계정으로 작업 중인지 확인용

# 2. 기존 kube 설정 삭제
rm -rf $HOME/.kube
# - 기존 kubeconfig 파일 및 디렉토리 삭제
# - 깨끗한 상태에서 새 클러스터 설정을 적용하기 위해 사용

# 3. kube 디렉토리 새로 생성
mkdir -p $HOME/.kube
# - kubeconfig를 저장할 디렉토리 생성
# - -p 옵션: 부모 디렉토리 없으면 자동 생성

# 4. 관리자 kubeconfig 파일 복사
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# - kubeadm으로 생성된 admin.conf를 현재 사용자 홈 디렉토리에 복사
# - -i : 덮어쓰기 시 확인 메시지 표시

# 5. kubeconfig 파일 소유자 변경
sudo chown $(id -u):$(id -g) $HOME/.kube/config
# - 현재 사용자(uid, gid) 소유로 변경
# - root 소유일 경우 일반 사용자로 kube 명령어 실행 불가 문제 해결

# 6. 현재 컨텍스트 확인
kubectl config get-contexts
# - kubeconfig에 정의된 모든 컨텍스트 확인
# - 컨텍스트 = 클러스터/사용자/네임스페이스 설정 정보

# 7. 현재 컨텍스트 이름 변경
kubectl config rename-context $(kubectl config current-context) k8s
# - 현재 컨텍스트 이름을 "k8s"로 변경
# - 클러스터가 여러 개일 때 명확하게 구분 가능

# 8. 변경 후 컨텍스트 재확인
kubectl config get-contexts
# - 컨텍스트 이름이 "k8s"로 변경됐는지 확인

# 9. 모든 네임스페이스의 Pod 상태 확인
kubectl get pods --all-namespaces
# - 클러스터 내 모든 네임스페이스에서 실행 중인 Pod 목록 출력
# - 마스터 노드 및 초기 시스템 Pod 상태 확인용

~~혹시라도 쿠버네티스를 초기화하고 싶다면, 아래를 실행해주세요.~~

~~처음부터 다시 설치해야합니다 !!~~

$ sudo su -

$ kubeadm reset -f
$ sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*
$ rm -rf $HOME/.kube

클러스터 시작하기

$ whoami
ubuntu 

# 기존 kube 설정 삭제
$ rm -rf $HOME/.kube

# kube 디렉토리 새로 생성
$ mkdir -p $HOME/.kube

# admin.conf를 사용자 kubeconfig로 복사
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# → kubeadm init 후 생성된 클러스터 관리용 config 복사

# kubeconfig 소유자를 현재 사용자로 변경
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
# → root 소유 문제 해결, kubectl 사용 가능

# 현재 컨텍스트 확인
$ kubectl config get-contexts
# → 클러스터, 사용자, 네임스페이스 정보 확인

# 모든 네임스페이스 Pod 상태 확인
# 마스터 관련 Pod들은 Running, coredns는 Pending 상태
$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-76f75df574-4nf25             0/1     Pending   0          44s
kube-system   coredns-76f75df574-btd98             0/1     Pending   0          44s
kube-system   etcd-k8s-master                      1/1     Running   1          58s
kube-system   kube-apiserver-k8s-master            1/1     Running   1          58s
kube-system   kube-controller-manager-k8s-master   1/1     Running   1          58s
kube-system   kube-proxy-fdsgf                     1/1     Running   0          44s
kube-system   kube-scheduler-k8s-master            1/1     Running   1          58s

# Flannel CNI 설치 (Pod 네트워크)
# → Pod 간 통신 및 네트워크 구성
$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

# CNI 설치 후 Pod 상태 확인
# → kube-flannel Pod가 Init 단계, coredns는 아직 Pending
#    etcd, kube-apiserver, controller-manager, kube-scheduler 등은 Running
$ kubectl get pods --all-namespaces
NAMESPACE      NAME                                 READY   STATUS     RESTARTS   AGE
kube-flannel   kube-flannel-ds-6sb42                0/1     Init:1/2   0          6s
kube-system    coredns-76f75df574-4nf25             0/1     Pending    0          66s
kube-system    coredns-76f75df574-btd98             0/1     Pending    0          66s
kube-system    etcd-k8s-master                      1/1     Running    1          80s
kube-system    kube-apiserver-k8s-master            1/1     Running    1          80s
kube-system    kube-controller-manager-k8s-master   1/1     Running    1          80s
kube-system    kube-proxy-fdsgf                     1/1     Running    0          66s
kube-system    kube-scheduler-k8s-master            1/1     Running    1          80s

아직 Flannel 초기화 중이어서 coredns와 kube-flannel Pod는 Pending/Init 상태
마스터 핵심 컴포넌트(etcd, apiserver, controller, scheduler)는 모두 정상 Running
시간이 조금 지나면 Flannel이 올라가면서 coredns도 Running 상태가 됩니다.

[Kubernetes] 쿠버네티스 환경 구축하기 (VMware에 쿠버 설치)

얀타호수 — Thu, 4 Sep 2025 11:50:52 +0900

1. k8s-master, k8s-worker1~3 에 ssh 접속을 합니다.

2. 아래 경로처럼 디렉토리를 만듭니다.

3. 쿠버네티스를 clone 받습니다.

4. hostname을 설정합니다.

$ ssh ubuntu@192.168.127.131

$ mkdir -p ~/dev/workspace/devops

$ cd ~/dev/workspace/devops

$ git clone https://github.com/kshelp/kubernetes

$ sudo hostnamectl set-hostname k8s-worker3

$ sudo vi /etc/hosts
#Kubernetes host - Jin Yu 250904
192.168.127.128 k8s-master
192.168.127.129 k8s-worker1
192.168.127.130 k8s-worker2
192.168.127.131 k8s-worker3

디렉토리 만들고 쿠버네티스 repo 클론

hostname 설정

다음,

쿠버가 제대로 작동하려면 아래의 이유때문에 swap 메모리를 비활성화해야합니다!

1. 리소스 관리의 일관성 문제

쿠버네티스는 cgroup을 이용해서 컨테이너별로 CPU, 메모리 리소스를 제한합니다.
메모리 제한은 OOM(Out Of Memory) 이벤트를 기준으로 동작하는데, 만약 스왑이 켜져 있다면 실제로는 물리 메모리 초과 상황에서도 스왑으로 밀려나면서 "쿠버네티스가 예상한 동작"과 달라집니다.
→ 즉, Pod이 제대로 종료되지 않고 계속 버티거나, 다른 Pod이 영향을 받을 수 있음.

2. 성능 저하 및 예측 불가 동작

스왑은 디스크 기반이라 RAM에 비해 속도가 수백~수천 배 느림.
어떤 Pod이 메모리를 많이 잡아먹을 경우, 스왑으로 밀려난 프로세스들이 급격히 느려짐 → 다른 Pod 전체가 영향을 받음.
쿠버네티스 스케줄러가 "노드에 리소스가 충분하다"고 판단하고 Pod을 배치했는데, 실제로는 스왑 때문에 성능이 급락하는 문제가 발생.

3. 노드 안정성 확보

스왑 활성화 상태에서 메모리 부족이 발생하면, 노드가 전체적으로 느려지거나 커널 OOM Killer가 임의의 프로세스를 종료시킬 수 있음.
쿠버네티스는 Pod 단위에서 책임지고 자원을 관리해야 하는데, 스왑이 켜져 있으면 운영체제가 개입해버리므로 제어권을 잃음.

그렇기 때문에 모든 노드에서 swap 메모리를 비활성화해줍시다.

$ sudo swapoff -a

$ sudo sed -i '/ swap / s/^/#/' /etc/fstab

$ sudo vi /etc/fstab
#/swap.img none swap sw 0 0

다음은, docker를 설치해줄겁니다.

docker를 설치하고 hello-world 이미지가 잘 실행이 되는지 run 해줍시다 ㅎㅎ (생략)

자, 실행이 잘 된다면!!

cgroup 드라이버를 설정합니다.

# cgroup 드라이버 설정
# - 쿠버네티스에서는 도커의 cgroup 관리를 위해 systemd를 사용하도록 변경해야 한다. 
# - 변경하지 않으면 클러스터 설치 과정에서 오류가 발생할 수 있다.
$ sudo docker info | grep Cgroup
WARNING: No swap limit support
 Cgroup Driver: cgroupfs #systemd 라고 되어있어야함
 Cgroup Version: 1
 
 
# cgroup driver가 systemd가 아닌 경우에만 아래와 같이 실행한다.
$ sudo vi /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file",
"log-opts": {
		"max-size": "100m"
	},
	"storage-driver": "overlay2"
}

다음 단계는 서비스를 재시작하는겁니다.

$ sudo mkdir -p /etc/systemd/system/docker.service.d
$ sudo systemctl daemon-reload
$ sudo systemctl restart docker
$ sudo docker info

....

Cgroup Driver: systemd
Cgroup Version: 1

위와 같이 Cgroup Driver: systemd 로 변경이 되어있어야해요 !!

Kubernetes 설치

자 이제 모든 설정은 끝났으니, 모든 노드에 쿠버네티스를 설치합니다.

총 6단계입니다.

1~4 단계: Kubernetes 공식 apt 저장소 추가 및 서명키 등록
5 단계: apt 목록 업데이트
6 단계: kubelet, kubeadm, kubectl 설치


# 1. Kubernetes 설치를 위해 필요한 패키지 설치
$ sudo apt-get install -y apt-transport-https ca-certificates curl gpg
# - apt-transport-https : HTTPS를 통해 apt 리포지토리를 접근 가능하게 함
# - ca-certificates       : HTTPS 인증서 확인용 루트 인증서 설치
# - curl                  : URL에서 파일 다운로드용 툴
# - gpg                   : 패키지 서명 검증용 GNU Privacy Guard 도구
# - -y 옵션              : 설치 시 사용자 확인 없이 자동 Yes


# 2. Kubernetes GPG 키를 저장할 디렉토리 생성
$ sudo mkdir -p -m 755 /etc/apt/keyrings
# - -p : 부모 디렉토리 없으면 생성
# - -m 755 : 디렉토리 권한 설정 (소유자 읽기/쓰기/실행, 그룹/타인 읽기/실행)


# 3. Kubernetes 패키지 서명키 다운로드 및 GPG 형식으로 저장
$ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
# - curl -fsSL : 실패 시 에러 메시지 없이 다운로드, 리다이렉션 허용
# - sudo gpg --dearmor : ASCII 형식의 GPG 키를 바이너리 형식(.gpg)으로 변환
# - -o : 출력 파일 지정


# 4. Kubernetes APT 저장소를 sources.list.d에 등록
$ echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
# - deb : apt 저장소를 의미
# - [signed-by=...] : 지정한 GPG 키로 패키지 서명 검증
# - https://pkgs.k8s.io/... : Kubernetes 공식 stable v1.29 패키지 URL
# - tee : 관리자 권한으로 파일 생성/덮어쓰기


# 5. 새 저장소 정보로 패키지 목록 업데이트
$ sudo apt-get update
# - apt 패키지 목록을 최신화하여 새 저장소 패키지를 인식


# 6. Kubernetes 핵심 구성 요소 설치
$ sudo apt-get install -y kubelet kubeadm kubectl
# - kubelet : 각 노드에서 Pod을 관리하는 에이전트
# - kubeadm : 클러스터 초기화 및 관리 도구
# - kubectl : 클러스터 제어 및 관리용 CLI
# - -y 옵션 : 설치 시 사용자 확인 없이 자동 Yes

[Kubernetes] 쿠버네티스 환경 구축하기 (VMware 사용하기)

얀타호수 — Thu, 4 Sep 2025 09:54:30 +0900

안녕하세요.

쿠버네티스 환경을 실습해보기 위해 실습 환경을 구축해보겠습니다.

오늘 해야할 일을 설명드리겠습니다.

1. ubuntu20.04 다운로드
2. vmware install
3. vmware에 4개의 vm 만들기
4. 네트워크 및 네트워크 인터페이스 설정하기

저는 ubuntu 20.04를 usb에 두고 부팅 usb로 쓸 때가 있어 가지고 다닙니다.

아니신 분들은 아래 링크에서 server install image를 선택해 설치하세요.

https://releases.ubuntu.com/focal/

VMware 에 들어가서 File > New 에 들어간 후,

다운로드받은 ubuntu를 Virtual machine 으로 선택해줍니다.

커스터마이징 하는 과정이 있는데 아래 표를 참고로 만들어주세요. ip는 추후 네트워크 인터페이스 과정에서 설정합니다.

k8s-matster	192.168.127.128	50G 할당
k8s-worker1	192.168.127.129	50G 할당
k8s-worker2	192.168.127.130	50G 할당
k8s-worker3	192.168.127.131	300G 할당

여러가지 과정이 있는데 그냥 넘겨주시고

SSH 접속은 해야하기 때문에 아래 과정에서 Install OpenSSH server를 선택해주세요.

그러면 오랜시간 설치하게 됩니다.

이럴 때는 커피 한 잔 마시고 와주면 끝내있습니다.

같은 과정을 네번 반복해야합니다.

설치가 다 된후, worker1에 ubuntu계정으로 로그인하면 이렇게 나옵니다 :)

나머지 3개의 vm도 이렇게 나와야합니다!!

모든 vm에 아래와 같은 설정을 해줄건데요.

네트워크 인터페이스에 address 부분은 테이블로 정의한 내부 ip를 작성해주세요.

k8s-matster	192.168.127.128	50G 할당
k8s-worker1	192.168.127.129	50G 할당
k8s-worker2	192.168.127.130	50G 할당
k8s-worker3	192.168.127.131	300G 할당

# 최신상태로 업데이트하기
$ sudo apt-get update && sudo apt-get upgrade -y

$ sudo apt install net-tools apt-transport-https curl -y

# 네트워크 설정 - 현재 설치된 네트워크 인터페이스 설정 보기
$ ifconfig

# 네트워크 인터페이스 설정하기
# ip고정을 위해 Ubuntu 20.04에서는 netplan을 사용
$ sudo vi /etc/netplan/00-installer-config.yaml

# 네트워크 설정 적용
$ sudo netplan apply

이렇게 설정을 해둔 뒤 네트워크 설정을 저장하고요

제 터미널에서 해당 ip에 ssh 접속이 되는지 봅시다

오~~ 완료

다음은 쿠버네티스 설정 편에서 만나요