Kubernetes : 해결된 문제들로 고통 받지 말아야 하는 이유

개발자에게 Kubernetes는 위협 요소가 될 필요가 전혀 없습니다. 클라우드 네이티브 커뮤니티의 적절한 툴과 통찰력을 통해 개발을 그 어느 때보다 단순하고 강력하게 수행할 수 있습니다.

개발자들에게 Docker와 더 넓은 컨테이너 혁명에 대해 가장 흥미로운 것 중 하나는 개발자 경험을 향상시키는 방법이었습니다.

기본 이미지는 새 프로젝트에 필요한 탈출 속도를 줄여줍니다. 휴대용 샌드박스 환경은 "내 컴퓨터에서 실행되는" 악몽 같은 스크램블을 줄입니다. 도커는 개발자의 관점에서 만들어졌고, 그것은 보여주었습니다.

Docker는 StackOverflow의 연간 설문 조사 결과에서 "가장 사랑받는" 개발자 도구와 "가장 원하는" 개발자 도구 부문에서 1위를 차지했습니다.

하지만 컨테이너가 현재 세계를 지배하는 길에 어떤 일이 일어났습니다. 복잡한 컨테이너형 애플리케이션을 규모에 맞게 실행하기 위해 Kubernetes와 같은 오케스트레이션 시스템은 전체적인 운영 관점을 취했습니다. 일리가 있지만 개발자들에게는 엄청난 비용이 들었습니다. 그리고 쿠베르네테스의 성숙도와 편재성이 증가함에 따라, 더 나은 방법이 있다는 것이 그 어느 때보다 분명해졌습니다.

Kubernetes는 Google의 내부 "Borg" 클러스터 관리 시스템에 설계를 뿌리로 두고 있습니다. Docker의 유행 이후 개발자 중심 도구가 아니라 괴짜처럼 확장된 은유에 대한 좋은 핑계였습니다.

스타 트렉에서 보그는 그들이 마주치는 모든 형태의 삶을 일관성 있고 일관성 있고 합리적인 시스템에 동화시키는 사이버네틱 사람들/패러다임입니다. 따라서 구글의 시스템의 이름은 IT 인프라 운영자라면 모든 동화와 표준화가 꽤 좋게 들립니다. 구성 요소와 응용 프로그램을 Borg가 생명체를 다루는 방식으로 처리하려고 합니다. 표준화된 방식으로 관리할 수 있는 공통 추상화 집합으로 시스템에 통합합니다.

운영의 관점에서 보면 그것은 훌륭합니다. 그러나 대규모 오케스트레이션 시스템의 필요성과 우선순위는 인간이 코드를 작성하는 것과 같지 않습니다. 따라서 개발자들에게 쿠버네티스의 핵심 개념조차도 완전히 다른 종류의 생각에서 비롯된 것처럼 이질적으로 보일 수 있습니다. 포드, 노드, ReplicaSet 등 모든 것이 막연하게 과학적인 허구처럼 들립니다. 그러나 이러한 개념적인 생소함은 개발자들에게 영구 스토리지를 사용하여 자신이 알고 있다고 생각하는 것을 다시 배우도록 요청하는 방식에 비하면 아무것도 아닙니다. 그리고 YAML 매니페스트의 지속적인 번거로움이나 쿠버네티스 내부 개발 루프의 비효율성에 비하면 아무것도 아닙니다.

 

 

Kubernetes : 해결된 문제들로 고통 받지 말아야 하는 이유

 

 

불편한 루프

내부 개발 루프는 작성에서 테스트, 디버깅 코드에 이르기까지 주어진 프로그래머의 하루 주기입니다. 로컬 시스템에서 노드 또는 파이썬 코드를 작성하고 테스트하는 경우, 기존 서버에 배포하는 경우 내부 루프는 매우 간단합니다. 코드를 작성하고 실행하고 문제를 해결하는 것입니다. 헹구고 반복합니다.

그러나 동일한 코드가 컨테이너화되어 쿠버네티스를 통해 배포될 예정이라면 이제 몇 가지 단계가 더 있습니다. 컨테이너 이미지 구축, 레지스트리 업로드, 쿠버네티스 리소스 생성, 실제로 컨테이너를 실행한 후 발생하는 문제 디버깅(순수한 코드 문제일 수 있음), 또는 잘못된 Kubernetes 구성의 결과일 수 있습니다. 이러한 모든 작업을 실제로 수행하려면 프로덕션 환경에 맞는 개발 클러스터가 필요합니다.

단순한 사실은 표준 Kubernetes 개발 루프가 개발자의 행복이나 효율성에 맞추어져 있지 않다는 것입니다. 개발자의 관점에서 볼 때, 이것은 차선의 프로세스입니다.

여기서 요점은 "Kubernetes는 너무 어렵다"거나 "개발자들은 Kubernetes를 싫어한다"는 것이 아닙니다. 방금 설명한 루프가 쿠버네티스 개발자들에게 가능한 유일한 경험은 아니지만, 단순히 박스 밖에서 쿠버네티스를 사용한다면 그것은 기본 경험입니다.

다행히도, 쿠베르네테스는 훨씬 더 나을 수 있습니다.

 

 

더 많은 기능

쿠베르네테스가 외계인처럼 보이고 접근할 수 없는 것처럼 보일지라도, 실제로 그것은 스스로의 학습 곡선 문제를 해결할 수 있는 수단을 제공합니다. Kubernetes는 동화에 대한 갈망 때문에 근본적으로 그리고 결정적으로 확장되도록 설계되었습니다. 그리고 그것의 천재적인 확장성은 우리로 하여금 쿠베르네테스 자신의 복잡성을 추상화할 수 있게 합니다.

클라우드 네이티브 에코시스템은 Kubernetes를 더욱 풍부하고 친숙하게 만들기 위해 시너지 효과를 내는 오픈 소스 툴로 가득합니다:

- Knative: Kubernetes에서 서버리스 배포를 위한 프로젝트로, 오픈 소스 클라우드에 구애받지 않는 플랫폼에 서버리스의 단순성과 개발자 친화성을 제공합니다.

- 라군: 프로덕션 이미지와 동일한 이미지로 개발 환경을 구축하여 환경 간의 패리티를 단순화하는 웹 애플리케이션 개발 플랫폼입니다.

- Argo: 개발자들이 Git를 단일 진실 소스로 사용할 수 있는 CI/CD 도구 모음으로, "GitOps"라고 불리는 인기 있는 접근 방식입니다

- 프로메테우스: Kubernetes용 Lens 그래픽 사용자 인터페이스에서 Grafana 시각화 플랫폼, CI/CD 시스템에 이르기까지 모든 것에 플러그인할 수 있는 풍부한 API를 갖춘 관찰 가능성 시스템으로 개발자들이 클러스터에서 무슨 일이 일어나고 있는지 계속 알 수 있습니다.

 

Kubernetes는 개발자들의 삶을 더 쉽게 만들 수 있는 놀라운 오픈 소스 툴링으로 넘쳐납니다.

개발자들이 완전히 새로운 패러다임에 사로잡힐 필요는 없습니다. 개발자 경험의 우선순위를 정하고 클라우드 네이티브 전문 지식과 점점 더 풍부해지는 에코시스템을 활용하면 됩니다. 올바른 툴과 툴을 구성하는 방법을 아는 것은 사소한 일이 아니지만, 이는 운영자가 필요로 하는 부분입니다. 리소스가 제한된 조직의 경우 DevOps-as-a-Service 오퍼링을 사용하면 운영 종료 시 번거로움을 최소화하면서 더 나은 개발 환경을 제공할 수 있습니다.

스타 트렉 팬들은 보그의 위협이 동화된 사람들로부터 얻은 지식 때문에 저항한다는 것을 알고 있습니다. 개발자에게 Kubernetes는 위협 요소가 될 필요가 전혀 없습니다. 클라우드 네이티브 커뮤니티의 적절한 툴과 통찰력을 통해 개발을 그 어느 때보다 단순하고 강력하게 수행할 수 있습니다.