▲

Kubernetese 2.0은 어떤 모습일까

 (matduggan.com)
4P by GN⁺ 6일전 | ★ favorite | 댓글 2개
  • 쿠버네티스는 지난 10년간 컨테이너 오케스트레이션 혁신을 주도했음
  • 현행 YAML 구성, etcd 의존성, Helm 패키지 관리 등에서 다양한 한계점과 개선 필요성이 관찰됨
  • HCL 도입, 플러그형 저장소, 새로운 패키지 관리자(KubePkg), IPv6 기본화 등이 쿠버네티스 2.0의 변화 요소로 논의됨
  • 현재의 오픈형 구조도 중요하지만, 기본값과 공식적인 방향 제시가 생태계 혁신에 결정적 영향을 미침
  • 쿠버네티스는 지속적인 파괴적 개선을 통해 더 넓은 사용자와 조직에 적합해질 필요성이 확인됨

쿠버네티스의 10년: 성공과 한계

시작과 성장

  • 2012~2013년 Google 내부의 Linux 컨테이너 시스템인 Borg에 대한 소문이 sysadmin 커뮤니티에 퍼지기 시작함
  • 2014년 쿠버네티스가 공개되었고, 초기에는 발음조차 어려운 이름이었음
  • 마이크로소프트, RedHat, IBM, Docker 등 주요 기업이 빠르게 합류하며 쿠버네티스가 생태계 표준으로 자리 잡기 시작함
  • 2015년 v1.0 공개 및 CNCF 출범으로 본격적인 개방 생태계 조성

주요 혁신 포인트

컨테이너의 대규모 관리

  • 쿠버네티스는 컨테이너 기반 소프트웨어 개발과 배포의 확장성을 제공함
  • 단순한 개발 환경에서부터 수천대 서버에 이르는 대규모 동일 환경 배포를 가능하게 함
  • 조직들은 모놀리식 구조에서 분산형 마이크로서비스로 전환하는 계기를 마련할 수 있었음

저비용 유지보수와 자기 치유

  • 서버 관리가 "Simpsons" (각 서버마다 별명, 수작업 운영) 시대에서 "UUID" (완전 교체, 자동화, 무상태) 시대로 급변함
  • 머신 수명, OS 지원 기간 개념이 거의 사라졌으며, 고장 시 "노드 재생성"으로 자동 재구성됨
  • 많은 리눅스 스킬이 이제 필수 조건이 아닌 "있으면 좋은" 수준으로 변화함

배치 작업과 Job 관리

  • 과거 "cron 전용 박스"에 의존하던 배치 처리가, 큐 기반 자동화 작업과 재시도 기작으로 대체됨
  • 작업 실패 시 자동 재시작과 유연한 처리로 운영 효율성과 개발자 만족도를 크게 높임

서비스 디스커버리와 로드밸런싱

  • IP 주소 하드코딩 대신 내부 DNS 기반 서비스 명명 체계를 도입
  • API, 고정 IP, 호스트명으로 서비스 간 연결을 단순화하고, 외부 서비스도 내부처럼 다룰 수 있게 함

쿠버네티스 2.0: 핵심 개선안

YAML에서 HCL로, 구성 언어 교체

YAML의 한계

  • YAML은 보기 쉽고 JSON, XML보다 나아 보이나, 오류 유발, 타입 미지원, 디버깅 어려움 등 심각한 문제 존재
  • 예시) 노르웨이 문제('NO'가 false로 해석), 인덴트 에러, 문자열 숫자 혼동 등 수많은 장애 요소 내재

대안: HCL 채택

  • HCL(HashiCorp Configuration Language) 은 Terraform의 표준 포맷으로, 강타입, 검증, 함수, 조건 분기 등 우수한 기능 제공
  • 이미 상당수 쿠버네티스 클러스터가 Terraform과 함께 HCL을 활용 중임
  • HCL은 타입 안정성, 중복 감소, 동적 설정, 반복 처리, 조건 논리, 뛰어난 주석 지원, 모듈성, 유효성 검증 등 YAML보다 강력한 기능 보유
  • 오픈소스 라이선스 문제(MPL 2.0 → Apache 2.0과의 호환성)는 남아있지만 품질 향상을 위한 가치가 충분함
예시: HCL vs YAML
  • 타입, 변수, 함수, 조건문, 반복문 등 HCL의 장점 덕분에 구성 오류 미연 방지, 유지관리성, 복잡한 환경에서도 일관성 확보

etcd 대체 옵션 지원

  • etcd는 강력하지만, 소규모 클러스터나 저사양 환경에는 과도한 자원 사용 발생
  • Kine 등 플러그형 백엔드 공식 지원을 통해 기본 저장소의 유연성 확대 필요성 제기
  • 예시) k8s-dqlite: 분산 SQLite+Raft로 가볍고 유연한 데이터 계층 제공

Helm을 넘어서: 네이티브 패키지 매니저

Helm의 한계

  • Helm은 임시 해킹 솔루션이 표준이 된 경우로, 템플릿 복잡성, 디버깅 난이도, 의존성/버전 충돌, 검증 미흡 등 다양한 문제점 존재
  • 여러 차트 중복, 버전 불일치, 네임스페이스 간 설치 난점, 차트 검색/메타데이터 부재, 시맨틱 버전 미준수, 비안전한 CRD 관리 등 실전 활용에서 다수의 어려움 발생

새로운 패키지 시스템 제안: KubePkg

  • 쿠버네티스 리소스 형태로 패키지/의존성/시맨틱 버전/시큐리티/생명주기/메타데이터까지 포괄 관리
  • 정교한 라이프사이클 Hook, 상태 및 백업/복구 전략, 선언적 구성, 검증 가능한 서명 프로세스, Audit 기록, 조직 정책 통제 등 완비
  • 리눅스 패키지 매니저의 장점을 계승하여 실제 인프라 관리에 강한 신뢰성과 일관성 제공 목표

주요 요구 조건

  1. 완전한 쿠버네티스 네이티브 리소스 구조
  2. 상태 기반 애플리케이션 내장형 지원
  3. 서명/검증/보안 스캐닝 프로세스 강화
  4. 구조화된 선언적 구성 + 스키마 검증
  5. 전 생명주기 통제와 간편한 Upgrade/Hook 지원
  6. 리눅스 스타일의 의존성/버전 해석
  7. 변경 이력 및 감사 추적
  8. 조직별 정책 적용 가능성
  9. 친숙한 리눅스 패키지 관리 UX 제공

IPv6 기본값 전환

  • 현재 IPv6와 dualstack이 지원되지만, 디폴트는 여전히 IPv4임
  • 클러스터 간 통신, NAT 문제, IP 부족 사태를 해결하고 단순한 네트워크 구조, 내장 IPSec 등 장점이 있음
  • 대규모 IP 필요 환경(예시: /20 대역, 노드 40개, 1개 노드에 30개 pod)은 빠르게 IPv4 한계에 봉착
  • 퍼블릭 IPv6 환경에서의 운영 단순화, 클라우드 사용자 확보, 사설 영역 관리 부담 감소 등 실용적 이점 분명

결론: 변화의 필요성과 기본값의 힘

  • "오픈 플랫폼이니 커뮤니티가 알아서"라는 의견도 있으나, 기본값이 업계 행동 양식을 주도함
  • 쿠버네티스 2.0에는 공식적 신념, 우수한 설계, 강력한 기본값이 필요한 시점임
  • 업계의 표준이자 글로벌 데이터센터 운영 대세 지위에 맞는 참신한 도약이 중요한 시기임
  • 이미 모바일, 웹 등 다양한 기술 영역에서 과감한 변화로 전체 생태계 혁신 경험이 반복적으로 등장
  • 쿠버네티스도 이제 기념비적 2.0을 통해 다음 단계를 고민할 시점임
▲
kaydash 3일전  [-]

오픈소스를 엮어만든 바닐라 k8s를 구성하고 운영할 수 있는 엔지니어는 앞으로도 소수일것같아요.
하둡클러스터를 클라우데라 플랫폼으로 묶어서 구매하지않고 바닐라의 하둡에코시스템을 운영할수있던 엔지니어가 극 소수였던것처럼.

답변달기
▲
GN⁺ 6일전  [-]
Hacker News 의견

  • Kubernetes의 가장 큰 문제점으로는 "그냥 잘 되는" 시스템이 아니라는 점을 꼽고 싶음. 실제로 프로덕션에서 무리 없이 서비스 운영이 가능한 엔지니어는 소수에 불과하며, 직접 VM 위에 Kubernetes 클러스터를 구축하고 유지하는 건 더더욱 어려운 일임. 그래서 요즘 뜨는 서버리스 스타트업들은 (1) 시간 소모가 많고, (2) 매우 오류가 많으며, (3) 프로덕션 환경에서 실패 확률이 높다는 인식이 퍼졌기 때문임. Kubernetes 2.0에서는 누구든 쉽게 배포 플랫폼을 셀프호스트하고 자신 있게 사용할 수 있으며, 작고 강력한 오케스트레이터 코어를 유지하는 방향을 고민해야 한다고 생각함. Rivet라는 오케스트레이터와 배포 플랫폼을 직접 개발 중이며, Rivet 오픈소스 서버리스 플랫폼임을 내세우지만, 스스로는 “Kubernetes 2.0이 뭘까?”라는 고민을 자주 함. 사람들이 기대 이상의 시나리오에 Rivet를 도입하는 케이스도 늘고 있음. Rivet의 최대 강점은 Kubernetes controller 수준의 기능을 손쉽게 개발 가능하다는 점이며, 이를 통해 게임 서버, 테넌트별 배포, 고급 워크로드 오케스트레이션, 멀티테넌시, 테넌트별 과금, 강력한 오퍼레이터 설계 등 다양한 시나리오에 활용 가능함.

    • 이런 관점, 참 반감 듦. 나이도 많고 마음이 약간 냉소적이라서 그런지, 자주 보게 되는 패턴임. X 기술이 너무 무거워서 "나는 그냥 이거 없이 노트북에서 간단히 돌리고 싶다"라는 사람이 Y 기술을 만듦. 그러다 Y도 인기를 얻고, 실제로 노트북이 아닌 곳에 돌릴 때 확장성이 필요해지면서 다양한 기능이 추가되어 무거워짐. 그러면 누군가는 "이젠 Y도 너무 무겁다"면서 같은 말을 반복함. 이건 마치 '시간의 바퀴'처럼 시작도 끝도 없는 반복되는 이야기임.

    • 실상은 k3s(경량 k8s)는 유지 관리가 정말 쉬움. k3s 자동업데이트, 적절한 이빅션 룰만 있으면 거의 손볼 일이 없으며, Ceph 같은 스토리지도 어렵다면 Lemon이나 Longhorn 같은 “관리 제로형” 대안 선택 가능함. 수천 개의 헬름 차트가 존재해서 복잡한 데이터베이스도 1분이면 바로 배포 가능함. 서비스 배포도 많이 쓰는 헬름 템플릿만 쓰면 매우 쉬움. 헬름이 완벽하진 않지만, 원하는 대로 세팅하면 값 완성 기능 등도 누릴 수 있음. 진입장벽이 서버리스보단 약간 높지만, 일주일 정도 배워서 실제 프로덕션에서 수천만 원 절약하는 건 충분히 가치 있는 일임.

    • Kubernetes가 해결하는 문제는 "이걸 어떻게 배포하지?"임. Rivet의 Docs를 보니 싱글 컨테이너, Docker Compose, 수동 배포(도커 커맨드)밖에 없음. 현실적으로 서버리스 인프라를 실제 규모로 이렇게 배포할 수 있는지 의문임. 내 첫 번째 의문은 "이쯤 되면, Rivet을 Kubernetes 위에서(컨테이너, kube-virt 등) 돌릴 수는 없을까?"임. Docker Compose가 Kubernetes보다 더 견고하거나 확장성이 좋을 수 있는지 모르겠음. 그렇지 않고 클라우드 서비스를 판다면, 이건 Kubernetes 2.0 컨셉과도 맞지 않음. 만약 Rivet을 직접 호스팅한다면 문서를 바꿔서 Kubernetes에서 돌릴 수 있게 할 것 같음.

    • 클러스터 유지관리를 클라우드 벤더에게 아웃소싱한 “서비스형 k8s”를 사용한다면, 어떤 부분이 그렇게 복잡하게 느껴지는지 궁금함. 설정의 범위는 넓지만, 실제 프로덕션에 넘길 서비스 구성에는 소수의 설정만 알면 충분함. Docker Compose보다 약간 더 복잡한 수준의 설정이면 충분히 k8s에 배포 가능함. 하지만 대다수의 앱들에겐 이런 “조금 더” 조차도 불필요할 수도 있음. 사실 Docker Compose가 원했던 대중적인 니즈인데, 지속적인 관심을 못 받은 점이 아쉬움.

    • 인프라 운영에서는 “그냥 잘 되는” 게 절대 나올 수 없다는 게 내 경험임. Heroku조차도 확장에서 이슈가 생김. 모두가 쉽게 채택할 수 있는 배포 플랫폼을 원한다면 Kubernetes를 특정 PaaS의 기반 프리미티브로 이해하는 게 더 현실적임. Rivet는 독특하고 BEAM생태계의 몇몇 아이디어도 보여서 흥미로움. 개인적으로는 대규모 배포보다는 탄탄함과 로컬-퍼스트에 더 관심 있음.

  • “Low maintenance”라... EKS(관리형 k8s)를 많이 쓰고 있는데, 클러스터 상태에 대해선 직접 신경 쓸 필요는 없음(물론 내가 노드를 망치는 신박한(?) 방법은 별개). Kubernetes는 정말 “최대한 유지관리 필요 없는” 척하지만, 실제로는 순수 유지관리 덩어리임. yaml만 내밀면 소프트웨어를 세상에 바로 배포할 수 있다는 점은 정말 대단함. 하지만 대가가 바로 복잡한 유지관리임. 클러스터 세팅, ArgoCD 초기화, 허브-스포크 모델에서 다른 클러스터 등록 등은 서커스 한장면일 뿐임. 거기에다가 CNCF Landscape tooling에서 쓸만한 오퍼레이터들 설치, ancillary 툴들(물리적으로는 1차가 아니지만 필수)에 최소 30개쯤은 돌아가게 됨. values.yaml 세팅도 한두 시간이 아닌데, 대부분은 ArgoCD와 템플릿 작업임. Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> Another values.yaml 등 boolean 값 하나 전달하는데도 시간 쏟는 경우가 많음. 클러스터/오퍼레이터 업데이트 주기도 빨라서, 늘 상존하는 유지관리 이슈임. Karpenter로 오토스케일 할 땐 노드 교체와 무중단이 또 하나의 곡예장이 됨(상태 기반 앱은 k8s에서 재미가 두 배). 요약: 진짜 “Low maintenance”는 반어적 표현임.

    • “Low Maintenance”는 결국 대안과의 상대적 개념임. 내 경험으론 k8s를 쓸 때 확장, 장애조치, 롤백, 재해 복구, 데브옵스, 독립 클러스터 스핀업 등 전반적으로 같은 품질의 서비스를 얻는 데 드는 유지보수 부담이 훨씬 낮았음. 상황에 따라 다를 수도 있지만, 나에겐 그런 경험임.

    • 나는 지난 2년 동안 hetzner에서 k3s를 써왔고, 100% 가동시간을 경험함. 유지관리 부담이 너무 낮아서 마스터 노드의 SSH키를 잃어버린 적도 있었는데, 클러스터 전체를 다시 프로비저닝하는 게 문서 업데이트까지 포함해서 90분밖에 안 걸림. 정말 급했다면 15분이면 충분했을 것임. 월 20유로에 ARM 기반 3노드 1마스터, 약간의 스토리지, 자동 DNS까지 클라우드플레어와 연동해서 k8s 클러스터 운영 중임.

    • 하지만 실제로 관리하고 있는 건 Kubernetes 자체가 아니라, CI/CD 시스템, 시크릿 매니지먼트 시스템, 데이터베이스 운영 자동화 같은 부가 시스템임. 과거에는 yaml 대신 크론잡, ansible, systemd, bash 스크립트 등으로 했을 것임.

    • 자기 손으로 곡예장을 만든 느낌임. 그렇게 많은 것들을 설치하지 말아야 함. 뭔가를 추가할 때마다 기술 부채와 유지비용이 붙는 법임, 무료 툴이어도 마찬가지임. 오토스케일이 절약보다 부채/유지비가 더 크면 그냥 꺼버리는 게 나음.

    • 비슷한 서비스 집합을 개별적으로 구성해서 운영했다면 훨씬 큰 유지관리 부담임. 하지만 Kubernetes는 불붙은 후 방치할 수 있을 정도로 관리가 쉬움. 단, 자신이 뭘 하고 있는지 알고 있어야 “멋져 보이는 툴” 설치하는 유혹에 빠지지 않음.

  • K8S는 yaml 강제도 아님. idiomatic할 수는 있지만, 필수는 아님. kubectl apply는 처음부터 json도 지원했고, endpoint도 json과 grpc 임. jsonnet 같은 다양한 언어에서 config 생성 가능함. 두 번째로, Helm 차트에서 dependency와 dependency ordering가 왜 이슈가 되는지 궁금함. Kubernetes의 주된 아이디엄은 루프에 있음: 종속성이 없으면 앱은 recoverable error로 치고, 가능할 때까지 반복 시도하는 식임. 아니면 crash해서 ReplicaSet 컨트롤러가 자동 재시작함. 차트에 dependency가 없으면 dependency 충돌도 없음. 진짜 의존하는 앱이면 Helm 차트 내에 종속 앱/서비스를 같이 포함시키는 게 맞음.

    • (주요 의견 인용) > crash 상황에서 ReplicaSet 컨트롤러가 앱 재시작해준다는 건 충분하지 않음. 예를 들어 keycloak이 1분 걸려서 뜨면, 여기에 의존하는 서비스가 keycloak 없이 바로 crash나고, 여기서 retry하다가 throttle이 걸려서 keycloak 뜬 뒤에도 5~10분 동안 쓸데없이 대기함. 그냥 의존관계가 확실하다면, main 컨테이너 넘기기 전 init 컨테이너로 의존 서비스 체크하고 넘어가는 게 더 적합함. Kubernetes에 명시적인 start dependency 선언 기능이 있으면 좋겠다고 생각함. crash나고 몇 번 재시도하다 throttle 거는 게 답이 아님. dependency는 그냥 존재하는 현실임.

    • 의존성 실패는 꼭 recoverable해야 한다고 생각함. 예전에 실제 사용하지도 않는 dependency 때문에 fail-closed 동작하다 장애난 경험 있음. 서버 사이 의존성은 거의 다 soft dependency임. downstream dependency 안 되면 그냥 500 던지고, 로드밸런서가 unhealthy 서버 피해가면 됨.

    • “supposed to”라고 얘기하지만, 그건 in-house 소프트웨어스택 구축 케이스에만 잘 맞음. 이미 만들어진 오래된 소프트웨어가 docker만 지원하다가 kubernetes에서 돌릴 수 있게 된 사례도 많음. 개발자가 자기 철학대로 툴을 만들면, 사람들은 어차피 원하던 방식대로 써서 엉망진창 결과가 나오기도 함. 결국 사람들한테 다양한 기능과 선택권을 줘야 하고, 시장은 원하는 대로 활용함.

    • “Kubernetes의 주요 아키텍처 특징 = 반복적 루프(reconciliation loop)”라는 말, 매우 동의함. 현재 상태를 관찰, 원하는 상태와 diff, 그리고 diff만큼 적용. 끝없이 반복. 성공/실패가 아니라, 오직 현재와 희망 상태간 차이만 iterative하게 해결. 이 패턴은 PID 제어 등 기계제어 시스템의 'good enough technology'와도 유사하다고 봄.

    • “yaml 말고 json도 쓸 수 있다”는 사실로 건을 비판하는 건 논점이 아님. 모두가 진짜 관심 있는 부분이 아님. 쓸데없는 트집이라는 생각임.

  • yaml 대신 HCL로 교체하자는 의견엔 강하게 반대함. HCL은 개발자가 보기 어렵고 읽기도 힘듦. import 지원 여부, 디버깅 난이도 등 usability에서 불만이 많음. 왜 protobuf 같은 인터페이스 정의 언어를 중심에 두고, 사용자 취향대로 형태만 변환 못하게 했는지 이해 못함.

    • HCL은 최악임. k8s yaml만으로도 모자란 적 없음. 혹시 구성이 너무 복잡하다면 config map보다는 app 설계 자체 문제에 가까움.

    • 사실 HCL이든 JSON이든 YAML이든, 클라이언트에서 직렬화/역직렬화 하면 되는 일임. 즉, 이건 Kubernetes 자체 이슈가 아니라, 단순히 외부 변환 레이어일 뿐임.

    • Kubernetes 인터페이스 정의는 이미 protobuf 기반임(crd는 예외로 하고).

    • 내 주된 HCL 불만은 for loop 문법임. 정말 최악임.

    • “HCL 개발자가 어렵고 린트나 디버깅이 어렵다”는 얘기는 새로운 걸 배우기 싫어서 나온 얘기에 더 가깝다고 들림. 복잡한 도메인을 HCL 배우는 것과 혼동해서 생긴 문제처럼 보임.

  • “Kubernetes 2.0” 스타일로 nebulous 프로젝트 개발 중임(아직 pre-alpha 단계). 목표는, 전세계적으로 분산/경량화, 노트북에서 싱글 바이너리 실행 가능+클라우드에서 수천 노드까지 확장, Tailnet 네트워크/BitTorrent 스토리지/멀티테넌시/라이브 마이그레이션 등. 대부분 요구사항은 ML 운영(특히 GPU 부족 현상)에서 발생했고, 앞으로 ML이 평범한 시대라면 이게 기본이 될지도 모름.

    • 라이브 마이그레이션이 흥미로움. 우리는 지금 여러 클러스터와 클라우드 간 오토스케일링 기반 가격전략 쓰는데, 라이브 마이그레이션은 또 다른 차원의 도전임.

    • 이건 Kubernetes가 아니라, GPU 운영에 특화된 별도 시스템임.

    • “글로벌 분산”은 오히려 non-requirement일지도 모름. Tailnet을 기본 네트워크로 쓴다면 오히려 바로 빼버리고 싶은 기능임. Kubernetes가 싱글 NIC 가정하는 건 클라우드에 맞춘 답답한 유산임(여러 CNI, 최근 Multus(참조: redhat 블로그)같은 프로젝트가 반가움). Multi-tenant 설계는 k8s와 뭐가 실질적으로 다른지 궁금함. BitTorrent로 storage 한다면, 퍼블릭 컨테이너 이미지까지 공유한다면 egress 트래픽 요금 엄청남.

    • GitHub를 보면 Chart.yaml이 보이고, 심지어 템플릿 provider_aws.yaml 등은 정말 하지 않았으면 하는 코드 패턴임.

  • Kubernetes는 지금도 정말 복잡하다고 느낌. 대중화로 인해 덜 느껴질 뿐임. Kubernetes 2.0에서는 사용자 경험, 특히 자주 하는 운영(앱 배포, 서비스 노출, 서비스 계정/이미지 변경 등)이 더 간소해지면 좋겠음. 하지만 지금 대세가 LLM이라 후속 개발은 어려워 보임.

    • Kubernetes는 추상화 계층이 너무 많음. pods는 멋진 핵심 개념인데, deployment, rep set, namespace 등이 추가되면서 Docker Swarm만큼 심플했으면 한다는 생각이 듦. Terraform도 단일 계층이고 배우기 편했음. K8s 학습曲선이 진짜 가파른 걸 실감하는 중임.

    • “컴퓨터 프로그램의 타입 구분은 인간의 인식 결과”라는 생각이 드는 이슈임. 오퍼레이터/컨트롤러는 과거 COM/CORBA처럼 지나치게 추상화되어 있음(장점이자 단점). 단순한 구현엔 더 제한적인 k8s-lite가 오히려 적합하다고 느낌. 반면, 복잡한 환경엔 오히려 k8s의 기존 추상화도 부족한 경우가 많았음. 하나의 시스템(Kubernetes 2.0이든 뭐든)이 현실 문제 전부를 감 싼 상태로 인간 개발자/설계자가 다룰 수 있을지 의문임.

  • “sane default” 즉, 특별히 고르지 않아도 기본 상태가 적당히 충분한(네트워크/스토리지/로드밸런서 등) 시스템을 원함. yaml과 HCL 모두 별로임. 더 나은 config 방법이 필요하고 언어만 바꾼다고 해결될 문제도 아님. IPv6는 반드시 필요하다고 생각. Docker, 컨테이너, Kubernetes 모두 내부는 IPv6-only로 했어야 하며, IPv4는 ingress controller에서 예외 처리가 맞음.

    • “Sane defaults”와 “Managed 서비스 고객 전환” 사이에는 본질적 갈등이 있음. K8s를 오래 지켜볼수록 스토리지/네트워크 등 “batteries not included” 철학이 커지고, 그걸 AWS/GCP 등이 비싼 연동서비스로 파는 현상이 짙어짐. 사실상 현실 K8s는 오픈소스가 아니라, 클라우드 gap filler 판매촉진 툴로 쓰이는 측면까지 보임.

    • (개인경험) Terraform/HCL이 YAML보다 나은 점은, 보이지 않는(인비저블) 문자에 의존하지 않아 더 읽기 쉬움.

    • "sane defaults" 때문에 k3s가 훨씬 더 마음에 듦.

  • 2.0 릴리즈로선 다소 소박한 위시리스트라고 생각. 내 주변 모두 프로덕션 k8s 복잡성에 불만이 큼. 백워드 컴패티빌리티와 심플함을 어떻게 동시에 구현할지가 진짜 핵심임. 보통 백워드컴패트덕분에 복잡도가 폭증함(새 시스템이 신구 기능을 죄다 떠앉게 됨).

    • “복잡성을 어디서 얼마나 덜어낼 수 있는가”가 결국 쟁점임. 지금까지 본 각종 k8s 추상화들은 극소수만 커버하거나(heroku류 wrapper) 또는 자체 DSL이 생겨서 오히려 학습곡선만 높아짐(결국 다시 복잡한 k8s+잡 DSL 2개나 배워야 함).

  • 나는 이미 Terraform으로 클러스터 및 앱을 관리하면서 “Kubernetes 2.0 월드”에 살고 있다고 느낌.

    • HCL/타입/리소스 종속성/데이터 조작을 바로 쓸 수 있음
    • tf apply 한방으로 클러스터, 노드, 클라우드 연동(S3 등), 클러스터 내 서비스까지 한 번에 구성
    • terraform module로 코드 재사용하고, 비-K8s 인프라도 통합. 예를 들어 Cloudflare ZeroTrust 모듈로 5줄 코드로 공개 SSO 엔드포인트 제공 가능. (클러스터에 cloudflared 배포+Cloudflare API 터널 config)
    • 주요 인프라 업체가 자체 Terraform module을 잘 만들어놓고, provider lockfile로 모듈/프로바이더 의존성 관리도 편함
    • Helm terraform provider로 헬름 차트도 자유롭게 관리. 특히 “namespace 생성+operator 배포+custom resource 생성”만 하는 헬름 차트는 operator만 설치하고 CRD를 terraform에서 직접 관리
    • 단점은 apply 프로세스 orchestration이 약간 번거로움(YAML 등도 유사), 우리는 Spacelift로 이슈 해결
    • 사실 시스템의 상태를 k8s state와 Terraform state 두 번 관리하는 건 비효율적임. 리소스가 mutating webhook 등으로 변경되면 “computed fields” 설정도 필요함. 그래서 애플리케이션 레벨 관리는 Terraform에서 지양함. 클러스터 자체는 Terraform으로 관리하는 것도 괜찮다고 봄.

  • 프론트엔드 출신으로서, Kubernetes가 굉장히 직관적이었다고 느낌. 기존에는 데이터를 입력받아 UI를 반응적으로 만들었는데, 이제는 제어판에 리소스와 config를 맞춰주는 코드를 쓰는 느낌임.

답변달기