Self Managed K8s on Joonlog

깃허브 코드로 배포한 Pokerogue 앱에서 구글/디스코드 외부 로그인이 실패하는 이슈

Wed, 22 Oct 2025 09:00:00 +0900

공식 rogueserver 코드의 쿠키 설정 버그로 인해 구글 OAuth 로그인이 작동하지 않는 이슈

환경

Vite 기반 React 프론트엔드와 Go 기반 백엔드 그리고 Mariadb로 구성
K8S + HAProxy를 통한 외부 접근

문제 상황

일반 계정 로그인은 정상 작동
구글/디스코드 계정 연결 시도 시 에러:
1. 일반 로그인 후 설정 메뉴에서 구글 연결 클릭
2. 구글 OAuth 인증 완료
3. 메인 화면으로 리다이렉트되지만 설정이 저장되지 않고 새로고침만 됨
4. 로그아웃 후 구글로 직접 로그인 시도 시 로그인 실패

에러 분석

1. 백엔드 로그 분석

1

kubectl logs -n pokerogue pokerogue-server

1
2
3


2025/10/14 23:02:24 [DEBUG] Google token response status: 200
2025/10/14 23:02:24 [DEBUG] Successfully extracted userId: 102118711772610730702
2025/10/14 23:02:47 /account/info: missing token

구글 OAuth 토큰 교환은 성공 (userId 추출 완료)
DB에 googleId도 정상 저장됨 확인
하지만 세션 토큰이 누락되어 로그인 상태 유지 실패

2. 브라우저 네트워크 탭 분석

1
2
3
4


Request: GET /api/auth/google/callback
Response: 303 See Other
Set-Cookie: pokerogue_sessionId=...; SameSite=Strict; Domain=pokerogue.net
Sec-Fetch-Site: cross-site

문제점 발견:

Domain=pokerogue.net
- 공식 pokerogue URL로 하드코딩 되어 있어 현재 도메인과 불일치
SameSite=Strict
- 구글에서 돌아오는 요청이 cross-site이므로 쿠키가 전송되지 않음

OAuth 리다이렉트 흐름:
- pokerogue.<도메인> → accounts.google.com → pokerogue.<도메인>/callback
  - SameSite=Strict는 같은 사이트 내부 요청에만 쿠키 전송
  - 구글에서 돌아오는 것은 cross-site 요청으로 간주되어 쿠키 차단

해결 방법

api/endpoints.go 파일의 쿠키 설정 수정:

1
2
3
4
5
6
7
8
9


http.SetCookie(w, &http.Cookie{
 Name: "pokerogue_sessionId",
 Value: sessionToken,
 Path: "/",
 Secure: true,
 SameSite: http.SameSiteLaxMode, // Strict → Lax 변경
 Domain: "", // "pokerogue.net" → "" 변경
 Expires: time.Now().Add(time.Hour * 24 * 30 * 3),
})

변경 사항
1. Domain: ""
  - 빈 문자열로 설정하여 현재 도메인 자동 적용
2. SameSite: http.SameSiteLaxMode
  - Strict → Lax
  - Lax는 안전한 cross-site GET 요청(OAuth 콜백 포함)에서 쿠키 전송 허용
  - OAuth 표준에서 권장하는 설정
  - 여전히 CSRF 공격 방어 가능 (위험한 POST 요청은 차단)

결과

일반 로그인 → 구글 계정 연결 → 로그아웃 → 구글 직접 로그인 모두 정상 작동
세션 쿠키가 올바르게 설정되어 로그인 상태 유지
브라우저 네트워크 탭에서 Set-Cookie: ...; SameSite=Lax 확인

참고

OAuth를 사용하는 많은 프로젝트에서 동일한 이슈가 발생했으며, 모두 SameSite=Lax로 해결

Kubernetes에서 Pokerogue 게임 배포하기

Mon, 20 Oct 2025 09:00:00 +0900

매니지드 K8S가 아닌 자체 관리형 K8S에서의 Pokerogue구축 방법

UI 접근을 위한 외부 통신으로 MetalLB+HAproxy+Nginx Controller가 구성 되었다는 전제 하에 구축

CSP 환경이라면 Ingress 설정에서 AWS ALB Controller와 같은 로드밸런서를 사용해 훨씬 간편하게 구축 가능

Pokerogue 공식문서: https://github.com/pagefaultgames/pokerogue https://github.com/pagefaultgames/rogueserver

아키텍쳐

인프라 구조: Pokerogue WEB(Frontend) - Pokerogue Rogueserver(Backend) - MariaDB(DB)
WEB과 API 통신 경로를 분리
- 분리 이유
  - SPA 특성상 Frontend가 / 경로로 모든 요청을 받아야 함
  - Backend는 /api/* 경로를 /*로 rewrite된 상태로 요청을 받아야 함
  - Ingress는 같은 Host(도메인)에 대해 두 개의 서로 다른 규칙 적용 불가
    - 따라서 HAproxy 설정에서 Frontend는 Ingress, Backend는 LoadBalancer타입 Service로 라우팅되도록 구성
- WEB 통신 구조:
  - Client(HTTPS) → HAproxy(SSL Termination) → Nginx Ingress Controller → Ingress → Service(pokerogue-web ClusterIP) → Workload(pokerogue-web)
- API 통신 구조:
  - Client JS(HTTPS/api/account/info) → HAproxy(SSL Termination + 경로 rewrite ⇒ HTTP /account/info) → Service(pokerogue-server LoadBalancer) → Workloads(pokerogue-server) → Service(pokerogue-db ClusterIP) → Workload(MariaDB)
구글 Oauth 로그인 흐름
- Client가 설정에서 Link Google → pokerogue-web에서 /api/auth/google?mode=link 요청 → rogueserver에서 Google OAuth URL 생성 → 브라우저에서 구글 로그인 → 구글에서 도메인/api/auth/google/callback?code=...&state=... 로 라우팅 → HAproxy(rogueserver-service)로 라우팅 → rogueserver에서 /auth/google/callback로 수신한 code로 구글 ID 조회 + 로그인한 사용자 ID 조회 → DB에서 해당 사용자에 구글 ID값 추가 → 도메인으로 리다이렉트
  - 디스코드 OAuth 로그인도 동일한 흐름

Pokerogue 구축

Pokerogue 네임스페이스 생성

1
2


kubectl create ns pokerogue
kubectl label namespace teleport-cluster 'pod-security.kubernetes.io/enforce=baseline'

mariadb-pvc 생성

mariadb-pvc.yaml
- longhorn pv 사용

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


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pokerogue-db-pvc
 namespace: pokerogue
spec:
 accessModes:
 - ReadWriteOnce
 storageClassName: longhorn
 resources:
 requests:
 storage: 10Gi

mariadb-secret 생성
- DB 인증정보 secret
  - MYSQL_ROOT_PASSWORD
  - MYSQL_DATABASE
  - MYSQL_USER
  - MYSQL_PASSWORD

mariadb 배포

mariadb-deployment.yaml
- mariadb secret 참조
- mysqladmin ping 명령어로 헬스 체크

 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82


apiVersion: apps/v1
kind: Deployment
metadata:
 name: pokerogue-db
 namespace: pokerogue
 labels:
 app: pokerogue-db
spec:
 replicas: 1
 selector:
 matchLabels:
 app: pokerogue-db
 template:
 metadata:
 labels:
 app: pokerogue-db
 spec:
 containers:
 - name: mariadb
 image: mariadb:11.2
 ports:
 - containerPort: 3306
 name: mysql
 env:
 - name: MYSQL_ROOT_PASSWORD
 valueFrom:
 secretKeyRef:
 name: pokerogue-db-secret
 key: MYSQL_ROOT_PASSWORD
 - name: MYSQL_DATABASE
 valueFrom:
 secretKeyRef:
 name: pokerogue-db-secret
 key: MYSQL_DATABASE
 - name: MYSQL_USER
 valueFrom:
 secretKeyRef:
 name: pokerogue-db-secret
 key: MYSQL_USER
 - name: MYSQL_PASSWORD
 valueFrom:
 secretKeyRef:
 name: pokerogue-db-secret
 key: MYSQL_PASSWORD
 volumeMounts:
 - name: db-data
 mountPath: /var/lib/mysql
 resources:
 requests:
 memory: "512Mi"
 cpu: "250m"
 limits:
 memory: "1Gi"
 cpu: "500m"
 livenessProbe:
 exec:
 command:
 - /usr/bin/mariadb-admin
 - ping
 - -h
 - localhost
 - -u
 - root
 - -p${MYSQL_ROOT_PASSWORD}
 initialDelaySeconds: 30
 periodSeconds: 10
 readinessProbe:
 exec:
 command:
 - /usr/bin/mariadb-admin
 - ping
 - -h
 - localhost
 - -u
 - root
 - -p${MYSQL_ROOT_PASSWORD}
 initialDelaySeconds: 5
 periodSeconds: 5
 volumes:
 - name: db-data
 persistentVolumeClaim:
 claimName: pokerogue-db-pvc

mariadb-service 생성

mariadb-service.yaml

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


apiVersion: v1
kind: Service
metadata:
 name: pokerogue-db
 namespace: pokerogue
spec:
 selector:
 app: pokerogue-db
 ports:
 - protocol: TCP
 port: 3306
 targetPort: 3306
 type: ClusterIP

OAuth-secret 생성
- rogueserver oauth 로그인을 위한 secret
  - GOOGLE_CLIENT_ID
  - GOOGLE_SECRET_ID
  - DISCORD_CLIENT_ID
  - DISCORD_CLIENT_SECRET

rogueserver 배포

rogueserver-deployment.yaml
- initcontainer로 DB가 준비될 때까지 대기
- DB secret 참조
- OAuth secret 참조

 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80


apiVersion: apps/v1
kind: Deployment
metadata:
 name: pokerogue-server
 namespace: pokerogue
 labels:
 app: pokerogue-server
spec:
 replicas: 1
 selector:
 matchLabels:
 app: pokerogue-server
 template:
 metadata:
 labels:
 app: pokerogue-server
 spec:
 # DB가 준비될 때까지 대기
 initContainers:
 - name: wait-for-db
 image: busybox:1.36
 command: ['sh', '-c', 'until nc -z pokerogue-db 3306; do echo waiting for db; sleep 2; done;']
 containers:
 - name: rogueserver
 image: <registry명>/rogueserver:latest
 imagePullPolicy: Always
 ports:
 - containerPort: 8001
 name: api
 env:
 - name: debug
 value: "true"
 - name: dbaddr
 value: "pokerogue-db:3306"
 - name: dbuser
 valueFrom:
 secretKeyRef:
 name: pokerogue-db-secret
 key: MYSQL_USER
 - name: dbpass
 valueFrom:
 secretKeyRef:
 name: pokerogue-db-secret
 key: MYSQL_PASSWORD
 - name: dbname
 valueFrom:
 secretKeyRef:
 name: pokerogue-db-secret
 key: MYSQL_DATABASE
 - name: gameurl
 value: "https://pokerogue.<도메인>:48443"
 - name: callbackurl
 value: "https://pokerogue.<도메인>:48443/api"
 - name: googleclientid
 valueFrom:
 secretKeyRef:
 name: pokerogue-oauth-secret
 key: GOOGLE_CLIENT_ID
 - name: googlesecretid
 valueFrom:
 secretKeyRef:
 name: pokerogue-oauth-secret
 key: GOOGLE_SECRET_ID
 - name: discordclientid
 valueFrom:
 secretKeyRef:
 name: pokerogue-oauth-secret
 key: DISCORD_CLIENT_ID
 - name: discordsecretid
 valueFrom:
 secretKeyRef:
 name: pokerogue-oauth-secret
 key: DISCORD_CLIENT_SECRET
 resources:
 requests:
 memory: "512Mi"
 cpu: "250m"
 limits:
 memory: "1Gi"
 cpu: "1000m"

rogueserver-service생성

rogueserver-service.yaml
- type을 LoadBalancer로 만들어서 pokerogue-web용 ingrss에 할당할 IP와 다른 IP를 MetalLB로부터 할당
- /api로의 통신은 haproxy에서 rogueserver Service(LB)로 직접 라우팅

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


apiVersion: v1
kind: Service
metadata:
 name: pokerogue-server
 namespace: pokerogue
spec:
 selector:
 app: pokerogue-server
 ports:
 - protocol: TCP
 port: 8001
 targetPort: 8001
 type: LoadBalancer

web 배포

web-deployment.yaml

 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
28
29
30
31


apiVersion: apps/v1
kind: Deployment
metadata:
 name: pokerogue-web
 namespace: pokerogue
 labels:
 app: pokerogue-web
spec:
 replicas: 1
 selector:
 matchLabels:
 app: pokerogue-web
 template:
 metadata:
 labels:
 app: pokerogue-web
 spec:
 containers:
 - name: web
 image: <registry명>/pokerogue-web:latest
 imagePullPolicy: Always
 ports:
 - containerPort: 80
 name: http
 resources:
 requests:
 memory: "512Mi"
 cpu: "500m"
 limits:
 memory: "1Gi"
 cpu: "1000m"

web-service생성

web-service.yaml

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


apiVersion: v1
kind: Service
metadata:
 name: pokerogue-web
 namespace: pokerogue
spec:
 selector:
 app: pokerogue-web
 ports:
 - protocol: TCP
 port: 80
 targetPort: 80
 type: ClusterIP

web-ingress 생성

pokerogue-web-ingress.yaml
- Frontend 라우팅만 처리
  - nginx.ingress.kubernetes.io/ssl-redirect
  - nginx.ingress.kubernetes.io/force-ssl-redirect
    - SSL Redirect 비활성화
      - HAproxy에서 SSL Termination 처리하기 때문
      - Ingress는 HTTP 트래픽만 수신
- Host 기반 라우팅
  - pokerogue.<도메인>으로 들어오는 요청만 처리
  - HAproxy가 Host 헤더 기반으로 이 Ingress로 라우팅

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


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: pokerogue-unified-ingress
 namespace: pokerogue
 annotations:
 nginx.ingress.kubernetes.io/ssl-redirect: "false"
 nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
spec:
 ingressClassName: nginx
 # TLS is handled by HAProxy, not by Ingress
 # This allows HAProxy to terminate SSL and forward HTTP to Ingress
 rules:
 - host: pokerogue.<도메인>
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: pokerogue-web
 port:
 number: 80

SSL 인증서 적용

인증서 발급
- /etc/letsencrypt/live/pokerogue.<도메인>/fullchain.pem
- /etc/letsencrypt/live/pokerogue.<도메인>/privkey.pem

1
2
3


certbot certonly --manual --preferred-challenges dns \
 -d pokerogue.<도메인> \
 --key-type ecdsa

haproxy용 인증서 생성

1
2
3


 cat /etc/letsencrypt/live/pokerogue.<도메인>/fullchain.pem \
 /etc/letsencrypt/live/pokerogue.<도메인>/privkey.pem \
 > /etc/haproxy/pokerogue.pem

HAproxy 설정

ingress, service를 조회하여 MetalLB로부터 부여받은 IP 확인

web: 172.27.1.100
backend: 172.27.1.104

1
2
3
4
5
6


# kubectl get ingress -n pokerogue 
NAME CLASS HOSTS ADDRESS PORTS AGE
pokerogue-unified-ingress nginx pokerogue.<도메인> 172.27.1.100 80 6d21h
# kubectl get svc -n pokerogue 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
pokerogue-server LoadBalancer 10.233.16.211 172.27.1.104 8001:30946/TCP 9d

확인한 IP를 HAproxy 설정에 추가
HTTPS 트래픽 처리
- SSL Termination
  - SSL인증서와 개인키 파일을 결합한 pokerogue.pem파일 사용
- X-Forwarded-Port
  - 구글/디스코드 같은 외부 로그인을 위한 Backend OAuth callback URL 생성 시
- 경로 기반 라우팅
  - /api/* 요청 시 rogueserver-service로 직접 라우팅
  - 나머지 모든 요청은 pokerogue-ingress로 라우팅

API 서버(rogueserver-service)로의 라우팅을 위해 /api/* 요청을 /* 요청으로 재작성하는 설정 적용

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


frontend pokerogue_frontend
 bind *:443 ssl crt /etc/haproxy/pokerogue.pem
 mode http
 option forwardfor

 # Set X-Forwarded headers for HTTPS
 http-request set-header X-Forwarded-Host %[req.hdr(host)]
 http-request set-header X-Forwarded-Proto https
 http-request set-header X-Forwarded-Port 48443

 # Path-based routing: /api -> Backend API, others -> Frontend
 use_backend pokerogue_api_backend if { path_beg /api }
 default_backend metallb_backend_pokerogue

backend metallb_backend_pokerogue
 # Frontend only (no rewrite)
 server pokerogue 172.27.1.100:80

backend pokerogue_api_backend
 # Backend API: direct to LoadBalancer Service (MetalLB managed)
 # Path rewrite: /api/* -> /*
 http-request set-path %[path,regsub(^/api,)]
 server pokerogue-server-lb 172.27.1.104:8001

haproxy 적용

1
2


haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

접근 성공!

K8S에 구축된 Jenkins-GitLab CI Jenkinsfile - 애플리케이션 빌드 필요 없는 경우

Fri, 17 Oct 2025 09:00:00 +0900

Kubernetes 환경에서 Jenkins 파이프라인으로 CI를 수행하도록 구성한 Jenkinsfile 정리

Jenkins와 GitLab이 같은 K8S에 있는 환경인 가정하에 유효

Python, PHP처럼 애플리케이션 빌드 과정이 필요 없는 인터프리터 언어 기반인 경우에 유효

1. Kubernetes Pod 템플릿

Jenkins 에이전트를 파드 단위로 생성하는 파드 템플릿 정의
docker, dind 컨테이너로 구성
- docker-daemon 컨테이너는 Docker in Docker(DIND)를 사용해서 도커 데몬 실행
workspace-volume와 docker-socket 볼륨 공유

hostNetwork: true 설정으로 파드의 컨테이너가 호스트 노드(현재 워커 노드)의 네트워크 네임스페이스를 사용할 수 있도록 설정

hostAliases 설정으로 사설 IP로 GitLab 서버에 접근할 수 있도록 설정

 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


 agent {
 kubernetes {
 yaml """
 apiVersion: v1
 kind: Pod
 spec:
 serviceAccountName: jenkins
 hostNetwork: true
 hostAliases:
 - ip: "<마스터 서버 사설 IP>"
 hostnames:
 - "registry.<도메인>"
 - "gitlab.<도메인>"
 containers:
 - name: docker
 image: docker
 command:
 - sleep
 args:
 - 99d
 tty: true
 volumeMounts:
 - name: workspace-volume
 mountPath: /home/jenkins/agent
 - name: docker-socket
 mountPath: /var/run
 - name: docker-daemon
 image: docker:dind
 securityContext:
 privileged: true
 env:
 - name: DOCKER_TLS_CERTDIR
 value: ""
 args:
 - --insecure-registry=registry.<도메인>:8080
 volumeMounts:
 - name: docker-socket
 mountPath: /var/run
 volumes:
 - name: workspace-volume
 emptyDir: {}
 - name: docker-socket
 emptyDir: {}
 """
 }
 }

2. Environment

Jenkinsfile에서 사용될 전역 환경 변수 정의

GITLAB_REGISTRY: GitLab Registry 주소
GITLAB_TOKEN: Jenkins Credentials에 저장된 GitLab 토큰

1
2
3
4
5
6
7
8


 environment {
 APP_NAME = "<앱 이름>"
 RELEASE = "1.0.0"
 GITLAB_REGISTRY = "registry.<도메인>:8080"
 GITLAB_TOKEN = credentials('<credentials 이름>')
 IMAGE_NAME = "${GITLAB_REGISTRY}/root/${APP_NAME}"
 IMAGE_TAG = "${RELEASE}-${BUILD_NUMBER}"
 }

3. Stages

Stage 1

SCM에서 소스코드 체크아웃
SCM의 url은 K8S Service의 FQDN으로 사용

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


 stage("Checkout from SCM") {
 steps {
 script {
 sh 'pwd'
 sh 'ls -al'
 git credentialsId: '<credentials 이름>',
 url: 'http://gitlab-webservice-default.gitlab.svc.cluster.local:8181/root/<리포지토리명>.git',
 branch: 'main'
 sh 'ls -al'
 }
 }
 }

Stage 2

Docker 이미지 빌드
- DinD 컨테이너에서 이미지 빌드 및 태그 추가

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


 stage('Build Docker Image') {
 steps {
 container('docker') {
 script {
 sh 'pwd'
 sh 'ls -al'
 sh 'docker build --no-cache -t ${IMAGE_NAME}:${IMAGE_TAG} .'
 sh 'docker tag ${IMAGE_NAME}:${IMAGE_TAG} ${IMAGE_NAME}:latest'
 }
 }
 }
 }

Stage 3

GitLab Registry 이미지 푸시
- GitLab Container Registry에 로그인 후 이미지 푸시
- GITLAB_TOKEN 환경변수에서 주입받은 credential로 GITLAB_TOKEN_PSW, GITLAB_TOKEN_USR 변수 사용 가능

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


stage('Push to GitLab Registry') {
 steps {
 container('docker') {
 script {
 sh 'echo $GITLAB_TOKEN_PSW | docker login ${GITLAB_REGISTRY} -u $GITLAB_TOKEN_USR --password-stdin'
 sh 'docker push ${IMAGE_NAME}:${IMAGE_TAG}' // Docker 이미지 푸시
 sh 'docker push ${IMAGE_NAME}:latest' // Docker 이미지 푸시(latest 태그)
 }
 }
 }
 }

4. 정리

파이프라인 종료 전 도커 리소스 정리 및 로그아웃

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


 post {
 always {
 // 작업 완료 후 정리
 container('docker') {
 script {
 sh 'docker logout ${GITLAB_REGISTRY} || true'
 sh 'docker system prune -f || true'
 }
 }
 }
 success {
 echo "Pipeline succeeded! Image ${IMAGE_NAME}:${IMAGE_TAG} pushed to GitLab Registry"
 }
 failure {
 echo "Pipeline failed!"
 }
 }

전체 Jenkinsfile

 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
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115


pipeline {
 agent {
 kubernetes {
 yaml """
 apiVersion: v1
 kind: Pod
 spec:
 serviceAccountName: jenkins
 hostNetwork: true
 hostAliases:
 - ip: "<마스터 서버 사설 IP>"
 hostnames:
 - "registry.<도메인>"
 - "gitlab.<도메인>"
 containers:
 - name: docker
 image: docker
 command:
 - sleep
 args:
 - 99d
 tty: true
 volumeMounts:
 - name: workspace-volume
 mountPath: /home/jenkins/agent
 - name: docker-socket
 mountPath: /var/run
 - name: docker-daemon
 image: docker:dind
 securityContext:
 privileged: true
 env:
 - name: DOCKER_TLS_CERTDIR
 value: ""
 args:
 - --insecure-registry=registry.<도메인>:8080
 volumeMounts:
 - name: docker-socket
 mountPath: /var/run
 volumes:
 - name: workspace-volume
 emptyDir: {}
 - name: docker-socket
 emptyDir: {}
 """
 }
 }

 environment {
 APP_NAME = "<앱 이름>"
 RELEASE = "1.0.0" // 릴리즈 버전
 GITLAB_REGISTRY = "registry.<도메인>:8080" // GitLab Registry 주소
 GITLAB_TOKEN = credentials('<credentials 이름>') // Jenkins Credentials에 저장된 GitLab 토큰
 IMAGE_NAME = "${GITLAB_REGISTRY}/root/${APP_NAME}" // 이미지 이름
 IMAGE_TAG = "${RELEASE}-${BUILD_NUMBER}" // 이미지 태그
 }

 stages {
 stage("Checkout from SCM") { // 소스 코드 관리(SCM)에서 체크아웃 단계
 steps {
 script {
 sh 'pwd'
 sh 'ls -al'
 git credentialsId: '<credentials 이름>', // GitLab 자격증명 사용
 url: 'http://gitlab-webservice-default.gitlab.svc.cluster.local:8181/root/<리포지토리명>.git', // GitLab 리포지토리 URL
 branch: 'main' // 브랜치 이름
 sh 'ls -al'
 }
 }
 }

 stage('Build Docker Image') { // Docker 이미지 빌드 단계
 steps {
 container('docker') {
 script {
 sh 'pwd'
 sh 'ls -al'
 sh 'docker build --no-cache -t ${IMAGE_NAME}:${IMAGE_TAG} .' // Docker 이미지 빌드
 sh 'docker tag ${IMAGE_NAME}:${IMAGE_TAG} ${IMAGE_NAME}:latest' // latest 태그 추가
 }
 }
 }
 }

 stage('Push to GitLab Registry') { // GitLab Registry에 이미지 푸시 단계
 steps {
 container('docker') {
 script {
 sh 'echo $GITLAB_TOKEN_PSW | docker login ${GITLAB_REGISTRY} -u $GITLAB_TOKEN_USR --password-stdin' // GitLab Registry 로그인
 sh 'docker push ${IMAGE_NAME}:${IMAGE_TAG}' // Docker 이미지 푸시
 sh 'docker push ${IMAGE_NAME}:latest' // Docker 이미지 푸시(latest 태그)
 }
 }
 }
 }
 }

 post {
 always {
 // 작업 완료 후 정리
 container('docker') {
 script {
 sh 'docker logout ${GITLAB_REGISTRY} || true'
 sh 'docker system prune -f || true'
 }
 }
 }
 success {
 echo "Pipeline succeeded! Image ${IMAGE_NAME}:${IMAGE_TAG} pushed to GitLab Registry"
 }
 failure {
 echo "Pipeline failed!"
 }
 }
}

K8S에 구축된 Jenkins-GitLab 파이프라인 설정

Thu, 16 Oct 2025 09:00:00 +0900

파이프라인 설정

Definition: Pipeline script from SCM
- SCM: Git
  - Jenkinsfile을 Git으로 읽도록 설정
git repository url: http://gitlab-webservice-default.gitlab.svc.cluster.local:8181/root/test.git
- Jenkins 서버와 GitLab 서버가 모두 같은 k8s 클러스터에 있으므로, 외부 서버에서 url 설정하던 것처럼 하긴 어려움
- GitLab UI Service의 FQDN인 gitlab-webservice-default.gitlab.svc.cluster.local 을 사용
Credentials: GitLab PAT
- GitLab의 사용자/리포지토리에서 발급한 PAT를 Jenkins Credentials에 등록해서 사용
Branches to build: */main
- 빌드할 브랜치 선택

Kubernetes환경 Teleport에서 사용자 관리하기

Sat, 11 Oct 2025 09:00:00 +0900

Teleport 사용자 생성

member Role 생성

member.yaml

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


kind: role
version: v7
metadata:
 name: member
spec:
 allow:
 kubernetes_groups: ["system:masters"]
 kubernetes_labels:
 '*': '*'
 kubernetes_resources:
 - kind: '*'
 namespace: '*'
 name: '*'
 verbs: ['*']

1

kubectl exec -i deployment/teleport-auth -n teleport-cluster -- tctl create -f < member.yaml

myuser 사용자 생성

출력된 링크를 브라우저에서 접속

1

kubectl exec -it deployment/teleport-auth -n teleport-cluster -- tctl users add myuser --roles=member,access,editor

로그인 성공!

tsh 로그인

tsh login

1

tsh login --proxy=teleport.<도메인>:8443 --user=myuser

사용자에 할당된 사용 가능한 k8s cluster 목록

1
2
3
4


# tsh kube ls
Kube Cluster Name Labels Selected
---------------------- ------ --------
teleport.<domain> *

k8s cluster login
1

tsh kube login teleport.<domain>

kubectl 성공!

1
2
3
4
5
6
7


# kubectl get nodes
NAME STATUS ROLES AGE VERSION
master1 Ready control-plane 51d v1.31.4
master2 Ready control-plane 51d v1.31.4
master3 Ready control-plane 51d v1.31.4
node1 Ready <none> 51d v1.31.4
node2 Ready <none> 51d v1.31.4

자체 관리형 Kubernetes에서의 Teleport 구축

Fri, 10 Oct 2025 09:00:00 +0900

매니지드 K8S가 아닌 자체 관리형 K8S에서의 Teleport구축 방법

UI 접근을 위한 외부 통신으로 MetalLB+HAproxy+Nginx Controller가 구성 되었다는 전제 하에 구축

CSP 환경이라면 Ingress 설정에서 AWS ALB Controller와 같은 로드밸런서를 사용해 훨씬 간편하게 구축 가능

Teleport 공식문서: https://goteleport.com/docs/ https://goteleport.com/docs/zero-trust-access/deploy-a-cluster/helm-deployments/kubernetes-cluster/

Teleport 설치

Helm 리포지토리 추가

1
2


helm repo add teleport https://charts.releases.teleport.dev
helm repo update

teleport-cluster 네임스페이스 생성

네임스페이스에 baseline 보안 수준 적용

1
2


kubectl create ns teleport-cluster
kubectl label namespace teleport-cluster 'pod-security.kubernetes.io/enforce=baseline'

pvc 생성

teleportpvc.yaml
- kubectl apply -f teleportpvc.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: teleport-pvc
 namespace: teleport-cluster
spec:
 accessModes: ["ReadWriteOnce"]
 storageClassName: longhorn
 resources:
 requests:
 storage: 10Gi

SSL 인증서 Secret 등록

인증서 발급
- /etc/letsencrypt/live/teleport.<도메인>/fullchain.pem
- /etc/letsencrypt/live/teleport.<도메인>/privkey.pem

1
2
3


certbot certonly --manual --preferred-challenges dns \
 -d teleport.<도메인> \
 --key-type ecdsa

secret 생성

1
2
3


kubectl -n teleport-cluster create secret tls teleport-tls \
 --cert=/etc/letsencrypt/live/teleport.<도메인>/fullchain.pem \
 --key=/etc/letsencrypt/live/teleport.<도메인>/privkey.pem

teleport 설치

https://goteleport.com/docs/reference/helm-reference/

values.yaml 수정

helm으로 설치

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


helm show values teleport/teleport-cluster > values.yaml
vim values.yaml

helm install teleport teleport/teleport-cluster \
 -f values.yaml \
 -n teleport-cluster

helm upgrade --install teleport teleport/teleport-cluster \
 -f values.yaml \
 -n teleport-cluster

클러스터 이름 기입
1

clusterName: teleport.<도메인>

외부 접근 주소

1
2


publicAddr: ['teleport.<도메인>:8443']
tunnelPublicAddr: ['teleport.<도메인>:8443']

프록시가 443 포트 하나에서 ALPN으로 Web UI/SSH 리버스 터널/Kubernetes 프록시를 다 처리
- 기본값이 seprate인데 이렇게 되면 3024/3025/3026 등등 각각 포트 사용해야함
- 외부 주소는 publicAddr로 노출됨
1

proxyListenerMode: "multiplex"

Proxy Service

1
2
3
4
5


service:
 type: LoadBalancer
 spec:
 # MetalLB에서 고정 IP를 쓰고 싶을 때만 지정
 # loadBalancerIP: 172.27.1.103

ACME 비활성화
1

acme: false
TLS 인증서 Secret 지정
- cert-manager가 발급한 Secret 이름으로 설정
1 2

tls: existingSecretName: teleport-tls

Auth 스토리지 PV 설정

pv는 longhorn이 자동으로 프로비저닝

1
2
3
4


persistence:
 enabled: true
 existingClaimName: "teleport-pvc"
 volumeSize: 10Gi

HA replica 설정
- HA 안쓰면 1
1 2

highAvailability: replicaCount: 1

Teleport UI 접근

Teleport는 443포트에서 HTTPS/SSH 리버스 터널/K8S Access Proxy 등을 ALPN으로 동시에 처리하기 때문에, 다른 애플리케이션처럼 ingress로 프록시하면 안됨
- ingress가 처리하면 ALPN 정보가 사라져서 Teleport Proxy는 트래픽의 소스를 알 수 없게 됨
  - web ui는 접근 되더라도 tsh login, tctl, kubectl 등은 모두 실패할 것
- Teleport의 Proxy 서비스를 Load Balancer 타입 서비스로 생성해야 함
마찬가지 이유로 haproxy 설정에서도 L7 프록시 말고 L4 프록시가 필요

HAproxy 설정

values로 생성한 load balancer를 조회하여 MetalLB로부터 부여받은 IP 확인

현재는 172.27.1.103

1
2
3


# kubectl get svc -n teleport-cluster 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
teleport LoadBalancer 10.233.62.211 172.27.1.103 443:30523/TCP,3023:31718/TCP,3026:31539/TCP,3024:31393/TCP,3036:30139/TCP 56s

확인한 IP를 HAproxy 설정에 추가

HAproxy 서버 공인 IP로 접근 시 teleport의 LB Service로 통신되도록 설정

1
2
3


vim /etc/haproxy/haproxy.cfg
haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

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


frontend unified_frontend_8443
 bind *:8443
 mode tcp
 option tcplog
 tcp-request inspect-delay 5s
 tcp-request content accept if { req_ssl_hello_type 1 }
 use_backend metallb_backend_teleport if { req.ssl_sni -i teleport.<도메인> }
 default_backend metallb_backend_teleport

backend metallb_backend_teleport
 mode tcp
 server teleport 172.27.1.103:443

접근 성공!

K8S에 구축한 GitLab Registry에 Container Image 푸시 시 blob upload unknown 에러 TroubleShooting

Sat, 27 Sep 2025 09:00:00 +0900

GitLab을 Helm Chart로 구축 + 브라우저에서 GitLab 접근 시 80 포트가 아닌 다른 포트로 접근해야 할 경우 발생하는 이슈 GitLab Helm Chart의 포트 설정이 80/443으로 고정되어 있기 때문에 발생

환경

자체 관리형 kubernetes이기에 외부용 L7 로드밸런서로 haproxy를 사용 중인 경우
helm chart로 GitLab 서버를 구축한 경우
외부에서 브라우저로 GitLab UI 접근 시 80포트가 아닌 8080과 같은 별도의 포트로만 접근해야하는 제약사항이 있는 경우

문제 상황

helm chart로 GitLab 서버 구축 후 <도메인>:<포트>로 접근 시 포트가 제거된 후 도메인으로만 강제 리다이렉션 되는 현상 발생
- 404 에러
브라우저 → HAProxy(8080) → GitLab(80) → 리다이렉트 응답

해결 방법

HAproxy 설정을 통해 포트를 포함해서 리다이렉트 하도록 설정

http-response replace-value Location ^http://gitlab\.<도메인>/(.*)$ http://gitlab.<도메인>:8080/\\1

정규식 분석:
- ^http://gitlab.<도메인>/(.*)$ - 매칭 패턴
- http://gitlab.<도메인>:8080/\1 - 치환 결과
- \1 = 첫 번째 그룹 (.*) 내용 (URL 경로)
- 변환 예시:
  - 원본: Location: http://gitlab.<도메인>/users/sign_in
  - 변환: Location: http://gitlab.<도메인>/users/sign_in
외부 브라우저에서 GitLab 접근 시 포트를 붙여서 접근해야 될 경우 반드시 설정
설정하지 않으면 접근 시 자동으로 포트가 제거된 상태로 리다이렉션되어 404 에러

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


frontend unified_frontend_8080
 bind *:8080
 mode http
 option forwardfor

 # Host 기반 라우팅
 ...
 use_backend metallb_backend_gitlab if { hdr(host) -i gitlab.<도메인> }
 ...

backend metallb_backend_gitlab
 http-response replace-value Location ^http://gitlab\.<도메인>/(.*)$ http://gitlab.<도메인>:8080/\\1
 server gitlab 172.27.1.102:80

결과

브라우저가 8080포트를 포함해서 리다이렉트
HAProxy를 통한 접속 유지

K8S에 구축한 Jenkins CI 파이프라인의 Dind 네트워크 에러 TroubleShooting

Sat, 27 Sep 2025 09:00:00 +0900

K8S 환경의 Jenkins에서 docker build가 Jenkins 파이프라인 파드의 dind 컨테이너에서 실행되기 때문에 발생한 이슈

환경

Jenkins 서버를 K8S에서 구축하고, 파이프라인을 K8S 파드에서 동작하도록 설정한 환경
- Jenkinsfile에서 K8S 파드 템플릿으로 파이프라인 실행하게 명시

문제 상황

Jenkinsfile의 docker build 단계에서 파이프라인 빌드 실패
- Dockerfile의 composer install 레이어에서 Could not fetch https://api.github.com/repos/ 에러 발생
- 외부에서 데이터를 받아오는 명령어에서 전부 timeout 에러 발생

에러 분석

Jenkins 파이프라인이 K8S 파드의 docker 컨테이너에서 실행되고, docker build 작업은 dind 컨테이너에서 실행됨
- dind 컨테이너 입장에서 네트워크가 격리되어 있어 GitHub API 서버로의 아웃바운드 연결 불가
따라서 composer install 와 같은 명령어 실행 시 연결 실패 에러 발생

해결 방법

Jenkinsfile의 k8s 파드 템플릿에 hostNetwork: true를 설정해서 파드의 컨테이너가 호스트 노드(현재 워커 노드)의 네트워크 네임스페이스를 사용할 수 있도록 설정
- 파드 템플릿이 아닌 docker build --network=host로 명령어 마다 옵션을 명시해서 해결도 가능하지만, 파드 레벨에서 해결하는게 관리에 용이

 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


kubernetes {
 yaml """
 apiVersion: v1
 kind: Pod
 spec:
 serviceAccountName: jenkins
 hostNetwork: true
 hostAliases:
 - ip: "172.27.1.9"
 hostnames:
 - "registry.<도메인>"
 - "gitlab.<도메인>"
 containers:
 - name: docker
 image: docker
 command:
 - sleep
 args:
 - 99d
 tty: true
 volumeMounts:
 - name: workspace-volume
 mountPath: /home/jenkins/agent
 - name: docker-socket
 mountPath: /var/run
 - name: docker-daemon
 image: docker:dind
 securityContext:
 privileged: true
 env:
 - name: DOCKER_TLS_CERTDIR
 value: ""
 args:
 - --insecure-registry=registry.<도메인>:8080
 volumeMounts:
 - name: docker-socket
 mountPath: /var/run
 volumes:
 - name: workspace-volume
 emptyDir: {}
 - name: docker-socket
 emptyDir: {}
 """
 }

K8S에 구축한 GitLab UI 접근 시 접근 포트가 제거된 상태로 강제 리다이렉션 TroubleShooting

Thu, 25 Sep 2025 09:00:00 +0900

GitLab을 Helm Chart로 구축 + 브라우저에서 GitLab 접근 시 80 포트가 아닌 다른 포트로 접근해야 할 경우 발생하는 이슈 GitLab Helm Chart의 포트 설정이 80/443으로 고정되어 있기 때문에 발생

환경

자체 관리형 kubernetes이기에 외부용 L7 로드밸런서로 haproxy를 사용 중인 경우
helm chart로 GitLab 서버를 구축한 경우
외부에서 브라우저로 GitLab UI 접근 시 80포트가 아닌 8080과 같은 별도의 포트로만 접근해야하는 제약사항이 있는 경우

문제 상황

helm chart로 GitLab 서버 구축 후 <도메인>:<포트>로 접근 시 포트가 제거된 후 도메인으로만 강제 리다이렉션 되는 현상 발생
- 404 에러
브라우저 → HAProxy(8080) → GitLab(80) → 리다이렉트 응답

해결 방법

HAproxy 설정을 통해 포트를 포함해서 리다이렉트 하도록 설정

http-response replace-value Location ^http://gitlab\.<도메인>/(.*)$ http://gitlab.<도메인>:8080/\\1

정규식 분석:
- ^http://gitlab.<도메인>/(.*)$ - 매칭 패턴
- http://gitlab.<도메인>:8080/\1 - 치환 결과
- \1 = 첫 번째 그룹 (.*) 내용 (URL 경로)
- 변환 예시:
  - 원본: Location: http://gitlab.<도메인>/users/sign_in
  - 변환: Location: http://gitlab.<도메인>/users/sign_in
외부 브라우저에서 GitLab 접근 시 포트를 붙여서 접근해야 될 경우 반드시 설정
설정하지 않으면 접근 시 자동으로 포트가 제거된 상태로 리다이렉션되어 404 에러

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


frontend unified_frontend_8080
 bind *:8080
 mode http
 option forwardfor

 # Host 기반 라우팅
 ...
 use_backend metallb_backend_gitlab if { hdr(host) -i gitlab.<도메인> }
 ...

backend metallb_backend_gitlab
 http-response replace-value Location ^http://gitlab\.<도메인>/(.*)$ http://gitlab.<도메인>:8080/\\1
 server gitlab 172.27.1.102:80

결과

브라우저가 8080포트를 포함해서 리다이렉트
HAProxy를 통한 접속 유지

자체 관리형 Kubernetes에서의 GitLab 구축

Wed, 24 Sep 2025 09:00:00 +0900

매니지드 K8S가 아닌 자체 관리형 K8S에서의 GitLab 구축 방법

UI 접근을 위한 외부 통신으로 MetalLB+HAproxy+Nginx Controller가 구성 되었다는 전제 하에 구축

CSP 환경이라면 Ingress 설정에서 AWS ALB Controller와 같은 로드밸런서를 사용해 훨씬 간편하게 구축 가능

GitLab 공식문서: ****https://docs.gitlab.com/install/install_methods/#helm-chart
GitLab Artifacthub 문서: https://artifacthub.io/packages/helm/gitlab/gitlab

GitLab 설치

Helm 리포지토리 추가

1
2


helm repo add gitlab https://charts.gitlab.io/
helm repo update

gitlab 네임스페이스 생성
1

kubectl create ns gitlab

gitlab-pv 생성(StorageClass 없을 시에만 진행)

기존에 사용하던 Ceph, Longhorn, EBS Driver, Harbor 같은 StorageClass가 없을 경우에 로컬 경로를 사용한 PV 할당 방법
- StorageClass가 있다면 PVC 생성 시 자동으로 PV가 할당되기 때문에 이 과정은 불필요

1
2


vim gitlab-01-volume.yaml
kubectl apply -f gitlab-01-volume.yaml

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


apiVersion: v1
kind: PersistentVolume
metadata:
 name: gitlab-pv
spec:
 storageClassName: gitlab-pv
 accessModes:
 - ReadWriteOnce
 capacity:
 storage: 20Gi
 persistentVolumeReclaimPolicy: Retain
 hostPath:
 path: /data/gitlab-volume/

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: gitlab-pv
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

gitlab 설치

values.yaml 수정
- helm으로 설치

1
2
3
4


helm show values gitlab/gitlab > values.yaml
vim values.yaml

helm install gitlab -n gitlab -f values.yaml gitlab/gitlab

소스코드 리포지토리 설정

1
2
3
4
5
6


# GitLab Gitaly (Git 저장소)
gitlab:
 gitaly:
 persistence:
 storageClass: "longhorn"
 size: 20Gi

postgresql, redis 설정
- postgresql: gitlab 전체의 메타데이터 저장
  - redis: 사용자 세션, 백그라운드 작업, 캐시, 알림 등에 사용

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


# PostgreSQL
postgresql:
 primary:
 persistence:
 storageClass: "longhorn"
 size: 8Gi

# Redis 
redis:
 master:
 persistence:
 storageClass: "longhorn"
 size: 2Gi

minio설정
- https://docs.gitlab.com/charts/charts/globals#configure-minio-settings
- S3와 호환되는 오브젝트 스토리지

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


global:

 # minio 서비스 활성화
 minio:
 enabled: true

 # 바이너리 파일들이 오브젝트 스토리지를 사용할 수 있도록 설정
 appConfig:
 object_store
 enabled: true

 # Container Registry가 minio의 registry 버킷을 사용
 registry:
 bucket: registry

# minio가 Longhorn을 통한 PV 사용
minio:
 persistence:
 enabled: true
 size: 10Gi
 storageClass: longhorn

불필요한 기능 비활성화

 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
28


global:
 lfs:
 enabled: false
 uploads:
 enabled: false
 toolbox:
 enabled: false

# GitLab KAS 비활성화 (Kubernetes Agent)
global:
 kas:
 enabled: false

# CI/CD 관련 비활성화
global:
 appConfig:
 artifacts:
 enabled: false
 packages:
 enabled: false

# 모니터링 비활성화
prometheus:
 install: false

# GitLab Runner 비활성화
gitlab-runner:
 install: false

도메인, 에디션(CE/EE)

1
2
3
4


global:
 edition: ce
 hosts:
 domain: <도메인>

http 접근을 위한 설정

1
2
3
4
5
6
7
8


global:
 hosts:
 https: false
 ingress:
 configureCertmanager: false
 tls:
 enabled: false
installCertmanager: false

GitLab UI

GitLab Helm Chart를 통해 ingress는 생성 완료!

values.yaml 내에 ingress 생성을 위한 nginx 설정이 포함되어 있음

HAproxy 설정

ingress를 조회하여 MetalLB로부터 부여받은 IP 확인

현재는 172.27.1.102

1
2
3
4


# kubectl get ingress -n gitlab
NAME CLASS HOSTS ADDRESS PORTS AGE
gitlab-registry gitlab-nginx registry.<도메인> 172.27.1.102 80 61m
gitlab-webservice-default gitlab-nginx gitlab.<도메인> 172.27.1.102 80 61m

확인한 IP를 HAproxy 설정에 추가

HAproxy 서버 공인 IP로 접근 시 gitlab의 Ingress로 통신되도록 설정
http-response replace-value Location ^http://gitlab\.<도메인>/(.*)$ http://gitlab.<도메인>:<포트>/\\1
두 조건을 만족할 경우 설정 필요
- 외부 브라우저에서 GitLab 접근 시 포트를 붙여서 접근해야 될 경우
- 애플리케이션 내부적으로 url로 응답이 나오도록 설정되어 있을 경우
  - EX) GitLab 로그인 시 GitLab에 설정된 url 응답
설정하지 않으면 접근 시 자동으로 포트가 제거된 상태로 리다이렉션되어 404 에러

1
2
3


vim /etc/haproxy/haproxy.cfg
haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

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


frontend unified_frontend_8080
 bind *:8080
 mode http
 option forwardfor

 http-request set-header X-Forwarded-Host %[req.hdr(host)]
 http-request set-header X-Forwarded-Proto http
 http-request set-header X-Forwarded-Port %[dst_port]

 # Host 기반 라우팅
 use_backend metallb_backend_gitlab if { hdr(host) -m sub gitlab }
 # GitLab Container Registry를 위한 경로
 use_backend metallb_backend_gitlab if { hdr(host) -m sub registry }

backend metallb_backend_gitlab
 http-response replace-value Location ^http://gitlab\.<도메인>/(.*)$ http://gitlab.<도메인>:<포트>/\\1
 server gitlab 172.27.1.100:80

접근 성공!

gitlab 관리자(root) 비밀번호 확인

1

kubectl get secret gitlab-gitlab-initial-root-password -n gitlab -o jsonpath="{.data.password}" | base64 --decode

자체 관리형 Kubernetes에서 Metrics Server를 통한 매트릭 자원 확인

Mon, 22 Sep 2025 09:00:00 +0900

kubectl top node node1과 같이 즉각적인 매트릭 자원 확인이 가능하도록 설정

GitHub: https://github.com/kubernetes-sigs/metrics-server?tab=readme-ov-file
Artifacthub: https://artifacthub.io/packages/helm/metrics-server/metrics-server
helm 리포지토리 추가

1
2


helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm upgrade

values.yaml 수정

1
2


helm show values metrics-server/metrics-server > metrics-server-values.yaml
vim metrics-server-values.yaml

metrics server가 tls 인증서를 검증하지 않도록 설정

1
2


args:
 - --kubelet-insecure-tls

metrics server 설치

1

helm upgrade --install metrics-server metrics-server/metrics-server -f metrics-server-values.yaml

자체 관리형 Kubernetes에서의 Prometheus와 Grafana 구축

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

매니지드 K8S가 아닌 자체 관리형 K8S에서의 Prometheus + Grafana 구축 방법

UI 접근을 위한 외부 통신으로 MetalLB+HAproxy+Nginx Controller가 구성 되었다는 전제 하에 구축

CSP 환경이라면 Ingress 설정에서 AWS ALB Controller와 같은 로드밸런서를 사용해 훨씬 간편하게 구축 가능

Prometheus 공식문서: https://prometheus.io/docs/prometheus/latest/installation/
Grafana 공식문서: https://grafana.com/docs/grafana/latest/setup-grafana/installation/

개요

kube-prometheus-stack helm chart 구조

1
2
3
4
5
6
7
8


kube-prometheus-stack
├── Prometheus Operator (핵심 엔진)
├── Prometheus 인스턴스
├── Grafana (시각화 대시보드)
├── AlertManager (알람 관리)
├── Node Exporter (Node 매트릭 수집)
├── kube-state-metrics (K8S 리소스 매트릭 수집)
└── 기본 ServiceMonitors/PrometheusRules (정책)

Prometheus Operator란

CRD 기반 Prometheus 관리 도구
Prometheus, ServiceMonitor, PrometheusRule 등의 Custom Resource 제공
선언적 방식으로 Prometheus 설정 관리

Prometheus + Grafana 설치

깃허브: https://github.com/prometheus-community/helm-charts

helm 리포지토리 추가

1
2
3


helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

kube-prometheus-stack 설치

prometheus + grafana 합쳐진 패키지
values.yaml 수정

1

helm show values prometheus-community/kube-prometheus-stack > values.yaml

grafana pvc 설정

1
2
3
4
5
6
7


 persistence:
 enabled: true
 type: sts
 storageClassName: "longhorn"
 accessModes:
 - ReadWriteOnce
 size: 5Gi

prometheus pvc 설정
- selector: {} 삭제
  - longhorn은 selector 지원하지 않음

1
2
3
4
5
6
7
8


 storageSpec:
 volumeClaimTemplate:
 spec:
 storageClassName: longhorn
 accessModes: ["ReadWriteOnce"]
 resources:
 requests:
 storage: 40Gi

alertmanager pvc 설정
- selector: {} 삭제
  - longhorn은 selector 지원하지 않음

1
2
3
4
5
6
7
8


 storage:
 volumeClaimTemplate:
 spec:
 storageClassName: longhorn
 accessModes: ["ReadWriteOnce"]
 resources:
 requests:
 storage: 2Gi

kube-prometheus-stack 설치

1

helm install prometheus prometheus-community/kube-prometheus-stack -f values.yaml --namespace monitoring --create-namespace

Grafana UI 접근

ingress 생성

8082포트를 사용하는 grafana service로 연결

 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


cat <<EOF > grafana-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: grafana-ingress
 namespace: monitoring
 annotations:
 nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
 nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
 ingressClassName: nginx
 rules:
 - host: "grafana.<도메인>"
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: prometheus-grafana
 port:
 number: 80
EOF

kubectl -n monitoring apply -f grafana-ingress.yaml

HAproxy 설정

ingress를 조회하여 MetalLB로부터 부여받은 IP 확인

현재는 172.27.1.100

1
2
3
4


# kubectl get ingress -n monitoring 
# kubectl get ingress -n monitoring 
NAME CLASS HOSTS ADDRESS PORTS AGE
grafana-ingress nginx grafana.<도메인> 172.27.1.100 80 9s

확인한 IP를 HAproxy 설정에 추가

HAproxy 서버 공인 IP로 접근 시 grafana의 Ingress로 통신되도록 설정

1
2
3


vim /etc/haproxy/haproxy.cfg
haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

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


frontend unified_frontend_8080
 bind *:8080
 mode http
 option forwardfor

 http-request set-header X-Forwarded-Host %[req.hdr(host)]
 http-request set-header X-Forwarded-Proto http
 http-request set-header X-Forwarded-Port %[dst_port]

 # Host 기반 라우팅
 use_backend metallb_backend_grafana if { hdr(host) -m sub grafana }

backend metallb_backend_grafana
 server grafana 172.27.1.100:80

접근 성공!

Grafana 관리자 비밀번호 확인

1

kubectl --namespace monitoring get secrets prometheus-grafana -o jsonpath="{.data.admin-password}" | base64 -d ; echo

대시보드 그래프 origin not allowed 에러 발생 시

IP주소로의 직접 접근을 Grafana의 CSRF 정책이 요청 차단

도메인을 통해 접근해서 CSRF 정책 통과

ingrass, haproxy에 설정되어있던 grafana.local을 새로 설정한 도메인으로 변경
values.yaml 수정

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


 grafana:
 ...
 adminPassword: <GRAFANA_PASSWORD>
 grafana.ini:
 server:
 domain: <도메인>:48082
 root_url: http://<도메인>:48082
 security:
 csrf_trusted_origins: "<도메인>:48082"
 csrf_cookies_secure: false
 cookie_secure: false
 cookie_samesite: lax
 ...

설정 반영

1
2
3
4



helm uninstall prometheus --namespace monitoring
kubectl --namespace monitoring delete pvc --all
helm install prometheus prometheus-community/kube-prometheus-stack -f values.yaml --namespace monitoring

Prometheus UI 접근

ingress 생성

8080포트를 사용하는 prometheus service로 연결

 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


cat <<EOF > prometheus-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: prometheus-ingress
 namespace: monitoring
 annotations:
 nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
 nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
 ingressClassName: nginx
 rules:
 - host: "prometheus.local"
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: prometheus-kube-prometheus-prometheus
 port:
 number: 9090
EOF

kubectl -n monitoring apply -f prometheus-ingress.yaml

HAproxy 설정

ingress를 조회하여 MetalLB로부터 부여받은 IP 확인

현재는 172.27.1.100

1
2
3


# kubectl get ingress -n monitoring 
NAME CLASS HOSTS ADDRESS PORTS AGE
prometheus-ingress nginx prometheus.<도메인> 172.27.1.100 80 9s

확인한 IP를 HAproxy 설정에 추가

HAproxy 서버 공인 IP로 접근 시 prometheus의 Ingress로 통신되도록 설정

1
2
3


vim /etc/haproxy/haproxy.cfg
haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

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


frontend unified_frontend_8080
 bind *:8080
 mode http
 option forwardfor

 http-request set-header X-Forwarded-Host %[req.hdr(host)]
 http-request set-header X-Forwarded-Proto http
 http-request set-header X-Forwarded-Port %[dst_port]

 # Host 기반 라우팅
 use_backend metallb_backend_prometheus if { hdr(host) -m sub prometheus }

backend metallb_backend_prometheus
 server prometheus 172.27.1.100:80

접근 성공!

자체 관리형 Kubernetes에서의 분산 스토리지 Longhorn 구축

Sun, 07 Sep 2025 09:00:00 +0900

매니지드 K8S가 아닌 자체 관리형 K8S에서의 Longhorn 구축 방법

UI 접근을 위한 외부 통신으로 MetalLB+HAproxy+Nginx Controller가 구성 되었다는 전제 하에 구축

CSP 환경이라면 Ingress 설정에서 AWS ALB Controller와 같은 로드밸런서를 사용해 훨씬 간편하게 구축 가능

개요

자체 관리형 K8S에서 애플리케이션의 데이터를 고가용성으로 운영하려면 Ceph, Longhorn 같은 분산 블록 스토리지 툴이 필요
- 노드마다 데이터를 복제해서 저장하는 분산 블록 스토리지
- Ceph, Longhorn 같은 툴이 없다면 파드는 워커노드의 로컬 경로에만 데이터를 저장해야 하는데, 이러면 워커노드 장애가 발생할 경우 데이터 가용성 보장이 안됨
  - NFS를 StorageClass로 사용할 수 도 있지만, NFS는 단일 서버, 단일 네트워크 I/O에 의존하기 때문에, 성능과 장애 내구성이 떨어져 PV 데이터 저장 용도로는 부적합
- Ceph 퍼포먼스가 더 뛰어나지만 리소스 자원을 꽤 점유하는 툴이므로, 현재 환경에서는 Longhorn을 사용
  - 워커 노드가 5대 이상, 8vCPU 16GB 이상인 스펙이어도 Longhorn으로 충분히 운영 가능

Longhorn을 쓰면 PVC를 생성하는 것 만으로도 PV가 자동으로 프로비저닝됨!!!

AWS라면 EBS같은 스토리지를 통해 고가용성 확보 가능
- ALB Controller와 마찬가지로 CSP 관리형 K8S를 쓰는 또하나의 이유

구조

PVC가 생성되면 Longhorn Volume을 관리하는 Engine Pod가 생성되고, 하위에 Replica Pod들이 각 노드에 생성됨
- Replica Pod는 해당 노드의 특정 경로에 전체 데이터 replica를 저장
- 쓰기 I/O는 Engine Pod가 받아서 모든 Replica Pod에 동기 복제한 뒤 성공을 리턴
Pod가 노드1에서 노드2로 옮겨지면 Longhorn이 볼륨을 노드1에서 detatch 했다가 노드2로 attatch
- 이때 노드2에 Replica가 있으면 그대로 사용, 없으면 다른 Replica에서 동기받아서 새 Replica 생성

Longhorn 설치

helm 리포지토리 추가s

1
2


helm repo add longhorn https://charts.longhorn.io
helm repo update

values.yaml 수정

1
2
3


helm pull longhorn/longhorn --untar
cd longhorn
vim values.yaml

1
2
3
4
5
6
7
8


persistence:
 ...
 defaultClassReplicaCount: 2

defaultSettings:
 ...
 defaultDataPath: /data
 defaultReplicaCount: 2

helm 설치

1
2
3
4
5


helm install longhorn longhorn/longhorn \
 --namespace longhorn-system \
 --create-namespace \
 --values values.yaml
kubectl -n longhorn-system get pod

Longhorn UI 접속

https://longhorn.io/docs/1.9.1/deploy/accessing-the-ui/

auth 파일 생성

반드시 auth라는 이름으로 생성 필요

1

USER=<USERNAME_HERE>; PASSWORD=<PASSWORD_HERE>; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> auth

secret 생성

1

kubectl -n longhorn-system create secret generic basic-auth --from-file=auth

ingress 생성

80포트를 사용하는 longhorn service로 연결

 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
28
29
30
31
32
33


cat <<EOF > longhorn-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: longhorn-ingress
 namespace: longhorn-system
 annotations:
 # type of authentication
 nginx.ingress.kubernetes.io/auth-type: basic
 # prevent the controller from redirecting (308) to HTTPS
 nginx.ingress.kubernetes.io/ssl-redirect: 'false'
 # name of the secret that contains the user/password definitions
 nginx.ingress.kubernetes.io/auth-secret: basic-auth
 # message to display with an appropriate context why the authentication is required
 nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required '
 # custom max body size for file uploading like backing image uploading
 nginx.ingress.kubernetes.io/proxy-body-size: 10000m
spec:
 ingressClassName: nginx
 rules:
 - host: "longhorn.local"
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: longhorn-frontend
 port:
 number: 80
EOF

kubectl -n longhorn-system apply -f longhorn-ingress.yaml

HAproxy 설정

ingress를 조회하여 MetalLB로부터 부여받은 IP 확인

현재는 172.27.1.100

1
2
3


# kubectl get ingress -n longhorn-system 
NAME CLASS HOSTS ADDRESS PORTS AGE
longhorn-ingress nginx longhorn.local 172.27.1.100 80 8s

확인한 IP를 HAproxy 설정에 추가

HAproxy 서버 공인 IP로 접근 시 Longhorn의 Ingress로 통신되도록 설정

1
2
3


vim /etc/haproxy/haproxy.cfg
haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

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


frontend unified_frontend_8080
 bind *:8080
 mode http
 option forwardfor

 http-request set-header X-Forwarded-Host %[req.hdr(host)]
 http-request set-header X-Forwarded-Proto http
 http-request set-header X-Forwarded-Port %[dst_port]

 # Host 기반 라우팅
 use_backend metallb_backend_longhorn if { hdr(host) -m sub longhorn }

backend metallb_backend_longhorn
 server longhorn 172.27.1.100:80

접근 성공!

자체 관리형 Kubernetes에서의 Jenkins 구축

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

매니지드 K8S가 아닌 자체 관리형 K8S에서의 Jenkins 구축 방법

UI 접근을 위한 외부 통신으로 MetalLB+HAproxy+Nginx Controller가 구성 되었다는 전제 하에 구축

CSP 환경이라면 Ingress 설정에서 AWS ALB Controller와 같은 로드밸런서를 사용해 훨씬 간편하게 구축 가능

Jenkins 공식문서: ****https://www.jenkins.io/doc/book/installing/kubernetes/

Jenkins 설치

Helm 리포지토리 추가

1
2


helm repo add jenkinsci https://charts.jenkins.io
helm repo update

jenkins-ci 네임스페이스 생성
1

kubectl create ns jenkins

jenkins-pv 생성(기존 StorageClass 없을 시에만 진행)

기존에 사용하던 Ceph, Longhorn, EBS Driver, Harbor 같은 StorageClass가 없을 경우에 로컬 경로를 사용한 PV 할당 방법
- StorageClass가 있다면 PVC 생성 시 자동으로 PV가 할당되기 때문에 이 과정은 불필요

1
2


vim jenkins-01-volume.yaml
kubectl apply -f jenkins-01-volume.yaml

https://raw.githubusercontent.com/jenkins-infra/jenkins.io/master/content/doc/tutorials/kubernetes/installing-jenkins-on-kubernetes/jenkins-01-volume.yaml

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


apiVersion: v1
kind: PersistentVolume
metadata:
 name: jenkins-pv
spec:
 storageClassName: jenkins-pv
 accessModes:
 - ReadWriteOnce
 capacity:
 storage: 20Gi
 persistentVolumeReclaimPolicy: Retain
 hostPath:
 path: /data/jenkins-volume/

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: jenkins-pv
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

ServiceAccount 생성

1
2


vim jenkins-02-sa.yaml
kubectl apply -f jenkins-02-sa.yaml

https://raw.githubusercontent.com/jenkins-infra/jenkins.io/master/content/doc/tutorials/kubernetes/installing-jenkins-on-kubernetes/jenkins-02-sa.yaml

 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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76


---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: jenkins
 namespace: jenkins
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 annotations:
 rbac.authorization.kubernetes.io/autoupdate: "true"
 labels:
 kubernetes.io/bootstrapping: rbac-defaults
 name: jenkins
rules:
- apiGroups:
 - '*'
 resources:
 - statefulsets
 - services
 - replicationcontrollers
 - replicasets
 - podtemplates
 - podsecuritypolicies
 - pods
 - pods/log
 - pods/exec
 - podpreset
 - poddisruptionbudget
 - persistentvolumes
 - persistentvolumeclaims
 - jobs
 - endpoints
 - deployments
 - deployments/scale
 - daemonsets
 - cronjobs
 - configmaps
 - namespaces
 - events
 - secrets
 verbs:
 - create
 - get
 - watch
 - delete
 - list
 - patch
 - update
- apiGroups:
 - ""
 resources:
 - nodes
 verbs:
 - get
 - list
 - watch
 - update
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 annotations:
 rbac.authorization.kubernetes.io/autoupdate: "true"
 labels:
 kubernetes.io/bootstrapping: rbac-defaults
 name: jenkins
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: jenkins
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:serviceaccounts:jenkins

jenkins 설치

https://github.com/jenkinsci/helm-charts/tree/main/charts/jenkins

helm으로 설치
values.yaml 수정

1
2
3
4


wget https://raw.githubusercontent.com/jenkinsci/helm-charts/main/charts/jenkins/values.yaml
vim values.yaml

helm install jenkins -n jenkins -f values.yaml jenkinsci/jenkins

helm을 통해 pvc 자동 생성

pv는 longhorn이 자동으로 프로비저닝
SA는 2번에서 생성한 리소스 사용

1
2
3
4
5
6
7


persistence:
 storageClass: longhorn
 size: "20Gi"

serviceAccount:
 create: false
 name: jenkins

Jenkins UI 접근

ingress 생성

8080포트를 사용하는 jenkins service로 연결

 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


cat <<EOF > jenkins-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: jenkins-ingress
 namespace: jenkins
 annotations:
 nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
 nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
 ingressClassName: nginx
 rules:
 - host: "jenkins.<도메인>"
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: jenkins
 port:
 number: 8080
EOF

kubectl -n jenkins apply -f jenkins-ingress.yaml

HAproxy 설정

ingress를 조회하여 MetalLB로부터 부여받은 IP 확인

현재는 172.27.1.100

1
2
3


# kubectl get ingress -n jenkins
NAME CLASS HOSTS ADDRESS PORTS AGE
jenkins-ingress nginx jenkins.<도메인> 172.27.1.100 80 26h

확인한 IP를 HAproxy 설정에 추가

HAproxy 서버 공인 IP로 접근 시 jenkins의 Ingress로 통신되도록 설정
http-response replace-value Location ^http://jenkins\.<도메인>/(.*)$ http://jenkins.<도메인>:<포트>/\\1
두 조건을 만족할 경우 설정 필요
- 외부 브라우저에서 Jenkins 접근 시 포트를 붙여서 접근해야 될 경우
- 애플리케이션 내부적으로 url로 응답이 나오도록 설정되어 있을 경우
  - EX) Jenkins 파이프라인 빌드 시 파라미터를 기입해야 할 경우 Jenkins 설정된 url 응답
설정하지 않으면 접근 시 자동으로 포트가 제거된 상태로 리다이렉션되어 404 에러

1
2
3


vim /etc/haproxy/haproxy.cfg
haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

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


frontend unified_frontend_8080
 bind *:8080
 mode http
 option forwardfor

 http-request set-header X-Forwarded-Host %[req.hdr(host)]
 http-request set-header X-Forwarded-Proto http
 http-request set-header X-Forwarded-Port %[dst_port]

 # Host 기반 라우팅
 use_backend metallb_backend_jenkins if { hdr(host) -m sub jenkins }

backend metallb_backend_jenkins
 http-response replace-value Location ^http://jenkins\.<도메인>/(.*)$ http://jenkins.<도메인>:<포트>/\\1
 server jenkins 172.27.1.100:80

접근 성공!

Jenkins 관리자 비밀번호 확인

1
2
3


jsonpath="{.data.jenkins-admin-password}"
secret=$(kubectl get secret -n jenkins jenkins -o jsonpath=$jsonpath)
echo $(echo $secret | base64 --decode)

외부에서 자체 관리형 Kubernetes 접근을 위한 MetalLB/HAproxy 설정과 통신 구조

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

외부에서의 로컬 K8S 클러스터 접근을 위해 MetalLB와 HAproxy를 사용
K8S 클러스터 내부의 로드밸런서로는 nginx controller를 사용 중인 상태
- AWS라면, ALB Controller 하나만으로 MetalLB+HAproxy+nginxcontroller 기능을 커버 가능
- 사실상의 CSP의 K8S를 쓰는 이유??

MetalLB

https://metallb.universe.tf/installation/

클러스터 내부용 로드밸런서
- 오픈소스
- CSP의 LB를 사용하지 못하는 경우(내/외부 양쪽에서 사용가능한 LB)에, 내부용 L4 로드밸런서로 사용하기 위해 주로 MetalLB를 사용

사전 준비

kube-proxy의 configmap에서 strictARP 활성화

1
2
3
4
5
6
7


kubectl edit configmap -n kube-system kube-proxy

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
 strictARP: true

MetalLB 설치

helm으로 설치

1
2


helm repo add metallb https://metallb.github.io/metallb
helm install metallb metallb/metallb

MetalLB 설정

IP Pool 설정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
 name: default-pool
 namespace: default
spec:
 addresses:
 - 172.27.1.100-172.27.1.110
EOF

L2Advertisement 설정

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
 name: default
 namespace: default
spec:
 ipAddressPools:
 - default-pool
EOF

HAproxy

haproxy 설치

1
2


yum install -y haproxy
systemctl enable --now haproxy

haproxy 설정
- Jenkins를 예시로 구성
  1 2 3
  
  # kubectl get ingress -n jenkins NAME CLASS HOSTS ADDRESS PORTS AGE jenkins-ingress nginx jenkins.local 172.27.1.100 80 26h
  - 파드가 MetalLB로부터 부여받은 IP가 172.27.1.100일 경우 하기와 같이 설정
    - 백엔드 헬스체크는 MetalLB에서 하고 있으니 HAproxy에선 설정하지 않음
  - http-request set-header Host
    - 클라이언트에서 오는 모든 HTTP 요청의 Host 헤더를 jenkins.local로 변경
  - http-request del-header X-Forwarded-Host
    - 이전 프록시에서 설정한 Host 헤더 제거
  - http-request del-header X-Forwarded-Proto
    - 이전 프록시에서 설정한 프로토콜 정보 제거
  1 2 3 4 5 6 7 8
  
  tee /etc/haproxy/haproxy.cfg > /dev/null <<EOF frontend jenkins_frontend bind *:8080 default_backend metallb_backend backend metallb_backend server metallb 172.27.1.100:80 EOF

통신 구조

jenkins 파드가 하기와 같이 구성되어 있다 가정할 때 통신 구조
- 현재 외부에서의 접근 시 80/443 포트를 사용하지 못하고 별도의 포트를 사용해야 하는 환경이기 때문에 8080포트를 사용

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


# kubectl get ingress -n jenkins
NAME CLASS HOSTS ADDRESS PORTS AGE
jenkins-ingress nginx jenkins.local 172.27.1.100 80 26h
# kubectl get all -n jenkins 
NAME READY STATUS RESTARTS AGE
pod/jenkins-0 2/2 Running 0 9d

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/jenkins ClusterIP 10.233.5.87 <none> 8080/TCP 9d
service/jenkins-agent ClusterIP 10.233.28.70 <none> 50000/TCP 9d

NAME READY AGE
statefulset.apps/jenkins 1/1 9d

브라우저에서 <도메인>:8080으로 접속
DNS 해석되어 공인IP:8080으로 라우팅
- 공인IP:8080는 HAproxy 서버
HAproxy frontend 설정으로 8080포트로 들어오는 요청을 HAproxy backend로 라우팅
- HAproxy backend는 172.27.1.100:80
172.27.1.100 IP는 MetalLB의 IP 풀에서부터 할당받은 Nginx Controller의 IP
- Nginx Ingress Controller는 LoadBalancer 타입 Service
Nginx Ingress Controller는 HAproxy backend로부터 받은 트래픽의 Host 헤더가 Jenkins Ingress에 정의된 Host인 jenkins.local인지 확인
Jenkins Ingress에 정의된 규칙에 따라 Jenkins Service로 라우팅
Jenkins Service에서 Jenkins Pod로 라우팅

자체 관리형 Kubernetes에서 NFS를 통한 StorageClass 사용

Thu, 31 Jul 2025 09:00:00 +0900

AWS의 경우 EBS Driver를 통해 pvc를 위한 StorageClass를 사용 가능
- 로컬 Kubernetes에서도 StorageClass를 사용하기 위해 NFS 서버를 구축해서 사용
NFS 서버 구축

1
2
3
4
5
6
7
8
9


dnf install -y nfs-utils

systemctl enable --now nfs-server

mkdir -p /exports/k8s-pv
chown -R nobody:nobody /exports/k8s-pv
chmod 777 /exports/k8s-pv
echo "/exports/k8s-pv *(rw,sync,no_subtree_check,no_root_squash)" | sudo tee -a /etc/exports
exportfs -rav

Helm을 통한 NFS Provisioner 설치

1
2
3
4


helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm repo update

helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner --set nfs.server=172.27.1.9 --set nfs.path=/exports/k8s-pv --set storageClass.name=nfs-sc --set storageClass.defaultClass=true

pvc 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pvc
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 1Gi
 storageClassName: nfs-sc

pod 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pvc
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 1Gi
 storageClassName: nfs-sc

Kubespray를 사용한 Kubernetes 클러스터 배포 (자체 관리형 Kubernetes)

Fri, 25 Jul 2025 09:00:00 +0900

https://github.com/kubernetes-sigs/kubespray

Kubespray를 사용해 설치
- kubespray 2.27 버전을 사용하여 Kubernetes 1.31버전 클러스터 구성
최소 4대가 필요
- 배포 서버 1EA
  - 도커로 Kubespray를 배포하고, Kubernetes CRI로 containerd를 사용할 거기 때문에 Master Node에서 배포 불가해서 별도의 배포 서버 필요
- Master Node 1EA
- Worker Node 2EA

사전작업

모든 Master, Worker Node에 작업

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


# vim 설정
cat << EOF >> ~/.bashrc
alias vi='/usr/bin/vim'
EOF

cat << EOF >> ~/.vimrc
syntax on
autocmd FileType yaml setlocal ai nu ts=2 sw=2 et
autocmd Filetype python setlocal ai nu ts=2 sw=2 et
EOF

. ~/.bashrc

# DNS 서버가 없으므로 /etc/hosts 파일 사용
cat << EOF >> /etc/hosts
172.27.1.9 master.k8s.com master
172.27.0.182 node1.k8s.com node1
172.27.1.35 node2.k8s.com node2
EOF

# cri 전부 제거
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo dnf remove $pkg -y; done