쿠버네티스는 반쯤 비어 있는 유리잔일까요, 아니면 반쯤 가득 찬 유리잔일까요? 글쎄요, 어떻게 보느냐에 따라 다릅니다! 오케스트레이션 기능의 메커니즘은 (제 생각에는) 다소 복잡하며, 경험이 많은 실무자라 하더라도 이 때문에 벽에 머리를 부딪히는 경우가 드물지 않습니다. 하지만 저는 초보 사용자나 기술 부채에 대한 수용 능력이 더 제한적인 비즈니스 사례에서도 더 열심히 일하는 것이 아니라 더 스마트하게 일하기 위한 목적으로 이 방법을 자주 추천해 왔습니다. 저는 프리랜서로 두 번째 아르바이트를 하며 소규모 비영리 단체의 시스템을 유지 관리하고 있습니다. 그래서 하루 8시간 동안 아이를 돌볼 시간이 없을 때, 무거운 일은 K8에게 더 많이 떠넘길수록 우리 모두의 삶이 더 나아질 수 있습니다. 더 좋은 점은 대기업에서 일하면서 하루 8시간의 보수를 받고 아이를 돌보는 경우에도 대부분의 업무를 K8의 힘을 빌려서 처리할 수 있다는 것입니다. K8을 여러분의 삶을 더 편하게 만들어주는 조력자라고 생각하면 유리알이 반쯤 꽉 찬 관점입니다. 원하는 것을 선언하고 가장 잘 할 수 있는 일을 맡기세요.
이러한 접근 방식이 지나치게 단순해 보일 수 있으므로, 일을 지나치게 복잡하게 만드는 경향에 대해서도 지적하겠습니다. 예를 들어, 아직 출시되지도 않은 '미래 보장형' 솔루션을 과도하게 엔지니어링하거나 이미 해당 작업에 맞게 설계된 검증된 툴을 사용하지 않고 처음부터 다시 개발하는 경우가 이에 해당합니다. 플랫폼 엔지니어링도 예외는 아니지만, 이에 대해서는 다음 글에서 자세히 살펴보겠습니다.
K8은 강력하고 복잡한 유기체이지만, 많은 업계 동료들이 "그냥 작동하는" 것을 만들기 위해 많은 시간을 쏟아부었다는 것을 기억하세요. 자동차 운전을 배우는 것처럼, 가장 좋은 학습 방법은 직접 해보는 것입니다.
저는 2019년에 Linode 고객 지원팀의 최전선에서 Linode Kubernetes Engine(LKE)을 출시하면서 Kubernetes를 처음 접하게 되었습니다. 사용자 수요가 너무 엄청났기 때문에 피할 수 없는 선택의 순간이었습니다. 이 제품을 지원해야 했기 때문에 우리는 이 제품을 배워야 했고, 더 나아가 문제를 해결해야 했습니다! 때때로 좌절감을 느끼기도 했지만 제 커리어에서 가장 소중한 경험이었습니다.
이 글에서는 저와 같은 실제 경험을 바탕으로 Kubernetes를 학습하고 관리하는 몇 가지 전략을 살펴보겠습니다.
실습을 통한 학습
플랫폼을 진정으로 이해하는 가장 좋은 방법은 플랫폼을 구축하고 깨는 해보는 것입니다. 문서와 튜토리얼을 결합하면 작동하는 클러스터를 손에 넣을 수 있는 좋은 방법입니다. 매니페스트를 Git 리포지토리에 저장하면 영원히 참조할 수 있는 템플릿을 갖게 됩니다. 그런 다음, 템플릿을 깨는 흥미로운 방법을 찾아보세요. 진단을 시작하기 전까지는 문제의 원인을 알 수 없도록 친구나 동료가 한 번 찔러보게 하는 방법도 있습니다. 또는 제가 사용한 또 다른 방법은 가이드에 설명된 것보다 더 복잡한 작업을 수행하는 것입니다. 예를 들어 Linux 재단에서 제공하는 CKAD 과정을 수강한다고 가정해 보세요. 단일 컨트롤 플레인과 하나의 작업자 노드만 있는 간단한 클러스터를 구축하도록 안내할 수 있습니다. 대신 고가용성을 위해 3개의 제어 플레인 노드와 3개의 작업자 노드로 클러스터를 성공적으로 부트스트랩해 보세요. 이것이 충분히 어렵다면 VPC를 구현하고 클러스터 네트워크 주소 지정을 사용자 지정하여 IP 공간에서 충돌을 방지하세요. 시간이 지나 좌절하고 포기하더라도 그렇지 않았을 때보다 훨씬 더 많은 것을 배울 수 있을 것입니다. 이는 제 경험에서 나온 두 가지 예일 뿐입니다. 하늘은 한계가 없습니다.
또한 클라우드의 모든 것을 건드리기 전에 미니큐브나 Kind와 같은 도구는 현지화된 실험에 매우 유용할 수 있습니다. 클러스터를 깨고, 문제를 해결하고, 고치는 방법에 관계없이 문서 흔적을 남기세요. 문서로 작성하는 행위는 단계와 해결 방법을 명확하게 설명해야 하기 때문에 기억에 도움이 됩니다. 이를 공개할 시간이 있다면 자신의 뛰어난 문제 해결 방법론을 뽐낼 수 있을 뿐만 아니라 동료들에게도 도움을 줄 수 있습니다.
학습 경로로서의 문제 해결
문제 해결 방법론이라는 주제에서 '모범 사례' 자체는 없으며, 자신에게 가장 잘 맞는 가려운 곳을 찾아야 한다는 의미의 '나만의 사례'가 있을 뿐입니다. 중요한 것은 스스로 이 근육을 키우려는 의도를 가지고 노력하면 시간이 지날수록 더 쉬워진다는 것입니다. 제가 만난 최고의 문제 해결사들은 수년간의 노력을 통해 최고가 되었고, 그 결과 어떤 문제도 해결할 수 있게 되었습니다. 결과적으로 그들은 가장 잘 배우는 사람이기도 합니다.
다음은 저에게 가장 효과적인 몇 가지 기술입니다:
- 나누고 정복하기: 문제를 절반으로 줄이고 잠재적인 원인을 체계적으로 제거하세요. 어떤 사람들에게는 체계적으로 스택을 쌓아 올리는 것이 더 쉽지만, 저는 일반적으로 먼저 배제할 수 있는 것부터 바로 뛰어넘는 것이 성공적이라고 생각합니다. 다른 사람들의 충고를 무시하는 건가요? 그럴 수도 있죠! 하지만 저는 저에게 맞는 것이 무엇인지 더 중요하게 생각합니다.
- Monitoring 관찰 가능성은 여러분의 친구이며 오류도 마찬가지입니다: 메트릭, 로그, 추적은 시스템에 대한 전체적인 관점, 더 나아가 문제에 대한 전체적인 관점을 그려줄 수 있습니다! Prometheus Grafana 사실상 모니터링을 위한 도구이며 로그 집계 및 추적 도구 선택에 있어 좋은 징조입니다. 그러나 현실에서는 항상 완전한 통합 가시성 스택을 사용할 수 있는 것은 아니며, 스크래핑할 원격 대상이 몇 개 있는 Prometheus Grafana 최선일 때도 있습니다. 다행히도, 이러한 스택이 있든 없든 오류 메시지를 친구처럼 대하면 많은 경우에 큰 도움이 됩니다! 물론 일부는 다른 것보다 더 도움이 되기도 하지만, 그럼에도 불구하고 이것은 무언가 잘못되었다는 정보가 담긴 시스템의 피드백입니다.
- 문제 재현하기: 가능한 한 별도의 환경에서 문제를 재현하세요. 이렇게 하면 원인에 대한 풍부한 정보를 얻을 수 있어 해결책을 찾는 데 도움이 됩니다. 또한 안전하게 실험할 수 있는 테스트 환경이 마련된다는 의미이기도 합니다. 필요에 따라 이 환경을 빠르게 다시 만들거나 파괴할 수 있다는 점도 IaC(인프라스트럭처를 코드로 구현)를 활용하는 것이 좋은 이유 중 하나입니다. 직접 작성해야 하는 경우라도 이전에 환경을 코드화하지 않은 상황에서는 이 작업에 조금만 더 시간을 투자하면 나중에 시간을 크게 절약할 수 있습니다.
- 문제 해결 로그를 보관하세요: 아키텍처 결정 기록/로그의 개념에 익숙하실 것입니다. 비슷한 개념을 문제 해결에 적용하는 것을 막을 수 있는 것은 무엇일까요? 아무것도 없습니다! 그리고 특별한 형식이나 규칙이 필요하지 않습니다. 그저 문제 해결 단계를 수행하면서 기록하기만 하면 됩니다. 이미 배제했던 사항을 역추적하거나 재확인해야 할 때 유용하게 사용할 수 있습니다. 가장 좋은 방법은 나중에 검토하여 해결책을 문서화하고 어떻게 해결책을 찾았는지 설명하는 것입니다. 단계와 논리를 명확하게 설명할 수 있으면 기억에 더 영구적인 흔적을 남길 수 있습니다. 또한 문서를 읽는 모든 사람에게도 유용할 것입니다. 이 문서는 내부 지식창고 플랫폼이나 다른 사람들을 가르치기 위한 공개 블로그에 올리는 것이 좋습니다.
특히 어려운 문제에 직면했을 때 문제 해결을 학습의 기회로 삼으면 문제 해결 능력이 장기적으로 향상되고 인프라 관리 방식을 개선하는 데 도움이 될 수 있습니다. 디버깅 프로세스를 개선하고 반복하는 팀은 Kubernetes의 강력한 기능을 더 잘 활용할 수 있게 됩니다.
간단하고 안정적인 기술 사용
클라우드 네이티브 에코시스템(및 전반적인 클라우드 환경)은 서로 연결할 수 있는 수많은 도구와 프레임워크를 제공합니다. 구축할 수 있는 것의 가능성은 거의 무한에 가깝습니다! 그러나 이러한 개념은 종종 너무 많은 도구, 너무 많은 복잡성, 너무 많은 기술 부채와 같은 몇 가지 주요 함정으로 이어질 수 있습니다. 다행히도 이러한 함정은 약간의 절제와 ' 적은 것이 더 많다'는 마음가짐만 있으면 쉽게 피할 수 있습니다. 최고의 기술은 가장 유지 관리하기 쉽고 가장 안정적인 기술이며, 사용자들도 이에 동의하는 경향이 있습니다. 사다리를 타고 집 옥상에 올라가야 한다면 제대로 사용하고 있는지 의심스러울 정도로 과도하게 설계된 사다리는 원하지 않을 것입니다. 정말 무섭겠죠!
아무도 읽을 수 없을 정도로 복잡한 코드 베이스를 유지하는 데 자부심은 없습니다. 아무도 사용할 수 없을 정도로 복잡한 시스템을 구축하는 데 금메달이나 트로피는 없습니다. 우리가 원하는 것은 작동하고, 안정적이며, 더 많은 수고를 들이지 않고도 안정적으로 올바르게 사용할 수 있는 것입니다. 여기서 단순함은 여러분의 친구입니다. 또한 클라우드 네이티브 디자인 패턴은 빠른 변화를 수용하는 패턴이라는 점을 기억하세요. 애플리케이션 아키텍처는 시간이 지남에 따라 자연스럽게 발전하면서 복잡해질 것이므로 억지로 복잡하게 만들 필요가 없습니다. 모듈식 클라우드 네이티브 설계와 더불어 최소한의 접근 방식을 통해 팀은 더 간결하고 안전한 시스템을 구축하고 배포, 유지 관리 및 문제 해결을 간소화할 수 있습니다.
또한, 단순하게 유지하면 잘못된 구성으로 인해 성능이 저하되거나 보안 결함에 대한 공격 표면이 늘어날 위험을 줄일 수 있습니다.
쿠버네티스 자체는 추상화입니다. 그렇지 않다면 "클라우드 네이티브"라고 부를 수 없겠지만, 불필요한 추상화를 최소화하면 엔지니어가 기본 복잡성을 관리하는 시간을 줄이고 가치 제공에 더 많은 시간을 집중할 수 있습니다. 제 경력에서 가장 진보된 혁신은 '엄격한 다이어트' 접근 방식을 구현하는 회사, 즉 기본을 마스터하는 데 집중하여 매우 복잡한 문제를 해결하는 최첨단 제품을 안전하고 안정적으로 구축하는 회사에서 나온 것이기 때문에 저는 여기서 '마음껏 먹기' 접근 방식에 반대하는 제 의견을 고수합니다.
쿠버네티스 마스터하기 계속하기
실습 경험, 강력한 문제 해결 방법론, 도구에 대한 사려 깊은 접근 방식을 결합하면 Kubernetes를 훨씬 쉽게 마스터할 수 있습니다. 단순히 읽는 것이 아니라 직접 해보면서 배우는 것은 실제 운영에서 중요한 문제 해결 기술을 익히는 데 도움이 됩니다. 문제 해결은 단순히 고장난 것을 고치는 것이 아니라, 이해를 개선하고, 문서를 개선하고, 향후 문제를 더 쉽게 해결할 수 있는 체계적인 접근 방식을 개발할 수 있는 기회입니다. 또한 불필요한 추상화를 최소화하여 Kubernetes 스택을 단순화하면 인지 오버헤드가 줄어들어 시간이 지나면서 관리가 더 쉬워집니다.
많은 숙련된 실무자들이 경험한 것처럼, 간결하고 잘 구조화된 클러스터는 명확한 이점을 제공하지 않고 복잡성을 더하는 도구로 과부하가 걸린 클러스터보다 유지 관리 및 확장이 더 쉽습니다. 궁극적으로 Kubernetes의 성공은 시중에 나와 있는 모든 새로운 도구를 사용하는 것이 아니라 장기적으로 실질적인 가치를 더하는 도구를 파악하는 것입니다.
Kubernetes에 대해 더 자세히 알고 싶으시다면 YouTube 또는 아래에서 시청할 수 있는 KubeFM 팟캐스트에서 더 자세히 설명해드리겠습니다.
내용