들어가며이 글에서는 폐쇄망(Air-Gap) 환경에서 Kubespray를 사용하여 Kubernetes 클러스터를 설치하는 방법을 실습하였습니다.일반적인 기업 환경에서는 보안을 이유로 내부망에서 외부 인터넷 접속이 차단된 경우가 많습니다. 이러한 폐쇄망 환경에서는 컨테이너 이미지, 패키지, 헬름 차트 등 필요한 모든 리소스를 사전에 준비하고 내부 저장소를 구축해야 합니다.실습 환경은 Vagrant를 사용하여 로컬에서 재현 가능하도록 구성했으며, Admin 서버 1대와 Kubernetes 노드 2대(Control Plane 1대, Worker 1대)로 이루어져 있습니다. 실제 환경에서는 DMZ의 Bastion 서버와 내부망의 Admin 서버가 분리되지만, 이번 실습에서는 리소스 효율을 위해 단일 Admin 서..

들어가며이번 글에서는 Kubespray 기반 Kubernetes 클러스터를 최소 중단(Minimal Downtime) 으로 업그레이드하는 전체 흐름을 실습하며 정리해보았습니다. 업그레이드는 단순히 kube_version만 올리는 작업이 아니라, Control Plane / Worker / Network(CNI) / Add-on / 런타임(containerd)까지 여러 구성 요소가 순차적으로 교체·재기동되면서 서비스 영향이 발생할 수 있었습니다.아래 세 가지 관점으로 전체 흐름을 먼저 잡아보는 방식으로 구성해보았습니다.업그레이드 순서: Control Plane → Network(CNI) → Worker → Add-on영향 포인트: apiserver 교체 시점, kube-proxy/DaemonSet 재기동,..

들어가며Kubespray를 활용한 Kubernetes 클러스터 배포 과정을 직접 진행하고, 그 구성 요소와 동작 방식을 분석한 내용을 정리한 포스팅입니다.이번 주차에서는 Kubespray가 어떤 목적과 구조를 가진 도구인지 먼저 정리한 뒤, 실습 환경에 실제로 배포를 수행해보며 배포 과정 전반을 확인했습니다. 이후에는 Kubespray가 내부적으로 어떤 작업을 자동화하는지 이해하기 위해 플레이북(Playbook) 과 롤(Role) 구성을 단계적으로 살펴보았고, 마지막으로 실습에 사용한 배포 환경을 기준으로 어떤 설정과 구성으로 클러스터가 만들어졌는지 분석하는 것을 목표로 했습니다.Kubespray 실습 전체 흐름 살펴보기Kubespray 기반 실습이 어떤 단계로 구성되어 있고, 각 단계가 무엇을 준비/생..

들어가며이 글에서는 kubeadm 기반 Kubernetes 업그레이드를 실습합니다.목표는 “명령어 나열”보다는, 버전 스큐(Version Skew) 규칙을 지키면서 컨트롤 플레인과 워커 노드를 순서대로 올리는 흐름을 손에 익히는 것입니다.실습 환경은 로컬에서 재현 가능한 Vagrant 기반(rockylinux + containerd)으로 구성했고, 초기 상태는 Kubernetes v1.32.11입니다. 이후 글에서는 kubeadm 방식으로 v1.33 → v1.34까지 단계적으로 업그레이드해보려 합니다.전체 흐름 살펴보기사전 준비(환경 안정화)Rocky Linux 10 vagrant 이미지에서 SWAP off 및 swap 파티션 삭제(재부팅 후에도 유지되도록)가상머신 외부 통신(ping 8.8.8.8) 실..

들어가며이번 포스팅에서는 kubeadm을 사용해 쿠버네티스(Kubernetes, K8S) 클러스터를 구성하는 과정을 정리해보겠습니다. 공통으로 필요한 사전 설정부터 시작해서 containerd 기반 런타임 구성, kubeadm/kubelet/kubectl 설치까지 먼저 준비합니다.이후 컨트롤 플레인(Control Plane) 노드에서 클러스터를 초기화하고 Flannel CNI(Container Network Interface) 를 적용한 뒤, 워커 노드를 join하여 클러스터 구성이 정상적으로 완료되었는지 확인할 예정입니다. 또한 운영 관점에서 기본적으로 필요한 모니터링을 위해 프로메테우스 스택(Prometheus Stack) 과 인증서 익스포터를 설치하고, 그라파나(Grafana) 대시보드로 상태를 확..

들어가며1주차에서는 kubeadm/kubespray 같은 자동화 도구를 사용하지 않고, Kubernetes The Hard Way 방식으로 구성 요소를 직접 설치 및 연결하면서 쿠버네티스가 어떻게 부팅되고 동작하는지 큰 흐름을 잡았습니다.이번 2주차에서는 그 흐름을 확장하여, 반복되는 운영 작업을 코드로 표준화하고 재현 가능하게 만드는 자동화 도구인 Ansible을 학습합니다.Ansible은 에이전트를 설치하지 않는(Agentless) 방식으로, 주로 SSH를 통해 원격 호스트에 접속하여 원하는 상태를 만들고 그 과정을 플레이북(Playbook) 으로 기록합니다.즉, 서버 한 대에 수동으로 명령어를 입력하는 방식이 아니라, “어떤 호스트들이 어떤 상태가 되어야 하는지”를 선언하고 실행하여 일관성을 확보하..

들어가며안녕하세요.On-Premise K8S 배포 Hands-on Study 1기에 참여하며 진행한 내용을 정리한 글입니다.이번 스터디에서는 Kubernetes를 더 깊이 이해하기 위해 kubeadm, kubespray 같은 자동화 도구를 사용하지 않고, 클러스터를 수동으로 설치하는 과정(Kubernetes The Hard Way)을 직접 실습했습니다.또한 동일한 클러스터를 kind(Kubernetes in Docker)로도 구성해 비교하면서, 쿠버네티스 설치가 어떤 순서로 이루어지는지, 내부 구성 요소들이 어떤 역할을 하는지 직접 확인했습니다. 이를 통해 자동화 도구가 내부적으로 어떤 작업을 대신 수행하는지도 이해하는 것을 목표로 했습니다.실습 환경은 아래 두 가지로 구성했습니다.kind 설치: Win..

서론프론트엔드 개발을 처음 접했을 때는 JavaScript만으로도 UI를 만들 수 있다는 사실이 흥미로웠습니다. 버튼 클릭이나 입력값에 따라 화면이 바뀌는 간단한 동작들은 Vanilla JS만으로도 충분히 구현할 수 있었고, 그 자체만으로도 재미있었습니다. 하지만 점점 기능이 늘어나고, UI 요소와 상태가 복잡해질수록 "이걸 매번 수동으로 관리해야 하나?" 하는 생각이 들기 시작했습니다. 코드가 늘어나면서 버그도 자주 발생했고, 유지보수는 갈수록 어려워졌습니다.이런 JavaScript의 한계를 극복하기 위한 시도로 다양한 프레임워크와 라이브러리들이 등장했습니다. Angular는 가장 먼저 등장해 MVC 구조 기반의 복잡한 앱 설계를 가능하게 했고, 이후 등장한 React는 상태 기반의 선언형 UI라는 새..