강의 연장 부탁드립니다.

안녕하세요. CloudNet@ 팀입니다.확인해 보니 수강 기간이 무제한으로 반영된 상태입니다.다시 한번 확인 부탁드립니다.

강의 연장 부탁드립니다.

강의 연장 대응 완료했습니다.

16강 16:59 부분 문의드립니다

안녕하세요. CloudNet@ 팀입니다.EKS 환경에서 통신 흐름에 따른 세션 처리 질문에 대한 답변드립니다. 먼저 kubectl node-shell 명령으로 노드에 접속하면 실제 접근 흐름은 다음과 같습니다. 사용자 → Kubernetes API Server → 대상 노드의 Kubelet 즉, 사용자가 직접 노드로 SSH 접속하는 것이 아니라API Server가 Kubelet에 요청을 보내고, Kubelet이 노드 안에서 nsenter 기반의 임시 쉘 프로세스를 실행하는 방식입니다. 그래서 node-shell을 실행하면: API Server → Kubelet 사이에 새로운 연결(세션)이 생김 -> Kubelet이 node-shell을 위해 “임시 쉘 프로세스(nsenter)”를 만들기 때문이 연결을 유지하려고 kubelet이 TCP 연결을 하나 더 염 -> 이 연결을 통해 node-shell의 입·출력이 오간다.따라서 ss 명령어에서 새로운 ESTABLISHED 세션이 보임 -> API Server와 Kubelet이 node-shell 세션을 유지하고 있다는 의미 결론적으로 질문했던 것처럼: “kubectl node-shell로 접속하면 api-server와 통신해서 tcp 세션이 보이는 건가요?”→ 맞습니다.node-shell은 로컬 SSH가 아니라 API Server를 통해 프록시되는 exec 접속이기 때문에 API Server와 Kubelet 사이의 새로운 TCP 세션이 생성되고, 그 연결이 ss 명령으로 확인되는 것입니다. 감사합니다.

BationHost에서 AWS CLI 접속 실패

안녕하세요. CloudNet@ 팀입니다. 현재 변수에 값이 들어가지 않는 이유는 해당 IAM의 권한이 없거나 잘못된 값을 입력한 경우로 예상됩니다. (해당 변수들은 awscli를 통해 값을 호출 해서 저장하는 구조입니다.)먼저 Access Key ID와 Secret Access Key가 정상적으로 입력했는지 확인해 보시고 문제가 없다면,IAM User의 권한을 검토해 보는 것이 좋겠습니다. 내용 검토 후 해결 안되시면 다시 말씀주세요. 감사합니다.

ch1 external-dns pod 관련 버전 오류와 해결 방법 후 추가 오류 사항

안녕하세요. CloudNet@ 팀입니다.우선 감기로 인해 정신이 없어서.. 해당 질문 확인 시점이 늦어졌네요.양해 말씀드립니다. external-dns 관련해서 문제점과 해결법까지 제시해 주셔서 감사합니다.저도 히스토리를 따라가 보니 terraform external-dns module 버전 변경이 불가피해 보이네요. 조치 사항으로 대체 모듈을 찾거나 최적화 작업을 수행하려고 했는데 생각해보니 external-dns가 eks add-on으로 편입되었습니다.eks에서 add-on으로 지속 관리하니 환경적인 이슈나 호환성은 해소될 것으로 기대되네요. 참고로 external-dns가 eks add-on으로 공식 지원한 시점이 2025년 3월 31일부터 입니다.현재 구성된 eks k8s 버전인 1.32에서도 정상적으로 지원합니다. (아래)aws eks describe-addon-versions --addon-name external-dns --kubernetes-version 1.32 --query "addons[].addonVersions[].addonVersion" --output table ------------------------ | DescribeAddonVersions| +----------------------+ | v0.19.0-eksbuild.2 | | v0.19.0-eksbuild.1 | | v0.18.0-eksbuild.2 | | v0.18.0-eksbuild.1 | | v0.17.0-eksbuild.2 | | v0.17.0-eksbuild.1 | | v0.16.1-eksbuild.2 | | v0.15.1-eksbuild.1 | +----------------------+ [조치 사항]1. 기존 terraform module로 external-dns를 설치하는 부분을 제거2. terraform eks module에서 cluster_addons로 external-dns 설치... module "eks" { source = "terraform-aws-modules/eks/aws" version = "~>20.0" cluster_name = var.ClusterBaseName cluster_version = var.KubernetesVersion cluster_endpoint_private_access = false cluster_endpoint_public_access = true cluster_addons = { coredns = { most_recent = true } kube-proxy = { most_recent = true } vpc-cni = { most_recent = true } external-dns = { most_recent = true } } ... 3. 변경 사항으로 external-dns 파드의 네임 스페이스 위치가 kube-system에서 external-dns으로 변경=> 네임 스페이스를 기존 kube-system으로 변경하려 했지만 별도의 인자가 존재하지 않네요. 그래서 기본 값으로 유지했습니다.(myeks:default) root@myeks-bastion-EC2:~# k get pod -A NAMESPACE NAME READY STATUS RESTARTS AGE external-dns external-dns-577b6488b-46sgn 1/1 Running 0 44m kube-system aws-load-balancer-controller-9774b5bf9-sqm69 1/1 Running 0 44m kube-system aws-load-balancer-controller-9774b5bf9-wkpjl 1/1 Running 0 44m kube-system aws-node-lbtm5 2/2 Running 0 44m kube-system aws-node-q62nr 2/2 Running 0 44m kube-system aws-node-tg5cg 2/2 Running 0 44m kube-system coredns-7bb47d475b-8f55v 1/1 Running 0 44m kube-system coredns-7bb47d475b-ls4q6 1/1 Running 0 44m kube-system kube-proxy-5gmlz 1/1 Running 0 44m kube-system kube-proxy-cv694 1/1 Running 0 44m kube-system kube-proxy-cxgt7 1/1 Running 0 44m 4. 말씀주신대로 변경된 컨테이너 빌드는 최소화된 형태로 별도의 셸이 포함하지 않습니다.=> 꼭 external-dns가 아니라 파드에 kubectl exec로 접근할 때 세션 정보를 보는 것이라 별도의 테스트 파드로 확인하도록 변경했습니다. (EKS Hands-On 반영) 5. 현재 add-on을 통해 구성된 external-dns 파드의 로그 상 에러가 발생하지 않습니다.=> 보내주신 로그는 권한 이슈로 irsa 구성 이슈 같은데, 어떤 환경 때문인지 알긴 어렵네요. 현재 add-on을 통한 구성은 알아서 권한을 정의해서 정상 동작합니다. 6. 변경 사항에 대한 terraform 코드는 git에 반영했고, EKS Hands-On 페이지도 적절한 문구를 삽입했습니다. 이슈 사항 제보 및 해결 점까지 제시해 주시점 다시 한 번 감사합니다.

fluentbit 관련 node 의 기본 로그 질문

Fluent Bit 로그 수집 오류 관련 검토 내용을 공유드립니다. 현재 Fluent Bit은 rsyslog 기반의 로그 경로(/var/log/messages, /var/log/secure, /var/log/dmesg)를 전제로 동작하고 있어, Amazon Linux 2(AL2) 환경과만 호환됩니다.그러나 Amazon Linux 2023(AL2023) 기반의 최신 EKS 노드는 systemd 중심의 journald 로그 시스템을 사용하므로, 기존 경로와 매칭되지 않아 로그 수집이 정상적으로 이루어지지 않습니다. 앞서 검토한 사항을 정리하면 다음과 같습니다.1. aws-for-fluent-bit 최신 버전 확인 (AL2023 호환 여부)→ 현재까지 aws-for-fluent-bit는 systemd 로그를 직접 추출해 수집하는 기능을 지원하지 않습니다.2. EKS Worker Node AMI 명시 (AL2 사용 가능 여부)→ 현재는 EKS에서 Amazon Linux 2 AMI를 명시적으로 지정하여 사용하기 어렵습니다.3. 대체 로그 수집 도구 검토→ 여러 대체 도구가 존재하지만, AWS 공식 문서에서도 여전히 Fluent Bit을 권장하기 때문에 동일 도구를 유지하는 방향으로 판단했습니다. [조치 사항] AL2023 환경에서 rsyslog를 수동 설치하여 기존 로그 경로(/var/log/messages, secure, dmesg)를 복원하는 우회 방안을 적용했습니다.CloudFormation 템플릿 수정으로 노드 부팅 시 자동 설정되므로, 별도 수동 작업 없이 실습이 가능합니다. 다만 이 조치는 임시 대응이며 근본적인 조치가 필요합니다.향후 aws-for-fluent-bit에서 journald(Systemd) 로그 수집 플러그인을 공식 지원하면, 그에 맞게 실습 구성을 변경할 예정입니다. 자세한 내용은 EKS Hands-On 페이지에서도 확인하실 수 있습니다.https://www.ongja.space/15b4c62d-36c3-801e-a757-d85a33ea1cba#1fe4c62d-36c3-808e-8261-c2a17c59bdf9 Fluent Bit 로그 수집 오류 관련 제보 감사드립니다. 🙇‍♂

fluentbit 관련 node 의 기본 로그 질문

안녕하세요. CloudNet@ 팀입니다. 이미 인지하고 계신 부분이지만, Fluent Bit의 로그 수집 관련해 설명드립니다. 현재 Fluent Bit의 호스트 로그 수집 경로는 강의에서 설명드린 것처럼 아래 경로를 참조하고 있습니다./var/log/dmesg, secure, messages 문제는 EC2 인스턴스의 OS가 Amazon Linux 2(AL2)에서 Amazon Linux 2023(AL2023)으로 변경되면서, 로그 저장 경로가 바뀌었다는 점입니다.그로 인해 Fluent Bit에 지정된 경로와 실제 로그 경로가 일치하지 않아 수집이 정상적으로 이루어지지 않습니다. 즉,Amazon Linux 2(AL2) 환경에서는 정상 수집 (OK)Amazon Linux 2023(AL2023) 환경에서는 수집 실패 (NOK) EKS Worker Node의 node-AMI-family는 별도로 지정하지 않으면 기본값으로 AL2가 적용됐습니다.이 경우 Fluent Bit과의 연동에 문제가 없겠죠.하지만 최근 기본값이 AL2023으로 변경되었네요.그로 인해 Fluent Bit의 기존 로그 경로가 더 이상 유효하지 않게 되었습니다.결국 이로 인해 로그 수집이 중단되는 현상이 발생하고 있습니다. 참고로 말씀드리면,현재 4장을 제외한 모든 강의는 AL2023 기반으로 업데이트가 완료된 상태입니다.다만 4장은 Fluent Bit 로그 수집 경로 문제로 인해 임시로 AL2를 유지하고 있습니다.Fluent Bit의 AL2023 호환 버전이 나오기를 기다리는 중이었는데, 타이밍상 이슈가 드러난 상황이네요. [검토 사항]1. aws-for-FluentBit 최신 버전 확인 (AL2023 호환 여부)2. EKS Worker Node의 node-AMI-family를 명시적으로 AL2로 지정(기본값 X)3. Fluent Bit을 대체할 수 있는 다른 로그 수집 도구 검토 내용을 검토한 후 다시 안내드리겠습니다.일단 해당 파트는 잠시 건너뛰고, 다른 부분 먼저 진행해 주시면 좋겠습니다. 감사합니다.

POD에 Security Group이 부착되어있을 경우 통신 흐름 문의

안녕하세요. CloudNet@ 팀입니다.ELB에서 Pod로 전달되는 트래픽 흐름은 다이렉트로 Pod SG로 전달되는 것이 아니라, NodeGroup SG가 할당된 노드 ENI를 반드시 거쳐서 최종적으로 Pod SG가 적용된 Pod ENI로 전달되는 구조입니다.ELB가 위치한 IP 대역이 노드 그룹 서브넷 내라 할지라도, 네트워크 트래픽은 먼저 해당 노드의 ENI(연결된 NodeGroup SG)를 경유하여 워커 노드로 접속됩니다.이후 ENIConfig 설정에 따라 Pod에 할당된 별도의 ENI(이때 Pod SG 적용)로 패킷이 전달되어 Pod에 도달합니다.결국, ELB → NodeGroup SG(노드 ENI) → Pod SG(별도 ENI) 순으로 보안 그룹 규칙 정책이 연속적으로 적용되며, 이 흐름이 EKS 내 통신 흐름입니다.감사합니다.

EKS SG ENI 질문

안녕하세요. CloudNet@ 팀입니다.말씀하신 것처럼 보안 그룹은 ENI(Elastic Network Interface)에 부착되어 트래픽 접근 제어를 수행합니다.하나의 ENI에는 여러 개의 보안 그룹을 동시에 붙일 수 있고, EKS에서 생성된 노드에도 ENI가 여러 개 존재할 수 있습니다.참고로 EKS 클러스터 생성 방식(eksctl, 관리 콘솔, terraform 등)이나 구성 방식에 따라 보안 그룹 배치는 달라집니다. Cluster shared node security group (자동 지정)클러스터의 모든 노드에 공통으로 부착되는 SG입니다. 주 목적은 노드 간 상호 통신(Pod ↔ Pod, 노드 ↔ 노드)을 보장하는 것입니다.각 노드의 ENI에도 이 보안 그룹이 자동으로 포함됩니다. Node group security group (사용자 지정)eksctl이나 콘솔에서 노드 그룹을 만들 때 지정한 SG입니다.외부 접근 제어, ALB/NLB 연결 같은 업무 목적의 통신 제어에 활용됩니다. 즉, 질문 주신 것처럼 노드에는 여러 개의 ENI가 붙을 수 있고, 각 ENI에 다수의 보안 그룹이 함께 적용되어 있습니다. 추가로, 완전 프라이빗 클러스터(Fully Private Cluster)라면 VPC Endpoint ENI에도 Cluster Shared Node SG를 붙여서 노드와의 통신을 제어할 수 있습니다. 감사합니다.

강의 자료 ?

안녕하세요. CloudNet@ 팀입니다.해당 부분 영상을 확인해 보니 별도의 그림이 있는 것은 아닙니다.설명하면서 마우스 포인트가 이동했을 뿐이네요.