티스토리 뷰

Retrospectives

Kubernetes 스터디 후기

Voyager Woo 2019. 8. 4. 19:42
반응형

Kubernetes 스터디 후기

올해(2019년) 1월 10일 부터 시작한 쿠버네티스(이하 k8s) 스터디가 드디어 막을 내렸다. 크게 3번으로 나눠서 진행했고, 총 20주에 걸쳐서 스터디를 진행했다. 이번 스터디를 통해서 좋은 사람들을 얻었고 여러 관점에서 많은 영감을 얻었다. 꼭 기록해두고 싶어서 이 스터디의 후기를 적어보고자 한다.

스터디의 동기

이 스터디를 열게 된 이유는 k8s를 사내에 도입하고 싶었기 때문이었다. 그 당시 나는 전 직장에서 도커와 AWS ECS를 이용하여 서비스를 운영해본 경험이 있었다. 현 직장은 아직 컨테이너 도입 전이었다. 현 직장은 퍼블릭 클라우드가 아닌 IDC에서 서비스를 운영하고 있었는데 막연하게 AWS의 컨테이너 오케스트레이션 서비스를 사용할 수 없으니 k8s를 해야겠다고 생각했다. 도커 스웜 등 여러가지 오케스트레이션 도구가 있었지만 본능처럼 현재 가장 인기가 많은 k8s를 해야겠다고 생각했다. 도입하지 않게 되더라도 가장 유명한 기술을 익히는 것이 나쁘지 않을 것이라고도 생각했다. 그렇게 스터디를 하기로 마음 먹었다.

스터디의 교재는 'Kubernetes In Action'으로 결정했다. 대단히 고심해서 한 결정은 아니고, 책의 구성이 좋아서 고르게 되었다.

첫번째 스터디 - Kubernetes 초급 스터디

스터디 모집

작년(2018년) 12월에 말 신림 프로그래머 페이스북 그룹에 스터디 공지를 올렸다. AWSKRUG 슬랙 채널에도 내용을 공유했다. 책이 두껍고 챕터가 많아서 10장까지 진행해 보는 것을 목표로 했다.

나를 포함해서 10명이 신청했다. 생각보다 인기가 많아서 놀랐다. 스터디 운영 경험이 조금 있었지만 이렇게 많은 사람들과 함께 하는 스터디는 처음이어서 걱정이 조금 되었다.

스터디 방법

스터디는 다음과 같은 방법으로 진행하기로 했다.

  • 각 장별로 발표자를 선정
  • 스터디 당일 장당 한시간정도 범위로 발표 진행
  • 자유로운 방식으로 진행 (ex. 슬라이드쇼형 발표자료 작성, 데모 시연 등)
  • 매일 두장 정도 분량을 진행

예전에는 각 챕터까지 모두 같이 읽어오고 스터디 당일에 뽑기로 뽑힌 사람이 진행하는 방식으로도 했었는데, 힘들어서 진행이 잘 되지 않았었다. 담당자를 지정해서 하는 것이 스터디 원들에게 부담이 덜해서 좋은 것 같다.

스터디 장소

장소는 서울대 입구역의 토즈에서 진행하기로 했다. 신림프로그래머에서 진행하는 스터디이기 때문에 신림과 가까운 장소로 선택했다. 30% 세일을 해서 스터디 1회, 일인당 5천원 정도 였다. (아직도 할인중이다.) 스터디 참석을 약간 강제하기 위해서 개인이 스터디 동안 부담할 비용(30000원)을 첫회차 때 한번에 받았다.

비용이 들긴 하지만 장소도 깔끔하고, 무료 음료와 토스트(식빵)이 있어서 손해보는 느낌은 아니었다.

스터디

스터디 멤버는 지금 뒤돌아보니 멤버들 전체적으로 수준이 높고, 개개인의 경험이나 지식들이 서로에게 도움이 되도록 구성되어 있었다. 연령대가 다양했고, 업무적인 경험도 다양했다. 컨테이너로 서비스를 운영 중이신 분, 네트워크 수준의 깊은 지식이 있는 분 등 다양한 분들이 모이게 되었다.

1월 3일 스터디 오리엔테이션을 시작으로 총 7주 동안 스터디를 진행했다. 10명이 신청했지만 보통 6명에서 8명 정도가 참여했다. 간혹 담당했던 날짜에 담장자가 오지 않으면 내가 책으로 진행했다.

진행 중에 질문과 토론이 많았다. k8s가 쉽지 않은 만큼 당연한 것이기도 한데, 특히나 이번 스터디는 이렇게 자유롭게 질문하고 토론하면서 지식의 전파가 빠르다고 느껴졌다.

  1. 질문한다.
  2. 대답한다.
  3. 질문자가 대답을 정리해본다.

위의 흐름이 이번 스터디의 핵심 포인트가 아니었나 생각해본다.

스터디와 함께 구글의 스터디잼도 함께 참여했는데, 복습의 효과가 있어서 좋았다.

당시에 공부한 내용

첫번째 스터디는 Kubernetes in Action 책의 10장까지 진행했으며, k8s의 기본적인 오브젝트들에 대해서 이해할 수 있었다. Pod, ReplicationSet, Service, Deployment, Volume, Config, Secret, DaemonSet, StatefulSet 등의 오브젝트들과 API 서버에 접근해서 관련 정보를 확인하는 방법을 배웠다.

개인적인 소회

꾸준하게 열심히 참여해주신 멤버들 덕분에 스터디의 운영이 매우 수월했다.

이번 스터디는 k8s 기본 개념을 잡는데 도움이 되었다. Kubernetes in Action 책은 번역이 매우 불만족스러웠지만, 구성이 정말 좋았다.

막연하게 복잡하다고 느끼던 k8s이 컨테이너로 한단계 추상화한 인프라 위에서 배포와 여러 기능들을 추상화하여 의미있는 오브젝트들이 도출되었음을 알게 되었다. 예를 들어 Deployment라는 배포를 추상화한 오브젝트와 가물가물하지만 영속적인 데이터를 저장하는 부분을 추상화한 Persistent Volumes, Persistent Volumes Claim이 인상깊었다.

또한 Label 이라는 개념이 인상깊었다. k8s는 리소스에 라벨을 붙이고 그 라벨을 가지고 리소스를 조회한다. 나중에 매니징 쿠버네티스 책 스터디하면서 이것이 암시적 그룹핑이라는 개념이라는 것을 알게 되었다.

그리고 k8s Service의 흐름을 대략적으로 이해하게 되면서 네트워크 인프라에 대해서 좀 더 깊게 이해할 수 있었다.

그러나, k8s를 조금 알게 되고 사내 도입이 쉽지 않다는 것을 깨닫게 되었다...

두번째 스터디 - Kubernetes 중급 스터디

스터디 모집

몇 주 쉬고 다시 스터디를 시작했다. 스터디 멤버는 우선 기존 스터디 멤버들에게 연장 신청을 받았고, 그 다음에 AWSKRUG 슬랙을 통해서 추가 모집 공지를 올렸다.

기존 스터디를 꾸준히 참여해주셨던 분들 대부분이 연장했고, k8s 경험이 있으신 분, 도입 예정이신 분이 새 멤버로 참여하게 되었다. 그리고 기존 멤버 중에서도 k8s를 실제로 도입하게 되었다. k8s 경험이 있는 분들 덕분에 이론적인 수준을 벗어나 실제 실무에서 도움이 될 만한 이야기들을 할 수 있었다.

스터디 방법과 장소

첫번째 스터디와 동일하다.

스터디

5주 동안 Kubernetes in Action 책의 11장부터 18장 까지 진행했다. 스터디 구성원 전체적으로 k8s에 대한 이해가 높아서 깊은 대화를 할 수 있었다. 이제는 단순한 질문이 아닌 토론이 자주 진행되었다. 가끔 토론 때문에 시간이 많이 소요되긴 했지만, 전체적으로 유의미한 대화들이 오고 갔다고 느껴졌다.

당시에 공부한 내용

11장에서 k8s의 내부구조에 대해서 자세하게 훑고 지나갔다. 쿠버네티스의 여러 컴포넌트가 어떻게 협력하는지 공부할 수 있었다. 그리고 k8s를 운영하는 측면에서 스케줄링, API 서버 보안, 네트워크 보안, 리소스 관리, 스케일링 등을 공부했다. 그리고 17장에서 전체를 복습하며 책에서 제안하는 베스트 프랙티스를 확인했다.

개인적인 소회

기존 멤버와 새롭게 함께하게 된 멤버들 간에 시너지가 매우 좋았다. 특히 각자 회사에서 k8s를 도입하고 있는 분들이 있어서 서로 자극받고 도움이 되는 것 같아서 보기가 좋았다. 스터디 멤버들 전체적으로 친해졌고, 자연스럽게 AWSKRUG 컨테이너 소모임과 연계되어서 소모임 운영에 대한 부담감이 줄어들었다.

이번 스터디를 통해서 개인적으로는 k8s 내부 설계에 대해서 큰 감명을 받았다.

Unix Way에 기반하여 컴포넌트들이 각자의 역할을 수행하며, 각자 컴포넌트는 약하게 결합되어 있다. API 서버가 클러스터의 상태를 etcd에 저장하고 각 컴포넌트들은 API 서버를 통해서 리소스 정보를 조회하고 수정한다. 예를 들어 스케줄러는 Pod의 스케줄 관련된 리소스 정보를 API 서버를 통해 조회하고 수정한다. 이런 디자인 철학이 개발자인 나에게 큰 감명을 주었다.

또한 쿠버네티스를 운영할 때 개발자와 클러스터 관리자라는 두 역할이 비교적 명확히 분리된다는 부분이 인상적이었다. 덕분에 사내 도입에 더 두려움을 가지게 되었다.

긴 스터디 끝에 Kubernetes in Action 이라는 어려운 책을 마무리 할 수 있었다. 최고로 좋았던 점은 내가 이해하지 못했던 부분이나 읽지 못한 부분, 놓친 부분을 스터디 멤버들 덕분에 이해할 수 있었던 것이다. 내 머리 속에 넣어 줬다. 모두에게 감사하다.

세번째 스터디 - Kubernetes Endgame

2번째 스터디를 마치고 다음 스터디에 대해서 의논을 많이 했다. 여러가지 제안이 있었다.

  • Kubernetes 자격증 스터디
  • Kubernetes PR 스터디
  • Kubernetes 이슈 리뷰 스터디
  • Kubernetes the hard way 스터디

그중에 우리는 Kubernetes the hard way라는 깃헙 레포를 교제로 스터디하기로 했었다. 그렇게 하면서 스터디 이름을 Kubernetes Endgame 이라고 정했다!

그러나 첫 회차 스터디 이후에 Managing Kubernetes 라는 책으로 변경했다.

스터디 모집

이번 스터디는 따로 추가 모집을 하지 않았다. 스터디 멤버간 신뢰가 쌓여서 충원의 필요성을 느끼지 못했다. 나중에는 추천 방식으로 인원을 2명 추가했다.

스터디 방법과 장소

스터디 방법은 기존과 동일했다. 책의 챕터별로 담당자를 지정하고 진행하도록 했다.

장소는 메가존이라는 회사에서 지원을 받았다. 장소 비용을 절약할 수 있었다.

당시에 공부한 내용

책이 얇지만 운영에 중요한 핵심 내용을 다루고 있었다. 아키텍처에 대해서 다시 한번 복습하고, 스케줄링에 대해서 좀더 자세하게 다뤘다. 그리고 API 서버의 인증, 인가, 승인 제어(Admission Control)이라는 k8s의 중요한 프로세스이자 오브젝트를 공부했다. 마지막으로 모니터링에 대해서 심도있게 토론을 하고 스터디를 마무리 했다.

개인적인 소회

스터디 멤버 모두가 k8s에 대한 기본적인 이해가 있어서 담당자가 빠지더라도 원활한 진행이 가능했다.

개인적으로는 인상깊은 개념 여러가지를 공부했다.

우선은 선언적 구성(Declarative Configuration)과 독립 조정(Independent reconciliation) 또는 제어 루프(Control Loop)라는 개념이다. 분산 시스템에서 각 시스템을 결합도를 낮추는 방식이다. 각 컨트롤러들이 자체적으로 독립 조정 루프를 가지고 있어 각자의 역할만 수행한다. 예를 들어 레플리카 셋 컨트롤러는 레플리카의 갯수만 맞추는 독립 조정 루프를 가지고 있다.

두번째는 암묵적 그룹핑이다. 명시적 그룹핑은 해당 그룹의 요소들에게 강한 의존을 가지고 있다. 그러나 암묵적으로 그루핑 한다면 요소들을 동적으로 관리할 수 있다. 예를 들어 우리 팀원은 철수, 영희, 길동이라고 명시적으로 그룹핑 한다면 그룹원을 변경할 경우 그 정의를 계속 수정해야 한다. 그러나 우리 팀원은 파란색 유니폼을 입고 있다고 한다면 그 사람이 누구든 파란 유니폼을 입으면 우리 팀원이 된다. (사람에 대고 비유하는 것은 적절하지 않다고 생각이 되지만, 마땅히 떠오르는 예시가 없다.) 당연하게도 암묵적 그루핑은 그룹의 요소가 계속 변화할 수 있고, 요소를 찾는 작업 때문에 복잡도가 더 올라가는 Trade off가 있지만 k8s 같이 복잡한 분산 환경에서는 변화에 유연하게 대응할 수 있다. k8s에서는 그 파란 유니폼이라는 정보를 Label로 기술하고 있다.

그리고 API 서버의 승인 제어(Admission Control)라는 단계가 인상 깊었다. API 서버로 들어온 요청이 인증 인가 단계를 거쳐서 검증(Validation)하거나 변경(Mutation)하는 단계이다. 예를 들어서, 새로 등록되는 Pod들이 적절하게 리소스가 할당 되었는지 검증하거나 적절한 값으로 변경할 수 있다. 또한 새로 등록되는 Pod에 로깅 또는 네트워크 관련한 사이드카 컨테이너를 추가할 수도 있다. k8s가 승인 제어를 통해서 워크로드를 관리하는 부분이 꽤 매력적으로 다가왔다.

지식은 많이 쌓였는데, k8s를 도입해야하는 것에 대해서는 더욱 고민이 많아졌다.

정리

k8s 에 대하여

k8s는 정말 매력적인 소프트웨어이다. 컨테이너 기반의 백앤드 인프라를 위한 다양한 기능을 제공한다. 현 시대의 DevOps 적인 방법론들을 실현하는 데 있어서 이만한 도구가 없어 보인다.

다만 도입에 대해서는 충분히 준비(인력과 학습)가 없다면 어렵다고 여겨진다. k8s의 추상화를 이해하고 각 컴포넌트간 협력을 이해하고 문제가 발생할 만한 부분들을 준비하지 않는 다면 위험할 수 있다.

스터디에 대하여

운 좋게도 이런 열정적인 스터디를 운영하게 되어서 매우 기쁘고, 스터디 멤버들에게 진심으로 감사의 마음을 전한다.

마치며

간단한 회고 트렐로 보드

올해 상반기는 좋은 사람들을 만나서 진하게 k8s에 대해서 공부했다. k8s 뿐만 아니라 개발자 혹은 엔지니어라는 직업에 대해서도 진지하게 토론을 하며 많은 영감을 얻었다. 스터디 멤버들 모두 승승장구하길 기원한다.

링크

반응형
댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/04   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
글 보관함