전체 글 썸네일형 리스트형 쿠버네티스 Istio protocol error: unsupported transfer encoding(Feign Client chunked) 자바/스프링 기반 애플리케이션 파드로 구성된 쿠버네티스[EKS] 클러스터를 운영 중 외부 API 호출이 불가능한 케이스가 생겼고 이를 분석한 내용을 정리하려고 한다. 현재 envoy-proxy를 istio가 매핑한 istio-proxy 컨테이너가 파드마다 사이드카 형태로 배포되고 있어 모든 네트워크 통신을 proxy하고 있다. istio에 대해 생소하다면 먼저 baeldung에 자료를 참고하면 좋을 것 같다. 모듈 개발을 포함한 다양한 개발 직군에서 이해할 수 있게 잘 설명한 듯 하다.https://www.baeldung.com/ops/istio-service-mesh istio 버전은 다음과 같다.[ec2-user@ip-10-250-32-36 ~]$ istioctl versionclient vers.. 더보기 쿠버네티스 파드 네트워킹 정리 시간이 지날수록 파드 네트워킹에 대한 개념이 흔들리는 것 같아 현재 내가 생각하고 있는 파드 네트워킹에 대해 기록해보려고 한다. 다음에 내가 이 글을 본다면 계속 수정해나가면서 개념을 잡을 수 있지 않을까 싶다. 쿠버네티스의 파드의 모든 컨테이너는 동일한 network namespace를 공유하기에 로컬 호스트로 서로 호출이 가능하다. 파드가 생성될 때 kubelet은 namespace와 croup을 설정하고 pause 컨테이너를 실행한다. 파드는 여러 컨테이너로 구성되어 있고 모든 파드 안에는 pause 컨테이너가 포함되어 있다. pause 컨테이너가 Network/IPC/UTS namespace를 생성, 유지, 공유하는 역할을 한다. 파드 내 컨테이너는 pause 컨테이너가 생성한 network .. 더보기 쿠버네티스[EKS] gp2, gp3 마이그레이션 다음은 Amazon EBS 볼륨 유형 gp2와 gp3의 비교 지표이다. 2020년 12월에 출시된 gp3를 사용하면 스토리지 크기를 느리지 않고도 IOPS와 처리량을 독립적으로 프로비저닝할 수 있어 GB당 최대 20% 비용을 절감할 수 있다고 한다. 즉 저렴한 비용으로 고성능을 유지하면서 더 적은 볼륨을 프로비저닝 할 수 있다. gp3의 최고 성능은 gp2의 볼륨의 최대 처리량보다 4배 빠르며 gp2 볼륨이 적용될만한 모든 케이스에서 gp3 볼륨을 사용할 수 있다고 하니 gp3를 사용하지 않을 이유가 없는 거 같다고 생각한다. gp3로 마이그레이션할 때 IOPS와 처리량에 대해서는 위 포스팅을 참고하도록 하자. https://aws.amazon.com/ko/blogs/korea/migrate-your-.. 더보기 쿠버네티스[EKS] Cluster, Node, Add ons Upgrade AWS EKS 의 경우, Kubernetes 버전이 정식 Release 이후 약 1년 동안 Support 해준다. 위와 같이 Extended support 라 하여 기존 Support 에 Extended Support 기간 1년을 지원해준다. 하지만, 안정적으로 Standard Support 받기 위해서는 기한 내에 Cluster의 Kubernetes 버전을 최신으로 업데이트 하는 것이 좋다. 마이너 버전은 출시 후 처음 14개월 동안은 표준 지원(Standard Support) 하에서 저렴한 비용(클러스터 하나에 시간당 $0.10)으로 이용이 가능하다. 그러나 해당 버전의 표준 지원이 종료된 이후에는 자동으로 다음 12개월 동안 추가 지원(Extended Support)을 받게 되는데, 이때는 더욱.. 더보기 쿠버네티스[EKS] SecurityGroupPolicy 일반적으로 EKS에서 Pod의 트래픽은 워커 노드의 Security Group을 따른다. 결국 Pod A와 Pod B가 동일한 워커노드에 있다면 Security Group 또한 동일할 것이다.필자는 EKS를 도입하기전 EC2 별로 서비스들을 운영하면서 보안그룹을 관리하였기에 Pod 별로 보안그룹을 관리하는 방법이 없을까 찾아보게 되었고 SecuriyGroupPolicy라는 것을 알게 되었다. 물론 익숙하지 않은 나에게 Ingree/Egress를 제어하는 방법은 다양한 것으로 보이지만 AWS native하게 설계된 서비스와 AWS VPC CNI를 쓰고 있는 나에게 적절해 보여 적용해보게 되었다. 간단히 말해 Pod 별로 SecuriyGroup를 만들어 관리하는 것이다. AWS SecuriyGroup은 EN.. 더보기 쿠버네티스[EKS] IRSA(IAM for ServiceAccount) AWS 자원 접근 시 EC2에 IAM Role을 부여하거나 IAM Account를 생성하여 accesskey, secretkey를 발급받아 aws configure에 등록하는 방법 등이 있다.뭐 상황에 따라 적절할 수는 있지만 최소한 쿠버네티스, EKS를 사용하는 환경에서는 워커노드에 권한을 주는 것은 Least Privilege Principle에 어긋날 것이다. 간단한 예를 들자면 Pod A가 DynamoDB 접근 권한이 필요해 워커노드에 권한을 준다면 해당 워커노드에서 실행 중인 Pod B, Poc C에게도 동일한 권한이 주어질 것이다. 또한 Account를 생성하여 키를 활용하는 방법은 키가 노출될 시 위험하기에 키 관리 또한 어려워질 수 있다.따라서 EKS 공식 기능인 IRSA(IAM roles.. 더보기 스프링부트 Virtual Thread, Spring Data Redis(Lettuce) 도입기 대규모의 트래픽을 받기 위해 설계하고 고민하는 도중 여러 선택지가 있었다. Corutin, Gorutin, Spring Webflux의 Reactive, 그리고 요즘 말이 많은 Virtual Thread 등이 있었다. 대규모 트래픽이라고 말하면 기준이 애매한 거 같다. 필자가 생각하는 대규모 트래픽은 현재 주어진 환경에서 받을 수 있는 최대치? 최선이 아닐까라고도 생각이 든다. 도메인마다 생각하는 대규모 트래픽이 다를 것이고 인프라 환경마다 받을 수 있는 트래픽이 다를 것이라고 생각이 들었기 때문이다. Virtual Thread를 선택한 이유는 단순히 기존 기술 스택에서 크게 벗어나지 않아 프로그래밍 스타일이 다르지 않고 러닝 커브와 학습 시간이 짧다고 생각했기 때문이다. 그렇지만 막상 도입하기 위해 .. 더보기 쿠버네티스[EKS] Strimzi Kafka 구축 (Kafka-Exporter, Metrics, Kafka-UI) Strimzi Kafka Operator를 활용하여 설치한 카프카에 대한 기록을 남겨보려고 한다. Strimzi Github을 참고하여 처음 설치할 때는 단발성의 (볼륨이 잡히지 않은) 카프카 클러스터를 생성하여 동작 과정을 확인하였고 바로 다음 볼륨(PVC)이 정의되고 메트릭 설정까지 정의된 예제 파일을 활용하여 클러스터를 설치하고 메트릭까지 확인하였다. Kafka pod안에서 Kafka CLI 간단한 명령어를 통해 토픽에 메시지를 보내고 컨슈머, 컨슈머 그룹을 통해 메시지를 받는 과정을 통해 상태를 확인했고 Kafka-ui를 통해 좀 더 직관적으로 토픽과 브로커에 대해 확인했다. 마지막으로 Kafka-exporter를 활용해 Consumer Lag을 포함한 정보를 프로메테우스에서 수집하고 그라파나.. 더보기 이전 1 2 3 4 ··· 20 다음
