들어가며이 글에서는 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라는 새..

서론웹 애플리케이션을 만들다 보면 화면이 사용자와 상호작용하면서 계속 바뀌는 상황을 자주 마주하게 됩니다. 사용자가 버튼을 클릭하거나, 데이터를 입력하거나, 서버로부터 응답을 받을 때마다 애플리케이션은 그에 따라 다른 동작을 해야 합니다. 이런 변화들을 가능하게 해주는 핵심 개념이 상태(state)입니다.상태라는 개념을 처음 접할 때 추상적으로 느껴질 수 있고, 왜 상태를 관리 해야할까? 라는 고민이 들 수 있습니다. 이 글에서는 상태란 무엇인지, 왜 상태관리가 필요하며, 어떻게 다룰 수 있는지 정리해보았습니다.상태란?상태(state)란 애플리케이션이 특정 시점에 가지고 있는 데이터나 정보, 그리고 그에 따라 달라지는 화면(UI)의 모습을 말합니다. 쉽게 말하면, 애플리케이션이 지금 어떤 상황인지를 나타..

서론초기의 웹은 단순한 문서를 주고받는 정적인 플랫폼이었습니다. 하지만 채팅, 알림, 실시간 주식 시세, 온라인 게임과 같은 실시간 상호작용 기능이 필요해지면서 기존 HTTP 통신 방식으로는 실시간 상호작용에 한계가 있었고, 이를 보완하기 위한 다양한 통신 기술이 등장하게 되었습니다.이 글에서는 HTTP의 구조적 한계를 짚어보고, 그에 대한 대안으로 등장한 다양한 통신 기술들을 정리해보려 합니다. 각각의 기술이 어떻게 발전해 왔는지, 어떤 상황에 적합한지 확인해보겠습니다.실시간 통신이란?HTTP 웹 통신 구조웹에서 가장 기본이 되는 HTTP(HyperText Transfer Protocol)는 클라이언트가 요청을 보내고 서버가 응답을 반환하는 구조입니다. 이 요청-응답이 완료되면 연결은 종료되며, 기본적..

서론웹과 모바일을 포함해 다양한 디바이스 환경에서 서비스가 제공되면서, 각각의 플랫폼이 요구하는 데이터 구조나 응답 방식도 점점 달라졌습니다. 이제는 프론트엔드가 단순히 화면만 그리는 역할에서 벗어나, 어떤 데이터를 어떻게 가져오고 가공할지까지 함께 고민해야 할 때가 많아졌습니다.이 과정에서 자연스럽게 등장하게 된 개념이 바로 BFF입니다. 필요에 따라 프론트엔드에 최적화된 전용 백엔드 계층을 두어, 중복된 연산이나 불필요한 데이터 전달을 줄이고, 개발 효율성과 사용자 경험을 높일 수 있게 도와줍니다.이번 글에서는 BFF가 등장하게 된 배경과 개념, 실무에서 어떻게 활용되는지, 그리고 구현 시 어떤 점을 고려하면 좋은지 정리해보려고 합니다.BFF란?BFF(Backend for Frontend)는 프론트엔..