EKS18 [AWS EKS] 보안그룹 최소 필요사항 정리 - 폐쇄망 기준- VPC Endpoint는 필요한 것 모두 생성되어 있다고 가정- inbound / outbound 모두 제어 (any는 없음)- Node의 보안그룹 / Cluster의 보안그룹은 각자의 클러스터 아키텍처에 맞게 생각 보안그룹typeprotocolport대상설명Node 보안그룹ingresstcp443, 10250Cluster 보안그룹필수 통신 포트Node 보안그룹egresstcp443, 10250Cluster 보안그룹필수 통신 포트Node 보안그룹egresstcp, udp53Cluster 보안그룹DNSNode 보안그룹egresstcp443VPC Endpoint 보안그룹endpoint 통신Node 보안그룹egresstcp443S3 Prefix Listendpoint 통신 Clust.. 2024. 7. 1. [AWS EKS] CoreDNS Addon을 FARGATE로 띄우기 (w. Terraform) # 0. 서론eks의 모든 노드들을 카펜터로 띄우기 시작했다.카펜터가 아닌 노드가 없기 때문에 karpenter 자체는 fargate로 띄워야만 했다.여기까지는 managed node group > karpenter로 마이그레이션하다가 알게 된 것이고.. 카펜터만 띄우는 설정으로 새로 클러스터를 띄우다보니 coredns가 karpenter보다 먼저 떠야 한다는 것을 알게 되었다.(카펜터도 내부 dns에 의존하는 무언가가 있나보다. 더 자세히 알아보진 않았다.) 따라서 karpenter와 마찬가지로 coredns도 fargate로 띄우도록 설정을 변경하게 되었다.이 때 필요한 과정을 terraform으로 설명하겠다. # 1. coredns fargate profile 생성locals { cluster_n.. 2024. 4. 28. [AWS EKS] 클러스터 보안그룹 vs 추가 보안그룹 (Cluster SG vs Additional SG) # 결론클러스터 보안그룹과 추가 보안그룹은 다르다.클러스터 보안그룹 (EKS 생성 시 자동 생성되며, self rule도 자동으로 생성되어 있음) 은 eks api로 만든 컴퓨팅 리소스 (fargate, managed ec2 node group) 들에 적용된다.즉,컨트롤플레인의 cross-eni : 클러스터 보안그룹 & 추가 보안그룹 사용fargate, managed node group 노드 : 클러스터 보안그룹 사용자체 런치템플릿 사용한 managed node group, self managed 노드 : 커스텀 보안그룹 사용 (내가 지정하는걸로) # 일단 용어정리클러스터 보안그룹 : eks 클러스터 생성 시 자동으로 생성되는 "Cluster security group"추가 보안그룹 : eks 클러스터 .. 2024. 4. 28. [k8s/ingress-nginx/aws] Chart: Add a TargetGroupBinding 결론 : 너무 user specific하다고 close 됨. >> 내가 별도로 차트 올려둠 (ingress-nginx-4.10.0 기반, https://artifacthub.io/packages/helm/suminhong/ingress-nginx-external-lb) https://github.com/kubernetes/ingress-nginx/pull/11198 Chart: Add a TargetGroupBinding object to the ingress-nginx helm chart template. by suminhong · Pull Request #11198 · kubernet What this PR does / why we need it: Add a TargetGroupBinding obje.. 2024. 4. 4. [EKS/Access Configuration] Managed Node Group > Karpenter Migration 시 aws-auth 문제 해결 # 이슈 발생 원래 Managed EC2 Node Group으로 EKS를 구성해 두었다가, Karpenter PoC를 마치고 모두 넘어가려고 준비중이었다. 따라서 Managed Node Group (이하 node group) & Karpenter가 모두 떠 있었고, node group은 노드를 0으로만 유지중이었다. 이제 모든 클러스터가 카펜터로 잘 동작중이기 때문에, node group은 이제 지워야지! 하고 dev 클러스터부터 전부 지움. 그러자 ... 갑자기 카펜터로 뜬 노드들이 전부 죽기 시작했다. # 뭔지 모르겠지만 일단 롤백 아무리 생각해도 node group이랑 카펜터에 연관 관계가 있을 것 같지 않았다. 근데 롤백하니까 (node group 살리니까) 카펜터 노드들도 다시 살아나기 시작했다.. 2024. 3. 28. [Karpenter] Disruption budget (중단 제어) 사용하기 (v0.34.0~) (feat. karpenter upgrade) https://aws.amazon.com/ko/about-aws/whats-new/2024/02/disruption-controls-karpenter/ Karpenter에 대한 중단 제어 기능 발표 오늘 v0.34.0 릴리스부터 오픈 소스 Karpenter 프로젝트를 사용하는 Amazon Elastic Kubernetes Service(EKS) 고객에게 Kubernetes 클러스터의 Amazon EC2 인스턴스에 획기적인 변경이 적용되는 방법과 시기를 제어할 aws.amazon.com https://karpenter.sh/v0.34/concepts/disruption/ Disruption Understand different ways Karpenter disrupts nodes karpenter.sh k.. 2024. 3. 9. [k8s/EKS] Fargate와 Daemonset # Fargate를 쓰는 이유 karpenter pod를 띄우기 위해서. (karpenter pod는 karpenter가 띄운 노드에 뜰 수 없다.) 별도 ec2 node group을 만들수도 있지만, 우리의 궁국적인 목적은 ec2 node group을 없애고 스팟으로만 운영하는 것이기 때문에 karpenter용 fargate를 띄움 참고로 pod 하나당 fargate 하나가 뜸 # Daemonset 노드의 백그라운드에서 항상 실행되며 여러 작업을 수행 → 노드별로 파드가 하나씩 떠야 함. 이 때, fargate도 결국 노드의 한 종류인데 fargate에도 떠야하느냐? → 아니다. fargate는 hsot가 없기 때문에 데몬셋이 지원되지 않는다. 따라서 데몬셋들은 fargate가 아닌, ec2 노드들에만.. 2024. 2. 9. [EKS/Terraform] Secondary IP 줄이기 with Terraform # 현상 18개 파드가 존재하는 10.10.0.218 노드가 있다. 그러나 해당 노드엔 2개 eni / eni포함 총 60개의 ip가 붙어있다.... 다른 노드들도 사용하는 파드들에 비해 상당히 많은 ip들을 갖고 있었고, 이로 인해 서브넷에 가용 ip가 부족해졌다. # 분석 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI Elastic network interfaces - Amazon Elastic Compute Cloud For EC2 instances in an IPv6-only subnet, if you attach a secondary network interface to the instanc.. 2024. 2. 6. [ingress-nginx] restart 시 downtime 해결 - minReadySeconds # 요약 NLB 에서 IP Type의 Target이 정상적으로 Register되는데 3분 이상이 걸리는 이슈가 있다. -> deployment restart로 신규 파드가 정상적으로 뜨더라도, NLB에서 3분동안은 바라볼 수 없음 -> 그 사이에 기존 파드들이 죽기 시작하면 순단이 생김 -> minReadySeconds를 적절한 시간으로 조정하여 해결 # 현재 구조 EKS Cluster 안에서 ingress-nginx 를 사용중이며, Service Annotation을 통해 (정확히는 aws-loadbalancer-controller를 통해) AWS NLB가 생성되어 매핑되어 있다. 이 때, NLB 의 Target으로 ingress-nginx controller pod들의 ip가 등록되어 있음 # res.. 2023. 11. 29. [Cluster-Autoscaler] Over Provisioning with Terraform # 현상 node의 cpu / memory가 거의 대부분 점유되고 있는 상황에서도 node가 늘어나지 않고 있다. 내가 생각했을 때 CA를 사용하면 노드 리소스가 80% 이상 사용 중일 때 새로 노드 추가 ~ 뭐 이런식으로 진행될 줄 알았는데, 그게 아니었다. 노드가 새로 추가되는건 노드에 자리가 없어서 배치되지 못하는 pod가 존재할 때 … 이다. 사실 쿠버네티스 사용 목적 등을 생각하면 그게 맞다. 하지만 파드가 하나 새로 떠야되는데 그 때서야 노드 프로비저닝을 시작한다? → 느리다. → 어느정도의 over provisioning이 필요하다. # Over Provisioning https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscal.. 2023. 11. 26. [EKS/Java/IRSA] JAVA App에 IRSA 부여할 때 종속성 추가하기 # 상황 IRSA : AWS EKS에 띄운 Application에 Pod 단위로 IAM Role을 부여하는 방법 따라서 AWS 리소스를 사용하는 Application을 쿠버에 띄울 때 IRSA 방식을 사용하면 보안적으로 좋다 근데 자바 앱들이 IRSA로 넣어준 Role을 사용하지 않고, 자꾸 EKS Node의 Role을 사용하다가 권한 에러가 났다. # 결론 sts 종속성을 추가해줘야 한다. dependencies { implementation("software.amazon.awssdk:sts:2.20.140") } # 분석 간단히 풀어 말해, IRSA 방식은 AWS STS 서비스의 AssumeRoleWithWebIdentity API 를 사용해 Role을 부여한다. -> 자바 앱들은 STS 종속성이 없.. 2023. 9. 15. [RBAC & IRSA] ECR Secret Updater Cronjob 구성 pod가 ECR의 이미지를 받아오는 방법은 여러가지가 있다. 1. EKS에서 보편적이고 권장되는 방법인, EKS Node Role의 권한으로 받아오는 것 2. ECR Token 값을 받아와 Docker Secret으로 저장 후 pod가 해당 Secret을 물고 올라감 나도 당연히 우리 회사의 새 아키텍처에서 1번으로 세팅해두고 싶었다. 그러나! 새 아키텍처에서는 "모든 계정의 클러스터" 에서 "공용 계정의 ECR" 에서 이미지를 받아오는 것으로 결정됐다. 뭐...그래도 Cross Account로 받아오는 방법이 당연 있을텐데, 역시 ECR Repository 단위로 타 계정을 허용해줄 수 있었다. { "Version": "2008-10-17", "Statement": [ { "Sid": "AllowPus.. 2023. 9. 4. [Grafana Loki] Errors loading rules # 상황 - 중앙 EKS 클러스터에 grafana chart를 사용해 Grafana가 설치되어 있음 - 각 EKS 클러스터별로 loki-stack chart를 사용해 Loki와 promtail이 설치되어 있음 - 각 EKS 클러스터별로 kube-prometheus-stack chart를 통해 Prometheus와 AlertManager가 설치되어 있음 (로키 스택에서 프로메테우스도 전부 깔 수 있지만, 프로메테우스가 먼저 깔려있는 상태에서 로키 도입하다 보니 이렇게 됨) # 문제 상황 Grafana와 Loki를 별도로 쿠버네티스 위에 띄우고, Grafana에서 Data Source로 Loki를 추가했습니다. Connection Test는 성공하지만,,, 위 사진처럼 Alert rules로 가면 로키 데이.. 2023. 7. 27. [k8s/aws] 쿠버네티스에서 AWS EBS를 볼륨으로 사용할 수 있기까지 본 글은 설명하고자 하는 전체 과정을 러프하게만 설명하며, 각 리소스들에 대한 상세한 설명 및 만드는 방법 등은 모두 생략합니다. # PV, PVC - 쿠버네티스에서의 볼륨 쿠버네티스에서 앱들은 pod 형태로 올라가며, 각 pod에는 1개 이상의 컨테이너가 돌아갑니다. 컨테이너 내 디스크에 존재하는 파일은 유실될 가능성이 높으며, 다른 pod 내 컨테이너와 공유할 수 없습니다. -> 쿠버네티스 클러스터 상의 볼륨 리소스를 사용해 같은 배포 내의 pod들이 같은 볼륨을 바라볼 수 있어야 합니다. 먼저 임시 볼륨 (ephemeral volume) 이 있습니다. 임시 볼륨으로도 파드 재시작 시의 데이터 보존은 가능하지만, 데이터의 영구 보존은 불가합니다. 그치만 영구 보존... 필요하죠? 필요한 경우, PV와.. 2023. 7. 26. [Terraform/k8s] aws-auth ConfigMap Patch # aws-auth란? aws와 k8s는 권한 체계를 다르게 가져간다. -> aws에 어드민 권한이 있더라도 eks를 최초로 생성한 User(또는 Role)가 아니라면 내부 리소스를 확인할 수 없다. 하지만 aws에서 올리는 k8s인 eks 특성상, aws의 권한을 인가받을 수 있어야 한다. 예를들면, 당장 eks의 노드(ec2. 또는 fargate session)에서도 k8s 리소스들에 대한 권한이 필요하며, aws의 다른 유저들에게 내가 생성한 eks를 공유할수도 있어야 한다. -> aws authentication을 k8s 권한체계랑 매핑시켜주는게 aws-auth ConfigMap의 역할이다. aws-auth의 full configuration format은 아래에서 확인할 수 있다. https:/.. 2023. 7. 20. 이전 1 2 다음
