iPhone에서 기대 Pod 수를 바꾸면 reconciliation 시뮬레이터가 이상하게 폭주함
그래도 사이트는 멋짐

전체를 다 읽었고 내용이 좋음 Gateway를 더 확장하고, 가능하면 CRD도 언급하면 좋겠음

멋진 사이트임
대부분의 사람들이 k8s에 대해 잘못 이해해서 학습을 불필요하게 어렵게 만드는 것 하나를 꼽자면 무엇일까?

멋짐. 예전에 Kubernetes 교육 콘텐츠를 만들었던 입장에서, 이런 걸 만들고 싶은 매력이 분명히 보임
기억하기로는 처음엔 Katacoda를 썼고 이후 비슷한 다른 플랫폼을 썼는데, 각 사용자에게 특정 설정이 된 새 인스턴스를 즉석에서 띄워줘서 매우 유용했음
다만 지금은 개념이나 아키텍처 교육에 더 잘 맞아 보임. 진짜 재미는 kubectl을 능숙하게 다루기 시작할 때부터임

예전 직장에서라면 컨트롤 플레인이 어떻게 동작하는지 설명하는 다이어그램, 성능 저하와 장애 모드, k8s에 배포하는 여러 아키텍처나 방식 비교에 정말 좋았을 것 같음

아쉽게도 Katacoda는 유료 장벽 뒤로 들어갔음. 왜 그렇게 했는지는 완전히 이해함. 이런 것들은 비용이 드니까
비슷한 다른 플랫폼들도 비용을 대줄 사람이 없어져 사라진 것 같고, 안타까움
이게 대안이 되길 바람. 현실과 달라져 낡아질 위험은 있지만, 그래도 핵심은 거의 항상 유효할 것임

우선 정말 멋짐
이게 LLM 보조 엔지니어링을 바라보는 올바른 방식처럼 느껴짐. AI는 놀랄 만큼 많은 코드를 생성할 수 있지만, 실제 가치는 리뷰 규율과 그 주변의 테스트에 있음
브라우저에서 Kubernetes를 다루는 각도도 멋지지만, 더 흥미로운 건 워크플로, 특히 “그럴듯해 보인다”를 믿는 대신 k8s에 대해 동작을 테스트하는 부분임. 이미 얼마나 많은 팀이 AI가 작성한 코드에 대해 이 정도 검증을 하고 있을지 궁금하고, 앞으로 몇 년간 모두가 가게 될 방향일 수도 있음

이건 말 그대로 맞춰 구현할 명세가 있는 특수한 경우임
안타깝게도 모든 코딩 작업이 그런 기회를 갖는 건 아님

진짜로 꽤 멋짐
추가 복잡도나 성능 손실에는 어느 정도 정당화가 필요하겠지만, 일부 사용 사례에서는 충분히 보상받을 수 있어 보임

kube 복잡도에 대한 농담들이 나오기 전에 말하자면, kube 같은 것은 kube가 의도한 작업들을 수행하기 위해 필요한 수준의 복잡도라는 흥미로운 논리가 가능해 보임
Fred Brooks의 본질적 복잡도와 우발적 복잡도 구분과 비슷함
물론 더 단순하게 할 수 있는 일에 kube를 쓰면, kube는 빠르게 우발적 복잡도가 됨

실제로 브라우저에서 컨테이너를 실행하는 건 아닌 것 같음. 모든 서비스에 커스텀 커넥터가 필요해 보이고, 더 중요하게는…

…렌더러도 필요하지 않나? 그렇지 않으면 “브라우저로 포팅됐다”는 게 무슨 뜻인지 모르겠음
비유하자면 누군가 DOOM을 브라우저로 포팅했다면 이제 브라우저에서 플레이할 수 있다는 뜻임. 하지만 탭에 보이는 데이터베이스들을 실제로 브라우저에서 실행할 수 있는 건 아니지 않나?
ruby2d를 띄우면 갑자기 클라이언트 쪽 Ruby 지원이 생긴다고 말할 수는 없음. 브라우저 탭에서 실제로 돌아가게 하려면 온갖 커스텀 작업이 필요함
반면 일반적인 백엔드 컨테이너 서비스는 정말로 여기저기로 옮겨 어디서든 실행할 수 있음
그래서 요점을 잘 모르겠고, 내가 틀렸다면 바로잡아 달라. 주장하는 바 자체와도 맞지 않아 보임

그 지점들은 제목에는 없지만 본문에서 다뤄짐
실제 컨테이너 이미지를 실행하는 건 아님. “시뮬레이션된 Kubernetes”라고 부르는 편이 더 나을 수도 있음
포팅된 것은 컨트롤 플레인임. 스케줄러, kube-proxy, deployment controller 등이 실제 Go 소스에서 옮겨졌고, 같은 클라이언트 API를 써서 k3s와의 동작 일치성을 테스트함. “렌더링”은 Pod 간 요청을 움직이는 점으로 시각화하는 데모 앱임