Plugins on Joonlog

자체 관리형 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에서의 분산 스토리지 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 접근을 위한 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 아키텍쳐

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

Nginx Ingress Controller

k8s 외부에서 들어오는 http/https 트래픽을 1차적으로 처리하는 Entry Point

Ingress Controller가 없다면 NodePort Service 만으로 Pod를 열어야한다.
Ingress 리소스를 통해 내부 서비스로 라우팅
TLS Termination, 리버스 프록시, 로드 밸린싱 등 수행 가능

https://docs.nginx.com/nginx-ingress-controller/installation/installing-nic/installation-with-helm/

helm을 통한 설치

1

helm install my-release oci://ghcr.io/nginx/charts/nginx-ingress --version 2.2.1

helm을 통한 설치 시 옵션 수정이 필요한 경우
- 하기 명령어로 pull한 helm chart의 values.yaml에서 옵션 수정

1

helm pull oci://ghcr.io/nginx/charts/nginx-ingress --untar --version 2.2.1

수정한 옵션 적용하여 설치

1

helm install my-release .

Kubernetes Helm 설치

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

Kubernetes에서 사용하는 여러 플러그인 및 툴의 yaml 파일들을 패키징하여 쉽게 설치할 수 있는 툴
- values.yaml을 통해 툴들의 옵션 조정 가능

1
2
3
4


cd
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh --version v3.17.4

3.18.5 버전에서 helm 설치 시에 values.schema.json이 원격 $ref(HTTPS)로 참조하는 JSON Schema를 불러오면 검증 단계에서 실패하는 이슈가 있어서 3.17.4 버전 명시

https://github.com/helm/helm/issues/31136?utm_source=chatgpt.com

1
2
3
4
5
6


[root@master1 ~]# helm install my-release oci://ghcr.io/nginx/charts/nginx-ingress --version 2.2.1
Pulled: ghcr.io/nginx/charts/nginx-ingress:2.2.1
Digest: sha256:00f7a7017799eafc7f109cca10204a9dc2bc2d2f0feafb8eff328d13e2cedd12
Error: INSTALLATION FAILED: values don't meet the specifications of the schema(s) in the following chart(s):
nginx-ingress:
failing loading "https://raw.githubusercontent.com/nginxinc/kubernetes-json-schema/master/v1.33.1/_definitions.json": invalid file url: https://raw.githubusercontent.com/nginxinc/kubernetes-json-schema/master/v1.33.1/_definitions.json

자체 관리형 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