개발 기록

쿠버네티스로 서비스를 운영하다 보면 처음엔 단순해 보이던 개념이 실제 트러블슈팅 상황에서 예상치 못한 문제로 이어지는 경험을 하게 된다. 이 글에서는 기본적인 ConfigMap 개념을 정리하고, 실제로 겪었던 "Helm + ArgoCD 환경에서 ConfigMap 데이터가 사라지는" 문제를 겪으면서 짐작해본 원인과 해결 방법도 같이 적어본다.1. ConfigMap: 설정을 이미지와 분리하기ConfigMap은 설정값을 컨테이너 이미지와 분리해서 관리할 수 있게 해주는 오브젝트다. 환경별로 달라지는 값(DB 주소, 로그 레벨, feature flag 등)을 이미지에 하드코딩하지 않고 외부에서 주입할 수 있다.apiVersion: v1kind: ConfigMapmetadata: name: app-configd..

상황리눅스 강의 실습 환경이 VMware + Windows 기준이었는데, M4 MacBook Pro라 그대로 따라할 수 없었다.핵심 정리VMware 대신 UTM 사용VMware Workstation Pro는 Windows/Linux 전용 → Mac 설치 불가VMware Fusion은 Mac용이지만 ISO 로딩에서 계속 멈춤 현상 발생UTM(무료)으로 대체 → Rocky Linux ARM64에서 정상 동작Rocky Linux ISO 선택M4는 ARM 아키텍처 → aarch64 버전 필수 (x86_64 설치 불가)Default Image(약 2.3GB) 다운로드가상머신 4대 구성이름 OS RAM 저장소ServerRocky Linux 9.78GB100GBServer(B)Rocky Linux 9.7512MB10..

전체 구조쿠버네티스 오브젝트는 크게 두 레벨로 나뉜다.Cluster Level — 클러스터 전체에서 유일한 오브젝트 (예: Namespace, PV)Namespace Level — Namespace 안에 소속된 오브젝트 (예: Deployment, Service, Pod 등)Namespace를 삭제하면 안에 소속된 오브젝트들도 함께 삭제되므로 주의가 필요하다.주요 오브젝트 역할 정리Namespace오브젝트들을 논리적으로 묶는 그룹 역할같은 이름의 오브젝트라도 다른 Namespace면 중복 허용됨네이밍 기준: "Namespace에 담을 앱의 범위"를 고려해서 짓는다DeploymentPod 배포 및 업그레이드를 담당하는 핵심 오브젝트내부적으로 ReplicaSet을 생성하고, ReplicaSet이 Pod를 생..

인프런 [쿠버네티스 어나더 클래스] 강의를 보고 정리한 글1. 컨테이너란?호스트 OS에 격리된 공간을 만들고, 그 안에서 독립된 프로세스를 실행하는 기술컨테이너가 격리하는 것들:파일 → chroot자원(CPU, Memory) → cgroup프로세스 / 유저 / 네트워크 → namespace이 세 가지 Linux 커널 기능이 컨테이너의 핵심이다. Docker 이전에도 LXC(LinuX Container)가 이 기술을 사용했고, Docker는 LXC를 기반으로 만들어졌다.2. Linux OS 계보UNIX (최초) └── Linux (무료, 1991) ├── Debian → Ubuntu (편의기능 추가) └── Red Hat (유료) ├── Fedora (개발버전, 무료) ..

하려던 것화분 클릭 → 화분이 옆으로 이동화분 아래 숨겨진 열쇠 오브젝트 활성화PlantInteractable 스크립트로 구현문제 | 화분을 눌러도 아무 반응이 없음원인 1 - Collider가 너무 작았다화분 오브젝트의 Scale이 X: 0.17, Y: 0.19로 엄청 작았는데, BoxCollider2D의 Size는 1x1이었다. Scale이 워낙 작으니까 실제 Collider 크기도 0.17 x 0.19 밖에 안 됐고, 클릭이 Collider 바깥으로 인식되고 있었다.해결: BoxCollider2D Size를 6x6 정도로 키워서 화분을 충분히 덮게 했다.실제 Collider 크기 = BoxCollider2D Size × Transform ScaleScale을 정규화하거나 Collider Size를 ..

## 프로그램의 동작을 스레드 스케줄러에 기대지 말라 ### 운영체제마다 스레드 스케줄러 정책이 다를 수 있다.- 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. ### 견고하고 이식성 좋은 프로그램 작성실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것실행 가능한 스레드가 CPU 코어 수를 크게 초과하면?스케줄러가 계속 스레드를 교체(컨텍스트 스위칭) 해야 함 (비용 큼)결과: 성능 저하, 응답 지연실행 준비가 된 스레드들은 맡은 작업을 완료할때까지 계속 실행되도록 만들자.괜히 양보(yield)하거나 인위적으로 멈추지 말고, 맡은 일을 끝낼 때까지 실행되도록 설계스레드는 당장 처리해야 할 작업이 없다면 실행돼서는 안 된다..

## 지연 초기화는 신중히 사용하라 ### 지연 초기화 : 필드의 초기화 시점을 그 값이 처음 필요할 때까지 늦추는 기법- 값이 전혀 쓰이지 않으면 초기화도 일어나지 않는다.- 정적 필드, 인스턴스 필드 모두 사용 가능.- 주로 최적화 용도로 쓰이지만, 클래스와 인스턴스 초기화 때 발생하는 위험한 순환 문제를 해결하는 효과도 있다. ### 지연 초기화는 필요할때까지는 하지 말라- 클래스, 인스턴스 생성 시의 초기화 비용은 줄지만 그 대신 지연 초기화하는 필드에 접근하는 비용은 커진다.- 결국 초기화 비율, 비용, 호출 빈도에 따라 실제로는 성능을 느려지게 할 수도 있다. ### 지연 초기화 방식1. 인스턴스 필드의 지연 초기화 - synchronized 접근자 방식private FieldType fiel..

## 스레드 안정성 수준을 문서화하라 한 메서드를 여러 스레드가 동시에 호출할 때 그 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다. API문서 에서 아무런 언급도 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다. 만약 그 가정 이 틀리면 오류로 이어질 수 있다. ### API 문서에 synchronized 한정자synchronized 한정자가 달려있는 메서드는 스레드 안전하다고 생각할 수 있다. 하지만 이는 몇 가지면에서 틀렸다.메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈일 뿐 API에 속하지 않는다.따라서 이것만으로는 해당 메서드가 스레드 안전하다고 믿기 어렵다.멀티스레드 환경에서도 API를 안전하게 사용하려면 클래스가 지원..