🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Learning Kubernetes on the internet like a madman - PART 5는 self-managed Kubernetes를 EC2 위에 직접 조립하며, Valheim 서버와 cats 웹서버가 결국 동작하더라도 bootstrap 순서·AWS 연동·비용·운영 복잡도가 핵심 학습 비용이라는 점을 보여준다.

📌 핵심 요점

1. EKS 없이 Talos 기반 control plane과 worker, Argo CD, Envoy Gateway, AWS CCM, EBS CSI를 직접 연결하면서 Kubernetes가 단순 배포 도구가 아니라 클라우드·네트워크·스토리지·GitOps를 엮는 플랫폼 조립 문제임이 드러났다.
2. 핵심 장애는 AWS CCM과 Argo CD 사이의 chicken-and-egg 문제였다. external cloud provider 설정 때문에 노드가 taint 상태로 등록되고, CCM이 provider ID를 붙여야 하지만, CCM 자체가 Argo CD를 통해 배포되도록 되어 있어 스케줄링 순서가 꼬였다.
3. target group에 인스턴스가 등록되지 않는 문제는 provider ID 누락과 연결되어 있었고, 이는 수동 patch로 덮을 문제가 아니라 CCM 같은 bootstrap dependency를 더 이른 단계에서 안정적으로 배치해야 하는 문제로 정리된다.
4. Valheim 서버는 인프라가 잘못되어서만 접속이 실패한 것이 아니라 서버 ready까지 약 15분이 걸린 것으로 보이며, 이후 실제 클라이언트 접속과 서버 로그 확인을 통해 Kubernetes 위에서 게임 서버가 동작하는 milestone에 도달했다.
5. 추가로 cats 웹서버를 배포해 Envoy Gateway, NLB, Argo CD 동기화, pod 생성, 외부 접속 흐름을 검증했고, Kubernetes를 self-service platform으로 만들려면 개발자가 YAML 세부사항을 직접 다루지 않게 하는 상위 추상화가 필요하다는 결론으로 이어졌다.

🧩 배경과 문제 정의

• Kubernetes를 인터넷 자료와 실습으로 직접 익히는 과정에서, 이전 세션을 보지 않은 시청자에게는 진입 장벽이 크다.
• 현재 실습 환경은 Valheim 게임 서버를 Kubernetes 위에 올리고, Argo CD, Envoy Gateway, AWS CCM, EBS CSI까지 연결하는 자체 운영형 클러스터다.
• 관리형 EKS가 아니라 control plane, worker, cloud provider 연동, ingress, storage를 직접 조립하는 방식이어서 복잡도와 학습 비용이 크게 드러난다.
• Kubernetes는 자체 플랫폼을 만들 때 의미가 커지지만, 일반적인 워크로드에는 Docker Compose나 EC2 여러 대만으로도 충분할 수 있다는 문제의식이 깔려 있다.

🕒 시간순 섹션별 상세정리

1. 스트림 설정 정정과 학습 범위 안내

• 마이크 작동 여부를 확인한 뒤 라이브가 시작되고, 초반에는 채팅 인사와 방송 상태 확인이 계속된다 [00:12]
• 라이브 제목이 part four로 보일 수 있어 part five로 다시 저장하려 하고, 반영되지 않으면 나중에 수정하기로 한다 [01:08]

2. 현재 클러스터에 올라간 주요 파드 구성

• 현재 상태를 거꾸로 추적하면서 Valheim pod가 게임 서버 역할을 맡는 핵심 워크로드로 놓인다 [03:44]
• AWS CCM, Argo CD, Envoy Gateway pod가 함께 존재해 클라우드 연동, 배포 자동화, 외부 트래픽 진입점까지 포함한 구조가 된다 [04:16]

3. 일주일간의 구축 난이도와 워커 노드 상태

• 홈 서버에 K3S를 올리는 것도 쉽지 않지만, 현재 방식은 그보다 더 복잡해 Docker run 방식도 충분히 이해 가능한 선택지가 된다 [05:30]
• 약 일주일 동안 시도해 pod 실행과 접근 단계까지 왔지만, 전체 스택을 삭제 후 재생성하자 정상 동작이 다시 흔들렸다 [05:46]

4. 컨트롤 플레인과 Kubernetes 복잡도 판단

• worker 영역과 별도로 control plane이 있으며, API server와 scheduler 같은 제어 구성요소가 클러스터 운영의 중심에 놓인다 [07:06]
• Kubernetes는 하드웨어를 추상화해 자체 플랫폼을 만들 때 의미가 크지만, 그런 목적이 없으면 많은 워크로드에는 과하게 복잡할 수 있다 [07:23]

5. Envoy Gateway, Argo CD, AWS 연동의 배치

• ingress가 빠진 것이 아니라 Envoy Gateway pod가 ingress controller 역할을 하며 외부 트래픽 경로를 구성한다 [08:58]
• Argo CD는 control plane 쪽에서 실행되고 GitHub의 선언적 구성을 가져오는 GitOps 축을 맡는다 [09:28]

6. EKS 없이 직접 조립하는 Kubernetes 운영 접근

• 이 구성은 EKS가 아니며, 관리형 Kubernetes 대신 Kubernetes 자체를 직접 관리하는 방식이다 [10:22]
• 관점은 EKS를 처음 만드는 사람에 가깝고, control plane, worker, cloud provider 연결을 직접 조립해야 한다 [10:29]

7. PVC, EBS, NLB로 그리는 클러스터 연결 구조

• PVC가 생성되고 다른 구성요소와 연결되며, 그 흐름 안에서 EBS 볼륨이 만들어지는 구조가 잡힌다 [12:20]
• NLB도 함께 생성되며, EBS 볼륨과 NLB는 모두 Amazon 인프라 조각으로 분리된다 [13:00]

8. 현재 클러스터 구성과 네트워크 구성요소의 위치

• Cilium이 네트워크 드라이버로 들어가 있지만, 아직 정확한 역할과 동작 방식은 파악되지 않은 상태다 [15:03]
• Kubernetes 쪽 구성요소와 외부 AWS 리소스를 만드는 CCM의 위치를 구분해 현재 아키텍처를 정리한다 [15:31]

9. AI 보조 FFmpeg 편집과 수동 편집의 역할 분리

• AI는 편집 앱 내부 기능이 아니라 FFmpeg 명령 생성이나 자동 처리 스크립트 구성에 쓰인다 [16:17]
• FFprobe는 영상의 duration, FPS, sample rate를 가져오고, 이 값들이 자동 편집 처리의 입력 데이터가 된다 [17:10]

10. 스택은 실행 중이지만 target group 등록 문제가 남아 있음

• 현재 스택과 pod들은 실행 중이지만, target group이 target을 등록하지 못하는 부분이 핵심 미해결 지점으로 남아 있다 [18:18]
• 실행 중인 pod 수가 작업 규모에 비해 많아 보이고, 실제 리소스 사용량을 확인할 필요가 생긴다 [18:37]

11. metrics 부재와 수동 provider ID patch의 문제

• kubectl top node로 노드 리소스를 보려 하지만 metrics가 없어 직접적인 사용량 확인이 막힌다 [21:07]
• Gemini가 EC2 관련 값을 수동으로 patch하려 했고, provider ID가 없는 노드를 bash script로 처리하려는 방향이 드러난다 [21:32]

12. Argo CD와 AWS CCM 사이의 chicken-and-egg deadlock

• Talos가 external cloud provider로 부팅하면 kubelet은 node를 no-schedule taint 상태로 등록하고, CCM이 provider ID를 붙이기 전까지 일반 workload 스케줄링이 막힌다 [22:41]
• CCM은 Argo CD로 배포되도록 구성되어 있지만, Argo CD도 일반 workload라 taint가 걸린 node 위에 스케줄링되지 못한다 [23:03]

13. CCM 의존성과 target group 등록 실패

• Provider ID가 빠져 있어 인스턴스가 target group의 target으로 나타나지 않았고, 이 값이 채워져야 Valheim 서버를 실제로 사용할 수 있다 [24:01]
• 올바른 구조에서는 CCM 같은 구성요소가 core bootstrap dependency로 취급되어 노드 ready 대기나 GitOps 도구 설치보다 먼저 배포되어야 한다 [24:22]

14. Kubernetes bootstrap 순서의 취약성과 의존성 표현 한계

• Kubernetes는 특정 구성요소를 올바른 순서로 세팅해야 작은 메타데이터 플래그가 설정되는 구조라, 순서를 모르면 장애 원인을 찾기 어렵다 [25:02]
• 전체 인상은 polished product라기보다 인프라 엔지니어들이 가능한 방식으로 구성요소를 이어 붙인 시스템에 가깝다 [25:50]

15. 스택 재생성과 Kubernetes 학습 방식

• 문제를 반영하려면 전체 stack을 destroy한 뒤 다시 만드는 방향이 필요하고, 이 작업은 시간이 걸릴 가능성이 크다 [27:58]
• EKS 없이 Kubernetes를 어떻게 구성할지 배우는 것이 핵심 질문이며, 관리형 서비스가 없을 때 무엇을 해야 하는지가 실습의 목적이다 [28:23]

16. 프로그래밍 학습과 문제 해결에 대한 조언

• 새 언어를 배울 때는 framework보다 vanilla language를 먼저 익히고, 그다음 framework로 넘어가는 순서가 낫다 [30:04]
• 해결책을 찾을 때는 GPT를 더 선호하며, GPT가 Stack Overflow를 학습했다는 점이 그 이유로 나온다 [30:33]

17. 대기 중 이어진 개발자 역량과 직무 선택 Q&A

• destroy operation이 진행되는 동안 할 수 있는 일이 많지 않아 질문 답변이 이어지고, stack 삭제 상태를 확인한다 [32:43]
• full stack developer를 목표로 한다면 DSA와 SQL은 둘 다 필요하며, 알고리즘과 데이터베이스 역량이 모두 요구된다 [33:36]

18. Kubernetes가 맞는 사용 사례와 DevOps 직군 변화

• Kubernetes는 많은 개발자가 각자의 애플리케이션을 매우 표준화된 방식으로 배포해야 하는 대규모 환경에서 의미가 커진다 [34:43]
• 단일 소규모 앱보다 여러 팀과 다수 애플리케이션이 공통 배포 방식을 공유해야 할 때 Kubernetes의 장점이 커진다 [34:50]

19. roadmap.sh 탐색과 역할별 로드맵 평가

• roadmap.sh에는 역할 기반 로드맵, 스킬 기반 로드맵, 프로젝트 아이디어, 베스트 프랙티스가 있어 학습 경로를 빠르게 훑을 수 있다 [36:13]
• Forward Deployed Engineer 로드맵은 초급 역할은 아니지만, 로드맵 자체는 초급에서 시작해 점진적으로 올라갈 수 있어 난이도 표기가 결정적 문제는 아니다 [36:57]

20. 커리어 진입과 학습 출발점에 대한 현실적 조언

• fresh grad가 기초는 있지만 실무 경험이 부족한 것은 자연스럽고, 기업의 graduate program이나 internship program 지원이 우선 경로가 된다 [39:13]
• 완전히 처음부터 시작한다는 가정은 현실과 맞지 않으며, 개인의 출발점은 게임, PC, 인터넷, 컴퓨터를 망가뜨린 경험 같은 누적된 호기심에서 생긴다 [39:49]

21. Kubernetes 실습 범위와 포트폴리오·역할 해석

• Kubernetes 학습의 실제 목표는 클러스터를 만들고 그 위에 game server pod를 올리는 것이며, 진행에 따라 추가 pod를 붙일 수 있다 [41:01]
• 인증서 생성과 서명은 직접 처리하지 않고 Talos와 부트스트래핑 과정에 맡겼으며, 초점은 저수준 인증서 관리보다 클러스터 구축 흐름에 있다 [41:16]

22. AWS 리소스 정리와 Pulumi 기반 재프로비저닝

• 인프라 삭제 작업은 계속 진행 중이며 실제로 리소스를 지우고 있어, 실패라기보다 대기와 정리 단계에 가깝다 [42:16]
• VPC 삭제 중 ENI가 사용 중이라는 오류가 나오지만 콘솔에서 관련 리소스가 보이지 않아, 클라우드 상태와 표시 사이의 불일치가 리스크로 남는다 [42:38]

23. 시스템 디자인과 백엔드 언어 선택

• C++ 경험이 있고 백엔드를 원한다면 Go가 자연스러운 다음 선택이며, 기존 언어 감각 때문에 진입이 비교적 쉽다 [44:39]
• 시스템 디자인은 코딩, 자료구조, 알고리즘만큼 중요하며, 가장 약한 영역을 우선 보완하는 방식이 학습 효율을 높인다 [44:57]

24. Rust 초반 난이도를 낮추는 우회 전략

• Rust는 초반에 압도적으로 느껴질 수 있고, async와 lifetime처럼 어려운 기능을 반드시 쓰는 프로그램은 초보자에게 부담이 크다 [45:43]
• 초반에는 async 대신 thread를 쓰고 lifetime 문제는 heap allocation으로 피하면서, 어려운 개념을 한꺼번에 마주치지 않는 방식이 좋다 [47:03]

25. 개발 언어와 인프라 커리어 선택의 현실

• 코딩 학습을 포기하고 AI에만 기대겠다는 태도는 좋지 않은 출발점이며, 직접 배우면서 막히는 지점을 파악하는 과정이 필요하다 [48:12]
• Cloudflare 같은 인프라 회사 진입에는 Rust 이해가 유리하고, Golang도 중요해서 둘 다 아는 쪽이 선택지가 넓어진다 [48:31]

26. 연봉 기준으로 본 역할과 언어의 격차

• Stack Overflow 개발자 설문 기준에서는 C-suite, VP, CTO 같은 임원급 역할이 가장 높은 보상 구간에 있다 [50:34]
• 미국과 인도 기준을 따로 봐도 엔지니어링 매니저 보상은 상위권이며, 단순 언어보다 역할과 책임 범위가 보상에 큰 영향을 준다 [50:53]

27. Pulumi 배포 완료와 클러스터 리소스 확인

• Pulumi 스택 생성이 진행 중이며, AWS 콘솔에는 컨트롤 플레인 초기화와 리소스 생성 상태가 확인된다 [52:37]
• 워커 노드가 실행 중이고, API 서버용 네트워크 로드밸런서가 컨트롤 플레인 앞단에 붙어 클러스터 접근 경로를 구성한다 [53:03]

28. kubeconfig·Talos 설정 복호화와 보안 처리

• kubeconfig와 Talos 설정은 암호화된 상태로 보관되어 있어 공개 환경에서 컨트롤 플레인 자격 증명이 노출되는 위험을 줄인다 [53:58]
• 자격 증명 복호화에는 PGP 작업이 필요해, 화면에 민감 정보가 보이지 않도록 데스크톱을 숨긴 뒤 수동으로 처리한다 [54:24]

29. 파드·로드밸런서 정상화와 Valheim 서버 접속 시도

• 보안 그룹에 현재 IP 접근 규칙을 추가한 뒤 kubectl 조회가 가능해지고, Valheim 서버와 Envoy Gateway pod들이 실행 중인 상태로 확인된다 [56:41]
• 클라우드 컨트롤러 매니저가 로드밸런서를 생성했고 대상 타깃도 붙어, Kubernetes 서비스가 AWS 로드밸런서와 연결된 상태에 도달한다 [57:06]

30. 접속 실패와 스트리밍 성능 병목

• 재시도 후에도 Valheim 서버 접속이 되지 않고, 정상이라면 빠르게 연결됐어야 하므로 단순 대기보다 구성 문제 가능성이 커진다 [58:20]
• 화면이 심하게 끊기며 스트림 품질 문제도 함께 발생하고, 여러 작업 동시 실행과 오래된 하드웨어가 성능 병목으로 작용한다 [58:52]

31. AWS EC2 기반 베어 Kubernetes 환경과 초기 전제

• 보안 그룹이 붙어 있지 않은 상태는 정상이며, 해당 리소스에는 security group이 연결될 필요가 없다고 본다 [1:00:02]
• Kubernetes는 로컬 머신이 아니라 Amazon 환경에서 실행되고, 이후 문제 해결도 EC2 기반 클러스터를 전제로 진행된다 [1:00:21]

32. 새 PC 사양과 Linux 중심 AMD 선택

• 새 PC는 AMD Ryzen 7 9800X3D, AMD RX 970XT, Gigabyte B850 보드, 32GB RAM 구성으로 잡혀 있다 [1:00:33]
• RAM 비용만 약 700달러 수준이라 전체 장비 비용 부담이 크지만, 로컬 모델 학습 목적은 아니다 [1:02:07]

33. 공개 sandbox와 작은 프로젝트부터 확장하는 학습 방식

• Kubernetes 작업은 단순 실험용 sandbox이면서 GitHub에 공개된 프로젝트라, 외부에서도 commit history와 build 상태를 확인할 수 있다 [1:04:09]
• 공개 저장소에는 진행 과정과 build 결과가 남아, Kubernetes를 배우는 과정 자체가 추적 가능한 실습 기록이 된다 [1:04:20]

34. GPU 벤치마크 비교와 업그레이드 판단

• GPU 선택은 벤치마크 비교로 판단할 수 있고, 카드 간 실제 성능 차이를 수치로 확인해야 합리적인 업그레이드 여부가 보인다 [1:06:28]
• RTX 3060 12GB는 가격 대비 괜찮지만, effective speed 기준에서는 2080 Super가 더 높아 60 라인업은 예산형 카드에 가깝다 [1:06:50]

35. AWS 비용 통제와 free tier 한계

• AWS에는 월 100달러 예산 설정이 걸려 있어, 실습 중 실수로 큰 비용이 발생하는 위험을 줄인다 [1:09:14]
• free tier를 벗어나 유료 사용으로 넘어가려면 monthly cost budget 같은 예산 설정이 필요해 비용 폭주를 막아야 한다 [1:09:47]

36. Valheim pod 상태 확인과 재시작 시도

• Gemini는 Valheim pod 문제를 찾으려 하지만, 핵심은 Kubernetes 안에서 Valheim 서버가 정상적으로 올라왔는지 확인하는 것이다 [1:10:43]
• Valheim server pod 로그를 조회하면서 default namespace의 서버 상태와 최근 실행 흐름을 확인한다 [1:10:59]

37. Valheim 클라이언트 접속과 서버 로그 검증

• 클라이언트 화면이 전체화면과 해상도 문제로 작고 불안정하지만, 720p로 낮추고 창 크기를 조정하며 접속을 계속 시도한다 [1:12:02]
• 게임 시작 후 ALB/NLB가 남아 있을 것으로 보고 접속을 진행하며, 비밀번호 입력 화면이 나타나 서버 접근 가능성이 높아진다 [1:13:25]

38. 원인은 설정 변경이 아니라 서버 준비 지연

• Gemini는 cluster 정보 읽기와 debug command 실행만 수행했고, UDP 도달 여부 확인용 network diagnostic script만 만들었으며 configuration 변경은 없었다 [1:14:34]
• 문제 해결은 외부 수정 때문이 아니라 Valheim 서버가 기동되고 ready 상태가 될 때까지 기다린 결과에 가깝다 [1:15:16]

39. 공개 서버 접속 가능성과 실시간 로그 추적

• Valheim 서버는 기술적으로 public 상태이며, 채팅 사용자가 주소를 찾으면 바로 접속할 수 있는 상태다 [1:16:30]
• 로그를 tail 형태로 열어두려는 시도가 이어지고, follow 옵션으로 접속 이벤트를 실시간으로 볼 수 있게 만든다 [1:16:43]

40. 리소스 상태, 비용, 리전 확인

• instrument metrics 확인은 즉시 다루기 어렵고, Cloudflare는 현재 구성에 포함되어 있지 않다 [1:17:51]
• CPU 사용량은 일시적으로 올라갔지만 과부하 수준은 아니며, credits를 일부 사용했지만 고갈되지는 않았다 [1:18:14]

41. 다음 실험으로 Envoy Gateway와 추가 파드 탐색

• Valheim 서버 구동은 milestone로 받아들여지고, 다음 단계로 단순한 web server 같은 다른 pod를 띄우는 방향을 검토한다 [1:18:48]
• Envoy Gateway 문서를 보며 Kubernetes Gateway API, route, path, filter, backend refs 구조를 확인하고 static response 가능성을 찾는다 [1:19:25]

42. 추가 탐색과 Kubernetes 저장소 개념 정리

• 다른 pod로 무엇을 실행할지 정하지 못한 상태에서 게임 개발자 계정과 외부 사례를 둘러보며 다음 실험 대상을 찾는다 [1:21:54]
• AI에게 바로 맡기지 않고 직접 판단하려는 흐름이 있으며, 자동화보다 Kubernetes 개념을 직접 이해하는 과정이 우선된다 [1:22:44]

43. Kubernetes 구성 검증 목표와 남은 배포 과제

• 현재 구성에는 Argo CD 기반 GitOps가 있고, 새 pod를 추가했을 때 실제로 동작하는 흐름을 확인하는 것이 직접적인 검증 목표다 [1:24:13]
• CCM은 AWS NLB와 target group 생성, target 등록까지 맡으며 외부 트래픽이 게임 서버로 들어오는 인프라 계층을 담당한다 [1:24:23]

44. Kubernetes 학습 경로: 공식 문서에서 kubeadm 자동화로

• Kubernetes를 거의 모르는 상태에서 kubernetes.io의 기본 문서를 읽으며 개념을 모으는 방식이 첫 출발점이 된다 [1:25:17]
• Kelsey Hightower의 Kubernetes the Hard Way를 따라가지만, certificate authority 단계에서 절차가 비효율적으로 느껴져 중단점이 생긴다 [1:25:53]

45. 로컬 실습, AWS 선택, LLM 답변의 한계

• 100k SWE 취업 질문에는 Claude가 일반적인 경로를 줄 수 있지만, 질문 자체는 기본 방향을 얻는 용도에 가깝다 [1:28:47]
• kind로 로컬 Kubernetes를 배우는 방식도 가능하지만, 노드당 2GB 메모리 요구를 보고 로컬 하드웨어 대신 AWS를 선택한다 [1:29:16]

46. 초보 개발자 진입 경로와 실습 중심 조건

• 무학위와 주 몇 시간 학습은 가장 느린 조합이며, 첫 단계는 언어 하나를 고르고 유지하는 일과 무료 자료 기반의 기본기 학습이다 [1:31:25]
• CRUD 앱, 포트폴리오, 오픈소스 기여, 실제 사용자가 있는 live project는 경력 없는 지원자가 증명 가능한 결과물을 만드는 핵심 재료다 [1:31:37]

47. Kubernetes 게임 서버 확인과 스트리밍 부하

• Valheim 서버는 Kubernetes 위에서 돌고 있고 client는 로컬 컴퓨터에서 실행되며, 실제 게임 접속으로 클러스터 워크로드 동작을 확인한다 [1:32:38]
• 작은 게임 화면도 encoder를 압박할 만큼 부하를 만들고, Kubernetes 실습보다 로컬 스트리밍 환경이 병목으로 드러난다 [1:32:50]

48. 태도 리스크, 라이브 조작 경계, 추가 pod 검증 목표

• 기본 학습 과정이 지루하게 느껴진다면 SWE 진입 가능성이 낮아지고, 원하는 결과에는 반복 실습을 견디는 태도가 필요하다 [1:33:28]
• 스트림 지연이 커지고, kubectl command 실행과 원치 않는 commit 여부를 즉시 경계할 만큼 라이브 환경 조작 리스크가 존재한다 [1:34:37]

49. cat 서비스 매니페스트와 정적 Nginx 앱 구성

• cat 서비스는 port 80, Gateway, HTTPRoute, cat-gateway, cat deployment로 구성되며, 외부 요청이 Kubernetes 리소스 체인을 따라 웹서버까지 도달하는지 확인하는 실습 단위가 된다 [1:36:25]
• Kubernetes 학습은 목표했던 범위에 가까워지고 있으며, 이후에는 Go 프로젝트 같은 다음 작업으로 넘어갈 가능성이 있다 [1:37:32]

50. Envoy Gateway, NLB, Argo CD 동기화 흐름

• Envoy Gateway가 NLB를 생성하고, NLB가 외부 트래픽을 동적으로 할당된 node port로 라우팅하므로 별도 AWS security group rule 추가가 필요하지 않다 [1:39:18]
• cat pod가 생성되어야 하는 상태가 되었고, 클러스터 안에서 배포 리소스가 실제 pod로 이어지는지 기다리는 단계로 넘어간다 [1:39:42]

51. Kubernetes 필요성, cats web server 생성, NLB 프로비저닝

• Kubernetes는 해당 분야에서 거의 모두가 사용하기 때문에 학습 대상이 되며, 조직에 적합한 선택인지와 별개로 실무 노출 가능성이 크다 [1:41:22]
• Git polling 주기가 3분이라는 점은 느리게 느껴지고, 배포 자동화가 있어도 실제 반영까지 기다리는 시간이 운영 경험에 영향을 준다 [1:41:39]

52. 비용 관리와 cat 서버 접속 검증

• EC2 비용 기준으로 대략 50달러 수준의 지출 가능성이 있으며, 월간 예산을 두고 사용 후 리소스를 삭제하는 방식으로 비용 리스크를 관리한다 [1:42:33]
• Kubernetes 학습 이후에는 XDS part 2 같은 후속 주제가 이어질 수 있고, 현재 실습이 다음 콘텐츠와 프로젝트의 전환점 역할을 한다 [1:43:45]

53. cats 서비스 성공 확인과 커뮤니티 반응

• cats 페이지가 열리면서 cat 웹서버가 Kubernetes 위에서 실제로 동작하는 상태가 확인된다 [1:45:12]
• gift membership 10개가 추가되며 커뮤니티 지원이 크게 늘고, 특정 후원자가 멤버십 대부분을 떠받치는 상황이 된다 [1:45:32]

54. cat 사이트 부하 유도와 네트워크 관찰

• cat 사이트를 반복해서 요청하면 네트워크 트래픽이 보이는지 확인할 수 있고, 실제 외부 요청이 어느 worker로 들어가는지가 다음 관찰 대상이 된다 [1:46:49]
• 시청자들에게 cat 사이트 접속을 요청하면서 간단한 부하를 만들고, cats 서비스가 트래픽 증가를 어떻게 받는지 실시간으로 확인하려 한다 [1:47:21]

55. 공개 접속 부하와 로그로 확인한 서비스 상태

• 외부 접속에서 rate limit 의심과 도달 실패가 섞여 나타나며, 같은 서비스라도 관측 위치에 따라 정상처럼 보이거나 접근 불가처럼 보인다 [1:49:02]
• 서비스는 작은 EC2 위의 단일 pod로 동작하고 있어, 공개 데모 트래픽이 몰리면 병목이나 응답 불안정이 생길 가능성이 있다 [1:49:10]

56. 당일 Kubernetes 실습에서 남은 문제와 해결된 작업

• secret sub-router는 아직 없지만, Cloud Controller Manager가 Argo로 provision되면서 provider ID가 설정되지 않는 race condition이 핵심 문제로 남았다 [1:51:01]
• Valheim 서버는 실제 boot에 약 15분이 걸렸고, 이 지연이 Valheim 자체 특성인지 인프라 문제인지는 확정하기 어렵다 [1:51:27]

57. 다음 Kubernetes 학습 과제와 self-service platform 방향

• 다음 실험 후보에는 KubeSpray와 Cluster API가 포함되며, 클러스터 구축 도구와 Cluster API의 역할을 비교할 필요가 있다 [1:52:28]
• 현재 구성 대부분은 Gemini 도움을 받은 코드라서, 전체 code review가 필요하고 생성된 YAML과 인프라 코드의 신뢰성 점검이 다음 리스크다 [1:52:37]

58. 운영 질문과 커뮤니티 관련 후속 작업

• PVC/PV mount는 이미 Valheim 게임 서버가 사용하는 방식이며, persistent volume 구성이 stateful workload 유지에 실제로 쓰이고 있다 [1:54:25]
• Discord 서버는 이미 있지만 설정을 다듬는 중이고, 준비가 끝나면 YouTube short와 채널 링크를 통해 참여 경로가 열린다 [1:54:37]

59. control plane 후속 주제와 마무리 일정

• 여러 CI build가 동시에 rendered file을 같은 application으로 push하는 상황은 control plane 추상화와 연결된 concurrency 문제로 이어질 수 있다 [1:55:46]
• Pulumi는 Terraform과 매우 유사하고, IaC 선택지는 Kubernetes 주변 자동화와 같은 문제 공간을 공유한다 [1:56:05]

🧾 결론

• 이 영상의 핵심은 “Kubernetes를 배웠다”보다 “Kubernetes를 직접 운영하려면 어떤 순서와 의존성을 이해해야 하는가”에 가깝다. control plane, worker, cloud provider, ingress/gateway, storage, GitOps가 모두 맞물려야 실제 워크로드가 외부에서 접근 가능해진다.
• Kubernetes는 많은 개발자가 여러 애플리케이션을 표준화된 방식으로 배포해야 하는 환경에서는 강력하지만, 단일 앱이나 작은 워크로드에는 Docker Compose, EC2 여러 대, 관리형 서비스가 더 단순한 선택일 수 있다.
• self-managed Kubernetes는 학습 효과가 크지만, 관리형 Kubernetes가 대신 처리해 주는 bootstrap, provider ID, load balancer target registration, storage provisioning, 보안 설정, 비용 관리까지 직접 책임져야 한다.
• 이번 실습에서는 Valheim 서버와 cats 웹서버가 실제로 동작하면서 큰 milestone은 달성했지만, AWS CCM race condition, secrets operator, 생성된 YAML·인프라 코드 리뷰, Argo polling 속도 같은 후속 과제가 남았다.
• 검증이 필요한 지점도 분명하다. Cilium의 정확한 역할, Valheim 서버 ready 지연이 애플리케이션 특성인지 인프라 구성 영향인지, Gemini 도움으로 작성된 Kubernetes·Pulumi 코드가 운영 관점에서 안전한지는 추가 확인이 필요하다.

📈 투자·시사 포인트

• 인프라 투자 관점에서 self-managed Kubernetes는 “클라우드 비용”보다 “운영 복잡도와 학습 시간”이 더 큰 비용으로 나타난다. 영상에서도 약 15호주달러 수준의 누적 비용과 월 100달러 예산 설정이 언급되지만, 실제 병목은 구성 순서와 디버깅 시간이었다.
• 조직이 Kubernetes를 도입할 때는 기술 자체보다 사용 사례가 먼저다. 여러 팀이 공통 배포 방식을 필요로 하고, platform engineering 또는 self-service deployment가 목표라면 가치가 커지지만, 단순 워크로드에는 과투자가 될 수 있다.
• GitOps, Gateway API, CCM, CSI 같은 구성요소는 각각 유용하지만, bootstrap dependency를 잘못 배치하면 자동화가 오히려 장애를 고착시킬 수 있다. 자동화 도입 전 “무엇이 먼저 떠야 하는가”를 명확히 모델링해야 한다.
• 비용 관리는 Kubernetes 학습에서도 필수다. EC2, NLB, EBS 같은 리소스가 반복 생성되므로 예산 알림, destroy/recreate 검증, 사용 후 정리 절차가 실습의 일부가 되어야 한다.
• 커리어 관점에서는 Kubernetes 자체보다 이를 통해 드러나는 platform engineering 역량이 중요하다. 클러스터를 만들고, 워크로드를 배포하고, 장애 원인을 좁히고, 개발자에게 더 단순한 배포 인터페이스를 제공하는 능력이 실무 가치로 이어진다.

⚠️ 불확실하거나 확인이 필요한 부분

• Cilium이 클러스터 네트워크에서 정확히 어떤 역할을 맡고 있는지는 방송 중에도 아직 명확히 파악되지 않은 상태로 남았다.
• Valheim 서버가 준비되기까지 약 15분이 걸린 원인이 Valheim 자체의 부팅 특성인지, Kubernetes·스토리지·네트워크 구성 지연 때문인지는 확정되지 않았다.
• 외부 로드밸런서가 실제로 NLB인지, 일부 구간에서 언급된 ALB 표현이 단순 말실수인지 AWS 리소스 기준으로 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• AWS CCM을 core bootstrap dependency로 분리해 Argo CD보다 먼저 배포되는 구조를 검토한다.
• 새로 생성한 클러스터에서 provider ID가 수동 patch 없이 자동으로 설정되는지 확인한다.
• target group에 worker node 또는 적절한 target이 자동 등록되는지 재현 테스트한다.
• 수동 untaint, bash 기반 provider ID patch 같은 임시 절차를 제거하거나 명확히 위험한 workaround로 문서화한다.

❓ 열린 질문

• self-managed Kubernetes에서 AWS CCM은 Talos 부트스트랩 단계에 포함해야 하는가, 아니면 Argo CD와 별도 bootstrap job으로 관리하는 편이 나은가?
• Argo CD 자체가 일반 workload로 스케줄링되는 구조에서, taint가 걸린 초기 노드에 GitOps 도구를 안전하게 올리는 표준 패턴은 무엇인가?
• Valheim 서버의 긴 준비 시간을 Kubernetes readiness/startup probe로 표현할 수 있는가, 아니면 게임 서버 특화 health check가 필요한가?