5장 원클릭 실습 프로메테우스 이슈

안녕하세요. CloudNet@ 팀입니다. 오류 메시지만 봤을 때는 PVC 바인딩되지 않는 문제를 표현하는 것 같은데요. 프로메테우스와 그라파나의 설치 파라미터에 Storage Class를 gp3로 사용하도록 선언하고 있습니다. 원클릭 배포 후에 기본 환경 설정에서 gp3 Storage Class 설정이 정상적으로 이루어져 졌는지 확인이 필요해 보이네요. 혹시 다른 이슈일 수도 있으니 저도 테스트를 위한 자원 배포 중에 있습니다. 배포까지 시간 소요되고~ 확인까지 시간이 필요하니 작업 후에 추가적으로 답변 드리겠습니다. 감사합니다.

안녕하세요, 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에 대해 다룰 예정입니다. 감사합니다.

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 영역에서 관리하기에 여러모로 유연한 통신 환경을 가질 수 있는 것이죠. 답변이 되었나 모르겠네요. 감사합니다 :)

내부에서 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] 감사합니다.

ALB 리스너 규칙 설정 부분 업데이트 필요

안녕하세요. CloudNet@ 팀입니다. 강의 관련해서 의견 감사드립니다. 전반적인 콘텐츠 확인 후 필요한 부분 업데이트 진행 계획 잡아두겠습니다. 감사합니다.