게시글
질문&답변
2024.05.22
Prometheus ALB 443 Listener Issue
보내주신 결과를 보면 aws-load-balancer-contoller와 IRSA는 문제가 없습니다. 다른 내용을 자세히 보니 Ingress ALB가 구성됐지만... 443에 대한 Targetgroupbinding이 되질 않는 것이네요. 이 부분은 인증서와 연관있어 보입니다. 증상 재현을 위해 AWS Cert Manager 인증서의 ARN을 변수에 선언하고 CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`; echo $CERT_ARN 강제로 대상 인증서를 삭제했습니다. 마치 유효하지 않는 인증서 인것 처럼요. aws acm list-certificates { "CertificateSummaryList": [] } (사진)ingress의 호스트에 ADDRESS가 보이질 않네요. (admin@myeks:default) [root@myeks-bastion-EC2 ~]# kubectl get targetgroupbindings -n monitoring No resources found in monitoring namespace. 결국 동일한 증상 재현이 가능하네요. 이것으로 보아 AWS Certificate 인증서 만료가 된게 아닐까 생각이듭니다. AWS 관리콘솔에 "AWS Certificate Manager"로 진입한 후 인증서 메뉴 살펴보세요. 만료가 되었다면 재인증 작업 수행 후 다시 진행해 보시길 바랍니다. 참고로 인증서 발급은 EKS Hands-On에 4장 실습 Amazon EKS 원클릭 배포 및 기본 설정 에 있으니 살펴보시고요. (사진) 잘 해결되었으면 좋겠네요~ --- 추가로 다시 인증서 생성 후 프로메테우스 스택을 다시 배포해보았습니다. (사진)잘 동작하네요.
- 2
- 6
- 435
질문&답변
2024.05.22
Prometheus ALB 443 Listener Issue
아무래도 aws-load-balancer-controller 구성이나 권한에 문제가 있어보입니다. 아래 명령어를 통해 정상적인 구성을 확인해 볼 필요가 있어보이네요. 그래야 원인 파악에 조금 더 다가갈 수 있을 것 같습니다. # aws-load-balancer-contoller Deployment 확인 kubectl get deploy -n kube-system | grep aws-load # aws-load-balancer-webhook-service Endpoints 확인 kubectl get endpoints -n kube-system aws-load-balancer-webhook-service # aws-load-balancer-contoller Pod 확인 kubectl get pods -n kube-system | grep aws-load- # aws-load-balancer-contoller Log 확인 kubectl logs deploy/aws-load-balancer-controller -n kube-system # irsa 확인 aws iam list-roles --query "Roles[?starts_with(RoleName, 'eksctl-myeks-addon-iam')].[RoleName]" --output text -- eksctl-myeks-addon-iamserviceaccount-kube-sys-Role1-BDYA44AFZXRR # irsa 상세 확인 (위 irsa 이름 지정) aws iam get-role --role-name eksctl-myeks-addon-iamserviceaccount-kube-sys-Role1-BDYA44AFZXRR # OIDC 확인 aws iam list-open-id-connect-providers
- 2
- 6
- 435
질문&답변
2024.05.22
Prometheus ALB 443 Listener Issue
안녕하세요. CloudNet@ 팀입니다. 문의 사항에 대해 확인해 보니 정상적으로 생성되고 동작하네요. kubectl get targetgroupbindings -n monitoring NAME SERVICE-NAME SERVICE-PORT TARGET-TYPE AGE k8s-monitori-kubeprom-325788d22a kube-prometheus-stack-prometheus 9090 ip 82s k8s-monitori-kubeprom-776042db8a kube-prometheus-stack-grafana 80 ip 80s ingress ALB 생성에 이슈가 있는 것으로 보이는데... 예상되는 이슈로는 AWS Load Balancer Controller의 IRSA 설정이 누락된게 아닌가 싶습니다. 참고로 원클릭 배포를 수행하면 최초 myeks 스택을 시작해서 다양한 스택이 생성되는데요. 이번 실습은 총 9개의 스택이 생성되어야 정상적인 환경이라고 볼 수 있습니다. (사진) (사진)위 스샷과 같이 AWS Load Balancer Contoller의 IRSA를 위한 스택이 보이네요. 모든 스택이 생성되기까지 20분 남짓의 시간이 필요합니다. 혹시 그전에 myeks-host에 접근해서 작업을 수행하면 문제가 발생할 수 있겠네요. 아무래도 개인적인 예상으로 다른 특정 사항이 있다면 코멘트 부탁드릴게요. 감사합니다.
- 2
- 6
- 435
질문&답변
2024.05.22
Prometheus ALB 443 Listener Issue
안녕하세요. CloudNet@ 팀입니다. 문의 사항 내용 확인했고 테스트 후 회신 드리겠습니다. 감사합니다.
- 2
- 6
- 435
질문&답변
2024.05.03
EKS 관리용 인스턴스(myeks-host)가 사라졌습니다.
안녕하세요. CloudNet@ 팀입니다. myeks-host 를 수동으로 종료했다는 의미인것이죠? 먼저 인스턴스 종료는 자원 삭제를 의미하는데요. 일정 시간 동안 EC2 인스턴스 메뉴에 노출되지만 자원 삭제된 상태인 것이죠. 인스턴스 중지와 종료에 대해 헤깔리는 경우가 종종 있습니다. 어떤 이유로 myeks-host 를 종료하신 것지 모르겠지만.. 기존 원클릭 배포 삭제 후 재배포 후 새롭게 진행하셔야 할 것 같네요. 감사합니다.
- 0
- 2
- 89
질문&답변
2024.04.28
5장 원클릭 실습 프로메테우스 이슈
안녕하세요. CloudNet@ 팀입니다. 오류 메시지만 봤을 때는 PVC 바인딩되지 않는 문제를 표현하는 것 같은데요. 프로메테우스와 그라파나의 설치 파라미터에 Storage Class를 gp3로 사용하도록 선언하고 있습니다. 원클릭 배포 후에 기본 환경 설정에서 gp3 Storage Class 설정이 정상적으로 이루어져 졌는지 확인이 필요해 보이네요. 혹시 다른 이슈일 수도 있으니 저도 테스트를 위한 자원 배포 중에 있습니다. 배포까지 시간 소요되고~ 확인까지 시간이 필요하니 작업 후에 추가적으로 답변 드리겠습니다. 감사합니다.
- 0
- 1
- 66
질문&답변
2024.04.14
안녕하세요, NatGateway 구성 질문 드립니다.
안녕하세요. CloudNet@ 팀입니다. 인프런 AI 인턴에서 빠른 답변을 했네요. 답변 내용이 조금 모호한 면이 있는 것 같아 질문에 대한 추가 답변 드립니다. 일단 NAT Gataway를 구성해야 하는 경우는 아래 설명과 같이 프라이빗 서브넷에 자원이 외부 인터넷 구간 통신을 위함 입니다. 이러한 NAT Gateway 구성은 사용량과 시간에 따른 과금이 발생하는데요. 아무래도 실습 환경에서 이러한 과금을 줄여보고자 환경적인 구성을 퍼블릭하게 구성한 것이죠. EKS 클러스터를 프라이빗한 환경을 구성한다면 필수적으로 NAT Gateway가 필요합니다. 프라이빗 서브넷에서 외부 간으로 통신이 필요할테니깐요 강의 상으로 보면 실습을 위한 환경일뿐 보안적인 측면을 고려한다면 비즈니스 환경에서는 EKS Fully Private Cluster 구성을 추천합니다. 그로 인해 NAT Gateway나 VPC Endpoint 등이 필요하겠네요. 이러한 환경을 구성하는 방법에 대해서는 AWS Docs나 검색을 통해 확인해야 할 것입니다. 참고로 Amazon EKS 확장판 강의를 6월 목표로 작업 중에 있는데 여기서 EKS Fully Private Cluster에 대해 다룰 예정입니다. 감사합니다.
- 1
- 3
- 96
질문&답변
2024.04.04
Amazon VPC CNI 아키텍처와 통신 흐름
안녕하세요. CloudNet@ 팀입니다. 먼저 질문하신 사항을 정리해보면... 서로 다른 노드에 위치한 파드가 통신할 때 IP 헤더를 캡슐화하는 것에 대해 어떻게 식별해서 IP 헤더를 붙이는 지에 대한 질문으로 보이는데요. Amazon VPC CNI 통신 흐름이 아닌 Kubernetes Calico CNI 통신 흐름에 대한 질문 같네요. Amazon VPC CNI 환경은 노드와 파드가 같은 대역으로 별도의 IP 헤더를 캡슐화하지 않으니깐요. Calico CNI 통신 방식은 총 3가지 유형이 있는데요. Amazon VPC CNI 동작과 대조하는 측면에서 IP-IN-IP 모드로 예를 들어 설명드린 것입니다. 결론부터 말씀드리면 Calico CNI의 IP-IN-IP 방식은 BGP로 Calico에서 관리하는 라우팅 테이블에 의해 파드 간의 정보를 파악하고 경로를 가지고 있으며 이를 통해 IP 헤더를 캡슐화하는 개념입니다. 즉, Calico 관리 라우팅 테이블을 참조해서 IP 헤더를 덧붙이는 것이죠. 참고로 Calico CNI의 다른 모드들도 간단히 설명드리자면… VXLAN 모드도 캡슐화를 통해 동작하는데 IP 레벨이 아닌 MAC 레벨의 캡슐화가 일어납니다. 그런 측면에서 Calico에서 관리하는 BGP 라우팅 테이블을 사용하지 않아 BGP 동작 없이 Calico 내부적으로 VXLAN 정보를 관리하고 활용합니다. 마지막으로 BGP 모드는 별도의 캡슐화 없이 직접적인 통신이 가능합니다. 그 이유는 노드 레벨의 라우팅 테이블에 BGP 라우팅 정보를 모두 가지고 있기 때문이죠. 직접적인 통신으로 오버헤드가 줄어들 수 있겠지만 대규모 환경이라면 노드 입장에서 모든 라우팅을 관리하는 점에 부담이 될 수 있겠네요. 이렇게 다양한 환경 조건에 따라 Calico CNI 통신 방식을 정할 수 있습니다. 이에 대비해서 VPC CNI는 캡슐화 없이 직접적인 통신이 가능하며 라우팅 테이블 관리도 AWS VPC 영역에서 관리하기에 여러모로 유연한 통신 환경을 가질 수 있는 것이죠. 답변이 되었나 모르겠네요. 감사합니다 :)
- 0
- 1
- 95
질문&답변
2024.03.26
내부에서 DNS 질의할때 CoreDNS 동작방식
안녕하세요. CloudNet@ 팀입니다. 강의 잘 듣고 계신다니 다행이네요. 🙂 질문하신 내용에 대해 답변드립니다. 내부에서 DNS 질의를 할때 동작을 살펴보면… 1. 파드에서 DNS Query를 수행하면 먼저 파드 내부에 Local DNS Resolver로 전달합니다. 여기서 resolv.conf에 구성된 파일을 확인하고 DNS 조회를 수행합니다. 2. NodeLocalDNS는 DNS 요청 결과를 기록해 두는 캐시 역할을 수행하며 빠르게 DNS Query를 처리하도록 돕습니다. 3. 만약 캐싱된 정보에 대상이 없을 경우 CoreDNS로 전달합니다. 4. CoreDNS는 Kubernetes 클러스터 내부의 서비스와 리소스에 대한 DNS 조회를 처리합니다. (서비스 조회, 외부 DNS 조회, 캐싱) 5. CoreDNS 구성은 corefile에 의해 관리되며 필요에 따라 커스터마이징할 수 있습니다. 참고로 2022년 10월 EKS 에서 Add-On에 대한 편집 기능을 도입하여 CoreDNS corefile 수정으로 사용자 정의가 가능합니다. https://aws.amazon.com/ko/blogs/containers/amazon-eks-add-ons-advanced-configuration/ (사진)[출처: By NsLookup.io. Licensed under CC By 4.0] 감사합니다.
- 0
- 1
- 134
질문&답변
2024.03.22
ALB 리스너 규칙 설정 부분 업데이트 필요
안녕하세요. CloudNet@ 팀입니다. 강의 관련해서 의견 감사드립니다. 전반적인 콘텐츠 확인 후 필요한 부분 업데이트 진행 계획 잡아두겠습니다. 감사합니다.
- 0
- 1
- 76