Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. 이번에도 해결 방법까지 공유해 주셔서 감사합니다. 최신 Jenkins는 Java 17 지원을 종료하고 Java 21 이상을 요구하네요. 에이전트도 컨트롤러와 같은 Java 21 이상이 필요해서, Bastion의 Java 17 환경에서는 말씀하신 오류가 발생합니다. Hands-On의 에이전트 설치 단계도 openjdk-21-jre-headless 로 수정해 반영하겠습니다. 연이어 꼼꼼하게 제보해 주셔서 큰 도움이 되었습니다. 감사합니다!
Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. Jenkins 버전에 따른 설치 오류 제보 감사드립니다. 내용 검토해서 Hands-On 페이지에 반영해 놓도록 하겠습니다. 감사합니다 :)
Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. Part 2 강의 일정 문의에 대해 2026년 8월 20일에 오픈이 완료된 점 알려드립니다. 감사합니다.
Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. macOS에서 Windows 환경을 보여드린 것은 실행하는 개념이 아닌 원격 접근입니다. 즉, 윈도우 PC를 동일 네트워크에 구성한 후 macOS에서 원격 접근한 것이죠. “ Windows App ”이라는 원격 접근 도구를 활용했습니다. 예전 이름으로는 “Microsoft Remote Desktop”이라는 도구였죠. 감사합니다.
Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. 좋은 질문 감사합니다. :) 결론부터 말씀드리면, 말씀하신 방향의 이해가 맞습니다. 실제로는 Readiness Probe만으로 완전히 해결된다기보다는, 여러 설정이 함께 동작해야 안정적인 Rolling Update가 가능한데요. Readiness Probe는 기본적으로 Pod가 트래픽을 받을 준비가 되었는지 확인하는 역할입니다. 다만 AWS ALB 환경에서는.. Kubernetes Ready 상태 ALB Target Group Healthy 상태 사이에 시간 차이가 발생할 수 있습니다. 그래서 실무에서는 보통.. Readiness Probe Graceful Shutdown terminationGracePeriodSeconds ALB Deregistration Delay 등을 함께 고려해서 무중단 배포를 구성합니다. 그리고 질문 주신 Readiness Gate 역시 좋은 포인트인데요. AWS Load Balancer Controller의 Pod Readiness Gate를 사용하면, ALB Target Group에서 Healthy 상태가 확인된 이후 Pod를 Ready로 판단할 수 있어서, 보다 안정적인 Rolling Update 구성에 도움이 될 수 있습니다. 다만 모든 환경에서 반드시 사용하는 것은 아니며, 서비스 특성과 운영 방식에 따라 선택적으로 적용하는 경우가 많습니다. 즉, 각 환경에 따른 적절한 튜닝이 필요한 것이죠. :) 좋은 포인트를 잘 짚어주셨습니다. 감사합니다~
Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. 이번 강의에 관심을 가져주셔서 감사합니다. Part 2 일정 문의 주셨는데요. 이번 Part 1 강의 개설 시점부터 3개월을 목표로 작업중에 있습니다. 올해 7월 말이나 8월 초 정도로 예상해 볼 수 있겠네요. 조금 더 빠른 작업을 위해 최선을 다해보겠습니다 👍 감사합니다.
Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. 확인해 보니 수강 기간이 무제한 으로 반영된 상태입니다. 다시 한번 확인 부탁드립니다.
Hỏi & Đáp
강의 연장 대응 완료했습니다.
Hỏi & Đáp
안녕하세요. 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 명령으로 확인되는 것입니다. 감사합니다.
Hỏi & Đáp
안녕하세요. CloudNet@ 팀입니다. 현재 변수에 값이 들어가지 않는 이유는 해당 IAM의 권한이 없거나 잘못된 값을 입력한 경우로 예상됩니다. (해당 변수들은 awscli를 통해 값을 호출 해서 저장하는 구조입니다.) 먼저 Access Key ID와 Secret Access Key가 정상적으로 입력했는지 확인해 보시고 문제가 없다면, IAM User의 권한을 검토해 보는 것이 좋겠습니다. 내용 검토 후 해결 안되시면 다시 말씀주세요. 감사합니다.
