안녕하세요. 클라우드플랫폼팀 bg.chun이라고 합니다. 여기에서는 Kubernetes에 코드 컨트리뷰션하는 방법과 관련 팁에 대해 말씀드리고자 합니다.

Kubernetes는 의심의 여지 없는 사실상의 표준인 컨테이너 오케스트레이션 도구(de-facto standard container orchestration tool) 이자, 지금도 지속적으로 발전해 나가고 있는 프로젝트입니다. 카카오 사내에서는 DKOS란 명칭으로 KaaS 형태로 제공하고 있으며, 현재는 카카오톡을 비롯한 대다수의 서비스가 DKOS 상에서 호스팅 되고 있습니다.

Kubernetes가 클라우드 업계에서 사실상의 표준(de-facto standard)이 되고 난 후부터 컨트리뷰션에 관심을 가지는 분들이 많으신데요, 제 개인적인 경험을 바탕으로, 실제 컨트리뷰션 과정에서 알게 된 몇 가지 팁을 공유하고자 합니다.

들어가며

먼저, Kubernetes뿐만 아니라 대부분의 오픈소스들에 있어서 가장 쉽게 컨트리뷰션하는 방법은, 문서 작성에 참여하거나 한국어로 번역 또는 오탈자를 수정하는 것입니다.

개인적으로는, Kubernetes에서 관심 있는 컴포넌트나 특정 기능(Feature)의 히스토리를 확인하고 구현 내용을 살펴보는 것처럼, 소스코드를 깊이 있게 살펴보는(Deep Dive) 것을 선호하는 편입니다.

소스코드로 Deep Dive를 하다 보면, 문서에서는 다루지 않는 내부의 세세한 동작이라던가, 인지는 하고 있지만 처리하고 있지 않은 엣지 케이스(Edge Case)와 같은 부분들을 알아낼 수 있고, 관련 컴포넌트나 기능을 실 서비스에 사용하려고 할 때 이슈나 버그가 발생하게 되면 더욱 유연하게 대처할 수 있는 지식을 얻을 수 있기 때문입니다. 그렇기 때문에, 특정 기능에 의존성이 강한 서비스를 개발하거나 사용하는 컴포넌트의 내부적인 동작에 관심이 있다면, 소스코드로의 Deep Dive를 강력하게 추천합니다.

제 경우, 컨트리뷰션을 진행하며 kubelet과 컨테이너 런타임(Container Runtime), 그리고 둘 간에 사용되는 CRI에 기여를 했습니다. 이러한 기여를 하는 과정에서 CRI 및 OCI 표준 컨테이너 런타임(Container Runtime)의 내부 구현까지 세세히 살펴볼 수 있었기에, 여러 이슈들을 해결하고 다양한 컨테이너 런타임을 테스트하는 데 있어 정말 많은 도움이 되었습니다.

Kubernetes에 컨트리뷰션하기

컨트리뷰션을 하기 전에

Kubernetes에 컨트리뷰션하려면, 기본적으로 CLA에 서약을 해야 합니다. 또한, 컨트리뷰션 시의 행동지침(Code of Conduct)과 기여자에 대한 커뮤니티의 기대와 역할(Community Expectations and Roles)를 숙지하고 있어야 합니다.

CLA 서약의 경우, PR을 생성하고 코드 컨트리뷰션 시 필수적으로 체크하는 항목이기 때문에, 컨트리뷰션할 계정으로 서약이 진행되어야 합니다. 자세한 내용은, 다음의 Getting started page에서 확인할 수 있습니다.

Kubernetes 커뮤니티 소개

Kubernetes는 방대한 오픈소스이며, 여러 종류의 SIG(Special Interest Group)들이 각자의 역할(Role)과 영역을 가지고 서로 협조하며 프로젝트를 관리하고 있습니다. 여러 SIG가 함께 논의해야 할 고정적인 주제가 있는 경우, 워킹 그룹(Working Group)을 형성하기도 합니다. 가장 최상단에는 각종 정책적인 결정을 하는 운영위원회(Steering Committee)가 존재합니다. 자세한 커뮤니티 거버넌스 모델(Community Governance Model)은 다음의 링크에서 확인 가능합니다.

코드 레벨 컨트리뷰션의 경우, 보통 특정 SIG에 속해 있는 승인(Approval) 권한을 가진 Kubernetes Org 멤버(“메인테이터(Maintainer)”라 칭함)와 코멘트(Comment) 또는 Slack으로 상호작용을 해야 합니다. 그렇기 때문에, 컨트리뷰션하는 코드가 어느 SIG에 속하는지를 파악하는 것을 강력하게 추천 드립니다.

아래는 여러 그룹들의 리스트입니다. 각 SIG들에 대한 자세한 정보는 다음의 sig-list link에서 확인 가능합니다.

SIG
- API Machinery, Apps, Architecture, Auth, Autoscaling, CLI, Cloud Provider, Cluster Lifecycle, Contributor Experience, Docs, Instrumentation, Multicluster, Network, Node, Release, Scalability, Scheduling, Security, Service Catalog, Storage, Testing, UI, Usability, Windows
Working Groups
- API Expression, Component Standard, Data Protection, IoT Edge, K8s Infra, Multitenancy, Naming, Policy, Reliability, Structured Logging
User Group
- Big Data, VMware Users
Committees
- Code of Conduct, Security Response, Steering

개선 제안서 작성: Kubernetes Enhancement Proposal(KEP)

코드 레벨 컨트리뷰션은 KEP(Kubernetes Enhancement Proposal)를 작성하는 경우와 작성하지 않는 경우로 분류할 수 있습니다. 물론, 이러한 KEP 또한 SIG 단위로 관리됩니다.

KEP을 쓰지 않는 경우:
- 버그픽스(Bugfix)
- 특정 오브젝트나 기능(Feature)의 동작을 변경하지 않는 수준의 개선 및 리팩토링
- 성능 향상(Performance Improvements)
- 동작하지 않는 테스트 코드 수정
KEP을 쓰는 경우:
- 새로운 오브젝트 및 기능(Feature)를 제안하는 경우
- 기존 API(오브젝트) 및 기능(Feature)를 확장 및 개선하여 기존의 동작이 변경되는 경우
- 변경 및 개선사항이 사용자 경험(User Experience)에 많은 영향을 주는 경우

- 참고 : KEP를 작성해야 하는 경우에는, KEP에 대한 승인(approval)을 받은 후에 해당 KEP가 먼저 머지 되어야 관련 코드 컨트리뷰션이 가능합니다.

KEP은 Kubernetes가 발전해 나가며 발생하는 다양한 개선사항들을 지속적으로 트래킹 하기 위한 일종의 문서입니다. KEP에는 Kubernetes의 전반적인 아키텍처나 스케줄러 프레임워크(Scheduler Framework)와 같이 특정 컴포넌트의 설계, 특정 기능(Feature)이나 개선사항이 제안된 배경(Background)과 변경 내용들이 포함될 수 있습니다.

소스코드로의 DeepDive를 하거나 실제 컨트리뷰션을 함에 있어 관련된 KEP가 존재한다면, 관련된 히스토리와 설계 사상, 주요 사용 사례(Usecase), 제한사항(Limitation) 등을 이해하기 위해 읽어 보는 것을 강력하게 추천드립니다.

아래의 리스트는 제가 관심 있게 읽었던 KEP들입니다.

자세한 이유는 모르지만, In-place Update of Pod Resources와 Pod level resource limit의 경우, Kubernetes를 시작했던 초창기 구글 엔지니어이자 아직도 왕성하게 활동하는 메인테이너인 Tim Hockin이 지속적으로 방문을 하는 KEP여서, 머지않은 미래에 만나볼 수 있는 개선사항들이라 생각합니다.

컨트리뷰션 실행(Contribution in Action)

컨트리뷰션할 커밋(Commit)이 준비되었다면, 이제 PR을 생성할 차례입니다. Kubernetes의 경우, 여타 다른 오픈소스 프로젝트와 마찬가지로, Repo에 직접적인 branch 생성이 불가능합니다. 따라서, 컨트리뷰션을 해야 하는 Repo를 Fork 하여 PR을 생성하면 됩니다.

주로, 코드 컨트리뷰션은 kubernetes repo로 이루어지며, KEP은 enhancements repo로, 문서 작성은 website repo로 PR을 생성해야 합니다.

- 참고 : 아래 내용들은 kubernetes repo를 기준으로 작성되었습니다.

하지만 PR을 생성했다고 해서, 자동으로 할당된 리뷰어가 적극적으로 리뷰를 해주거나, 담당 메인테이너가 리뷰 및 머지를 해 주는 경우는 많지 않습니다. 따라서, 해당 PR와 연관된 SIG의 Slack 채널로 직접 방문해, 아래와 같이, PR에 대한 간단한 한 줄 정도(one-line)의 설명과 함께 리뷰를 정중하게 요청하는 것을 추천합니다. 친절한 컨트리뷰터들과 Kubernetes Org 멤버들이 여러분의 PR을 리뷰해 줄 것입니다.

Hey guys, I opened a PR to fix a weird bug of {COMPONENT_OR_FEATURE}.
{PUT_ONE_LINE_PR_DESCRIPTION_HERE} 
plz take a look: {YOUR_PULL_REQUEST_LINK}

담당 SIG의 Slack 채널로의 방문을 강력하게 추천하는 이유는, Kubernetes Org 멤버만이 PR에 ok-to-test 란 라벨을 달수 있으며, Kubernetes CI 시스템(prow)은 해당 라벨이 있는 PR만을 처리하기 때문입니다.

여러분의 PR에 해당 라벨이 부착되면, CI 시스템이 지정된 테스트와 일부 테스트를 무작위로 뽑아 CI 테스트를 수행합니다. 참고로 CI 테스트의 경우, 별다른 이유 없이 테스트 중 오류로 실패(fail)가 나는 경우가 빈번하기 때문에, 일부 실패한 테스트에 대해서는 /retest 또는 /retest {TEST_NAME} 명령어를 코멘트(Comment)로 달아 재테스트(retest)를 해 주어야 합니다. 아래는 ok-to-test 라벨을 받은 PR의 일부 테스트가 실패한 경우의 예시입니다.

여러분의 PR이 충분한 리뷰를 받고 lgtm 라벨을 가지고 있다면, 이제 PR에 대한 승인(Approval) 권한을 가지고 있는 메인테이너와 소통을 해야 합니다. Kubernetes의 경우, SIG 리더들이 해당 SIG가 관리하는 소스코드에 대한 승인 권한을 가지며, 해당 SIG의 일부 Org 멤버들은 특정 기능(Feature)나 특정 소스 트리(Source-tree)에 대한 제한된 승인 권한을 가집니다.

SIG 리더 또는 승인자(Approver)로부터 관심을 받는 가장 좋은 방법은 Slack 채널에서 멘션(Mention)을 하거나 주간 미팅(Weekly meeting)에 참여하는 것입니다.

간단한 버그픽스(Bugfix)의 경우 Slack 채널에서의 논의만으로 PR이 머지 될 수도 있습니다. 하지만, 새로운 기능(Feature)의 제안, 특정 기능(Feature)이나 API의 동작 변경과 같이, KEP 작성/수정을 동반하는 수정사항들의 경우, SIG 주간 미팅(Weekly meeting)에서 이러한 개선이 왜 필요한지에 대해 커뮤니티 구성원들을 설득해야 합니다. 여러 SIG의 리더, Slack 채널, 주간 미팅 정보는 다음 링크에서 확인할 수 있습니다.

주간 미팅에서 발언을 하기 위해서는 각 SIG 별 아젠다 보드(Agenda board)에 안건을 등록해야 합니다. 대규모 변경사항의 경우, 지원해야 할 사용 사례(Usecase)나 구현 방향에 대한 논의가 여러 미팅에 걸쳐 오랜 시간 동안 이루어지기 때문에, 아젠다 보드는 항상 가득 차 있습니다.

여러 SIG에서 복합적으로 논의가 필요한 경우, 다른 SIG의 리더를 주간 미팅에 초대해야 하는 경우도 발생하며, 별도의 미팅을 주선해야 하기도 합니다. 다음 링크는 제가 주로 활동했던 SIG Node의 아젠다 보드입니다.

마침내 구성원들로부터 동의를 얻고 승인자(Approver)가 모든 피드백이 반영되었다고 판단이 되면, 여러분의 PR에 approved 라벨을 부착할 것입니다. 최종적으로 CI 시스템이 CLA 서약 및 여러 조건을 검토한 후, 모두 만족한다면 여러분의 PR을 master 브랜치에 머지 시킵니다.

아래는 PR을 생성하여 머지 되기까지의 일련의 과정이 요약된 다이어그램입니다.

마치며

저는 현재 Kubernetes Organization에 멤버로 가입이 되어 있으며, 종종 제가 기여했던 기능(Feature)과 관련된 개선사항을 추적하고, 관련 PR에 리뷰를 남기고 있습니다. 실제 코드 컨트리뷰션을 하게 되면, 종종 공동으로 작업하는 커뮤니티 컨트리뷰터 간의 의견 충돌이나 담당 메인테이너의 반대 의견 등으로 인해 원활히 진행되지 않을 수 있어, 컨트리뷰션을 적극적으로 추천하지는 않습니다. 다만, 개인적 혹은 업무적인 이유로 컨트리뷰션을 해야만 하는 사내외의 많은 분들께 제 경험 공유가 조금의 도움이 되기를 바랍니다.

다음번에는 파드(Pod) 오브젝트 생성 후 노드(Node)에서 kubelet이 파드와 컨테이너를 생성하는 자세한 과정을 분석하는 글을 작성할 예정입니다. 컨테이너 내부 동작 원리와 구조에 흥미가 있으시다면 많은 관심 부탁드립니다.

Kubernetes에 컨트리뷰션 하는 아주 자세한 방법을 알려드립니다.