원클릭 배포 결과가 다릅니다.

안녕하세요. CloudNet@ 팀입니다.원클릭 배포 후 추가 스택 3개를 기다리시는 것을 보니 2장 원클릭 배포로 보이네요. 기본적인 원클릭 배포 구조는 VPC 환경 생성과 관리형 EC2 인스턴스가 생성됩니다.그리고 관리형 EC2 인스턴스에서 eksctl 명령을 자동으로 수행해서 EKS 클러스터가 생성되는 구조네요.이때 eksctl 명령에 따라 추가적인 CloudFormation 스택이 생성되는 것이죠. 아무래도 IAM User에 대한 권한이 부족하거나 Access Key ID와 Secret Access Key가 제대로 정의된 것인지 궁금하네요. 먼저 관리용 EC2에 등록된 IAM User 정보를 호출해 보시고요. aws sts get-caller-identity --query Arn 정상적으로 출력되면 대상 IAM User의 Policy가 어떤 것인지 확인 부탁드립니다. 감사합니다.

[실습] Service[NLB] 배포 및 확인의 aws-loadbalancer-controller 설치 및 실습 시 트러블슈팅

안녕하세요. CloudNet@ 팀입니다. 확인해 보니 aws-loadbalancer-controller의 버전이 올라가면서 iam policy 필수 옵션이 추가되었네요. (아래 링크)elasticloadbalancing:DescribeListenerAttributeselasticloadbalancing:ModifyListenerAttributes https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/tag/v2.9.0 iam policy 생성을 위한 레퍼런스 링크가 2.4.7 버전으로 고정되어 있어 최신 버전의 링크로 변경하였습니다.(eks hands-on 페이지 반영)https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json 제보 감사합니다.

eks 생성시 Control plane 질문

안녕하세요. CloudNet@ 팀입니다.질문 하신 내용에 대해 답변드리겠습니다. 먼저 EKS 클러스터는 영역을 컨트롤 플레인과 데이터 플레인으로 구분할 수 있습니다. 여기서 컨트롤 플레인 영역은 AWS 관리형으로 사용자 VPC와 서브넷과 별개로 AWS Managed VPC에 구성됩니다. 반면에 데이터 플레인은 사용자가 구성하는 Custom VPC에 구성됩니다. 이를 위해 CloudFormation에서 정의하고 있는 것이죠. 감사합니다 :)

강의 연장 요청 드립니다.

안녕하세요. CloudNet@ 팀입니다.강의 연장 요청에 대해 반영 후 알려 드립니다.감사합니다. --그리고 추가로 해당 글을 보시고 해당 게시판에 연장 요청을 하시는 분이 있을까 싶어 말씀드리자면...현재 제가 판단하기로 질문/답변 게시판에 강의 연장 요청은 게시판 취지에 적합해 보이지 않습니다.혹시나 요청할 분들이 있다면 메일 주소(ongja@cloudneta.net)로 연락주시면 감사하겠습니다.

강의 수장 연장 관련 문의

안녕하세요. CloudNet@ 팀입니다.강의 연장 요청에 대해 반영 후 알려 드립니다.감사합니다. --그리고 추가로 해당 글을 보시고 해당 게시판에 연장 요청을 하시는 분이 있을까 싶어 말씀드리자면...현재 제가 판단하기로 질문/답변 게시판에 강의 연장 요청은 게시판 취지에 적합해 보이지 않습니다.혹시나 요청할 분들이 있다면 메일 주소(ongja@cloudneta.net)로 연락주시면 감사하겠습니다.

강의 연장 요청드립니다.

안녕하세요. CloudNet@ 팀입니다.강의 연장 요청에 대해 반영 후 알려 드립니다.감사합니다. --그리고 추가로 해당 글을 보시고 해당 게시판에 연장 요청을 하시는 분이 있을까 싶어 말씀드리자면...현재 제가 판단하기로 질문/답변 게시판에 강의 연장 요청은 게시판 취지에 적합해 보이지 않습니다.혹시나 요청할 분들이 있다면 메일 주소(ongja@cloudneta.net)로 연락주시면 감사하겠습니다.강의 소개에 관련 내용 업데이트해 두겠습니다. :)

강의 기간이 얼마 남지 않아서 그런데 기한 연장을 요청드려도 될까요?

안녕하세요. CloudNet@ 팀입니다.요청하신 기한 연장에 대해 반영하였습니다.감사합니다.

VPC CNI 네트워크 환경 확인 문의

안녕하세요. CloudNet@ 팀입니다. VPC CNI 관련해서 깊이 있게 확인하시고 질문주시것 같네요. 확인이 늦어져 답변이 늦어진 점 양해 말씀드립니다. 저도 VPC CNI 동작관련해서 살펴 보았을때 “최초 파드 생성”에 대한 이벤트의 전과 후에 따른 상태가 다른 것으로 파악되었습니다.최초 파드가 생성되지 않는 상태에서는 별도의 Secondary ENI를 생성하지 않고 Primary ENI만 가지고 있는 상태를 볼 수 있습니다. 최초 파드가 생성되지 않는 노드에는 VPC CNI가 파드의 네트워크 설정을 관리하는 행위를 기록한 plugin.log 파일이 보이지 않을 수 있습니다. 어찌 보면 별도의 행위를 하지 않았으니 자연스러울 수도 있겠네요. 참고로 실습 환경에서 최초 환경을 보자면 daemon set 형태가 아닌 파드는 coreDNS 파드 뿐입니다.그런 측면에서 coreDNS 파드가 위치한 노드에는 VPC CNI 동작에 의해 plugin.log 파일이 보일 것이며, 그것이 아닌 노드에는 대상 파일이 보이질 않겠네요. 관련 동작에 대한 이유는 VPC CNI의 동작 알고리즘이니 제 기준으로 답을 내리긴 어려워 보입니다ㅠㅠVPC CNI 동작은 이런 형태로 취하구나 정도로만 이해하면 좋을 것 같습니다. 좋은 질문과 자체적인 답변 감사드립니다.

안녕하세요 ~ 궁금한 사항이 있습니다.

안녕하세요. CloudNet@ 팀입니다.일단 질문 내용은 아래와 같으며 이에 대한 답변드립니다."혹시 외부와 통신시에 고정 ip 1개로 통신하고 싶다면 워커노드를 프라이빗 서브넷에 배치후 NAT GateWay 를 통한 방법만 있을까요 ??" 질문주신 내용 그대로 해석하면 프라이빗 서브넷 환경을 구성하고 NAT GW 구성을 하는 방법 뿐이겠네요. 프라이빗 서브넷을 구성한다는 것은 외부에서 접근하는 노출을 막는 것이며, 구성된 자원의 외부 통신을 위해 NAT GW를 구성해야겠죠. 추가로 워커 노드를 프라이빗 서브넷을 구성하는 목적은 API 서버의 접근을 프라이빗하게 구성하는 것도 있습니다.강의 설명에도 있듯이 Endpoint Public Access와 Endpoint Public & Private Access와 Endpoint Private Access가 있다고 설명드렸죠.관련 내용 설명은 별도로 드리진 않고 아래 그림으로 갈음하겠습니다.(사진)감사합니다.

Karpenter VPC 질문입니다.

안녕하세요. CloudNet@ 팀입니다. 질문하신 내용에 대해 답변드립니다.먼저 Karpenter Preconfig로 배포하는 VPC는 EKS Bastion Host가 구성되는 네트워크 환경입니다. 참고로 EKS Bastion Host는 EKS Cluster를 관리하는 목적으로 사용되는데요.현재 API Endpoint 접근이 퍼블릭 액세스로 특별한 제약 없이 외부 통신만 가능하면 됩니다. 그래서 별도의 VPC에 퍼블릭 환경으로 구성한 것이죠. 반면 eksctl 명령으로 EKS 클러스터를 구성할 때 별도의 VPC를 지정하지 않으면, 자동으로 신규 VPC와 서브넷을 자동으로 생성하고 배포됩니다.이때 생성되는 VPC의 IP CIDR는 192.168.0.0/16이고 /19로 서브넷팅하여 퍼블릭 서브넷 3개와 프라이빗 서브넷 3개로 구성되네요. 정리해보면 CloudFormation을 통해 배포되는 VPC는 관리 용도의 Bastion Host를 위한 네트워크이고, eksctl로 배포되는 VPC는 클러스터의 네트워크로 서로 상관 관계가 없습니다.이러한 이유는 API 접근이 퍼블릭 액세스로 외부 인터넷을 통해 접근하기 때문인 것이죠.만약 프라이빗 액세스라면 VPC간 통신이 가능하도록 설정하거나, EKS Bastion Host가 클러스터 용도의 VPC에 존재해야 합니다. 추가로 eksctl로 배포할 때 발생하는 로그는 오류 메시지보다는 권고 사항을 알리는 목적으로 보입니다.IRSA를 통해 권한을 위임하는 방식에서 EKS Pod Identity로 위임하는 방식을 권고하는 것인데요. 참고로 Pod Identity는 파드에 대한 AWS 자원의 접근을 권한을 정의하는 새로운 방식으로 AWS에서 밀고 있는 방식입니다.이부분은 참고만 하세요~! 감사합니다.