day-log

어제 팀원이 distroless 이미지로 뜬 파드에 붙어서 tcpdump를 뜨려다가 삽질했다. kubectl exec 안 되는 건 알아서 kubectl debug까지는 갔는데, 그 다음에 막혔다. 컨테이너는 붙었는데 /proc/1 못 읽고, 네트워크 인터페이스도 안 보이고. "이거 왜 이러지?" 하길래 옆에서 --profile=sysadmin 하나 붙여줬더니 바로 됐다.이 옵션 모르는 사람이 생각보다 많아서 짧게 정리한다.profile이 뭐냐kubectl debug는 기본적으로 ephemeral container를 파드에 끼워넣는다. 근데 이 컨테이너의 securityContext를 어떻게 세팅할지가 문제다. 그냥 붙이면 non-root에 capability 다 벗겨진 상태로 뜬다. nsenter, tc..

지난주에 롤링 업데이트 도중 5분 동안 502가 쭉쭉 떨어졌다. 트래픽 피크 시간대였고, 알림 채널이 몇 초 간격으로 울렸다. 새벽도 아닌 오후 3시였는데, 오히려 그게 더 뼈아팠다. 다들 사무실에 있었으니까.우리 팀은 EKS 위에 AWS Load Balancer Controller로 ALB를 붙여서 쓴다. 노드 24대, 파드 수는 서비스마다 다르지만 문제가 된 서비스는 파드 12개짜리였다. 배포 스크립트도 평범한 Deployment 롤링 업데이트, maxSurge: 25%, maxUnavailable: 0. 이론적으로는 무중단이어야 하는데, 현실은 그렇지 않았다.처음 의심한 건 헬스체크였다로그를 열어보니 502가 뜬 요청들은 전부 upstream connect error 계열이었다. ALB는 살아있다고..

오늘 팀원한테 Helm values override 얘기를 하다가 알게 됐다. --set-json 플래그 쓰는 사람이 생각보다 적더라. 대부분 --set으로 어떻게든 우겨넣거나 임시 values 파일 만들어서 -f로 넘긴다.근데 CI 파이프라인에서 잠깐 하나만 override할 때는 이게 좀 애매하다. values 파일 만들자니 번거롭고, --set으로 배열/객체 넣자니 콤마 이스케이프 지옥이 시작된다. 이럴 때 --set-json이 답이다.--set의 콤마 지옥sidecar 하나 붙이려고 --set으로 배열 넣어본 적 있으면 안다. 이런 걸 만나게 된다.# 실패 확률 높은 코드helm install redis ./chart \ --set master.sidecars[0].name=logger \ -..

요즘 새 클러스터 세팅할 때마다 CNI를 Cilium으로 깔고, 그 다음날부터 "Hubble UI 켜주세요" 요청이 들어온다. Pixie도 붙여봤고, 최근에는 Grafana Beyla까지 검토 목록에 올렸다. 세 도구 다 "사이드카 없이 관측성 확보"라는 같은 문구를 쓰는데, 사실 내부적으로는 노드에서 하는 일이 꽤 다르다. 이번 주에 팀 세미나 준비하면서 각 도구가 어디에 eBPF 프로그램을 붙이는지, 데이터는 어떻게 흘러 나가는지 다시 정리했다.이 글은 그 정리 노트다. 사용법 튜토리얼은 아니고, "왜 이 도구는 HTTP 헤더까지 보이는데 저 도구는 IP:포트만 보이지?" 같은 궁금증에 답이 되도록 쓴다.eBPF 훅 포인트가 결정하는 관측 범위관측성 도구가 뭘 볼 수 있는지는 결국 커널의 어느 지점에..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. topologySpreadConstraints에서 whenUnsatisfiable: ScheduleAnyway로 설정해두고 "AZ 골고루 퍼지겠지" 안심하다가 뒤통수 맞기 딱 좋다.우리 팀에서도 이번 주에 비슷한 일이 있었다. 3-AZ EKS에 6개 replica를 배포하는데 특정 AZ에 4개가 몰려서 나머지 두 AZ는 각각 1개씩. 스펙에 maxSkew: 1, whenUnsatisfiable: ScheduleAnyway가 분명히 박혀 있는데도 그랬다.왜 이런 일이 생기나ScheduleAnyway는 이름 그대로 소프트 제약이다. 스케줄러가 최선을 다해서 스프레드를 지키려 하지만, 다른 스코어링(리소스 여유, 이미지 로컬리티, 노드 셀렉터 우선순위 등)이 ..

지난주 화요일 밤, 스테이징에서 새 서비스를 릴리즈하는 중이었다. ArgoCD 앱 하나 만들고, sync 눌렀고, 커피 한 잔 뜨러 갔다 왔다. 돌아왔더니 sync 상태가 Progressing에서 멈춰 있었다. 40분째. 그때부터 새벽 두 시까지 이걸 풀었다.뭐가 문제였나우리 팀은 요즘 ArgoCD 앱에 argocd.argoproj.io/sync-wave annotation을 적극적으로 쓴다. 이유는 단순하다. Helm chart 하나에 CRD, Namespace, ConfigMap, Deployment, Service, Ingress가 다 들어 있으면 순서가 꼬인다. CRD가 만들어지기 전에 Custom Resource가 apply되면 sync가 실패한다. 그래서 CRD는 wave 0, Namespac..

3월 24일에 ingress-nginx가 공식적으로 EOL 됐다. 이제는 CVE 패치도 안 나온다. 우리 팀도 절반이 아직 ingress-nginx를 쓰고 있어서 지난 두 달 동안 대체제 검토를 이어왔다. Envoy Gateway, Cilium Gateway, Traefik, kgateway. 이 네 개를 실제로 클러스터에 붙여봤고, 그 중 하나로 결정을 내렸다. 결정 자체보다는 각각 뭐가 다른지, 어디서 삽질했는지를 정리해보려 한다.전제 조건부터 짚자. 우리는 EKS 위에서 돌아가고, 노드는 대략 90대. 트래픽은 RPS 8k 정도이고 대부분 gRPC와 HTTP/2. 사내 서비스 60여개가 하나의 Ingress 컨트롤러 뒤에 붙어있는 형태다. 만약 여러분 환경이 GKE 매니지드 게이트웨이를 그냥 켜면 ..

지난 주말 새벽 3시, 알림이 울려서 눈을 떴다. 사내 스테이징 API 게이트웨이가 TLS handshake failure를 뱉고 있었다. 그때만 해도 "그냥 인증서 문제겠지, 아침에 보자" 하고 다시 누웠는데, 아침이 되니 프로덕션까지 같은 증상이 번지고 있었다.결론부터 말하면 cert-manager는 인증서를 잘 발급하고 있었다. Kubernetes Secret도 잘 갱신됐다. 그런데 워크로드가 새 인증서를 안 읽고 있었다. 이 삽질 이야기를 정리해둔다.처음엔 cert-manager를 의심했다먼저 한 게 이거다.kubectl describe certificate api-gateway-tls -n gatewaykubectl get certificaterequest -n gateway --sort-by=..

올해 2월에 Kyverno 1.17이 나오면서 재밌는 변화가 하나 있었다. ClusterPolicy와 CleanupPolicy가 공식적으로 Deprecated로 마킹된 것. 아직 지워지진 않았지만, Kyverno 팀이 CEL(Common Expression Language) 중심 아키텍처로 방향을 확 틀었다는 신호다. 우리 팀은 지난달부터 조금씩 이 전환을 시작했는데, 처음 시작하는 팀들을 위해 몇 가지 정리해두려고 한다.왜 갑자기 CEL인가간단히 말하면, Kubernetes 자체가 1.30부터 ValidatingAdmissionPolicy(VAP)를 GA로 넣으면서 admission control 계층에 CEL 기반 표현식을 표준으로 밀기 시작했다. Kyverno가 오랫동안 자체 DSL로 정책을 표현해..