Kubernetes를 배우기 시작하는 사람은 첫 주부터 플랫폼의 모든 구성 요소와 선택지를 이해하려고 애쓸 필요가 없다. Portainer.io의 Joep Piscaer가 제시하는 결론은 이와 같다. VMware 아키텍트로 일했던 이전 경험과, 개발자와 IT 담당자들이 컨테이너 기반 환경으로 전환할 때 같은 질문에 직면한다는 관찰을 바탕으로 한 것이다. 실제로 학습은 어디서 시작해야 하는가?
저자는 일반적인 학습 경로가 항상 적절한 출발점을 제공하지는 않는다고 본다. Kubernetes 문서는 방대하고, 유료 강좌는 같은 문서를 다시 제시하는 경우가 있으며, 자격증 학습 경로는 빠르게 깊어지거나 기본 개념에 대한 연결된 이해를 형성하지 않은 채 긴 리소스 목록을 제시할 수 있다. 따라서 저자는 플랫폼의 수많은 세부 사항으로 넘어가기 전에 플랫폼의 동작을 설명하는 제한된 개념 집합, 즉 자신이 ‘정신적 비계’라고 부르는 것부터 시작할 것을 제안한다.
원하는 상태 메커니즘부터 시작하라
첫 번째 개념은 원하는 상태와 조정이다. Kubernetes에서는 컨테이너를 실행하라는 명령을 내리는 데 그치지 않는다. 사용자는 특정 상태가 존재해야 한다고 선언하고, 플랫폼은 그 선언과 실제 상태를 계속 비교하며 둘 사이의 차이를 수정한다. 저자에 따르면 자동 복구, 확장, 점진적 배포와 같은 기능은 원하는 상태나 그 상태를 변경하는 방식은 서로 다르지만 모두 같은 메커니즘에 속한다.
이 개념은 교육적이면서 실무적으로도 중요하다. 학습자는 각 기능을 별개의 기능으로 암기하는 대신 Kubernetes의 동작을 하나의 메커니즘을 다양하게 적용한 것으로 볼 수 있다. 저자는 이러한 이해가 없으면 플랫폼의 나머지 부분이 암기해야 하는 서로 분리된 긴 기능 목록처럼 보인다고 강조한다.
노드 모델의 차이를 이해하라
두 번째 축은 제어 플레인과 작업 노드의 분리, 그리고 노드가 ‘교체 가능하다’는 의미를 이해하는 것이다. 저자는 이를 VMware의 전통적인 경험과 비교한다. 이 경우 팀은 장애가 난 ESXi 호스트를 수리하거나, 해당 호스트에서 워크로드를 이동하거나, 업그레이드한 뒤 다시 서비스에 투입할 수 있다.
반면 Kubernetes에서는 노드가 장애를 일으켰을 때 시스템이 반드시 그 노드 자체를 구해야 한다고 가정하지 않는다. 어떤 정상 노드든 어떤 워크로드든 실행할 수 있으므로, 시스템은 특정 하드웨어를 보호하기보다 문제가 발생한 노드를 우회하고 교체하도록 설계되었다. Piscaer는 전통적인 인프라 관리 습관을 이 모델에 그대로 적용하면, 플랫폼이 필요할 때 원래 포기하도록 설계한 구성 요소를 팀이 보호하게 될 수 있다고 지적한다.
네트워크에서 문제의 계층을 특정하라
저자는 네트워크를 네 개의 연속된 계층으로 살펴볼 것을 제안한다. 컨테이너에서 파드(pod)로, 파드에서 서비스로, 서비스에서 인그레스(ingress) 게이트웨이로, 그리고 인그레스 게이트웨이에서 외부 세계로 이어지는 계층이다.
이 관점에 따르면 네트워크를 진단할 때 팀이 문제가 발생한 계층을 특정하지 않기 때문에 혼란의 상당 부분이 생긴다. 파드의 IP 주소는 존재하지만 변경될 수 있는 반면, 서비스의 IP 주소는 가상이며 안정적이고, 그 주소에서 직접 수신 대기하는 프로세스가 반드시 존재하는 것도 아니다. 어느 계층을 검사해야 하는지 알면 추가적인 진단 명령을 실행하기 전에 상당한 모호함을 제거할 수 있다.
requests와 limits를 운영상의 경계로 다뤄라
출처는 리소스 요청(requests)과 제한(limits)을 단순한 권고 값이 아니라 운영 워크로드의 생존을 위한 계약으로 설명한다. 스케줄러는 request 값을 사용해 워크로드를 실행하기에 적합한 위치를 결정하고, limit는 워크로드가 초과해서는 안 되는 상한을 나타낸다.
리소스를 과도하게 선언하면 용량이 낭비될 수 있고, 반대로 너무 적게 선언하면 노드의 여유 공간이 소진되는 중요한 시점에 파드가 축출될 수 있다. 저자는 이 오류를 테스트 환경에서는 작동하다가 프로덕션에서 무너지는 워크로드와 연결하며, 문제가 애플리케이션 코드가 아니라 리소스 사양에 있을 수 있다고 설명한다.
CNI와 CSI 애드온은 왜 존재하는가?
다섯 번째 축은 네트워크와 스토리지를 Kubernetes 내부의 단일 구현으로 포함하는 대신 CNI와 CSI 같은 애드온에 맡긴 이유를 이해하는 것이다. 출처는 플랫폼이 계약을 정의하지만 구현은 애드온에 맡긴다고 설명한다. 엣지 환경의 소규모 클러스터가 필요로 하는 것과 규제를 받는 멀티 리전 환경이 필요로 하는 것은 근본적으로 다르기 때문이다.
이는 도구와 선택지의 생태계가 넓은 이유를 설명한다. 네트워크 선택지가 여러 개 존재하는 것은 반드시 우연한 혼란의 결과가 아니라, 모든 환경에 하나의 설계를 강요하기보다 유연성을 선택한 직접적인 결과다. 그렇다고 애드온 선택이 쉬워졌다는 뜻은 아니지만, 선택지가 많은 이유를 올바른 맥락에서 이해할 수 있게 해준다.
학습자에게 실질적으로 무엇이 달라지는가?
제안된 방법론은 GitOps, 모니터링, 서비스 네트워크, 정책 엔진과 같은 주제를 없애는 것이 아니라, 학습자가 해당 주제를 의미 있게 만드는 문제에 직면할 때까지 미루는 것이다. 기본 메커니즘, 제어 플레인과 노드의 구조, 네트워크 경로, 리소스 한계를 이해한 뒤에는 전체 ‘지도’를 다루려는 시도가 아니라 구체적인 실무 질문을 바탕으로 이러한 주제로 넘어갈 수 있다.
이는 교육적인 해석이지, 자격증 취득을 위한 공식 경로이거나 전문 문서를 대체하는 방법은 아니다. 또한 출처는 설정 단계나 실행 명령을 제공하지 않고 초기 이해를 구축하기 위한 틀을 제공한다. 글의 마지막에서 저자는 kubeschool.portainer.io에 있는 무료 교육 리소스를 소개하며, 이를 공급업체에 중립적인 자료라고 설명한다. 그러나 이 리소스는 저자가 속한 기관과 연결되어 있으므로, 여기에서는 독립적으로 검증된 참고 자료가 아니라 출처가 제안한 리소스로 보아야 한다.