전체 글 썸네일형 리스트형 쿠버네티스 자원 할당에 대한 고려 쿠버네티스에서 Pod의 cpu, memory, hugepages를 포함한 리소스에 대해서 Request, Limit을 지정할 수 있습니다. 말 그대로 자원의 최소, 최댓값을 주어 파드마다 리소스를 보장할 수 있습니다. 적용 방법은 k8s ko 공식 문서에서 손 쉽게 확인할 수 있습니다. 참고 그런데 실제로 쿠버네티스를 운영하다보면 cpu를 지정한 limit만큼 사용하지 않아도 throttling이 발생하는 것을 확인되었습니다. throttling은 쉽게 설명드리면 컨테이너가 limit 이상으로 사용될 경우 커널이 해당 cpu를 사용하지 못하게 일정 시간 동안 강제로 중단시키는 것을 말합니다. 이렇게 스스로 정의했었기에 throttling이 발생하는 것이 의아했습니다. 이것을 이해하기 위해서는 쿠버네티스.. 더보기 쿠버네티스 파드 생성부터 종료까지 (graceful shutdown) 쿠버네티스에서 파드가 생성되는 과정에 대해서는 많은 글에서 참고할 수 있습니다.특히 쿠버네티스 컴포넌트들의 동작 과정 중심으로 추상화된 파드 생성 과정은 많이 볼 수 있습니다. 마스터 노드와 워커 노드에 각 컴포넌트들과 파드의 생성 과정에 대해 처음이라면 해당 블로그를 참고하면 될 것 같습니다. 참고 이번 글은 쿠버네티스에서 graceful shutdown의 과정을 기록하기 위하여 조금 더 이와 관련된 파드 생성 과정부터 간략히 적어보려고 합니다. 그 이유는 파드의 생성 과정과 반대로 종료 과정이 이루어지기 때문입니다. 다음과 같은 파드가 생성된다고 가정해보겠습니다. pod.yamlapiVersion: v1kind: Podmetadata: name: my-podspec: containers: .. 더보기 쿠버네티스 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와 cgroup을 설정하고 pause 컨테이너를 실행한다. 정확히는 kubelet이 CRI에게 생성을 위임하며 이는 파드를 실행하며 설정된다. 파드는 여러 컨테이너로 구성되어 있고 모든 파드 안에는 pause 컨테이너가 포함되어 있다. pause 컨테이너가 Network/IPC/UTS namespace를 생성, 유지, .. 더보기 쿠버네티스[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.. 더보기 이전 1 2 3 4 ··· 21 다음
