kkumtree

• kkumtree

2026-06-20T17:57:45+09:00

지난 주 일요일부터 CloudNet@에서 진행하고 있는 (이하, AIDC)에 참여하게 되었습니다.

요새는 PC에 달린 그래픽카드 활용을 위해, 이것저것(RAG, ASR 및 일반적인 추론모델) 돌려보는 중인데 그 중에서 막히던게 KV cache에 대한 이해 부족으로 Hermes Agent용 모델 선정에 애를 먹고 있었습니다. 그래서 이왕 하는 김에 큰 욕심을 버리고 KV cache에 대한 이해를 해보고자 합니다.

영상은 스터디에서 참고용으로 추천해주신 수 많은 영상들 중에서 [KV cache 시각화로 설명] 영상을 참고 하였습니다.

1. KV cache 란?

이해하고 있는 내용으로는 역시 말 그대로 Key-Value 형태의 캐싱입니다.

• kkumtree

2025-12-07T05:59:10+09:00

CloudNet@에서 진행하고 있는 CI/CD Study 8주차에는 Vault의 HA(High Availability)에 대해 다루었습니다.

구성 방법의 이론적 부분은 단순했으나, 예상한 구성 방법과 달라서 제가 나중에 참고하려고 부연설명을 해두려고 합니다.

더불어 대시보드에서 Vault 관련 메트릭을 보고 싶어서, Datadog과 연동하여 관측하였습니다.

0. 실습 환경 준비

해당 구성들은 아래 GitHub에 탑재되어 있습니다.
https://github.com/kkumtree/ci-cd-cloudnet-study 의 8w 폴더 Helm v4 출시 후 한 달도 안된 시점에 작성되었기에, v3에 호환되는 차트 버전을 명시하여 배포했습니다.

kind 배포와 ingress-nginx, 그리고 vault-worker 까지 배포하면, 아래와 같은 구성도가 됩니다.

• kkumtree

2025-11-30T08:59:34+09:00

CloudNet@에서 진행하고 있는 CI/CD Study 7주차에는 Vault를 다루었습니다.

자세한 설명은 해당 공식 페이지에서 해주고 있지만, 그저 1password 같은 패스워드 관리 서비스가 엔드유저 대상이라면 Vault는 인프라 관리자 대상으로 사용되는 것으로 알고 있는 제게는 흥미로운 주차였습니다.

이번 스터디에서는 계속해서 kind로 로컬 Kubernetes(k8s)를 활용했기에, 이번에도 비슷하게 배포해보겠습니다.

0. 실습 환경 준비 - kind 클러스터 배포

해당 구성들은 아래 GitHub에 탑재되어 있습니다.
https://github.com/kkumtree/ci-cd-cloudnet-study 의 7w 폴더

kind create cluster --name vault --image kindest/node:v1.32.8 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
  labels:
    ingress-ready: true
  extraPortMappings:
  - containerPort: 80
    hostPort: 30080
EOF


echo "[Provisoning..] ingress-nginx in vault cluster"

kubectl config use-context kind-vault

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=90s

sudo tailscale serve -bg localhost:30080

kubectl apply -f whoami.yaml 

이번에는 UI 관련해서 80포트 하나만 뚫어놓고 사용하고 싶었는데, 뭔가 하나씩 막히는 중입니다. 그래서 traefik/whoami 이미지를 활용하여 디버깅을 하기로 했습니다.

• kkumtree

2025-11-22T20:56:43+09:00

CloudNet@에서 진행하고 있는 CI/CD Study 6주차에는 ArgoCD를 마지막으로 다루었습니다.
Cluster를 추가해보고 Gitea를 붙이기 전에, ArgoCD를 Prefix로 라우팅하려고 했는데 로그아웃하고 나서 원치않는 경로로 빠지는 바람에
이것저것 살펴보고 수정을 하여 원하는 대로 구동되도록 셋업했습니다.

0. 실습 준비

해당 구성들은 아래 GitHub에 탑재되어 있습니다.
https://github.com/kkumtree/ci-cd-cloudnet-study 의 6w 폴더

이전 포스팅 Tailscale을 타고, ArgoCD에 접근해보기을 하였다면, 리소스 정리를 합니다.

kind 배포 시, 포트 점유로 오류가 발생합니다.

sudo tailscale serve --tcp 443 off

• kkumtree

2025-11-17T10:23:03+09:00

이전 게시물, ArgoCD with Ingress의 도메인 설정을 하다가 문득, Tailscale의 serve기능을 활용하여 Tailscale 내부 네트워크(이하, tailnet)에서만 접근 가능한 ArgoCD 서버를 구축하면 되지 않을까? 하여 구성해보았습니다.

kind를 운용 중인 Host와 접속할 Client들에 Tailscale 설치되어 있어야합니다.

1. Tailscale과 Serve

전통적인 중앙집중식(Hub-Spoke) VPN이 아래와 같다면,

Tailscale의 경우, Mesh 네트워크의 형태를 가지며 Wireguard를 활용합니다.

Tailscale의 serve와 같은 경우는, ngrok의 기본 기능과 유사한 funnel과 달리
tailnet에 속한 기기만 접근이 가능합니다.

• kkumtree

2025-11-16T17:38:34+09:00

CloudNet@에서 진행하고 있는 CI/CD Study 5주차에는 ArgoCD를 좀더 다루었습니다.

0. 실습 준비

해당 구성들은 아래 GitHub에 탑재되어 있습니다. https://github.com/kkumtree/ci-cd-cloudnet-study 의 5w 폴더

우선 80/443 포트를 사용할 수 있는지 확인하여야합니다. 아닌 경우, 다른 포트를 사용해야합니다.

실제로 해보았을 경우 tailscale이 포트를 사용하는 것으로 오인하여 해당 서비스를 중지해보았습니다.
다만, 단순히 kind YAML을 잘못 작성한 것으로 보입니다.

(1) kind 및 kube-ops-view

이번에는 Ingress의 배포를 하기 위한 밑작업으로
Control Node에 라벨링을 진행합니다.
이는 다음에 이어질 ingress-nginx 배포 시, nodeSeletor 조건으로 사용합니다.

• kkumtree

2025-11-09T08:44:34+09:00

CloudNet@에서 진행하고 있는 CI/CD Study 4주차에는 ArgoCD를 다루기 시작했습니다.

Kubernetes(이하, k8s) 상에서 ArgoCD는 Controller보다는 Operator에 가까운 포지션을 갖는다고 하여,
이번 기회에 실습을 하면서 체감을 하는 것에 목적을 두었습니다.

• Controller: live state(실제 상태)와 desired state(원하는 상태)가 일치하는지 관찰 및 지속적 조정
• Operator: Controller가 k8s 내부 object에서 동작한다면, Operator는 k8s 외의 것들도 다룰 수 있음

해당 구성들은 아래 GitHub에 탑재되어 있습니다.
https://github.com/kkumtree/ci-cd-cloudnet-study 의 4w 폴더

0. 실습 준비

이전 게시물, Jenkins, git and kubernetes의 kind 및 kube-ops-view 설정과 동일하여 생략합니다.

• kkumtree

2025-11-02T08:51:39+09:00

CloudNet@에서 진행하고 있는 CI/CD Study 3주차에는 Jenkins와 ArgoCD을 다뤘습니다.

이번에는 kubernetes(이하, k8s)에 self-host Git과 Jenkins를 배포 후 CI/CD 부분을 다루도록 하겠습니다.

하다보니 개인적으로, 아래 3가지가 주로 기억에 남았던 것 같습니다.

• Docker UDS의 GID
• Gitea와 Multibranch Pipeline의 결합
• Local PV의 Taint 및 Node 지정

더불어, Gitea에 대해 Basic Auth를 통한 CLI 접근을 막아보는 것도 새로이 해보았습니다.

해당 구성들은 아래 GitHub에 탑재되어 있습니다.
https://github.com/kkumtree/ci-cd-cloudnet-study 의 3w 폴더

0. 실습 준비

(1) kind

kind 설치의 경우 다음 포스트를 참고할 수 있습니다.
리눅스에 KIND 설치하기 w/golang
Docs: https://kind.sigs.k8s.io/

• kkumtree

2025-10-26T03:16:04+09:00

이번에는 재사용성을 위해서 _helpers.tpl 파일을 활용해보겠습니다.

기존의 Helm 101 - CI/CD 스터디 2주차에서 이어집니다.

1. _helpers.tpl을 통한 공통 변수 재사용

(1) 공통사항 숙지

이전에 생성한 deployment.yaml과 service.yaml의 selector 부분에 공통점이 있습니다.

# `{{ .Values.replicaCount }}
## deployment.yaml  
spec.selector.matchLabels
spec.template.metadata.labels
## service.yaml  
spec.selector

(2) 템플릿 생성

해당 label을 추가/삭제하려면, 여러 필드를 업데이트를 하여야합니다.
대신 _helpers.tpl파일을 생성하여 구성읋 합니다.

_helpers.tpl 뿐만 아니라, 맨 앞에 _로 시작하기만 하면 되며,
이 파일은 k8s manifest 파일로 취급되지 않습니다.

• kkumtree

2025-10-24T01:17:39+09:00

CloudNet@에서 진행하고 있는 CI/CD Study 2주차에는 Helm과 Tekton을 다뤘습니다.

이번에는 Helm의 기본적인 부분을 다루도록 하겠습니다.

1. Helm의 역할과 실습 준비사항

Helm?

템플릿 기반 솔루션. 즉, 버전 관리 및 공유, 배포가 가능한 아티팩트를 생성하도록 돕습니다.

• Helm chart(차트)

  • 공유 가능한 Kubernetes(쿠버네티스, 이하 k8s) 패키지며, 차트 간 의존성 등 다양한 요소를 포함합니다.
  • k8s를 다루면 Helm을 많이 사용하게 되는데, 그 이유 중 하나가 chart 개념입니다.

• Rolling Update for ConfigMap

  • 애플리케이션의 설정값은 일반적으로 k8s의 ConfigMap에 대응되는 속성입니다.
  • ConfigMap: 수정되어도 애플리케이션의 롤링 업데이트 전, 즉 애플리케이션을 수동 재시작 하기 전까지는 값이 적용되지 않습니다.
    • Helm은 ConfigMap이 변경되면, 자동으로 Rolling Update가 이루어지는 기능들을 제공합니다.

실습 준비

1. kind