노드를 비우는 kubectl drain이 PodDisruptionBudget(PDB) 때문에 멈추는 과정과, drain이 옵션 없이는 거부하는 파드 세 가지(DaemonSet, emptyDir, 컨트롤러 없는 파드)를 3노드 k3s에서 직접 확인했습니다.환경: k3s v1.35.9(server 1대 + agent 2대, Docker 컨테이너), 커널 6.12.54-linuxkit, 이미지 busybox:1.36.1. drain이 하는 일커널 패치처럼 노드를 재부팅해야 할 때는 노드를 한 대씩 비운 뒤 작업합니다(Linux 커널 TCP use-after-free(CVE-2026-98432)가 쿠버네티스 노드에 주는 영향). 이때 쓰는 kubectl drain은 두 단계로 동작합니다. 먼저 cordon으로 ..
Linux 커널 IPv4 TCP 처리 코드의 use-after-free 취약점 CVE-2026-98432가 쿠버네티스·OpenShift 노드에 어떤 의미인지 정리하고, Red Hat이 제시한 임시 nftables 규칙이 어떤 경로를 막는지 직접 실험했습니다.환경: Docker Desktop 29.1.3(커널 6.12.54-linuxkit), k3s v1.35.9, nftables v1.1.3(alpine 3.22). 취약점 정보는 2026-11-11에 확인한 Red Hat·GKE 공지를 기준으로 합니다.1. 어떤 취약점인가CVE-2026-98432는 IPv4 TCP 연결을 맺는 과정에서 커널이 이미 해제한 메모리를 다시 읽을 수 있는 결함입니다. 이렇게 해제된 메모리를 계속 쓰는 버그를 use-after..
ConfigMap을 수정해도 이미 실행 중인 파드가 새 값을 보는지는 그 값을 어떻게 가져왔느냐에 따라 달라집니다. 같은 ConfigMap을 환경변수, 볼륨 마운트, subPath 마운트로 동시에 소비하는 파드를 로컬 k3s에 띄우고, 값을 바꿨을 때 각각 언제 바뀌는지 시간을 재어 확인했습니다. 파드를 재시작해야 하는 경우, immutable ConfigMap, Kustomize configMapGenerator가 이 문제를 푸는 방식도 함께 다룹니다.환경은 k3s v1.35.9(Kubernetes v1.35.9), kubectl v1.34.1, Docker 29.1.3(Docker Desktop), busybox 1.36입니다.먼저 결과를 한 장으로 봅니다. ConfigMap의 LOG_LEVEL을 i..
쿠버네티스의 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가 어떻게 달라졌는지를 업그레이드 전과 후로 나눈..
