쿠버네티스의 readiness·liveness·startup 프로브는 이름은 비슷해도 실패했을 때 바꾸는 것이 전혀 다릅니다. 로컬 k3s에서 같은 앱의 health 파일을 일부러 바꾸거나 앱을 느리게 띄워서, 프로브마다 트래픽, 재시작, 롤링 업데이트가 어떻게 달라지는지 실제로 확인했습니다. liveness 실패 뒤 재시작이 30초 늦어지는 경우와 startupProbe가 필요한 경우도 다룹니다.환경은 k3s v1.35.9(Kubernetes v1.35.9), kubectl v1.34.1, Docker 29.1.3(Docker Desktop), busybox 1.36.1입니다.먼저 한 장으로 봅니다. 컨테이너가 시작된 뒤 세 프로브가 언제 실행되고, 각각 실패하면 무엇이 바뀌는지를 정리한 그림입니다. ..
OpenShift 템플릿(Template)은 오브젝트 여러 개를 한 장의 YAML로 묶고, 일부 값을 파라미터로 열어 두는 리소스입니다. 예제 템플릿을 직접 만들어 OpenShift 클러스터에서 oc process로 파라미터를 채우고, 클러스터에 만들고, 템플릿을 저장해 oc new-app으로 쓰는 과정을 실제로 실행해 확인하고, 웹 콘솔에서 같은 템플릿을 인스턴스화하는 화면과, Git 소스를 S2I로 빌드해 이미지 트리거까지 이어지는 실전형 템플릿도 함께 봅니다. 파라미터를 ${}로 쓸지 ${{}}로 쓸지에 따라 서버가 오류를 내는 경우와, 자동 생성 값이 다시 적용할 때마다 바뀌는 점도 다룹니다.환경은 OpenShift 4.20.8(Kubernetes v1.33.6), oc 4.20.8입니다.먼저 한..
RKE2 업그레이드로 ingress-nginx가 1.12.2에서 1.14.5로 올라간 뒤, 접속 IP가 실제 클라이언트가 아니라 HAProxy IP(HTTP)와 127.0.0.1(HTTPS)로 기록되어 whitelist-source-range가 403을 냈습니다. 원인을 소스에서 찾고 로컬 k3s에서 재현해 해결 방법까지 확인한 기록입니다.환경은 ingress-nginx 1.12.2에서 1.14.5로 업그레이드한 RKE2이고, 재현은 Docker 29.1.3(Docker Desktop), k3s v1.35.9, Helm v4.1.4에서 했습니다.먼저 한 장으로 봅니다. 같은 설정과 같은 HAProxy에서 ingress-nginx 버전만 올렸을 때 접속 IP가 어떻게 달라졌는지를 업그레이드 전과 후로 나눈..
컨테이너를 지우면 컨테이너 안에서 쓴 파일도 함께 사라집니다. 이름 있는 볼륨(named volume), 바인드 마운트(bind mount), tmpfs가 각각 데이터를 어디에 저장하고 컨테이너를 지운 뒤 무엇이 남는지 실제로 실행해 확인합니다. 마운트가 이미지 안의 파일을 가리는 경우, 이미지를 바꿔도 볼륨 내용이 그대로인 경우, 익명 볼륨이 쌓이는 경우, non-root 컨테이너의 쓰기 권한(UID) 문제, 백업과 정리 방법도 다룹니다.환경은 Docker 29.1.3(Docker Desktop, linux/arm64), alpine 3.22, nginx 1.29-alpine입니다.먼저 한 장으로 봅니다. 컨테이너 안의 경로 세 곳을 각각 named volume, bind mount, tmpfs에 연결..
Docker 컨테이너는 기본 설정에서 root로 실행되고 14개의 리눅스 권한(capability)을 가집니다. --user, --cap-drop, --read-only, --security-opt no-new-privileges, seccomp, --privileged가 각각 무엇을 막거나 여는지 같은 명령을 옵션 유무로 나눠 실행해 확인하고, 모두 합친 docker run 한 줄과 쿠버네티스 securityContext와의 대응까지 정리합니다.환경은 Docker 29.1.3(Docker Desktop, linux/arm64), busybox 1.36, python 3.12-slim입니다.먼저 한 장으로 봅니다. 같은 명령을 옵션이 없을 때(왼쪽, 열린 쪽)와 옵션이 있을 때(오른쪽, 막힌 쪽)로 나눠..
쉘이 없는 distroless 이미지의 파드는 kubectl exec로 들어갈 수 없고, 죽어 있는 파드는 더더욱 들여다보기 어렵습니다. kubectl debug가 기존 파드에 임시 컨테이너(ephemeral container)를 붙이는 방법과 --target의 효과, CrashLoopBackOff 파드에서 --copy-to로 복제해야 하는 이유, 디버그 프로파일과 노드 디버깅, 필요한 RBAC 권한을 로컬 k3s 클러스터에서 직접 실행해 정리합니다.환경은 로컬 k3s(Kubernetes v1.35.9)와 kubectl v1.34.1입니다.먼저 전체 그림입니다. 쉘이 없는 app 컨테이너에는 kubectl exec가 실패하지만, kubectl debug는 같은 파드에 도구가 든 임시 컨테이너를 붙이고, ..
