매일 쓰고 달립니다.

AWS 카펜터 v0.27 to v0.32 업그레이드 작업 내용을 공유합니다. 작업하면서 장애도 있었고 실수도 있어 아마도 다른 분들에게 도움이 될 것 같습니다. 업그레이 작업을 하게된 이유는 카펜터 Spot 노드 최적화가 v0.34부터 지원하기 때문입니다. 24년 10월 기준 카펜터 최신 버전은 v1.1.0 인데, 바로 최신 버전으로 업그레이드 하고 싶었는데, provisioner, awsnodetemplte 등 기존 자원에 대한 dual support가 필요하여 v0.32 으로 먼저 업그레이드 했습니다. 기존 현황입니다. (eks_dive-dev:karpenter)dev$ helm lsNAME NAMESPACE REVISION UPDATED ..

Why Kubernetes에서 파드를 동일한 노드에 배치하지 않기 위해 Anti-Affinity를 설정하는 경우가 많습니다. 하지만, 새로운 버전의 파드(예: 1.0.0 → 1.0.1) 배포 시 기존 노드에 실행하지 않고 새로운 노드에 배치되는 경우가 발생합니다. 이는 동일한 Deployment라 레이블이 같기 때문입니다. 기존 파드와 새로운 파드는 서로 다른 버전이라 같은 노드에 실행해도 문제없지만, 같은 레이블을 사용하기 때문에 서로 다른 노드에 배치됩니다. 이는 일반적인 상황에서는 문제가 없지만, Karpenter 환경에서는 새로운 노드가 생성되면서 기존 노드에 실행 중이던 파드들이 새로운 노드로 불필요하게 이동하는 문제가 발생합니다. (Karpenter의 consolidation 기능으로 인한 파..

쿠버네티스 공식 문서 기반으로 네트워킹 및 로드 밸런싱을 스터디하고 있습니다. 관련해서 현재 사용 현황을 정리해 보았습니다. Amazon EKS 네트워크 아키텍처를 고민하는 분들께 도움이 되었으면 합니다.EKS VPC CNIEKS 사용하면 당연히(?) VPC CNI를 사용합니다.장점파드와 노드의 IP 대역이 동일하여 다른 노드의 파드와 통신 시 NAT 등의 추가 과정없이 바로 통신 가능합니다.주의사항파드 네트워크 대역을 /24가 아닌 /20 등으로 넓게 할당합니다. EKS 업그레이드 등 작업 시 IP가 부족한 경우가 발생할 수 있습니다.당연히 Private Subnet 대역에 파드 배포합니다.EKS ALB와 LB Controller장점target-type: ip 옵션을 사용하여 네트워크 홉 수를 줄일 수..

현재 저는 CPU는 Limit을 지정하지 않는 Burstable 설정을 사용하고, CPU와 메모리 Request, Limit의 구체적인 설정값은 KRR을 사용하여 실제 사용량 기반으로 지정합니다. 이러한 구성은 시스템 안정성에 큰 영향을 미치지 않으면서 비용을 절감할 수 있는 효과적인 방법 같아서 공유합니다. QoS 설정과 Burstable 운영 환경의 안정성을 위해 많은 분들이 파드의 QoS 설정을 Guaranteed로 지정합니다. Guaranteed 설정은 Burstable 및 Best Effort 설정에 비해 노드의 자원이 부족할 때 파드가 Evict(추출) 당하지 않기 때문에 당연한 선택처럼 보입니다.  그러나 메모리와 달리 CPU는 Node Pressure가 없습니다. 즉, CPU를 과도하게 사..

기존 쿠버네티스 스터디에서 새로운 멤버가 추가되어 이번에는 쿠버네티스 공식 문서로 스터디를 하고 있습니다. 관련 내용 중 k8s 공식 문서에 Recommended 레이블이 있어 해당 내용을 기반으로 현재 사용하고 있는 현황을 공유합니다. 쿠버네티스 공식 문서 - Recommended 레이블https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/ Recommended LabelsYou can visualize and manage Kubernetes objects with more tools than kubectl and the dashboard. A common set of labels allows tools to wo..

이번 포스트에서는 최근에 발생한 CoreDNS 장애 관련 내용을 공유합니다. 당연한 것들인데 새롭게 배운 것들이 많습니다. Karpenter, CoreDNS 사용하는 분들에게 참고가 되었으면 합니다. 장애 현상일부 파드에서 DNS 조회 실패(dns resolve fail) 현상이 발생하였습니다.장애 원인Karpenter 설정에서 노드 그룹을 On-Demand와 Spot 두 가지로 운영하고 있었지만, interruptionQueue 설정이 누락되어 있었습니다. interruptionQueue 설정이 없으면 Spot 노드 종료 시 실행하고 있는 파드가 Graceful Shutdown하게 기존 세션을 종료하고 정상 종료되지 않아 해당 노드에 실행 중인 CoreDNS 파드 등에 문제가 발생합니다. 장애 조치1...

TL; DR; . IRSA(by 테라폼) + 헬름으로 External DNS 설치 경험을 공유합니다. . eksctl도 가능하지만 테라폼을 이용하여 IRSA를 설치하면 코드(IaC)로 남아서 좀 더 관리가 용이합니다. 1. External DNS IRSA 테라폼으로 EKS 관련 모듈(ebs-csi-controller, aws load balancer controller)을 IRSA + 헬름까지 설치할 수 있습니다. 하지만 테라폼으로 헬름까지 설치하는 것은 테라폼 State가 맞지 않는 경우 디버깅을 해야 하는 위험 + 번거로움이 있어 개인적으로는 테라폼은 IRSA까지만 설치하는 것을 선호합니다. AWS 관련 리소스(IAM, VPC 등)는 테라폼으로 쿠버네티스 애플리케이션은 헬름 + ArgoCD로 설치, ..

TL; DR; . grpc는 nlb + ingress-nginx-controller 설정으로 에러가 발생하여 alb + aws load balancer controller로 해결하였다. . ingress로 설정한 alb는 특이하게 path를 '/'가 아닌 '/*'로 지정해야 한다. 작업 내역 기존 REST 방식이 아닌 gprc는 nlb + ingress-nginx-controller로 설정하면 에러가 발생하였다. ### SERVER SIDE ingress-nginx-controller-6997b74f67-fgbb7 controller 10.0.197.170 - - [15/Jun/2023:05:11:33 +0000] "PRI * HTTP/2.0" 400 150 "-" "-" 0 0.003 [] [] - -..

최근에 미팅을 하고 가시다 스터디를 참가하다 보니 어렴풋이 가졌던 쿠버네티스를 가지고 회사를 만들어도 되지 않을까 하는 생각이 다시 든다. 쿠버네티스가 대세이고 사용하면 좋다는 것은 알겠는데 진입 장벽이 있어서 사용하기 어렵다고 말하는 사람들이 많다. 대기업, 스타트업, SI 업체 등. 어제 오늘 이야기도 아니고 한 3,4년 전부터 쭈욱. 그래서 OSC 코리아 이런데서 기존 SI랑 차별화해서 쿠버네티스에 특화된 SI, 컨설팅도 하고 OpenMSA 이런 것도 만드는 것 같고. (머 비슷한 사업 계획이 많이 있겠지.) 나도 비슷한 개념이다. 쿠버스택이라고(feat 오픈스택) 쿠버네티스를 실제 업무에 사용할 수준이 되도록 쿠버네티스 설치 + CI/CD + 모니터링/로깅/알람 + 네트워크(LB, Ingress)..

오늘은 회사에 새로운 (대단한) DevOps가 조인하고 생긴 여러가지 변화 중 하나를 소개한다. 나는 2003년 처음 시스템 엔지니어(솔라리스)로 업무를 할 때는 까만 콘솔에 명령어를 치면서 작업했다. 여러 Unix 명령어를 외우는게 중요했다. 사실 명령어도 쳤지만 네트워크 케이블 찝고 바닥 뜯고 8U(SUN 880, 무게가 무려 88Kg, 둘이서 마운트하면 허리 나간다.) 서버 마운트하고 랙 뒷면 케이블 이쁘게 정리하는게 주요한 업무였다. 당연히 코드를 짤일이 없었다. 시스템 운영자는 개발자와 업무가 달랐다. 난 경력 초반 3년 엔지니어 생활을 하고 이후 여러가지 이유로 제안서를 만들고 고객 미팅을 주로하는 시스템 아키텍트, 세일즈 엔지니어 등의 업무를 15년 넘게 하였다. 굳이 정리하자면 기존의 시스..