macOS에서 Windows 실행하는 프로그램

안녕하세요. CloudNet@ 팀입니다. macOS에서 Windows 환경을 보여드린 것은 실행하는 개념이 아닌 원격 접근입니다.즉, 윈도우 PC를 동일 네트워크에 구성한 후 macOS에서 원격 접근한 것이죠. “Windows App”이라는 원격 접근 도구를 활용했습니다.예전 이름으로는 “Microsoft Remote Desktop”이라는 도구였죠. 감사합니다.

Readiness Probe 관련 질문드립니다.

안녕하세요. CloudNet@ 팀입니다.좋은 질문 감사합니다. :)결론부터 말씀드리면, 말씀하신 방향의 이해가 맞습니다. 실제로는 Readiness Probe만으로 완전히 해결된다기보다는, 여러 설정이 함께 동작해야 안정적인 Rolling Update가 가능한데요.Readiness Probe는 기본적으로 Pod가 트래픽을 받을 준비가 되었는지 확인하는 역할입니다.다만 AWS ALB 환경에서는..Kubernetes Ready 상태ALB Target Group Healthy 상태사이에 시간 차이가 발생할 수 있습니다.그래서 실무에서는 보통..Readiness ProbeGraceful ShutdownterminationGracePeriodSecondsALB Deregistration Delay등을 함께 고려해서 무중단 배포를 구성합니다. 그리고 질문 주신 Readiness Gate 역시 좋은 포인트인데요.AWS Load Balancer Controller의 Pod Readiness Gate를 사용하면, ALB Target Group에서 Healthy 상태가 확인된 이후 Pod를 Ready로 판단할 수 있어서, 보다 안정적인 Rolling Update 구성에 도움이 될 수 있습니다. 다만 모든 환경에서 반드시 사용하는 것은 아니며, 서비스 특성과 운영 방식에 따라 선택적으로 적용하는 경우가 많습니다.즉, 각 환경에 따른 적절한 튜닝이 필요한 것이죠. :)좋은 포인트를 잘 짚어주셨습니다.감사합니다~

part 2 강의 일정

안녕하세요. CloudNet@ 팀입니다.이번 강의에 관심을 가져주셔서 감사합니다.Part 2 일정 문의 주셨는데요.이번 Part 1 강의 개설 시점부터 3개월을 목표로 작업중에 있습니다. 올해 7월 말이나 8월 초 정도로 예상해 볼 수 있겠네요.조금 더 빠른 작업을 위해 최선을 다해보겠습니다👍감사합니다.

강의 연장 부탁드립니다.

안녕하세요. 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을 대체할 수 있는 다른 로그 수집 도구 검토 내용을 검토한 후 다시 안내드리겠습니다.일단 해당 파트는 잠시 건너뛰고, 다른 부분 먼저 진행해 주시면 좋겠습니다. 감사합니다.